Bug 195863
| Summary: | gnome-mount segfaults on a CD insertion | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> | ||||
| Component: | gnome-mount | Assignee: | David Zeuthen <davidz> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5 | CC: | mclasen, moritz, triage | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | bzcl34nup | ||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2008-05-06 16:00:49 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: | |||||||
| Attachments: |
|
||||||
I would like to add a "me too" on this one. I see exactly the same thing. (Also
check out #195406 and #189557. Quite old already. Time to go upstream!?) I'm
add ing my stuff here because this bug entry is the most concise one I've found.
I recently burnt a DVD too fast(?) and it turned out defective (my standalone
DVD player cannot access and play it properly, though it tries to read it).
When I insert this DVD into my drive, I get a popup telling me about an
unexpected crash of gnome-mount.
gnome-mount version is 0.4-5.
Debugging: Pretty much the same result as above:
1.) Text-mode:
barsnick@sunshine:~ > gnome-mount -d /dev/hda -t
gnome-mount 0.4
Segmentation fault
2.) gdb:
barsnick@sunshine:~ > gdb gnome-mount
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db
library "/lib/libthread_db.so.1".
(gdb) set args -d /dev/hda -t
(gdb) run
Starting program: /usr/bin/gnome-mount -d /dev/hda -t
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0x2e5000
[Thread debugging using libthread_db enabled]
[New Thread -1208109376 (LWP 23220)]
gnome-mount 0.4
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208109376 (LWP 23220)]
0x0804c32f in volume_mount (
udi=0x8174890 "/org/freedesktop/Hal/devices/volume_part_1_size_2048",
volume=0x8174f78, drive=0x0) at gnome-mount.c:644
644 } else if (strcmp (fstype, "vfat") == 0) {
(gdb) bt
#0 0x0804c32f in volume_mount (
udi=0x8174890 "/org/freedesktop/Hal/devices/volume_part_1_size_2048",
volume=0x8174f78, drive=0x0) at gnome-mount.c:644
#1 0x0804cdb4 in main (argc=1, argv=0x3) at gnome-mount.c:1698
#2 0x00ab5724 in __libc_start_main () from /lib/libc.so.6
#3 0x0804a6c1 in _start ()
(gdb) print fstype
$1 = 0x0
Looks like an illegal dereference of the var "fstype" despite it not having
been set.
Upstream CVS has a NULL dereference fix (in 1.18, see log http://cvs.gnome.org/
viewcvs/gnome-mount/src/gnome-mount.c?view=log), but seemingly for something
different - check diff: http://cvs.gnome.org/viewcvs/gnome-mount/src/gnome-
mount.c?r1=1.17&r2=1.18
More package versions, in case it helps:
barsnick@sunshine:~ > rpm -qa | grep -E "gnome-(mount|vfs)" | sort
gnome-mount-0.4-5
gnome-mount-debuginfo-0.4-5
gnome-vfs2-2.14.2-1
gnome-vfs2-devel-2.14.2-1
gnome-vfs2-smb-2.14.2-1
D'uh, should've checked earlier. Upstream bug report (with lots of dupes, but no resolution): http://bugzilla.gnome.org/show_bug.cgi?id=340113 Got a quick fix for us, perhaps? Thanks! Created attachment 131255 [details]
backported patch for fstype crash (from upstream CVS)
A fix is available upstream now. Look at the patch: http://cvs.gnome.org/viewcvs/gnome-mount/src/gnome- mount.c?r1=1.19&r2=1.20&sortby=date or in case bugzilla breaks that line again (why is there no preview function??): http://shurl.net/QB Download the patch: http://cvs.gnome.org/viewcvs/gnome-mount/src/gnome- mount.c?r1=1.19&r2=1.20&sortby=date&makepatch=1&diff_format=u http://shurl.net/QC Or check out the attached patch: I've back-ported (i.e. re-applied and unified) it to 0.4, and attached it in comment #3, attachment #131255 [details]. I have _not_ tested the patch yet, as I don't have access to my home FC5 machine before this evening. Please have someone reproduce, test, and fix this. Check out the (presumed) dupes already in bugzilla: bug #189557, #187427. I am afraid that after applying a simple guard from comment #3 (which is really an obvious "if fstype is NULL then do not bother with attempts to add some hardwired options") instead of crash I am seeing just "Cannot mount volume" and this disregards that tiny detail that my test volume is perfectly mountable. Another bug or the real problem is elsewhere and 'fstype' should not be NULL with a valid media? I totally agree with comment #5. Michal's question: > Another bug or the real problem is elsewhere and 'fstype' > should not be NULL with a valid media? is very valid IMO. Case not closed. Nevertheless, my case (as reported in comment #1) with _invalid_ media is indeed fixed as far as I'm concerned. I now get a popup "can't mount volume" (or something like that), the command line interface says: org.freedesktop.DBus.Error.UnknownMethod : Method "Mount" with signature "ssas" on interface "org.freedesktop.Hal.Device.Volume" doesn't exist I'll check back upstream and decline their fix, okay? Fedora apologizes that these issues have not been resolved yet. We're sorry it's taken so long for your bug to be properly triaged and acted on. We appreciate the time you took to report this issue and want to make sure no important bugs slip through the cracks. If you're currently running a version of Fedora Core between 1 and 6, please note that Fedora no longer maintains these releases. We strongly encourage you to upgrade to a current Fedora release. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained and closing them. http://fedoraproject.org/wiki/LifeCycle/EOL If this bug is still open against Fedora Core 1 through 6, thirty days from now, it will be closed 'WONTFIX'. If you can reporduce this bug in the latest Fedora version, please change to the respective version. If you are unable to do this, please add a comment to this bug requesting the change. Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we are following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. And if you'd like to join the bug triage team to help make things better, check out http://fedoraproject.org/wiki/BugZappers This bug is open for a Fedora version that is no longer maintained and will not be fixed by Fedora. Therefore we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen thus bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Description of problem: Insert a CD and see "gnome-mount quit unexpectedly" alert. That particular CD happens to have hfsplus type filesystem on it and mounts without any problems, and with expected filesytem, when using mount -r /dev/cdrom /some/mount/point With 'gnome-mount-debuginfo' installed bug-buddy produces the following backtrace: Backtrace was generated from '/usr/bin/gnome-mount' Using host libthread_db library "/lib64/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 46912496373552 (LWP 12416)] 0x0000003f63b0cc95 in waitpid () from /lib64/libpthread.so.0 #0 0x0000003f63b0cc95 in waitpid () from /lib64/libpthread.so.0 #1 0x0000003a20d57db7 in libgnomeui_segv_handle (signum=11) at gnome-ui-init.c:820 #2 <signal handler called> #3 0x0000000000404a7e in volume_mount ( udi=0x554ce0 "/org/freedesktop/Hal/devices/volume_part_1_size_561516544", volume=0x556810, drive=0x0) at gnome-mount.c:644 #4 0x000000000040537c in main (argc=1, argv=0x7fffffbf9cd8) at gnome-mount.c:1698 #5 0x0000003f62a1ce54 in __libc_start_main () from /lib64/libc.so.6 #6 0x00000000004032d9 in _start () #7 0x00007fffffbf9cc8 in ?? () #8 0x0000000000000000 in ?? () Thread 1 (Thread 46912496373552 (LWP 12416)): #0 0x0000003f63b0cc95 in waitpid () from /lib64/libpthread.so.0 No symbol table info available. #1 0x0000003a20d57db7 in libgnomeui_segv_handle (signum=11) at gnome-ui-init.c:820 estatus = 0 sa = {__sigaction_handler = {sa_handler = 0, sa_sigaction = 0}, sa_mask = {__val = {272350053928, 140737484134992, 272350025178, 140737484134992, 140737484134352, 5597000, 272349884237, 206158430240, 140737484134608, 140737484134384, 140737484134992, 5602320, 34359738368, 19327352823, 5590392, 108}}, sa_flags = 108, sa_restorer = 0x556744} pid = Going there with gdb we see: (gdb) where #0 0x0000003f63b0cc95 in waitpid () from /lib64/libpthread.so.0 #1 0x0000003a20d57db7 in libgnomeui_segv_handle (signum=11) at gnome-ui-init.c:820 #2 <signal handler called> #3 0x0000000000404a7e in volume_mount ( udi=0x554ce0 "/org/freedesktop/Hal/devices/volume_part_1_size_561516544", volume=0x556810, drive=0x0) at gnome-mount.c:644 #4 0x000000000040537c in main (argc=1, argv=0x7fffffbf9cd8) at gnome-mount.c:1698 #5 0x0000003f62a1ce54 in __libc_start_main () from /lib64/libc.so.6 #6 0x00000000004032d9 in _start () #7 0x00007fffffbf9cc8 in ?? () #8 0x0000000000000000 in ?? () (gdb) list gnome-mount.c:644 639 /* volume from a non-pollable drive, just set uid.. */ 640 641 snprintf (uidbuf, sizeof (uidbuf) - 1, "uid=%u", getuid ()); 642 g_ptr_array_add (options, uidbuf); 643 644 } else if (strcmp (fstype, "vfat") == 0) { 645 /* 646 * Ugh, flush is not upstream yet.. better not add it... 647 * 648 if (opts & MOUNT_FLUSH) (gdb) p fstype $1 = 0x0 SIGSEGV is clearly the only reasonable response in that moment. Version-Release number of selected component (if applicable): gnome-mount-0.4-5 and gnome-mount-0.4-7 from rawhide How reproducible: Always with the right CD.