GNOME Bugzilla – Bug 637057
[plugin-scanner] gstpoll fails with select backend
Last modified: 2011-01-04 13:49:46 UTC
Created attachment 176257 [details] Log of it hanging Running gst-inspect hangs on osx when it runs on a separate process. Doing git bisect leads to this commit: 22fa4470e2497a1b766322497e285ca199709fcc Trace: (gdb) thread apply all bt
+ Trace 225089
Thread 3 (process 25075)
Thread 2 (process 25075)
And I'm also attaching a gst debug log here. If it helps, this setup only has the core package, so it should only find coreelements plugin.
I remember seeing a similar bug some time ago but can't find it now. What's 22fa4470e2497a1b766322497e285ca199709fcc for you? I can't find it in core
That would be the GstPoll refactoring by wim: commit 22fa4470e2497a1b766322497e285ca199709fcc Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Wed Nov 3 17:56:24 2010 +0100 poll: Refactor and make more lockfree Refactor the wakeup of the poll thread. Always make a control socket to make things easier. Make more methods lockfree. The osx buildslave is getting the same issue fwiw
Ah, my core was too old :) But that's a different bug then, the one I remembered was reported a few months ago.
You could try to disable always creating the control socket, that was the biggest change. Like this: diff --git a/gst/gstpoll.c b/gst/gstpoll.c index af34f66..8dd3286 100644 --- a/gst/gstpoll.c +++ b/gst/gstpoll.c @@ -555,6 +555,7 @@ gst_poll_new (gboolean controllable) nset->active_fds = g_array_new (FALSE, FALSE, sizeof (struct pollfd)); nset->control_read_fd.fd = -1; nset->control_write_fd.fd = -1; +#if 0 { gint control_sock[2]; @@ -570,6 +571,7 @@ gst_poll_new (gboolean controllable) gst_poll_add_fd_unlocked (nset, &nset->control_read_fd); gst_poll_fd_ctl_read_unlocked (nset, &nset->control_read_fd, TRUE); } +#endif #else nset->mode = GST_POLL_MODE_WINDOWS; nset->fds = g_array_new (FALSE, FALSE, sizeof (WinsockFd));
That makes gst-inspect work again, but causes failures on the check tests: "Unexpected critical/warning: gstsystemclock: write control failed in wakeup_async, trying again : 9:Bad file descriptor" I guess we need to add some more ifs on other calls using the control sockets
I find that the hang does not occur if I invoke gst-inspect with: $ gst-inspect --gst-disable-registry-fork
gstpoll on macosx uses pselect due to a broken poll implementation. The timeout seems to be due to the fact that there now is an extra fd to track... which still exists *after* the 'regular' fds have been removed.
Also fails on linux when you #undef' HAVE_POLL and HAVE_PPOLL in gstpoll (which makes it use pselect).
Created attachment 177427 [details] [review] pluginloader: Always mark reception as complete after EXIT Avoids waiting forever on gst_poll_wait when using the select backend. Fixes #637057
commit 36d44b3e5287af081dbea9840689e96d4f962cf1 Author: Edward Hervey <edward.hervey@collabora.co.uk> Date: Mon Jan 3 20:32:23 2011 +0100 pluginloader: Always mark reception as complete after EXIT Avoids waiting forever on gst_poll_wait when using the select backend. Fixes #637057