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 768365 - shmsrc: gst_poll_remove_fd: assertion 'fd->fd >= 0' failed
shmsrc: gst_poll_remove_fd: assertion 'fd->fd >= 0' failed
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.8.0
Other Linux
: Normal normal
: 1.9.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-07-04 09:49 UTC by Marcin Lewandowski
Modified: 2016-07-04 10:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Do not call gst_poll_remove_fd upon stop if reading was never started (765 bytes, patch)
2016-07-04 10:20 UTC, Marcin Lewandowski
committed Details | Review

Description Marcin Lewandowski 2016-07-04 09:49:40 UTC
I am adding dynamically a branch to the audiomixer.

I have a custom bin class that basically contains shmsrc and capsfilter with src ghost pad made from capsfilter.

I create a bin, its constructor creates internal pipeline and then I add this bin to the parent bin and create appropriate pads on audiomixer and multiqueue that separates the two.

Then I call sync_state_with_parent on the branch bin, and if SHM socket is unavailable it returns false.

Then I invoke procedure to remove the branch bin which calls set_state(Gst.State.NULL)

Then GStreamer crashes with

gst_poll_remove_fd: assertion 'fd->fd >= 0' failed
Comment 1 Marcin Lewandowski 2016-07-04 09:55:59 UTC
For some reason I have trouble to catch detailed stack trace with function names on the machine I use but it seems to be caused by the SHM element:

 bt
* thread #1: tid = 0, 0x00007feeeaf14a6b libglib-2.0.so.0`g_logv + 683, name = 'lt-radiokit-plu', stop reason = signal SIGTRAP
  * frame #0: 0x00007feeeaf14a6b libglib-2.0.so.0`g_logv + 683
    frame #1: 0x00007feeeaf14bdf libglib-2.0.so.0`g_log + 143
    frame #2: 0x00007feeea6365da libgstreamer-1.0.so.0`gst_poll_remove_fd + 298
    frame #3: 0x00007feecbbf255c libgstshm.so
Comment 2 Tim-Philipp Müller 2016-07-04 10:13:56 UTC
Do you have a small test app to reproduce the problem by any chance?
Comment 3 Marcin Lewandowski 2016-07-04 10:20:29 UTC
Created attachment 330842 [details] [review]
Do not call gst_poll_remove_fd upon stop if reading was never started
Comment 4 Marcin Lewandowski 2016-07-04 10:21:53 UTC
I have taken a look at the code and I think the problem is obvious.

In gst_shm_src_start_reading if there was an error, self->pollfd.fd is never assigned, but in gst_shm_src_stop_reading gst_poll_remove_fd is called regardless of that.

Please take a look at my patch.
Comment 5 Sebastian Dröge (slomo) 2016-07-04 10:35:07 UTC
Comment on attachment 330842 [details] [review]
Do not call gst_poll_remove_fd upon stop if reading was never started

Makes sense, but did you check if the same/similar bug exists in shmsink? Please do :)
Comment 6 Marcin Lewandowski 2016-07-04 10:40:30 UTC
It seems that shmsink is fine.

It calls gst_poll_remove_fd only in the close_client block and jump to that block is always preceeded with stuff like gst_poll_fd_has_closed, gst_poll_fd_has_error or gst_poll_fd_can_read which operate on fd already allocated per client.
Comment 7 Sebastian Dröge (slomo) 2016-07-04 10:52:58 UTC
commit b2880cdd038ea39d0994998ca1f50dacaa071670
Author: Marcin Lewandowski <marcin@radiokit.org>
Date:   Mon Jul 4 12:19:36 2016 +0200

    shmsrc: Do not call gst_poll_remove_fd upon stop if reading was never started
    
    https://bugzilla.gnome.org/show_bug.cgi?id=768365