Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 122662
Summary: | nautilus crashes and will not restart when entering gnome | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Chuck Mead <csm> | ||||||
Component: | nautilus | Assignee: | Alexander Larsson <alexl> | ||||||
Status: | CLOSED DUPLICATE | QA Contact: | |||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | rawhide | CC: | alanh, csm, fedora, jsk_priv, marshall, thomas.walker | ||||||
Target Milestone: | --- | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2006-02-21 19:03:04 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 114961, 123268 | ||||||||
Attachments: |
|
Description
Chuck Mead
2004-05-06 18:18:31 UTC
I ran an strace on this Nautilus problem. Here is the end of it: mmap(NULL, 10485760, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS|0x40, -1, 0) = 0x40000000 mprotect(0x40000000, 4096, PROT_NONE) = 0 clone(child_stack=0x409ff8b0, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0x409ff9f0, tls=0x409ff960, child_tidptr=0x409ff9f0) = 5008 futex(0x3cc7283c28, FUTEX_WAKE, 1) = 1 writev(18, [{"GIOP\1\2\1\0\16\3\0\0", 12}, {"h\352\377\277\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\225P\330"..., 782}], 2) = 794 futex(0x5e19e0, FUTEX_WAIT, 0, NULL) = 0 futex(0x5e19a0, FUTEX_WAKE, 1) = 0 socket(PF_UNIX, SOCK_STREAM, 0) = 23 fcntl(23, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 fcntl(23, F_SETFD, FD_CLOEXEC) = 0 connect(23, {sa_family=AF_UNIX, path="/tmp/orbit-csm/linc-1392-0-90850df6d638"}, 42) = 0 write(20, "A", 1) = 1 futex(0x82d738, FUTEX_WAKE, 1) = 1 writev(23, [{"GIOP\1\2\1\0\224\1\0\0", 12}, {"8\354\377\277\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0q\230H\350"..., 404}], 2) = 416 futex(0x5e19e0, FUTEX_WAIT, 1, NULL) = 0 futex(0x5e19a0, FUTEX_WAKE, 1) = 0 writev(23, [{"GIOP\1\2\1\0\234\1\0\0", 12}, {"\230\354\377\277\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0q\230"..., 412}], 2) = 424 futex(0x5e19e0, FUTEX_WAIT, 2, NULL) = 0 futex(0x5e19a0, FUTEX_WAKE, 1) = 0 writev(23, [{"GIOP\1\2\1\0\214\1\0\0", 12}, {"\370\353\377\277\3\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0q\230"..., 396}], 2) = 408 futex(0x5e19e0, FUTEX_WAIT, 3, NULL) = 0 futex(0x5e19a0, FUTEX_WAKE, 1) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- write(3, "\22\0\20\0\1\0@\2\4\1\0\0\37\0\0\0\10_ID%\0\0\00011c0a"..., 72) = 72 write(3, " \0\2\0\0\0\0\0", 8) = 8 write(3, "+\0\1\0", 4) = 4 read(3, 0x7fbfffe5e0, 32) = -1 EAGAIN (Resource temporarily unavailable) select(4, [3], NULL, NULL, NULL) = 1 (in [3]) read(3, "\34\0G\0\1\0@\2\4\1\0\0\365\221\16\0\0\0\0\0\0\0\0\0n\222"..., 32) = 32 read(3, "\1\2J\0\0\0\0\0\25\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\200\36"..., 32) = 32 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2a9650f1f0) = 5044 wait4(5044, [WIFEXITED(s) && WEXITSTATUS(s) == 0], 0, NULL) = 5044 --- SIGCHLD (Child exited) @ 0 (0) --- rt_sigreturn(0x5e76e0) = 5044 exit_group(1) Created attachment 100056 [details]
this is an strace of nautilus blowing up with FC2T3 on an x86_64
Created attachment 100104 [details]
bug-buddy output with some debug info
this is the output from bug-buddy including some debug info. I created a brand
new user account to get this so it's default profile stuff.
CC me. Argh. I have not been able to reproduce this on any of my x86_64 systems (the rebuild issue would not impact beehive, so that is not the problem). Have you tried deleting your preferences, or replicating on a newly created user with no existing environment? In my case the system is newly installed, only root and one normal user exist. Does the gnome configuration get written when a user is created or when he logs in for the first time? The problem occurs for both root and my local user at first login. However, the problem is 100% reproducible, i even installed the OS twice to ensure nothing went wrong during installation. Could you get a backtrace of the crash? If nautilus-media is installed, could you try removing it and see if it makes any difference? an strace and a bug-buddy attachment are already here. Also... in my case I have done 4 installations. the first was an upgrade, the 2nd and 3rd were fresh installs, and on the 4th I repartitioned the box too. It does not matter what I do... nautilus crashes on root or a regular user. oh... I tried uninstalling nautilus media and it made no difference. Fresh install of FC2 Test3 on an Athlon64. Think I got all of the symbols there (deep bt w/ quite a ew libs in there). Looks like somthing in gnome-vfs is not 64 bit clean. Note that this is likely related to another x86_64 nautilus bug (I'll find it in a minute) because it starts to tumble after read_drives_from_daemon() #0 __libc_free (mem=0x500000000) at malloc.c:3356 #1 0x0000003faf52a42f in g_free (mem=0x500000000) at gmem.c:186 #2 0x0000003fb432d2ba in ORBit_free_T (mem=0x500000000) at allocators.c:187 #3 0x0000003fb432d15a in ORBit_freekids_via_TypeCode_T (mem=0x8d38b0, tc=0x5a9e00) at allocators.c:88 #4 0x0000003fb432d126 in ORBit_freekids_via_TypeCode_T (mem=0x8d38b0, tc=0x35a97661c0) at allocators.c:65 #5 0x0000003fb432d297 in ORBit_free_T (mem=0x500000000) at allocators.c:197 #6 0x0000003fb432d0b5 in ORBit_freekids_via_TypeCode_T (mem=0x8d3810, tc=0x35a9766240) at allocators.c:96 #7 0x0000003fb432d297 in ORBit_free_T (mem=0x500000000) at allocators.c:197 #8 0x0000003fb432d2fd in ORBit_free (mem=0x8d3810) at allocators.c:213 #9 0x0000003fb432d1f9 in CORBA_free (mem=0x500000000) at allocators.c:138 #10 0x00000035a9646234 in read_drives_from_daemon ( volume_monitor_client=0x8d3e60) at gnome-vfs-volume-monitor-client.c:135 #11 0x00000035a9646399 in gnome_vfs_volume_monitor_client_init ( volume_monitor_client=0x8cf430) at gnome-vfs-volume-monitor-client.c:182 #12 0x0000003fafb21dc4 in g_type_create_instance (type=0) at gtype.c:1595 #13 0x0000003fafb0ea89 in g_object_constructor (type=21474836480, n_construct_properties=0, construct_params=0x0) at gobject.c:1044 #14 0x0000003fafb0e242 in g_object_newv (object_type=7059216, n_parameters=0, parameters=0x0) at gobject.c:941 #15 0x0000003fafb0ea63 in g_object_new_valist (object_type=7059216, first_property_name=0x0, var_args=0x7fbffff080) at gobject.c:984 #16 0x0000003fafb0dfb7 in g_object_new (object_type=7059216, first_property_name=0x0) at gobject.c:822 #17 0x00000035a9648330 in _gnome_vfs_get_volume_monitor_internal (create=1) at gnome-vfs-volume-monitor.c:224 #18 0x00000035a964836e in gnome_vfs_get_volume_monitor () at gnome-vfs-volume-monitor.c:238 #19 0x0000000000429d92 in nautilus_application_instance_init ( application=0x8cb270) at nautilus-application.c:183 #20 0x0000003fafb21dc4 in g_type_create_instance (type=0) at gtype.c:1595 #21 0x0000003fafb0ea89 in g_object_constructor (type=21474836480, n_construct_properties=1, construct_params=0x8d2c70) at gobject.c:1044 #22 0x0000003fb3d31bdf in bonobo_object_query_local_interface () from /usr/lib64/libbonobo-2.so.0 #23 0x0000003fafb0e242 in g_object_newv (object_type=9244096, n_parameters=7279424, parameters=0x0) at gobject.c:941 #24 0x0000003fafb0ea63 in g_object_new_valist (object_type=9244096, first_property_name=0x0, var_args=0x7fbffff470) at gobject.c:984 #25 0x0000003fafb0dfb7 in g_object_new (object_type=9244096, first_property_name=0x0) at gobject.c:822 #26 0x0000000000429e52 in nautilus_application_new () at nautilus-application.c:202 #27 0x000000000043549e in main (argc=1, argv=0x7fbffff8b8) at nautilus-main.c:319 #122087 looks to be the same. Since it works if I remove some things from my /etc/fstab file I figured I should post that file here: LABEL=/ / ext3 defaults 1 1 LABEL=/boot /boot ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 LABEL=/home /home ext3 defaults 1 2 LABEL=/opt /opt ext3 defaults 1 2 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 LABEL=/usr /usr ext3 defaults 1 2 LABEL=/usr/local /usr/local ext3 defaults 1 2 LABEL=/var /var ext3 defaults 1 2 /dev/hdc3 swap swap defaults 0 0 /dev/hda5 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/cdrom1 /mnt/cdrom1 udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 If I remove the two cdrom's and the floppy it works. I have basically the same behavior, I only have to remove my 2nd cdrom though (which is a usb dvd writer). My install and upgrades worked perfectly, but today I attached a usb keyboard, and upgraded the bios on my workstation, that's when the problems started appearing (I had experienced the problem with an earlier test release, but it when away on a fresh install). Same here... if I comment out hdc (atapi cdrw) nautilus works. Its worth noting that I get seek errors from this device when I boot (duh, it has no media in it) but it otherwise seems to work fine. I'll take a look at this a bit more closely under gdb when I get a chance (its just too nice outside to be staring at things in debuggers today!) Well how about posting your fstab files guys... it might help with the bugfix to see what's in common on all of this! Here's my fstab, but I don't think that it show's anything overly interesting.. sda is a 18gig drive on an adaptec scsi controller, hde is a sata drive on a via controller (builtin), cdrom is a regular ide dvd drive, cdrom1 is a usb dvd writer (commented out at the moment so nautilus would work). /dev/sda2 / ext3 defaults 1 1 /dev/sda1 /boot ext3 defaults 1 2 /dev/hde3 /home ext3 defaults 1 2 none /dev/pts devpts gid=5,mode=620 0 0 none /dev/shm tmpfs defaults 0 0 none /proc proc defaults 0 0 none /sys sysfs defaults 0 0 /dev/sda3 swap swap defaults 0 0 /dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0 /dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0 #/dev/cdrom1 /mnt/cdrom1 udf,iso9660 noauto,owner,kudzu,ro 0 0 This fstab with the bottom line uncommented had been working fine for me until I did a bios upgrade and attached a usb keyboard (I did both things at the same time, so I'm not sure which caused the problem). I did try putting the keyboard back on the ps/2 port and down grading the bios, but nautilus still wouldn't start. Oh, and I did create a fresh test user to verify that it wasn't something in my user's config. Offending line is: /dev/cdrom1 /mnt/cdrom1 udf,iso9660 noauto,owner,kudzu,ro 0 0 (The default that kudzu sets up). If I remove 'owner' nautilus is able to start up. Replace it with 'user' (what I really want because local user secuirty isn't of a concern here) and it crashes again. The backtrace I posted earlier seems to indicate stack corruption (the mem value to be freed keeps flipping between a "valid" address of 0x8d3810 and 0x500000000). The last one, between frames 2 and 3 is strange, you can print the value of the pointer you're passing into ORBit_free_T(mem) before the function call and it looks good but once inside the "free", the address is corrupt... from there on out you wind up trying to 'free' in invalid address and get a SEGV as expected. Someone with a little more gonme-vfs/ORBit/CORBA experience might be able to spot what is going on here... Ditto above removing owner from fstab entry brought back nautilus as well as this gedit could open file tree to locate the fstab file. I have the exact same thing. If I remove the "owner" feature from the options line then nautilus runs perfectly! *** Bug 123154 has been marked as a duplicate of this bug. *** I think bug 123807 bug 123066 bug 122087 are duplicates / related of this bug?! A patch has been posted over at http://bugzilla.gnome.org/show_bug. cgi?id=138986">Gnome.org. The bug is in ORBit2's ORBit_freekids_via_TypeCode_T(). It doesn't adjust for the alignment of the structures in a 64 bit environment. Thanks to Chris Landrieu for finding this. I tried the fix on my Core 2 system and it works. Good to hear. I will try it within the week. The new ORBit2 is in rawhide, so this should be ok now. *** This bug has been marked as a duplicate of 123807 *** Changed to 'CLOSED' state since 'RESOLVED' has been deprecated. |