In https://bugs.launchpad.net/bugs/899757 we get quite a few duplicates on a crash that looks like this:

#1  0xb74640b3 in g_log (log_domain=0x8072adb "udisks-daemon", log_level=G_LOG_LEVEL_ERROR, format=0x8078cac "**** HACK: Wanting to register object at path `%s' but there is already an object there. This is an internal error in the daemon. Aborting.\n") at /build/buildd/glib2.0-2.30.1/./glib/gmessages.c:591
        args = 0xbfe867ac "`hP\t"
#2  0x08068736 in register_disks_device (device=0x9504ff0) at device.c:1968
        error = 0x0
#3  device_new (daemon=0x94e4c10, d=0x94fa590) at device.c:5159
        device = 0x9504ff0
        native_path = <optimized out>
#4  0x080523d0 in block_device_add (emit_event=1, d=0x94fa590, daemon=0x94e4c10) at daemon.c:1340
        device = <optimized out>
        native_path = 0x94e2ef8 "/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.2/1-1.2:1.0/host7/target7:0:0/7:0:0:0/block/sdb"

(Full trace at https://launchpadlibrarian.net/86784583/Stacktrace.txt, but this is the essential part).

This happens when adding a new device, particular with devices which bounce a bit (i. e. you get several adds, removes, and changes before it stabilizes).

Unfortunately I cannot reproduce this myself with the devices I have, but a colleague of mine (Sebastien Bacher) can reproduce it very easily with his iPod.

After a few rounds of debugging I now understand what happens:

This seems to be related to media polling (we verified both in-kernel and udisks based polling trigger this, and cause the same uevents).

Correlating udev events and the corresponding udev debug output, we get:

UDEV [26112.066235] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/target29:0:0/29:
0:0:0/block/sdb/sdb1 (block)
--
**** REMOVING /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/target29:0:0/29:0:0:0/block/
sdb/sdb1
**** EMITTING REMOVED for /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/target29:0:0/29:
0:0:0/block/sdb/sdb1

UDEV [26112.067123] remove /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/target29:0:0/29:0:0:0/block/sdb (block)
--
**** REMOVING /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/target29:0:0/29:0:0:0/block/
sdb
**** EMITTING REMOVED for /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/target29:0:0/29:
0:0:0/block/sdb
**** scsi_host IGNORING REMOVE /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host29/scsi_host/h
ost29

Now we get a rather weird change uevent with a hilariously broken device path and device name, at a time when sdb is already gone!

UDEV [26112.087644] change /sdb (block)
ACTION=change
DEVNAME=/dev/sdb
DEVPATH=/sdb
DEVTYPE=disk
DISK_MEDIA_CHANGE=1
SUBSYSTEM=block
--
**** TREATING CHANGE AS ADD /sys/sdb
**** ADDING /sys/sdb
**** UPDATING /sys/sdb
**** ADDED /sys/sdb
**** EMITTING ADDED for /sys/sdb

Now we get a similar change event again, but this time WITHOUT DISK_MEDIA_CHANGE

UDEV [26112.102230] change /sdb (block)
ACTION=change
DEVNAME=/dev/sdb
DEVPATH=/sdb
DEVTYPE=disk
SUBSYSTEM=block
--
**** CHANGING /sys/sdb
**** UPDATING /sys/sdb
**** EMITTING CHANGED for /sys/sdb
**** CHANGED /sys/sdb

Now we get the device back:

UDEV [26123.419938] add /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host32/target32:0:0/32:0:0:0/block/sdb (block)
--
**** ADDING /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host32/target32:0:0/32:0:0:0/block/sdb
**** UPDATING /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/host32/target32:0:0/32:0:0:0/block/sdb

(udisks-daemon:24900): udisks-daemon-ERROR **: **** HACK: Wanting to register object at path `/org/freedesktop/UDisks/devices/sdb' but there is already an object there. This is an internal error in the daemon. Aborting.

So I think the problem is that the media polling for the /sdb device creates a device in udisks.

I tried for two hours to reproduce this using scsi_debug (ptype=5 for CD-ROM, or the default fake hard disk, with faking media polling), but without success. I'd like to write a test case for this, but for this to work we need to add the possibility of adding/removing media to scsi_debug. So for now we are stuck with real hw testing.