GNOME Bugzilla – Bug 727701
debugutils: Handle caps field values being NULL
Last modified: 2014-04-06 18:47:47 UTC
Yesterday I tried to call GST_DEBUG_BIN_TO_DOT_FILE() on a pipeline in my application. This caused a SIGSEGV due to a string-field in one of the caps being NULL. It could be argued that NULL-values are not permissible, but a program like the one below, neither fails nor crashes despite the dummy-field having a NULL value: caps = gst_caps_new_empty(); s = gst_structure_new ("video/x-raw", "dummy", G_TYPE_STRING, NULL, NULL); gst_caps_append_structure (caps, s); GST_ERROR ("%" GST_PTR_FORMAT, caps); str = gst_caps_to_string (caps); gst_caps_unref (caps); caps = NULL; caps = gst_caps_from_string (str); g_free (str); GST_ERROR ("%" GST_PTR_FORMAT, caps); gst_caps_unref (caps); So since this type of caps is allowed as input elsewhere in GStreamer my attached patch changes GST_DEBUG_BIN_TO_DOT_FILE() to not crash in strlen() on this type of input, but instead print the string "NULL".
Created attachment 273651 [details] [review] Proposed patch fixing GST_DEBUG_BIN_TO_DOT_FILE() to handle caps field values being NULL.
I would say that NULL string fields in caps are not valid, but I agree that the code should still handle it. The real question is: where did you come across this, which element created caps with a NULL string?! commit e1e5183181f17a4dd342a3b64210b109131f2ed6 Author: Sebastian Rasmussen <sebras@hotmail.com> Date: Sun Apr 6 11:23:34 2014 +0200 debugutils: Handle caps field values being NULL GST_DEBUG_BIN_TO_DOT_FILE() would cause a segfault whenever it encountered an element's caps that had a field value being NULL. Such fields are successfully handled e.g. by GST_*_OBJECT(), and with this patch so does GST_DEBUG_BIN_TO_DOT_FILE(). Even if string fields with a NULL value are not supposed to be valid in caps, such caps can be created. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=727701
(In reply to comment #2) > The real question is: where did you come across > this, which element created caps with a NULL string?! You need not worry -- in proprietary code that was buggy (the string field should of course not be NULL).