Re: Analysis of 21_strings/ctor_copy_dtor.cc (execution test) failure

[Benjamin Kosnik <bkoz at redhat dot com>]

Richard I think this is the same bug discussed two wednesdays ago, or 
related to it: exception code falling through and calling terminate. 
Something's up with the call-frame exception handling bits on x86.

Here's a smaller example:

#include <string>

int main(void)
{
  bool test = true;
  typedef std::string::size_type csize_type;
  csize_type csz01;
  const char str_lit01[] = "rodeo beach, marin";
  const std::string str01(str_lit01);
  csz01 = str01.size();

  try 
    {
      std::string str03(str01, csz01 + 1);
      test = false;
    }		 
  catch(...) 
    {
      test = true;
    }

  return 0;
}


(gdb) where
#0  0x08076181 in __kill ()
#1  0x0807601b in raise (sig=6) at ../sysdeps/posix/raise.c:27
#2  0x0804e921 in abort () at ../sysdeps/generic/abort.c:88
#3  0x080995e5 in __cxxabiv1::__terminate(void ( *)(void)) (
    handler=0x804e7e4 <abort>)
    at /mnt/hd/bliss/src.gcc/libstdc++-v3/libsupc++/eh_terminate.cc:47
#4  0x080994c4 in __gxx_personality_v0 ()
    at /mnt/hd/bliss/src.gcc/libstdc++-v3/libsupc++/eh_personality.cc:547
#5  0x08049ba6 in _Unwind_RaiseException_Phase2 ()
#6  0x08049fa0 in _Unwind_Resume ()
#7  0x08090a69 in _ZSt20__throw_out_of_rangePKc () at stl_alloc.h:545
#8  0x0809b796 in std::string::_M_check(unsigned int) const 
(this=0xbffffa54, 
    __pos=1) at basic_string.h:267
#9  0x0809b600 in basic_string (this=0xbffff990, __str=@0xbffffa5c, 
    __pos=3221224020, __n=4294967295) at basic_string.h:217
#10 0x080482a5 in main () at rth01.cc:14
#11 0x0804ac5a in __libc_start_main (main=0x80481f0 <main>, argc=1, 
    ubp_av=0xbffffa54, init=0x80480b4 <_init>, fini=0x80c70c0 <_fini>, 
    rtld_fini=0, stack_end=0xbffffa4c) at ../sysdeps/generic/libc-start.c:129
(gdb) 


Here's the original mail from Loren:

> On x86 targets (both FreeBSD and Linux display the problem so it
> appears general to x86), 21_strings/ctor_copy_dtor.cc (execution
> test), static fails but shared is fine.  Interesting red herring: if
> one manually rebuilds that static test with -O2 (but the command line
> identical to that logged otherwise), it no longer crashes.
> 
> A small test case is not available yet.  (At least, I see no simple test
> case in `make check-g++' that fails.  OTOH, this is not surprising
> since none of those tests appear to link against the static version of
> libstdc++, if the shared version is available.  I have added -static
> to my schedule of variations to locate a small test case.)
> 
> However, on any x86 system with mainline gcc built and, at least,
> `make -C i?86-*-*/libstdc++-v3/testsuite check' or a full `make check'
> run and which is seen to fail:
> 
>    21_strings/ctor_copy_dtor.cc (execution test), static
> 
> but pass the related shared test, the following steps can be used to
> run the built test cases:
> 
>    cd i?86-*-*/libstdc++-v3/testsuite/21_strings
>    gdb ctor_copy_dtor.sh-exe
>    gdb ctor_copy_dtor.st-exe
> 
> After setting a breakpoint at __gxx_personality_v0 (and verifying that
> the execution paths to that point are identical), I have
> single-stepped both the dynamic-linked and static-linked versions
> until the execution of the static-linked executable crashes.  However,
> the execution paths diverge before that point.  The key difference is
> that the dynamic-linked executable walks up the call-site stack and
> correctly finds the catch block in main.  The static-linked executable
> doesn't find it for some reason and thus sets up to (eventually)
> terminate.  Perhaps, this description makes sense to someone.  Or, at
> least, maybe someone with the right skills will be motivated to take a
> look at the problem with the above details of how to find a built test
> case.
> 
> Regards,
> Loren
>