Do you have windows machine/will to investigate windows problem, or would you like for someone else to take over?

Do you have windows machine/will to investigate windows problem, or would you like for someone else to take over?

I don't have a Windows machine. I only investigate Github Actions. I can only reproduce in resource_thread::test_exit release build on ver1.79&1.80. I would take me a lot of time to fix, as it is too difficult to reproduce in debug build. I would like to request a takeover.

https://github.com/Hmikihiro/servo/actions/runs/10181674109

as it is too difficult to reproduce in debug build

Are you saying that debug builds works, but release don't?

I can only reproduce in resource_thread::test_exit release build on ver1.79

So 1.79 is bad?

Are you saying that debug builds works, but release don't?

Yes, I do. In debug build worked also warning are not occur.

So 1.79 is bad?

Yes, in my view, 1.79 is bad around resource_thread::test_exit.

nightly-2024-04-05 is good
nightly-2024-04-07 is good
nightly-2024-04-08 is bad
nightly-2024-04-09 is bad
nightly-2024-04-10 is bad
nightly-2024-04-14 is bad

I suspect rust-lang/rust#122268 also related: rust-lang/rust#116900

I did multiple runs to make get confidence in results (as this is flaky error).

I used cargo-bisect-rustc and here is the report https://github.com/sagudev/servo/actions/runs/10205095025/job/28235104802#step:14:92168

Apparently caused by rust-lang/rust@6f83750, I believe it's caused by rust-lang/rust#119224

I think this happens because we panic in drop of OsIpcReceiverSet, (it's actually panic while panic), but this is in separate thread. While before this was visible rarely (we have retry 3 on unit-tests), but now rust-lang/rust#119224 causes main test thread to wait for panic_hook to not be used (so it can be freed), so this panic is visible way more often (as it actually finishes in time).

🔨 Triggering try run (#10217246405) for Windows

✨ Try run (#10217246405) succeeded.

I think this happens because we panic in drop of OsIpcReceiverSet, (it's actually panic while panic), but this is in separate thread. While before this was visible rarely (we have retry 3 on unit-tests), but now rust-lang/rust#119224 causes main test thread to wait for panic_hook to not be used (so it can be freed), so this panic is visible way more often (as it actually finishes in time).

I believe panic in panic being a hard unrecoverable abort is intentional in newer rustc versions. So I suspect we'll need to change the code to not do that.

I think this happens because we panic in drop of OsIpcReceiverSet, (it's actually panic while panic), but this is in separate thread. While before this was visible rarely (we have retry 3 on unit-tests), but now rust-lang/rust#119224 causes main test thread to wait for panic_hook to not be used (so it can be freed), so this panic is visible way more often (as it actually finishes in time).

I believe panic in panic being a hard unrecoverable abort is intentional in newer rustc versions. So I suspect we'll need to change the code to not do that.

The problem is that we panic in the first place (both panics actually happens in same place if I am reading traces correctly). Anyway given that we have workaround for #32912 (which is just sleeping to wait for transmission to finish, as the code that checks for transmission finish is panicking), I think we do not need to block landing this PR on #32912.