Description of problem: Jun 7 19:53:06 host kernel: gvfsd-computer[10543]: segfault at 0 ip 0033c9b3 sp bfc22db8 error 4 in libc-2.10.1.so[2c4000+16b000] Version-Release number of selected component (if applicable): gvfs-1.2.3-2.fc11.i586 How reproducible: Always Additional info: ltrace shows: strchr("Generic- MS/MS-Pro", '/') = "/MS-Pro" strchr("Generic- MS\\MS-Pro", '/') = NULL g_strconcat(0x9a97cd0, 0x80614d4, 0, 0x8053223, 0x9a89b20) = 0x9a978f8 g_free(0x9a97cd0, 0x80614d4, 0, 0x8053223, 0x9a89b20) = 0 g_drive_get_name(0x9a92490, 0x80614d4, 0, 0x8053223, 0x9a89b20) = 0x9a97cd0 g_volume_get_name(0x9aa4c30, 0x80614d4, 0, 0x8053223, 0x9a89b20) = 0x9a97af0 g_strdup_printf(0x80614cd, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 0x9a97d50 g_free(0x9a97af0, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 0x9a97ad8 g_free(0x9a97cd0, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 0 g_volume_get_icon(0x9aa4c30, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 0x9a89230 g_volume_can_mount(0x9aa4c30, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 1 g_volume_can_eject(0x9aa4c30, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 1 g_drive_get_name(0x9a92490, 0x9a97cd0, 0x9a97af0, 0x8053223, 0x9a89b20) = 0x9a97cd0 strchr("Generic- SD/MMC", '/') = "/MMC" strchr("Generic- SD\\MMC", '/') = NULL g_strconcat(0x9a97cd0, 0x80614d4, 0, 0x8053223, 0x9a89b20) = 0x9a97ce8 strcmp("Generic- MS\\MS-Pro.drive", "Generic- SD\\MMC.drive") = -1 g_free(0x9a97cd0, 0x9a97ce8, 0, 0x8053223, 0x9a89b20) = 0 g_drive_get_icon(0x9a924c8, 0x9a97ce8, 0, 0x8053223, 0x9a89b20) = 0x9a89180 g_drive_get_name(0x9a924c8, 0x9a97ce8, 0, 0x8053223, 0x9a89b20) = 0 g_drive_can_eject(0x9a924c8, 0x9a97ce8, 0, 0x8053223, 0x9a89b20) = 1 g_drive_get_name(0x9a924c8, 0x9a97ce8, 0, 0x8053223, 0x9a89b20) = 0 strchr(NULL, '/' <unfinished ...> --- SIGSEGV (Segmentation fault) --- +++ killed by SIGSEGV +++ Looks like the last strchr has a problem.
Can you please grab a backtrace according to instructions on this page: https://fedoraproject.org/wiki/StackTraces The backend will need to be started manually by `GVFS_DEBUG=1 /usr/libexec/gvfsd-computer`. Be sure to kill old instance of gvfsd-computer first.
$ LC_ALL=C GVFS_DEBUG=1 gdb /usr/libexec/gvfsd-computer ... (gdb) run Starting program: /usr/libexec/gvfsd-computer [Thread debugging using libthread_db enabled] Added new job source 0x8074010 (GVfsBackendComputer) Queued new job 0x8075818 (GVfsJobMount) Program received signal SIGSEGV, Segmentation fault. strchr () at ../sysdeps/i386/strchr.S:127 127 ../sysdeps/i386/strchr.S: No such file or directory. in ../sysdeps/i386/strchr.S Current language: auto; currently asm (gdb) bt #0 strchr () at ../sysdeps/i386/strchr.S:127 #1 0x0804eba3 in convert_slashes (str=<value optimized out>) at gvfsbackendcomputer.c:219 #2 recompute_files (str=<value optimized out>) at gvfsbackendcomputer.c:475 #3 0x0804f180 in try_mount (backend=0x8074010, job=0x8075818, mount_spec=0x80716b0, mount_source=0x806a830, is_automount=0) at gvfsbackendcomputer.c:561 #4 0x08054dd5 in try (job=0x8075818) at gvfsjobmount.c:131 #5 0x08053f8d in g_vfs_job_try (job=0x8075818) at gvfsjob.c:216 #6 0x0804fc72 in g_vfs_daemon_queue_job (daemon=0x806b320, job=0x8075818) at gvfsdaemon.c:460 #7 0x08050143 in g_vfs_daemon_initiate_mount (daemon=0x806b320, mount_spec=0x80716b0, mount_source=0x806a830, is_automount=0, request=0x0) at gvfsdaemon.c:1066 #8 0x0804f80e in daemon_main (argc=1, argv=0xbffff474, max_job_threads=1, default_type=0x80614b4 "computer", mountable_name=0x0, first_type_name=0x80614b4 "computer") at daemon-main.c:287 #9 0x0804fb46 in main (argc=1, argv=0xbffff474) at daemon-main-generic.c:39
Current rawhide suffers from the same problem which prevents opening "Computer" window. Executing that directly does not seem to bring much of information: $ GVFS_DEBUG=1 /usr/libexec/gvfsd-computer Added new job source 0xb27040 (GVfsBackendComputer) Queued new job 0xb29000 (GVfsJobMount) Segmentation fault That seems be caused by floppy. Stopping a demented incessant floppy polling does not help very much. OTOH removal of a floppy module changes that picture: $ GVFS_DEBUG=1 /usr/libexec/gvfsd-computer Added new job source 0x1724040 (GVfsBackendComputer) Queued new job 0x1726000 (GVfsJobMount) send_reply, failed: 0 register_mount_callback, mount_reply: 0x17319c0, error: (nil) and this sits there until interrupted. Still after that a "Computer" window can be opened although, not surprisingly, floppy device is not there.
Thanks for the backtrace. Can you please attach output of `devkit-disks --dump`?
I'm unable to reproduce the issue on my machines, so I've prepared a testing build which I would like to ask you to try. Please download directly from Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=1418083 Now the `GVFS_DEBUG=1 /usr/libexec/gvfsd-computer` should give you verbose debug messages. Please also attach output of `gvfs-ls -hc computer:///`
gvfs-1.2.3-6.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/gvfs-1.2.3-6.fc11
F12 (rawhide) packages will follow soon, waiting for new gnome-disk-utility release. Upstream bug: https://bugzilla.gnome.org/show_bug.cgi?id=582772
gvfs-1.2.3-6.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.