> On 17 Nov 2021, at 13:42, Robert Schmaus <robert.schm...@web.de> wrote:
> 
> Dear Ponderers,
> 
> I was just about to quickly write down a sheet of music, nothing fancy at 
> all, when all of a sudden I got an exception. This is the full ly code (and I 
> can’t make it any shorter for the reasons explained below):
> 
> ...

> This compiled fine until I got to the last four bars in the file (inside the 
> \relative block). Then this was the lilypond message:
> 
> Starting lilypond 2.20.0 [Haydn 2 Bass.ly <http://bass.ly/>]...
> Processing `/Users/myname/Bass/Haydn 2 Bass.ly <http://bass.ly/>'
> Parsing...
> Interpreting music...
> warning: no music found in score
> Preprocessing graphical objects...
> Interpreting music...[8][16][24]
> Preprocessing graphical objects...
> Finding the ideal number of pages...
> Fitting music on 1 page...Assertion failed: (my_index == 0), function 
> line_divisions_rec, file 
> /Users/marnen/lilypond-mac-builder/source/lilypond/lily/page-breaking.cc 
> <http://page-breaking.cc/>, line 1040.
> Exited with return code 6.
> 
> 
> This message disappears if I remove the last \relative block. But it also 
> disappears if I remove the \header block (and leave in all the music). 
> The file also compiles fine if I remove the *first* \relative block. So, 
> there appears to be nothing wrong with all individual parts of the file, just 
> all together they refuse to cooperate.
> 
> What also mystifies me is that path in the penultimate line of the Exception 
> message: “/Users/marnen/lilypond-mac-builder/“ … that’s certainly not on my 
> computer.

That's because you have the binary as advertised in 
https://lists.gnu.org/archive/html/lilypond-user/2020-03/msg00077.html 
<https://lists.gnu.org/archive/html/lilypond-user/2020-03/msg00077.html>
on your system. It was built by Marnen, hence the path where the source resided 
when Marnen built it are stored in the debug-symbols which get reported when 
encountering the assertion error.

> Should I just keep on writing and hoping that the page layout will be ok 
> again in the end? Or does anyone see what’s the problem here?

I don’t hit the errors on my system (Mac OS 11.6.1) for the MacPorts build of 
lilypond stable (2.22.1), but don’t know whether that’s because I don’t 
encounter the error, or because assertions are not enabled in the MacPorts 
build (the error will only surface when assertions are enabled). The error 
condition itself is commented in source as a scenario that “should never occur”:
      /* this should never happen within a recursive call. If it happens
         at all, it means that we were called with an unsolvable problem
         and we should return an empty result */
If assertions are disabled the method will just stop further processing and 
return to the caller, if assertions are enabled it will result in the breaking 
error you encountered.





Reply via email to