Bug 234672 - www/chromium: c++: error: unable to execute command: Segmentation fault (core dumped)
Summary: www/chromium: c++: error: unable to execute command: Segmentation fault (core...
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: arm64 Any
: --- Affects Only Me
Assignee: freebsd-chromium mailing list
URL:
Keywords: crash, needs-qa
Depends on:
Blocks:
 
Reported: 2019-01-06 21:55 UTC by Bob Prohaska
Modified: 2019-01-20 17:54 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (chromium)


Attachments
diagnostic files generated by clang (7.63 KB, application/x-shellscript)
2019-01-06 21:55 UTC, Bob Prohaska
no flags Details
Clang segfault diagnostic file (1 of 2) (301.44 KB, text/plain)
2019-01-07 18:01 UTC, Bob Prohaska
no flags Details
Clang segfault diagnostic file (2 of 2) (5.24 KB, application/x-shellscript)
2019-01-07 18:03 UTC, Bob Prohaska
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Bob Prohaska 2019-01-06 21:55:08 UTC
Created attachment 200848 [details]
diagnostic files generated by clang

Tried to compile www/chromium on rpi3 at r342781M using four swap partitions,
3 usb and 1 microSD.

M on revision is for
https://people.freebsd.org/~gonzo/arm/patches/vchiq-wip-20180217.diff
which seems unlikely to be the cause.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2019-01-07 04:08:28 UTC
@Bob Could you please:

- Attach the patch in question that is in use with this port
- Attempt to reproduce and confirm the issue (crash) is apparent without that patch
Comment 2 Bob Prohaska 2019-01-07 04:38:14 UTC
The patch attempted was found here:
https://people.freebsd.org/~gonzo/arm/patches/vchiq-wip-20180217.diff

It has been backed out and the system is rebuilding. I'll then try compiling
www/chromium again.
Comment 3 Bob Prohaska 2019-01-07 18:01:34 UTC
Created attachment 200875 [details]
Clang segfault diagnostic file (1 of 2)
Comment 4 Bob Prohaska 2019-01-07 18:03:07 UTC
Created attachment 200876 [details]
Clang segfault diagnostic file (2 of 2)
Comment 5 Carlos J. Puga Medina freebsd_committer 2019-01-07 20:02:44 UTC
(In reply to Bob Prohaska from comment #0)

Surely there is some problem that mitigate with clang 7.0.1 on aarch64. Let's see if Oleksandr can shed some light.
Comment 6 Bob Prohaska 2019-01-09 17:47:11 UTC
(In reply to Bob Prohaska from comment #2)

The audio patch has been backed out, the running kernel is now
up to r342855. Sources are at r342874

All attempts to make buildworld result in segmentation faults in clang.
Make toolchain is running now and seems better-behaved.

The system appears reasonably well-behaved (no console errors or hardware
faults reported) apart from the errors in clang. 

The difficulties only emerged when running a version of clang compiled with
the patched kernel. It's almost as if clang and only clang got corrupted
by rebuilding with the patched kernel.
Comment 7 Bob Prohaska 2019-01-15 16:48:13 UTC
(In reply to Bob Prohaska from comment #6)
The system has been updated to 
13.0-CURRENT FreeBSD 13.0-CURRENT r342987 GENERIC  arm64
and segfaults persist, even when make is run without -j.
Comment 8 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-16 07:51:07 UTC
This looks more like clang-related crash than ARM-specific. I'll try to take a look but my expertise in this area is not great. Adding dim@ to Cc, he may be aware of known problems with clang/ARM in the latest release.
Comment 9 Dimitry Andric freebsd_committer 2019-01-16 20:56:42 UTC
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.
Comment 10 Bob Prohaska 2019-01-16 21:39:22 UTC
(In reply to Dimitry Andric from comment #9)

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?
Comment 11 Dimitry Andric freebsd_committer 2019-01-17 18:57:38 UTC
(In reply to Bob Prohaska from comment #10)
> (In reply to Dimitry Andric from comment #9)
> 
> Here's the latest segfault message, generated using make buildworld (with
> no -j) on r342987, from sources at 343001
...
> -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

I've tried these files, but they compile just fine for me.  However, this is on an amd64 host machine.  I haven't tried it on an aarch64 machine, but I suspect that there is either something wrong with your aarch64 host, or with your installation


> 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?

It is probably easiest to extract them from a snapshot. E.g. from here: https://download.freebsd.org/ftp/snapshots/arm64/13.0-CURRENT/ download the base.txz file, extract it into a temp dir, and get the usr/bin/clang executable (and maybe also lld) from there.
Comment 12 Bob Prohaska 2019-01-20 17:54:32 UTC
Attempts to work through the crashes by cleaning up and restarting
buildworld have so far proved ineffective. Clang still stops with
signal 11's or internal higher-numbered (e.g., 254) errors fairly regularly.

Oddly enough, chromium (the browser) seems to work alright, if slowly,
and no errors apart from clang are evident.

The only complaint other than from clang occurs when starting chromium:

[83827:1218383872:0120/075747.927080:ERROR:gpu_process_transport_factory.cc(1016)] Lost UI shared context.
[84111:1339003392:0120/075753.574384:ERROR:command_buffer_proxy_impl.cc(113)] ContextResult::kFatalFailure: Shared memory handle is not valid

Still, chromium does not crash.

In any case, this does not seem to be a chromium issue so this particular
bug report might as well be closed.

Thanks for everyone's attention,

bob prohaska