G_TYPE_CHECK_INSTANCE_TYPE Segfault

I’ve been trying to address this Pidgin crash:

GstDevice *device;
GstElement *result;
PurpleMediaElementType type;

device = g_object_get_data(G_OBJECT(info), "gst-device");
if (!device) {
	return NULL;
}

result = gst_device_create_element(device, NULL);

Originally the last line was causing the crash:

Thread 1 "pidgin" received signal SIGSEGV, Segmentation fault.
0x00007ffff7d6642a in gst_device_create_element () from /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0

So I concluded device potentially has garbage and so altered the check:

2137     device = g_object_get_data(G_OBJECT(info), "gst-device");
2138     if (!device ||
2139         !GST_IS_DEVICE(device)) {
2140         return NULL;
2141     }
2142
2143     result = gst_device_create_element(device, NULL);

However, the reporter still gets a crash, backtrace shows it is the GST_IS_DEVICE call:

#0  0x00007ffff6f94ee2 in gst_device_create_cb (info=info@entry=0x555555b9e1f0, media=media@entry=0x0, 
    session_id=session_id@entry=0x0, participant=participant@entry=0x0) at ../../libpurple/mediamanager.c:2139
#1  0x00007ffff6f950f1 in purple_media_element_info_call_create (info=0x555555b9e1f0, media=media@entry=0x0, 
    session_id=session_id@entry=0x0, participant=participant@entry=0x0) at ../../libpurple/mediamanager.c:2816
#2  0x00005555555fdc22 in create_test_element (type=type@entry=1025) at ../../pidgin/gtkprefs.c:2846
#3  0x00005555555fe267 in create_voice_pipeline () at ../../pidgin/gtkprefs.c:2869
#4  enable_voice_test () at ../../pidgin/gtkprefs.c:2966

Now, GST_IS_DEVICE is just a macro for GObject.TYPE_CHECK_INSTANCE_TYPE , why is that crashing?

You’re probably calling it on some memory which isn’t a GObject. The GObject runtime type checking can only be called on things which are GObjects, to distinguish one class instance from an instance of another class. It can’t distinguish GObjects from arbitrary heap or vice-versa, and it can crash when called on arbitrary memory, as it does some dereferences internally.

Most likely, the GstDevice has been finalised at some point, and the pointer in the gst-deviceobject data has been left dangling. Look for reference counting mismatches on that object.

1 Like

Yeah, it’s very likely a memory error.

1 Like