Solved clang error during kernel compilation

T

TempleBSD

Hello,

I have just upgraded my system from 12.2-Release to 13.0-Release without any problems. I had a custom kernel set up before and wanted to compile one for the upgraded install too. Obtained relevant /usr/src from git with branch releng/13.0 and configured it using a copy of GENERIC. I then started the build but shortly an error similar to this one popped up:
Code: 
1.    ./pci_if.h:101:2: current parser token 'return'
2.    ./pci_if.h:96:1: parsing function body 'PCI_GET_VPD_IDENT'
3.    ./pci_if.h:96:1: in compound statement ('{}')
#0 0x0000000003b24fae (/usr/bin/cc+0x3b24fae)
#1 0x0000000003b23355 (/usr/bin/cc+0x3b23355)
#2 0x0000000003ac9061 (/usr/bin/cc+0x3ac9061)
#3 0x0000000806e73e00 (/lib/libthr.so.3+0x19e00)
cc: error: clang frontend command failed due to signal (use -v to see invocation)
FreeBSD clang version 11.0.1 ([email]git@github.com[/email]:llvm/llvm-project.git llvmorg-11.0.1-0-g43ff75f2c3fe) Target: x86_64-unknown-freebsd13.0
Thread model: posix Installed
Dir: /usr/bin cc: note: diagnostic msg:
I fiddled around but with every config I tried (even bog standard GENERIC) i get the same type of error but different file/state. This made me try with aslr and stackgap disabled for both /usr/bin/clang and /usr/bin/clang++ and while that fixes the error, the compilation then just fails on random errors (i.e. "unterminated conditional directive" and so on) in random files.

- compiling from/for x86_64
- unmodified source tree
- freshly upgraded system

If anything else is needed, please do not refrain from asking.
Thank you for your time
 
TempleBSD said:
the compilation then just fails on random errors
Click to expand...
You might want to check your system for memory errors. I've had similar weird, seemingly random, build issues and it turned out to be some bad memory. Building world is quite a test for your system, it's a really good stress-test for the whole machine.
 
That sounds reasonable, thanks. I'll give memtest a go and try swapping out some sticks. Weird why that would show after an upgrade though. My 12.2 compilation wasn't that long ago. I'll report back after I've had the time. Thanks again.
 
TempleBSD said:
My 12.2 compilation wasn't that long ago.
Click to expand...
You may not have had the memory issue back then. Or it didn't push the machine as hard as the compilation of 13.0 does. In any case, just test the memory, even if it's only to rule it out as a possible cause.
 
Doesn't seem like memory is an issue. I'm at one successful pass of memtest86 (though I intend to let it run through three) without any errors.
 
TempleBSD said:
I'm at one successful pass of memtest86 (though I intend to let it run through three) without any errors.
Click to expand...
One pass will usually do, if there's anything really wrong it would have shown up by now. At least we ruled it out as a possible cause (it took me a long time to realize my memory was bad).

So, we're going to hunt for other potential issues. Do you have anything in /etc/make.conf and/or /etc/src.conf? Perhaps /etc/src-env.conf?
 
if it bombs in various ways it is very probably hardware
if you can reproduce it any number of times it's probably not the hardware
 
SirDice said:
So, we're going to hunt for other potential issues. Do you have anything in /etc/make.conf and/or /etc/src.conf? Perhaps /etc/src-env.conf?
Click to expand...
/etc/src.conf and /etc/src-env.conf both do not exist and /etc/make.conf contains only the two lines placed in there by installing linuxulator. trying with make.conf removed caused the same error.
 
TempleBSD said:
/etc/src.conf and /etc/src-env.conf both do not exist
Click to expand...
Ok, that's good, then they can't interfere either.
TempleBSD said:
/etc/make.conf contains only the two lines placed in there by installing linuxulator.
Click to expand...
Installing it shouldn't change anything in that file.
TempleBSD said:
trying with make.conf removed caused the same error.
Click to expand...
Ok, that's good. Well, it's good that it's out of the way. It's not so good because it still doesn't work.

So, lets circle back to the beginning.
TempleBSD said:
Obtained relevant /usr/src from git with branch releng/13.0
Click to expand...
How? Did you use git(1) or gitup(8)? Or used some other way of getting the source?

TempleBSD said:
I then started the build
Click to expand...
How did you start the build? cd /usr/src and make buildworld?
 
SirDice said:
How? Did you use git(1) or gitup(8)? Or used some other way of getting the source?
Click to expand...
I initially obtained it with doas git clone -b releng/13.0 --depth 1 https://git.freebsd.org/src.git /usr/src but then to remove git as a variable tried doas svn checkout https://svn.freebsd.org/base/head /usr/src while I'm not too sure of the second one. Either way, both produced the same error.
SirDice said:
How did you start the build? cd /usr/src and make buildworld?
Click to expand...
cd /usr/src and then doas make buildkernel kernconf=CUSTOM after having placed my config in /usr/src/sys/amd64/conf/CUSTOM

Do you know of any good CPU stresstests I could try to check? Running benchmarks/unixbench now.

UPDATE: Unixbench crashed by sigabort quite quickly after which I tweaked some settings in the BIOS (which will be listed if they work) and now unixbench got past the point of the last crash which gives me a little hope. Gonna let it run through and try a compilation afterwards.
 
TempleBSD said:
while I'm not too sure of the second one
Click to expand...
The sources for 13.0 aren't on SVN anymore, the head there is an old 13-CURRENT. Only the 11.x and 12.x versions are still maintained in SVN. Use git(1) to get the sources for 13.0 or higher.

TempleBSD said:
cd /usr/src and then doas make buildkernel kernconf=CUSTOM after having placed my config in /usr/src/sys/amd64/conf/CUSTOM
Click to expand...
Build world fist. Or run make kernel-toolchain first. And the proper way to set the kernel to build is KERNCONF=CUSTOM
Code: 
     kernel-toolchain      Rebuild the tools needed for kernel compilation.
                           Use this if you did not do a buildworld first.
Code: 
     KERNCONF             Overrides which kernel to build and install for the
                          various kernel make targets.  It defaults to
                          GENERIC.
build(7)
 
If you see random crashes you should also consider that you have corrupted files (and binaries) so you probably want do a fresh install once you've verified that your hardware is stable.
 
SirDice said:
The sources for 13.0 aren't on SVN anymore, the head there is an old 13-CURRENT. Only the 11.x and 12.x versions are still maintained in SVN. Use git(1) to get the sources for 13.0 or higher.
Click to expand...
Reverted back to git now.
SirDice said:
Build world fist. Or run make kernel-toolchain first. And the proper way to set the kernel to build is KERNCONF=CUSTOM
Click to expand...
Thanks for pointing that out. The fully qualified monkey I am is definitely incapable of reading manpages.
diizzy said:
If you see random crashes you should also consider that you have corrupted files (and binaries) so you probably want do a fresh install once you've verified that your hardware is stable.
Click to expand...
Trying to avoid that really. Some time investment is involved with that and I'd love to avoid re-doing my setup. Thanks for the suggestion.

Unixbench now completed.
I'm remapping clang10 to clang12 (in /etc/make.conf) to see if that changes anything because I still got a crash during toolchain build. No idea if that's reasonable though.
Have you got any idea whether aslr/stackgap can interfere with the kernel compilation? Building world succeeded under 12.2 with both of them on so it should not be an issue right? I will reboot with these turned off and try again after the currently running attempt. I'm also using devel/ccache but to avoid conflicts did clear out the whole cache between changes.
 
TempleBSD said:
I'm remapping clang10 to clang12 (in /etc/make.conf) to see if that changes anything because I still got a crash during toolchain build. No idea if that's reasonable though.
Have you got any idea whether aslr/stackgap can interfere with the kernel compilation? Building world succeeded under 12.2 with both of them on so it should not be an issue right? I will reboot with these turned off and try again after the currently running attempt. I'm also using devel/ccache but to avoid conflicts did clear out the whole cache between changes.
Click to expand...
To rule out any issues build it as "plain" as possible. No messing around with compilers, ASLR or any other advanced features. Disable ccache too. Building a bog standard world should always work. Once that builds properly you can try enabling certain features or using ccache.
 
Disabled all entries in /etc/sysctl.conf (followed by a reboot) set by me, ran a pkg check -sa to check for corrupted binaries and then started the compilation with make buildworld from plain userland. Issue still persists. Checked git stash to check whether any files had changed locally. This is very confusing to me. Looks like its gonna be a reinstall once I find the time to do that. I will try and compile from a live-usb to see if that changes something.
 
I'm compiling from a live-usb chrooted into my current systems drive and its been going alright so far. At least it has lasted for an hour now which is far longer than my install took until crashing. I don't yet understand which component would be faulty if the live-compile works as chrooting would make me use all packages/files from my main system leaving only the kernel and modules loaded during boot as variables correct? This assumption should be verifiable after the compilation succeeded by then trying to build world again with the new kernel booted. Thanks you two for sticking with me so far!
 
Tieks said:
Did you rule out file system problems after upgrading to v13?
Click to expand...
Not specifically, no. I only checked whether enough space was available and it sure is. How would you go about finding problems with the filesystem?

Compiling the kernel chrooted through live-usb worked. Now booted into the newly compiled one and recompiling it to see whether some issue with my kernel caused the instability.
 
Thanks guys, somewhat solved. Compiled new kernel from chroot into my systems drive from the live session of the installer stick. The newly compiled kernel fixed the issue and I can now successfully build world on my machine. Weird.
 
You must log in or register to reply here.
Back
Top