Re: Debugging help on lilypond

[David Kastrup]

Carl Sorensen <address@hidden> writes:

> On 12/12/09 2:27 PM, "Joe Neeman" <address@hidden> wrote:
>
>> On Sat, 2009-12-12 at 14:15 -0700, Carl Sorensen wrote:
>>> So I've finally gotten to a point where I think I know what to do with the
>>> autobeaming code to make it work properly in 4/4 time with a 1/16 note in
>>> the second beat.
>>> 
>>> I've written code to try to fix it.  The code seems to execute properly
>>> through my changes, but then it gets into a problem, and I get this error
>>> message:
>>> 
>>> terminate called after throwing an instance of 'std::out_of_range'
>>>   what():  vector::_M_range_check
>>> Abort trap
>>> 
>>> 
>>> So I try running it in gdb, and I get the same error.
>> 
>> At this point, you should be able to type "bt" to get a backtrace. You
>> can move up and down through the frames by typing "up" and "down" or you
>> can jump to the 23rd frame with "fr 23". Once you are in a frame, you
>> can examine all of the local variables. The first few frames will
>> probably be non-lilypond code, so you'll want to ignore them.
>
>
> Thanks, Joe.  This really helped.
>
> Now I have another problem.  I have something that seems impossible to me.

Without _any_ analysis of the actual problem, I am just regurgitating
some keyword-triggered advice from Emacs' DEBUG file.  You might have
compiled without optimization in which case it does not apply.  This
particular option might be considered useful generally since otherwise
debugging any abort/failed assertion (and what's the use of abort
without debugging?)  becomes quite useless.  Spent days on hunting down
an "impossible bug" more than once.

** When you are trying to analyze failed assertions, it will be
essential to compile Emacs either completely without optimizations or
at least (when using GCC) with the -fno-crossjumping option.  Failure
to do so may make the compiler recycle the same abort call for all
assertions in a given function, rendering the stack backtrace useless
for identifying the specific failed assertion.

-- 
David Kastrup