bug-lilypond
[Top][All Lists]
Advanced

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

Re: Assertion !is_empty() failed - yet again


From: Andrew Bernard
Subject: Re: Assertion !is_empty() failed - yet again
Date: Fri, 26 Apr 2019 23:54:10 +1000

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?

Andrew





On Fri, 26 Apr 2019 at 22:47, David Kastrup <address@hidden> wrote:

> Andrew Bernard <address@hidden> writes:
>
> > Lilypond 2.19.83. Yet again I see this error:
> >
> > Drawing systems...
> > Finding the ideal number of pages...
> > Fitting music on 15 or 16 pages...
> > Drawing systems...lilypond:
> > /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv
> .gnu.org--lilypond.git-stable-test/flower/include/interval.hh:227:
> > T Interval_t<T>::center() const [with T = double]: Assertion `!is_empty
> ()'
> > failed.
> > Aborted (core dumped)
> > make: *** [Makefile:57: sq1-215.pdf] Error 134
> >
> > After only about 30 pages of dense string quartet music, now happens
> when I
> > just add one more note. This came up for me before with tuplets, but now
> a
> > plain note triggers this.
> >
> > How do we move forward on solving this? Once more, irritatingly for me
> and
> > for all, I don;t know how to make an MWE to stimulate this.
> >
> > Perhaps resort to gdb backtrace again?
>
> Yes?  That's what the "core dumped" triggered by assertion failures is
> good for.  Which is why "abort" should not be marked "noreturn" in
> gcclib so that gcc maintains a stack state useful for backtrace analysis
> rather than saying "what the heck, I won't return anyway".  But you tell
> that to Drepper and you'll get derided from here to Westborough.
>
> But most of the time, a backtrace will be useful for failed assertions
> (I debugged around for days for a case where gcc decided to just fold
> all abort calls in some function to the same place but that happens
> rarely).
>
> --
> David Kastrup
>
> _______________________________________________
> bug-lilypond mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-lilypond
>


reply via email to

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