| Summary: | Crash when mixing _GLIBCXX_DEBUG and non-_GLIBCXX_DEBUG std::deque | ||
|---|---|---|---|
| Product: | gcc | Reporter: | dominik.strasser |
| Component: | libstdc++ | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 4.7.0 | ||
| Target Milestone: | --- | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | ||
| Attachments: | Example to illustrate the problem | ||
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 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.
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. (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. I see the point, so no need to change anything. |
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.