You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recent CI fails because of data races under load showed that there were still many tests not behaving well in regards to thread safety (for example at merge of !5 and !6) and potentially there are many more.
While one can fix them one by one whenever a pipeline fails it would be better to check with a thread sanitizer. This would also prevent new data races from creeping in. A separate build is then needed because the thread sanitizer can't be used together with the others we currently employ.
The issue is: I tried this already and the method to check-wait with a signal spy on a signal being emitted seems to be inherently racy. It's always a read after write until the read is successful. I'm unsure how to solve that. Maybe a helper class with a mutex?
The text was updated successfully, but these errors were encountered:
The Plasma Window Model test seems to be especially problematic:
FAIL! : PlasmaWindowModelTest::testTitle() Compared values are not the same
Loc: [/home/roman/dev/kde/wrapland/src/autotests/client/test_plasma_window_model.cpp(648)]
FAIL! : PlasmaWindowModelTest::testAppId() Compared values are not the same
Loc: [/home/roman/dev/kde/wrapland/src/autotests/client/test_plasma_window_model.cpp(682)]
I could reproduce this locally when running the test through valgrind and having stress running for some time.
Removing the discussion label again and moving forward to execute. After all the goal is clear: test with thread sanitizer. If this is realized in the end by introducing mutex around every spy or something else is a technical implementation detail and if this needs discussion the issue can be moved back.
Recent CI fails because of data races under load showed that there were still many tests not behaving well in regards to thread safety (for example at merge of !5 and !6) and potentially there are many more.
While one can fix them one by one whenever a pipeline fails it would be better to check with a thread sanitizer. This would also prevent new data races from creeping in. A separate build is then needed because the thread sanitizer can't be used together with the others we currently employ.
The issue is: I tried this already and the method to check-wait with a signal spy on a signal being emitted seems to be inherently racy. It's always a read after write until the read is successful. I'm unsure how to solve that. Maybe a helper class with a mutex?
The text was updated successfully, but these errors were encountered: