Re: Any idea what's going on here? (clang blow-up on Pi3 under 14.1)
- In reply to: Mark Millard : "Re: Any idea what's going on here? (clang blow-up on Pi3 under 14.1)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 27 Jun 2024 11:16:17 UTC
On 6/27/2024 00:57, Mark Millard wrote: > On Jun 26, 2024, at 15:01, Karl Denninger<karl@denninger.net> wrote: > >> FreeBSD 14.1-STABLE stable/14-n267995-2472e352d80f GENERIC >> Environment: Pi3; this code has built without issue for quite some time on 13.x. >> But check this out on the same physical Pi3 I use for development under 14.1: >> $ make clean >> rm -f *.o hd-mcp hd-mcp.freeware license-server hd-commit >> $ make >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c config.c -o config.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c funcs.c -o funcs.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o hd-mcp.o >> PLEASE submit a bug report tohttps://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. >> Stack dump: >> 0. Program arguments: cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o hd-mcp.o >> 1. <eof> parser at end of file >> 2. Code generation >> 3. Running pass 'Function Pass Manager' on module 'hd-mcp.c'. >> 4. Running pass 'AArch64O0PreLegalizerCombiner' on function '@process_unit_get_response' >> #0 0x0000000004b17588 (/usr/bin/cc+0x4b17588) >> #1 0x0000000004b15650 (/usr/bin/cc+0x4b15650) >> #2 0x0000000004ae16a0 (/usr/bin/cc+0x4ae16a0) >> #3 0x0000000089b92eb8 (/lib/libthr.so.3+0x2aeb8) >> cc: error: clang frontend command failed with exit code 139 (use -v to see invocation) >> FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67) >> Target: aarch64-unknown-freebsd14.1 >> Thread model: posix >> InstalledDir: /usr/bin >> 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/hd-mcp-a07b96.c >> cc: note: diagnostic msg: /tmp/hd-mcp-a07b96.sh >> cc: note: diagnostic msg: >> >> ******************** >> *** Error code 1 >> >> Stop. >> make: stopped in /data/karl/HD-MCP >> $ make >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o hd-mcp.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -cwww.c -owww.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c slave.c -o slave.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c amcrest.c -o amcrest.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c license.c -o license.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c z-wave.c -o z-wave.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c malloc.c -o malloc.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c S0-encryption.c -o S0-encryption.o >> PLEASE submit a bug report tohttps://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. >> Stack dump: >> 0. Program arguments: cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c S0-encryption.c -o S0-encryption.o >> 1. <eof> parser at end of file >> 2. Code generation >> 3. Running pass 'Function Pass Manager' on module 'S0-encryption.c'. >> 4. Running pass 'AArch64O0PreLegalizerCombiner' on function '@decrypt_packet' >> #0 0x0000000004b17588 (/usr/bin/cc+0x4b17588) >> #1 0x0000000004b15650 (/usr/bin/cc+0x4b15650) >> #2 0x0000000004ae16a0 (/usr/bin/cc+0x4ae16a0) >> #3 0x0000000089887eb8 (/lib/libthr.so.3+0x2aeb8) >> cc: error: clang frontend command failed with exit code 139 (use -v to see invocation) >> FreeBSD clang version 18.1.6 (https://github.com/llvm/llvm-project.git llvmorg-18.1.6-0-g1118c2e05e67) >> Target: aarch64-unknown-freebsd14.1 >> Thread model: posix >> InstalledDir: /usr/bin >> 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/S0-encryption-30d26b.c >> cc: note: diagnostic msg: /tmp/S0-encryption-30d26b.sh >> cc: note: diagnostic msg: >> >> ******************** >> *** Error code 1 >> >> Stop. >> make: stopped in /data/karl/HD-MCP >> >> Note that the first time it stops in one of the files, hd-mcp.c in the function "process_unit_get_response." >> But if I invoke "make" again having changed nothing the same file compile succeeds! >> It then fails on a different file in the routine "decrypt_packet"; that particular source file has only a handful of functions in it and I've seen it fail on different entries -- it is not always in the same place. >> Once in a great while the entire build will succeed. Note that on the same Pi3 running 13.1 (which is what I'm using right now in most cases, but looking to move to 14.x) the same code builds every time. >> I've grabbed a brand-new in-box Pi3 that I have here as a spare - no difference - thus I conclude its not the specific hardware that decided to take a dump on me without warning. >> Now I take the same SD card and stick it in a 4Gb Pi4 and boot that, clear the object files (so it has to do the entire thing) and.... >> root@rpi:~ # su - karl >> $ ls >> HD-MCP >> $ cd HD-MCP >> $ make clean >> rm -f *.o hd-mcp hd-mcp.freeware license-server hd-commit >> $ make >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c config.c -o config.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c funcs.c -o funcs.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-mcp.c -o hd-mcp.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -cwww.c -owww.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c slave.c -o slave.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c amcrest.c -o amcrest.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c license.c -o license.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c z-wave.c -o z-wave.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c malloc.c -o malloc.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c S0-encryption.c -o S0-encryption.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c boot-include.c -o boot-include.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c root-include.c -o root-include.o >> cc -g -o hd-mcp hd-mcp.owww.o config.o slave.o amcrest.o license.o funcs.o z-wave.o malloc.o S0-encryption.o root-include.o boot-include.o -lm -lcrypt -lssl -lpthread -lcrypto -lgpio >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c hd-commit.c -o hd-commit.o >> cc -g -o hd-commit hd-commit.o >> cc -g -Wstrict-prototypes -DVERSION=\"8.0.0-LocalAuth\" -c license-server.c -o license-server.o >> cc -g -o license-server license-server.o funcs.o malloc.o -lcrypto -lssl -lm >> $ >> No problem. >> Ehhhh.... that does not smell good. >> Has anyone seen some sort of problem with 14.x and the Pi3 series CPUs? There ARE a LOT of complaints about "clk_fixed...." printed on both the 3 and 4 during boot (clk_fixed4: clock-fixed has no clock-frequency), probably 50 all-in, but other than the complaint during the boot it appears to have no other effect and doesn't show up again once the system has come up. >> The only other complaint of note during the boot is several of these on the Pi4 during the boot process : >> sdhci_bcm0-slot0: Got command interrupt 0x00030000, but there is no active command. >> sdhci_bcm0-slot0: ============== REGISTER DUMP ============== >> sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version: 0x00009902 >> sdhci_bcm0-slot0: Blk size: 0x00000000 | Blk cnt: 0x00000000 >> sdhci_bcm0-slot0: Argument: 0x000001aa | Trn mode: 0x00000000 >> sdhci_bcm0-slot0: Present: 0x000f0000 | Host ctl: 0x00000001 >> sdhci_bcm0-slot0: Power: 0x0000000f | Blk gap: 0x00000000 >> sdhci_bcm0-slot0: Wake-up: 0x00000000 | Clock: 0x00003947 >> sdhci_bcm0-slot0: Timeout: 0x00000000 | Int stat: 0x00000000 >> sdhci_bcm0-slot0: Int enab: 0x01ff00bb | Sig enab: 0x01ff00bb >> sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 >> sdhci_bcm0-slot0: Caps: 0x00000000 | Caps2: 0x00000000 >> sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 >> sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 >> sdhci_bcm0-slot0: =========================================== >> The complaint asks to submit a bug on the compiler but I suspect this isn't the compiler at all, but rather something odd going on related to the OS and the CPU instead since the exactly same SD card booted in a "4" completes every time and the same code also compiles cleanly without problems on the Pi3 under 13.1. >> Thanks in advance! >> -- >> Karl Denninger >> karl@denninger.net >> The Market Ticker >> [S/MIME encrypted email preferred] > Hello. > > Can you provide any folks the files (or from similar failed > attempts): > > /tmp/hd-mcp-a07b96.c > /tmp/hd-mcp-a07b96.sh > > and/or: > > /tmp/S0-encryption-30d26b.c > /tmp/S0-encryption-30d26b.sh > > ? The purpose of these is to allow attempted replication without having to > have as much detailed material duplicated. The .c file has the after > preprocessing source file. The .sh has the command(s). > > You could also try the replication in your failing contexts and see if they > are sufficient for you to get example failures or not. (If you can not, it > might not be reasonable for other folks to try to get the failures this way.) > > > === > Mark Millard > marklmi at yahoo.com > Whatever it is, its in STABLE/14 /but the problem does not manifest on RELEASE-14.1/ Overnight I ran a Crochet build against releng/14.1 and just ran several make clean;make cycles on the image it generated with the same code checked out of my master repo. It succeeds 100% of the time but against the stable/14 (which has the tag indicated) it fails as indicated above -- but not every single time, and only on the Pi3 -- on the 4 it never fails on either build. I'll start digging around the source repo between releng/14.1 and stable/14 of the last few days and see what's been committed that might be implicated and if I can find a potential suspect try a bisect there. I//have, on the failing instance, attempted to move all the files to /tmp (which is a tempfs) with the same results, and also attempted to "cc -g" the dumped .c file (which is on that tempfs) and it blew up as well, so potential problems with I/O to the SD card and ufs/su+j (which is in use on the home directory where the compile normally runs against) should not be a factor. -- Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/