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 implicit `Staff` contexts. 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:
<<
\relative { a'2 g }
\relative { f'2 e }
\relative { d'2 b }
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.
Note: each note is relative to the previous note in the input,
only the first is relative to the ‘c''’ in the initial
‘\relative’ command.
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`. `\offset` is 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.
---
** [issues:#5383] Crash with simultaneous-duplicating music function and \once
\offset **
**Status:** New
**Created:** Mon Jul 16, 2018 05:45 AM UTC by pkx166h
**Last Updated:** Mon Jul 16, 2018 05:45 AM UTC
**Owner:** nobody
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
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/testlilyissues/issues/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/testlilyissues/admin/issues/options. Or, if this is
a mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Testlilyissues-auto mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto
