Re: [2.20] Issue 4943 Manual page breaking causing assertion failure using Windows

[Thomas Morley]

2017-01-06 12:34 GMT+01:00 David Kastrup <address@hidden>:
> Thomas Morley <address@hidden> writes:
>
>> 2017-01-04 16:01 GMT+01:00 Chris Yate <address@hidden>:
>>> On Wed, 4 Jan 2017 at 14:25 Thomas Morley <address@hidden> wrote:
>>
>>> Well, it's odd. I'm not sure this is anything to do with /overrideProperty.
>>>
>>> Referring back to my original tests, I can change your definitions to the
>>> following, and it will crash on each of your test cases:
>>>
>>> Uncomment the \override line-break-permission and it renders OK.
>>>
>>> Chris
>>>
>>> ------------
>>> myAutoBreaksOn = {
>>>   %\override Score.NonMusicalPaperColumn.line-break-permission = #'allow
>>>   \override Score.NonMusicalPaperColumn.page-break-permission = #'allow
>>> }
>>>
>>> myAutoBreaksOff = {
>>>   %\override Score.NonMusicalPaperColumn.line-break-permission = ##f
>>>   \override Score.NonMusicalPaperColumn.page-break-permission = ##f
>>> }
>>
>> meanwhile I'm at the end of my knowledge.
>> So I limited myself to the attempt of creating a meaningful test-file.
>> It should display in terminal which Staff is currently compiled.
>>
>> I hope lilypond will proceed with the next score once an assertion
>> failure happens (not sure about that, though)
>>
>> In order not to clutter the terminal output you could compile it with
>> lilypond --loglevel=WARN manual-breaking-assertion-failure-04.ly
>>
>> I'd expect some assertion failures, but at least some scores should
>> work for you (hopefully).
>> Please post the terminal output.
>
> Assertions should not be used when LilyPond has a sane way to continue:
> for that case, programming errors are more appropriate.  The question is
> whether this is the case here: I think we are also dealing with bad
> output even when assertions are disabled: right?

On Linux no assertion failure happens and the output _is_ as expected.
Lines running out of page or compressed over-full pages are forced by
the test-cases.
So the bad output is intended in the tests.

> But as long as it is not _dangerous_ to continue (like using 0 pointers
> or uninitialized data), a programming error might be more suitable.


The function which does the assertion is min_page_count from page-breaking.cc
Btw, not triggered if one does in the ly-file:
\paper { page-breaking = #ly:minimal-breaking }

I tried to insert some print-functions in page-breaking.cc, but I'm
really not a C++-guy...
All I managed was to display simple text-strings, which indeed confirm
the problem in min_page_count but no computed data.
But that was already clear from the error-message Chris had posted.

Cheers,
 Harm