Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 16 Jan 2019 13:45:08 -0800
From:      bob prohaska <fbsd@www.zefox.net>
To:        freebsd-arm@freebsd.org
Subject:   Re: [Bug 234672] www/chromium: c++: error: unable to execute command: Segmentation fault (core dumped)
Message-ID:  <20190116214508.GA5922@www.zefox.net>
In-Reply-To: <bug-234672-35337-yWOOnawHCZ@https.bugs.freebsd.org/bugzilla/>
References:  <bug-234672-35337@https.bugs.freebsd.org/bugzilla/> <bug-234672-35337-yWOOnawHCZ@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 16, 2019 at 08:56:42PM +0000, bugzilla-noreply@freebsd.org wrote:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234672
> 
> --- Comment #9 from Dimitry Andric <dim@FreeBSD.org> ---
> I tried the sprintf-4b97e4.{c,sh} test case, and that compiles without any
> problem for me, with clang 7.0.1 on head r342759.  I also tried clang 6.0.1
> succesfully.
> 
> The other test case, partial_circular_buffer-563908.sh, is missing the
> corresponding .cpp file, so I can't evaluate it.
> 

Here's the latest segfault message, generated using make buildworld (with
no -j) on r342987, from sources at 343001
......
/usr/obj/usr/src/arm64.aarch64/tmp/usr/include/openssl/opensslconf.h:107:55: note: 
      expanded from macro 'DECLARE_DEPRECATED'
#   define DECLARE_DEPRECATED(f)    f __attribute__ ((deprecated));
                                                      ^
1 warning generated.
cc: error: unable to execute command: Segmentation fault (core dumped)
cc: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1)
Target: aarch64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin
cc: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
cc: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
cc: note: diagnostic msg: /tmp/serverloop-a25e04.c
cc: note: diagnostic msg: /tmp/serverloop-a25e04.sh
cc: note: diagnostic msg: 

********************
root@www:/usr/src # 
root@www:/usr/src # find /usr/obj -name serverloop.o -depth -print
root@www:/usr/src # ls -l /tmp/serverloop-a25e04.*
-rw-r--r--  1 root  wheel  2320872 Jan 16 12:41 /tmp/serverloop-a25e04.c
-rw-r--r--  1 root  wheel     4056 Jan 16 12:41 /tmp/serverloop-a25e04.sh

The end of the build log contains:
cc -target aarch64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin  -O2 -pipe   -I/usr/src/crypto/openssh -include ssh_namespace.h -DHAVE_LDNS=1 -DUSE_BSM_AUDIT=1 -DHAVE_GETAUDIT_ADDR=1 -DUSE_BLACKLIST=1 -I/usr/src/contrib/blacklist/include -include krb5_config.h -DLIBWRAP=1 -g -MD  -MF.depend.serverloop.o -MTserverloop.o -std=gnu99 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses  -Qunused-arguments  -c /usr/src/crypto/openssh/serverloop.c -o serverloop.o
*** Error code 254

Stop.
make[5]: stopped in /usr/src/secure/usr.sbin/sshd
*** Error code 1

Stop.
make[4]: stopped in /usr/src/secure/usr.sbin
*** Error code 1

Stop.
make[3]: stopped in /usr/src/secure
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

make: stopped in /usr/src

The diagnostic files are at
http://www.zefox.net/~fbsd/rpi3/swaptests/r342987/

It's starting to look as if I've somehow corrupted my clang installation.
Is it possible to download a precompiled binary, akin to a package, as a
workaround? Failing that, a compilation sequence that more thoroughly 
sanitizes the buildworld process? The most careful sequence tried to
date was kernel-toolchain, installkernel, reboot, then buildworld.

Thanks for reading!

bob prohaska




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190116214508.GA5922>