-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test_pthread_abort is failing on macOS & flaky on linux #15014
Comments
Seeing this flake on linux too: https://logs.chromium.org/logs/emscripten-releases/buildbucket/cr-buildbucket/8828967471954354369/+/steps/Emscripten_testsuite__AddressSanitizer_/0/stdout
|
Still flaky: https://circleci.com/gh/emscripten-core/emscripten/626723. This might be a race condition between the Lines 435 to 439 in aef5d39
And when it throws this exception: Lines 491 to 494 in aef5d39
This would be fine on the main runtime thread, but when emscripten/src/library_pthread.js Lines 347 to 356 in aef5d39
Lines 160 to 162 in aef5d39
So, it might be possible that the pthread propagated the uncaught exception back to the main thread before the |
This change is designed fix address pthread thread flakiness around process termination. For example see #19683 and #15014. In some cases I believe that workers are being terminated while they have postMessage messages in their queue, so messages are getting lost. In other cases we are seeing message arrive after the call to `terminate()`. This change attempts to avoid using `terminate()` at all and attempts to cooperatively shut down the worker. We only use `terminate()` if the thread doesn't respond in a certain amount of time.
This change is designed fix address pthread thread flakiness around process termination. For example see #19683 and #15014. In some cases I believe that workers are being terminated while they have postMessage messages in their queue, so messages are getting lost. In other cases we are seeing message arrive after the call to `terminate()`. This change attempts to avoid using `terminate()` at all and attempts to cooperatively shut down the worker. We only use `terminate()` if the thread doesn't respond in a certain amount of time.
This change is designed fix address pthread thread flakiness around process termination. For example see #19683 and #15014. In some cases I believe that workers are being terminated while they have postMessage messages in their queue, so messages are getting lost. In other cases we are seeing message arrive after the call to `terminate()`. This change attempts to avoid using `terminate()` at all and attempts to cooperatively shut down the worker. We only use `terminate()` if the thread doesn't respond in a certain amount of time.
Its not clear what changed but this test recently started failing more consistently:
https://chromium-review.googlesource.com/c/emscripten-releases/+/3151159
https://ci.chromium.org/ui/p/emscripten-releases/builders/try/mac/b8836587739777488289/overview
The text was updated successfully, but these errors were encountered: