STLport crash (race condition, Darwin only?)

When I run STLport on D开发者_JS百科arwin 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.)

---

hmm.. STLPort uses allocaters which takes platform memory and pool it internally to the data structures when needed.

Just check when the crash happens, the heap given to the executing thread is enough for a alloc to happen. Even if an alloc fails, this crash can happen.

I am not sure about the granularity of the STL allocator in the current configuration you are working on. Check stl_config.h for that.

---

This problem was caused by an unrelated crash bug, causing memory overwrites leading to an STLport crash in my case.