GNOME Bugzilla – Bug 118151
Crash in new gst_debug code
Last modified: 2004-12-22 21:47:04 UTC
Found this crash in with Marlin, but the Marlin code hasn't changed since before the new GstDebug stuff landed. Basic scenerio is GstThread hits EOF, Marlin changes the state of this pipeline to GST_STATE_NULL and this happens. I had to set MALLOC_CHECK_ to 2 to see the crash, otherwise, the application continues and eventually gives an X ASync error and dies shortly afterwards. (gdb) bt
+ Trace 38970
The backtrace appears to be inconsistent, possibly indicating prior corruption. Does it work with debugging off? Did you recompile gstreamer, gst-plugins, and marlin from scratch after the debug update? (And could you do this again just to check.) Care to try it with electric fence or valgrind?
How do I turn off debugging? Everything was recompiled, but I shall try again. Tried it with EF, but it just sat there for ages. I'll give it another go too. Valgrind never works for me...
10 hours of running under EFence and GDB later (yes, it took that long to load a 500k mp3)... The crash doesn't occur. Running without EFence and GDB...occurs. -------------------------------------------- Recompiled GStreamer with --disable-gst_debug and the crash doesn't occur. Running like this also shows up how very very badly the new debugging stuff needs to be profiled, because it is slow.
This was a bug in the threading code, where the GstThread is assumed to still exist when it not necissarily does anymore while outputting the debug message. As for the new debugging being slower than the old: Yes, that's true, but I prefered a good debugging interface to a fast one. And there are multiple ways to make it faster: - compile it out via the configure switch --disable-gst-debug - use --gst-disable-debug with your application (saves a g_strdup_vprintf for every debugging statement) I did not however notice differences in CPU usage when testing mp3 decoding so I assume that might be a EFence or GDB issue. I'm closing this now.
Created attachment 18651 [details] [review] Suggested patch for gst_debug_logv()
How about changing gst_debug_logv() in the way suggested by the patch? It requires adding a function to LogFuncEntry.
Your patch is fine with me. I don't know how important that is though. I have done some oprofile profiling and optimized the debugging stuff quite a bit. Iain, you may want to change if his problem is still there.