After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 660664 - gnome-settings-daemon crashes due to some error in color profile loading
gnome-settings-daemon crashes due to some error in color profile loading
Status: RESOLVED FIXED
Product: gnome-settings-daemon
Classification: Core
Component: color
3.2.x
Other Linux
: Normal normal
: ---
Assigned To: Richard Hughes
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2011-10-02 00:01 UTC by Dmitry Suzdalev
Modified: 2012-02-01 11:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
debug log (30.43 KB, text/x-log)
2011-10-02 00:01 UTC, Dmitry Suzdalev
Details

Description Dmitry Suzdalev 2011-10-02 00:01:08 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
  • #0 gcm_profile_store_process_child
    at gcm-profile-store.c line 257
  • #1 gcm_profile_store_next_files_cb
    at gcm-profile-store.c line 320
  • #2 ??
    from /usr/lib/libgio-2.0.so.0
  • #3 g_simple_async_result_complete
    from /usr/lib/libgio-2.0.so.0
  • #4 ??
    from /usr/lib/libgio-2.0.so.0
  • #5 ??
    from /usr/lib/libglib-2.0.so.0
  • #6 g_main_context_dispatch
    from /usr/lib/libglib-2.0.so.0
  • #7 ??
    from /usr/lib/libglib-2.0.so.0
  • #8 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #9 gtk_main
    from /usr/lib/libgtk-3.so.0
  • #10 main
    at main.c line 458

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
Comment 1 Sun Ning 2011-10-02 08:08:57 UTC
Also affected by this issue.

I got segment fault even when I removed all color profiles under ~/.local/share/icc
Comment 2 Dmitry Suzdalev 2011-10-02 08:10:47 UTC
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 :)
Comment 3 Sun Ning 2011-10-02 09:58:09 UTC
I just removed libcolor.so to disable the color plugin. This could be a workaround before the bug is actually fixed.
Comment 4 Richard Hughes 2011-10-03 08:51:47 UTC
(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.
Comment 5 Richard Hughes 2011-10-03 08:53:56 UTC
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
Comment 6 Dmitry Suzdalev 2011-10-03 09:02:13 UTC
(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...
Comment 7 Dmitry Suzdalev 2011-10-03 09:03:39 UTC
Forgot to notice that ~/.local has a lot of other configs/directories so I never removed it completely - it is always there.
Comment 8 Bastien Nocera 2011-10-03 10:08:08 UTC
(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).
Comment 9 Richard Hughes 2011-10-03 10:30:52 UTC
(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.
Comment 10 Richard Hughes 2011-10-03 10:40:42 UTC
(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
Comment 11 Ionut Biru 2011-10-03 17:14:59 UTC
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
Comment 12 Matjaž Črnko 2011-10-03 18:05:39 UTC
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!
Comment 13 Richard Hughes 2012-02-01 11:52:06 UTC
(In reply to comment #12)
> I tested x86_64 and works like a charm.

Great, thanks. Closing.