|Summary:||Apparently spurious OOM conditions triggered by nautilus|
|Product:||[Fedora] Fedora||Reporter:||Tim Vismor <tvismor>|
|Component:||nautilus||Assignee:||Alexander Larsson <alexl>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-10-01 08:35:42 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Tim Vismor 2004-09-24 17:21:24 UTC
Given the nature of the problem, I hestitate to blame Nautilus. However, it is always present and active when the problem occurs. Details follow. I post this to Redhat bugzilla, rather than Gnome, since it is not clear to me that this behavior is not system dependent. System: Dell Precision Workstation 420 Details: 2 1Ghz Pentium III cpus, Adaptec AIC-7899P U160/m SCSI, 256MB memory, 753MB swap partition Operating System: Fedora Rawhide (updated as of 9/24/04) Kernel: 2.6.8-1.541smp Nautilus: 2.8.0 During the last few days I have received numerous OOM-Killer events under the following circumstances: a) Opening nautilus (in browser mode with tree view in left pane with "display directories only" enabled). b) Attempting to navigate into a folder with nautilus (under the same conditions). This behaviour has not occured while any other program is in the foreground and has input focus. Yesterday, (9/23) I switched to using Knonqueror for file management duties (while running Gnome) and no incidents occurred. After today's updates the problem still persisted and was easily reproduced (I don't have the patience to determine if it is "always reproducible"). I was able to produce an event as follows: a) Boot the system. b) Log in as root. c) Start the system monitor. d) Start nautilus (in browser mode with tree view in left pane with "display directories only" enabled). At this point the system monitor showed: Used memory: 141 out of 249 MB Used swap: 4.9 out of 753 MB e) Attempt to navigate to the "/etc" directory with nautilus. At this point, the system became unresponsive as the oom-killer started to run. See the first attachment. Once the process died out, I snapped a screen shot of the CPU/memory history. It is the second attachment. The appent discontinuity in memory usage occurred during the oom-killer episode. The system monitor did not update during this period. Note: Over time, I have run various flavors of Redhat linux on this machine (7.3, 8.0, 9.0, FC1, and FC2). I have only begun to see this problem recently.
Comment 1 Tim Vismor 2004-09-24 17:23:37 UTC
Created attachment 104276 [details] System log of the event
Comment 2 Tim Vismor 2004-09-24 17:24:53 UTC
Created attachment 104277 [details] System monitor recording of the event
Comment 3 Alexander Larsson 2004-09-28 09:31:05 UTC
Can you strace nautilus when this happens. Remove it from the session and kill it, then start it as "strace -o nautilus.log nautilus" and attach nautilus.log here.
Comment 4 Tim Vismor 2004-09-28 14:00:35 UTC
Created attachment 104437 [details] strace of nautilus during oom incident Per your request, I ran the nautilus browser under strace and generated a trace of an OOM incident. The script of the session was similar to the original bug report.
Comment 5 Alexander Larsson 2004-09-29 08:10:17 UTC
Hmm. It doesn't seem to allocate a lot of memory. Maybe one of the threads does it. Can you try "strace -o nautilus.log -tt -f nautilus" instead?
Comment 6 Alexander Larsson 2004-09-29 08:10:43 UTC
Also, could you try this not running as root?
Comment 7 Tim Vismor 2004-09-29 12:44:47 UTC
Created attachment 104503 [details] Output from strace -o nautilus3.log -tt -f nautilus --browser Attached is the output of strace with the additional arguments. This trace was run as root. The OOM triggering scenario was similar to the previous two events. FYI, terminal output was as follows: [root@redbud ~]# strace -o nautilus3.log -tt -f nautilus --browser PANIC: attached pid 4596 exited PANIC: handle_group_exit: 4596 leader 4595 [root@redbud ~]# The output occurred immediately after running strace, before any user interaction with nautilus. Will try this as a normal user now.
Comment 8 Tim Vismor 2004-09-29 13:14:23 UTC
Created attachment 104504 [details] strace output from normal user account This trace is from a user account with normal privileges. For what its worth, I looked at the system log associated with this OOM event and only nautilus was killed. Normally, daemons like named and httpd are shut down first. Terminal output was similar to the previous report: [tdv@redbud ~]$ strace -o nautilus.log -tt -f nautilus --browser PANIC: attached pid 5884 exited PANIC: handle_group_exit: 5884 leader 5848 [tdv@redbud ~]$
Comment 9 Tim Vismor 2004-09-29 13:27:58 UTC
Created attachment 104505 [details] Anomaly in tree view prior to previous OOM This may be the subject of another bug report or it may be relevant to the current discussion. When the nautilus browser started during previous OOM incident, the tree view in its left pane was "different". In particular, note (a) The samba share "Dogwood" is located above the local file system in the tree. It is normally, displayed beneath the "Filesystem". (b) The "Filesystem" icon does not a symbol for expanding its node in the tree. I have seen this problem sporadically with various versions of nautilus thoughout August and September. Note: The current OS is Rawhide as of 9/28/04.
Comment 10 Tim Vismor 2004-09-29 13:31:40 UTC
Created attachment 104506 [details] Previous screen shot as png. Sorry, I forgot to mark the tree view screen shot as a png and it was saved as text.
Comment 11 Alexander Larsson 2004-09-29 14:05:01 UTC
Its very strange. It doesn't look from the trace like nautilus is allocating a lot of memory. I have no idea why this is happening.
Comment 12 Tim Vismor 2004-09-29 17:40:00 UTC
Since I updated from Rawhide today (9/29/04), I have not encountered this problem. Looking over today's changes, it struck me that a bug (http://bugzilla.gnome.org/show_bug.cgi?id=153759) which was fixed in gnome-vfs may have been the culprit. Apparently, a bug in the desktop file parser could generate gigabyte memory allocations (by computing string length using inappropriate pointer arithemtic). Since desktop file parsing is now used for mime type determination (which is used for icon selection, etc), it seems to me that encountering some ill-formed (in the sense that it triggered the bug) desktop file could have caused the OOM condition. Just speculation.
Comment 13 Alexander Larsson 2004-10-01 08:35:42 UTC
Yes. That is likely the problem. I'll close this for now then. Reopen if you see it again.