GNOME Bugzilla – Bug 150467
gnome-settings-daemon always crashing
Last modified: 2004-12-22 21:47:04 UTC
The g-s-d keeps crashing while trying to access the file /usr/share/applications/defaults.list which does not exist on my system. After creating an empty defaults.list it works. The bug occurs on mandrake cooker with the gnome2.7 rpms from Goetz Waschk as well as on my gentoo box with a current cvs build. Backtrace of g-s-d:
+ Trace 49435
Also on FC3 development packages.
I think it's really related to bug http://bugzilla.gnome.org/show_bug.cgi?id=117483 cd mkdir bakcup mv .gnome .gnome_private backup/ Get out of gnome COMPLETELY. If you don't know how reboot, for instance. You should be absolutely certain no process is going to be running in the background. At least that has worked for me.
I don't think it is related to #117483 because in my case it is not related to old files in .gnome or .gnome_private, it is not even related to any out-dated files in the user's home directory. I've created a new user account. Only file in his home directory is an .xinitrc to start gnome. :-) And g-s-d is still choking on it. :-( Also, I must admit that creating the /usr/share/applications/defaults.list does not cure all problems. I cannot change the default applications for a file in the nautilus file properties dialog. It crashes when clicking on an item in the application list. So, something else must be wrong. What really drives me mad is that for most of the users of the gnome2.7 rpms for Mandrake it seems to work without any problems. But there are a few others experiencing exactly the same problem as I do.
Well, I do think it is related, and I've got more data concerning it. It seems some process keeps creating ~/.gnome and more. I now have: [rms@roque ~]$ find .gnome .gnome .gnome/mime-info .gnome/gnome-vfs .gnome/gnome-vfs/.trash_entry_cache [rms@roque ~]$ rpm -qa gnome-vfs* gnome-vfs2-devel-2.7.91-1 gnome-vfs2-smb-2.7.91-1 gnome-vfs2-2.7.91-1 So who's writing it? Nautilus? Maybe, judging by the trash reference.
Marking with 2.8.0 milestone; sounds like something fishy is going on and it's stopping gnome booting at all.
Now "tentatively" 2.8.0 - comments on mailing lists suggest it may only be mandrake packages.
Fedora Core 3 (development) on my case, so it's not just Mandrake packages!
The original suggestion (which I somehow missed): # touch /usr/share/applications/defaults.list Does seem to solve it.
This seems like a gnome-vfs level fix.
Reassigning to the correct owner too. Please remember to do this every time a report is moved between products.
I don't have defaults.list and it's not crashing here at all. Also FC3. Did anyone try the latest gnome-vfs and control-center release?
Found the problem. It is the mimeinfo.cache file in /usr/share/applications created by running 'update-desktop-database'. After removing it, gnome-settings-daemon runs without crashing. Running u-d-d and restarting g-s-d, the crash is back. Tested with latest gnome-vfs and control-center. A stripped-down version only containing image/jpeg and image/png works fine. So, it must be one of the other entries which makes it crash. I'll try to figure out the bad entry.
Created attachment 31195 [details] mimeinfo.cache making g-s-d crash
The abiword.desktop file was causing the crash. It contains spaces in the MimeType list after the semicolons. MimeType=application/x-abiword; text/x-abiword; text/x-xml-abiword; text/plain; application/msword; Removing the spaces and running u-d-d makes g-s-d happy. :-)
I didn't manage to reproduce it even with artificially corrupted files. Could you try the attached test and tell me if it's reproduceable with it?
Created attachment 31219 [details] test program
After running your test program on mandrake, gentoo and fedora core rawhide, things are getting clearer now. To make a long story short: The problem are duplicate entries in mimeinfo.cache. The problem is triggered by a combination of two bugs: 1. If one desktop file defines 'MimeType=text/plain;' and a second one defines 'MimeType=application/x-abiword; text/plain;', the update-desktop-database tool creates two entries in mimeinfo.cache. One for 'text/plain' and another one for ' text/plain'. Actually, I'm not sure whether this is a bug or intended behaviour. 2. I guess gnome-vfs will ignore the space at the beginning of the line. So, we have two entries for text/plain! Which makes gnome-vfs go mad. Depending on the location and associated desktop file(s) of the duplicate entries, it either returns a wrong desktop file, complete rubbish or segfaults. Tests with the abiword.desktop file: Mandrake/Gentoo: olemke@defiant:mtest ./test-mime text/plain Desktop files associated with text/plain: gnumeric.desktop After shuffling the lines in mimeinfo.cache it returns ggv.desktop or others. FedoraCore Rawhide: [olemke@stargazer mtest]$ ./test-mime text/plain Desktop files associated with text/plain: ar_LB ar_KW.utf8 ar_KW.UTF-8 (no, this is NOT a copy'n'paste error :-) ) Afterwards I played a bit around with duplicating different entries and associating different desktop entries with them. In some cases it produced a segfault: [olemke@stargazer mtest]$ gdb ./test-mime (gdb) run application/x-tar Starting program: /home/olemke/mtest/test-mime application/x-tar [Thread debugging using libthread_db enabled] [New Thread -151074560 (LWP 6974)] Desktop files associated with application/x-tar: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -151074560 (LWP 6974)] 0x002952fa in strcmp () from /lib/tls/libc.so.6 (gdb) thread apply all bt
+ Trace 49857
Thread 1 (Thread -151074560 (LWP 6974))
This was on Fedora Core as I don't have debug-enabled compiles on gentoo and mandrake at the moment. If you can't reproduce it and/or need more info let me know. In that case I can recompile gnome-vfs and glib with debug info on my gentoo box and hopefully provide a more detailed backtrace.
Both gnome-settings-daemon and nautilus both crash-looping.. Here are the backtraces I got in case they are of use to anyone: - http://extremeboredom.net/Stuff/nautilus-crash1.txt - http://extremeboredom.net/Stuff/gsd-crash1.txt I tried running test-mime on a few things and it didn't crash, but text/plain was assoceated with eye of gnome for some reason, and x-directory/normal was assoceated with nothing, not sure if that's important or not. This is using the latest gnome ebuilds from breakmygentoo.net.
Ok, thanks for all the investigation Oliver. I finally managed to reproduce the crash in gnome-settings-daemon, here comes a patch which fixes it for me.
Created attachment 31231 [details] [review] double free fix
Yes, the patch fixed it. One issue remaining: gnome-vfs only uses the last entry of the duplicate mime type entries. If you have the following in mimeinfo.cache: text/plain=emacs.desktop text/plain=vim.desktop test-mime will only return vim.desktop instead of both. But I guess it's not up to gnome-vfs to deal with this. update-desktop-database has to be fixed upstream to not create those duplicate entries.
ok, gnome-vfs-2.7.92 did fix the GSD and Nautilus crashes for me (Gentoo, BMG) now there is one app still crashing: file-roller. Not sure whether this is related. though (backtrace does not mention gnome-vfs). I run a gentoo box and stuff is compiled without much debug info. running file-roler with gdb I get Starting program: /usr/bin/file-roller /opt/netapplet-ebuild.tar.bz2 warning: Unable to find dynamic linker breakpoint function. GDB will be unable to debug shared library initializers and track explicitly loaded dynamic code. Detaching after fork from child process 13016. Gtk-ERROR **: file gtksequence.c: line 1015 (_gtk_sequence_node_insert_sorted): assertion failed: (node_compare (new, closest, &info) <= 0) aborting... Program received signal SIGTRAP, Trace/breakpoint trap. 0x40c2244e in g_logv () from /usr/lib/libglib-2.0.so.0
jens: your stack trace is useless, and I don't really see why you thought reporting a file-roller crash here would be useful to us...
Can this bug be closed? I see this in the ChangeLog: 2004-09-04 Christophe Fergeau <teuf@gnome.org> * libgnomevfs/gnome-vfs-mime-info-cache.c: make sure we don't free memory we'll reuse later when managing the mime_info_cache_map hash table memory (fixes #150467)
Fixed in cvs. Closing.