lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging help on lilypond


From: David Kastrup
Subject: Re: Debugging help on lilypond
Date: Mon, 14 Dec 2009 11:20:21 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.50 (gnu/linux)

Carl Sorensen <address@hidden> writes:

> Quoting David Kastrup:
>
> 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.
>
> </quote>
>
> I've compiled LilyPond using --disable-optimizing, so it should be
> debuggable.

Checked the compilation options on --disable-optimizing, and you are
right.

> I'm running gdb directly from the command prompt, rather than through
> Emacs, so I don't think the optimization of Emacs should apply.

Sorry for the red herring: this does not involve using Emacs at all.
The above blurb was from the documentation for compiling Emacs itself.
It applies to any other program you want to debug equally well, and it
does not matter whether or not you use Emacs as your IDE for debugging.

> But if I'm wrong in these assumptions, I'd be happy to have you tell
> me and give me some pointers as to what to do.

It does not appear like you need to do anything beyond
--disable-optimizing.  The advice was for how to properly debug failed
assertions when you _did_ use optimizing.  In _that_ case, you want to
explicitly switch off one particular optimization (crossjumping) that
makes all tracebacks potentially useless.

Sorry for the noise: it was basically keyword-triggered.

-- 
David Kastrup





reply via email to

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