lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: min-systems-per-page causes LilyPond to hang 2.20


From: Richard Shann
Subject: Re: min-systems-per-page causes LilyPond to hang 2.20
Date: Fri, 23 Oct 2020 10:18:55 +0100

On Fri, 2020-10-23 at 10:17 +0200, Jean Abou Samra wrote:
> Le 21/10/2020 à 17:58, Jean Abou Samra a écrit :
> > Le 21/10/2020 à 17:37, Richard Shann a écrit :
> > 
> > > I've noticed that having
> > > 
> > > min-systems-per-page  = 2
> > > 
> > > can in some circumstances cause LilyPond to hang. The attached
> > > non-minimal file exhibits this behavior:
> > > 
> > > Starting lilypond 2.20.0 [NonTypesettablePart.ly]...
> > > Processing `/tmp/frescobaldi-
> > > hm6j987d/tmpvp8zypvl/NonTypesettablePart.ly'
> > > Parsing...
> > > Interpreting music...[8][16]
> > > Preprocessing graphical objects...
> > > Interpreting music...[8][16][24][32][40][48][56][64][72]
> > > Preprocessing graphical objects...
> > > Interpreting music...[8][16][24][32]
> > > Preprocessing graphical objects...
> > > Interpreting music...[8][16][24][32][40][48]
> > > Preprocessing graphical objects...
> > > Interpreting music...
> > > Preprocessing graphical objects...
> > > Calculating line breaks...
> > > Drawing systems...
> > > Fitting music on 5 pages...
> > > [hangs ... manual abort]
> > > Aborting lilypond 2.20.0 [NonTypesettablePart.ly]...
> > > 
> > > commenting out the line
> > > min-systems-per-page  = 2
> > > allows it to typeset normally, curiously it does not have an
> > > orphan
> > > line.
> > > 
> > > I just wondered if this is a known issue - I don't see it
> > > mentioned in
> > > the docs
> > > 
> > > https://lilypond.org/doc/v2.20/Documentation/notation/other-paper
> > > -variables#index-min_002dsystems_002dper_002dpage 
> > > 
> > > 
> > > there is a very large amount of irrelevant material in the
> > > attached
> > > lily file which I would be in the best position to excise if that
> > > were
> > > useful, but I wouldn't want to undertake the task if the issue
> > > was
> > > already known about, or there was no-one wanting to work on it
> > > anyway,
> > > or indeed if it wouldn't really help as this bug is not at all
> > > likely
> > > to be due to some typo to be spotted by eye.
> > > Let me know if help would be welcomed.
> > > 
> > > Richard Shann
> > 
> > Hello,
> > 
> > I could not find this bug in the list of current issues,
> > which for your information is available at
> > 
> > https://gitlab.com/lilypond/lilypond/-/issues
> > 
> > It would certainly help if you could boil it down to a
> > minimal example.
> > 
> > Best regards,
> > Jean
> > 
> 
> Any update on this?

I'm afraid I wasn't perhaps clear enough in what I wrote: I was
offering to remove large amounts of irrelevant material from the .ly
file as it is machine-generated (by Denemo) and I understand what can
be dropped without changing the music that LilyPond will try to
typeset. 
However, even this is not an insignificant task and I'm not at all
clear in what debugging scenario this would be useful. Normally when
someone finds a crash asking them to chop down the file to isolate the
bit causing the crash makes perfect sense. The file is hand-written and
often chopping it down will reveal some typo or syntax combination
which triggers the crash. In this case the same bits of syntax have
been generated in thousands of files without trouble except for the
introduction of min-systems-per-page  = 2 which is a new feature in
Denemo. So it is highly likely that it is the combination of this
syntax with \pageBreak that causes LilyPond to hang. It also means that
altering any of the music that will actually be typeset is likely to
trigger the disappearance/re-appearance of the bug - and indeed I found
just this to be the case when I was first trying to track down the
cause of the bug.
So, if someone is wishing to tackle the debugging and needs irrelevant
material to be removed from the exemplar for some specific reason I can
help. But it would only reduce the file by about three quarters. I
suspect debugging this would require detecting the loop that is being
triggered and eyeballing the source code involved to see where it is
being assumed that something will always break out of the loop. For
that sort of work the input is irrelevant.

Richard










reply via email to

[Prev in Thread] Current Thread [Next in Thread]