GNOME Bugzilla – Bug 794611
GStreamer-CRITICAL updating the plugin registry on windows due to ladspa
Last modified: 2018-04-11 00:31:01 UTC
(gst-launch-1.0:9756): GStreamer-CRITICAL **: gst_object_ref: assertion 'object != NULL' failed Not entirely sure yet why this happens; likely something in registry creation or loading? This does not cause any failures of course, but it confuses people who are using gstreamer on windows.
Created attachment 370044 [details] [review] ladspa: Fix critical during plugin load on Windows
Nicolas, can you please review this patch? I don't know if this is the expected behaviour :)
Review of attachment 370044 [details] [review]: While this patch looks correct, how does it fix a gst_object_ref() critical warning? That sounds like at least some check would be needed elsewhere too to not work with NULL objects.
Hmm, I wasn't paying enough attention while debugging this. I just set G_DEBUG=fatal-criticals and found this. This patch actually fixes this critical: (gst-launch-1.0:1436): GLib-CRITICAL **: g_string_insert_len: assertion 'len == 0 || val != NULL' failed I can't reproduce the other critical anymore. I am baffled. Maybe it was fixed between one of the dev releases and the final release?
Maybe it reappears again if you let it recreate the whole registry?
(In reply to Sebastian Dröge (slomo) from comment #5) > Maybe it reappears again if you let it recreate the whole registry? I did all my testing my deleting the registry and forcing a full rescan every time. I guess I'll push this and close the bug, and see if someone else reports it.
Yes, go ahead :)
(In reply to Nirbheek Chauhan from comment #0) > (gst-launch-1.0:9756): GStreamer-CRITICAL **: gst_object_ref: assertion > 'object != NULL' failed > Turns out this happens when you pass an invalid device to wasapisrc and we post an ELEMENT_ERROR in get_caps(), which calls gst_audio_base_src_post_message() and does gst_object_ref (src->ringbuffer) before the ringbuffer is allocated. The fix is in two parts: 1. Don't call ELEMENT_ERROR in get_caps() before the device is opened; just return the template caps in that case 2. Check that the ringbuffer is allocated before trying to ref it in gst_audio_base_src_post_message()
Created attachment 370683 [details] [review] audiobasesrc: posting errors should be always be safe Don't try to signal an error in the ringbuffer if it hasn't been allocated yet.
Created attachment 370684 [details] [review] wasapi: Don't open the device in get_caps() We can just return the template caps till the device is opened when going from READY -> PAUSED. This fixes a CRITICAL when calling ELEMENT_ERROR before the ringbuffer is allocated. Also fixes a couple of leaks in error conditions.
Comment on attachment 370683 [details] [review] audiobasesrc: posting errors should be always be safe Attachment 370683 [details] pushed as b569899 - audiobasesrc: posting errors should be always be safe
Attachment 370684 [details] pushed as 371a787 - wasapi: Don't open the device in get_caps()
*** Bug 795143 has been marked as a duplicate of this bug. ***