Re: [Boost-bugs] [Boost C++ Libraries] #2442: Application statically linked with Boost.Thread crashes when Google Desktop is installed (Windows XP)

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #2442: Application statically linked with Boost.Thread crashes when Google Desktop is installed (Windows XP)
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2012-04-11 06:17:04

#2442: Application statically linked with Boost.Thread crashes when Google Desktop
is installed (Windows XP)
---------------------------------------+------------------------------------
  Reporter:  kvo5v7l02@…               |       Owner:  anthonyw                
      Type:  Bugs                      |      Status:  new                     
 Milestone:  To Be Determined          |   Component:  thread                  
   Version:  Boost 1.35.0              |    Severity:  Problem                 
Resolution:                            |    Keywords:  thread google desktop GS
---------------------------------------+------------------------------------

Comment (by anonymous):

 The bug is more profound and brings out flaws in the design itself.
 I recently started using boost threads in one of my project (has dlls and
 exes) and stumbled on this problem quite early in the test cycle. After I
 analyzed the crash dump, I was lead to look at the dumpbin output for my
 exe and dll for static TLS entires. I found new entries in the place where
 there used to be none before I had started using boost threads.
 As my dll(s) are explicitly loaded I did not use static TLS in my code
 before, but now the boost thread library has put in static TLS without
 taking into account which module it is linking into and assumptions of it.
 I presume(hope) boost thread library is using static TLS to only attach
 it's own TLS callbacks. Though I wish this method was avoided.

 Given that TLS callbacks would be called before dll initialization code -
 implementation should have put tighter control on what the callback
 function calls (directly and indirectly) - definitely not call or read or
 write c/c++ runtime code/date. But this implementation has led to allow
 calls to its own functions that are compiled (with the same flags like
 /GS) along with the code of the user of the library.

 If the implementation had not used automatic char buffer like in the case
 of "create_once_mutex" the problem would not have occurred, as buffer
 overflow check is only applied to functions that have buffers. Or may be
 naked functions which deliberately avoids buffer overflow checks could
 have been used.

 As I am not very sure about how static TLS is used I suspect there could
 be more problems lurking around.

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