GNOME Bugzilla – Bug 660664
gnome-settings-daemon crashes due to some error in color profile loading
Last modified: 2012-02-01 11:52:06 UTC
Created attachment 197990 [details] debug log Just updated my Arch Linux packages to gnome 3.2.0 and found gtk+ being themeless. Right after that I stopped by #archlinux and together with arch's packager we found that to be due to a crash in gnome-settings-daemon. Here's a bt, partially filled with debug symbols: Program received signal SIGSEGV, Segmentation fault. 0xb4df05c2 in gcm_profile_store_process_child (profile_store=0x80dfd68, path=0x80e6ab0 "/home/dimka/.local/share/icc", info=0x808ea98) at gcm-profile-store.c:257 257 gcm-profile-store.c: No such file or directory. in gcm-profile-store.c (gdb) bt
+ Trace 228662
Also attached a log of 'gnome-settings-daemon --debug'. Also you might be interested in: [dimka@dimka-laptop dimka]$ ls /home/dimka/.local/share/icc edid-8b57b7903fbc1df048da48d18150cf9f.icc
Also affected by this issue. I got segment fault even when I removed all color profiles under ~/.local/share/icc
Confirming that - I also tried to "rm -rf ~/.local/share/icc", but on the next start of g-s-d it was recreated and it immediately crashed again :)
I just removed libcolor.so to disable the color plugin. This could be a workaround before the bug is actually fixed.
(In reply to comment #0) > Program received signal SIGSEGV, Segmentation fault. > 0xb4df05c2 in gcm_profile_store_process_child (profile_store=0x80dfd68, > path=0x80e6ab0 "/home/dimka/.local/share/icc", info=0x808ea98) > at gcm-profile-store.c:257 > 257 gcm-profile-store.c: No such file or directory. > in gcm-profile-store.c Hmm, I can see where the plugin crashes, but I can't understand why. Do you have a non-standard home directory, e.g. on NFS or symlinked somewhere else? I'll apply a fix to fix the crash of course, but I'm confused how it's processing subdirectories when the parent seems not to exist. The only way I could think you could get this is if /home/dimka/.local suddenly goes away.
I've applied the following to gnome-3-2 and master: commit 7fc50d98a84ccf004e184e85d10de0b8f9d57f88 Author: Richard Hughes <richard@hughsie.com> Date: Mon Oct 3 09:52:06 2011 +0100 color: Fix a crash if ~/.local is deleted at runtime Resolves https://bugzilla.gnome.org/show_bug.cgi?id=660664
(In reply to comment #4) > Hmm, I can see where the plugin crashes, but I can't understand why. Do you > have a non-standard home directory, e.g. on NFS or symlinked somewhere else? > > I'll apply a fix to fix the crash of course, but I'm confused how it's > processing subdirectories when the parent seems not to exist. The only way I > could think you could get this is if /home/dimka/.local suddenly goes away. Nope. Neither of these is true :) [dimka@dimka-laptop dimka]$ ls -ld /home/dimka drwx------ 75 dimka users 4096 03.10.2011 11:43 /home/dimka/ It's not on NFS for sure - local HDD. .local is always there and i'm able to reproduce this bug even after I do 'rm -rf ~/.local/share/icc'. And also without removing it... Some more info: drwxr-xr-x 3 dimka users 4096 05.05.2010 02:22 /home/dimka//.local// drwx------ 24 dimka users 4096 02.10.2011 15:37 /home/dimka//.local/share/ drwxr-xr-x 2 dimka dimka 4096 02.10.2011 03:50 /home/dimka//.local/share/icc/ This bug is still reproducable (i didn't obviously got an update yet), so if you interested you might instruct me on what to investigate and i'll do it :) But perhaps i'll be offline for one-two days...
Forgot to notice that ~/.local has a lot of other configs/directories so I never removed it completely - it is always there.
(In reply to comment #4) > (In reply to comment #0) > > Program received signal SIGSEGV, Segmentation fault. > > 0xb4df05c2 in gcm_profile_store_process_child (profile_store=0x80dfd68, > > path=0x80e6ab0 "/home/dimka/.local/share/icc", info=0x808ea98) > > at gcm-profile-store.c:257 > > 257 gcm-profile-store.c: No such file or directory. > > in gcm-profile-store.c > > Hmm, I can see where the plugin crashes, but I can't understand why. Do you > have a non-standard home directory, e.g. on NFS or symlinked somewhere else? > > I'll apply a fix to fix the crash of course, but I'm confused how it's > processing subdirectories when the parent seems not to exist. The only way I > could think you could get this is if /home/dimka/.local suddenly goes away. You can remove the patch, it won't work (store isn't NULL, it's 0x80dfd68). You need to make sure that you cancel each and every call to g_file_enumerator_next_files_async() when stopping the plugin, which I guess is the problem that happend (the color plugin wasn't getting cleaned up properly).
(In reply to comment #8) > You can remove the patch, it won't work (store isn't NULL, it's 0x80dfd68). I'm not checking store, I'm checking the result from gcm_profile_store_find_directory() > You need to make sure that you cancel each and every call to > g_file_enumerator_next_files_async() when stopping the plugin, which I guess is > the problem that happend (the color plugin wasn't getting cleaned up properly). Yup, that's probably a good idea too. I'll fix this now.
(In reply to comment #9) > Yup, that's probably a good idea too. I'll fix this now. commit 42fa1af884fda1590bc7af0f78e4fc70d0eb621b Author: Richard Hughes <richard@hughsie.com> Date: Mon Oct 3 11:34:04 2011 +0100 color: Cancel any in-progress directory searching on plugin unload
for arch users, here is a package for testing this changes. http://pkgbuild.com/~ioni/gnome-settings-daemon-3.2.0-2-i686.pkg.tar.xz http://pkgbuild.com/~ioni/gnome-settings-daemon-3.2.0-2-x86_64.pkg.tar.xz let us know if is working
I tested the (In reply to comment #11) > for arch users, here is a package for testing this changes. > > http://pkgbuild.com/~ioni/gnome-settings-daemon-3.2.0-2-i686.pkg.tar.xz > http://pkgbuild.com/~ioni/gnome-settings-daemon-3.2.0-2-x86_64.pkg.tar.xz > > let us know if is working I tested x86_64 and works like a charm. Thanks!
(In reply to comment #12) > I tested x86_64 and works like a charm. Great, thanks. Closing.