[asio] Boost-1.65.0 TlsSlot leak on win32
Hi,
I am using boost version 1.65.0 in a 32 bit DLL. I use VS2005
When using ApplicationVerifier, I got application verifier stops due to leaked TLS slots.
The TLS slots are allocated in win_tss_ptr_create(). Each slot is wrapped into RAII class win_tss_ptr. The constructor allocates the TLS slot and the destructor de-allocates it.
I put printf-Statements in both methods and I see, that the constructor is called twice, while the destructor is not called at all. If I put a breakpoint into the destructor, it never triggers.
The printf() satemets show, that the following instances have been constructed:
boost::asio::detail::win_tss_ptr
xxx.dll!boost::asio::detail::win_tss_ptr_create() Line 40 C++
xxx.dll!boost::asio::detail::win_tss_ptr
On 20/03/2018 05:08, Klebsch, Mario wrote:
I am using boost version 1.65.0 in a 32 bit DLL. I use VS2005
When using ApplicationVerifier, I got application verifier stops due to leaked TLS slots.
The TLS slots are allocated in win_tss_ptr_create(). Each slot is wrapped into RAII class win_tss_ptr. The constructor allocates the TLS slot and the destructor de-allocates it.
I put printf-Statements in both methods and I see, that the constructor is called twice, while the destructor is not called at all. If I put a breakpoint into the destructor, it never triggers.
How is your process exiting? Global destructors will only be called if execution leaves main/WinMain normally (without calling terminate, abort, _exit, TerminateProcess, throwing an exception, etc) -- and they'll (silently) stop being called if any destructor does throw an exception. Also, unless you are dynamically unloading and reloading the DLL (and dynamically unloading the DLL should trigger the destructors), a *small* TLS slot leak is not that important as they are destroyed when your process exits anyway -- despite annoying AppVerifier. The main thing the checks are there for are if you are leaking TLS slots each time you call a particular method or something.
Hi,
How is your process exiting? Global destructors will only be called if execution leaves main/WinMain normally (without calling terminate, abort, _exit, TerminateProcess, throwing an exception, etc) -- and they'll (silently) stop being called if any destructor does throw an exception.
The process does not terminate. It just unloads the DLL.
Also, unless you are dynamically unloading and reloading the DLL
That is what I (and our customer) is doing.
(and dynamically unloading the DLL should trigger the destructors),
That is what I think, too. I found, that _CRT_INIT() is called on load time to execute the constructors of global instances and that it is also called on unload time to execute destructors for global instances. I put a breakpoint into the loop calling the destructors at unload time, and stepped into each of them. I found a lot of global destructors called, some for my global instances, others for boost::asio and other boost internal instances. But the destructor for those two win_tss_ptr<> instances does not seem to be in the list of destructors to call. :-(
a *small* TLS slot leak is not that important as they are destroyed when your process exits anyway -- despite annoying AppVerifier. The main thing the checks are there for are if you are leaking TLS slots each time you call a particular method or something.
Our customer recently had a problem caused by a TLS slot leak in an old version of boost::thread. The customers application stopped working after about 50 minutes, just because a single TLS slot leaked on each library unload. 73, Mario
participants (2)
-
Gavin Lambert -
Klebsch, Mario