Arm v7 RPi2 -current unresponsive to debugger escape during buildworld
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