GNOME Bugzilla – Bug 580579
crash in Volume Control: aucunes idées désolé.
Last modified: 2009-05-22 20:17:07 UTC
What were you doing when the application crashed? aucunes idées désolé. Distribution: Debian 5.0 Gnome Release: 2.22.3 2008-09-18 (Debian) BugBuddy Version: 2.22.0 System: Linux 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686 X Vendor: The X.Org Foundation X Vendor Release: 10402000 Selinux: No Accessibility: Disabled GTK+ Theme: SphereCrystal Icon Theme: Amaranth Memory status: size: 29548544 vsize: 29548544 resident: 6983680 share: 3166208 rss: 6983680 rss_rlim: 4294967295 CPU usage: start_time: 1240915975 rtime: 0 utime: 0 stime: 0 cutime:0 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/lib/bug-buddy/mixer_applet2' [Thread debugging using libthread_db enabled] [New Thread 0xb6c89700 (LWP 4305)] 0xb7f50424 in __kernel_vsyscall ()
+ Trace 214886
Thread 1 (Thread 0xb6c89700 (LWP 4305))
*** Bug 580580 has been marked as a duplicate of this bug. ***
The crash occurs in the gstreamer library. I'm fairly confident that there is nothing that the applet code is doing that could cause the failure (we call it with gst_init (NULL, NULL);), therefore I'm punting the bug over to the gstreamer folks. The crash appears to be in the post-error cleanup code of gst_registry_binary_write_cache which hints that there might be something wrong with your gstreamer cache or the writability of the disk its on (the file name starts with /net, is it on a network drive of some description?). I admit I'm guessing though, I'm not that familiar with the gstreamer code.
Can we get a stack trace of a recent gstreamer? git head has a comment at that line: gst_registry_binary_write_cache (registry=0x91a22f0, location=0x91b53d0 "/net/etd1/bocastag/.gstreamer-0.10/registry.i486.bin") at gstregistrybinary.c:706 Ideally also add a log for GST_DEBUG="*REGISTRY*:5" gst-inspect
For gstreamers of about the time of the GNOME release used (e.g. 0.10.20) line 706 is: GstBinaryChunk *cur = walk->data; near the start of the fail_free_list error handling goto in gst_registry_binary_write_cache (). walk is set on the following line to to_write, which in turn is set by gst_registry_binary_save_plugin (). That is about the place where my understanding of the code stopped so I didn't investigate further.
commit 158895f56b200db93cc46bc56793de09ec1b1cb0 Author: Stefan Kost <ensonic@users.sf.net> Date: Fri May 22 23:14:41 2009 +0300 registry: don't free node-date and deref again. Fixes #580579 When writing a cache chunk fails, we were freeing the node and jump to a final cleanup which dereferenced a null pointer. Leve freeing the node to the cleanup code in fail_free_list.