Disabling flaky test_pthread_cond_signal_1_1#13259
Conversation
| # Mark certain tests as flaky, which may sometimes fail. | ||
| # TODO invesigate these tests. | ||
| flaky = { | ||
| 'test_pthread_cond_signal_1_1': 'test has tight timing requirements, may fail when test suite is run in parallel', |
There was a problem hiding this comment.
In fact if you just make the string here "flaky: <bug_url>" you can put the rest of the details in the bug report rather than here.
There was a problem hiding this comment.
Ok, just to make things clear to me. You mean that I should file a bug as described here https://emscripten.org/docs/getting_started/bug_reports.html#bug-reports and then use URL of this newly reported bug? Or should I report this bug somewhere else?
|
Yes, file an emscripten bug called "test_pthread_cond_signal_1_1 is flaky", in which you can describe why it is flaky. Then if it ever gets fixed we can link it back to this disabled test. In our test code if often flag disabled python tests with "@disabled(<url_to_bug>)" so that anyone auditing the disabled tests can to the bug URL to get all the details and see its already been fixed. |
|
Another way of putting it: we don't ever want to disable tests without a bug filed so there can be path to re-enabling it. (Except of course for all the tests in this test suite that don't apply to emscripten.. we have no plans to fix those). |
|
Ok, thanks for explanation :) I'll file a bug and update review as suggested. |
73f8d9b to
08b74d0
Compare
|
@sbc done as suggested:
|
test_pthread_cond_signal_1_1 has very tight timing requirements, and expects that side threads will be woken and do some action in very short time. This causes occasional spurious fail of this test not because side thread(s) hasn't been woken by pthread_cond_signal, but because this threads hasn't been scheduled and hasn't get CPU on time. See emscripten-core#13283
08b74d0 to
712b97d
Compare
test_pthread_cond_signal_1_1 has very tight timing requirements, and
expects that side threads will be woken and do some action in very short
time. This causes occasional spurious fail of this test not because side
thread(s) hasn't been woken by pthread_cond_signal, but because this
threads hasn't been scheduled and hasn't get CPU on time.