>> I'm on a GNU/Linux box, running `autogen.sh' with >> `--disable-optimising', and compiling with g++ 4.6.2. > > The released builds are not compiled this way, so no-one can > reproduce your bug without using Linux to create a debug-enabled > build.
Well, assertion aborts should *never* happen, so it's either a
compiler bug or a bug in the lilypond code, probably compiled away in
optimized builds.
> I would guess that readers of bug-lilypond are more interested in
> helping to record bugs that affect released builds (I am, at least).
OK, so it's better to send such problem reports to lilypond-devel?
> - y = me->get_bound (dir)->extent (common_y, Y_AXIS).center ();
> + Interval ii = me->get_bound (dir)->extent (common_y, Y_AXIS);
> + if (!ii.is_empty())
> + y = ii.center ();
This works, thanks, and I get output which looks like being
predictable (see attached image), assuming that a non-existing
notehead makes the glissando point to position zero.
>> BTW, here is a full backtrace (of the first 32 frames).
>
>> #0 Interval_t<double>::center (this=0xbfff96ec)
>> at ../flower/include/interval.hh:226
>> #1 0x082d9cdd in Note_head::get_stem_attachment (fm=0x8602ec8, key=...)
>> at note-head.cc:181
>
> Somehow, you got a misleading backtrace, because note-head.cc:180
> tests the same condition as the assertion that you report as failed.
Misleading? Using gdb-7.3, I've set the breakpoint directly at
interval.hh:226. What should I've done instead?
Werner
<<inline: gliss.png>>
_______________________________________________ bug-lilypond mailing list [email protected] https://lists.gnu.org/mailman/listinfo/bug-lilypond
