#4864 using beamed groups across staves - adding a slur or a phrasing slur causes lilypond to fail with an assertion

On 26/05/16 10:52, Andrew Bernard wrote:

I keep finding situations using beamed groups across staves where
adding a slur or a phrasing slur causes lilypond to fail with the
following error:

\version "2.19.41"

treble = {
  \clef treble
  \time 1/4
  s4 s
}

bass =  {
  \clef bass
  \time 1/4

  %\once \override Beam.positions = #'(4 . 4)
  \stemUp
  c32[\( c
  \change Staff = treble
  \stemDown c' e' g' c'' c'
  \change Staff = bass
  \tuplet 5/4 { e c g, d32\rest e' }
  \change Staff = treble
  g'
  \change Staff = bass
  g
  \change Staff = treble
  a'']\)
}

\score {

  \new PianoStaff
  <<
    \new Staff = "treble" { \treble }

    \new Staff = "bass" { \bass }
  >>

  \layout {
  }
}

Processing /home/andro/work/lilypond/fp/exp-slur-crash.ly' Parsing... Interpreting music... Preprocessing graphical objects... Finding the ideal number of pages... Fitting music on 1 page... Drawing systems... /home/andro/work/lilypond/fp/exp-slur-crash.ly:15:6: warning: no viable initial configuration found: may not find good beam slope c32 [\( c lilypond: /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/flower/include/interval.hh:227: T Interval_t::center() const [with T = double]: Assertion!is_empty
()' failed.

Refer to the MWE here for an example. This occurs in 2.19.41 at least.
I have not tried previous versions.

In other scenarios in my score even when the warning about not finding
a good beam slope is not emitted I still get the crash reliably in
this type of situation.

Is this a bug?

[Anonymous]

• Description has changed:

Diff:

--- old
+++ new
@@ -1,4 +1,3 @@
-
 On 26/05/16 10:52, Andrew Bernard wrote:
 > I keep finding situations using beamed groups across staves where
 > adding a slur or a phrasing slur causes lilypond to fail with the

[Anonymous]

Likely a faulty assertion. Versions of LilyPond previous to something
around 2.19.20 were compiled/distributed with assertions turned off. A
failed assertion usually indicates a condition that the program cannot
sensibly deal with and that should never occur. Well, here it occurs
and likely the program had some way of meddling on. Which likely
warrants more of a (non-fatal) programming_error until the malcondition
has been diagnosed and fixed.

--
David Kastrup

[Anonymous]

Andrew Bernard andrew.bernard@gmail.com writes:

Thanks. Do we raise a bug? The program stops and will not continue to
compile after this error.

Like after any failed assertion since an assertion indicates that the
program cannot continue sensibly.

So yes, that's a bug. The proper fix is finding out under which
conditions the assertion failure can trigger and then figure out how to
proceed in this case or how to avoid it.

The bandaid fix would be replacing the assertion failure with a
programming error as long as one can state with confidence that it will
not result in a hard crash.

--
David Kastrup

[Federico Bruni]

• Description has changed:

Diff:

--- old
+++ new
@@ -3,7 +3,7 @@
 > adding a slur or a phrasing slur causes lilypond to fail with the
 > following error:

-
+~~~~
 \version "2.19.41"

 treble = {
@@ -43,7 +43,7 @@
   \layout {
   }
 }
-
+~~~~

 >
 > Processing `/home/andro/work/lilypond/fp/exp-slur-crash.ly'

• status: New --> Accepted