GNOME Bugzilla – Bug 340113
Mount CD (VCD)
Last modified: 2006-08-28 17:12:49 UTC
Distribution: Fedora Core release 5 (Bordeaux) Package: gnome-applets Severity: blocker Version: GNOME2.14.1 unspecified Gnome-Distributor: Red Hat, Inc Synopsis: Mount CD (VCD) Bugzilla-Product: gnome-applets Bugzilla-Component: drivemount Bugzilla-Version: unspecified BugBuddy-GnomeVersion: 2.0 (2.14.1) Description: Description of the crash: Unable to mount VCD Cd Steps to reproduce the crash: 1. Insert a VCD 2. 3. Expected Results: gnome-mount quit unexpectedly How often does this happen? Every time a VCD disk is inserted Additional Information: Debugging Information: Backtrace was generated from '/usr/bin/gnome-mount' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) `shared object read from target memory' has disappeared; keeping its symbols. (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208437072 (LWP 7415)] (no debugging symbols found) 0x003d5402 in __kernel_vsyscall ()
+ Trace 67910
Thread 1 (Thread -1208437072 (LWP 7415))
------- Bug created by bug-buddy at 2006-04-29 14:04 -------
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.
*** Bug 343636 has been marked as a duplicate of this bug. ***
*** Bug 344174 has been marked as a duplicate of this bug. ***
From (344174) Hope it helps. Nelson Backtrace was generated from '/usr/bin/gnome-mount' Using host libthread_db library "/lib/libthread_db.so.1". `shared object read from target memory' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1208699200 (LWP 12581)] 0x001e7402 in __kernel_vsyscall ()
+ Trace 68712
Thread 1 (Thread -1208699200 (LWP 12581))
*** Bug 344486 has been marked as a duplicate of this bug. ***
Re-opening due to extra info in comment 4 (thanks!). Also, FWIW, steps to reproduce from bug 344486: Steps to reproduce the crash: 1. Insert "Group Therapy" by Dope (barcode 6 99675 12572 1, there's a couple versions of it and I just have the one) 2. See the dialog come up asking what to do. Leave "every time" checkbox unchecked, click "Browse folders" 3. Get the exception.
Here is a debug trace from my system using "Group Therapy":
+ Trace 68768
Thread 1 (Thread -1209096512 (LWP 18141))
I am also including some messages from /var/log/messages, as there is information in there which is probably relevant. It is quite long so I'll post it as an attachment "messages_crash_during_group_therapy_vcd_insert.txt"
Created attachment 67084 [details] Messages log during insert of subject VCD This is from /var/log/messages during an insert of the VCD.
*** Bug 344492 has been marked as a duplicate of this bug. ***
These crashes are in gnome-mount, reassigning to what I think is the correct component.
Same here, after inserting audio disk with VCD video as track 14 (Blade Loki "...no pasaran") and clicking "browse files". Bug Buddy was very helpful and searched and found this bug, so I just paste my backtrace here, maybe to make it not "UNCORFIRMED".
Created attachment 67486 [details] bt
Oops, I reported this "downstream" for Fedora Core: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195863 Anyway, I had a look at the code. The problem seems to be (in almost all cases, as far as I can see) a NULL dereference of the variable "fstype" in the code: if (strcmp (fstype, "vfat") == 0) fstype is derived with this code: fstype = libhal_volume_get_fstype (volume); But libhal_volume_get_fstype() actually does nothing more than to return volume->fstype, and is therefore not safe from returning NULL. (Other code in hal also knows this and checks for return value != NULL. Actually, some code I found in HAL actually _fails_ to check this, but I may have been looking at an old revision. ;-> ) Please fix, this is bugging hundreds of people (tens of bug reporters)!
See also gdb backtraces at https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=195863 One is from an attempt to mount a CD with an hfsplus file system on it (definitely not defective and mounts without any issues if gnome-mount is not used) and another one resulted from a DVD with "some problems".
Should be fixed in CVS. Otherwise please reopen.
The fix mentioned in comment #15 appears to consist from 'if (fstype != NULL) { ... }' check before 'fstype' is used by 'strcmp()'. Does NULL is really a valid 'fstype' value at this point? Because gnome-mount patched that way does now for me "Cannot mount volume" with a perfectly mountable CD. Is this a different bug? From some POV one could replace gnome-mount code with 'int main() {return 0;}'. Does roughly the same thing, is much simpler and surely it does not segfault. :-)
This fix works for me (comment #13), where I have an invalid medium in the drive. I agree though with comment #16 that the fix is not sufficient for the failures with valid media. But this goes in libhal function debugging and I'm not keen on looking into that code. ;-) (The fix you made should be in gnome-mount nevertheless until all these functions are safe from returning NULL pointers.)
Sigh, Michal, we meet again, this time in a different bug tracker > Because gnome-mount patched that way does now > for me "Cannot mount volume" with a perfectly mountable CD. > Is this a different bug? You know, it would be useful if you could provide the following information 1. Information about your "perfectly mountable CD," including output of lshal when it's inserted into an optical drive. My guess is that it's a Apple HFS+ optical disc and due to the braindeadness of how Linux handle optical discs (no multi-session / multi-partition code) we don't really support this yet. I could be wrong though. 2. Whether this is the case on all optical discs. For example does a normal Fedora install CD automount. > From some POV one could replace gnome-mount code with > 'int main() {return 0;}'. Does roughly the same thing, is > much simpler and surely it does not segfault. :-) Hah hah. No, seriously, comments like these are not getting your bugs fixed any faster :-)
> 1. Information about your "perfectly mountable CD," including > output of lshal when it's inserted into an optical drive. I believe this bug refers to Video CD's, music + videos. Not sure what the Apple format is you're talking about though (probably the same thing). > 2. Whether this is the case on all optical discs. For example > does a normal Fedora install CD automount. Normal 'data only' CD discs mount fine. Pure music CD's play without mounting fine for me. The only trouble I have is with the VCDs that has both music and MOV files ("Group Thereapy" by Dope and I just checked an old "Killers" disc by Iron Maiden). The latter is a more general mixed-mode with Win32 exe's, images, etc. etc. I did a lshal and it returned a TON of information, most of which I'm pretty sure isn't germaine. However, there does seem to be some interconnectedness (is that a word?) in some of the layers so I'll include all rather than clip something important.
Created attachment 67852 [details] Full "lshal" output when a VCD disc is in the drive This is the full text of the lshal output when the "Group Therapy" disc by Dope is inserted. This disc is a mixed-mode music + data (videos).
I comment #18 David Zeuthen wrote: > My guess is that it's a Apple HFS+ optical disc and due > to the braindeadness of how Linux handle You are partially correct. No, this is not an optical disc. This is just a plain data CD which reports 536M size (495M used). Indeed it has an hfsplus file system on it and it was written on Mac OS X. When mounted with 'mount -r /dev/hdc /mnt/cd', which does not have the slightest problems even without an explicit filesytem specification, it shows up in an output of 'mount' as: /dev/hdc on /mnt/cd type hfsplus (ro) Also properly configured autofs does not have the slightest issues with mounting and unmounting these media. So Linux does not seem to be particularly braindead here. I cannot tell anything about optical discs. I do not have such hardware. That volume shows up with an id of /org/freedesktop/Hal/devices/volume_part_1_size_561516544 and lshal has the following to say about it: udi = '/org/freedesktop/Hal/devices/volume_part_1_size_561516544' info.udi = '/org/freedesktop/Hal/devices/volume_part_1_size_561516544' (string) info.product = 'Volume' (string) volume.disc.capacity = 735051776 (0x2bd00000) (uint64) volume.disc.is_svcd = false (bool) volume.disc.is_vcd = false (bool) volume.disc.is_videodvd = false (bool) volume.disc.is_rewritable = false (bool) volume.disc.is_appendable = false (bool) volume.disc.is_blank = false (bool) volume.disc.has_data = true (bool) volume.disc.has_audio = false (bool) volume.disc.type = 'cd_r' (string) volume.size = 561516544 (0x21781000) (uint64) volume.num_blocks = 1096712 (0x10bc08) (int) volume.block_size = 2048 (0x800) (int) info.capabilities = {'volume', 'block'} (string list) info.category = 'volume' (string) volume.is_partition = true (bool) volume.is_disc = true (bool) volume.is_mounted = false (bool) volume.mount_point = '' (string) volume.label = '' (string) volume.uuid = '' (string) volume.fsversion = '' (string) volume.fsusage = '' (string) volume.fstype = '' (string) storage.model = '' (string) block.storage_device = '/org/freedesktop/Hal/devices/storage_model_LITE_ON_COMBO_SOHC_5232K' (string) block.is_volume = true (bool) block.minor = 0 (0x0) (int) block.major = 22 (0x16) (int) block.device = '/dev/hdc' (string) linux.hotplug_type = 3 (0x3) (int) info.parent = '/org/freedesktop/Hal/devices/storage_model_LITE_ON_COMBO_SOHC_5232K' (string) linux.sysfs_path_device = '/sys/block/hdc/fakevolume' (string) linux.sysfs_path = '/sys/block/hdc/fakevolume' (string) If you will mount it then, not so surprisingly, only 'volume.is_mounted' and 'volume.mount_point' change its value.
*** Bug 351800 has been marked as a duplicate of this bug. ***
*** Bug 353219 has been marked as a duplicate of this bug. ***