Application statically linked with Boost.Thread crashes when Google Desktop is installed (Windows XP)

[kvo5v7l02@…]

Application statically linked with Boost.Thread crashes when Google Desktop is installed (Windows XP, VC9).

Google Desktop installs a hook and injects its DLL to application address space on application startup. This DLL creates its own thread, does something, and then calls Windows API's FreeLibraryAndExitThread() function. This function eventually calls boost::detail::create_once_mutex(), which crashes with VC "buffer security check" (see /GS option, which is default). I suppose this is because of CRT was not initialized yet (application crashes on the very start) and particularly because __security_init_cookie() function was not called. It seems there are two possible workarounds:

1. Recompile Boost.Thread with /GS- option

2. Add an explicit call of __security_init_cookie() function, e.g. in run_thread_exit_callbacks() function.

The crash can be reliably reproduced on Windows XP with the latest Google Desktop (5.8.0809.23506-en-pb) installed. To reproduce:

1. Download and unzip test application archive from ​http://engineering.meta-comm.com/resources/boost_thread_with_google_desktop_crash_test.zip

2. Open the folder with the test application in Windows Explorer, and launch several (>= 3) instances of "run.bat" at once.

I was not able to reproduce it on Windows Vista.

[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.

[nanda]

Replying to anonymous: Forgot to mention my name - nanda.

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.

[viboes]

Please reopen if this old ticket is of actuality yet.