Re: -current buildworld stoppage

On Sat, Oct 10, 2026 at 09:14:19AM -0700, Mark Millard wrote:
> On 10/10/26 08:35, bob prohaska wrote:
> > On Sun, Oct 04, 2026 at 02:22:06PM -0700, bob prohaska wrote:
> >> On Sat, Oct 03, 2026 at 01:18:44PM -0700, bob prohaska wrote:
> >>> On Sat, Oct 03, 2026 at 12:43:37PM -0700, Mark Millard wrote:
> >>>>>
> >>>>>
> >>>>
> >>>> That log file suggests file content corruption for a file that was
> >>>> being read:
> >>>>
> >>>> ~/Downloads/buildworld.log:48399: /usr/src/contrib/unvis/unvis.c:1:1:
> >>>> error: unknown type name '$'
> >>>
> >>> That file displays like it's binary, I've deleted the file and run 
> >>> git reset --hard.
> >>> There's no mention of replacing the missing file, but git reports
> >>> HEAD is now at 34b00ed041a4 hwpmc: fix IBS fetch and op NMI handling
> >>>
> >>> Buildworld has been restarted in meta mode, I'll post what happens.
> >>
> >> Buildworld completed successfully, how that file got scrambled is still
> >> unclear.
> > 
> > After the successful buildworld git pull was run again and buildworld
> > restarted in meta mode. Once again, buildworld stopped, reporting:
> > ...
> > Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaStmtAsm.pico
> > In file included from /usr/src/contrib/llvm-project/clang/lib/Sema/SemaStmtAsm.cpp:26:
> > In file included from /usr/src/contrib/llvm-project/llvm/include/llvm/MC/MCParser/MCAsmParser.h:19:
> > /usr/src/contrib/llvm-project/llvm/include/llvm/MC/MCParser/AsmLexer.h:1:1: error: unknown type name '$'
> >     1 | $<U+001A><9C><92>m<85><CE>mo<93>L<D2>D<FC><DC>;<98>%g<CF>?w<EA><C1>ŷ<U+0019><F8><U+0016><EE><F9>ovH0<F5><C9>a<87>5<A3><DA>*<EE><A0><C3><CC>l͛<9B>S<A0>iy<U+0001><E4><94>r<D5>O7<AA><93><9E><81>%L]<DD><D7>%<B1><BA><U+001C><C7>hk<U+0000><B6><AB><B7><F7>>v1<AD>HB<A3><AE><B1><U+0005><DF><DE><DA>d\<81>(<U+0013>e<U+000B>o<U+001F>Ix<A2>>3<B4><U+0001>6BS%<CC><D8><E1><93>(<U+007F>
> > # ls -l /usr/src/contrib/llvm-project/llvm/include/llvm/MC/MCParser/AsmLexer.h
> > -rw-r--r--  1 root wheel 7175 May  1 06:37 /usr/src/contrib/llvm-project/llvm/include/llvm/MC/MCParser/AsmLexer.h
> > 
> > This time the file displays normally:
> > # more /usr/src/contrib/llvm-project/llvm/include/llvm/MC/MCParser/AsmLexer.h
> > //===- AsmLexer.h - Lexer for Assembly Files --------------------*- C++ -*-===//
> > //
> > // Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
> > // See https://llvm.org/LICENSE.txt for license information.
> > // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> > //
> > //===----------------------------------------------------------------------===//
> > //
> > // This class declares the lexer for assembly files.
> > //
> > //===----------------------------------------------------------------------===//
> > 
> > It's unclear what to try next. To my eye this does not look like a hardware
> > problem, it seems too consistenent and (relatively) rare. I'll again try 
> > deleting the offending files, run git reset --hard and try buildworld 
> > again because that's relatively quick. If this is obvious folly, please 
> > indicate so.
> > git reset --hard reports
> > Updating files: 100% (96/96), done.
> > HEAD is now at 6c305c3c3129 dhclient-script(8): s/URI/URL
> > 
> > Thanks for reading!
> > 
> > bob prohaska
> >  
> > 
> > 
> 
> Given the 2 distinct reported starts to the same file without an update
> between  . . .
> 
> I'll note that if you get a failure and the later more command (or
> whatever) also looks corrupted, just rebooting and checking on what the
> file ends up looking like is of interest: no longer seeing the odd data
> would tend to suggest internal corruption that is not in the drive content.
> 
> But, for what happend, more interesting might have been to not reboot
> initially and:
> 
> 1) try an incremental build to see if a failure repeated at the same
> unchanged file --and if the same problem text was reported if it did
> fail there. No reboot or such first. If it does not fail the same way at
> the same file, it suggests internal corruption that is not on the media.
> 
> Then, if it failed the same way ay the same file:
> 
> 2) just reboot and try an incremental build to see if a failure repeated
> at the same unchanged file --and if the same problem text was reported
> if it did fail there. The reboot is to prevent any already correctuped
> internal state to be avoided this time.
> 
> Those are deliberately not doing a full rebuild up front, although such
> experiments could potentiially also produce useful information after the
> above.
> 
I'll try to preserve more carefully the state of failures to see how
and if they repeat. Up to now I'd thought this just "one of those 
things" that happen when following -current.

> What type of media? Do you have alternate media of a different type
> (different drivers) that could be set up as a duplicate-by-content to
> try builds with? If it is repeatable with some different drivers in use,
> then it is not a problem with code unique to the original drivers, code
> that was not used in the later attempt.

It's a SATA mechanical hard disk in a USB3 enclosure connected via a
powered USB3 hub to an RPi2B. It's been self-hosting -current since 
March of 2025 and apart from warm-boot failures seemed reasonably 
reliable. Not to say it couldn't be failing now, but it's not my first 
guess. I don't have alternate media handy, alas

Thanks for writing!

bob prohaska