[Boost-bugs] [Boost C++ Libraries] #10715: Race condition in codecvt() persists in VC++

Subject: [Boost-bugs] [Boost C++ Libraries] #10715: Race condition in codecvt() persists in VC++
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2014-10-29 15:51:13

#10715: Race condition in codecvt() persists in VC++
------------------------------+------------------------
 Reporter:  willw@…           |      Owner:  bemandawes
     Type:  Bugs              |     Status:  new
Milestone:  To Be Determined  |  Component:  filesystem
  Version:  Boost 1.54.0      |   Severity:  Problem
 Keywords:  codecvt race      |
------------------------------+------------------------
 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.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/10715>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.