devkit-disks-part-id crashed with SIGSEGV in v4l1_open()

[D. Wegener]

Binary package hint: devicekit-disks

Error received when upgrading from jaunty to karmic

ProblemType: Crash
Architecture: i386
Date: Fri Oct 2 23:25:40 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /lib/udev/devkit-disks-part-id
NonfreeKernelModules: nvidia
Package: devicekit-disks 007-0ubuntu1
ProcCmdline: /lib/udev/devkit-disks-part-id /dev/block/8:21
ProcEnviron:

ProcVersionSignature: Ubuntu 2.6.28-15.52-generic
SegvAnalysis:
 Segfault happened at: 0xb7c6b25a <v4l1_open+57>: repz cmpsb %es:(%edi),%ds:(%esi)
 PC (0xb7c6b25a) ok
 source "%es:(%edi)" (0xb7c6c305) ok
 destination "%ds:(%esi)" (0x0000007b) not located in a known VMA region (needed writable region)!
SegvReason: writing NULL VMA
Signal: 11
SourcePackage: devicekit-disks
StacktraceTop:
 v4l1_open (file=0x0, oflag=0) at libv4l1.c:265
 open () from /usr/lib/libv4l/v4l1compat.so
 ?? ()
 __libc_start_main () from /lib/tls/i686/cmov/libc.so.6
 ?? ()
Title: devkit-disks-part-id crashed with SIGSEGV in v4l1_open()
Uname: Linux 2.6.28-15-generic i686
UserGroups:

[Apport retracing service (apport)]

StacktraceTop:?? ()
open (file=0x0, oflag=0) at v4l1compat.c:60
main (argc=2, argv=0xbff57ab4)

[Martin Pitt (pitti)]

Thanks for your report. This looks like a "should not happen (TM)" situation. Can you reproduce this by running

  sudo /lib/udev/devkit-disks-part-id /dev/block/8:21

? Does that crash, or give you some output? (Please just copy&paste the entire output here if you are unsure). Can you please also do

  devkit-disks --dump > /tmp/dkd.txt
  udevadm info --export-db > /tmp/udev.txt

and attach /tmp/dkd.txt and /tmp/udev.txt here?

Thanks!

Note to self: This happens because udev_device_get_devnode (device) == NULL, with device being a valid udev_device from a valid drive sysfs path.

[D. Wegener (dpwegener)]

Here is the output for devkit-disks-part-id:
sudo /lib/udev/devkit-disks-part-id /dev/block/8:21
Entering MS-DOS parser (offset=0, size=120034123776)
MSDOS_MAGIC found
looking at part 0 (offset 32256, size 254951424, type 0x83)
new part entry
looking at part 1 (offset 254983680, size 119776527360, type 0x05)
Entering MS-DOS extended parser (offset=254983680, size=119776527360)
readfrom = 254983680
MSDOS_MAGIC found
readfrom = 254984192
MSDOS_MAGIC found
readfrom = 4252469760
MSDOS_MAGIC found
Exiting MS-DOS extended parser
looking at part 2 (offset 0, size 0, type 0x00)
new part entry
looking at part 3 (offset 0, size 0, type 0x00)
new part entry
Exiting MS-DOS parser
MSDOS partition table detected
DKD_PARTITION=1
DKD_PARTITION_SCHEME=mbr
DKD_PARTITION_NUMBER=5
DKD_PARTITION_TYPE=0x83
DKD_PARTITION_SIZE=99772614144
DKD_PARTITION_LABEL=
DKD_PARTITION_UUID=
DKD_PARTITION_FLAGS=

[D. Wegener (dpwegener)]

Ouput to commands attached. During the upgrade process from Jaunty to Karmic, I couldn't get my system to boot and performed a clean install of Karmic. This completely changed my partitions defined/used on my hard drives. This output is based on the current configuration of the hardisks. I don't remember if the reported crash occurred before or after the clean install, so this data may not reflect the state of the system when the crash occurred.

Previously, I had logical volumes for my file systems. Now, I have standard partitions.

[Martin Pitt (pitti)]

We got a report about dk-disks-part-id crashing during a distribution release upgrade:

#0 0xb7c6b25a in ?? ()
No symbol table info available.
#1 0xb7f34900 in open (file=0x0, oflag=0) at v4l1compat.c:60
 fd = 0
#2 0x08049afd in main (argc=2, argv=0xbff57ab4)
    at /usr/include/bits/fcntl2.h:54
 n = <value optimized out>
 fd = <value optimized out>
 partition_number = 5
 devpath = <value optimized out>
 device_file = <value optimized out>
 partition_table_device_file = (gchar *) 0x0
 udev = (struct udev *) 0x9e0d790
 partition_table = (PartitionTable *) 0x0

This happens in src/part-id.c:

        fd = open (partition_table_device_file, O_RDONLY);

As seem from the trace above, the partition_table_device_file is NULL.

This happens if there is a valid partition number (sda5 in that case), and the partition_table_devpath loop was successful in determining the drive from the partition (sda), but udev_device_get_devnode("sda") returns NULL.

This "Should Not Happen", since if you have a valid /dev/sda5 you also ought to have a valid /dev/sda. I had the original reporter confirm that in a running system, "sudo /lib/udev/devkit-disks-part-id /dev/block/8:21" works just fine, so it's not generally broken, but a glitch during a distribution upgrade, when udev/dk-disks/etc. all get upgraded, and are in a state of flux.

So this is a very low-profile crash, and I propose to just handle this unsual situation gracefully in part-id instead of crashing.

[Martin Pitt (pitti)]

Created an attachment (id=30281)
git formatted patch

[Martin Pitt (pitti)]

Thanks. The devkit-disks-part-id output looks fine now, so it's not generally broken but it looked like an upgrade glitch. We did not receive any duplicates either.

So I don't think that there's a fundamental bug to fix here, the part-id program should just intercept this corner case and handle it gracefully. I'll propose a patch upstream.

[Martin Pitt (pitti)]

Patch sent to upstream for review.

[Zeuthen (zeuthen)]

Committed, thanks!

[Martin Pitt (pitti)]

Fixed in 009 in lucid.