GNOME Bugzilla – Bug 170910
gnome-vfs-daemon segfault
Last modified: 2005-07-02 12:25:41 UTC
Version details: 2.10.0-0ubuntu2 Distribution/Version: Ubuntu Hoary Having just moved across an IDE NTFS formatted drive from another computer to this machine and connected to the primary connector on the first IDE channel and with the cable select jumper setting (Linux is installed on an SATA drive which is the drive that I actually boot from) I booted up and noticed that my gnomevfs samba folder had disappeared from my desktop. Checking dmesg I noticed the following: gnome-vfs-daemo[6074]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6082]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6086]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6088]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6095]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6103]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6114]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6116]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6118]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6231]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6269]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6271]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6273]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6328]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 gnome-vfs-daemo[6336]: segfault at 0000000000000050 rip 0000002a957e1ba0 rsp 0000007fbffff218 error 4 Here's a backtrace: (gdb) r Starting program: /usr/lib/gnome-vfs2/gnome-vfs-daemon (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) [Thread debugging using libthread_db enabled] [New Thread 182931822432 (LWP 6345)] (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) libhal.c 911 : Error sending msg: No property info.category on device with id /org/freedesktop/Hal/devices/ide_0_0 Program received signal SIGSEGV, Segmentation fault.
+ Trace 57058
Thread 182931822432 (LWP 6345)
could you get a backtrace with libgnomevfs2-0-dbg installed ?
(gdb) r Starting program: /usr/lib/gnome-vfs2/gnome-vfs-daemon [Thread debugging using libthread_db enabled] [New Thread 182931822432 (LWP 6996)] libhal.c 911 : Error sending msg: No property info.category on device with id /org/freedesktop/Hal/devices/ide_0_0 Program received signal SIGSEGV, Segmentation fault.
+ Trace 57060
Thread 182931822432 (LWP 6996)
Created attachment 39057 [details] [review] Patch to fix this bug This patch was applied to the Ubuntu package, the submitter confirmed that it fixes the segfault. It's also pretty obvious.
Thanks for your bug report! This looks like a very sane addition, considering that hal_volume may actually be NULL. I wonder whether libhal_drive_policy_compute_icon_name may receive NULL as 2nd parameter. If not, we'd have to handle that case as well.
Hal code changed. Closing this one therefore.