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 Desktop Packages, which is subscribed to umockdev in 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 Status in Mir: In Progress Status in “umockdev” package in Ubuntu: New Bug description: As seen in: http://s-jenkins.ubuntu-ci:8080/job/mir-clang-utopic- amd64-build/799/console To reproduce locally: bzr branch lp:mir/devel mir-devel && cd mir-devel mkdir build && cd build && cmake .. && make -j4 umockdev-wrapper bin/mir_unit_tests --gtest_filter=MesaDisplayTest.drm_device_change_event_triggers_handler --gtest_repeat=-1 --gtest_break_on_failure (Ignore the segfault when the test fails, it's a side effect of --gtest_break_on_failure) Running with strace or on a system with high load increases the chances that we hit the problem. For example, running make -j4 in another mir branch while running the tests does the trick for mir. To manage notifications about this bug go to: https://bugs.launchpad.net/mir/+bug/1336671/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
