[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Assertion !is_empty() failed - yet again
From: |
David Kastrup |
Subject: |
Re: Assertion !is_empty() failed - yet again |
Date: |
Sat, 27 Apr 2019 12:44:20 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Andrew Bernard <address@hidden> writes:
> Thanks David.
>
> I built 2.21.0 on Ubuntu 19.04. Running gdb, sure enough, it's the familiar
> tuple bracket issue:
>
> Drawing systems...lilypond:
> /home/andro/lilypond-git/flower/include/interval.hh:227: T
> Interval_t<T>::center() const [with T = double]: Assertion `!is_empty ()'
> failed.
>
> Program received signal SIGABRT, Aborted.
> __GI_raise (address@hidden) at ../sysdeps/unix/sysv/linux/raise.c:50
> 50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
> (gdb) backtrace
> #0 0x00007ffff76bfed7 in __GI_raise (address@hidden) at
> ../sysdeps/unix/sysv/linux/raise.c:50
> #1 0x00007ffff76a1535 in __GI_abort () at abort.c:79
> #2 0x00007ffff76a140f in __assert_fail_base
> (fmt=0x7ffff782f588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n",
> assertion=0x55555594ab94 "!is_empty ()", file=0x55555594abb8
> "/home/andro/lilypond-git/flower/include/interval.hh", line=227,
> function=<optimised out>) at assert.c:92
> #3 0x00007ffff76b1012 in __GI___assert_fail
> (address@hidden "!is_empty ()",
> address@hidden
> "/home/andro/lilypond-git/flower/include/interval.hh", address@hidden,
> address@hidden <Interval_t<double>::center()
> const::__PRETTY_FUNCTION__> "T Interval_t<T>::center() const [with T =
> double]") at assert.c:101
> #4 0x00005555556d93c7 in Interval_t<double>::center() const
> (this=<optimised out>) at
> /home/andro/lilypond-git/lily/include/lily-guile-macros.hh:70
> #5 0x00005555556d93c7 in Tuplet_number::calc_x_offset(scm_unused_struct*)
> (smob=<optimised out>) at /home/andro/lilypond-git/lily/tuplet-number.cc:293
>
> Last time this arose Aaron provided this code for me:
>
> \override TupletBracket.X-positions = #(lambda (grob)
> (let ((xpos (ly:tuplet-bracket::calc-x-positions grob)))
> (if (> (car xpos) (cdr xpos))
> (let ((mid (/ (+ (car xpos) (cdr xpos)) 2)))
> (format #t "\nwarning: Fixing invalid X-positions ~a" xpos)
> (cons mid mid))
> xpos)))
>
> Adding that prints a warning, and works around the issue, and I can,
> thankfully go on.
>
> But since this keeps coming up, is it something that should be reported as
> a bug, so as to eventually get fixed?
I am looking at this code right now and it is not clear to me that
break-overshoot is used consistently. Its usual settings are something
like
(break-overshoot ,number-pair? "How much does a broken spanner
stick out of its bounds?")
Examples of this property are
Documentation/ly-examples/cary-layout.ily: \override Beam.break-overshoot =
#'(-0.5 . 1.0)
input/regression/beam-outside-beamlets.ly: \override Beam.break-overshoot =
#'(-0.5 . 0.5)
input/regression/spanner-break-overshoot.ly: \override Beam.break-overshoot =
#'(1.0 . 2.0)
input/regression/spanner-break-overshoot.ly: \override
TupletBracket.break-overshoot = #'(1.0 . 2.0)
so it's sometimes positive, sometimes negative. The default code in
lily/tuplet-bracket.cc does
if (connect_to_other[d])
{
Interval overshoot (robust_scm2drul (me->get_property
("break-overshoot"),
Interval (-0.5, 0.0)));
if (d == RIGHT)
x_span[d] += d * overshoot[d];
else
x_span[d] = (bounds[d]->break_status_dir ()
? Axis_group_interface::generic_bound_extent
(bounds[d], commonx, X_AXIS)[-d]
: robust_relative_extent (bounds[d], commonx,
X_AXIS)[-d])
- overshoot[LEFT];
}
so the default value is negative which moves the left end of the span to
the _right_ since the left overshoot is subtracted.
The comparable code for beams does
if (on_line_bound
&& me->get_bound (event_dir)->break_status_dir ())
{
current.horizontal_[event_dir]
= (Axis_group_interface::generic_bound_extent
(me->get_bound (event_dir),
commonx,
X_AXIS)[RIGHT]
+ event_dir * break_overshoot[event_dir]);
}
which again puts in a factor of -1 for the left bound, also using a
default value of -0.5 .
Is this negative break_overshoot (which reduces the extent on the left
side, possibly until the interval becomes empty) as intended or is this
a consequence of confusion?
--
David Kastrup