Another update: This is not an fsync() race after all. The /uevent files it tries to read already exist and can be successfully read in a previous event. I adjusted the libudev debugging to http://paste.ubuntu.com/7747163/ and umockdev's to http://paste.ubuntu.com/7747174/ to get a non-overwhelming debug output, and still run the test like
With that, a "normal" event processing looks like that: libudev: udev_monitor_receive_device: udev_monitor_receive_device: start libudev: udev_device_read_uevent_file: reading /sys/devices/card2/uevent testbed wrapped fopen(/sys/devices/card2/uevent) -> /tmp/umockdev.YI7DIX/sys/devices/card2/uevent libudev: udev_device_read_uevent_file: line DEVTYPE=drm_minor libudev: udev_monitor_receive_device: udev_monitor_receive_device: success But I also see ones that look like that: libudev: udev_monitor_receive_device: udev_monitor_receive_device: start libudev: udev_device_read_uevent_file: reading /sys/devices/card2/uevent testbed wrapped fopen(/sys/devices/card2/uevent) -> /tmp/umockdev.YI7DIX/sys/devices/card2/uevent libudev: udev_device_new_from_syspath: device 0x7f2208001be0 has devpath '/devices/card2' libudev: udev_device_read_uevent_file: reading /sys/devices/card2/uevent testbed wrapped fopen(/sys/devices/card2/uevent) -> /tmp/umockdev.YI7DIX/sys/devices/card2/uevent libudev: udev_device_read_uevent_file: line DEVTYPE=drm_minor libudev: udev_device_read_uevent_file: line DEVTYPE=drm_minor libudev: udev_monitor_receive_device: udev_monitor_receive_device: success and for a failing case: ibudev: udev_monitor_receive_device: udev_monitor_receive_device: start libudev: udev_device_read_uevent_file: reading /sys/devices/card2/uevent testbed wrapped fopen(/sys/devices/card2/uevent) -> /tmp/umockdev.YI7DIX/sys/devices/card2/uevent libudev: udev_device_new_from_syspath: device 0x7f2208001be0 has devpath '/devices/card2' libudev: udev_device_read_uevent_file: reading /sys/devices/card2/uevent testbed wrapped fopen(/sys/devices/card2/uevent) -> /tmp/umockdev.YI7DIX/sys/devices/card2/uevent libudev: passes_filter: passes_filter: monitor filters on DEVTYPE=drm_minor, but device does not have DEVTYPE libudev: udev_monitor_receive_device: udev_monitor_receive_device: failed filter test, discarding libudev: udev_device_read_uevent_file: line DEVTYPE=drm_minor libudev: udev_device_read_uevent_file: reading /sys/devices/card2/uevent testbed wrapped fopen(/sys/devices/card2/uevent) -> /tmp/umockdev.YI7DIX/sys/devices/card2/uevent libudev: udev_device_read_uevent_file: line DEVTYPE=drm_minor libudev: udev_monitor_receive_device: udev_monitor_receive_device: success So the really strange thing is that there are often multiple parallel runs of these functions, like if udev_monitor_receive_device() was being called in parallel. I wonder if that's related to the test having three threads, so that the display's configuration handler monitor somehow also runs in the "t" and "watchdog" threads? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1336671 Title: Intermittent mir_unit_tests.MesaDisplayTest.drm_device_change_event_triggers_handler test failure: device DEVTYPE is sometimes NULL To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1336671/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
