Simon Albrecht <simon.albre...@mail.de> 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 _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
