Bug 761703 – Recursive backtrace that exceeds stack size with v4l

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


Summary:	Recursive backtrace that exceeds stack size with v4l


Status:	RESOLVED DUPLICATE of bug 759292

Product:	GStreamer
Classification:	Platform
Component:	gst-plugins-good
Version:	1.6.2
Hardware:	Other Linux

Importance:	Normal critical
Target Milestone:	git master
Assigned To:	GStreamer Maintainers
QA Contact:	GStreamer Maintainers

URL:
Whiteboard:

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 ***