[gcc 4.0.1/Mac OS X] SIGABRT throwing an exception

• Key: STDCXX-600
• Type: Bug
• Status: Open
• Priority: Minor
• Assignee: Eric Lemings
• Reporter: Martin Sebor
• Component/s: 18. Language Support
• Affects Version/s: 4.2.0, 4.2.1
• Fix Version/s: 4.2.2

Description

Throwing an exception from the library causes a SIGABRT. Example programs that demonstrate library exceptions abort, as does the program below:

$ cat t.cpp && make t && gdb -q t
#include <string>

int main ()
{
try { std::string s; s.replace (1, 1, "x"); }
catch (...) {
}
}

gcc -c -I/Users/sebor/stdcxx/include/ansi -D_RWSTDDEBUG -I/Users/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.0.1-15d/include -I/Users/sebor/stdcxx/examples/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align t.cpp
gcc t.o -o t -L/build/sebor/stdcxx-gcc-4.0.1-15d/lib -lstd15d -lsupc++ -lgcc_eh -lm
Reading symbols for shared libraries ... done
(gdb) run
Starting program: /build/sebor/stdcxx-gcc-4.0.1-15d/examples/t
Reading symbols for shared libraries .+ done

Program received signal SIGABRT, Aborted.
0x9003d66c in kill ()
(gdb) where
#0 0x9003d66c in kill ()
#1 0x9010e8cf in raise ()
#2 0x9010d422 in abort ()
#3 0x00002959 in _Unwind_SetGR () at t.cpp:11
#4 0x000026a6 in __gxx_personality_v0 () at t.cpp:11
#5 0x002681c4 in _Unwind_RaiseException_Phase2 () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#6 0x002683f4 in _Unwind_RaiseException () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#7 0x00260a57 in __cxa_throw () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#8 0x0020b774 in _rw::_rw_throw_exception (id=9, what=0x11001d0 "") at /Users/sebor/stdcxx/src/exception.cpp:694
#9 0x0020ac40 in _rw::_rw_throw (id=9) at /Users/sebor/stdcxx/src/exception.cpp:832
#10 0x00238149 in std::string::replace (this=0xbffffa88, __pos1=1, __n1=1, __s=0xbac8 "x", __n2=1) at /Users/sebor/stdcxx/include/string.cc:312
#11 0x0023852f in std::string::replace (this=0xbffffa88, __pos=1, __n=1, __s=0xbac8 "x") at /Users/sebor/stdcxx/include/string:545
#12 0x00001c4d in main () at t.cpp:7

Comments

[Martin Sebor]

Enhancing the original test case to catch the exception and print out the what() string reveals either another problem or a different symptom of the same one. The following post might be a clue as to what's going on:

http://www.nabble.com/RE%3A-4.2.0-rc-6%2C-final-candidate-p13234984.html

$ cat t.cpp && make t && gdb -q t
#include <cstdio>
#include <exception>
#include <string>

int main ()
{
    try {
        std::string s;
        s.replace (1, 1, "x");
    }
    catch (std::exception &ex) {
        std::fprintf (stderr, "%s\n", ex.what ());
    }
}

gcc -c -I/Users/sebor/stdcxx/include/ansi -D_RWSTDDEBUG    -I/Users/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-4.0.1-15d/include -I/Users/sebor/stdcxx/examples/include  -pedantic -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   t.cpp
gcc t.o -o t  -L/build/sebor/stdcxx-gcc-4.0.1-15d/lib  -lstd15d -lsupc++ -lgcc_eh -lm 
Reading symbols for shared libraries ... done
(gdb) run
Starting program: /build/sebor/stdcxx-gcc-4.0.1-15d/examples/t 
Reading symbols for shared libraries .+ done
terminate called after throwing an instance of 'std::out_of_range'
t(17938) malloc: ***  Deallocation of a pointer not malloced: 0x11003c0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug
  what():  
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000016
0x900298db in fputs ()
(gdb) where
#0  0x900298db in fputs ()
#1  0x00261b9b in __gnu_cxx::__verbose_terminate_handler () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#2  0x00260912 in __cxxabiv1::__terminate () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#3  0x00260950 in std::terminate () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#4  0x00260a64 in __cxa_throw () at /Users/sebor/stdcxx/src/wctype.cpp:1058
#5  0x0020b774 in __rw::__rw_throw_exception (id=9, what=0x11001d0 "") at /Users/sebor/stdcxx/src/exception.cpp:694
#6  0x0020ac40 in __rw::__rw_throw (id=9) at /Users/sebor/stdcxx/src/exception.cpp:832
#7  0x00238149 in std::string::replace (this=0xbffffa74, __pos1=1, __n1=1, __s=0xbac4 "x", __n2=1) at /Users/sebor/stdcxx/include/string.cc:312
#8  0x0023852f in std::string::replace (this=0xbffffa74, __pos=1, __n=1, __s=0xbac4 "x") at /Users/sebor/stdcxx/include/string:545
#9  0x00001bde in main () at t.cpp:9

[Martin Sebor]

This is possibly related to the fix committed to resolve STDCXX-262.

[Martin Sebor]

Switching the order of std::exception dtor and std::exception::what() (i.e., back the way it was before rev 583667 (http://svn.apache.org/viewcvs?view=rev&rev=583667) gets rid of the malloc error but in shared library builds (archive builds are okay) the exception is still not caught. The output then looks like this:

terminate called after throwing an instance of 'std::out_of_range'
what(): /Users/sebor/stdcxx/include/string.cc:316: std::basic_string<_CharT, _Traits, _Allocator>& std::basic_string<_CharT, _Traits, _Allocator>::replace(typename _Allocator::size_type, typename _Allocator::size_type, typename _Allocator::const_pointer, typename _Allocator::size_type) [with _CharT = char, _Traits = std::char_traits<char>, _Allocator = std::allocator<char>]: argument value 1 out of range [0, 1)
Abort trap

While switching the order the std::exception virtual members either way (before rev 583667 and after) doesn't seem to cause any problems when linking the library, doing the same with std::bad::alloc dtor and std::bad::alloc::what() causes the following linker error when linking the shared library:

ld: multiple definitions of symbol __ZTVSt9bad_alloc
memory.o definition of _ZTVSt9bad_alloc in section (DATA,_const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) private external definition of _ZTVSt9bad_alloc in section (DATA,_const)
/usr/bin/libtool: internal link edit command failed

and the following one when linking with an archive of it:

/build/sebor/stdcxx-gcc-4.0.1-11s/lib/libstd11s.a(memory.o) definition of vtable for std::bad_allocin section (_DATA,_const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) private external definition of vtable for std::bad_allocin section (_DATA,_const)
collect2: ld returned 1 exit status

[Martin Sebor]

Part of the problem is that we're defining classes that are defined in the language runtime library with no reliable way to detect their exact layout, including the order of their virtual member functions. We have tests that try to detect whether the member functions (virtual or otherwise) of these classes are defined in the runtime but the tests are less than 100% reliable. We also unconditionally declare all the members even though the runtime might be relying on the compiler to generate some of them (e.g., the ctors and assignment operator).

[Martin Sebor]

Let's revisit this in 4.2.2, if only to verify whether it's still a problem and decide if we can do something about it or not.

[Eric Lemings]

I can verify it's still a problem, at least with gcc 4.0.1 on Darwin 9.3. Not sure what to do about it though.

[Martin Sebor]

Lowered Priority to Minor since gcc on Darwin is a Best Effort platform according to the TargetPlatforms on the Wiki.