Crash due to internal memory limits (?) in lilypond (was: Crash with bars-per-line-engraver as of LSR snippet id=838)

[Michael Gerdau]

> I doubt it's caused by any custom-engraver.
> At least on my machine this code:
> 
> \paper {
>   systems-per-page = #5
> }
> 
> music = \absolute {
>     \repeat unfold 2000 {
>       d'8 f' a' g'  d' f' b' d' d'8 f' a' g'  d' f' b' d' \break
>     }
> }
> 
> \new Staff { \music }
> 
> already fails with:
> [...]
> Preprocessing graphical objects...terminate called after throwing an
> instance of 'std::bad_alloc'
>   what():  St9bad_alloc
> Aborted (core dumped)
> 
> on Ubuntu 64-bit 18.04 for any tested version (2.18.2 up to current master)

I've played with it a bit more and indeed I don't need a custom-engraver
either. The problem only surfaces earlier with it.

The code below works or crashes, depending on which line I activate:
snip --- snip --- snip --- snip --- snip
\version "2.19.83"

music = \absolute {
      \repeat unfold 10000 {
         %d'1 % works
         %d'2 f' % works
         d'4 f' a' g' % crashes
         %d'8 f' a' g'   d' f' b' d' % crashes
      }
}

{ \music }
snip --- snip --- snip --- snip --- snip

My system is a current ArchLinux 64 bit with 64GB RAM installed.
Running under WSL Debian on Win10 Pro on the same machine gives a
similar result. It only takes longer.

Could someone knowledgeable w/r to the way lilyponds internals work
explain what is happening and if/how this can be avoided?

For my practical case I can split my rather large music file into chunks
and combine the fragments later outside of LP, but IMO this should not
be required.

Kind regards,
Michael
-- 
 Michael Gerdau       email: address@hidden
 GPG-keys available on request or at public keyserver

signature.asc
Description: OpenPGP digital signature