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 (sig=sig@entry=6) 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 (sig=sig@entry=6) 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 (assertion=assertion@entry=0x55555594ab94 "!is_empty ()", file=file@entry=0x55555594abb8 "/home/andro/lilypond-git/flower/include/interval.hh", line=line@entry=227, function=function@entry=0x55555595c560 <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 <d...@gnu.org> wrote: > Andrew Bernard <andrew.bern...@gmail.com> 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 > bug-lilypond@gnu.org > https://lists.gnu.org/mailman/listinfo/bug-lilypond > _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond