Launchpad has imported 2 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=48173.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2012-04-02T07:43:30+00:00 Martin Pitt wrote: 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. Reply at: https://bugs.launchpad.net/udisks/+bug/899757/comments/14 ------------------------------------------------------------------------ On 2012-04-02T07:49:26+00:00 Martin Pitt wrote: I'll have Sebastien test a potential patch, I'll submit it here if that is successful. I also asked him to test with udisks2, so that it doesn't get the same problem all over again. I am not sure whether this is to be considered a kernel bug (sending media change uevents after a device is removed, especially with bogus device paths), but they might be useful for other purposes or hard to avoid. Within udisks, I see two options to fix this: * Drop the "treating change as add" logic. In all my experiments and log files I created for this bug I never saw a situation where a device got added without an "add" event, even with the worst bouncing. I. e. we could just simply ignore change events on nonexisting devices. My gut feeling is that this is the "more" correct approach, and certainly the one we should pursue in udisks2 (if it is affected in the first place). * Add a plausibility check to add/change events, to ensure that the native path actually exists before we create an object for it. That's what I'm currently testing. It's much less intrusive and much safer than the first option, so it's appropriate for the udisks1 branch. Reply at: https://bugs.launchpad.net/udisks/+bug/899757/comments/15 ** Changed in: udisks Status: Unknown => In Progress ** Changed in: udisks Importance: Unknown => High -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/899757 Title: udisks-daemon assertion error: HACK: Wanting to register object at path `%s' but there is already an object there. To manage notifications about this bug go to: https://bugs.launchpad.net/udisks/+bug/899757/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
