Re: Crash with simultaneous-duplicating music function and \once\offset

[David Kastrup]

Aaron Hill <address@hidden> writes:

> On 2018-07-15 20:09, Aaron Hill wrote:
>> Seems the custom music function is not needed to reproduce a crash.
>>
>> %%%%
>>   \version "2.19.82"
>>   music = { \once \offset length 5 Stem 4 4 }
>>   << \music \music >>
>> %%%%
>>
>> This also results in:
>>
>>> GNU LilyPond 2.19.82
>>> Processing `crash.ly'
>>> Parsing...
>>> Interpreting music...
>>> Preprocessing graphical objects...
>>> fish: “lilypond crash.ly” terminated by signal SIGSEGV (Address
>>> boundary error)
>
> David mentioned two issues: using `<<...>>` top-level and using
> unpitched notes.
>
> Consider the following not-quite-as-minimal example:
>
> %%%%
>   \version "2.19.82"
>   music = { \once \offset length 5 Stem c'4 c'4 }
>   \new Staff { c'4 << \music \music >> c'4 }
> %%%%

I got
Tracker issue: 5386 (https://sourceforge.net/p/testlilyissues/issues/5386/)
Rietveld issue: 367760043 (https://codereview.appspot.com/367760043)
Issue description:
  Make grob-transform robust against cloned invocations  Well,
  "robust" is a bit of an exaggeration but at least it doesn't crash
  anymore.  It just drops transforms (and warns about that) until the
  rest can be handled safely.   Also contains commit:  Add ly:grob-
  warning function

for this one.

> I tried manually duplicating the music:
>
> %%%%
>   \version "2.19.82"
>   music = { \once \offset length 5 Stem c'4 c'4 }
>   musicCopy = { \once \offset length 5 Stem c'4 c'4 }
>   \new Staff { c'4 << \music \musicCopy >> c'4 }
> %%%%
>
> This variant does compile, although the side-effect here is that the
> stem length is twice as long.

As expected.

> I suppose this would make sense providing simultaneous music results
> in a single stem shared by the notes so that the two \offsets stack
> their effects.  But then that doesn't explain why the same behavior
> isn't seen when omitting \once in the first example.

Try with \temporary (though avoiding the crash with the same kind of
manual copy).  Without either \temporary or \once, any preceding
override (such as another \offset) is replaced, so you see only one stem
length increase.

> In that case, there is still a shared stem, but the \offset effect is
> not doubled.


> Based on that success, I tried to get the original approach to compile
> using either music-clone or ly:music-deep-copy, but perhaps I do not
> understand those functions well enough to use properly.  I would have
> expected that it would be possible to programmatically achieve the
> equivalent to \musicCopy as in my second example, with something like
> this:
>
> %%%%
>   \version "2.19.82"
>   music = { \once \offset length 5 Stem c'4 c'4 }
>   \new Staff { { c'4 << \music $(music-clone music) >> c'4 } }
> %%%%
>
> It still fails in the same way.

That one's the bug that my patch is supposed to, well, not fix but
lessen its consequences and giving a warning.  There is another one (a
failed assertion) that's still open.

-- 
David Kastrup