Bug 53324 - Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
Summary: Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2012-05-11 14:39 UTC by dominik.strasser
Modified: 2013-09-18 09:13 UTC (History)
0 users

See Also:
Known to work:
Known to fail:
Last reconfirmed:

Example to illustrate the problem (516 bytes, application/octet-stream)
2012-05-11 14:39 UTC, dominik.strasser

Note You need to log in before you can comment on or make changes to this bug.
Description dominik.strasser 2012-05-11 14:39:43 UTC
Created attachment 27373 [details]
Example to illustrate the problem

The attached example mixes std::deque compiled without _GLIBCXX_DEBUG.
The non-_GLIBCXX_DEBUG comes in the original from a binary supplied lib.

IMHO the mixture should either work or disallowed by making std::deque not assignable to a std::__debug::deque.
Comment 1 Jonathan Wakely 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
Comment 2 Jonathan Wakely 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.
Comment 3 dominik.strasser 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.
Comment 4 Jonathan Wakely 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.
Comment 5 dominik.strasser 2013-09-18 09:13:50 UTC
I see the point, so no need to change anything.