http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16612
j.scheid <julians37 at googlemail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |julians37 at googlemail dot
| |com
--- Comment #34 from j.scheid <julians37 at googlemail dot com> 2012-04-05
18:45:37 UTC ---
For what it's worth, it appears as if I was just bitten by this issue in a
slightly different context.
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.
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.
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?
