Red Hat Bugzilla – Bug 57698
Nautilus binary becomes corrupt
Last modified: 2007-04-18 12:38:47 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98) Description of problem: nautilus gives a segmentation fault allmost every time it starts. Gnome is not working fine due to that. It works fine on a intel-II machine and not working on a intel-III-machine Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.start up gnome or start nautilus 2. 3. Actual Results: On startup of gnome : nothing, desktop icons are not arpearing on startup out of a terminal : segmentation fault Expected Results: a working system Additional info: system is running kernel 2.4.9-13 the same kind of problems, but less frequent, appeared on the 7.1- distribution on the same machine There has NOT been a upgrade, there was a fresh install of 7.2, followed by a kernel upgrade. It can be observed that the spash-screen takes a very long time to disapear. The following output is made in a terminal window after the icon's did not appear. [root@tst1 root]# nautilus Segmentation fault [root@tst1 root]# nautilus-clean.sh nautilus-clean: No stale processes found. [root@tst1 root]# oaf-slay [root@tst1 root]# killall -9 nautilus nautilus: no process killed [root@tst1 root]# gdb nautilus GNU gdb Red Hat Linux (5.1-1) Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux"... (no debugging symbols found)... (gdb) run Starting program: /usr/bin/nautilus [New Thread 1024 (LWP 2479)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 2479)] 0x40278984 in __do_global_ctors_aux () from /usr/lib/libnautilus- private.so.0 (gdb) bt #0 0x40278984 in __do_global_ctors_aux () from /usr/lib/libnautilus-private.so.0 #1 0x4020fcb6 in _init () from /usr/lib/libnautilus-private.so.0 #2 0x4000da97 in _dl_init (main_map=0x40016c00, argc=1, argv=0xbffffa64, env=0xbffffa6c) at dl-init.c:70 (gdb)
When you say "kernel upgrade" you mean to our errata right? When you say the same happened in 7.1 what do you mean - Nautilus wasn't in 7.1?
On 7.1 the startup of gnome did not work allways. Sometimes the panel did crash. Now the panel is allways starting, but the desktop isn't. the upgrade of kernel is done via the kernel 2.4.9-13-prm on the redhat errata- pages
I have no preliminary idea what's going on here.
I have a similar problem on Dell Inspiron 8000. Generally I have a segmentation fault of nautilus at startup. But I noted that often the nautilus binary is changed (/usr/bin/nautilus) so the workaround is to reinstall the rpm. The behaviour changes everytime, like if nautilus, when it can run, modifies only a part of its files.
I do confirm that behaviour Sergio described... :-(( I run RH 7.2 on a Compaq Armada M700 (PIII) laptop. Nautilus 's binary in /usr/bin/nautilus is corrupted after a user login. Consequently the splash screen is lasting much longer than usually and Nautilus is not launched (of course). The fallback solution is to copy again the binary file from a temporary place, but each time you boot on, you have to do that. Very bad...
AFAIK if the Nautilus binary is munged, this has to be a kernel or hardware problem. Nautilus does not have write permission to /usr/bin/nautilus. I have no idea however why the nautilus binary would get mangled but not other files on your disk.
These problems sound very much like data corruption, yes: it could be corruption in memory or on the ide bus. rpm checksums all files in all packages using reliable md5 signatures, and you can check any installed package for corruption with "rpm -V". I'd suggest that the first step to diagnosing the corruptions here would be to run rpm -V on various packages: "rpm -Va" will verify all packages on the system (but beware that it will warn about changes which may be legitimate, including config file changes, so dont' assume that absolutely all warnings are fatal.) If rpm -Va produces different results from one run to the next, it's a pretty good indicator that we're getting ide bus corruption. Booting with the "ide=nodma" kernel option is often enough to work around problems with some ide controllers.
I am doing futher investigations, waiting the next file modification. But I forgot to tell that when the file is changed also the date is updated. [sergiop@gart bin]$ ls -l nautilus.* -rwxr-xr-x 1 root root 537868 Feb 4 23:08 nautilus.old -rwxr-xr-x 1 root root 537868 Feb 6 08:50 nautilus.old2 [sergiop@gart bin]$ ls -l nautilus -rwxr-xr-x 1 root root 537868 Sep 7 02:03 nautilus The date are not random, reflect real use of the system. For my knowledge, in this case who changes the file understand also the filesystem; I suppose that it is not a low level driver.
If a file is being modified that way then it's not likely to be a kernel fault, but an application. What is the difference between the different copies of the files, and what does rpm -V show?
After two weeks of testing, the impression is that problem is with ide dma. Premise: with past redhat installation (7.0) for a problem with X windows I often had not clear umount, so generally I do not care about failed fsck, and I understimate some other problems. Generally the problem is with nautilus binary, sometimes it is corruped only in memory; sometimes the date of the file changes, other times not. Some files disappared, preferred directoris are in /usr/share. [root@dylan root]# diff rpmV8-2.txt rpmV24-2.txt 3a4,12 > .M...UG. /usr/share/pixmaps/calculator-font.png > .M.D.UG. /usr/share/pixmaps/gnome-default-dlg.png > .M.D.UG. /usr/share/pixmaps/gnome-error.png > SM?..UGT /usr/share/pixmaps/gnome-info.png > .M.D.UG. /usr/share/pixmaps/gnome-question.png > .M.D.UG. /usr/share/pixmaps/gnome-warning.png > missing /usr/share/pixmaps/no.xpm > missing /usr/share/pixmaps/yes.xpm > missing /usr/share/pixmaps/gftp.png 286a296,298 > missing /usr/share/pixmaps/dia-diagram.png > missing /usr/share/pixmaps/dia_gnome_icon.png > ..5..... /usr/bin/panel 507,508c519 < .....U.. /dev/tty1 < .M....G. /dev/tty2 --- > .....U.. /dev/tty2 587a599,625 > missing /etc/X11/sysconfig/serviceconf.desktop > missing /usr/share/pixmaps/serviceconf.xpm > missing /usr/share/pixmaps/gnome-calendar-conduit.png > missing /usr/share/pixmaps/gnome-gnomecard.png > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/basic.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/basic.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/bindings.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/bindings.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/inline.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/inline.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/lap.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/lap.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/modules.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/modules.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/no-lang.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/no-lang.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/rep.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/rep.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/scheme.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/scheme.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/src.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/src.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/unscheme.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/unscheme.jlc > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/utils.jl > missing /usr/share/rep/0.13.6/lisp/rep/vm/compiler/utils.jlc 653a692 > missing /usr/share/pixmaps/kontrol-panel.png 1749a1789,1791 > missing /etc/X11/sysconfig/hwbrowser.desktop > missing /usr/share/pixmaps/hwbrowser.png > missing /etc/X11/sysconfig/redhat-config-users.desktop 1763a1806 > S.5....T c /etc/httpd/conf/httpd.conf 1789a1833,1835 > Unsatisfied dependencies for gcvs-1.0b2-1: /usr/bin/csh > missing /etc/X11/sysconfig/dateconfig.desktop > missing /usr/share/pixmaps/dateconfig.png 1790a1837,1839 > missing /usr/share/pixmaps/gnome-ee.png > missing /usr/share/pixmaps/gqview.png > missing /usr/share/pixmaps/gnome-gtop.png 1835a1885,1886 > missing /usr/share/pixmaps/gedit-icon.png > missing /usr/share/pixmaps/gedit-logo.png 1849a1901,1902 > missing /etc/X11/sysconfig/printconf-gui.desktop > missing /usr/share/pixmaps/printer.png If I do a fsck on a clear unmounted disk I hade often corruption. In the past I had also an ext3 hole, I suppose that was a problem with the ext3 driver, but now I think that could be the same problem. With the kernel option ide=nodma I had no problem: no problem with nautilus, all fsck are ok.
Red Hat 7.0 used the 2.2 kernel, which had much more limited support for modern IDE chipsets in DMA mode. So, under 7.0, you may well have been running in nodma mode anyway. There are updates available for 2.4.17 which have been reported to fix some IDE DMA problems for certain chipsets, and our rawhide kernels now contain those patches if you want to try them. There have been no updates, though, from dirk.ketels@uzgent.be. Dirk, do you have "rpm -V" output for Nautilus available?
sorry for not reacting. I did leave the gnome-desktop to go to the kde- desktop, as the first reaction ( 3/2 ) was cvoming late for me ( started 19/12) and the system had to go in to production. For that reason I changed to KDE, which is not having any problems on that same machine. I can't give you any prm -V output for that reason, sorry.
OK, thanks. Please reopen if you want to take this any further.