[Bug 755782] compositor: Segmentation fault

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=755782

George Kiagiadakis <gkiagia at tolabaki.gr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |gkiagia at tolabaki.gr
            Version|1.6.0                       |git master
         Resolution|INCOMPLETE                  |---

--- Comment #12 from George Kiagiadakis <gkiagia at tolabaki.gr> ---
I have seen this crash as well and after some debugging, I also know why it
happens. It is a race condition caused by a questionable mutex unlock in
gst_video_aggregator_src_setcaps() (which originates in the fix for bug
735042).

The case I have been debugging runs a complex live pipeline that involves a
compositor with 10 sink pads. It looks like this compositor starts immediately
after some of the sink pads are configured, so we run into a case where the
aggregate() function runs for the first time but with only 3 out of the 10 sink
pads being configured at the time.

* Since aggregate() is running for the first time, it proceeds to configure the
src pad, which runs set_info() for the 3 fully linked sink pads and sets their
conversion_info (in GstCompositorPad)

* Around the same time, another one of the sink pads (sink_1) is being sent a
CAPS event (on another thread). This calls
gst_video_aggregator_pad_sink_setcaps() and blocks on the video aggregator
mutex.

* During the src pad configuration process on the aggregate thread, at some
point execution reaches the GST_VIDEO_AGGREGATOR_UNLOCK() call in
gst_video_aggregator_src_setcaps() where the video aggregator mutex is being
temporarily unlocked

* The other thread that was blocked in gst_video_aggregator_pad_sink_setcaps()
now takes the lock and configures sink_1.

* Configuration of this sink pad completes, the lock is released and taken by
the aggregate thread again, while this thread continues and chains one buffer
on this sink pad.

* aggregate() now reaches the point where it tries to prepare the images from
the sink pads that are configured and have a buffer; this includes sink_1 at
this time, as it has managed to chain a buffer before execution of this thread
reached here!

* ... well, unfortunately, though, set_info() has not run for sink_1 so it has
no conversion_info and the code crashes as explained in the description above.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.