FreeBSD 13.0 - amd64: clang generates segmentation fault during compilation

Have experienced clang crash during compilation on FreeBSD 13.0?

  • yes

    Votes: 0 0.0%
  • no

    Votes: 5 100.0%
  • unsure / not checked

    Votes: 0 0.0%

  • Total voters
    5
  • Poll closed .
Hi,

I've installed the newest FreeBSD 13.0 amd64 via Qemu with x86-64 native emulation. I started from minimal installation after which I installed gcc and vim and I think... probably nothing more.
I had an issue when making FreeBSD buildworld. I have managed to isolate the issue and it turns out that clang (which seems to be compiling a /usr/src compilation) is unable to compile a simple program.

Compiling simple program steps (first part - clang crash):
Code:
root@fb:~ # clang test.c
PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script.
Stack dump:
0.      Program arguments: clang test.c
1.      Compilation construction
2.      Building compilation jobs
3.      Building compilation jobs
4.      Building compilation jobs
5.      Computing output path
Segmentation fault (core dumped)
root@fb:~ # gcc test.c
root@fb:~ # ./a.out
root@fb:~ # cat test.c
int main() {
    return 0;
}

root@fb:~ # uname -a
FreeBSD fb 13.0-RELEASE FreeBSD 13.0-RELEASE #0 releng/13.0-n244733-ea31abc261f: Fri Apr  9 04:24:09 UTC 2021     [EMAIL]root@releng1.nyi.freebsd.org[/EMAIL]:/usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
root@fb:~ # clang --version
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)

When running a compilation with clang under gdb:
# gdb --args clang test.c
Code:
Reading symbols from clang...
(No debugging symbols found in clang)
(gdb) run
Starting program: /usr/bin/clang test.c

Program received signal SIGSEGV, Segmentation fault.
0x0000000804ec556a in ?? () from /lib/libc.so.7
(gdb) bt
#0  0x0000000804ec556a in ?? () from /lib/libc.so.7
#1  0x0000000804ec533a i[B]n arc4random () from /lib/libc.so.7[/B]
#2  0x0000000003b1890b in ?? ()
#3  0x0000000003b18b13 in ?? ()
#4  0x0000000003b18f0a in ?? ()
#5  0x0000000003b18f78 in ?? ()
#6  0x0000000001fb07af in ?? ()
#7  0x0000000001fb8cf0 in ?? ()
#8  0x0000000001fb72e5 in ?? ()
#9  0x0000000001fb579f in ?? ()
#10 0x0000000001fb67a3 in ?? ()
#11 0x0000000001fb579f in ?? ()
#12 0x0000000001fad0f0 in ?? ()
#13 0x0000000001fa767e in ?? ()
#14 0x00000000018b3e8e in ?? ()
#15 0x00000000018a7070 in ?? ()
#16 0x00000000018a6f70 in ?? ()
#17 0x0000000000000000 in ?? ()
(gdb)
Clang has no debug symbols compiled, so I cannot say much from the above except arc4random and libc involved.
uint32_t arc4random(void) is a random number generator and it works when it is compiled with gcc into a program (also a trivial implementation).

The program in test.c is extremely simple, test.c:
C:
int main() {
    return 0;
}

Notice, that I have very little experience with BSD systems. Therefore although it was only a simple installation, I would rather suspect that I'm doing something wrong if such basic thing like compiler crashes. On the other hand maybe there is some conflict on libc between clang and gcc.

BTW. I think I did not install the clang with pkg, it was default in the system.

Do you have any idea how to fix the issue or to continue investigation?
Do you experience the same issue or can you reproduce?

Should I submit a bug report?
 
You might want to check your memory for failures. Code compiles just fine.

Code:
dice@chibacity:~/test % freebsd-version
13.0-RELEASE
dice@chibacity:~/test % cat test.c
int main() {
    return 0;
}
dice@chibacity:~/test % clang test.c
dice@chibacity:~/test % ls
a.out   test.c
 
I'd suggest first compiling devel/llvm11 from ports... and enable every option you can. It's very likely that you have a pre-compiled package. You can also do devel/llvm12 or devel/llvm80 if you like... My point is, if you compile LLVM/Clang on your system from ports, it will be more cooperative with your system, and not dump core.

As an aside, generally pre-compiled packages on FreeBSD are compiled with very conservative options (I saw that on the email lists). So a few details like upper limits of memory addresses can by chance get hard-coded by accident, and end up crashing the program when it's run on a different system.
 
It's very likely that you have a pre-compiled package.
clang(1) 11.0.1 is part of the base OS.
Code:
dice@molly:~ % clang -v
FreeBSD clang version 11.0.1 (git@github.com:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe)
Target: x86_64-unknown-freebsd13.0
Thread model: posix
InstalledDir: /usr/bin

As an aside, generally pre-compiled packages on FreeBSD are compiled with very conservative options (I saw that on the email lists).
Ports build packages, so those exact same compiler options are going to be used when building from ports. Options aren't going to change that (barring the occasional OPTIMIZED_CFLAGS option, only a few ports actually have that).
 
From what I see the issue occurs also with clang80 and clang90 installed using pkg.

As the next step:
I will try to install FreeBSD from FreeBSD-13.0-RELEASE-amd64-bootonly.iso one more time and maybe if the issue reproduces I would be able to tell more. This time during the installation I will choose option:
[x] base-dbg Base system debugging
And some other stuff with "debug" in the installation menu. Maybe it would install libc and clang with debug symbols?
 
Hello again,

I've used FreeBSD base-dbg as mentioned above. Therfore I have been able to debug FreeBSD both: in user-space and within the kernel.
I have found the root cause of my issue was using qemu..x86_64 with -cpu max, see the description below for details:

During the investigation, surprisingly, I've found out that LA57 / Intel 5-level paging is enabled:
Code:
(gdb) b elf_machdep.c:125
Note: breakpoint 8 also set at pc 0xffffffff81060869.
Breakpoint 9 at 0xffffffff81060869: file /usr/src/sys/amd64/amd64/elf_machdep.c, line 126.
(gdb) c
Continuing.
[Switching to Thread 1.4]

Python Exception <class 'NameError'> Installation error: gdb._execute_unwinders function is missing:
Thread 4 hit Breakpoint 8, amd64_init_sysvecs (Python Exception <class 'NameError'> Installation error: gdb._execute_unwinders function is missing:
arg=0x0)
    at /usr/src/sys/amd64/amd64/elf_machdep.c:126
126     in /usr/src/sys/amd64/amd64/elf_machdep.c
(gdb) print la57
$33 = 1
I have an older CPU, so I think it shouldn't have the la57 support within hardware, according to Wikipedia:
The extension was first implemented in the Ice Lake processors

I have used quemu parameter: -cpu max (since -cpu host did not work for some reason), from qemu's help:
x86 max Enables all features supported by the accelerator in the current host
This might mean that qemu for some unknown to me reason assumes incorrectly, that I have a CPU, that provides la57 support...

After removing '-cpu max' from qemu command line and restarting FreeBSD, there are no segmentation faults and clang compiles the test.c file.
Also the code of FreeBSD kernel at startup doesn't enter the la57 condition:
Code:
(gdb) print la57
$34 = 0

Summary:
Seems that FreeBSD build is not the root cause of the error.
I think the next step should be checking&debugging qemu and fixing la57 detection when -cpu max is used.
 
Back
Top