6dc19b55fc
Amends 65093a84c2b94b1543fd4593bc45d491951d28d4, which changed how we destroyed the main thread's QThreadData. This merges the call to destroy_current_thread_data() for both types of Unix systems: those with broken thread_local destructors and those with working ones. It turns out that the function got called too early for us in those working systems (see updated comment). The clean up of the QThreadData is split into two different mechanisms: * for any auxiliary thread, when it exits, PThread will call back to destroy_current_thread_data() * for the thread that called ::exit(), PThread won't, but ::exit() will invoke set_thread_data()::TlsKey's destructor This is different from the situation that existed prior to commit 65093a84c2b94b1543fd4593bc45d491951d28d4: first, there's no code in qcoreapplication.cpp for this (all in qthread_unix.cpp). Second one may call ::exit() from any thread, whether that is the thread that called main(), the thread Qt thinks is theMainThread, or any other. This commit moves the tst_QCoreApplication check for no extant objects to a new test. I've chosen to add a new test instead of running a helper binary via QProcess because we do have a couple of !QT_CONFIG(process) platforms in the CI, and this is too important. Credit to OSS-Fuzz for finding this, though it is not itself a fuzzying problem (all tests of a given structure were crashing on exit). Fixes: QTBUG-132381 Task-number: QTBUG-130895 Task-number: QTBUG-129927 Task-number: QTBUG-129846 Task-number: QTBUG-130341 Task-number: QTBUG-117996 Pick-to: 6.8 Change-Id: Ie294dce7263b4189f89ffffd9155ec71d31b89d9 Reviewed-by: Robert Löhning <robert.loehning@qt.io> Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io> (cherry picked from commit 1da7558bfd7626bcc40a214a90ae5027f32f6c7f) Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>