STLport crash (race condition, Darwin only?)
- by Jonas Byström
When I run STLport on Darwin I get a strange crash. (Haven't seen it anywhere else than on Mac, but exactly same thing crash on both i686 and PowerPC.) This is what it looks like in gdb:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
[Switching to process 21097]
0x000000010120f47c in stlp_std::__node_alloc_impl::_M_allocate ()
It may be some setting in STLport, I noticed that Mac.h and MacOSX.h seemed far behind on features. I also know that it it must be some type of race condition, since it doesn't occur just by calling this method (implicity called). The crash happens mainly when I push the system, running 10 simultaneous threads that do a lot of string handling.
Other theories I come up with have to do with compiler flags (configure script) and g++ 4.2 bugs (seems like 4.4.3 isn't on Mac yet with Objective-C support, which I need to link with).
HELP!!! :)
Edit: I run unit tests, which do all sorts of things. This problem arise when I start 10 threads that push the system; and it always comes down to std::string::append which eventually boils down to _M_allocate. Since I can't even get a descent dump of the code that's causing the problem, I figure I'm doing something bad. Could it be so since it's trying to execute at instruction pointer 0x000...000? Are dynlibs built as DLLs in Windows with a jump table? Could it perhaps be that such a jump table has been overwritten for some reason? That would probably explain this behavior. (The code is huge, if I run out of other ideas, I'll post a minimum crashing sample here.)
