Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-11 02:19, O. Hartmann wrote: On 01/11/13 00:39, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ Very appreciated and thanks. oh For the record, I rebuilt my world/kernel after this commit, and rebuilt VirtualBox, and it now works correctly. Thanks Dimitry! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 214-642-9640 (c) E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/11/13 00:39, Dimitry Andric wrote: > On 2013-01-08 09:58, Stefan Farfeleder wrote: >> On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: > ... >>> After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume >>> which when compiled by clang caused the crashes, but when compiled by >>> gcc ran OK. >> your patch seems to work just fine. No crashes whatsoever so far. Thank >> you. > > I have committed a slighly cleaned-up version of this hack in r245272, > so until this is fixed by upstream, everybody will at least have a > correctly functioning libgcc on amd64. > > Since this issue can potentially also occur on stable/9, I will MFC the > fix too, after a few days timeout. > ___ Very appreciated and thanks. oh signature.asc Description: OpenPGP digital signature
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 11, 2013 at 12:39:44AM +0100, Dimitry Andric wrote: > On 2013-01-08 09:58, Stefan Farfeleder wrote: > > On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: > ... > >> After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume > >> which when compiled by clang caused the crashes, but when compiled by > >> gcc ran OK. > > your patch seems to work just fine. No crashes whatsoever so far. Thank > > you. > > I have committed a slighly cleaned-up version of this hack in r245272, > so until this is fixed by upstream, everybody will at least have a > correctly functioning libgcc on amd64. > > Since this issue can potentially also occur on stable/9, I will MFC the > fix too, after a few days timeout. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
08.01.2013 03:21, Dimitry Andric пишет: > Can you please try the attached patch, which is a very horrid, atrocious > hack, and will only work for amd64. Then rebuild libgcc with clang, and > please try if this fixes at least some of the crashes... The patch fixed building editors/libreoffice. Without this patch the port segfaulted while doing cppunittest. The system: - % uname -a FreeBSD BB051.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r245047: Sat Jan 5 03:19:00 SAMT 2013 b...@bb051.wart.ru:/usr/obj/usr/src/sys/BB64X amd64 % clang --version FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix - Thanks! -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-08 09:08, David Chisnall wrote:
On 7 Jan 2013, at 23:21, Dimitry Andric wrote:
This is at least the direction I'm looking at. It seems that in some
cases with __builtin_eh_return(), llvm does not see that registers can
be clobbered, and it doesn't save and restore them.
Do you mean that some registers were clobbered by a prior call?
__builtin_eh_return() doesn't return, so whether it clobbers anything or not
isn't something that should matter. The preceding call is
__builtin_frob_return_addr, which seems to be a no-op, so it shouldn't clobber
any registers either...
No, I mean that gcc seems to take great care in saving and restoring
almost all important registers in a function, if that function contains
a call to __builtin_eh_return.
If you look at expand_eh_return() in contrib/gcc/except.c, you can see
that it sets the special variable 'current_function_calls_eh_return'.
This influences the code generation all over the place, and specifically
the saving of registers in contrib/gcc/config/i386/i386.c:
==
/* Return 1 if we need to save REGNO. */
static int
ix86_save_reg (unsigned int regno, int maybe_eh_return)
{
if (pic_offset_table_rtx
&& regno == REAL_PIC_OFFSET_TABLE_REGNUM
&& (regs_ever_live[REAL_PIC_OFFSET_TABLE_REGNUM]
|| current_function_profile
|| current_function_calls_eh_return
|| current_function_uses_const_pool))
{
if (ix86_select_alt_pic_regnum () != INVALID_REGNUM)
return 0;
return 1;
}
if (current_function_calls_eh_return && maybe_eh_return)
{
unsigned i;
for (i = 0; ; i++)
{
unsigned test = EH_RETURN_DATA_REGNO (i);
if (test == INVALID_REGNUM)
break;
if (test == regno)
return 1;
}
}
[...]
/* Emit code to save registers in the prologue. */
static void
ix86_emit_save_regs (void)
{
unsigned int regno;
rtx insn;
for (regno = FIRST_PSEUDO_REGISTER; regno-- > 0; )
if (ix86_save_reg (regno, true))
{
insn = emit_insn (gen_push (gen_rtx_REG (Pmode, regno)));
RTX_FRAME_RELATED_P (insn) = 1;
}
}
==
On i386, most registers are touched anyway in _Unwind_Resume, so clang
will already save and restore them. But on amd64, there are more
registers than local variables, so clang only seems to save a few; not
enough, in any case. This is why I added the asm statement which
clobbers all those registers, forcing clang to save and restore them.
This fixes most of the crashes I was able to reproduce. I think I still
have another unrelated issue in libgcc with clang, but this only occurs
when compiling the testcases with gcc 4.7, and very high optimization.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: > On 2013-01-06 17:03, Stefan Farfeleder wrote: > > On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: > ... > > The bug also affects ports software, e.g., I also experienced strange > > rtorrent segfaults that are now gone. > > Can you please try the attached patch, which is a very horrid, atrocious > hack, and will only work for amd64. Then rebuild libgcc with clang, and > please try if this fixes at least some of the crashes... > > This is at least the direction I'm looking at. It seems that in some > cases with __builtin_eh_return(), llvm does not see that registers can > be clobbered, and it doesn't save and restore them. > > After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume > which when compiled by clang caused the crashes, but when compiled by > gcc ran OK. Hi Dimitry, your patch seems to work just fine. No crashes whatsoever so far. Thank you. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 7 Jan 2013, at 23:21, Dimitry Andric wrote: > This is at least the direction I'm looking at. It seems that in some > cases with __builtin_eh_return(), llvm does not see that registers can > be clobbered, and it doesn't save and restore them. Do you mean that some registers were clobbered by a prior call? __builtin_eh_return() doesn't return, so whether it clobbers anything or not isn't something that should matter. The preceding call is __builtin_frob_return_addr, which seems to be a no-op, so it shouldn't clobber any registers either... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-06 17:03, Stefan Farfeleder wrote: On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: ... The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Can you please try the attached patch, which is a very horrid, atrocious hack, and will only work for amd64. Then rebuild libgcc with clang, and please try if this fixes at least some of the crashes... This is at least the direction I'm looking at. It seems that in some cases with __builtin_eh_return(), llvm does not see that registers can be clobbered, and it doesn't save and restore them. After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. Here is a side-by-side overview of the output; sorry for going over any 72-char margin, but this is for illustration. You can see that gcc saves most registers on the stack, and restores them just before the eh return. Clang does not, at least by default: GCC OUTPUT CLANG OUTPUT = = _Unwind_Resume: _Unwind_Resume: # @_Unwind_Resume pushq %rbppushq %rbp movq%rsp, %rbp movq %rsp, %rbp pushq %r15pushq %rdx pushq %r14pushq %rax pushq %r13subq $528, %rsp # imm = 0x210 pushq %r12movq %rdi, -24(%rbp) pushq %rbxmovq %rbp, %rdi pushq %rdxaddq $16, %rdi pushq %raxmovq 8(%rbp), %rdx subq$536, %rsp leaq -264(%rbp), %rcx movq%rdi, -584(%rbp)movq %rdi, -536(%rbp)# 8-byte Spill movq8(%rbp), %rax movq %rcx, %rdi movq%rax, %rdx movq -536(%rbp), %rsi# 8-byte Reload leaq16(%rbp), %rsi callq uw_init_context_1@PLT leaq-336(%rbp), %rdimovabsq $240, %rdx calluw_init_context_1@PLT leaq -264(%rbp), %rcx leaq-576(%rbp), %rdileaq -504(%rbp), %rsi leaq-336(%rbp), %rsimovq %rsi, %rdi movl$240, %edx movq %rcx, %rsi callmemcpy@PLT callq memcpy@PLT movq-584(%rbp), %raxmovq -24(%rbp), %rcx movq16(%rax), %rax cmpq $0, 16(%rcx) testq %rax, %rax jne .LBB0_2 jne .L59leaq -504(%rbp), %rsi leaq-576(%rbp), %rsimovq -24(%rbp), %rdi movq-584(%rbp), %rdicallq _Unwind_RaiseException_Phase2@PLT call_Unwind_RaiseException_Phase2@PLT movl %eax, -508(%rbp) movl%eax, -84(%rbp) jmp .LBB0_3 jmp .L61.LBB0_2: # %if.else .L59: leaq -504(%rbp), %rsi leaq-576(%rbp), %rsimovq -24(%rbp), %rdi movq-584(%rbp), %rdicallq _Unwind_ForcedUnwind_Phase2@PLT call_Unwind_ForcedUnwind_Phase2@PLT movl %eax, -508(%rbp) movl%eax, -84(%rbp) .LBB0_3: # %if.end .L61: cmpl $7, -508(%rbp) cmpl$7, -84(%rbp) je .LBB0_5 je .L62callq abort@PLT
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Jan 06, 2013 at 04:51:11PM +, David Chisnall wrote: > On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: > > > No. It's completely broken at all optimization levels. There do not > > appear to be any flags that change the behavior. Building unwind-dw2.c > > either with gcc or with the previous import of clang in our tree does > > fix it, however. > > Do you have an LLVM PR# for this that I can follow? There's http://llvm.org/bugs/show_bug.cgi?id=8541 which I think should be reopened. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: > No. It's completely broken at all optimization levels. There do not > appear to be any flags that change the behavior. Building unwind-dw2.c > either with gcc or with the previous import of clang in our tree does > fix it, however. Do you have an LLVM PR# for this that I can follow? David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/06/13 11:46, David Chisnall wrote: > On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote: > >> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >>> Here's a minimal test case that reproduces the bug: >> [...] >> >> Until someone fixes this bug, could we apply something like this as a >> work-around? >> >> Stefan >> >> Index: gnu/lib/libgcc/Makefile >> === >> --- gnu/lib/libgcc/Makefile (revision 245055) >> +++ gnu/lib/libgcc/Makefile (working copy) >> @@ -6,6 +6,8 @@ >> SHLIB_NAME= libgcc_s.so.1 >> SHLIBDIR?= /lib >> >> +CC= gcc >> + >> .include >> # >> # libgcc is linked in last and thus cannot depend on ssp symbols coming > > This will break the build entirely for those of us who build without gcc, and > as we are planning on removing gcc entirely by the 10.0 timeframe we should > be encouraging people to do this, not discouraging it. > > Does compiling at a lower optimisation level (-O1? -O0) work as a temporary > fix? > No. It's completely broken at all optimization levels. There do not appear to be any flags that change the behavior. Building unwind-dw2.c either with gcc or with the previous import of clang in our tree does fix it, however. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 6 Jan 2013, at 14:17, Stefan Farfeleder wrote: > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >> Here's a minimal test case that reproduces the bug: > [...] > > Until someone fixes this bug, could we apply something like this as a > work-around? > > Stefan > > Index: gnu/lib/libgcc/Makefile > === > --- gnu/lib/libgcc/Makefile (revision 245055) > +++ gnu/lib/libgcc/Makefile (working copy) > @@ -6,6 +6,8 @@ > SHLIB_NAME= libgcc_s.so.1 > SHLIBDIR?=/lib > > +CC= gcc > + > .include > # > # libgcc is linked in last and thus cannot depend on ssp symbols coming This will break the build entirely for those of us who build without gcc, and as we are planning on removing gcc entirely by the 10.0 timeframe we should be encouraging people to do this, not discouraging it. Does compiling at a lower optimisation level (-O1? -O0) work as a temporary fix? David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/06/13 10:29, Nathan Whitehorn wrote: > On 01/06/13 09:59, Dimitry Andric wrote: >> On 2013-01-06 15:17, Stefan Farfeleder wrote: >>> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: >>> [...] >>> >>> Until someone fixes this bug, could we apply something like this as a >>> work-around? >>> >>> Stefan >>> >>> Index: gnu/lib/libgcc/Makefile >>> === >>> --- gnu/lib/libgcc/Makefile(revision 245055) >>> +++ gnu/lib/libgcc/Makefile(working copy) >>> @@ -6,6 +6,8 @@ >>> SHLIB_NAME=libgcc_s.so.1 >>> SHLIBDIR?=/lib >>> >>> +CC=gcc >>> + >>> .include >> >> I think this is a bit overkill approach. We still don't know what the >> exact cause of the problem is, and this just papers over it. >> >> Also, ince the bug is only reproducible by compiling the testcase with >> g++, could you not compile your crashing programs with clang instead, >> for now? :-) >> > > I would very much support this patch. Whatever is going wrong is a > critical problem -- although his testcase requires g++, I have lots of > code that also crashes when built with clang. The fact that *any* code > built with *any* compiler crashes when used with clang-built libgcc is > an error. This is quite serious and breaks a *lot* of C++ code. If it > can't be fixed now, papering it over is required. > -Nathan For whatever it's worth, I verified that this is the same bug I was seeing earlier: only unwind-dw2.c is being miscompiled. The preprocessed versions of this file are identical with both gcc and clang and the problem occurs at all optimization levels with it is built with clang. I tried replacing as many of the __builtin functions as a could with thunks to the gcc versions, with no positive result. The ones I could not replace are __builtin_return_address, __builtin_dwarf_cfa, and __builtin_eh_return. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: > On 2013-01-06 15:17, Stefan Farfeleder wrote: > > On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > >> Here's a minimal test case that reproduces the bug: > > [...] > > > > Until someone fixes this bug, could we apply something like this as a > > work-around? > > > > Stefan > > > > Index: gnu/lib/libgcc/Makefile > > === > > --- gnu/lib/libgcc/Makefile (revision 245055) > > +++ gnu/lib/libgcc/Makefile (working copy) > > @@ -6,6 +6,8 @@ > > SHLIB_NAME= libgcc_s.so.1 > > SHLIBDIR?=/lib > > > > +CC=gcc > > + > > .include > > I think this is a bit overkill approach. We still don't know what the > exact cause of the problem is, and this just papers over it. It seems unwise to install a known-to-be-broken libgcc by default, even though the exact cause is not known yet. > Also, ince the bug is only reproducible by compiling the testcase with > g++, could you not compile your crashing programs with clang instead, > for now? :-) The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/06/13 09:59, Dimitry Andric wrote: > On 2013-01-06 15:17, Stefan Farfeleder wrote: >> On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: >>> Here's a minimal test case that reproduces the bug: >> [...] >> >> Until someone fixes this bug, could we apply something like this as a >> work-around? >> >> Stefan >> >> Index: gnu/lib/libgcc/Makefile >> === >> --- gnu/lib/libgcc/Makefile(revision 245055) >> +++ gnu/lib/libgcc/Makefile(working copy) >> @@ -6,6 +6,8 @@ >> SHLIB_NAME=libgcc_s.so.1 >> SHLIBDIR?=/lib >> >> +CC=gcc >> + >> .include > > I think this is a bit overkill approach. We still don't know what the > exact cause of the problem is, and this just papers over it. > > Also, ince the bug is only reproducible by compiling the testcase with > g++, could you not compile your crashing programs with clang instead, > for now? :-) > I would very much support this patch. Whatever is going wrong is a critical problem -- although his testcase requires g++, I have lots of code that also crashes when built with clang. The fact that *any* code built with *any* compiler crashes when used with clang-built libgcc is an error. This is quite serious and breaks a *lot* of C++ code. If it can't be fixed now, papering it over is required. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2013-01-06 15:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?=/lib +CC=gcc + .include I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: > Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME=libgcc_s.so.1 SHLIBDIR?= /lib +CC=gcc + .include # # libgcc is linked in last and thus cannot depend on ssp symbols coming ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 10:23:34PM +0200, Konstantin Belousov wrote: > > 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. FWIW, the diff between working and non-working assembler can be found at http://people.freebsd.org/~stefanf/tmp/libgcc_s.s.diff . Not that I expect much from that. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 01/04/13 15:23, Konstantin Belousov wrote:
> 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:
$ 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=0x7fffd62fe8, __a=@0x7fffd628)
>> at atomicity.h:69
>> 69 _Atomic_word __result = *__mem;
>> (gdb) bt
>> #0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8,
>> __a=@0x7fffd628)
>> at atomicity.h:69
>> #1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
>> at basic_string.h:482
>> #2 0x00401038 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, 0x000800d420b4 in _Unwind_RaiseException ()
>>from /lib/libgcc_s.so.1
>> (gdb) f 2
>> #2 0x00400f51 in f2 () at throw-crash.cc:5
>> 5 throw std::runtime_error("foo");
>> (gdb) p &s
>> $1 = (string *) 0x7fffd600
>> (gdb) up
>> #3 0x00400fe2 in main () at throw-crash.cc:15
>> 15 f1();
>> (gdb) p &s1
>> $2 = (string *) 0x7fffd650
>> (gdb) p &s2
>> $3 = (string *) 0x7fffd640
>>
>> (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=0x7fffd600) at basic_string.h:279
>> 279 _M_data() const
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
>> 279 _M_data() const
>> (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
>>
>> 279 _M_data() const
>>
>> So, the address of s2 is 0x7fffd640, but the dtor is called with
>> 0x7fffd60f 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.
>
If this is the same bug I was seeing, recompiling only the file
unwind-dw2.c in libgcc with GCC/old clang, leaving everything else the
same, fixed everything. This would lead me to suspect an error in one of
the many __builtins called by unwind-dw2.c.
-Nathan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 01/04/2013 12:23, Konstantin Belousov wrote:
> 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:
$ 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=0x7fffd62fe8,
>> __a=@0x7fffd628) at atomicity.h:69 69 _Atomic_word
>> __result = *__mem; (gdb) bt #0 std::string::_Rep::_M_dispose
>> (this=0x7fffd62fe8, __a=@0x7fffd628) at atomicity.h:69 #1
>> 0x00080089d168 in ~basic_string (this=0x7fffd62fe8) at
>> basic_string.h:482 #2 0x00401038 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, 0x000800d420b4 in _Unwind_RaiseException ()
>> from /lib/libgcc_s.so.1 (gdb) f 2 #2 0x00400f51 in f2 ()
>> at throw-crash.cc:5 5 throw std::runtime_error("foo");
>> (gdb) p &s $1 = (string *) 0x7fffd600 (gdb) up #3
>> 0x00400fe2 in main () at throw-crash.cc:15 15
>> f1(); (gdb) p &s1 $2 = (string *) 0x7fffd650 (gdb) p &s2 $3 =
>> (string *) 0x7fffd640 (gdb) b 'std::basic_string> std::char_traits, std::allocator >::~basic_string()'
>> Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
>> (gdb) c Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd600) at
>> basic_string.h:279 279 _M_data() const (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd640) at
>> basic_string.h:279 279 _M_data() const (gdb) c
>> Continuing.
>>
>> Breakpoint 3, ~basic_string (this=0x7fffd60f) at
>> basic_string.h:279 279 _M_data() const
>>
>> So, the address of s2 is 0x7fffd640, but the dtor is called
>> with 0x7fffd60f 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.
>
Since this is similar to the pain I was seeing rebuilding everything
with clang so I have been following this thread with much interest.
Just to add more data, I get different results. This is all i386.
gcc v464 built using an earlier clang from -current world/kernel
r243027. boost was also built using this revision.
$ /usr/local/bin/g++46 -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x2806e000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c2000)
libm.so.5 => /lib/libm.so.5 (0x281a1000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c2000)
libc.so.7 => /lib/libc.so.7 (0x281cd000)
libthr.so.3 => /lib/libthr.so.3 (0x28317000)
[atkinson@moby ~/dev]$ ./unwinder
Abort trap (core dumped)
clang 32 built from -current world/kernel r244958 works just fine.
$ c++ -O2 -I/usr/local/include -L/usr/local/lib
- -lboost_program_options -o unwinder unwinder.cc
[atkinson@moby ~/dev]$ ./unwinder
[atkinson@moby ~/dev]$ ldd unwinder
unwinder:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x2806d000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x280c1000)
libm.so.5 => /lib/libm.so.5 (0x281a)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x281c1000)
libc.so.7 => /lib/libc.so.7 (0x281cc000)
libthr.so.3 => /lib/libthr.so.3 (0x28316000)
It might be useful to exp
Re: clang 3.2 RC2 miscompiles libgcc?
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:
> > >
> > > $ 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=0x7fffd62fe8, __a=@0x7fffd628)
> at atomicity.h:69
> 69 _Atomic_word __result = *__mem;
> (gdb) bt
> #0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
> at atomicity.h:69
> #1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
> at basic_string.h:482
> #2 0x00401038 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, 0x000800d420b4 in _Unwind_RaiseException ()
>from /lib/libgcc_s.so.1
> (gdb) f 2
> #2 0x00400f51 in f2 () at throw-crash.cc:5
> 5 throw std::runtime_error("foo");
> (gdb) p &s
> $1 = (string *) 0x7fffd600
> (gdb) up
> #3 0x00400fe2 in main () at throw-crash.cc:15
> 15 f1();
> (gdb) p &s1
> $2 = (string *) 0x7fffd650
> (gdb) p &s2
> $3 = (string *) 0x7fffd640
>
> (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=0x7fffd600) at basic_string.h:279
> 279 _M_data() const
> (gdb) c
> Continuing.
>
> Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
> 279 _M_data() const
> (gdb) c
> Continuing.
>
> Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
>
> 279 _M_data() const
>
> So, the address of s2 is 0x7fffd640, but the dtor is called with
> 0x7fffd60f 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.
pgpM6TAs72wPh.pgp
Description: PGP signature
Re: clang 3.2 RC2 miscompiles libgcc?
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=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
69 _Atomic_word __result = *__mem;
(gdb) bt
#0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
#1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
at basic_string.h:482
#2 0x00401038 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, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1
(gdb) f 2
#2 0x00400f51 in f2 () at throw-crash.cc:5
5 throw std::runtime_error("foo");
(gdb) p &s
$1 = (string *) 0x7fffd600
(gdb) up
#3 0x00400fe2 in main () at throw-crash.cc:15
15 f1();
(gdb) p &s1
$2 = (string *) 0x7fffd650
(gdb) p &s2
$3 = (string *) 0x7fffd640
(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=0x7fffd600) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called with
0x7fffd60f which is also very unaligned. I think this is the reason
for the crash.
Stefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
> On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
> > On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
> > >
> > > I have been playing with Stefan's testcase for a while now, and while I
> > > can reproduce the crashes, I am still at a loss about the cause. It
> > > does seem to have something to do with throwing exceptions, but I am
> > > still not sure whether I am looking at a bug in boost, gcc, clang, or
> > > libgcc...
> > >
> > > Do you happen to have a smaller testcase, by any chance?
> >
> > Not yet, but I'll try to come up with something smaller.
>
> 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.
pgpqQWwruELDD.pgp
Description: PGP signature
Re: clang 3.2 RC2 miscompiles libgcc?
On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
> On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
> >
> > I have been playing with Stefan's testcase for a while now, and while I
> > can reproduce the crashes, I am still at a loss about the cause. It
> > does seem to have something to do with throwing exceptions, but I am
> > still not sure whether I am looking at a bug in boost, gcc, clang, or
> > libgcc...
> >
> > Do you happen to have a smaller testcase, by any chance?
>
> Not yet, but I'll try to come up with something smaller.
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
Stefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2 January 2013 08:59, Stefan Farfeleder wrote: > On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: >> >> I have been playing with Stefan's testcase for a while now, and while I >> can reproduce the crashes, I am still at a loss about the cause. It >> does seem to have something to do with throwing exceptions, but I am >> still not sure whether I am looking at a bug in boost, gcc, clang, or >> libgcc... >> >> Do you happen to have a smaller testcase, by any chance? > > Not yet, but I'll try to come up with something smaller. Take a look at devel/delta as well as creduce (require ToT clang so it is unported at this time) to help you with finding minimal testcase. If you need help, let me know. -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: > > I have been playing with Stefan's testcase for a while now, and while I > can reproduce the crashes, I am still at a loss about the cause. It > does seem to have something to do with throwing exceptions, but I am > still not sure whether I am looking at a bug in boost, gcc, clang, or > libgcc... > > Do you happen to have a smaller testcase, by any chance? Not yet, but I'll try to come up with something smaller. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 2012-12-27 16:15, Nathan Whitehorn wrote: On 12/27/12 09:07, Stefan Farfeleder wrote: I noticed that most of my C++ applications in recent versions of FreeBSD head suddenly crash without me recompiling them. I tracked it down to r243830 which imported a new clang version. The new clang seems to compile libgcc in a wrong or at least incompatible way with what gcc expects. In fact, the breakage only occurs with libgcc compiled by a post-r243830 clang and an application compiled with g++ -O2. For me, the crash happens with boost::program_options, but I'm not sure if that is necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On Thu, Dec 27, 2012 at 09:15:01AM -0600, Nathan Whitehorn wrote: > On 12/27/12 09:07, Stefan Farfeleder wrote: > > Hi, > > > > I noticed that most of my C++ applications in recent versions of FreeBSD > > head suddenly crash without me recompiling them. I tracked it down to > > r243830 which imported a new clang version. The new clang seems to > > compile libgcc in a wrong or at least incompatible way with what gcc > > expects. In fact, the breakage only occurs with libgcc compiled by a > > post-r243830 clang and an application compiled with g++ -O2. For me, the > > crash happens with boost::program_options, but I'm not sure if that is > > necessary for the crash. > > I've seen what I think is the same thing due to a miscompilation of > unwind-dw2.c that caused crashes related to cross-shared-object > exception handling. It seems to have been fixed with the 3.2 release but > I haven't tested it too thoroughly yet. Thanks for the confirmation. The cross-dso requirement would explain why my simpler approaches to reproduce it didn't work. But for me there's no difference between RC2 and release (FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221), both cause my applications to crash. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: clang 3.2 RC2 miscompiles libgcc?
On 12/27/12 09:07, Stefan Farfeleder wrote: > Hi, > > I noticed that most of my C++ applications in recent versions of FreeBSD > head suddenly crash without me recompiling them. I tracked it down to > r243830 which imported a new clang version. The new clang seems to > compile libgcc in a wrong or at least incompatible way with what gcc > expects. In fact, the breakage only occurs with libgcc compiled by a > post-r243830 clang and an application compiled with g++ -O2. For me, the > crash happens with boost::program_options, but I'm not sure if that is > necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
clang 3.2 RC2 miscompiles libgcc?
Hi,
I noticed that most of my C++ applications in recent versions of FreeBSD
head suddenly crash without me recompiling them. I tracked it down to
r243830 which imported a new clang version. The new clang seems to
compile libgcc in a wrong or at least incompatible way with what gcc
expects. In fact, the breakage only occurs with libgcc compiled by a
post-r243830 clang and an application compiled with g++ -O2. For me, the
crash happens with boost::program_options, but I'm not sure if that is
necessary for the crash.
$ cat po.cc
#include
int main(void) {
namespace po = boost::program_options;
const char *argv[] = { "a.out", "-x", 0 };
po::options_description options("Options");
options.add_options()("bla", "");
try {
po::variables_map vm;
po::store(po::parse_command_line(2, argv, options), vm);
notify(vm);
return 0;
} catch (const std::exception &ex) {
return 1;
}
}
$ g++ -O2 -I /usr/local/include -L /usr/local/lib -lboost_program_options po.cc
$ ./a.out
zsh: segmentation fault (core dumped) ./a.out
$ ldd ./a.out
./a.out:
libboost_program_options.so =>
/usr/local/lib/libboost_program_options.so (0x800821000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x800a7e000)
libm.so.5 => /lib/libm.so.5 (0x800d7c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x800f9e000)
libc.so.7 => /lib/libc.so.7 (0x8011ab000)
libthr.so.3 => /lib/libthr.so.3 (0x801523000)
$ ls /usr/home/stefan/scratch/r243829
libgcc_s.so.1
$ LD_LIBRARY_PATH=/usr/home/stefan/scratch/r243829 ./a.out
$ valgrind ./a.out
==47491== Memcheck, a memory error detector
==47491== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==47491== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==47491== Command: ./a.out
==47491==
==47491== Invalid read of size 8
==47491==at 0x405DAA: boost::program_options::basic_parsed_options
boost::program_options::parse_command_line(int, char const* const*,
boost::program_options::options_description const&, int,
boost::function1, std::string const&>) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491== Address 0x2800ef8 is 24 bytes inside a block of size 27 alloc'd
==47491==at 0x1009FB6: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==47491==by 0x213F95A: operator new(unsigned long) (in
/usr/lib/libsupc++.so.1)
==47491==by 0x14F08D2: ??? (in /usr/lib/libstdc++.so.6)
==47491==by 0x14EDCFD: std::basic_string,
std::allocator >::basic_string(std::string const&, unsigned long,
unsigned long) (in /usr/lib/libstdc++.so.6)
==47491==by 0x1234B12:
boost::program_options::detail::cmdline::parse_short_option(std::vector >&) (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x123843A:
boost::detail::function::function_obj_invoker1,
std::allocator > >,
boost::_mfi::mf1,
std::allocator > >,
boost::program_options::detail::cmdline, std::vector >&>,
boost::_bi::list2,
boost::arg<1> > >, std::vector,
std::allocator > >,
std::vector
>&>::invoke(boost::detail::function::function_buffer&, std::vector >&) (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x12367C1: boost::program_options::detail::cmdline::run() (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x4051D5:
boost::program_options::basic_command_line_parser::run() (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x405B7A: boost::program_options::basic_parsed_options
boost::program_options::parse_command_line(int, char const* const*,
boost::program_options::options_description const&, int,
boost::function1, std::string const&>) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491==
==47491== Jump to the invalid address stated on the next line
==47491==at 0x782D: ???
==47491==by 0x405DBF: boost::program_options::basic_parsed_options
boost::program_options::parse_command_line(int, char const* const*,
boost::program_options::options_description const&, int,
boost::function1, std::string const&>) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491== Address 0x782d is not stack'd, malloc'd or (recently) free'd
==47491==
==47491==
==47491== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==47491== Bad permissions for mapped region at address 0x782D
==47491==at 0x782D: ???
==47491==by 0x405DBF: boost::program_options::basic_parsed_options
boost::program_options::parse_command_line(int, char const* const*,
boost::program_options::options_description const&, int,
boost::function1, std::string const&>) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491==
==47491== HEAP SUMMARY:
==47491== in use at exit: 2,298 bytes in 24 blocks
