This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Analysis of 21_strings/ctor_copy_dtor.cc (execution test) failure
- To: libstdc++ at gcc dot gnu dot org
- Subject: Analysis of 21_strings/ctor_copy_dtor.cc (execution test) failure
- From: Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>
- Date: Wed, 18 Apr 2001 03:43:12 -0500 (CDT)
- CC: gcc-bugs at gcc dot gnu dot org
- Reply-to: rittle at rsch dot comm dot mot dot com
Hi Benjamin,
You wanted to try and nail the remaining libstdc++ failures this week.
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