Amends 65093a84c2, 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.9 6.8
Change-Id: Ie294dce7263b4189f89ffffd9155ec71d31b89d9
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
1da7558bfd