Comment 9 for bug 441088

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.