Bug 107652
versions: nautilus-media-0.3.1-1 gthumb-2.0.2-1 XFree86-4.3.0-40 kernel-2.4.22-1.2097.nptl (current default). This behavoir also noticed with previous kernel versions: 2096, 2098, 2093. nVidia drivers installed using "export CC=gcc32" Display resolution: 1024 x 768 x 24-bit. Created attachment 95355 [details]
traceback created with Bug Buddy after most recent crash
I can now confirm that it is NOT related to the nVidia drivers. I've reverted my XF86Config to use the "nv" drivers instead of "nvidia", and the problem is still reproducible. I can't reproduce this. Can you please install these rpms and attach the backtrace again (it should have more information): http://people.redhat.com/alexl/RPMS/nautilus-debuginfo-2.4.0-5.i386.rpm http://people.redhat.com/alexl/RPMS/eel2-debuginfo-2.4.0-1.i386.rpm Also, are you sure you're using the gthumb view and not the EOG one? Does the view menu say "View as Image" or "View with GThumb"? *** Bug 106413 has been marked as a duplicate of this bug. *** "view as image", so that should be "eog", NOT gthumb... I've installed the two *debuginfo packages as mentioned above. Though I've been noticing these crashes when viewing image files, it (nautilus) just crashed *twice* when I went to Edit-->Preferences--> Show Hidden and Backup files. Attaching debuginfo from most recent crash. Created attachment 95389 [details]
traceback of most recent crash
Hmmm, thats a different crash. I can't reproduce it either. Can you try reproducing the first crash again? Also, at least the second crash should have printed something. Can you see if anything gets written to ~/.xsession-errors when this happens? Last night, Nautilus was *constantly* crashing. I had the machine running all day and night. (Usually turn it off at night ... I'm wondering if this might have anything to do with heat build-up, since my CPU fan has been running a bit more noisly lately. I usually do a semi-annual cleanup of the internals, with this in mind.) Anyhow: I've had the machine off for several hours, and I've just turned it on. Within about 10 minutes, I was able to repeat the crash when viewing graphics files (it took a bit of playing around, but within another 5 minutes or so, we were off to the races. Crash. Restart. View *one* or a few images. Crash. Restart. In the second case, that of Nautilus crashing when changing the preferences, that took a bit longer, but eventually, I got it to crash (say, about 10 - 15 minutes playing around with the Preferences). WRT the image viewing the crash is much more frequent and 'predictable' (read: repeatable). The second type of crash (changing preferences) is a bit harder to repeat ... but it *can* me made to happen. I'm creating two new attachments (the *time stamp will show you which is the earlier one: i.e. image viewing). The second attachment is my xsession.errors which I copied _after_ I succeded in getting nautilus to crash with the "Preferences" issue. Created attachment 95435 [details]
Today's (23 OCT) traceback of nautilus crash when viewing graphics
Created attachment 95436 [details]
xsession.errors after nautilus crashed when changing Preferences
Same date as the traceback, but note the time difference.
I don't understand how event->window can be null in the eog crash. When it has crashed and the bug-buddy window is up, can you do: gdb /usr/bin/nautilus <pid-of-nautilus> bt <might have to press enter to show all of the backtrace here> frame 5 (or whatever number nautilus_icon_canvas_item_event has in the backtrace) p *(GdkEventCrossing *)event and attach the output? Created attachment 95465 [details]
bug-buddy out put - 15:18 EST
This crash now occurred simply by doing "open new window"!!!
Created attachment 95466 [details]
result of: gdb /usr/bin/nautilus 5252
Proc number is 5252, I don't know if I have done the procedure properly as
suggested, but I didn't want to lose this output, especially as I chose *not*
to create a core dump.
now nautilus crashed simply by "open new window". The two submitted attachements
are so you have something to 'sink your teeth into', since I didn't do the
procedure exactly as Alex described: I haven't found the frame number or the
line with nautilus_icon_canvas_item_event in either bug buddy or the rather long
output
of gdb /usr/bin/nautilus {proc number}.
... about to do another try. At least, these crashes are "reliable" in that I
know that they will occur *that* frequently! :-(
now the crashes are more frequent and worse, if anything. Selecting open a new window, or clicking on *any* object on the desktop (home, start here folders, etc.), and nautilus will *immediately* die with 10 to 12 segfaults (I've done this four times so far, and *counted* the error popups) before I can select logout from the panel menu. The desktop does not refresh or restore its icons, so I _must_ logout and back in. The only recent change to the system has been updating ftp://people.redhat.com/bfox/redhat-config-xfree86-0.9.15-1.noarch.rpm as per https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107790 Nautilus is now practically *unusable* due to the constant and consistent crashing. [18h:18 EST] Just a thought. Since nautilus now no longer reloads, I wonder if I should revert to the 'nv' drivers? ... I suspect my continued use of the 'nvidia' drivers *might* be muddying the waters WRT to tracking down this bug. Yes? No? Nautilus reliably segfaults on me, too, when I double-click on any desktop icon or try to open a new window via a menu. This happens even on a fresh user account. System is fully updated (Rawhide), no binary drivers are present. nautilus-2.4.0-5 kernel-2.4.22-1.2105.nptl (i686) Created attachment 95472 [details]
Backtrace from a crash.
The situation is now such that upon login to the desktop, my startup programs load: tkseti, kmail, licq. NONE of the desktop objects work. Clicking on "home", "Start here", or even a text file that I _saved to_ the desktop, *immediately* results in eleven (11) dialogs popping up one after another, informing me that process number(s) bla, bla, has segfaulted. Another item of note: the RHN icon in the panel blinks red, indicating that updates are avaialable. Clicking on it crashes the applet and I get one segfault popup. Immediately after, I run up2date from the console, and it tells me "the system is fully updated"?!! ... I'll have to come back to this later today, as I am about to represent my LUG at a provincial conference later this morning. Same here with an IBM IntelliStation SMP P III / Matrox dual head Xinerama. Instead of the segmentation fault message often there is no message but the following entry in .xsession-errors: nautilus: relocation error: /usr/lib/librsvg-2.so.2: undefined symbol:cr_doc_handler_new (msg repeated 5 times) see bug 107980 A member on the list directed me to bug 107875, and mentioned the problem as being with librsvg2. After tonight's updates from rawhide (including librsvg2-2.4.0-3) nautilus is now behaving normally. correction: "behaving normally", but still crashing when viewing graphics files. At least, when clicking on desktop objects, nautilus does not crash, and now it restarts itself after an abend caused when using the graphics view mode. Created attachment 95482 [details]
nautilus crash when viewing graphics _after_ rawhide update to librsvg2-2.4.0-3
Created attachment 95483 [details]
nautilus crash when viewing csv file with internal viewer
I am now discovering that the crashes are not only caused by viewing graphics
files, but also when calling another internal viewer
natilus also abends when viewing other files. This attachement is a result of a crash when loading a csv file. another crash was caused simply by internally viewing a *text* file.... Created attachment 95484 [details]
traceback of crash caused by internally loading a plain text file
Lots of comments, but i still need the output i asked for in comment #14, especially the output of: p *(GdkEventCrossing *)event Understood. I will try again. I feel that my intial attempt to follow procedure as outlined in Comment 14, was because I could not find any reference to "nautilus_icon_canvas_item_event" so I could not input the frame number. (*Yes* I did, and always have to hit enter because there is always more output). If I understand you correctly, I should do the command thus: gdb /usr/bin/nautilus [proc number] bt frame [frame number shown by nautilus_icon_canvas_item_event] p *(GdkEventCrossing *)event Try as I might, I am not finding any reference to nautilus_icon_canvas_item_event, so I am unable to find the frame number, and this *is* an important part of the command, right? ... just to be sure that I have not missed that line, I copied the entire output (including the several "enter" commands) and pasted into the gedit, then did a search for nautilus_icon_canvas_item_event. That entire string does not show up, if I select just one of the words in it. I tried the command without the "frame number" since I cannot find it, and now I
have a syntax error:
$ gdb /usr/bin/nautilus 5357 bt p *(GdkEventCrossing *)event
bash: syntax error near unexpected token `('
What am I doing wrong, now? ... or is the wildcard after the "p" a placeholder
for the same process number (5357)?
Alexander, please do not think I'm being "difficult" or "facetious". I am not a programmer, and I honestly can *not* figure out what is wrong with syntax. Awaiting your reply so I can try a traceback again.... nautilus-2.4.0-5 (current version) will load a poscript file, and internally display. However, it will either refuse to remove the ggv sidebar, and or crash when the back, forward, or up arrows are selected. Created attachment 95530 [details]
ggv fails to remove its sidebar, after loading as internal viewer
this is the only internal viewer, so far that will consistently load a file,
but will also consistently crash nautilus after viewing.
Created attachment 95531 [details]
a more informative xsession.errors file created today
Most of the commands are not to be entered on the command line. After the initial gdb command (gdb /usr/bin/nautilus [proc number]) you will get a gdb prompt where you can type the other command (each on its own line). Also, please stop attaching random things to this bug report. It just makes it impossible to read. Since every viewer crashes its clear that this is not a viewer issue, so you don't have to comment for each new viewer that you can crash. >you will get a gdb
>prompt where you can type the other command (each on its own line).
This is what I *didn't* understand. Now that it's clearer to me, I'll try again.
I am still unable to find the frame number. Put it this way:
Assume that I know *nothing* about command lines... I know it's usually difficult
for a programmer to descend to the newbie level, but as much as you think I may
know about linux, there are still many things (of which this is a good example),
where I *am* totally lost... :-(
I hope that I *finally* have this right. Created attachment 95557 [details] backtrace as per comment #14 Thats it. I still don't understand whats going on here though. It seems to reference a GdkWindow that somehow was freed already. I don't understand why so few other people see it though. Is your machine slow? fast? loaded? unloaded? swappy? Can you install the gtk+ and glib debuginfo rpms (matching your normal packages versions) from: http://ftp.redhat.com/pub/redhat/linux/rawhide/i386/debug/ Then start nautilus under the debugger. (I normally do this by first "kill -9 nautilus" repeatedly in the shell until it says "nautilus: no process killed" and then start gdb with "gdb nautilus") Then inside gdb (use a large terminal window for gdb), set a breakpoint at g_log ("break g_log") and start the app ("run"). This should start nautilus. Now try to reproduce the image crash. This time instead of crashing gdb should hit the breakpoint in g_log. So it'll say something like: Breakpoint 1, 0x004d8f43 in g_log () from /usr/lib/libglib-2.0.so.0 (gdb) Unfortunately there is another g_log call that seems to happen sometimes, so type "bt" and look at the backtrace (make sure you contine if you get a prompt). If it has bonobo_pbclient_get_value() or something like that below the g_log line, just type "cont" and keep trying to reproduce the bug. If it is the right place it'll look something like: #0 0x004d8f43 in g_log () .... #1 0x00445fe3 in gdk_window_set_cursor () from /usr/lib/libgdk-x11-2.0.so.0 #2 0x00dce408 in nautilus_icon_canvas_item_event (item=0x8baa638, ... Now go to the frame of nautilus_icon_canvas_item_event (probably nr 2): "frame 2" Then type these commands: p *(GdkEventCrossing *)event p item p *item p item->canvas p *item->canvas And send me the log of the whole gdb session. >Is your machine slow? fast? loaded? unloaded? swappy?
FWIW: The machine is not overclocked (AMD Athlon 1.0G)
System memory is 512 Mb, My startup programs are: tkseti, kmail, and licq ... and
*sometimes* limewire. At the moment of writing this, I have up2date installing
the latest from rawhide.
The system monitor gives me the following information:
Processor: 100%, memory 95%, swap space 0%, Load average 11%.
Could tkseti be the cuplrit?
The default invocation is: "./setiathome -email -nice 19"
To confirm:gtk+-debuginfo-1.2.10-28.1, gtk-engines-debuginfo-0.12-1,glib-debuginfo-1.2.10-11 are the packages installed on my system, and also the latest kernels and updates from rawhide (30 OCT - 11:h50 EST). I wanted to be sure that I had these updates in case that fixed the problem, hence th delay (my apologies). After rebooting the system, I started the procedure outlined in comment #43 above. Can I crash the window? Yes. OK. Next step, nautilus reloads, and from a console I get this: ]$ kill -9 nautilus bash: kill: nautilus: no such pid [abe@dhcp-133-74 abe]$ su root Password: [root@dhcp-133-74 abe]# kill -9 nautilus bash: kill: nautilus: no such pid [root@dhcp-133-74 abe]# This is most illogical, since there is at least *one* instance of nautilus loaded! Therefore, I will kill nautilus from the System Monitor, and restart the procedure. However, I feel that I shoul point out this illogical response from the system. *damn*!!! I can't get nautilus to close, and as a workaround, I tried the process in KDE (using a maximized console window), but of course I *don't* get any frame number with nautilus_icon_canvas_item_event, instead the only frame statement is nautilus-main, so even proceeding with the rest: Then type these commands: p *(GdkEventCrossing *)event p item, etc ... is totally useless. How do I proceed now? I can't kill nautilus from the console, and if I use the system monitor to kill (or more gently *close*) it, it restarts, so I'm stuck as regards invoking it in debug mode (per your instructions). I think Alexander meant to write "killall" (or "pkill", perhaps). The "kill" command expects a numeric process ID (PID), not a process name. If you want to prevent GNOME from respawning Nautilus, run "gnome-session-properties" or choose "Preferences" -> "More Preferences" -> "Sessions" from the GNOME main menu. On the "Current Session" tab, select Nautilus from the process list, change its "Style" to "Normal" and apply the settings. Ok. I go to Preferences, bla, bla, and save as "normal", then do "kilall -9 nautlius". I then get as far as "run" ---> crash proggie ---> Seg fault (so far so good), *except* nautilus now *freezes*, and I have to 'force quit' so I can't continue the debug session. To add salt to my wounds, Preferences resets nautilus to 'restart' so I have to go back again and set it to "normal". ...I'm starting to take this very personally (me and nautilus) ... to use a very common programmer's expression: "F****!!*, "F****!!*, "F****!!*, *grrrr.....*!! <*SIGH*> ... one more try ... <*sheesh*> Debug session: I get a viewer to crash, but now nautilus just freezes on screen and I have to force quit. In the console, I do a CTRL-C (break) to regain the debug session, and I get ten frame numbers, but I *don't* get any frame reference for nautilus_icon_canvas_item_event, which is the most important item that Alex wants to see in the debug session. So I exit with 'q' and 'y' to completely end the session. ... awaiting further instructions ... :-( Created attachment 95613 [details]
this is the best that I am able to do (following instructions *to the letter*).
The internal viewer (s) still crash(es), but Nautilus no longer
abends. Instead it either freezes on screen or I have to close it
in order to proceed with the debugging session. (Sorry, this is the
best that I can produce so far). I will close the machine, and attempt
the procedure again later today.
I am about to give up on this.Since it seems that I am the only one experiencing the problem, I guess it's just my hardware... I am attempting to do the procedure described in comment #14 _to the letter_. However, nautilus crashes / restarts at the "wrong time" during the debugging session. I wonder if I can do this by starting the system in runlevel 3? ... but then, I would still need to "startx" *first* before calling up nautilus, right? ... effectively, a "catch-22" situation. An easier way might be to start x without the whole desktop. Just log in with failsafe mode or start x with "X" (and then start a terminal and a window manager from the terminal, after setting DISPLAY to ":0.0". Without gnome-session running nautilus won't be respawning. Also, when running under gdb with the breakpoint set nautilus won't crash like normal. Instead it'll stop running (seemingly frozen) and the gdb prompt will appear. This is when you'll type the commands in gdb. Also, i meant gtk2-debuginfo and glib2-debuginfo. >under gdb with the breakpoint set nautilus won't crash like >normal. Instead it'll stop running (seemingly frozen) and the gdb >prompt will >appear. This is when you'll type the commands in gdb. At this point, the application (internal viewer) would crash, and I would then have to "force quit" nautilus. Obviously, I was doing it wrong at this stage. I will make a further attempt within the desktop, but if I still have problems with the Preferences being reset, I will start the system in runlevel 3 or in failsafe mode as you indicated... >meant gtk2-debuginfo and glib2-debuginfo. I suspected as much, but I didn't want to "second-guess" you and install unneeded stuff. Will get / install these libs right away, and re-run the debug session. One quick question: while running debug in a console on the desktop, I am able to save the session by using the mouse to copy the window contents and pasting into gedit. In failsafe or runlevel 3, how do I do I save the debugging session to a text file. (Regrettably, I have not learned the basics of vi). Created attachment 95643 [details] debug session done in failsafe mode as per requirements in comment #14 I was able to copy the screen output by loading gedit. Nautilus (and later gedit) loaded in such a way as to partially block the failsafe window. I've done my best to ensure that I've faithfully copied the screen output and saved to this text attachment. (I realise that time of the essence). One further comment: I am also able to reproduce the crash by opening nautlius,and changing (enabling *or* disabling) the following preference: "Show hidden and backup files". Nautilus will crash, save the preference setting and restart. ... hoping this will provide another pointer to the source of the problem. With the last updates from rawhide, the crashes take a bit longer to occur, but they still do, and are still as predictable, and with the same frequency. *** Bug 109273 has been marked as a duplicate of this bug. *** Elton, can you try to reproduce the view as images crash with this installed: http://people.redhat.com/alexl/RPMS/eel2-2.4.0-1.1eventcrash.i386.rpm It looks like it is fixed in Yarrow. I've done a clean install with the Fedora Core 1 release disks, and now nautilus doesn't crash. Before, the crashes were so consistent and frequent, that they were *almost* predictable. However, I noticed that with the last updates from rawhide this week, it would take a bit more "effort" (i.e. open an image or document a two or more times) in order to get the crash. I now have Yarrow installed, and I've already powered off the machine once. I have opened and viewed several images, and also a csv file (gnumeric). They all loaded with the respective internal viewers without even once causing nautilus to abend with the regularity it did. Perhaps this bug should now be marked as closed? No, its not fixed. bug 109273 is a dup, and its using the latest stuff, plus no code related to this problem changed at all. Its just that something changed when you reinstalled, so now you can't reproduce the bug easily anymore. This is sort of bad though, then we can't verify if the fix i made actually fixes the problem... Last night, nautilus did crash on me, but it was only a couple of times, and _nowhere near the frequency_ it did. This was after browsing through, and loading *several* ( > 20) image files. At one point, it immediately crashed when I used the "up" arrow to exit and then *delete* the directory. Since doing this 'clean' install of Yarrow, I have again installed xine, gxine, and totem. There were certain reqired libraries that did NOT come with Yarrow: aalib-1.4rc5-3.fr.i386.rpm alsa-lib-0.9.8-1.fr.i386.rpm flac-1.1.0-fr3.i386.rpm glut-3.7-12.i386.rpm libfame-0.9.0-fr2.i386.rpm speex-1.0.2-1.fr.i386.rpm xine-lib-1.0.0-0.2.rc1.fr.i386.rpm Of the above, I note that glut was deprecated as of RH 9 (Shrike). There must have been a reason for this. My suspicion is that this lib *might be* a contributory factor to the problem. Perhaps you could install it and see if it can help you reproduce the crashes more easily. glut, and all the other libraries you list here has zero influence on this problem. They are just a random bunch of bits on the disk. glut was deprecated due to license issues. Did you try if my updated eel fixes the problem for you? Understood. I am trying to 'trace back' if any "third party" multimedia libs that I had installed might have some bearing... so far the system is rock solid. Those two crashes that occured (since installing Yarrow) are apparently not reproducible ... due to their rarity. Actually, I *didn't* install the eel2-2.4.0-1.1eventcrash.i386.rpm, since I was installing Fedoraa Core Release 1. Subsequent to Comment #63, I have just installed it. I guess this would serve as a tool _in case_ the problem resurfaces. To date, this is no longer happening on my system. I respectfully suggest closing this bug as the problem no longer
exists in Fedora Core Release 1 ("Yarrow")
test change - ignore test |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031014 Description of problem: when one or two images are viewed with the internal viewer, nautilus crashes with a segmentation fault, then restarts. Version-Release number of selected component (if applicable): nautilus-2.4.0-5 How reproducible: Always Steps to Reproduce: 1. Open a Nautilus window with image files 2. View one, a few (as little as 3 images), or several images 3. Select "Up" while viewing Actual Results: Nautilus crashes with a segmentation fault. Expected Results: Nautilus should exit the image view mode, and revert to the directory. Additional info: Immediately after the crash, Nautilus will restart. Continued attempts to view image files will allow one or two images to be viewed, before the crash occurs. Since this involves the inernal viewer (gthumb) should this have been filed under "nautilus-media"?