GNOME Bugzilla – Bug 695981
Segmentation fault on gst_v4l2_buffer_pool_process after sending "start-capture" signal to camerabin2 just after setting the pipeline state to PLAYING
Last modified: 2013-07-26 09:27:57 UTC
Created attachment 239044 [details] script to reproduce the bug I'm developing a python application that uses Gstreamer Camberabin2, and sometimes I get a segfault when starting the application. I attach a small script that reproduces the problem. Many times it runns correctly, but it sometimes crash, so you may have to run it a few (or not so few) times. I'll also attach different versions of the same backtraces with different levels of detail. Does this bug only affect during the creation of the camerabin2 or can it crash the application later? Can it be dependent on the webcam I use?
Created attachment 239045 [details] Simple backtrace
Created attachment 239046 [details] Simple backtrace of all the threads
Created attachment 239047 [details] Full backtrace
Created attachment 239048 [details] Full backtrace of all the threads
Created attachment 239062 [details] A smaller reproduction script, with a workaround commented out I kept investigating about this bug and created a better reproduction script. It doesn't have all the unnecessary Gtk stuff as I realized that the bug will affect me just by creating the pipeline, it doesn't matter that I never use it. The script makes use of fork() to create sub-processes iteratively until one of them crashes. The expected behavior would be the program running forever without printing anything. The bugged behavior would be printing "Program crashed" and exiting correctly. I also found a workaround to this bug. It consists on sleeping the processes during some time (say 100ms) after setting the pipeline's state to PLAYING before sending the first "start-capture" signal to camera bin. It's commented out on the reproduction script. I tested it during a long time (1000s of executions) and it never crashed. I filed this bug under gst-plugins-good as the backtraces said it crashed on v4l, but maybe is a camerabin2 bug. I'm afraid I'm not qualify enough to be sure about that.
I can't reproduce it here with your script.. Which kernel version and camera do you have ?
Created attachment 241608 [details] [review] I think I understand this bug, what happens is that you can get a renegotiate event between the time that gst_base_src_start_complete() is executed and when the loop starts. The patch that I'm proposing to revert would then remove the reconfigure flag from the pad, which had the side effect of never caling set_caps, and of never creating the buffer pool. So I suggest a different way to disable renegotiation by just doing it at the start of the negotiate method. Revert "v4l2: disable renegotiation" This reverts commit d1b26e1d594ab2b63324e43a36330475e98cdf18.
Created attachment 241609 [details] [review] v4l2src: Disable renegotiation in the negotiate method This way, we don't block the initial negotiation.
Btw, mucho thanks to jpwhiting for doing all the testing for me as I can't reproduce it.
*** Bug 697236 has been marked as a duplicate of this bug. ***
Comment on attachment 241609 [details] [review] v4l2src: Disable renegotiation in the negotiate method Looks good to me, please push
pushed! commit b5a9ed20e1018741a4f1ac511f3e11c564aac410 Author: Olivier Crête <olivier.crete@collabora.com> Date: Mon Apr 15 19:53:28 2013 -0400 v4l2src: Disable renegotiation in the negotiate method This way, we don't block the initial negotiation. Thanks to Jeremy Whiting for doing all the testing. https://bugzilla.gnome.org/show_bug.cgi?id=695981 commit 3340baa37473ae3e0b520a4570fa05c463227904 Author: Olivier Crête <olivier.crete@collabora.com> Date: Mon Apr 15 19:46:12 2013 -0400 Revert "v4l2: disable renegotiation" This reverts commit d1b26e1d594ab2b63324e43a36330475e98cdf18. This causes the initial negotiation to never happen if a reconfigure event is received after gst_base_src_start_complete() but before the loop starts. https://bugzilla.gnome.org/show_bug.cgi?id=695981
*** Bug 704918 has been marked as a duplicate of this bug. ***
This is a crash.. cherry-picked to 1.0 branch