Flaky test: test_pthread_proxying_cpp

[RReverser]

Looks like test_pthread_proxying_cpp is flaky on the CI too, probably similar to #18307 / #18314.

[RReverser]

Probably related to #16569 too, although there it was reported only to hang with wasm2js. cc @tlively

[tlively]

Thanks, taking a look now.

[kleisauke]

Interesting, so assuming this is related to these linked issues, it also affects Node.js and the new proxying API.

Perhaps we could experiment with removing those std::cout calls (to make sure it doesn't conflict with the printf-locks introduced in commit fdd486f)?

[RReverser]

(to make sure it doesn't conflict with the printf-locks introduced in commit fdd486f)?

@kleisauke Interesting catch. It started failing pretty suddenly and pretty frequently, so a recent change being a culprit seems likely.

[kleisauke]

FWIW, issue #16136 was the first one that reported this flaky behavior, a couple months after that commit was landed. At the time, I thought it only affected the browser tests (unfortunately, all those CI logs disappeared due to the retention time on CircleCI).

[kleisauke]

Given these tests started to fail more frequently, it could also be related to commit a37b4b2 and/or the current libc.need_locks logic.

I once had a idea to do this during compile-time, see for e.g. commit 27c2a3a. However, I abandoned it because that could lead to redundant file locking if no pthreads are running. Although in retrospect, I think this could resolve a similar issue in the Wasm Workers API (which I reproduced in PR #18201).

[kleisauke]

... let me know if help is needed with testing/implementation. Note that the above assumptions were made for triage purposes (and given that race conditions/deadlocks are generally difficult to debug).

[tlively]

I assume that this is due to my change to this test a few days ago (#18350), and not anything to do with musl or other system libraries.

[RReverser]

Whew, I started worrying this is due to my recent changes to Node.js pthreads.

[sbc100]

Interesting, so assuming this is related to these linked issues, it also affects Node.js and the new proxying API.

Perhaps we could experiment with removing those std::cout calls (to make sure it doesn't conflict with the printf-locks introduced in commit fdd486f)?

BTW a good way to avoid the C stdio subsystem completely in such tests its to use emscripten_log and/or emscripten_err which are defined in <emscripten/console.h>