bug-lilypond
[Top][All Lists]
Advanced

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

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


From: David Kastrup
Subject: Re: Crash with simultaneous-duplicating music function and \once\offset
Date: Tue, 17 Jul 2018 00:14:35 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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 }
> %%%%
>
> Near as I can tell, the thing that makes the difference here is the
> \once.  If you omit the \once (which means the stem length change
> persists), then you can at least get it to compile.

That's plausible: \once incurs action both at the current timestep and
in preparation for the next timestep.  If the context is in bad shape
for the latter (and the context is not slated for continuation here),
that could trigger the trouble.

>
> 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.

That would be how it should be I think.  Note that \music already
triggers a copy to be made.  Maybe that copy is not dealing well with
the kind of code/closure/container \offset generates?  If that is not
copied and is then subsequently modified due to property value caching,
the cached value might bleed into the other copy?

I hope it isn't anything like that since that sounds nightmarish.

> 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.

I'll take a look tomorrow.

-- 
David Kastrup



reply via email to

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