Date: Fri, 4 Jan 2013 22:23:34 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Stefan Farfeleder <stefanf@freebsd.org> Cc: freebsd-current@freebsd.org, Dimitry Andric <dim@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <20130104202334.GN82219@kib.kiev.ua> In-Reply-To: <20130104190602.GE1430@mole.fafoe.narf.at> References: <20121227150724.GA1431@mole.fafoe.narf.at> <50DC65F5.6060004@freebsd.org> <50E0BD66.4070609@FreeBSD.org> <20130102135950.GA1464@mole.fafoe.narf.at> <20130104154940.GD1430@mole.fafoe.narf.at> <20130104181438.GL82219@kib.kiev.ua> <20130104190602.GE1430@mole.fafoe.narf.at>
next in thread | previous in thread | raw e-mail | index | archive | help
--jobRqqe4Hp8P9iE7
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 04, 2013 at 08:06:02PM +0100, Stefan Farfeleder wrote:
> On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
> > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
> > > Here's a minimal test case that reproduces the bug:
> > >=20
> > > $ cat throw-crash.cc
> > > #include <stdexcept>
> > >=20
> > > void f2(void) {
> > > std::string s;
> > > throw std::runtime_error("foo");
> > > }
> > >=20
> > > void f1(void) {
> > > f2();
> > > }
> > >=20
> > > int main(void) {
> > > try {
> > > std::string s1, s2;
> > > f1();
> > > return 0;
> > > } catch (const std::exception &) {
> > > return 1;
> > > }
> > > }
> > > $ g++ -O2 -finline-limit=3D0 throw-crash.cc=20
> > > $ ./a.out=20
> > > zsh: bus error (core dumped) ./a.out
> >=20
> > What is the backtrace ?
> > Compile the system libraries (ld-elf, libc, libgcc etc) with the
> > debugging information and obtain the backtrace once more.
>=20
> I'm afraid the backtrace is not really interesting:
>=20
> Program received signal SIGBUS, Bus error.
> std::string::_Rep::_M_dispose (this=3D0x7fffffffd62fe8, __a=3D@0x7fffffff=
d628)
> at atomicity.h:69
> 69 _Atomic_word __result =3D *__mem;
> (gdb) bt
> #0 std::string::_Rep::_M_dispose (this=3D0x7fffffffd62fe8, __a=3D@0x7fff=
ffffd628)
> at atomicity.h:69
> #1 0x000000080089d168 in ~basic_string (this=3D0x7fffffffd62fe8)
> at basic_string.h:482
> #2 0x0000000000401038 in main () at throw-crash.cc:16
>=20
> I think the stack is somehow corrupted after the exception was
> performed. As with the original test case, loading an old libgcc_s.so.1
> instead makes the program run correctly.
>=20
> It seems the std::string destructor is called with an invalid this
> pointer for s2:
>=20
> (gdb) r
> Starting program: /usr/home/stefan/scratch/a.out=20
>=20
> Breakpoint 1, main () at throw-crash.cc:12
> 12 int main(void) {
> (gdb) b _Unwind_RaiseException
> Breakpoint 2 at 0x800d420b4
> (gdb) c
> Continuing.
>=20
> Breakpoint 2, 0x0000000800d420b4 in _Unwind_RaiseException ()
> from /lib/libgcc_s.so.1
> (gdb) f 2
> #2 0x0000000000400f51 in f2 () at throw-crash.cc:5
> 5 throw std::runtime_error("foo");
> (gdb) p &s
> $1 =3D (string *) 0x7fffffffd600
> (gdb) up
> #3 0x0000000000400fe2 in main () at throw-crash.cc:15
> 15 f1();
> (gdb) p &s1
> $2 =3D (string *) 0x7fffffffd650
> (gdb) p &s2
> $3 =3D (string *) 0x7fffffffd640
> ^^^^
> (gdb) b 'std::basic_string<char, std::char_traits<char>, std::allocator<c=
har> >::~basic_string()'=20
> Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
> (gdb) c
> Continuing.
>=20
> Breakpoint 3, ~basic_string (this=3D0x7fffffffd600) at basic_string.h:279
> 279 _M_data() const
> (gdb) c
> Continuing.
>=20
> Breakpoint 3, ~basic_string (this=3D0x7fffffffd640) at basic_string.h:279
> 279 _M_data() const
> (gdb) c
> Continuing.
>=20
> Breakpoint 3, ~basic_string (this=3D0x7fffffffd60f) at basic_string.h:279
> ^^^^
> 279 _M_data() const
>=20
> So, the address of s2 is 0x7fffffffd640, but the dtor is called with
> 0x7fffffffd60f which is also very unaligned. I think this is the reason
> for the crash.
Thank you for digging more.
In fact, it is more likely that there is some bug or incompatibility in
c++ unwinder than in the libgcc itself, but as you noted, a compiler bug
is also possible.
Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug
also cannot be excluded at this stage, but it not much likely.
--jobRqqe4Hp8P9iE7
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iQIcBAEBAgAGBQJQ5zpFAAoJEJDCuSvBvK1BiXIQAI3dQYqz6mmhplx7gzcqBM+Z
0Z4+u0vgmgKCHfYrDxGEZokBJPEd0Io6jrQjriBRWMjuarEx6FctRcBEkTmUV/Re
yfXWcAvnBlSfC3al8X+f3qmVuXFmG40dpTB8pkFJWCSoX3Z/UWWhpXvdqC8jajJz
UNshhVn65cmuDYbfRc+D+aVu6BKoZ7jbP8ZTeKn6v3/wUyZfdHK7iZYmnscuRLiv
4tFGF5oo0yZyipaNk2ichSxbb1UTpyT/Tg/HY0LgYWy0DDn46Zce2VYiO1HEahdk
rjqkwbOeaLnkjR9YBawa8kT+fMjHmu/xbbvrgTmqYuar8+caPY5U3xi4bTLKQVLy
MCD/tX8G7Q3xZK9NvAqihQdIB1ZU6a5OxuqSoa2J9umFM6pXZlKyc1Y9Z9vL5B7A
2487YS8TOITNRsr8qNqWPHB5JZwwNh/khCEuwgxusTAGNxu5uwivOYudFP3ulAM0
L7dqF55waaTOMsjOxWxEwFwuqRW4u0nwquSulp/QiHgqOjt9lrZho4HLxOWuWS48
6+ZeMLqiyI3TuSJ8mVM+wEi7HDFiW7dKK/opjJp+jtv9ss3QbhS64xM7M23rHUKB
gLgwcpSbOE7FtkbV7tP2LDDEuZyDdkfG7QJxJGpM/bKRYSUnOQw7+QbR7t/W/Nvu
BIiujTvHg1xpnNRq/L/F
=oLMM
-----END PGP SIGNATURE-----
--jobRqqe4Hp8P9iE7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130104202334.GN82219>