After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 142813 - [PATCH] Deadlock in optimal scheduler
[PATCH] Deadlock in optimal scheduler
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.8.1
Other Linux
: Normal blocker
: 0.8.4
Assigned To: Wim Taymans
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-20 01:26 UTC by David Moore
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4


Attachments
Patch to fix deadlock (886 bytes, patch)
2004-05-20 01:30 UTC, David Moore
none Details | Review
improved patch (1.18 KB, patch)
2004-07-19 16:22 UTC, Wim Taymans
none Details | Review

Description David Moore 2004-05-20 01:26:59 UTC
When a group gets scheduled by the non-cothread version of the optimal
scheduler, a "pre-run" and "post-run" function is executed for each element in
the group.  However, if the group is altered during the iteration such that an
element is removed from that particular group, the post-run function is not
executed for that element.  This causes a deadlock the next time the element is
iterated, because it's properties mutex has been locked by the pre-run function,
but never unlocked by the post-run function.

For example, this scenario would happen with this pipeline:

filesrc ! spider ! osssink

If we play a song until EOS, and then delete the spider element during the EOS
handler, both filesrc and osssink will be removed from the group.  If we then
create a new spider and link it back together with the same filesrc and osssink,
the osssink and filesrc properties mutex's will deadlock the first time they are
iterated.
Comment 1 David Moore 2004-05-20 01:30:43 UTC
Created attachment 27860 [details] [review]
Patch to fix deadlock

This patch fixes the aforementioned deadlock by creating a reference to each
element of the group before its pre-run function is executed.  The list of
elements is duplicated, so we can run the post-run function later for each
element that we ran the pre-run function for, even if the group changes during
the iteration.	After the iteration, we run the post-run functions, and unref
each element.

The patch applies to 0.8.1, and I've also tested it with 0.8.1, but I suspect
it also works fine with HEAD.
Comment 2 Wim Taymans 2004-07-16 17:23:25 UTC
The patch is almost correct, it does not free the copied list. In the testsuite
is now a testapp that demonstrates the deadlock, after applying your patch
(+g_slist_free) the tests work fine. Going to test some more and push it for the
next release.
Comment 3 Wim Taymans 2004-07-19 16:22:03 UTC
Created attachment 29654 [details] [review]
improved patch

improved patch. frees the list and makes sure that the right thing even happens
when the post/pre functions mess with the group element list.
Comment 4 Thomas Vander Stichele 2004-07-20 10:55:12 UTC
deadlock with patch, marking as blocker.