[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