Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

From: bob prohaska <fbsd_at_www.zefox.net>
Date: Thu, 06 Nov 2025 14:04:52 UTC
For roughly the past year I've been seeing buildworld become unresponsive
compiling -current on a Pi2 (armv7). The stoppages seem random, sometimes
with no visible memory pressure, other times while swapping. The machine
uses a USB mechanican hard drive for root and swap. 

Numerous attemps to use enter-tilda-control-B to get into the debugger 
have failed, with absolutely no response. In the most recent case the
disk activity light was flashing rapidly, a relatively uncommon event.
The frozen top window showed ~312 MB swap in use, less than half of
the maximum commonly seen for a -j3 buildworld.

Looking at the log file after power-cycling it appeared to have last
updated the previous evening, so it seems unlikely it got stuck on
a core dump. Reboot was uneventful, with fsck completing successfully.
Buildworld has been restarted, it'll pick up where it left off.

The last entries in the buildworld log file were:
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateInstantiateDecl.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaTemplateVariadic.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaType.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaWasm.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/SemaX86.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Sema/TypeLocBuilder.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTCommon.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReader.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderDecl.pico
Building /usr/obj/usr/src/arm.armv7/lib/clang/libclang/Serialization/ASTReaderStmt.pico

No warnings or errors of any kind appear on the serial console, ever.

Is there some other way to get at debugger services in a case like this?
I understand it's possible to run programs under debugger "supervision"
at the time of invocation, but would that provide any extra avenues to
find out what's going wrong? I think not, but I'd like very much to gather 
some useful information toward a fix. 

Thanks for reading,

bob prohaska