GNOME Bugzilla – Bug 538259
crash in Open Folder: bringing to foreground a...
Last modified: 2008-06-15 01:19:14 UTC
Version: 2.20.0 What were you doing when the application crashed? bringing to foreground a file window that had been open for some time. Distribution: Fedora release 8 (Werewolf) Gnome Release: 2.20.3 2008-01-08 (Red Hat, Inc) BugBuddy Version: 2.20.1 System: Linux 2.6.24.7-92.fc8 #1 SMP Wed May 7 16:50:09 EDT 2008 i686 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: Enforcing Accessibility: Disabled GTK+ Theme: Clearlooks Icon Theme: Clearlooks Memory status: size: 305979392 vsize: 305979392 resident: 174743552 share: 42016768 rss: 174743552 rss_rlim: 4294967295 CPU usage: start_time: 1212753813 rtime: 305172 utime: 275502 stime: 29670 cutime:2 cstime: 96 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/usr/bin/nautilus' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1209153776 (LWP 3020)] 0x00110402 in __kernel_vsyscall ()
+ Trace 200384
Thread 1 (Thread -1209153776 (LWP 3020))
----------- .xsession-errors (657662 sec old) --------------------- Selected video codec: [mpeg12] vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2)) ========================================================================== ========================================================================== Opening audio decoder: [mp3lib] MPEG layer-2, layer-3 AUDIO: 32000 Hz, 2 ch, s16le, 64.0 kbit/6.25% (ratio: 8000->128000) Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3) ========================================================================== AO: [alsa] 32000Hz 2ch s16le (2 bytes per sample) Starting playback... VDec: vo config request - 320 x 240 (preferred colorspace: Planar YV12) VDec: using Planar YV12 as output csp (no 0) Movie-Aspect is 1.33:1 - prescaling to correct movie aspect. VO: [xv] 320x240 => 320x240 Planar YV12 A: 0.2 V: 0.0 A-V: 0.187 ct: 0.000 1/ 1 ??% ??% ??,?% 0 0 A: 0.2 V: 0.2 A-V: 0.070 ct: 0.003 2/ 2 ??% ??% ??,?% 0 0 A: 0.3 V: 0.2 A-V: 0.070 ct: 0.0 ...Too much output, ignoring rest... --------------------------------------------------
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 510468 ***
Created attachment 112758 [details] yum updates log of what packages have changed since reboot. More info in case it is useful. $ uptime 10:12:44 up 8 days, 12:11, 9 users, load average: 0.68, 0.48, 0.41 $ free total used free shared buffers cached Mem: 1555052 1497816 57236 0 193868 586900 -/+ buffers/cache: 717048 838004 Swap: 1048568 524116 524452 Linux davidtdesktop 2.6.24.7-92.fc8 #1 SMP Wed May 7 16:50:09 EDT 2008 i686 athlon i386 GNU/Linux {Fedora 8} 4x workspaces open: 1: 4x gnome-terminal thunderbird 2x firefox {x10 tabs] 7x nautilus {configured as default list view, places sidebar}. fslint {scanning for empty dirs within /home} baobab {finding large space used in /home} 2: firefox {8x tabs} gedit {3x tabs} 3x gnome terminals 3: xmms {1500 song playlist, not playing} 4: 2x evince gnome-terminal oocalc {small spreadsheet} 8x nautilus The nautilus are getting opened via baobab open folder capability. The day of the crash, was the first time that I had used nautilus in tree view mode for some years. The machine hasn't been rebooted since a kernel and other updates were installed {see attach}. It also hasn't been logged out. Some nautilus windows have been running for a week.
One other thing noted was in the lead up to the crash, Nautilus window folder changes {ie changing the viewed folder} was occurring very slowly, eg 1.5-2.5secs to load a file list of just a few files. This is why I tried turning on tree view, since it allowed me to expand relevant parts of the tree without having to wait. I was using baobab to find large disk space uses, opening in nautilus, and then moving files/folders from that folder to other nautilus windows that are already open. After the crash {which only stopped one or two file windows}, the normal 0.5s responses to folder changes has returned.