Description of problem: After applying all current updates gnome-volume-manager simply refuses to start. It does not matter if this is a part of a session startup or from a terminal window. There are no traces of anything wrong on a command line and when doing that from gdb one sees something like: Detaching after fork from child process 3136. Program exited normally. Only bug-buddy provides a backtrace which, after loading 'dbus-debuginfo' and 'gnome-volume-manager-debuginfo' looks like follows: Backtrace was generated from '/usr/bin/gnome-volume-manager' Using host libthread_db library "/lib64/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 46912516496624 (LWP 3214)] 0x00002aaaab335005 in waitpid () from /lib64/libpthread.so.0 #0 0x00002aaaab335005 in waitpid () from /lib64/libpthread.so.0 #1 0x0000003b9e2526d9 in gnome_init_with_popt_table () from /usr/lib64/libgnomeui-2.so.0 #2 <signal handler called> #3 0x0000003b9b639573 in _dbus_marshal_write_basic (str=0x585358, insert_at=20, type=115, value=0x406c4e, byte_order=108, pos_after=0x7fffffe1d200) at dbus-marshal-basic.c:808 #4 0x0000003b9b61a929 in _dbus_type_writer_write_basic ( writer=0x7fffffe1d1e0, type=115, value=0x406c4e) at dbus-marshal-recursive.c:2402 #5 0x0000003b9b6201bd in dbus_message_iter_append_basic (iter=0x7fffffe1d1d0, type=115, value=0x406c4e) at dbus-message.c:2132 #6 0x0000003b9b620615 in dbus_message_append_args_valist (message=) at dbus-message.c:1295 #7 0x0000003b9b62196c in dbus_message_append_args (message=0x585310, first_arg_type=115) at dbus-message.c:1200 #8 0x000000000040490c in gvm_device_mount ( udi=0x586cf0 "/org/freedesktop/Hal/devices/volume_uuid_3dfb7d9e_e89a_4f20_b2cc_45233842e3c8", apply_policy=0) at manager.c:1265 #9 0x00000000004051c4 in main (argc=) at manager.c:2174 #10 0x00002aaaab45ac44 in __libc_start_main () from /lib64/libc.so.6 #11 0x0000000000403a29 in _start () #12 0x00007fffffe1d598 in ?? () #13 0x0000000000000000 in ?? () Thread 1 (Thread 46912516496624 (LWP 3214)): #0 0x00002aaaab335005 in waitpid () from /lib64/libpthread.so.0 No symbol table info available. #1 0x0000003b9e2526d9 in gnome_init_with_popt_table () from /usr/lib64/libgnomeui-2.so.0 No symbol table info available. #2 <signal handler called> No symbol table info available. #3 0x0000003b9b639573 in _dbus_marshal_write_basic (str=0x585358, insert_at=20, type=115, value=0x406c4e, byte_order=108, pos_after=0x7fffffe1d200) at dbus-marshal-basic.c:808 __FUNCTION__ = "_dbus_marshal_write_basic" #4 0x0000003b9b61a929 in _dbus_type_writer_write_basic ( writer=0x7fffffe1d1e0, type=115, value=0x406c4e) at dbus-marshal-recursive.c:2402 retval = udi refered to in this backtrace belongs to, according to lshal, to a partition on a hard disk (which happens to be a boot partition of _another_ installation and not a test one). volume.label = '/boot' (string) volume.uuid = '3dfb7d9e-e89a-4f20-b2cc-45233842e3c8' (string) volume.fsversion = '1.0' (string) volume.fsusage = 'filesystem' (string) volume.fstype = 'ext2' (string) and which is not mounted or even desirable to mount. Version-Release number of selected component (if applicable): gnome-volume-manager-1.5.7-1 How reproducible: always
I am using the very same version of g-v-m on an up to date fedora devel system and I see the same crashes. But I am using Rawhide on a VMWare machine and this is happening when I try to install the VMWare Tools, it was working fine before this. It seems that VMWare Tools creates a virtual CD on the guest OS and that's when g-v-m starts crashing no matter if you start it from the command line, the only way for it to work again is to disable the VMWare Tools. Hence I am running Rawhide without g-v-m. Michal, are you using VMWare? It seems to me that my symptoms are very similar to yours. J5, under this conditions, how do you get a backtrace? like Michal, I am unable to get a backtrace when I try to debug it with gdb.
> Michal, are you using VMWare? Nope! This is a regular installation on x86_64. Can you even run VMWare on that architecture (i.e. not as an x86 program)? I guess that in the light of the above I should change "Hardware" tag to "All".
(In reply to comment #2) > I guess that in the light of the above I should change "Hardware" tag to "All". Please do, I have found a bug report in upstream b.g.o identified as #324618: [] http://bugzilla.gnome.org/show_bug.cgi?id=324618 It seems to be the very same problem with the same version of g-v-m under PPC, so that's 3 archs already, he is using Yellow Dog Linux, compiled Gnome with GARNOME 2.13.3 and his installation is under /opt. He states that g-v-m 1.5.5 doesnt crash in his environment... see the bug report for a detailed backtrace.
Sent a patch upstream and building g-v-m into rawhide now. You can read the upstream link in comment #3 for details. This will fix the crash but I need to update HAL for it to start mounting again since hal now handles that. Please grab the new binaries tomorrow and tell me if it still crashes or not.
It does not crash for me anymore.
Yes, it doesn't crash for me any more either, now with VMWare when I hit "Install VMWare Tools..." from the menu it creates the virtual CD and the corresponding icon appears in the Gnome desktop automatically, when I cancel the installation, the CD is unmounted automatically too... so, the bug seems to be fixed, it all works perfectly now. Besides, the upstream bug was marked as fixed too. Thanks to everybody for the assistance.