Boost C++ Libraries: Ticket #2442: Application statically linked with Boost.Thread crashes when Google Desktop is installed (Windows XP)

anonymous — Wed, 11 Apr 2012 06:17:04 GMT

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 — Wed, 11 Apr 2012 06:27:03 GMT

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.

version, milestone changed

WhaleGerbbila — Thu, 06 Jun 2013 00:48:03 GMT

version Boost 1.35.0 → Boost 1.38.0
milestone To Be Determined → Website 1.X

milestone changed

viboes — Sat, 08 Jun 2013 12:58:55 GMT

milestone Website 1.X → To Be Determined

status changed; resolution set

viboes — Wed, 07 Jan 2015 02:43:56 GMT

status new → closed
resolution → obsolete

Please reopen if this old ticket is of actuality yet.