[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 dominik.stras...@onespin-solutions.com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from dominik.stras...@onespin-solutions.com --- I see the point, so no need to change anything.
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #3 from dominik.stras...@onespin-solutions.com 2012-06-11 15:10:49 UTC --- I get the point. However, I could imagine that it is a quite common scenario to have a binary contributed C++ lib. Mixing debug/non-debug is impossible due to name mangling, however you can get random behavior if debug-enabled containers are returned. It took me quite a while to find out what was going wrong. Maybe some annotation for the linker could help here. I see that there's a general problem with overloading on function return values, but usually this is under the control of the user.
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org 2012-06-11 15:34:49 UTC --- (In reply to comment #3) Maybe some annotation for the linker could help here. Suggestions welcome. I don't see any way to do anything here. The docs say you need to recompile everything when defining _GLIBCXX_DEBUG. If you have a binary lib you can't recompile everything, so don't define _GLIBCXX_DEBUG. You can still use __gnu_debug::deque in specific places to get checking for individual containers, rather than defining the macro. That's how I use the Debug Mode containers when I can't recompile everything.
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-11 17:09:26 UTC --- Even if it wasn't assignable your program would crash, C++ name mangling doesn't include the return type so the symbol _ZN2XX5getmeEv defined in x.o reolves the undefined reference in y.o even though they disagree on the return type. I don't think it's possible to fix that, you just have to follow the documentation and ensure you recompile all necessary code with -D_GLIBCXX_DEBUG
[Bug libstdc++/53324] Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53324 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-05-11 17:20:13 UTC --- N.B. this is basically the same scenario as if you compiled x.C, then changed XX::getme to return a std::list instead of std::deque, then compiled y.C -- it would link, but crash at runtime. This is a general feature of C++ name-mangling and separrate compilation, not specific to our debug mode. If you create a file called deque in the same directory containing: #include list #define deque list then change the makefile to build y.o with this rule, not using debug mode: y.o: y.C g++ -c -I. y.C then it will link (even though you can't assign std::list to std::deque, i.e. your suggestion won't help) but it will segfault when run.
