GNOME Bugzilla – Bug 673991
[0.10] basetransform regression: gstreamer hangs when accessing webcam (on specific hardware)
Last modified: 2012-12-11 10:53:13 UTC
The bug has been reported on https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/966294 "Every time I install ubuntu on this hardware with ubiquity it hangs before the camera loads and after clicking continue on the "choose a user" screen. ... This problem also happens when trying to activate the camera with cheese. ... Upgrading libgstreamer0.10-0 to the Precise version re-creates the problem. So the regression likely happened in the gstreamer0.10 source."
some addition infos from the launchpad bug comments "Did some extra debugging in webcam.c initially, I tracked down the hanging call to be: if (gst_element_set_state (priv->camerabin, GST_STATE_PLAYING) == GST_STATE_CHANGE_FAILURE) { or more specifically gst_element_set_state(priv->camerabin, GST_STATE_PLAYING)" https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/966294/comments/41 has details it points to http://paste.ubuntu.com/926326/ as "fixing" the issue (reverting part of f56c6e12255b37d75b1eb949e434fa8e3bb33f51" "GST_DEBUG=5 for cheese (camerabin) and ubiquity (camerabin2) both with the revert (working behaviour) and without (UI hanging). https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/966294/+attachment/3052263/+files/cheese.gz https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/966294/+attachment/3052264/+files/cheese-with-revert.gz https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/966294/+attachment/3052265/+files/ubiquity.gz https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/966294/+attachment/3052290/+files/ubiquity-with-revert.gz"
Could you also get a backtrace of all threads when everything hangs?
Response in launchpad bug was: "It never really hung for me. What happened was that the ubiquity tread used all the CPU it could get and start eating up all the memory. After almost an hour of unresponsiveness the last bit of memory and swap was gobbled up and the ubiquity thread was killed (by 'kswap0' or something with a similar name). After that the liveCD desktop would start. It does feel like something hangs, but the machine is actually really busy (and unresponsive). I don't have a backtrace or the bugged .iso to reproduce the bug, sorry." Not sure what to do about this. The commit in question that was reverted downstream is this btw: commit f56c6e12255b37d75b1eb949e434fa8e3bb33f51 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed May 4 11:29:15 2011 +0200 basetransform: In getcaps() prefer the caps order and caps of downstream if possible It would be useful, to just run it in gdb and then after it has been going at it for multiple seconds at full CPU just press control-C and get a stack trace of all threads, so we get a rough idea of where it's doing things.
Created attachment 231155 [details] GDB output of a hanging cheese no. 1
Created attachment 231156 [details] GDB output of a hanging cheese no. 2
I have a cheese that hangs in gstreamer. I am currently investigating whether the suggested revert fixes the issue for me.
Confirming: The revert of commit f56c6e12255b37d75b1eb949e434fa8e3bb33f51 fixes the issue for me.
Thanks for the additional information. I believe this issue is fixed in GStreamer 1.0, could you re-test with a cheese version that uses 1.0 ? It looks like it might be a duplicate of, or related to, bug #684981 as well. Perhaps you could test if cherry-picking commit 507fc9cea7d587446fba08dfeac7e063e14c680e in core helps as well?
Cherry-picking commit 507fc9cea7d587446fba08dfeac7e063e14c680e on GStreamer 0.10.36 caused a segfault once, but besides that seems to fix the issue too. Unfortunately I can't reproduce the segfault anymore.
Hrm, ok. I think it's quite unlikely that that patch causes any crashes. "Freak crash somewhere else" seems more likely to me. You didn't get a stack trace or core file by any chance I suppose? I'm happy to cherry-pick 507fc9ce into 0.10. Reverting f56c6e12 not so much.
cherry-picking that into 0.10 should be safe, yes
Sorry, no stack trace or core file for the "freak crash somewhere else" :-/ But as it was only a one time crash, I of course do not object against cherry-picking 507fc9ce into 0.10.
commit 401f9b3de72de759c76da155a339c754b653bf9d Author: Tim-Philipp Müller <tim.muller@collabora.co.uk> Date: Sat Sep 29 14:35:58 2012 +0100 value: avoid duplicates when intersecting lists Fixes negotiation taking a ridiculous amount of time (multiple 10s of seconds on a core2) when there are duplicate entries in lists. Could have a negative performance impact on other scenarios because we now have to iterate the dest list to avoid duplicates, but we don't have a lot of lists any more these days, and they tend to be small anyway. The negatives are hopefully countered by the positive effects of reducing the list length early on in the process. And in any case, it's the right thing to do. Based on patch by Andre Moreira Magalhaes. https://bugzilla.gnome.org/show_bug.cgi?id=684981