Nautilus 2.6.0 refuses to startup. I've got a trace of the segfault: #0 0x0000002a992f007e in pthread_getconcurrency () from /lib/libpthread.so.0 #1 0x0000002a992eff00 in pthread_getconcurrency () from /lib/libpthread.so.0 #2 0x0000002a992ef837 in pthread_create () from /lib/libpthread.so.0 #3 0x0000002a991e415e in ?? () from /usr/lib/libgthread-2.0.so.0 #4 0x0000002a99843383 in g_thread_create_full () from /usr/lib/libglib-2.0.so.0 #5 0x0000002a986b9cc5 in link_thread_io_context () from /usr/lib/libORBitCosNaming-2.so.0 #6 0x0000002a986b988d in link_exec_command () from /usr/lib/libORBitCosNaming-2.so.0 #7 0x0000002a986b9d90 in link_set_io_thread () from /usr/lib/libORBitCosNaming-2.so.0 #8 0x0000002a98f7fd44 in ORBit_ObjectAdaptor_set_thread_hintv () from /usr/lib/libORBit-2.so.0 #9 0x0000002a97fca68f in bonobo_poa_get_threadedv () from /usr/lib/libbonobo-2.so.0 #10 0x0000002a97fca81d in bonobo_poa_get_threaded () from /usr/lib/libbonobo-2.so.0 #11 0x0000002a97e5a302 in _gnome_vfs_get_client () from /usr/lib/libgnomevfs-2.so.0 #12 0x0000002a97e762ac in gnome_vfs_volume_monitor_client_get_type () from /usr/lib/libgnomevfs-2.so.0 #13 0x0000002a990c8cd0 in g_type_free_instance () ---Type <return> to continue, or q <return> to quit--- from /usr/lib/libgobject-2.0.so.0 #14 0x0000002a990ca176 in g_type_class_ref () from /usr/lib/libgobject-2.0.so.0 #15 0x0000002a990b4804 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #16 0x0000002a990b4c23 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #17 0x0000002a990b4177 in g_object_new () from /usr/lib/libgobject-2.0.so.0 #18 0x0000002a97e784b0 in _gnome_vfs_get_volume_monitor_internal () from /usr/lib/libgnomevfs-2.so.0 #19 0x0000002a97e784ee in gnome_vfs_get_volume_monitor () from /usr/lib/libgnomevfs-2.so.0 #20 0x0000000000429a92 in nautilus_application_get_spatial_window_list () #21 0x0000002a990c7f84 in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #22 0x0000002a990b4c49 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #23 0x0000002a97fceddf in bonobo_object_query_local_interface () from /usr/lib/libbonobo-2.so.0 #24 0x0000002a990b4402 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #25 0x0000002a990b4c23 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #26 0x0000002a990b4177 in g_object_new () from /usr/lib/libgobject-2.0.so.0 #27 0x0000000000429b52 in nautilus_application_new () #28 0x0000000000434d9e in main () Reproducible: Always Steps to Reproduce: 1. 2. 3.
emerge info: Portage 2.0.50-r1 (default-amd64-2004.0, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.4-gentoo-r1) ================================================================= System uname: 2.6.4-gentoo-r1 x86_64 4 Gentoo Base System version 1.4.3.13p1 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://sunsite.cnlab-switch.ch/ftp/mirror/gentoo http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X aalib acpi alsa amd64 apm arts avi berkdb bonobo cdr crypt cups dvd encode esd foomaticdb gdbm gif gnome gpm gstreamer gtk gtk2 imlib java jpeg kde libg++ libwww mikmod motif mozilla mpeg ncurses nls nogcj nptl oggvorbis opengl oss pam pdflib perl png python qt quicktime readline samba sdl slang spell ssl tcpd tetex truetype unicode xml2 xmms xv zlib"
I compiled nautilus with USE="-gstreamer -cups -oggvorbis" emerge nautilus and the segfault still happens... I'll try to trace to the problem further...
i think this might be amd64 related
I've got the same problem, but I've found some more details. If I comment out all of the msdos/ntfs/nfs mounts in /etc/fstab it runs fine. Uncommenting any one of them will make it crash again.
Further testing shows that adding a new tmpfs mount causes the same problem ie none /mnt/ramdisk tmpfs defaults,user,noauto 0 0
That's what my fstab looks like. Just commenting out the tmpfs line (while it's still beeing mounted) didn't help. /dev/hda5 /boot ext2 noatime 1 1 /dev/hda2 / ext3 noatime 0 0 /dev/hda3 none swap sw 0 0 none /mnt/cdrom supermount <some options> none /mnt/burner supermount <some options> none /mnt/floppy supermount <some options> /dev/shm tmpfs defaults 0 0 But can I safely disable the tmpfs? fstab states, that glibc needs it...
on second thought, it's probably supermount.. supermount doesn't work well with nautilus. Try with it disabled.
Well, I can confirm, commenting out tmpfs and supermount sections, the bug disappeared (I also unmounted the supermount mounts). For now, this is a workaround, however, no more than a workaround. To me, it looks like a nautilus bug. Has somebody already posted this on bugs.gnome.org?
this is a known problem with nautilus for a long time (or according to some iirc with supermount). caleb, are you on amd64 as well ? there are upstream bugs i think.
Nautilus also crashes when these lines are commented out: #/dev/hdc /mnt/cdrom auto ro,user,exec 0 0 #/dev/hdd /mnt/burner auto ro,user,exec 0 0 #/dev/fd0 /mnt/floppy auto rw,user,exec 0 0 I know there were supermount issues, but nautilus-2.4 didn't crash because of them.
A bug has been added to the Gnome Bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=138986
Yes, I'm on amd64 as well, but I am NOT using supermount. My /etc/fstab follows (note, if I uncomment ANY of the commented lines nautilus starts crashing again): /dev/sda1 /boot ext2 noauto,noatime 1 1 /dev/sda3 / ext3 noatime 0 0 /dev/sda2 none swap sw 0 0 /dev/discs/disc3/part1 /home ext3 noatime 0 0 #/dev/discs/disc2/part1 /mnt/windata ntfs user,noauto,umask=000 0 0 #/dev/discs/disc0/part1 /mnt/windows ntfs user,noauto,umask=000 0 0 #/dev/discs/disc0/part2 /mnt/dos msdos user,noauto,umask=000 0 0 /dev/cdroms/cdrom0 /mnt/cdrom iso9660 user,exec,noauto,ro 0 0 /dev/floppy/0 /mnt/floppy auto user,noauto 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0
this seems to be amd64 specific & maybe not directly supermount related after all, can the amd64 team please investigate ? It would be helpful if the reporters here could build their builds with full debug output support and get a backtrace. That includes building gnomevfs, nautilus, glib,libbonobo & orbit2
Ask and ye shall receive: CFLAGS="-ggdb -pipe" FEATURES="nostrip" USE="debug" re-emerged glib,ORBit2,gnome-vfs,libbonobo,libgnomeui,nautilus ---------------------------- (gdb) run Starting program: /usr/bin/nautilus (nautilus:28778): Gtk-WARNING **: Unable to locate theme engine in module_path: "redmond95", (nautilus:28778): Gtk-WARNING **: Unable to locate theme engine in module_path: "redmond95", Program received signal SIG32, Real-time event 32. 0x0000002a9936f07e in pthread_getconcurrency () from /lib/libpthread.so.0 (gdb) bt #0 0x0000002a9936f07e in pthread_getconcurrency () from /lib/libpthread.so.0 #1 0x0000002a9936ef00 in pthread_getconcurrency () from /lib/libpthread.so.0 #2 0x0000002a9936e837 in pthread_create () from /lib/libpthread.so.0 #3 0x0000002a99262472 in g_thread_create_posix_impl ( thread_func=0x2a998d1c99 <g_thread_create_proxy>, arg=0x6d4840, stack_size=0, joinable=1, bound=0, priority=G_THREAD_PRIORITY_NORMAL, thread=0x6d4868, error=0x7fbfffe6e8) at gthread-posix.c:339 #4 0x0000002a998d1fbd in g_thread_create_full ( func=0x2a98715076 <link_io_thread_fn>, data=0x0, stack_size=0, joinable=1, bound=0, priority=G_THREAD_PRIORITY_NORMAL, error=0x7fbfffe748) at gthread.c:587 #5 0x0000002a98715267 in link_exec_set_io_thread (data=0x7fbfffe7d0, immediate=1) at linc.c:402 #6 0x0000002a98715364 in link_dispatch_command (data=0x7fbfffe7d0, immediate=1) at linc.c:444 #7 0x0000002a98714c9c in link_exec_command (cmd=0x7fbfffe7d0) at linc.c:115 #8 0x0000002a98715300 in link_set_io_thread (io_in_thread=1) at linc.c:429 #9 0x0000002a98fea75e in ORBit_ObjectAdaptor_set_thread_hintv ( adaptor=0x753c40, thread_hint=ORBIT_THREAD_HINT_PER_OBJECT, args=0x7fbfffe8f0) at orbit-adaptor.c:29 #10 0x0000002a98011c3d in bonobo_poa_get_threadedv ( hint=ORBIT_THREAD_HINT_PER_OBJECT, args=0x7fbfffe8f0) at bonobo-main.c:392 #11 0x0000002a98011d95 in bonobo_poa_get_threaded ( ---Type <return> to continue, or q <return> to quit--- hint=ORBIT_THREAD_HINT_PER_OBJECT) at bonobo-main.c:428 #12 0x0000002a97e94b81 in _gnome_vfs_get_client () at gnome-vfs-client.c:339 #13 0x0000002a97eb8757 in gnome_vfs_volume_monitor_client_class_init ( class=0x753b80) at gnome-vfs-volume-monitor-client.c:83 #14 0x0000002a991421d4 in type_class_init_Wm (node=0x62e690, pclass=0x6d4550) at gtype.c:1907 #15 0x0000002a99143a77 in g_type_class_ref (type=6481552) at gtype.c:2404 #16 0x0000002a9912666c in g_object_newv (object_type=6481552, n_parameters=0, parameters=0x0) at gobject.c:857 #17 0x0000002a99126cd0 in g_object_new_valist (object_type=6481552, first_property_name=0x0, var_args=0x7fbfffed90) at gobject.c:984 #18 0x0000002a991264ae in g_object_new (object_type=6481552, first_property_name=0x0) at gobject.c:822 #19 0x0000002a97ebb070 in _gnome_vfs_get_volume_monitor_internal (create=1) at gnome-vfs-volume-monitor.c:226 #20 0x0000002a97ebb0ed in gnome_vfs_get_volume_monitor () at gnome-vfs-volume-monitor.c:238 #21 0x0000000000429f16 in nautilus_application_instance_init ( application=0x754a20) at nautilus-application.c:182 #22 0x0000002a991415bb in g_type_create_instance (type=7683392) at gtype.c:1595 #23 0x0000002a991272dc in g_object_constructor (type=7683392, n_construct_properties=1, construct_params=0x756e00) at gobject.c:1044 #24 0x0000002a98018161 in bonobo_object_constructor (type=7683392, ---Type <return> to continue, or q <return> to quit--- n_construct_properties=1, construct_properties=0x756e00) at bonobo-object.c:813 #25 0x0000002a99126a5c in g_object_newv (object_type=7683392, n_parameters=0, parameters=0x0) at gobject.c:941 #26 0x0000002a99126cd0 in g_object_new_valist (object_type=7683392, first_property_name=0x0, var_args=0x7fbffff230) at gobject.c:984 #27 0x0000002a991264ae in g_object_new (object_type=7683392, first_property_name=0x0) at gobject.c:822 #28 0x0000000000429ff9 in nautilus_application_new () at nautilus-application.c:201 #29 0x0000000000436e6f in main (argc=1, argv=0x7fbffff648) at nautilus-main.c:319
hey guys.... sorry to complicate matters even more, but I've noticed something interesting. The following line in my fstab causes nautilus to segfault: /dev/hda1 /mnt/xp ntfs noauto,user,ro,umask=000 0 0 or at least it /used/ to make nautilus segfault. I just recompiled glibc with NPTL support and nautilus no longer crashes when I leave that line uncommented. so... any idea why that might happen?
Are we maybe looking at a glibc/pthread bug that nautilus exposes?
that is quite possible... anyone with the keywords to install gnome 2.6 is also using a cvs snapshot of glibc. i think it might be a good idea for me to try compiling and using nautilus with a stable glibc. unfortunately, i cant downgrade glibc without breaking everything so i'd have to build from scratch using a stable stage... is anybody else experiencing this bug able to easily test it against a stable glibc? start off amd64, then: mkdir /etc/portage echo "=sys-libs/glibc-2.3.3*" > /etc/portage/package.mask afterward, switch to ~amd64 by adding it to ACCEPT_KEYWORDS and install gnome 2.6. let us know if the problem persists...
Well, after rebuilding glibc with nptl and rebuilding nautilus and relevant libs, I still get the segfault. One notable thing is different though. #0 in the backtrace previous to nptl was in pthread_getconcurrency () from /lib/libpthread.so.0, now WITH nptl it's in free () from /lib/libc.so.6. My money is on this being a bug in the glibc snapshot.
the entry in /etc/fstab that breaks nautilus doesn't do so when using the stable glibc. this is definately a glibc bug.
well, I found an interesting bug in glibc 2.3.3 that might be the cause of our pthread issues. "Without TLS, the thread descriptor is allocated from stack. If the thread stack is malloced and set by pthread_attr_setstack, it may be freed before the thread manager thread finishes processing the thread descriptor." http://sources.redhat.com/bugzilla/show_bug.cgi?id=110 that explains why nptl fixes it for me. the glibc ebuild only enables thread-local storage if nptl is enabled, as they both seem to require at least a 2.6 kernel and 2.6 kernel headers. so.. yeah. a fix to that here would require 2.6 kernel headers to enable thread local storage, and there are still a number of essentials that will refuse to compile with linux-headers 2.6, at least on amd64. a prime example is sash. also, users in testing cant downgrade glibc to stable without breaking their entire install.
base-system - this is a glibc bug, and it seems not to be amd64 specific.
adding plasmaroo at his request since header-related problems go to him
I just temporary set ACCEPT_KEYWORDS="~amd64" to install Gnome 2.6, so I'm using glibc-2.3.2-r9, and I'm getting the crash. Looking at "etcat uses glibc" I get: U I [ Found these USE variables in : sys-libs/glibc-2.3.2-r9 ] + + nls : unknown - - pic : Build position independent code. Needed for (prelink/hardened-gcc) - - build : !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping. - - nptl : If you want the Native POSIX Threading Library built into glibc. Is it safe to recompile glibc with nptl? If so, I can see if that fixes the problem.
crap. guess that kills the glibc cvs snapshot theory. charles, would you mind adding a comment to http://bugzilla.gnome.org/show_bug.cgi?id=140348 ? after peeking through the gnome bugzilla, it seems most (if not all) of the people reporting this bug are gentoo users. this is still very likely a gentoo bug. :/
can everyone try the new glibc snapshot and see if this fixes things?
Well, I'd love to try the new glibc snapshot, but it doesn't build for me, off to file a bug report now.
I emerged glibc 2.3.3_pre20040420 snapshot last night and then rebuilt nautilus (just in case). Still no dice, fails on load unless I disable a fair number of my fstab entries.
Im going to try explicitly USEing NPTL and re-emerging glibc, since it is... possible... it is the problem. Also, I have discovered that ONE line of my fstab doesnt cause nautilus to crash, the line for my Memory Stick reader; which differs not really at all from any other lines... wierness, will attach my fstab later. err! D.
Created attachment 30226 [details] my fstab Ok, see attachment; if *ANY* of the 3 commented finesystems (or combination thereof) are uncommented, nautilus will segfault. All are IDE All are removeable devices AMD64 gentoo-dev-sources 2.6.5-r1 sys-libs/glibc-2.3.3_pre20040420 sys-devel/gcc-3.3.3-r3 gnome-base/nautilus-2.6.1 oddness
I'm using sys-libs/glibc-2.3.2-r9 with USE=nptl and still get this segfault. (disappears upon removing supermount entries from fstab.)
Same problem here...
On my box nautilus segfaulted too... i noticed that the reason for the problems was a mount option... one line in my fstab looked like this /dev/cdrom /mnt/cdrom iso9660 noauto,user,owner 0 0 if i remove the user and owner options nautilus stops segfaulting... i'm not soo sure that it's a glibc problem after all...
I have the same problem on Alpha (EV56). Here is my fstab : ---------------- /dev/scsi/host0/bus0/target0/lun0/part1 /boot ext3 defaults 0 2 /dev/md/0 / ext3 errors=remount-ro 0 1 /dev/scsi/host0/bus0/target0/lun0/part2 none swap sw 0 0 /dev/scsi/host0/bus0/target1/lun0/part2 none swap sw 0 0 /dev/scsi/host0/bus0/target2/lun0/part2 none swap sw 0 0 /dev/scsi/host0/bus0/target3/lun0/part2 none swap sw 0 0 /dev/cdroms/cdrom0 /mnt/dvd iso9660 noauto,ro,user 0 0 /dev/cdroms/cdrom1 /mnt/cdrom iso9660 noauto,ro,user 0 0 /dev/fd0 /mnt/floppy auto noauto,user 0 0 /dev/md/1 /usr ext3 defaults 0 2 /dev/md/2 /home ext3 defaults 0 2 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 /dev/scsi/host0/bus0/target0/lun0/part4 /mnt/redhat ext3 noauto,ro 0 2 Here is my emerge info : ---------------------- Portage 2.0.50-r6 (default-alpha-1.4, gcc-3.3.3, glibc-2.3.3_pre20040207-r0, 2.6.5) ================================================================= System uname: 2.6.5 alpha EV56 Gentoo Base System version 1.4.10 Autoconf: sys-devel/autoconf-2.59-r3 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="alpha ~alpha" AUTOCLEAN="yes" CFLAGS="-mcpu=ev56 -O3 -pipe" CHOST="alpha-unknown-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=ev56 -O3 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="ccache" GENTOO_MIRRORS="http://gentoo.oregonstate.edu" MAKEOPTS="-j1" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X X509 acl alpha alsa avi berkdb bonobo cdr clamav crypt cups doc dvb dvd encode esd ethereal evo fam ffmpeg flac flash foomaticdb gamma gb gd gdbm gif gnome gpm gstreamer gtk gtk2 gtkhtml guile hbci imagemagick imap imlib info innodb ipv6 jpeg kerberos lcms ldap libg++ libgda libwww mad maildir mbox mcal memlimit menu mikmod mldonkeypango motif mozilla mozinterfaceinfo mozirc mozp3p mozsvg mozxmlterm mpeg music ncurses nls oav odbc oggvorbis opengl pam pdf pdflib perl pic plotutils png postgres ppds python quicktime readline samba sasl scanner sdl slang slp snmp spell ssl tcltk tcpd tetex tiff transcode truetype type1 usb v4l videos vim-with-x wmf xfs xinerama xml xml2 xmms xosd xv xvid zlib" Here is the trace : ----------------- Backtrace was generated from '/usr/bin/nautilus' (no debugging symbols found)...Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)... (no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...0x0000020001689e40 in waitpid () from /lib/libpthread.so.0 #0 0x0000020001689e40 in waitpid () from /lib/libpthread.so.0 #1 0x000002000049e094 in libgnomeui_module_info_get () from /usr/lib/libgnomeui-2.so.0 #2 0x0000020001688ea8 in pthread_barrierattr_setpshared () from /lib/libpthread.so.0 #3 0x0000020001a3a420 in sigset () from /lib/libc.so.6.1 #4 0x0000020001a87528 in free () from /lib/libc.so.6.1 #5 0x000002000175bb24 in g_free () from /usr/lib/libglib-2.0.so.0 #6 0x00000200014fc848 in ORBit_free_T () from /usr/lib/libORBit-2.so.0 #7 0x00000200014fc614 in CORBA_wstring_len () from /usr/lib/libORBit-2.so.0 #8 0x00000200014fc5b8 in CORBA_wstring_len () from /usr/lib/libORBit-2.so.0 #9 0x00000200014fc804 in ORBit_free_T () from /usr/lib/libORBit-2.so.0 #10 0x00000200014fc500 in CORBA_wstring_len () from /usr/lib/libORBit-2.so.0 #11 0x00000200014fc804 in ORBit_free_T () from /usr/lib/libORBit-2.so.0 #12 0x00000200014fc8bc in ORBit_free () from /usr/lib/libORBit-2.so.0 #13 0x00000200014fc708 in CORBA_free () from /usr/lib/libORBit-2.so.0 #14 0x0000020000e193c4 in _gnome_vfs_volume_monitor_client_daemon_died () from /usr/lib/libgnomevfs-2.so.0 #15 0x0000020000e19050 in _gnome_vfs_volume_monitor_client_daemon_died () from /usr/lib/libgnomevfs-2.so.0 #16 0x0000020001579b7c in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #17 0x0000020001562d9c in g_cclosure_new_object_swap () from /usr/lib/libgobject-2.0.so.0 #18 0x000002000155d694 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #19 0x000002000155e184 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #20 0x000002000155d374 in g_object_new () from /usr/lib/libgobject-2.0.so.0 #21 0x0000020000e1c418 in _gnome_vfs_get_volume_monitor_internal () from /usr/lib/libgnomevfs-2.so.0 #22 0x0000020000e1c49c in gnome_vfs_get_volume_monitor () from /usr/lib/libgnomevfs-2.so.0 #23 0x0000000120028144 in nautilus_application_close_all_navigation_windows () #24 0x0000020001579b7c in g_type_create_instance () from /usr/lib/libgobject-2.0.so.0 #25 0x0000020001562d9c in g_cclosure_new_object_swap () from /usr/lib/libgobject-2.0.so.0 #26 0x0000020000e90d54 in bonobo_object_bag_destroy () from /usr/lib/libbonobo-2.so.0 #27 0x000002000155d694 in g_object_newv () from /usr/lib/libgobject-2.0.so.0 #28 0x000002000155e184 in g_object_new_valist () from /usr/lib/libgobject-2.0.so.0 #29 0x000002000155d374 in g_object_new () from /usr/lib/libgobject-2.0.so.0 #30 0x0000000120027b74 in nautilus_application_new () #31 0x000000012003e5f8 in main ()
can't use nautilus either, neither with gnome-2.4.2 nor with gnome-2.6. i heared that it may be related to the fstab, so here's mine: # /etc/fstab: static file system information. # $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.14 2003/10/13 20:03:38 azarah Exp $ /dev/sdb1 /boot ext2 noauto,noatime 1 2 /dev/md0 none swap sw 0 0 /dev/md1 / ext3 noatime 0 1 /dev/md2 /home ext3 noatime 0 0 /dev/md3 /free ext3 noatime 0 0 /dev/hdc /mnt/dvdrw iso9660 noauto,ro,users 0 0 /dev/hdb /mnt/cdrw iso9660 noauto,ro,users 0 0 /dev/hda /mnt/dvd iso9660 noauto,ro,users 0 0 /dev/fd0 /mnt/floppy auto noauto 0 0 /dev/sdd1 /mnt/sdd1 vfat noauto,rw,users 0 0 /dev/sdd2 /mnt/sdd2 ext3 noauto,rw,users 0 0 /dev/sdd3 /mnt/sdd3 ext3 noauto,rw,users 0 0 /dev/sdd2 /mnt/ipod vfat noauto,ro,users 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0
if this happens on alpha as well, i'm beginning to think we have 64bit issues somewhere and i'm just too dense to see them. also, if it happens with gnome 2.4.2 it cant be a problem with nautilus either... blinkeye: can you give us the output of emerge info, and let us know which version of glib and gtk+ you had installed when nautilus from 2.4.2 died?
ok, now this just gets wierd; the bug doesnt occur with this fstab: # /etc/fstab: static file system information. # $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.13 2003/07/17 19:55:18 azarah Exp $ # <fs> <mountpoint> <type> <opts> <dump/pass> /dev/discs/disc0/part2 /boot ext2 noauto,noatime 1 1 /dev/discs/disc0/part3 / ext3 noatime 0 0 /dev/discs/disc0/part1 none swap sw 0 0 /dev/discs/disc2/part1 /arch vfat rw,umask=0000 0 0 /dev/discs/disc1/part1 /mnt/windrive ntfs rw,umask=0000 0 0 #/dev/cdroms/cdrom0 /mnt/cdrom auto noauto,ro,users,exec 0 0 /dev/sde2 /mnt/ipod vfat users,rw,umask=0000,noauto 0 0 #/dev/hdc1 /mnt/archive auto users,rw,umask=0000,noauto 0 0 /dev/sda1 /mnt/cf auto users,rw,umask=0000,noauto 0 0 #/dev/sdb1 /mnt/ms auto users,rw,umask=0000,noauto 0 0 #/dev/sdc1 /mnt/sd auto users,rw,umask=0000,noauto 0 0 #/dev/sdd1 /mnt/sm auto users,rw,umask=0000,noauto 0 0 none /proc proc defaults 0 0 none /dev/shm tmpfs defaults 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0 However, if I uncomment any ONE of /dev/sdb1, /dev/sdc1, /dev/sdd1; it segfaults... wtf?? the lines are fsking identical!!!! Also, when I was editing fstab to a form which brings nautilus down, epiphany crashed in the background with a "cannot access bonobo resource" or some such... this may be unrelated as I was flashing the firmware on my wireless AP at the time...
The "users" option is what is doing it! When you have "users" or "user" set, Nautilus makes an icon on the desktop, and an entry in "Save in Folder" on the new save menu (click save in gedit 2.6). That is where the crash is occuring. Everyone, try removing "user" and "users" and see what you get.
if this is the case, why are their lines containing users or user which *DO* work?? I would buy this if the behaviour was consistent, it isnt; two lines with "users" work, 3 dont. Besides, bloody pointless having entries in fstab that don't have "users" or "auto", just as easy to type a fully qualified command line for mount. Are there any thoughts as to the cause of this bug?? Im willing to do unpleasant things to my system to make this work...
I think Charles has got a point with the user/users option being the cause of the trouble. However, one or two fstab entries with user/users options seem to be ok, three or more entries gives me a crash every time. I have three fstab entries with the user options: /dev/dvd /mnt/dvd auto user,noauto,ro,exec 0 0 /dev/cdrw /mnt/cdrw auto user,noauto,ro,exec 0 0 /dev/usbhd1 /mnt/usbhd auto user,noauto,rw,sync 0 0 if I comment out (or remove the user option from) any one of them then nautilus will start. Having all three leads to a crash. can anyone confirm this behaviour?
The same goes for supermount entries. As long as you have no more than two fstab entries with supermount,user or users options then nautilus won't crash. Three or more such lines in any combination gives me the crash. (this kind of makes sense as these are the only fstab entries that nautilus takes notice of afaik)
I can confirm Herbie's behaviour; and TWO of the sda throught sde (except sdc : "#/dev/sdc1 /mnt/sd auto users,rw,umask=0000,noauto 0 0", crashes every time) in my fstab uncommented is fine, any more and there is a crash. However, *ANY* IDE device in my fstab with "users" will cause the segfault.
Pukka backtrace with all debug info (prior backtraces are either at SIG32 == wrong (use cont until you get SIGSEGV ;-) or stripped... Program received signal SIGSEGV, Segmentation fault. ORBit_free_T (mem=0x400000002) at allocators.c:167 167 allocators.c: No such file or directory. in allocators.c (gdb) bt #0 ORBit_free_T (mem=0x400000002) at allocators.c:167 #1 0x0000002a98cfbffc in ORBit_freekids_via_TypeCode_T (mem=0x71bf70, tc=0x5ae610) at allocators.c:88 #2 0x0000002a98cfbfe3 in ORBit_freekids_via_TypeCode_T (mem=0x71bf70, tc=0x2a980207e0) at allocators.c:65 #3 0x0000002a98cfbe16 in ORBit_free_T (mem=0x400000002) at allocators.c:197 #4 0x0000002a98cfc0eb in ORBit_freekids_via_TypeCode_T (mem=0x71bbc0, tc=0x2a98020760) at allocators.c:96 #5 0x0000002a98cfbe16 in ORBit_free_T (mem=0x400000002) at allocators.c:197 #6 0x0000002a98cfbe80 in ORBit_free (mem=0x71bbc0) at allocators.c:213 #7 0x0000002a97eff4c6 in read_drives_from_daemon (volume_monitor_client=0x71c640) at gnome-vfs-volume-monitor-client.c:135 #8 0x0000002a97eff629 in gnome_vfs_volume_monitor_client_init (volume_monitor_client=0x71bb50) at gnome-vfs-volume-monitor-client.c:182 #9 0x0000002a98e5bd18 in g_type_create_instance (type=0) at gtype.c:1595 #10 0x0000002a98e4276c in g_object_constructor (type=17179869186, n_construct_properties=0, construct_params=0x0) at gobject.c:1044 #11 0x0000002a98e41ac7 in g_object_newv (object_type=7438496, n_parameters=0, parameters=0x0) at gobject.c:941 #12 0x0000002a98e425c5 in g_object_new_valist (object_type=7438496, first_property_name=0x0, var_args=0x7fbfffeb50) at gobject.c:984 #13 0x0000002a98e42739 in g_object_new (object_type=7438496, first_property_name=0x0) at gobject.c:822 #14 0x0000002a97f01821 in _gnome_vfs_get_volume_monitor_internal (create=1) at gnome-vfs-volume-monitor.c:226 #15 0x0000000000429f72 in nautilus_application_instance_init (application=0x717780) at nautilus-application.c:183 #16 0x0000002a98e5bd18 in g_type_create_instance (type=0) at gtype.c:1595 #17 0x0000002a98e4276c in g_object_constructor (type=17179869186, n_construct_properties=1, construct_params=0x717990) at gobject.c:1044 #18 0x0000002a9819a4b9 in bonobo_object_query_local_interface () from /usr/lib/libbonobo-2.so.0 #19 0x0000002a98e41ac7 in g_object_newv (object_type=7420512, n_parameters=1, parameters=0x717970) at gobject.c:941 #20 0x0000002a98e425c5 in g_object_new_valist (object_type=7420512, first_property_name=0x0, var_args=0x7fbffff160) at gobject.c:984 #21 0x0000002a98e42739 in g_object_new (object_type=7420512, first_property_name=0x0) at gobject.c:822 #22 0x000000000042a032 in nautilus_application_new () at nautilus-application.c:202 #23 0x0000000000435d45 in main (argc=0, argv=0x7fbffff528) at nautilus-main.c:319
I debugged gnome-vfs-daemon at the same time as running nautilus - it also segfaults in a similar manner... Program received signal SIGSEGV, Segmentation fault. ORBit_free_T (mem=0x400000002) at allocators.c:167 167 allocators.c: No such file or directory. in allocators.c (gdb) bt #0 ORBit_free_T (mem=0x400000002) at allocators.c:167 #1 0x0000002a95cf4ffc in ORBit_freekids_via_TypeCode_T (mem=0x5650a0, tc=0x513020) at allocators.c:88 #2 0x0000002a95cf4fe3 in ORBit_freekids_via_TypeCode_T (mem=0x5650a0, tc=0x40d220) at allocators.c:65 #3 0x0000002a95cf4e16 in ORBit_free_T (mem=0x400000002) at allocators.c:197 #4 0x0000002a95cf50eb in ORBit_freekids_via_TypeCode_T (mem=0x564e50, tc=0x40d1a0) at allocators.c:96 #5 0x0000002a95cf4e16 in ORBit_free_T (mem=0x400000002) at allocators.c:197 #6 0x0000002a95cf4e80 in ORBit_free (mem=0x564e50) at allocators.c:213 #7 0x0000002a95cefc74 in ORBit_small_invoke_adaptor (adaptor_obj=0x558090, recv_buffer=0x55ad40, m_data=0x511b20, data=0x7fbffff490, ev=0x7fbffff4f0) at orbit-small.c:971 #8 0x0000002a95cfeebc in ORBit_POAObject_handle_request (pobj=0x558090, opname=0x55b7cc "getDrives", ret=0x0, args=0x0, ctx=0x0, recv_buffer=0x55ad40, ev=0x7fbffff4f0) at poa.c:1350 #9 0x0000002a95cff5e1 in ORBit_POAObject_invoke_incoming_request (pobj=0x558090, recv_buffer=0x55ad40, opt_ev=0x0) at poa.c:1418 #10 0x0000002a95ce8656 in giop_thread_queue_process (tdata=0x51f0a0) at giop.c:743 #11 0x0000002a95ce896f in giop_mainloop_handle_input (source=0x400000002, condition=5320736, data=0x2a95d11020) at giop.c:450 #12 0x0000002a962aefcc in unblock_source () from /usr/lib/libglib-2.0.so.0 #13 0x0000002a962b042d in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #14 0x0000002a962b0950 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #15 0x0000002a962b118b in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #16 0x0000002a959495f6 in bonobo_main () from /usr/lib/libbonobo-2.so.0 #17 0x0000000000407054 in main (argc=3, argv=0x513020) at gnome-vfs-daemon.c:605
I've tried starting nautilus with several different lines in fstab to get a clue as to what exactly causes the problem. Here are the results: NO SEGFAULT: /dev/hda1 /mnt/other vfat defaults 0 0 /dev/hda1 /mnt/other ext3 defaults 0 0 SEGFAULTS: /dev/hda1 /mnt/other ext3 defaults,user 0 0 /dev/hda1 /mnt/other vfat noauto,owner,nodev 0 0 /dev/hda1 /mnt/other vfat defaults,user 0 0 Apparently the presence of the 'user' or 'owner' flag is making nautilus segfault. The coredump I get is identical to the one in Comment #33 From Mathieu Millet. I don't know if that happens in i686, since I only have an amd64 at home to test it. By the way, changing glibc version as suggested in other posts didn't help me at all :-(
woohoo! there is now a fix for this in gnome bugzilla: http://bugzilla.gnome.org/show_bug.cgi?id=138986 Seems is was on ORBit2 problem after all. Please can we have this patch added to the ORBit2 ebuild.
fixed in cvs, give it some time to reach rsync. then go nuts remerging ORBit2! :)
uhm, this is still a gnome pack, so i would prefer if you could wait for our approval to apply it for all arches (c'mon how often do i have to repeat this). second, why don't you rev bump it like it should've been, the fix is important enough. This way it won't be fixed for anyone who's not on this bug. third, please use the usual ${PN}-${PV}-bug_desc.patch format for the patch in gnome ebuilds. fourth.. the changelog doesn't need to c&p of some quote, just a reference is more than enough, this clutters up the format needlessly. 5th amd64 is once again needlessly marking stable before the maintainers arch -> 2.10.1 (c'mon how often do i have to repeat this?) You do try to apply it for all arches, but effectively it only helps on amd64 atm and not even everybody on amd64. Try to think consequences before you act.
FUCK YOU. 1) sorry it doesnt fuck up on x86 2) i was waiting for a gnome dev in #gentoo-dev to ask for a rev bump because you chewed me out about the subject before. 3) the patch applies and works for multiple versions of orbit2 asshole. that's why i didnt use that format. same patch, multiple ${PV}. 4) i ALSO got bitched out by another person on gnome for adding a fix and not a bug fat ass description as to why it was added. 5) you're not an arch maintainer for amd64. suck a cock. 6) this bug effects at least alpha and ppc. scroll up and see the fucking comment about alpha, and i've had someone mention it doing the same on ppc with a different number of entries. on another gnome bug report (i think it got marked a dupe?) it mentioned ppc64. once again FUCK YOU, this is not in any way an arch specific bug! i cant do a damn thing right it the eyes of the gnome herd, so i really dont give a shit. lick my swamp. i dont care.
ok, little boys, both of you need to pack it in. foser, while I agree with most of what you say, you were a little bit overly harsh with Lv, and it would have served you well to talk to him on irc/in private email over your perceptions. You can't just criticise people in public and not expect a backlash. having said that, Lv: your response was _inappropriate_ and I'm being kind when I say that. This sort of behaviour is an embarrassment to Gentoo, and I'll thank you to knock it off. Everyone on the CC: list and to the bug reporter: my apologies on their behalf.
Well, indeed this kind of behaviour is disapointing... and should be taken away in irc/pm... Anyway, this patch was the solution ! Now, I can put back my good old fstab, and unmerge automount, as I used it as a workaround ;-) Thanks !
I couldn't be on IRC last few days, only time I have right now is spent going trough bugmail. About my list : Part of it were just pointers to keep in mind next time, no big deal (3 & 4) Others were things where the amd64 team went around the herds protocol and this got discussed before, so i really don't see why it has to happen once again (1 & 5) Last but not least we have the simple QA measures (rev bumping, arch only patches) to make sure it works for everybody affected... the patch doesn't even get exposure for all of amd64 at this point, i'd say thats something the arches own team should be looking at (not to mention all the other arches influenced) (2 & 6) Lv : 1) You don't know that, actually you just assume it here without proof. Besides that the maintainer of the pack hasn't responded to the upstream patch yet & the author of the patch sais it's probably not the best fix. I seriously think you should be more cautious applying a fix to all arches that only fixes a problem on amd64 & alpha that is not checked & approved upon (in the past a similar amd64 specific fix did break other arches -> remember *mm bugs ?) 2) That's good & I appreciate that, I know i wasn't on IRC so I guess that made it hard to wait, but you can always mail gnome@gentoo.org & we're on the bug, so you could've reacted there. The problem is not so much with applying the patch, but with applying it to all arches. Plus the lack of rev bumping, effectively there's ppl now with the same version number, where one guy experiences the bug (hasn't rebuild) & the other doesn't. This should never happen. 3) We either choose to not use the full version (2.10.x) or use the first version number the patch is applied to/applies to. That's also a sort of versioning control/reminder. No biggie. 4) All needed references are here in the bug, just reference to it with a short note what problem it fixes. Short, but all info that is needed is easily accessible. No biggie. 5) Don't pretend you don't know what i mean here. It has nothing todo with amd64 or being a maintainer for it, no arch should move to stable before the maintainer makes it stable on his arch, thats the _only_ way proper QA of an ebuild can be applied & ensured by it's maintainer. That's the way it works. I'm actually amazed everytime an arch doesn't do this, because it's nothing more than logical and most arches have their specific issues already, so I don't know why they would want to deal with general package bugs needlessly as well. 6) It is an alignment issue.. you as amd64 maintainer should immediatly know that the likelihood that it only affects 64 bit platforms is like 99%. The whole fact that it didn't get reported on x86 is a statement to that assumption, as well as the other arches being reported are alpha & ppc64. And sure you can do things right (actually i did admire the speed with which you applied the patch), but the real problem here is that the amd64 team makes the same basic QA mistakes again and again. As far as this being outside the scope of this bug : I think proper maintenance & QA on _all_ platforms is part of a bug & that was one of the reasons i just commented here (plus that i wasn't on IRC).
foser, thanks for the longer note with explanations. The only issue that I can see from the initial communication (which seemed to have sparked off the rather bad reaction from Lv) was in the way you came across. It isn't new, of course, it's just you, but I think if your "tone" (if I may use that word) was a little clipped -- that said, if this last note of yours was actually the first note of yours, things *might* have gone differently ;) That said, I'm adding amd64@gentoo to the CC list, as you seem to have a long standing complaint against their methods, so I'd like them to be aware of this instance.
[Lv] do you mind making the reply for me? with "travis tilley would like to respond, but doesnt have bugzilla access anymore so he asked me to paste this:" [Lv] ? [msg(Lv)] I'm waiting to paste. [Lv] actually, yes, thankyou. i would have appreciated the second reply even though it is still being sent to a mass mailing of users on this bug that has been building up since early april... [Lv] and i apologise for blowing up on you, but i did -not- appreciate how you were treating me. and it still does seem to me that i cant do right in the eyes of gnome... [Lv] 2) i was watching irc on one monitor and anime on the other at the time. i was just checking my mail and about to shoot off a mail to gnome when i saw the reply to that bug and snapped. [Lv] 5) x86 and amd64 have different bugs. i've figured this out quite quickly from my work with gcc 3.4. as a result, id' call gcc 3.4 stable on amd64 and ppc64 but i wouldnt even put it into testing on x86 yet... far too many apps use assembly that clobbers ebx, which is needed for handling PIC. plus, i really dont like having a .0 in stable if i can avoid it, so i think it's a good idea to have .1 in stable and . [Lv] 2 in testing. i do realise that we're the only arch with that package in stable, but our only major bug with it just got fixed (and is in all versions). [msg(Lv)] that it? [Lv] yeah [Lv] and to everyone on the list, sorry for blowing up in front of all of you
