linking 2 files compiled with different NDEBUG causes segfault

[smr@…]

Linking y1.o and y2.o compiled as below causes the resulting executable to segfault and show valgrind errors. x1.o defines NDEBUG before including a boost header, x2.o doesn't. If both define NDEBUG, or both don't then linking them produces an executable that runs, and shows no valgrind errors.

This is y1.cpp: #define NDEBUG 1 #include <boost/date_time/posix_time/posix_time.hpp> #include <iostream>

void foobar() {

boost::posix_time::time_duration td(0, 0, 1, 0); std::stringstream ss; ss << td;

} void bar(void); int main() {

bar(); return 0;

}

This is y2.cpp: #include <boost/date_time/posix_time/posix_time.hpp> void bar(void) {

std::cerr<<boost::posix_time::second_clock::local_time()<<' ';

}

Fails: $ g++ y1.cpp y2.cpp && ./a.out Segmentation fault

Reported by Debian user; see ​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537680 for valgrind output.

I have reproduced this behaviour on today's trunk, so I expect it is still a problem in 1.39.0 and upcoming 1.40.0.

[smr@…]

I reproduced this bug with Boost 1.41.

[smr@…]

Log of valgrind run with Boost 1.41 on Debian x86_64

[smr@…]

Log of valgrind run with Boost 1.42 on Debian x86_64

[Vladimir Prus]

Generally speaking, why is this a problem? In general, NDEBUG may change ABI, and therefore should be consistent for entire application -- unless there's a standard saying otherwise.

[anonymous]

Replying to vladimir_prus:

Generally speaking, why is this a problem? In general, NDEBUG may change ABI, and therefore should be consistent for entire application -- unless there's a standard saying otherwise.

What I can find on the web is ​http://www.visualco.de/NDEBUG.html which asserts that

The C standard only dictates that when NDEBUG is defined, the assert macro shall expand to nothing. NDEBUG has no other effect or meaning.

The standardization of assert() supports that; c.f. ​http://www.opengroup.org/onlinepubs/9699919799/functions/assert.html I don't know of anything that states NDEBUG may change ABI -- do you?

One problem the current situation causes is that a boost-using library may be compiled without NDEBUG while someone's application uses NDEBUG, and then goes kabloom when it runs.

[smr@…]

Hi,

I don't see any activity on this bug, but I just tried it with the 1.46 Release Candidate and the specific issue here seems resolved. I no longer get a segfault.