id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
10715,Race condition in codecvt() persists in VC++,willw@…,Beman Dawes,"This is a restatement of Ticket #6320, which is still causing me problems; specifically when path objects are used in a DLL with multithreading. Environment is VC++11, although I believe it is also applicable to VC++12. Both versions have documentation warnings against using static local variables in a multithreaded application.

Demo code: A DLL containing the simple function:
{{{
//  exported function.
extern ""C"" DLL_API void fnDll( void )
{
	boost::filesystem::path p(""test_path"");
	return;
}
}}}
The main program creates threads to load the DLL and call this function:
{{{
void thread_func() 
{
	boost::this_thread::sleep(boost::posix_time::milliseconds(100));
	HINSTANCE hLib = LoadLibraryA(""Dll.dll""); 
	if (hLib != NULL) { // Resolve test function in DLL
		FARPROC f = GetProcAddress(hLib,""fnDll"");
		if (f)	f(); // call it
	}
}

int main(int argc, _TCHAR* argv[])
{
	boost::thread_group tg;
	for(int i = 0; i < 2; i++)
		tg.create_thread(thread_func);
	tg.join_all();
	return 0;
}
}}}
Built and run for debug, this code fails when the BOOST_ASSERT:

""codecvt_facet_ptr() facet hasn't been properly initialized""

fires on line 888, in const path::codecvt_type& path::codecvt()

The user workaround is to put code in DllMain's DLL_PROCESS_ATTACH, as described in the earlier ticket, to force initialisation before multiple threads share the DLL.

I attach the Visual Studio project used to test this. This DLL scenario is a simplification of a genuine situation: I found it when an Apache add-on started crashing its host.",Bugs,new,To Be Determined,filesystem,Boost 1.54.0,Problem,,codecvt race,raad@…