An strace confirms that all three threads interact with libudev. That's bad as libudev is very far away from being thread safe. Only the main thread actually calls recvmsg(), i. e. udev_monitor_receive_device(). But the others do something as well. This isn't expected I figure, as at least the watchdog thread doesn't touch udev at all, and the "t" thread does not talk to libudev but only to umockdev. So *something* leaks into these threads which has no business there.
-- 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
