lilypond-auto
[Top][All Lists]
Advanced

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

[Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5383 Crash wi


From: Auto mailings of changes to Lily Issues via Testlilyissues-auto
Subject: [Lilypond-auto] [LilyIssues-auto] [testlilyissues:issues] #5383 Crash with simultaneous-duplicating music function and \once \offset
Date: Mon, 16 Jul 2018 07:44:51 -0000

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 address@hidden 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
address@hidden
https://lists.sourceforge.net/lists/listinfo/testlilyissues-auto

reply via email to

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