Re: pkg/35437 (games/wesnoth generates internal compiler error (NetBSD 3.0))

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR pkg/35437; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/35437 (games/wesnoth generates internal compiler error (NetBSD 
3.0)) 
Date: Thu, 18 Jan 2007 13:44:03 +0700

     Date:        Wed, 17 Jan 2007 22:45:05 +0000 (UTC)
     From:        wiz%NetBSD.org@localhost
     Message-ID:  <20070117224505.53A5963BC7A%narn.NetBSD.org@localhost>
 
   | Could it be possible that you're running out of available RAM?
 
 Almost anything is possible, but I don't think it very likely.  The
 system I'm building on has a GB of (real) ram, and another 2GB of swap
 space (virtual ram...) - which swapctl says is just 15% used, meaning
 there should have been about 1.7GB of swap available for gcc to use
 (give or take a little) when it failed - if that's not enough, then
 gcc needs some serious work!
 
 In any case, if a process gets killed because of an out of swap condition,
 there would be a kernel printf about that, wouldn't there?   There wasn't.
 I also wouldn't expect "segmentation violation" as the signal used to
 kill such a process - after all, processes can catch SIGSEGV, and continue
 (as /bin/sh used to do, at least the real Bourne sh did, and aside from the 
 "continue" part in any real sense, gcc is doing here), which wouldn't
 be useful at all when a process was being killed to free VM.
 
 But ...
 
   | Perhaps adding some swapspace (see swapctl) helps,
   | could you please try that?
 
 Sure.   That's easy, I just added a bit over 13GB of swap, and tried
 building again.   Same result.   What's more, I was watching vm using
 (all of) vmstat, systat (vm), systat (swap), and xuvmstat - none of
 those indicated any serious paging activity.   The extra 13GB of swap I
 added has < 100MB in use (and never exceeded that from what I could see).
 (That's just swap load balancing happening).
 
 I guess I need to resurrect my patch to pkg_comp to stop it cleaning
 everything after it is "done" (successful or unsuccessful) so I can go
 look at what is happening more easily (also I guess I should see if I
 can find a way to allow gcc to simply allow its processes to dump core
 instead of catching the signal and attempting to supply a helpful message,
 and in so doing, making debugging almost impossible).
 
 kre