Re: Troubles building world on stable/13
- Reply: Mark Millard : "Re: Troubles building world on stable/13"
- In reply to: Mark Millard : "Re: Troubles building world on stable/13"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Tue, 25 Jan 2022 18:08:23 UTC
On Tue, Jan 25, 2022 at 09:13:08AM -0800, Mark Millard wrote: > > -DBATCH ? I'm not aware of there being any use of that symbol. > Do you have a documentation reference for it so that I could > read about it? > It's a switch to turn off dialog4ports. I can't find the reference now. Perhaps it's been deprecated? A name like -DUSE_DEFAULTS would be easier to understand anyway. On a whim, I tried building devel/llvm13 on a Pi4 running -current with 8 GB of RAM and 8 GB of swap. To my surprise, that stopped with: nemesis.zefox.com kernel log messages: +FreeBSD 14.0-CURRENT #26 main-5025e85013: Sun Jan 23 17:25:31 PST 2022 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1873450, size: 4096 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 521393, size: 4096 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 209826, size: 12288 +swap_pager: indefinite wait buffer: bufobj: 0, blkno: 1717218, size: 24576 +pid 56508 (c++), jid 0, uid 0, was killed: failed to reclaim memory On an 8GB machine, that seems strange. Per the failure message I restarted the build of devel/llvm13 with make -DBATCH MAKE_JOBS_UNSAFE=YES > make.log & It seems to be running with only one thread so far, not sure if that's by design or happenstance. > > However, restarting buildworld using -j1 appears to have worked past > > the former point of failure. > > Hmm. That usually means one (or both) of two things was involved > in the failure: > > A) a build race where something is not (fully) ready when > it is used > > B) running out of resources, such as RAM+SWAP > The stable/13 machine is short of swap; it has only 2 GB, which used to be enough. Maybe that's the problem, but having an error report that says it's a segfault is a confusing diagnostic. > But, as I understand, you were able to use a .cpp and > .sh file pair that had been produced to repeat the > problem on the RPi3B --and that would not have been a > parallel-activity context. > To be clear, the reproduction was on the same stable/13 that reported the original failure. An attempt at reproduction on a different Pi3 running -current ran without any errors. Come to think of it, that machine had more swap, too. > > It's in the building libraries phase now. > > Based on log size I'd guess it's about halfway through buildworld. > > > > Well, hopefully you will not be stuck with -j1 builds in > the future as well. > Indeed! bob prohaska