Re: nasm-2.16.01,1 build (nearly) locks up machine

------- Original Message -------
On Friday, December 23rd, 2022 at 8:18 PM, Tomoaki AOKI junchoon@dec.sakura.ne.jp wrote:



> On Fri, 23 Dec 2022 19:50:55 +0100
> Stefan Ehmann shoesoft@gmx.net wrote:
> 
> > On Friday, December 23, 2022 7:26:30 PM CET Tomoaki AOKI wrote:
> > 
> > On Fri, 23 Dec 2022 15:48:21 +0100
> > > 
> > > Stefan Ehmann shoesoft@gmx.net wrote:
> > > 
> > > > On Friday, December 23, 2022 3:41:30 PM CET Yasuhiro Kimura wrote:
> > > > 
> > > > > From: Stefan Ehmann shoesoft@gmx.net
> > > > > Subject: nasm-2.16.01,1 build (nearly) locks up machine
> > > > > Date: Fri, 23 Dec 2022 15:31:00 +0100
> > > > > 
> > > > > > devel/nasm nearly killed my machine today:
> > > > > > 
> > > > > > It starts thousands of gmake processes (probably until the machine
> > > > > > locks
> > > > > > up).
> > > > > > 
> > > > > > I also see lots of log entries in the build log (probably ~1 per gmake
> > > > > > 
> > > > > > invocation):
> > > > > > : > asm/warnings.time
> > > > > > 
> > > > > > gmake asm/warnings.c.time include/warnings.h.time
> > > > > > doc/warnings.src.time
> > > > > > gmake[13499]: Entering directory '/wrkdirs/usr/ports/devel/nasm/work/
> > > > > > nasm-2.16.01'
> > > > > > 
> > > > > > Seems some kind of make loop. Is this a general problem or is there
> > > > > > something wrong with my setup? I'm building in poudriere on
> > > > > > 13.1/amd64.
> > > > > 
> > > > > Do you build nasm 2.16.01 with poudriere and you tmpfs for working
> > > > > directory (that is, you specify either 'USE_TMPFS=wrkdir' or
> > > > > 'USE_TMPFS=yes' in poudriere.conf)?
> > > > > 
> > > > > If so, you can work it around by disabling use of tmpfs by adding
> > > > > 'USE_TMPFS=no' in poudriere.conf.
> > > > 
> > > > Yea, I have USE_TMPFS=all in poudriere.conf. USE_TMPFS=no works indeed.
> > > > 
> > > > Thanks for the fast reply.
> > > 
> > > I've bitten by it, too.
> > > Found this. [1] [2]
> > > [2] is linked from [1].
> > > 
> > > But Not at all tried though (as I'm not sure it is safe [100% upper
> > > compatible] to switch to -devel).
> > > 
> > > ports-mgmt/poudriere-devel seems to have it, but ports-mgmt/poudriere
> > > doesn't.
> > > 
> > > [1] https://github.com/freebsd/poudriere/issues/888
> > > 
> > > [2]
> > > https://github.com/freebsd/poudriere/commit/56233a1aaea1be59dcc111e7b3f97b6e
> > > 891bb06a
> > 
> > Thanks for the pointer. The rust tmpfs problem is different - it will work if
> > you have enough RAM. For some reason (not obvious to me), nasm build is
> > totally broken on tmpfs.
> > 
> > Meanwhile, the nasm update was reverted in commit
> > 102f7173426ac4122afd355205aa141bb50b2803.
> 
> The most important thing is that [2] introduced TMPFS_BLACKLIST
> variable.
> 
> I think adding nasm there causes building nasm without using tmpfs,
> while other ports, excluding listed there at the same time, can keep on
> using tmpfs.
> 
> P.S.
> To test pre-built nasm causes failure on ports BUILD_DEPENDing on nasm,
> I've done below and confirmed OK, even with USE_TMPFS=yes
> on /usr/local/etc/poudriere.conf.
> So maybe TMPFS_BLACKLIST'ing nasm alone would be sufficient.
> 
> 1. Built devel/nasm with ports-mgmt/pkg_replace, which builds fine,
> 2. pkg create it,
> 3. start usual poudriere run with unusual "-i" added,
> 4. after poudriere goes into shell, copy pre-built nasm package,
> to /poudriere/data/packages/(jain name)/All/,
> 5. exit shell invoked by poudriere,
> 6. once finished, delete jpeg-turbo package from
> /poudriere/data/packages/(jain name)/All/,
> 7. build jpeg-turbo using poudriere.
> 
> Copying pre-build nasm package without steps 3-5 caused re-building
> nasm, which promissingly fails.


Thank you very much for reporting the issue.
As it has already been noted, the commit that broke nasm has been reverted with
https://cgit.freebsd.org/ports/commit/?id=102f7173426ac4122afd355205aa141bb50b2803 .
 
Investigations have started to understand the issue and a bug report has been opened
to track the issue:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=268528

Thanks and sorry for the broken update,

Lorenzo Salvadore