GNOME Bugzilla – Bug 84273
Crash as login
Last modified: 2004-12-22 21:47:04 UTC
Package: nautilus Severity: normal Version: 1.1.19 Synopsis: Crash as login Bugzilla-Product: nautilus Bugzilla-Component: general BugBuddy-GnomeVersion: 2.0 (1.117.2) Description: Description of Problem: Not sure if this is the same known problem but here's another crash log of nautilus dying at login. Additional Information: Red Hat 7.3/Ximian Gnome 2 Snaps/nautilus2-1.1.19.0.200206050512-0.snap.ximian.1 Debugging Information: Backtrace was generated from '/usr/bin/nautilus' [New Thread 1024 (LWP 3116)] [New Thread 2049 (LWP 3121)] [New Thread 1026 (LWP 3122)] [New Thread 2051 (LWP 3123)] [New Thread 3076 (LWP 3124)] [New Thread 4101 (LWP 3125)] [New Thread 5126 (LWP 3126)] [New Thread 6151 (LWP 3127)] [New Thread 7176 (LWP 3128)] [New Thread 8201 (LWP 3129)] [New Thread 9226 (LWP 3130)] [New Thread 10251 (LWP 3131)] 0x420b4769 in wait4 () from /lib/i686/libc.so.6
+ Trace 23369
Thread 4 (Thread 2051 (LWP 3123))
------- Bug moved to this database by unknown@bugzilla.gnome.org 2002-06-05 15:26 ------- 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.
This trace terrifies me, guys, because there have been many changes in gnome-vfs and nautilus interaction lately. Can someone please investigate this ASAP? Thanks...
Another problem I see is that when Nautilus doesn't crash at login, it usually, I guess you'd say, hangs at login. I just logged in this morning and nautilus didn't crash but it has both CPUs pegged and none of the desktop has been drawn, no background or icons. If I killall -9 nautilus, that fixes the problem, i.e. a background is drawn, the icons appear, and a nautilus window of my home directory is opened.
After todays snapshot update, I logged out and in everything worked perfectly. So I tried it again, and it worked again. Version is nautilus2-1.1.19.0.200206060514-0.snap.ximian.1.
Marking as fixed, then. Please re-open it if you see the same problem again.
I logged in this morning, still running the nautilus2-1.1.19.0.200206060514-0.snap.ximian.1 snap and I had the same hang/both cpus pegged problem. We then had a nasty power outage and when I rebooted and logged in again, I had the same hang but without the CPUs being pegged.
I get the nautilus hang with the latest snaps. It's running: tjb 4165 1 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4170 4165 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4171 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4172 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4173 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4174 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4175 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4176 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4177 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4178 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4179 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4180 4170 0 09:38 ? 00:00:00 nautilus --sm-config-prefix /nautilus-y2Ksad/ --sm-client-id 1184b1f1640001022770984 tjb 4551 4527 0 09:39 pts/1 00:00:00 grep nautilus bit it's not drawing anything. It's not pegging the CPUs though. Version is nautilus2-1.1.19.0.200206061050-0.snap.ximian.1.
Can we please get a stack trace of all the threads?
I submitted another crash log here: http://bugzilla.gnome.org/show_bug.cgi?id=84736 I don't know if this is what you're looking for or not.
No, that looks like a different crash.
Created attachment 9169 [details] backtrace of hung nautilus process
I just attached a backtrace of a hung nautilus process. I upgraded to the latest snaps this morning (nautilus2-2.0.0.0.200206120511-0.snap.ximian.1), logged out, and logged back in and got the hang again. I opened a terminal, ran gdb, attached to the process, and got the back trace. Is there anything else I could do to help?
Attached below is the crash I got when I killed the above traced nautilus processes.
Created attachment 9170 [details] crash after killing the hung nautilus process
The stuff from this morning is bug 85033. Reopen this if tomorrow you're still seeing the other problems. *** This bug has been marked as a duplicate of 85033 ***
After updating to the nautilus2-2.0.0.0.200206121541-0.snap.ximian.1 snaps, logging out, rebooting my machine, and logging back in, nautilus doesn't start. It's not pegging both cpus but it doesn't start, the desktop is not drawn nor is the background. I'll attach a backtrace next.
Created attachment 9191 [details] backtrace of hang described in entry above
Just a follow up. After doing a 'killall nautilus', it starts up normally, the desktop and background are drawn.
Hi TJB, If you can repeat this, what would be _extremely_ useful, would be to type 'finish', 'finish' etc. until you hit the frame that is taking a long time to complete, so we can isolate what is going on there, and them print the contents of as many pointers as you can ;-)
I think I got what you want. The first 'finish' is the one that hung. It's all in the next attachment.
Created attachment 9221 [details] Backtrace of hung nautilus after a finish
Hi Tib, Well - sadly your trace is a different bug that looks extremely like memory corruption. Can you make sure _MALLOC_CHECK=2 is exported in your bashrc file so all apps get run with that, that will hopefully help debugging this. Sadly by the time bug-buddy fires up and attaches, 'finish' is no good - it's already locked the process so it won't continue. It'd be useful though if you can attach a gdb to a hung nautilus and trace what is happening, if you can repeat what you had before.
Created attachment 9296 [details] Backtrace of hung-at-login nautilus
The above attachment is a backtrace done after nautilus hung at login. I have _MALLOC_CHECK=2 set and I attached to the process. It's all there in the typescript. Nautilus is version nautilus2-2.0.0.0.200206150519-0.snap.ximian.1.
This trace is memory pool corruption - extremely difficult to track. Hopefully Alex can fix this with Valgrind. If you can [ it may not be feasible with your machine ], can you insert this into your invironment before nautilus is executed: export LD_PRELOAD=/usr/lib/libefence.so That should make nautilus segv where the corruption happens.
I made a simple script in ~bin to preload libefence for just nautilus but it doesn't work. Do I need to have it enabled for everthing? wintermute> nautilus Electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <bruce@perens.com> ElectricFence Exiting: mmap() failed: Cannot allocate memory wintermute> cat bin/nautilus #!/bin/sh export LD_PRELOAD=/usr/lib/libefence.so /usr/bin/nautilus wintermute>
It's possible that nautilus allocates too much memory for electic fence to be useable [ which sucks ]. Could you use valgrind instead ? You need to get Alex(l) to tell you how to get it to align memory correctly though. Alex ?
Created attachment 9444 [details] crash at startup backtrace
I just installed the 2.4.19-rc1 kernel. The first time I didn't actually boot the correct kernel, I then logged in, and nautilus crashed. The backtrace is the preceding attachment. I then fixed my grub.conf and rebooted again. This second time, nautilus hung (background yes, desktop icons no) and is currently pegging one cpu (it usually pegs both). Next attachment is a gdb attach to that process.
Forgot to mention: wintermute> rpm -qa | grep nautilus nautilus2-2.0.0.0.200206210447-0.snap.ximian.1 nautilus-gtkhtml-0.3.2.0.200206210447-0.snap.ximian.1 nautilus2-devel-2.0.0.0.200206210447-0.snap.ximian.1 wintermute>
Given the difficulty of reproduction, I'm punting this out to 2.0.2.
OK, if no one can reproduce, and we're not seeing it from anyone else, I'm going to close this. Sorry. :/
For what it's worth, here's some more interesting info. First some background. I've been testing the Gnome 2 snapshots on four different systems. At home I had a laptop and a dual CPU desktop and at work I have a single and a dual cpu system. The duals were my primary desktops and on both systems I got the same hangs with nautilus. The single CPU systems never had the problem. At home I recently upgraded my system to a single P4 from dual P3s. Everything else remained the same, i.e. I didn't reinstall the OS, didn't change the config files, etc. Nautilus has so far not hung one time. This morning I just updated to the latest snaps, logged out and logged back in and it was perfect. Got to work and did the same thing on the dual P3 system and nautilus hung again. I generally need to kill nautilus several times to get it to come up correctly on that system. So, it appears to me to be some SMP interaction that causes the problems. It seems to be the same thing with mini-commander but I need to double check to be sure. (On my SMP systems with the latest snaps, I can't have mini-commander in the doc because it hangs at startup, which hangs the whole panel).
Hi there; this sounds like a most interesting bug; but I have acute problems determining which of the umpteen attached stack traces is a current one. Please can you open a new bug, with a current stack trace of the lockup and CC me - I'm most interested in fixing this.
Since it's a hang, what exactly do you want me to do? In the past, what I did was log in, nautilus hangs, open a terminal, gdb attach to the nautilus process and then do a traceback. Is there something I could do that would be more helpful?
Sure; do exactly that - log in, open an xterm, gdb, attach; thread apply all bt and post the output in a new bug report that doesn't have umpteen confusing traces and various comments about fixedness etc. etc. I like 1 report with 1 stack trace per report - then I have some chance of tracking whether it's fixed or not. That'd be great :-) it sounds like some nasty gnome-vfs deadlock, and that needs fixing. Thanks.