Menu
▾
▴
#5383 Crash with simultaneous-duplicating music function and \once \offset
On 2018-07-15 18:21, Simon Albrecht wrote:
Hello everybody,
this combination of a custom music function that combines the music
simultaneously with itself and a \once\offset command causes LilyPond
to crash (exit with return code 11):
%%%%%%%%%%%%
\version "2.19.82"
test =
#(define-music-function (parser location mus) (ly:music?)
#{ << $mus $mus >> #})
\test { \once\offset length 1 Stem 4 }
%%%%%%%%%%%%
On Sun, 15 Jul 2018 20:09:52 -0700, 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)
Omitting the \once lets the example compile. And use of \undo works in
lieu of \once:
%%%%
\version "2.19.82"
longStem = \offset length 5 Stem
music = { \longStem 4 \undo \longStem 4 }
<< \music \music >>
%%%%
However, attempting to test the "tweak" variant of \offset...
%%%%
\version "2.19.82"
music = { \offset Stem.length 5 4 4 }
<< \music \music >>
%%%%
...produced a different error:
GNU LilyPond 2.19.82
Processing `crash.ly'
Parsing...
Interpreting music...lilypond:
/home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/lily/context-def.cc:232:
std::vector<Context_def*>
Context_def::internal_path_to_acceptable_context(SCM, Output_def*, SCM,
std::set<const Context_def*>*) const: Assertion `(!(6 & ((scm_t_bits)
(0? (*(SCM*)0=(type_sym)): type_sym))) && ((0x7f & ((((scm_t_bits) (0?
(*(SCM*)0=((((SCM *)((scm_t_cell *) (((scm_t_bits) (0?
(*(SCM*)0=((((type_sym))))): (((type_sym)))))))) [((0))]))): (((SCM
*)((scm_t_cell *) (((scm_t_bits) (0? (*(SCM*)0=((((type_sym))))):
(((type_sym)))))))) [((0))])))))) == 5))' failed.
fish: “lilypond crash.ly” terminated by signal SIGABRT (Abort)
Figuring that perhaps the parser is confused by the naked duration, I
tried this:
%%%%
\version "2.19.82"
music = { \offset Stem.length 5 c'4 4 }
<< \music \music >>
%%%%
It compiles, but produces two staves as output rather than combining the
notes on one staff. I am almost certainly overlooking an important
detail in parsing which would explain this difference, but it is still
confusing to say the least.
-- Aaron Hill
Discussion
This is running so many different problems into one report that it isn't funny, and most of them are user-generated.
First, the principal problem is that
<< \music \music >>as top-level music will create two implicitStaffcontexts. This is totally expected behavior. In general, implicit contexts created as expressions in<< >>are not carried over to the next such expression.That is most certainly not a bug. The Learning manual contains:
Simultaneous music expressions: multiple staves
...............................................
Music Glossary: *note (music-glossary)polyphony::.
This technique is useful for polyphonic music. To enter music with
more voices or more staves, we combine expressions in parallel. To
indicate that two voices should play at the same time, simply enter a
simultaneous combination of music expressions. A ‘simultaneous’ music
expression is formed by enclosing expressions inside ‘<<’ and ‘>>’. In
the following example, three sequences (all containing two separate
notes) are combined simultaneously:
Note that we have indented each level of the input with a different
amount of space. LilyPond does not care how much (or little) space
there is at the beginning of a line, but indenting LilyPond code like
this makes it much easier for humans to read.
and the image clearly shows three staves.
The next problematic point is that the example gets started off with an unpitched note, and unpitched notes take their pitch from the preceding pitch. There is none here, so the note stays around without a definite pitch into the expression. That is an invalid expression to work with but it's not easy to determine when to warn about it and whether engravers get along with it anyway.
They usually do.
Except that then this unpitched note without definite vertical position is additionally shifted with
\offset.\offsetis sort of a trick function meddling in internals, and the internals here are in haywire state due to previous user action. Should it be made more robust against such abuse? Possibly.Now the "different error" I am not to sure about: it is a failed assertion. It is triggered by the line
c76d27c5924 lily/context-def.cc (Han-Wen Nienhuys 2004-09-05 11:19:14 +0000 232) assert (scm_is_symbol (type_sym));
I've never seen that assertion triggered before, and Dan has recently worked on context definitions. However, it would seem that at least the point where the problem triggers is old code. And the context creation does not really look related all that much to the other problems, either. So the question would be whether this problem can be triggered with older versions as well. But to figure that out, one would need to remove all unrelated complications and try reverting to a syntax supported previous to 2.19.
I am not sure how to deal with this now. Since issue #5386 has been committed, this one does not result in a crash. Instead one gets
Visual output is probably closer to what the user expected than otherwise (since the "correct" effect would be applying
\offsettwice, lengthening the single Stem by double the amount) but that may change in future versions, so warning is quite appropriate.So since the core of this bug report and most certainly the crash does no longer occur, I am marking this as "invalid". Further comments likely are better applied to issue #5386.