Bug#726009: Insufficient RAM on build-machines (was Bug#726009: yade: FTBFS on i386 (and others))

[Dmitrijs Ledkovs]

On 11 October 2013 20:32, Steve Langasek <vorlon at debian.org> wrote:
> severity 726009 serious
> thanks
>
> This remains a serious bug.  Your package, which previously built on
> multiple architectures, is now failing to build due to memory exhaustion.
> While in some circumstances it is permissible to remove the old binaries and
> drop support for an architecture, this remains a serious bug until this has
> been done.  (And anyway, your package won't reach testing in the current
> state, so is de facto unreleasable.)
>
> On Fri, Oct 11, 2013 at 09:00:36PM +0200, Anton Gladky wrote:
>> severity 726009 wishlist
>> retitle 726009 Yade requires too much RAM for building
>> thanks
>
>> thanks for bug-report. The problem is, that all build-failures are due
>> to insufficient RAM on build-machines [1]. I do not really know how to
>> "fix" that except of backlisting of some machines, as was suggested by
>> Julien [2]. The same package builds fine on Launchpad's PPA. It seems,
>> the package builds only on machines, where >4Gb RAM is available.
>
> This diagnosis is incorrect.  The error you are hitting here is not that you
> are exhausting the available memory on the machine, it's that you're
> exhausting the *address space* on the machine.  Adding more memory to the
> buildd would have zero effect, because you're on a 32-bit system which has a
> limit of 4GB of address space anyway.  (In practice, I believe this is 3GB
> for userspace and 1GB for kernel on i386.)
>
> The buildd almost certainly has swap already, giving it total available
> memory in excess of 4GB, but that doesn't help if you have a single process
> - in this case g++ - that needs more than 3GB all to itself.
>
> If this same package version built on Launchpad but is failing to build in
> Debian unstable, then you should look at differences in toolchain versions
> between the two.  It's possible that Ubuntu has a compiler fix that isn't
> yet available in unstable; it's equally possible that the successful builds
> in Launchpad were done with an earlier toolchain, and that there's a more
> recent regression in g++ memory usage.  Either way, it's not the buildd's
> fault.

I'm not sure, but launchpad is running 64-bit machines even when
compiling for the i386 architecture, and then launchpad supports PAE
only and thus can get >4GB of address space.
I think debian buildds are also all 64-bit apart from one (or
something like that) thus it shouldn't be a problem there.

Last time I spoke with Colin about yade FTBFS due to memory
exhaustion, the recommendation he gave was to reduce translation units
and thus to reduce the compiler memory usage. GCC memory usage can go
very large and has regressed since 3.3 when templates are used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12850
It has been done before for some other packages, but i haven't yet had
time to look more into yade. I think that's the best way to go for
yade, to address it in the source-code / restructure it to use less
memory at compile time.

Regards,

Dmitrijs.