diff options
author | Alexander Golubev <fatzer2@gmail.com> | 2024-03-16 08:31:50 +0300 |
---|---|---|
committer | TDE Gitea <gitea@mirror.git.trinitydesktop.org> | 2024-03-18 09:36:47 +0000 |
commit | b1e6f384640525c5a0caceef017848f8ebee46b8 (patch) | |
tree | 0503258437e109f568af20702e446fc092dc2555 /src/tools/qthreadstorage_unix.cpp | |
parent | bcda4011918a88064d35908b089a3300e187245a (diff) | |
download | tqt3-b1e6f384640525c5a0caceef017848f8ebee46b8.tar.gz tqt3-b1e6f384640525c5a0caceef017848f8ebee46b8.zip |
Fix TQThreadStorage destruction in the main thread
Before that the allocations of TQThreadStorage objects from the main
thread were never destroyed and memory associated with them were never
freed. The second one isn't a huge problem as at that point program is
terminating anyway (but it still makes valgrind complain). The first one
is the bigger issue as destructors might contain some essential external
cleanups like removing temporary files.
Also make `TQApplication::guiThread()` return `0` when the thread is
destroyed (may happen on the program exiting during destruction of
statics).
Signed-off-by: Alexander Golubev <fatzer2@gmail.com>
Diffstat (limited to 'src/tools/qthreadstorage_unix.cpp')
-rw-r--r-- | src/tools/qthreadstorage_unix.cpp | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/src/tools/qthreadstorage_unix.cpp b/src/tools/qthreadstorage_unix.cpp index d53f6fb6e..86192868e 100644 --- a/src/tools/qthreadstorage_unix.cpp +++ b/src/tools/qthreadstorage_unix.cpp @@ -38,6 +38,8 @@ #ifdef TQT_THREAD_SUPPORT +#include "ntqapplication.h" +#include "ntqthread.h" #include "qplatformdefs.h" #include "ntqthreadstorage.h" @@ -88,6 +90,21 @@ TQThreadStorageData::TQThreadStorageData( void (*func)( void * ) ) TQThreadStorageData::~TQThreadStorageData() { + // The Gui thread has static storage duration, TQThreadStorage are almost always static (it's + // technically possible to allocate those in the heap, but it's quite unusual). It's impossible + // to predict whichever of those one gets destroyed first, but usually it's a TQThreadStorage. + // In that case we have to do the cleanup of its storage ourself as it won't be possible after + // nullifying the destructor below. + TQThread *guiThread = TQApplication::guiThread(); + if (guiThread) { + TQThreadInstance *d = guiThread->d; + TQMutexLocker locker( d->mutex() ); + if (d->thread_storage && d->thread_storage[id]) { + thread_storage_usage[id].func( d->thread_storage[id] ); + d->thread_storage[id] = nullptr; + } + } + pthread_mutex_lock( &thread_storage_mutex ); thread_storage_usage[id].used = FALSE; thread_storage_usage[id].func = 0; |