GNOME Bugzilla – Bug 739312
gst_init segmentation fault
Last modified: 2016-03-16 17:45:29 UTC
gst_init is generating a segmentation fault when I attempt to incorporate gstreamer into a much larger application. It works fine if gst_init is used in a much smaller application. With GST_DEBUG=9 I get the following GST messages: 0:00:00.007413074 1381 0x2422600 INFO GST_INIT gst.c:499:init_pre: (null) 0:00:00.014728296 1381 0x2422600 INFO GST_INIT gst.c:500:init_p re: (null) 0:00:00.015514185 @0 1381 0x2422600 INFO GST_INIT gst.c:511:init_pre: (null) 0:00:00.031426148 1381 0x2422600 DEBUG GST_MEMORY gstallocator.c:5 85:_priv_gst_allocator_initialize: (null) Aborted As you can see instead of the normal debug messages after the routine name you see (null). It looks to me as if the memory associated with gstreamer has been corrupted in some manner so that even debug messages cannot display correctly. Has anybody seen something like this before? I'm stumped right now.
Have you tried running it in valgrind? Is it possible you might be calling gst_init() from multiple threads? (at the same time roughly)
I'm running this on an Arm 7 based system which doesn't have valgrind ported to it, so no I haven't tried running it in valgrind. I'll have to look into that. For testing purposes I'm calling gst_init at the very beginning of my program before anything else is done. So I'm not calling gst_init from multiple threads.
Ok. Which libc library are you using? (I'm just guessing at this point)
Looks like it's glibc 2.8. Does that make sense? It's a little hard to determine. That's pretty old since the latest glibc is 2.20. It came with the development environment.
That should be fine, just checking it's not dietlibc or somesuch. I don't know, I suppose you'll have to debug it then :) Do you have a stack trace with debugging symbols for the crash?
Unfortunately, I'm debugging an embedded system and gdb will not support debugging shared libraries so the instant my code enters gst_init my stack becomes invalid to the debugger. That means I can't get a valid stack trace when it crashes. gdb is reporting: warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. I'm looking around trying to find a solution to this so then I might be able to further debug my actual problem.
Could you check if any code is calling g_mem_set_vtable(), in which case you might be running into bug #701694.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!
I just ran into this bug with 1.6.3 on an x86 based box with glibc 2.19 and glib2 2.40.0: Program received signal SIGSEGV, Segmentation fault. 0xb7697cf0 in g_datalist_id_dup_data (datalist=datalist@entry=0x8295438, key_id=key_id@entry=233, dup_func=dup_func@entry=0x0, user_data=user_data@entry=0x0) at gdataset.c:864 864 gdataset.c: No such file or directory. (gdb) bt
+ Trace 236090
A breakpoint on g_mem_set_vtable() did not hit prior to this crash. I run into it 100% of the time when I use glibc's __malloc_hook/__free_hook/__realloc_hook to track memory allocations. Running it with valgrind (without using using these hooks) has not yielded any complaints.
Turns out my malloc hook did not guarantee 8 byte aligned pointers, which ended up causing this crash because the code in gdataset depends on this (using the lower bits of pointers for flags).