Why is this stack trace appearing when compiled with gcc 4.7 but not with older pre 4.3?

Question

I have a fairly large binary which I had been building for a while on a pretty old version of GCC (4.1.2). I recently built it with 4.7 but when I run it it crashes with the following backtrace:

terminate called after throwing an instance of 'std::logic_error'
  what(): basic_string::_S_construct NULL not valid

Program received signal SIGABRT, Aborted.
0x000003728472c5 in raise() from /lib64/libc.so.6
(gdb) bt
#0 0xbla in raise () from /lib64/libc.so.6
#1 0xbla in abort() from /lib64/libc.so.6
#2 0xbla in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib64/libstdc++.so.6
#3 0xbla in ?? () from /usr/lib64/libstdc++.so.6
#4 0xbla in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0xbla in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0xbla in std::__throw_logic_error(char const*) () from /usr/lib64/libstdc++.so.6
#7 0x00000024727472 in ?? () from /usr/lib64/libstdc++.so.6
#8 0xbla in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib64/libdstdc++.so.6
#9 0xbla in CFGS_XML_Parser::ns_name (name=0x12283c0 "name") at CFGS_XML_Parser.H:258
#10 0xbla in __static_initialization_and_destruction_0 (__initialize_p=1,__priority=65535)
#11 0xbla in _GLOBAL__sub_I__Z15init_xml_loaderv () at CFGS_XML_Loader.C:728
#12 0xbla in __libc_csu_init()
#13 0xbla in __libc_start_main () from /lib64/libc.so.6
#14 0xbla in _start ()

I have no idea what this is complaining about and why it would be a gcc 4.7 only thing. What could it be and how can I debug this?

Answer 1

As Mats Petersson correctly stated, you are trying to construct a std::string from a const char *, that is NULL.

The likely reason this didn't happen with older GCC and is happening with newer one is that GCC-4.7 stopped using .ctors and started usting .init_array. See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46770

As Mats Petersson also likely correctly guessed, you have depended on initializer order between separate compilation units, and now that this order changed (the order is undefined), you are paying the price.

We had this exact problem in a codebase of 100+ MLOC, and our solution is to reconfigure GCC with configure --disable-initfini-array ... (we build our own GCC releases).

Note that some platforms (e.g. ARM) do not support .ctors, only .init_arrays.