Description
Copying my Discord post verbatim:
There's something fucked up with Qt 6.9.0 that I can't explain. If you try to stop a program while an inference is running, there's a good chance it will hang.
Reproduce steps:
- Compile latest on Qt 6.9.0.
- Run the Watt Farmer with no program open.
- Wait until the program appears to get stuck trying to enter game.
- Click "Stop Program". The program will never stop and just hangs on "Stopping program".
When I try to follow the wait chain, it doesn't make sense. The thread that it's waiting on is our thread, but the debugger is showing it as a Qt rendering thread.
When I put logs to track our thread that it was waiting on, it ends properly, but then the thread-id somehow gets (immediately) reused or reassigned to a Qt rendering thread that doesn't end. So when we try to join our thread, it's actually waiting for that Qt rendering thread forever.
It does not reproduce with an earlier build with Qt 6.8.3.
I'm going to rebuild latest with Qt 6.8.3 and see if it happens there.
Yup, no issue on Qt 6.8.3. I'll rebuild the latest release candidate with Qt 6.8.3.
I'm not satisfied with "just waiting for a newer Qt." The nature of this bug is really concerning as the thread ID gets immediately reassigned. This suggests that it is happening at the OS-level. But why does the Qt version matter? And why does it only happen with the specific thread being joined and the Qt rendering thread? The program makes a lot of other threads, yet it's only this pair that gets "merged".
This will not block v0.52.x release since I'm rolling it back to Qt 6.8.3. But it's very concerning nonetheless.