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 761703 - Recursive backtrace that exceeds stack size with v4l
Recursive backtrace that exceeds stack size with v4l
Status: RESOLVED DUPLICATE of bug 759292
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.6.2
Other Linux
: Normal critical
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-02-08 10:59 UTC by Ilya Kulakov
Modified: 2017-08-05 16:31 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
GST_DEBUG=v4l*:9 (1.29 MB, application/zip)
2016-02-08 12:05 UTC, Ilya Kulakov 		  Details
GST_DEBUG=v4l*:9 (509.83 KB, application/zip)
2016-02-08 12:10 UTC, Ilya Kulakov 		  Details
Block recursive calls to gst_v4l2_buffer_pool_resurect_buffer() (1.37 KB, patch)
2017-06-28 19:13 UTC, Matt Fischer 		none Details | Review

Description Ilya Kulakov 2016-02-08 10:59:10 UTC 
If you unplug camera which is currently being used for recording, there is a chance that gstreamer will exceed stack size and application will crash.

+ Trace 235955

  • #0 v4l2_ioctl
    from /usr/lib/x86_64-linux-gnu/libv4l2.so.0
  • #1 gst_v4l2_allocator_qbuf
    at gstv4l2allocator.c line 1243
  • #2 gst_v4l2_buffer_pool_qbuf
    at gstv4l2bufferpool.c line 1111
  • #3 gst_v4l2_buffer_pool_release_buffer
    at gstv4l2bufferpool.c line 1403
  • #4 gst_buffer_pool_release_buffer
    at gstbufferpool.c line 1296
  • #5 _gst_buffer_dispose
    at gstbuffer.c line 627
  • #6 gst_mini_object_unref
    at gstminiobject.c line 448
  • #7 gst_buffer_unref
    at <....>/usr/include/gstreamer-1.0/gst/gstbuffer.h line 364
  • #8 gst_v4l2_buffer_pool_resurect_buffer
    at gstv4l2bufferpool.c line 685
  • #9 ??
    from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  • #10 g_signal_emit_valist
    from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  • #11 g_signal_emit
    from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
  • #12 gst_v4l2_allocator_release
    at gstv4l2allocator.c line 369
  • #13 _v4l2mem_dispose
    at gstv4l2allocator.c line 138
  • #14 gst_mini_object_unref
    at gstminiobject.c line 448
  • #15 gst_memory_unref
    at ../gst/gstmemory.h line 349
  • #16 _gst_buffer_free
    at gstbuffer.c line 665
  • #17 gst_v4l2_buffer_pool_release_buffer
    at gstv4l2bufferpool.c line 1457
  • #106309 gst_tee_handle_data
    at gsttee.c line 739
  • #106310 gst_tee_chain
    at gsttee.c line 780
  • #106311 gst_pad_chain_data_unchecked
    at gstpad.c line 4086
  • #106312 gst_pad_push_data
    at gstpad.c line 4338
  • #106313 gst_pad_push
    at gstpad.c line 4454
  • #106314 gst_base_transform_chain
    at gstbasetransform.c line 2369
  • #106315 gst_pad_chain_data_unchecked
    at gstpad.c line 4086
  • #106316 gst_pad_push_data
    at gstpad.c line 4338
  • #106317 gst_pad_push
    at gstpad.c line 4454
  • #106318 gst_base_src_loop
    at gstbasesrc.c line 2845
  • #106319 gst_task_func
    at gsttask.c line 331
  • #106320 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #106321 ??
    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
  • #106322 start_thread
    at pthread_create.c line 312
  • #106323 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 111 

Stack in the middle is being repeated.
Comment 1 Ilya Kulakov 2016-02-08 12:05:32 UTC 
Created attachment 320617 [details]
GST_DEBUG=v4l*:9
Comment 2 Ilya Kulakov 2016-02-08 12:10:28 UTC 
Created attachment 320618 [details]
GST_DEBUG=v4l*:9

Ignore previous log, it has some unnecessary data
Comment 3 Nicolas Dufresne (ndufresne) 2016-02-08 14:45:03 UTC 
Can you retest on 1.6.3 and master ? Sounds familiar, I thought someone had fixed it.
Comment 4 Nicolas Dufresne (ndufresne) 2016-02-08 15:14:09 UTC 
Nevermind, I managed to reproduce once out of 10 tries. Will need to be investigated.
Comment 5 Nicolas Dufresne (ndufresne) 2016-02-08 15:15:39 UTC 
(note, I see stack trace in the kernel, there might be a miss-behaviour there too, we'll need to find what and protect against it)
Comment 6 Nicolas Dufresne (ndufresne) 2016-02-08 15:16:29 UTC 
A trace that matters:
0:00:07.512508644  1613       0xd26990 ERROR          v4l2allocator gstv4l2allocator.c:1245:gst_v4l2_allocator_qbuf:<v4l2src0:pool:src:allocator> failed queing buffer 0: Aucun périphérique de ce type
Comment 7 Matt Fischer 2017-06-28 19:13:59 UTC 
Created attachment 354638 [details] [review]
Block recursive calls to gst_v4l2_buffer_pool_resurect_buffer()

I recently encountered this bug as well.  I don't know the v4l2 code well enough to fully understand what is going wrong, but the immediate cause is that the group-released signal is triggering a call to gst_v4l2_buffer_pool_resurect_buffer(), which allocates and frees a buffer.  The free results in group-released being sent again, so the code recurses infinitely.

The simplest solution is just to block reception of the signal while the signal handler is running.  This seemed to resolve the problem for me, but I don't know if it is the correct solution.  I've attached a patch, can anybody comment on its correctness?
Comment 8 Nicolas Dufresne (ndufresne) 2017-08-05 16:31:29 UTC 

*** This bug has been marked as a duplicate of bug 759292 ***