Re: 2.17.6: assertion failed with \glissando

[Werner LEMBERG]

>> 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