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.
@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
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.
Created attachment 200875 [details] Clang segfault diagnostic file (1 of 2)
Created attachment 200876 [details] Clang segfault diagnostic file (2 of 2)
(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.
(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.
(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.
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.
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.
(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?
(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.
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
There's a seemingly unrelated bug report at https://github.com/android-ndk/ndk/issues/386 in which an i386 host cross-compiling for arm64 using clang segfaults repeatedly, much as I'm seeing in, first, chromium and then buildworld. IIUC the problem is on the arm64 side of the compiler. Most curiously, using the suggested workaround of setting CFLAGS=-O2 in /etc/make.conf seems to help. On the first buildworld signal 11's were seen early in buildworld but grew scarce with repetition. So far it looks as if three OS build and install cycles might be enough to flush out the problem. The bug report indicates a fix in place as of nearly a year ago. I'd think freebsd-arm would have it by now, but....
Adding CFLAGS=-O2 to /etc/make.conf _almost_ fixed the clang segfaults, there was still one signal 11 error, IIRC somewhat past halfway through the build. After restarting make, chromium compiled successfully. While not perfect, it represents a huge improvement. Chrome failed to run, with the glib error reported in Bug 220103. /usr/ports is updating now and I'll try again.
Clang has been updated a couple of times since this issue was observed - have you tried building again more recently?
(In reply to Ed Maste from comment #15) No, I have not. The Pi3 in use has been switched in the meantime to FreeBSD 12.1-STABLE r361429 GENERIC. Xorg seems to be broken in that version, discussed in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246319 The storage configuration is different now, / is on a mechanical hard disk, /ports would have to be on microSD with swap partitions on each device. If that would still be interesting please let me know and I'll try. Thanks for reading, bob prohaska
Still an issue?
Let's assume these problems went away in the mean time. Please create a new PR if something similar happens again.