Re: -current buildworld stoppage

On 10/10/26 14:23, bob prohaska wrote:
> 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

I'm not suggesting drive or cable failures, though I can not rule them
out. If you had such, testing the an alternate same type of drive setup
that would use the same drivers would be a cross check on such by seeing
if only the one device gets failures. (Not that you have the means of
doing such testing.)

> 
> Thanks for writing!
> 
> bob prohaska
> 
> 
> 


-- 
===
Mark Millard
marklmi at yahoo.com