Bug 234672

Comment 1 Kubilay Kocak 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

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)

Comment 5 Carlos J. Puga Medina 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.

(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.

Comment 8 Oleksandr Tymoshenko 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 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.

(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 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.

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.

Comment 15 Ed Maste 2020-05-27 12:56:29 UTC

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

Comment 17 Graham Perrin 2022-11-20 00:36:21 UTC

Still an issue?

Comment 18 Dimitry Andric 2022-11-20 10:12:13 UTC

Let's assume these problems went away in the mean time. Please create a new PR if something similar happens again.