GNOME Bugzilla – Bug 75504
started up nautilus without gconf running and it blew up
Last modified: 2004-12-22 21:47:04 UTC
Package: nautilus Severity: critical Version: 1.1.10 Synopsis: started up nautilus without gconf running and it blew up Bugzilla-Product: nautilus Bugzilla-Component: Backgrounds Emblems and Themes BugBuddy-GnomeVersion: 2.0 (1.113.0) Description: Description of Problem: On login, gconf failed to run (because of another problem.) I got a load of 'an error occured while loading or saving configuration information' errors (apprently those are from libgnomeui) and thenthis segfault before the desktop was ever drawn. Debugging Information: Backtrace was generated from '/usr/bin/nautilus' [New Thread 1024 (LWP 6416)] [New Thread 2049 (LWP 6528)] [New Thread 1026 (LWP 6529)] [New Thread 2051 (LWP 6530)] [New Thread 3076 (LWP 6623)] [New Thread 4101 (LWP 6657)] [New Thread 5126 (LWP 6658)] 0x4094ee29 in __wait4 () from /lib/libc.so.6
+ Trace 19483
Thread 1 (Thread 1024 (LWP 6416))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-03-19 15:23 ------- Unknown version 1.1.x in product nautilus. Setting version to the default, "unspecified". Reassigning to the default owner of the component, nautilus-maint@bugzilla.gnome.org.
probably related to gconf bugs 75503 and 75511.
And #75523 looks like this as well.
*** Bug 79069 has been marked as a duplicate of this bug. ***
*** Bug 77202 has been marked as a duplicate of this bug. ***
Still seeing this one in 1.5.11, it looks like. And one basically identical trace from 1.0.4, so maybe this isn't gconf related.
From the 79069 trace it looks like XOpenDisplay is returning NULL, and calling XSetCloseDownMode() with a NULL display crashes. So could it be that GDK_DISPLAY () hasn't been created yet, which makes the XOpenDisplay fail? Maybe there is a race condition between loading the background image and GTK+ opening its display. I'm not familiar with Nautilus code yet, so this is just a guess.
I can't claim I understand why the XOpenDisplay would fail, but I added some checks for this that prints out a warning. So at least it should not crash anymore.
Yes, I was just about to send a patch to check for NULL. After reading the code a bit I don't think the race condition idea is very likely. gtk_init() is called very early on. Other ideas are: ran out of fds, or the display string is corrupted. If you look at bug #75511 there is a bit about fd leaks, so I'd guess that is the root problem.
Yeah, probably a dup. Marking as such and will reopen if we see new dups. *** This bug has been marked as a duplicate of 75511 ***
The fd leaks should be fixed, and really shouldn't affect a gconf client program like nautilus.
What seems to happen is that one of the underlying libraries (gnome-vfs or gconf or something) gets in a really bad state and uses up all file descriptors on the system. Orph has seen this, and managed to fix it by updating gnome-vfs, I think. So it may be a messed-up build issue, i.e. not likely to be seen in packages. Alex has fixed it so it doesn't crash Nautilus any more. I suppose we could try running Nautilus without gconf running and see if we can reproduce the problem.
Damon: gconf used to; michael and havoc fixed it. So if (1) that state isn't caused anymore and (2) alex fixed the nautilus end of the problem then we can close this.