Arm v7 RPi2 -current unresponsive to debugger escape during buildworld

bob prohaska <[email protected]>
Newsgroups gmane.os.freebsd.current,gmane.os.freebsd.devel.arm
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.