[Gstreamer-bugs] [Bug 118151] Changed - Crash in new gst_debug code

bugzilla-daemon at widget.gnome.org bugzilla-daemon at widget.gnome.org
Sun Jul 27 06:13:09 PDT 2003


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=118151

Changed by in7y118 at public.uni-hamburg.de.

--- shadow/118151	Sat Jul 26 06:55:42 2003
+++ shadow/118151.tmp.16802	Sun Jul 27 09:13:09 2003
@@ -1,13 +1,13 @@
 Bug#: 118151
 Product: GStreamer
 Version: HEAD CVS
 OS: Linux
 OS Details: 
-Status: NEW   
-Resolution: 
+Status: RESOLVED   
+Resolution: FIXED
 Severity: normal
 Priority: Normal
 Component: gstreamer (core)
 AssignedTo: gstreamer-maint at bugzilla.gnome.org                            
 ReportedBy: bugs at prettypeople.org               
 QAContact: gstreamer-maint at bugzilla.gnome.org
@@ -82,6 +82,22 @@
 --------------------------------------------
 
 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.
 
+
+------- Additional Comments From in7y118 at public.uni-hamburg.de  2003-07-27 09:13 -------
+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.




More information about the Gstreamer-bugs mailing list