Opened 5 years ago
Last modified 5 years ago
#13008 new Bugs
[windows][Visual Studio compiler] Building Boost Thread with /GL causes leak in boost::thread_specific_ptr
| Reported by: | Owned by: | Anthony Williams | |
|---|---|---|---|
| Milestone: | To Be Determined | Component: | thread |
| Version: | Boost 1.64.0 | Severity: | Optimization |
| Keywords: | Cc: |
Description
When Boost Thread is build using the Visual Studio compiler with the optimization flag /GL ("Whole Program Optimization") added, and when a program links statically against Boost Thread for release builds, instances of boost::thread_specific_ptr don't call the cleanup function for object instances in other threads when threads have been started via windows API (not using boost::thread). The problem occurs for both 32-bit and 64-bit systems, and has been observed on Windows 7 and Windows 10, and for both auto-linking and not auto-linking situations.
How to reproduce:
a) Build the relevant Boost libraries using the following command:
b2 --build-dir="%TMP%" toolset=msvc-14.1 --with-thread --with-system --with-date_time --with-atomic address-model=32 link=static,shared variant=release asynch-exceptions=on extern-c-nothrow=off rtti=on optimization=speed cxxflags="/GL" linkflags="/LTCG:incremental" --stagedir=C:\SomePath --compiler="C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.10.25017\bin\HostX64\x64\cl.exe"
b) Build statically against the following translation unit in release mode and run the program:
#include <iostream>
#include "boost/config.hpp"
#include "boost/thread/tss.hpp"
#include "boost/atomic.hpp"
#if !defined(BOOST_HAS_WINTHREADS)
# error Windows platform required
#endif
#include <windows.h>
// Uncomment to activate IO output for debugging purposes:
#define BDAL_USE_IO_OUTPUT
typedef int atomic_int_underlying_type;
typedef boost::atomic<bool> atomic_bool_type;
typedef boost::atomic<atomic_int_underlying_type> atomic_integral;
atomic_integral instance_counter(0);
atomic_bool_type test_result(false);
struct InstanceCountingClass
{
InstanceCountingClass()
{
++instance_counter;
#ifdef BDAL_USE_IO_OUTPUT
std::cout << "[InstanceCountingClass] default c'tor" << std::endl;
#endif
}
InstanceCountingClass(const InstanceCountingClass&)
{
++instance_counter;
#ifdef BDAL_USE_IO_OUTPUT
std::cout << "[InstanceCountingClass] copy c'tor" << std::endl;
#endif
}
~InstanceCountingClass()
{
--instance_counter;
#ifdef BDAL_USE_IO_OUTPUT
std::cout << "[InstanceCountingClass] d'tor" << std::endl;
#endif
}
};
boost::thread_specific_ptr<InstanceCountingClass> tss;
DWORD WINAPI myThreadFunction(LPVOID)
{
#ifdef BDAL_USE_IO_OUTPUT
std::cout << "[myThreadFunction] called" << std::endl;
#endif
atomic_int_underlying_type cnt = instance_counter.load();
if (cnt != 1) {
std::cerr << "[myThreadFunction] TSS instance counter is different from 1: " << cnt << std::endl;
test_result.store(false);
}
if (tss.get()) {
std::cerr << "[myThreadFunction] TSS contains unexpected value" << std::endl;
test_result.store(false);
}
tss.reset(new InstanceCountingClass());
cnt = instance_counter.load();
if (cnt != 2) {
std::cerr << "[myThreadFunction] TSS instance counter is different from 2: " << cnt << std::endl;
test_result.store(false);
}
return 0;
}
bool doTestBoostThreadSpecificPtrCleanup()
{
instance_counter.store(0);
test_result.store(true);
if (tss.get()) {
std::cerr << "[doTestBoostThreadSpecificPtrCleanup] TSS contains unexpected value" << std::endl;
return false;
}
tss.reset(new InstanceCountingClass());
// Use Windows API to instantiate a thread
HANDLE threadhandle = ::CreateThread(NULL, 0, myThreadFunction, NULL, 0, 0);
if (!threadhandle) {
std::cerr << "[doTestBoostThreadSpecificPtrCleanup] CreateThread failed" << std::endl;
return false;
}
// Wait for thread to exit
DWORD rc = ::WaitForSingleObject(threadhandle, INFINITE);
if (!::CloseHandle(threadhandle) || rc != WAIT_OBJECT_0 || !test_result) {
std::cerr << "[doTestBoostThreadSpecificPtrCleanup] WaitForSingleObject or CloseHandle failed" << std::endl;
return false;
}
// Make sure that the thread-specific instance has been destroyed,
// even though we haven't used the Boost.Thread API to start the
// thread.
atomic_int_underlying_type cnt = instance_counter.load();
if (cnt != 1) {
std::cerr << "[doTestBoostThreadSpecificPtrCleanup] TSS instance counter is different from 1: "
<< cnt << std::endl;
return false;
}
return true;
}
int main()
{
if (doTestBoostThreadSpecificPtrCleanup())
{
std::cout << "SUCCESS!" << std::endl;
}
else
{
std::cerr << "FAILURE!" << std::endl;
}
}
Observed output:
[InstanceCountingClass] default c'tor [myThreadFunction] called [InstanceCountingClass] default c'tor [doTestBoostThreadSpecificPtrCleanup] TSS instance counter is different from 1: 2 FAILURE! [InstanceCountingClass] d'tor
Verified for:
Boost versions: 1.64, 1.63
Visual Studio versions: VS 2012 (toolset=msvc-11.0), VS 2015 (toolset=msvc-14.0), VS 2017 (toolset=msvc-14.1)
Workaround:
Don't build Boost using the /GL compiler flag.
Change History (6)
comment:1 by , 5 years ago
comment:2 by , 5 years ago
This was mainly a documentary issue because we needed quite a while to figure out *what* was the actual cause of a problem that we had after we had build Boost with this setting, since the problem manifested very late and at a completely unexpected point. My main motivation was to give other Boost users a chance to read that issue when they also were investigating a similar issue. I would not be opposed if you would wish to close the issue as WON'T FIX based on your arguments.
comment:4 by , 5 years ago
Good idea. I will take a look at it, but presumably I need at least a week from now on for working on this.
comment:5 by , 5 years ago
Replying to viboes:
Could I ask you to propose a documentation patch?
Could you give me a pointer for the proper location for that patch? Initially I thought that the chapter "Limitations" would be the correct place for it, but it seems that it lists only limitations of boost features that are macros starting with "BOOST_THREAD_"
There is also the chapter "Using and building the library", but I also find only examples of the effects or validity to define BOOST_ macros.
I'm now confused where to put such an information, any hints are appreciated.
comment:6 by , 5 years ago
Sorry for the late response. Maybe you could add them to the thread_specific_ptr section.

Thanks for the report, but I don't know how to fix this. thread_specific_ptr has too much linker issues.