[Top][All Lists]

[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: Fri, 26 Apr 2019 14:47:48 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

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

David Kastrup

reply via email to

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