From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 19:06:06 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 20F7A568; Fri, 4 Jan 2013 19:06:06 +0000 (UTC) (envelope-from stefan@fafoe.narf.at) Received: from fep15.mx.upcmail.net (fep15.mx.upcmail.net [62.179.121.35]) by mx1.freebsd.org (Postfix) with ESMTP id 3EEAB268; Fri, 4 Jan 2013 19:06:04 +0000 (UTC) Received: from edge04.upcmail.net ([192.168.13.239]) by viefep15-int.chello.at (InterMail vM.8.01.05.05 201-2260-151-110-20120111) with ESMTP id <20130104190603.PSBO2598.viefep15-int.chello.at@edge04.upcmail.net>; Fri, 4 Jan 2013 20:06:03 +0100 Received: from mole.fafoe.narf.at ([80.109.55.137]) by edge04.upcmail.net with edge id jv621k0292xdvHc04v62yw; Fri, 04 Jan 2013 20:06:03 +0100 X-SourceIP: 80.109.55.137 Received: by mole.fafoe.narf.at (Postfix, from userid 1001) id 9CFD66D454; Fri, 4 Jan 2013 20:06:02 +0100 (CET) Date: Fri, 4 Jan 2013 20:06:02 +0100 From: Stefan Farfeleder To: Konstantin Belousov Subject: Re: clang 3.2 RC2 miscompiles libgcc? Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130104181438.GL82219@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-current@freebsd.org, Dimitry Andric , Nathan Whitehorn X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 19:06:06 -0000 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: > > > > $ cat throw-crash.cc > > #include > > > > void f2(void) { > > std::string s; > > throw std::runtime_error("foo"); > > } > > > > void f1(void) { > > f2(); > > } > > > > int main(void) { > > try { > > std::string s1, s2; > > f1(); > > return 0; > > } catch (const std::exception &) { > > return 1; > > } > > } > > $ g++ -O2 -finline-limit=0 throw-crash.cc > > $ ./a.out > > zsh: bus error (core dumped) ./a.out > > What is the backtrace ? > Compile the system libraries (ld-elf, libc, libgcc etc) with the > debugging information and obtain the backtrace once more. I'm afraid the backtrace is not really interesting: Program received signal SIGBUS, Bus error. std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) at atomicity.h:69 69 _Atomic_word __result = *__mem; (gdb) bt #0 std::string::_Rep::_M_dispose (this=0x7fffffffd62fe8, __a=@0x7fffffffd628) at atomicity.h:69 #1 0x000000080089d168 in ~basic_string (this=0x7fffffffd62fe8) at basic_string.h:482 #2 0x0000000000401038 in main () at throw-crash.cc:16 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. It seems the std::string destructor is called with an invalid this pointer for s2: (gdb) r Starting program: /usr/home/stefan/scratch/a.out Breakpoint 1, main () at throw-crash.cc:12 12 int main(void) { (gdb) b _Unwind_RaiseException Breakpoint 2 at 0x800d420b4 (gdb) c Continuing. 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 = (string *) 0x7fffffffd600 (gdb) up #3 0x0000000000400fe2 in main () at throw-crash.cc:15 15 f1(); (gdb) p &s1 $2 = (string *) 0x7fffffffd650 (gdb) p &s2 $3 = (string *) 0x7fffffffd640 ^^^^ (gdb) b 'std::basic_string, std::allocator >::~basic_string()' Breakpoint 3 at 0x80089d154: file basic_string.h, line 482. (gdb) c Continuing. Breakpoint 3, ~basic_string (this=0x7fffffffd600) at basic_string.h:279 279 _M_data() const (gdb) c Continuing. Breakpoint 3, ~basic_string (this=0x7fffffffd640) at basic_string.h:279 279 _M_data() const (gdb) c Continuing. Breakpoint 3, ~basic_string (this=0x7fffffffd60f) at basic_string.h:279 ^^^^ 279 _M_data() const 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. Stefan