http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
--- Comment #35 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-08 13:59:20 UTC --- (In reply to comment #34) > For what it's worth, it appears as if I was just bitten by this issue in a > slightly different context. You haven't given enough detail to know if it's the same issue or just user error. > I was passing a std::string across a dylib boundary which worked on Apple's > gcc > 4.2.1 but crashed on Windows (MSVC). Figuring that with MSVC the allocator > would use a different heap in each dylib I wrote a custom allocator, and now > it > worked on MSVC but crashed on gcc on Darwin. > > I worked out that on Darwin, the custom allocator attempted to release the > empty string created in the other dylib. Defining > _GLIBCXX_FULLY_DYNAMIC_STRING solved the issue. That doesn't make sense. Nothing should release the empty string unless string is fully dynamic already, so defining it shouldn't make any difference. Further, simply defining _GLIBCXX_FULLY_DYNAMIC_STRING when compiling your program is incorrect and not supported. You need to build GCC with --enable-fully-dynamic-string, which is how Apple's GCC and system libraries are built, so building GCC on Darwin should usually use that option. > Anyway, I haven't yet dug deep enough to be certain that this is the same > issue, but it very much appears as if this is not only a problem for shared > memory but also when two dynamic libraries both link against libstdc++ and > exchange std::strings. That should (and does) work fine on GNU/Linux and similar platforms, as long as both libs were built with the same setting for fully dynamic strings (either both using them of neither using them.) Enabling fully dynamic strings changes the library ABI, so you can't mix code with different settings. > The one thing that baffles me, though, is why this wasn't a problem before I > introduced the custom allocator. Does std::allocator have any safeguards > against this? No, but all instances of std::allocator are equivalent (i.e. it's stateless) and (in libstdc++'s default configuration) just call new/delete, so there's nothing std::allocator really needs to do. My guess is you're mixing incompatible libraries, but if not then please open a new bugzilla report instead of adding to this one, thanks.
