Bug 195863 - gnome-mount segfaults on a CD insertion
gnome-mount segfaults on a CD insertion
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gnome-mount (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-18 18:26 EDT by Michal Jaegermann
Modified: 2013-03-05 22:45 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 12:00:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backported patch for fstype crash (from upstream CVS) (1.87 KB, patch)
2006-06-21 04:08 EDT, Moritz Barsnick
no flags Details | Diff

  None (edit)
Description Michal Jaegermann 2006-06-18 18:26:03 EDT
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.
Comment 1 Moritz Barsnick 2006-06-19 14:46:40 EDT
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
Comment 2 Moritz Barsnick 2006-06-19 14:57:15 EDT
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!
Comment 3 Moritz Barsnick 2006-06-21 04:08:16 EDT
Created attachment 131255 [details]
backported patch for fstype crash (from upstream CVS)
Comment 4 Moritz Barsnick 2006-06-21 04:40:33 EDT
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.
Comment 5 Michal Jaegermann 2006-06-21 16:20:09 EDT
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?
Comment 6 Moritz Barsnick 2006-06-22 09:29:58 EDT
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?
Comment 7 Bug Zapper 2008-04-03 23:06:39 EDT
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
Comment 8 Bug Zapper 2008-05-06 12:00:47 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.