GNOME Bugzilla – Bug 759503
Stopping a stream very soon after starting asserts
Last modified: 2015-12-16 09:21:10 UTC
When I run the attached example code on my target hardware it asserts when the millisecond delay hits around 300ms. The original assert was intermittent and racey, so there's an additional change required to open up the race. In gstbaseparse.c: /* should have caps by now */ if (!gst_pad_has_current_caps (parse->srcpad)) goto no_caps; + /* Open up race.. */ + g_usleep (100000); if (G_UNLIKELY (!parse->priv->checked_media)) { /* have caps; check identity */ gst_base_parse_check_media (parse); } The resulting assert is identical to the one mentioned in bug 755123 comment 11. The summary of what appears to be happening is... Inside gst_base_parse_push_frame, it checks to see whether the srcpad has caps before carrying on. In our crash situation this test passes, but the caps have gone (because another thread has put the pad into FLUSHING mode) by further down the function when it calls gst_aac_parse_pre_push_frame. Although gst_pad_set_active appears to only set the pad to FLUSHING on return from gst_pad_activate_mode, pre_activate inside gst_pad_activate_mode has already set the pad to FLUSHING.
Created attachment 317434 [details] Example that provokes assert. It uses gstreamermm and boost, but is otherwise straightfoward
Where exactly do you get an assertion/crash?
The crashing thread:
+ Trace 235814
I guess aacparse (and others) will have to check if get_current_caps() returns NULL
I had originally been comparing with gstaacparse with gstmpegaudioparse but their behaviour was the same. I see that gsth264parse has better behaviour. I'll prepare a patch which addresses as many cases of the issue as I can.
Also reference bug 737186 is the case where this was fixed for H.264.
Created attachment 317450 [details] [review] Patch for plugins-bad
Created attachment 317451 [details] [review] Patch for plugins-good
Review of attachment 317450 [details] [review]: Again ... :/ Looks good.
Comment on attachment 317450 [details] [review] Patch for plugins-bad You were leaking all the tag lists in error cases, I fixed that before merging. commit 88d7beb921ac15893fa886647ebccf8931cccdbb Author: Dave Craig <davecraig@unbalancedaudio.com> Date: Tue Dec 15 17:10:00 2015 +0000 videoparsers: Check for NULL return value of gst_pad_get_current_caps() https://bugzilla.gnome.org/show_bug.cgi?id=759503
commit 328346ad210f1e64e147acac770024aa668b82e8 Author: Dave Craig <davecraig@unbalancedaudio.com> Date: Tue Dec 15 17:10:00 2015 +0000 audioparsers: Check for NULL return value of gst_pad_get_current_caps() https://bugzilla.gnome.org/show_bug.cgi?id=759503
(In reply to Sebastian Dröge (slomo) from comment #10) > Comment on attachment 317450 [details] [review] [review] > Patch for plugins-bad > > You were leaking all the tag lists in error cases, I fixed that before > merging. > Ah yes, did you fix the h264parser case too where I duplicated the fixes from?
(In reply to davecraig from comment #12) > (In reply to Sebastian Dröge (slomo) from comment #10) > > Comment on attachment 317450 [details] [review] [review] [review] > > Patch for plugins-bad > > > > You were leaking all the tag lists in error cases, I fixed that before > > merging. > > > Ah yes, did you fix the h264parser case too where I duplicated the fixes > from? Yes you did :-) Thanks!