Bug 107652 - nautilus segfaults when viewing images
Summary: nautilus segfaults when viewing images
Alias: None
Product: Fedora
Classification: Fedora
Component: nautilus (Show other bugs)
(Show other bugs)
Version: rawhide
Hardware: athlon Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
: 106413 109273 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2003-10-21 18:46 UTC by Elton Woo
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-09 10:39:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
traceback created with Bug Buddy after most recent crash (7.43 KB, text/plain)
2003-10-21 18:54 UTC, Elton Woo
no flags Details
traceback of most recent crash (5.18 KB, text/plain)
2003-10-22 16:15 UTC, Elton Woo
no flags Details
Today's (23 OCT) traceback of nautilus crash when viewing graphics (5.82 KB, text/plain)
2003-10-23 17:26 UTC, Elton Woo
no flags Details
xsession.errors after nautilus crashed when changing Preferences (6.43 KB, text/plain)
2003-10-23 17:28 UTC, Elton Woo
no flags Details
bug-buddy out put - 15:18 EST (3.32 KB, text/plain)
2003-10-24 19:17 UTC, Elton Woo
no flags Details
result of: gdb /usr/bin/nautilus 5252 (5.82 KB, text/plain)
2003-10-24 19:20 UTC, Elton Woo
no flags Details
Backtrace from a crash. (53.02 KB, text/plain)
2003-10-25 01:24 UTC, Kai Thomsen
no flags Details
nautilus crash when viewing graphics _after_ rawhide update to librsvg2-2.4.0-3 (6.02 KB, text/plain)
2003-10-26 01:34 UTC, Elton Woo
no flags Details
nautilus crash when viewing csv file with internal viewer (5.48 KB, text/plain)
2003-10-26 01:52 UTC, Elton Woo
no flags Details
traceback of crash caused by internally loading a plain text file (5.82 KB, text/plain)
2003-10-26 02:03 UTC, Elton Woo
no flags Details
ggv fails to remove its sidebar, after loading as internal viewer (65.91 KB, image/jpeg)
2003-10-27 20:07 UTC, Elton Woo
no flags Details
a more informative xsession.errors file created today (195.35 KB, text/plain)
2003-10-27 20:09 UTC, Elton Woo
no flags Details
backtrace as per comment #14 (14.20 KB, text/plain)
2003-10-28 19:27 UTC, Elton Woo
no flags Details
this is the best that I am able to do (following instructions *to the letter*). (3.31 KB, text/plain)
2003-10-30 19:02 UTC, Elton Woo
no flags Details
debug session done in failsafe mode as per requirements in comment #14 (8.78 KB, text/plain)
2003-11-01 07:08 UTC, Elton Woo
no flags Details

Description Elton Woo 2003-10-21 18:46:19 UTC
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):

How reproducible:

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

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

Since this involves the inernal viewer (gthumb) should this have been filed 
under "nautilus-media"?

Comment 1 Elton Woo 2003-10-21 18:51:06 UTC
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.

Comment 2 Elton Woo 2003-10-21 18:54:22 UTC
Created attachment 95355 [details]
traceback created with Bug Buddy after most recent crash

Comment 3 Elton Woo 2003-10-21 20:53:17 UTC
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

Comment 4 Alexander Larsson 2003-10-22 07:44:00 UTC
I can't reproduce this.
Can you please install these rpms and attach the backtrace again (it should have
more information):


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"?

Comment 5 Alexander Larsson 2003-10-22 10:26:12 UTC
*** Bug 106413 has been marked as a duplicate of this bug. ***

Comment 6 Elton Woo 2003-10-22 15:48:11 UTC
"view as image", so that should be "eog", NOT gthumb...

Comment 7 Elton Woo 2003-10-22 16:13:55 UTC
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.

Comment 8 Elton Woo 2003-10-22 16:15:36 UTC
Created attachment 95389 [details]
traceback of most recent crash

Comment 9 Alexander Larsson 2003-10-23 09:56:38 UTC
Hmmm, thats a different crash. I can't reproduce it either.
Can you try reproducing the first crash again?

Comment 10 Alexander Larsson 2003-10-23 10:00:01 UTC
Also, at least the second crash should have printed something. Can you see if
anything gets written to ~/.xsession-errors when this happens?

Comment 11 Elton Woo 2003-10-23 17:25:39 UTC
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

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.

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.

Comment 12 Elton Woo 2003-10-23 17:26:52 UTC
Created attachment 95435 [details]
Today's (23 OCT) traceback of nautilus crash when viewing graphics

Comment 13 Elton Woo 2003-10-23 17:28:12 UTC
Created attachment 95436 [details]
xsession.errors after nautilus crashed when changing Preferences

Same date as the traceback, but note the time difference.

Comment 14 Alexander Larsson 2003-10-24 09:40:54 UTC
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>
<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?

Comment 15 Elton Woo 2003-10-24 19:17:33 UTC
Created attachment 95465 [details]
bug-buddy out put - 15:18 EST

This crash now occurred simply by doing "open new window"!!!

Comment 16 Elton Woo 2003-10-24 19:20:10 UTC
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.

Comment 17 Elton Woo 2003-10-24 19:25:06 UTC
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
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! :-(

Comment 18 Elton Woo 2003-10-24 22:17:16 UTC
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 

Nautilus is now practically *unusable* due to the constant and consistent
crashing. [18h:18 EST]

Comment 19 Elton Woo 2003-10-24 22:19:15 UTC
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?

Comment 20 Kai Thomsen 2003-10-25 01:17:38 UTC
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.

kernel-2.4.22-1.2105.nptl (i686)

Comment 21 Kai Thomsen 2003-10-25 01:24:49 UTC
Created attachment 95472 [details]
Backtrace from a crash.

Comment 22 Elton Woo 2003-10-25 11:34:33 UTC
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.

Comment 23 Dr. Peter Boy 2003-10-25 14:42:10 UTC
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
(msg repeated 5 times)

see bug 107980

Comment 24 Elton Woo 2003-10-26 01:13:35 UTC
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.

Comment 25 Elton Woo 2003-10-26 01:32:45 UTC
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.

Comment 26 Elton Woo 2003-10-26 01:34:55 UTC
Created attachment 95482 [details]
nautilus crash when viewing graphics _after_ rawhide update to librsvg2-2.4.0-3

Comment 27 Elton Woo 2003-10-26 01:52:47 UTC
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

Comment 28 Elton Woo 2003-10-26 01:57:07 UTC
natilus also abends when viewing other files. This attachement is a result of a
crash when loading a csv file.

Comment 29 Elton Woo 2003-10-26 01:59:18 UTC
another crash was caused simply by internally viewing a *text* file....

Comment 30 Elton Woo 2003-10-26 02:03:36 UTC
Created attachment 95484 [details]
traceback of crash caused by internally loading a plain text file

Comment 31 Alexander Larsson 2003-10-27 11:52:42 UTC
Lots of comments, but i still need the output i asked for in comment #14,
especially the output of:
p *(GdkEventCrossing *)event

Comment 32 Elton Woo 2003-10-27 17:33:40 UTC
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


Comment 33 Elton Woo 2003-10-27 18:11:19 UTC
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.

Comment 34 Elton Woo 2003-10-27 18:15:46 UTC
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)?

Comment 35 Elton Woo 2003-10-27 19:11:24 UTC
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....

Comment 36 Elton Woo 2003-10-27 20:03:49 UTC
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.

Comment 37 Elton Woo 2003-10-27 20:07:11 UTC
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.

Comment 38 Elton Woo 2003-10-27 20:09:17 UTC
Created attachment 95531 [details]
a more informative xsession.errors file created today

Comment 39 Alexander Larsson 2003-10-28 09:22:06 UTC
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.

Comment 40 Elton Woo 2003-10-28 18:02:40 UTC
>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... :-(

Comment 41 Elton Woo 2003-10-28 19:26:38 UTC
I hope that I *finally* have this right.

Comment 42 Elton Woo 2003-10-28 19:27:16 UTC
Created attachment 95557 [details]
backtrace as per comment #14

Comment 43 Alexander Larsson 2003-10-29 08:41:13 UTC
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?

Can you install the gtk+ and glib debuginfo rpms (matching your normal packages
versions) from:

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

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.

Comment 44 Elton Woo 2003-10-29 14:58:13 UTC
>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"

Comment 45 Elton Woo 2003-10-30 16:59:17 UTC
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
[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.

Comment 46 Elton Woo 2003-10-30 17:23:54 UTC
*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). 

Comment 47 Kai Thomsen 2003-10-30 17:31:52 UTC
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 

Comment 48 Elton Woo 2003-10-30 18:09:32 UTC
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*>

Comment 49 Elton Woo 2003-10-30 18:21:21 UTC
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 ...  :-(

Comment 50 Elton Woo 2003-10-30 19:02:06 UTC
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.

Comment 51 Elton Woo 2003-10-31 04:53:34 UTC
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.

Comment 52 Alexander Larsson 2003-10-31 08:34:50 UTC
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.

Comment 53 Alexander Larsson 2003-10-31 08:44:12 UTC
Also, i meant gtk2-debuginfo and glib2-debuginfo.

Comment 54 Elton Woo 2003-11-01 03:51:31 UTC
>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.

Comment 55 Elton Woo 2003-11-01 04:20:32 UTC
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).

Comment 56 Elton Woo 2003-11-01 07:08:15 UTC
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
loaded in such a way as to partially block the failsafe window. I've done my
to ensure that I've faithfully copied the screen output and saved to this text
attachment. (I realise that time of the essence).

Comment 57 Elton Woo 2003-11-02 17:32:51 UTC
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.

Comment 58 Alexander Larsson 2003-11-07 14:23:01 UTC
*** Bug 109273 has been marked as a duplicate of this bug. ***

Comment 59 Alexander Larsson 2003-11-07 14:28:49 UTC
Elton, can you try to reproduce the view as images crash with this

Comment 60 Elton Woo 2003-11-08 06:19:08 UTC
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?

Comment 61 Alexander Larsson 2003-11-10 12:01:37 UTC
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...

Comment 62 Elton Woo 2003-11-10 18:05:44 UTC
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:


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.

Comment 63 Alexander Larsson 2003-11-11 08:36:30 UTC
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?

Comment 64 Elton Woo 2003-11-11 20:50:26 UTC
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.

Comment 65 Elton Woo 2003-12-30 19:04:56 UTC
I respectfully suggest closing this bug as the problem no longer
exists in Fedora Core Release 1 ("Yarrow")

Comment 66 Alexander Larsson 2004-07-02 13:10:31 UTC
test change - ignore

Comment 67 Dan Williams 2004-07-02 13:15:14 UTC

Note You need to log in before you can comment on or make changes to this bug.