GNOME Bugzilla – Bug 74189
nautilus crash on startup [get_info_callback]
Last modified: 2004-12-22 21:47:04 UTC
Package: nautilus Severity: normal Version: 1.1.8 Synopsis: Crash on startup Bugzilla-Product: nautilus Bugzilla-Component: general BugBuddy-GnomeVersion: 2.0 (1.112.1) Description: Description of Problem: Nautilus crashes most times when starting new Gnome2 X session. After the crash, it respawns successfully. This is CVS everything as of about 10 March 2002 I have noticed it for the past few days. This appears on stderr: nautilus (pid:1989): ** ERROR **: file nautilus-directory-async.c: line 2643 (get_info_callback): assertion failed: (handle == NULL || handle == directory->details->get_info_in_progress) Additional Information: Have also noticed that Nautilus sometimes tries to open a nautilus window when starting new Gnome2 session even though I closed all nautilus windows at end of last session. Debugging Information: [New Thread 1024 (LWP 1989)] [New Thread 2049 (LWP 1996)] [New Thread 1026 (LWP 1997)] [New Thread 2051 (LWP 1998)] [New Thread 3076 (LWP 2007)] 0x40a906e9 in wait4 () from /lib/libc.so.6
+ Trace 18955
Thread 1 (Thread 1024 (LWP 1989))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-03-10 20:51 ------- 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.
Additional info, sometimes instead of gnome-segv catching the bug, I get this instead: The program 'nautilus' received an X Window System error. This probably reflects a bug in the program. The error was 'BadPixmap (invalid Pixmap parameter)'. (Details: serial 4585 error_code 4 request_code 2 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.)
Created attachment 7097 [details] screenshot to show possible session problem
Note the attchment above. Nautilus is in there twice which doesn't look right to me. In fact, if I remove the second session (using the capplet) then quit session, then restart session, everything comes up as expected. So maybe this is a session related problem?
*** Bug 75105 has been marked as a duplicate of this bug. ***
Marking this confirmed, since it has a duplicate.
Darin: is this bug 71149? Greg: this might be the result of a mismatched nautilus and gnome-vfs build, according to the other bug. Can you try rebuilding both with most recent from CVS and seeing if that works?
I'm closing this bug now as my recent builds don't display the problem.
*** Bug 81194 has been marked as a duplicate of this bug. ***
Reopening :/
Jacob, can you take a look at this?
Ok - so I can see how this could happen, possibly in this circumstance: g_idle_add as used in job_oneway_notify is assumed to be thread safe by gnome-vfs, indeed this locking is pretty vital to avoid nasty memory trashing corruption. I'm guessing then that this problem only occurs for people who compiled glib themselves, and (presumably) ommitted the --with-threads=posix, or somesuch.
sigh, what rubbish I talk, of course g_thread_supported would fail in this case, it's not the problem - unless the g_idle_add locking is busted. It's prolly something more banal.
It would be _extremely_ helpful to be able to see the contents of: #12 $ p *(NautilusDirectory *)callback_data $ p *$1.details It's possible that the object has been finalized, it's pretty much all I can think of.
*** Bug 83596 has been marked as a duplicate of this bug. ***
*** Bug 84402 has been marked as a duplicate of this bug. ***
Twanger: can you still reproduce this? Can you also take a look at Michael's comment if you can?
*** Bug 84910 has been marked as a duplicate of this bug. ***
I can't remember having this crasher.
Markus: you submitted it as bug 84402; it had the same stack trace though you reached it differently.
*** Bug 85313 has been marked as a duplicate of this bug. ***
If anoncvs wasn't so fscked up, i'd bring my gnome2 up-to-date and tried reproducing. :( cvs -z3 update -dP -A cvs server: Updating . cvs server: failed to create lock directory for `/cvs/gnome/gtk-doc' (/cvs/gnome/gtk-doc/#cvs.lock): Permission denied cvs server: failed to obtain dir lock in repository `/cvs/gnome/gtk-doc' cvs [server aborted]: read lock failed - giving up which modules need updating for the re-check to make sense?
The crash still occurs. The first bugbuddy report I get is another backtrace, though, which I filed as bug 85448. After that, when nautilus is restarted, I get this crash several times. I tried to get that backtrace in gdb to help Michael, didn't work. I only get SIG32s. Another difference to other crashes is, that the gnome-segv dialogbox says ".. has crashed due to a fatal error (Trace/breakpoint trap)", not ".. has crashed due to a fatal error (Segmentation Fault)".
could this be Damon's gnome-vfs fix in a different guise ?
I wouldn't think so, though I'm not sure. My bug was about bad file monitors, but here it looks like we have a bad GnomeVFSAsyncHandle: get_info_callback (handle=0x1 Other that that, I have no idea.
*** Bug 86071 has been marked as a duplicate of this bug. ***
Actually a GnomeVFSAsyncHandle is a GUINT_TO_POINTER, so 0x1 could be valid. Quite a few of the traces have a handle of 1 or 2, though bug 85313 has handle=0x400d9e95. Most crashes happen on startup, though bug 84402 doesn't. I can reproduce 84910 up to the hang, but it doesn't SEGV.
gnome_vfs_async_job_cancel_job_and_callbacks() doesn't set the job's cancelled flag to TRUE if async_job_callback_map == NULL. It just returns. So if a job is cancelled before any callbacks have been registered at all, then it isn't marked as cancelled. I can reproduce by adding sleep(5) to job_oneway_notify() to delay adding callbacks. I'll attach a patch in a sec.
Created attachment 9451 [details] [review] Patch to fix it
The patch looks good Damon, thanks for looking at this. As long as you've tested basic GnomeVFS clients to make sure they still run and are basically ok (say, Nautilus, I really don't think this would break them, but better to be safe than sorry), go ahead and checkin to HEAD and the gnome-vfs-2-0 branch.
Patch applied to head and gnome-2-0 branch.
*** Bug 86556 has been marked as a duplicate of this bug. ***
*** Bug 87044 has been marked as a duplicate of this bug. ***
*** Bug 87493 has been marked as a duplicate of this bug. ***
*** Bug 88137 has been marked as a duplicate of this bug. ***
*** Bug 90025 has been marked as a duplicate of this bug. ***