Re: TiBook w/-current semi-comatose building boost-libs

On Mon, 5 Oct 2020, John D. Baker wrote:

> On Mon, 5 Oct 2020, David Brownlee wrote:
> 
> > On Mon, 5 Oct 2020 at 13:30, John D. Baker <[email protected]> wrote:
> > >
> > > Except, when it tries to build "devel/boost-libs".  It gets as far as:
> > >
> > > Ideas?
> > 
> > Some random thoughts:
> > - Can you see if there is any interesting (nfs) traffic?
> > - Does ^T give any output (or ^C)
> 
> I'll see about gathering this when I next attempt to build
> "devel/boost-libs".  Right now, I have it and everything that depends
> on it eXcluded via 'pkg_rolling-replace -u -Xfoo,bar,baz,qux' and
> pkg_rr is rolling right along.

I've had it come to a similar impasse while building "qt5-qtbase".
While it echoed <space><backspace> in the SSH session and the login
on the console accepted characters, it was unresponsive to ^T or ^C.

It got as far as:

[...]
=> Generating pkg-config file for builtin expat package.
=> Replacing Perl interpreter in bin/fixqt4headers.pl bin/syncqt.pl mkspecs/features/data/unix/findclasslist.pl.
Creating qmake...
..............[stuck]

> > - Does it have plenty of swap configured
> 
> It has 2GB in "/swap" (1GB RAM).  I'll see about increasing this.
> 
> > - How reproducible is it (maybe leave a separate ssh session running
> > top & unblanked console)
> 
> I'll see if I can arrange the extra session or run 'top' on console but so
> far it is completely reproducible, any attempt to build "devel/boost-libs"
> hangs as described previously.

A second ssh session running 'top' is now frozen displaying the following:

load averages:  2.01,  1.92,  1.56;               up 0+15:36:18        07:38:44
42 processes: 3 runnable, 38 sleeping, 1 on CPU
CPU states: 10.8% user,  0.0% nice, 89.2% system,  0.0% interrupt,  0.0% idle
Memory: 566M Act, 278M Inact, 26M Wired, 31M Exec, 337M File, 24K F Free
Swap: 2048M Total, 5668K Used, 2042M Free

  PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
  347 sysop     28    0   253M  234M RUN        1:56 48.15% 48.14% cc1plus
22976 sysop     29    0   273M  248M RUN        1:51 47.75% 47.75% cc1plus
    0 root     125    0     0K   36M vdrain     4:57  0.00%  0.00% [system]
  851 sysop     43    0  8996K 2584K CPU        0:46  0.00%  0.00% top
10685 sysop     80    0  8376K  356K wait       0:14  0.00%  0.00% sh
  980 sysop     85    0    19M 2084K select     0:07  0.00%  0.00% sshd
  560 ntpd      85    0    13M   12M pause      0:05  0.00%  0.00% ntpd
  818 sysop     85    0    19M  704K select     0:05  0.00%  0.00% sshd
 5335 sysop     83    0    11M 5256K wait       0:04  0.00%  0.00% make
  303 root      85    0    13M 2164K kqueue     0:01  0.00%  0.00% syslogd
  804 root      85    0    17M  760K kqueue     0:01  0.00%  0.00% master
23987 sysop     83    0    10M  316K wait       0:01  0.00%  0.00% make
13280 sysop     81    0    10M 1788K wait       0:01  0.00%  0.00% make
  350 root      85    0    13M   14M select     0:00  0.00%  0.00% amd
 1186 root      85    0    19M 7232K poll       0:00  0.00%  0.00% sshd
 8278 postfix   85    0    17M 4700K kqueue     0:00  0.00%  0.00% pickup
29656 sysop     85    0    11M 3092K wait       0:00  0.00%  0.00% g++
 1338 root      85    0    18M 2860K select     0:00  0.00%  0.00% sshd
 1121 sysop     85    0  7468K 2096K pause      0:00  0.00%  0.00% ksh
 1306 root      85    0  7028K 2016K ttyraw     0:00  0.00%  0.00% getty
  677 root      85    0  7028K 2008K ttyraw     0:00  0.00%  0.00% getty
  825 root      85    0  7576K 1824K nanoslp    0:00  0.00%  0.00% cron
 1201 root      85    0  6540K 1684K kqueue     0:00  0.00%  0.00% powerd
24782 sysop     85    0  7572K 1092K pipe_rd    0:00  0.00%  0.00% bash
  821 postfix   85    0    17M  852K kqueue     0:00  0.00%  0.00% qmgr
  833 sysop     85    0  7520K  608K pause      0:00  0.00%  0.00% ksh
  857 root      85    0  7028K  300K ttyraw     0:00  0.00%  0.00% getty

The timestamp in the display is about 20 minutes prior to my sending this
message.

It would appear to be out of memory, if the "24K F Free" is to be believed.
The glitch in the display is where it was in the midst of updating when the
machine went comatose.

It appears to have most of its swap space still available.  I tend to run
with MAKE_JOBS=2 (ncpu+1).  Perhaps I'll re-try with MAKE_JOBS=1 and see
if that helps.

I should also note that my previous posts on the subject were still using
GCC 8.  This and future posts are using GCC 9.

-- 
|/"\ John D. Baker, KN5UKS               NetBSD     Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net  OpenBSD            FreeBSD
| X  No HTML/proprietary data in email.   BSD just sits there and works!
|/ \ GPGkeyID:  D703 4A7E 479F 63F8 D3F4  BD99 9572 8F23 E4AD 1645