Re: GS error on somewhat large score

[David Kastrup]

Simon Albrecht <address@hidden> writes:

> Hello everybody,
>
> I’ve just noticed a problem when compiling a medium to large score (44
> pages of output) with 2.19.65: everything is fine until GS fails with
> the message
> warning: g_spawn_sync failed (0): gs: Failed to fork (Cannot allocate
> memory).
> Compiling the 3–5 page bookparts individually is no problem.
>
> Does this ring a bell with anybody? or
> How should I further investigate the problem? or
> Would anybody be interested in getting the file privately to investigate?

Ok, so I looked at the g_spawn_sync source code: it uses the fork+exec
paradigm.  Should be using vfork where available.  The reason is that
fork duplicates the entire process space which can be large here.  When
the next operation is an exec call, no actual duplication occurs (this
works via copy-on-write, and basically no write happens), but Linux
tends to allow only a certain amount of "overcommitment" of memory, so
it may refuse to fork because it suspects that it might run out of
memory afterwards, not anticipating the following exec.

So adding the swap space is a good remedy: it will usually not be needed
but allows Linux to fork even when the current process already eats 2GB.

Running an effectively 2GB system in the ground still requires some
large memory usage, but it's not quite as suspicious.

-- 
David Kastrup