Re: Lilypond crashes while drawing systems

[David Kastrup]

Lukas-Fabian Moser <address@hidden> writes:

>>> I seem to have managed to create a Lilypond file that crashes my
>>> system (Linux Mint 64-Bit with kernel 4.4.0-98-generic) so hard that I
>>> have to shut it down using the power button. Even a bash script in
>>> background that kills the Lilypond process every few seconds cannot
>>> rescue reliably. :-( The system hangs while "Drawing systems"
>>> ("Systeme erstellen" on my pc).
>> That sounds like exploding memory usage.  Try using the ulimit command
>> for limiting the memory usage per process to something quite lower than
>> your physical memory and have some swap space available so that dormant
>> processes can be temporarily moved out, not contributing to the memory
>> pressure that much.
>>
> Thanks for pointing me to ulimit. This enabled me to safely strip down
> the example to a minimal one. With ulimit -Sv 5000000, Lilypond thinks
> for a while during "drawing systems" and then aborts with a
> std::bad_alloc.)
>
> This kind-of-minimal version crashes 2.19.80 as well as current master:
>
> \version "2.19.80"
>
> \new Staff <<
>   {
>     \clef bass
>     e,4
>   }
>   {
>     \omit NoteHead
>     e,4
>   }
>>>
>
> Everything here (except the \version) seems to be necessary. I can
> reproduce the crash with some other configurations as well (another
> pitch in tenor clef, for instance), but removing any single command
> seems to resolve the problem. Also, putting each "voice" into a
> regular \new Voice (as in Harm's proposal) makes the problem
> disappear. Just as  taking f, instead of e, for the pitch does (which
> could point to ledger lines).

Excellent work.  I can reproduce the crash.  Unfortunately, I am not
really all that familiar with the page builder where the problem appears
to be.  I am currently involved in several other LilyPond tasks and have
several family matters to attend to this weekend, so it would be good if
the bug squad created an issue for this crash, with a warning that this
is a matter of running out of memory and should be tested with
appropriate limits in place.

-- 
David Kastrup