using the debugger

using the debugger

[Eric Abrahamsen]

I'm just learning to use the emacs debugger, and wish I'd done so a lot
earlier. There's one thing I can't figure out how to do. In many cases,
while I'm stepping through the calling of a function, it in turn calls
another function, which I don't really care about. I know what it's
going to return, I just want to get on with things, but the secondary
function is long and drawn-out and I have to hit "d" like fifty times to
get through it and back to the top-level function.

I thought "u" might be there to unstar a particular subroutine and let
me jump straight to its return, but that doesn't seem to be the case, or
else I'm using it wrong -- in any case I still have to walk through all
the gory internals of all secondary functions. Can someone tell me how I
can skip them?

Thanks!
Eric

Re: using the debugger

[ken]

On 04/08/2011 07:18 AM Eric Abrahamsen wrote:
> I'm just learning to use the emacs debugger, and wish I'd done so a lot
> earlier. There's one thing I can't figure out how to do. In many cases,
> while I'm stepping through the calling of a function, it in turn calls
> another function, which I don't really care about. I know what it's
> going to return, I just want to get on with things, but the secondary
> function is long and drawn-out and I have to hit "d" like fifty times to
> get through it and back to the top-level function.
> 
> I thought "u" might be there to unstar a particular subroutine and let
> me jump straight to its return, but that doesn't seem to be the case, or
> else I'm using it wrong -- in any case I still have to walk through all
> the gory internals of all secondary functions. Can someone tell me how I
> can skip them?
> 
> Thanks!
> Eric

Just don't instrument the functions you don't want to step through.  If
a function is already instrumented, undo that by evaluating it in the
normal way, i.e., place the point at the end of it and do C-x C-e.

Re: using the debugger

[Eric Abrahamsen]

On Fri, Apr 08 2011, ken wrote:

> On 04/08/2011 07:18 AM Eric Abrahamsen wrote:
>> I'm just learning to use the emacs debugger, and wish I'd done so a lot
>> earlier. There's one thing I can't figure out how to do. In many cases,
>> while I'm stepping through the calling of a function, it in turn calls
>> another function, which I don't really care about. I know what it's
>> going to return, I just want to get on with things, but the secondary
>> function is long and drawn-out and I have to hit "d" like fifty times to
>> get through it and back to the top-level function.
>> 
>> I thought "u" might be there to unstar a particular subroutine and let
>> me jump straight to its return, but that doesn't seem to be the case, or
>> else I'm using it wrong -- in any case I still have to walk through all
>> the gory internals of all secondary functions. Can someone tell me how I
>> can skip them?
>> 
>> Thanks!
>> Eric
>
> Just don't instrument the functions you don't want to step through.  If
> a function is already instrumented, undo that by evaluating it in the
> normal way, i.e., place the point at the end of it and do C-x C-e.

In this case I'm using the debugger to find out why a particular
function produces an error. I'm instrumenting this top level function
and then stepping through it using "d" to see what's going on, but in
the middle there's, say, a ibus related function call that I know is
incredibly complicated, and also isn't the source of the error. So I'd
like to just hop over that particular ibus call and continue on with the
body of the function. Hope that's a clearer explanation…

Thanks!
Eric

RE: using the debugger

[Drew Adams]

> while I'm stepping through the calling of a function, it in turn calls
> another function, which I don't really care about. I know what it's
> going to return, I just want to get on with things, but the secondary
> function is long and drawn-out and I have to hit "d" like 
> fifty times to get through it and back to the top-level function. 
> Can someone tell me how I can skip them?

Use `c' to `c'ut to the `c'hase, skipping directly to the result of an
evaluation.

Use `d' to `d'ig through an evaluation step by step.

Remember the `C-h m' is your friend in nearly any buffer.


[Ken's reply about "instrumenting" was no doubt about using `edebug'.  I take it
that you are instead using `debug' (which is what I use, FWIW).  IOW, I assume
you're either calling `(debug)' in your code or doing `M-x debug-on-entry' or
setting `debug-on-error' or `debug-on-quit' to non-nil.]

Re: using the debugger

[Eric Abrahamsen]

On Fri, Apr 08 2011, Drew Adams wrote:

>> while I'm stepping through the calling of a function, it in turn calls
>> another function, which I don't really care about. I know what it's
>> going to return, I just want to get on with things, but the secondary
>> function is long and drawn-out and I have to hit "d" like 
>> fifty times to get through it and back to the top-level function. 
>> Can someone tell me how I can skip them?
>
> Use `c' to `c'ut to the `c'hase, skipping directly to the result of an
> evaluation.

That was it! I'd been assuming, for no good reason, that 'c' would
continue the entire evaluation of the top-level function, not just the
frame I happened to be on. Thanks!

> [Ken's reply about "instrumenting" was no doubt about using `edebug'.  I take it
> that you are instead using `debug' (which is what I use, FWIW).  IOW, I assume
> you're either calling `(debug)' in your code or doing `M-x debug-on-entry' or
> setting `debug-on-error' or `debug-on-quit' to non-nil.]

I am using 'debug', with debug-on-entry, but only just ten minutes ago
discovered edebug, so I'll look into that as well.

Thanks again.

Re: using the debugger

[rusi]

On Apr 8, 7:03 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
> > while I'm stepping through the calling of a function, it in turn calls
> > another function, which I don't really care about. I know what it's
> > going to return, I just want to get on with things, but the secondary
> > function is long and drawn-out and I have to hit "d" like
> > fifty times to get through it and back to the top-level function.
> > Can someone tell me how I can skip them?
>
> Use `c' to `c'ut to the `c'hase, skipping directly to the result of an
> evaluation.
>
> Use `d' to `d'ig through an evaluation step by step.
>
> Remember the `C-h m' is your friend in nearly any buffer.
>
> [Ken's reply about "instrumenting" was no doubt about using `edebug'.  I take it
> that you are instead using `debug' (which is what I use, FWIW).  IOW, I assume

Just curious -- why do you prefer debug over edebug?
Or perhaps a better question: Whats your debug-workflow?

> you're either calling `(debug)' in your code or doing `M-x debug-on-entry' or
> setting `debug-on-error' or `debug-on-quit' to non-nil.]

RE: using the debugger

[Drew Adams]

> Just curious -- why do you prefer debug over edebug?

No good reason that I can think of.  It's what I'm used to.  That's probably the
best reason I can give, albeit a lame one.

From time to time someone exclaims that I should try `edebug' because it is
superior.  And from time to time I do try `edebug'.  But I always go back to
`debug', for some reason.

I don't claim to be a model in this regard; it's just what I happen to use.
YMMV.

> Or perhaps a better question: Whats your debug-workflow?

What I mentioned earlier.  I use `M-x debug-on-entry' a lot.  I use variables
`debug-on-error' (most of the time) and `debug-on-quit' (sometimes), depending
on the context.

And sometimes I insert `(debug)' or `(debug nil SHOW-ME)' into source code at
specific points, in particular to bypass code I'm uninterested in (as opposed to
`debug-on-entry', which uses the function call as entry point).

And I use calls to `message', old-school style, in particular when using the
debugger heisenbergs the execution negatively.

---

FWIW, the one improvement, in particular, that I wish someone would make to the
debugger (the debugger I use) is to have an option to control what `d' does on a
macro or special form call - or to provide another key, say `s', that does what
I want.

I, and I suspect most users, typically want to use `c' when I get to a macro
call, because I don't care to drill down through the macro expansion - I trust
it most of the time.  But sometimes I don't notice in time and I hit `d'
instead.

Without such an enhancement I need to pay a little more attention, to stop
hitting `d' and hit `c' when I get to a macro call.  In particular, `dolist' and
similar are a pain because they involve two levels of macros, for `dolist' and
for `block'.

Sure, when you catch yourself already started down the rabbit hole you can hit
`c' and `d' a bit to recuperate, but the point is that you have to pay a little
attention during a part of the process that should be a no-brainer (autopilot).

I filed an enhancement request for this back in 2009:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3466,
but no one ever responded.  Maybe someone on this list will feel like submitting
a patch to improve the debugger this way. ;-)

Re: using the debugger

[Tim X]

rusi <rustompmody@gmail.com> writes:

> On Apr 8, 7:03 pm, "Drew Adams" <drew.ad...@oracle.com> wrote:
>> > while I'm stepping through the calling of a function, it in turn calls
>> > another function, which I don't really care about. I know what it's
>> > going to return, I just want to get on with things, but the secondary
>> > function is long and drawn-out and I have to hit "d" like
>> > fifty times to get through it and back to the top-level function.
>> > Can someone tell me how I can skip them?
>>
>> Use `c' to `c'ut to the `c'hase, skipping directly to the result of an
>> evaluation.
>>
>> Use `d' to `d'ig through an evaluation step by step.
>>
>> Remember the `C-h m' is your friend in nearly any buffer.
>>
>> [Ken's reply about "instrumenting" was no doubt about using `edebug'.  I take it
>> that you are instead using `debug' (which is what I use, FWIW).  IOW, I assume
>
> Just curious -- why do you prefer debug over edebug?
> Or perhaps a better question: Whats your debug-workflow?
>
>> you're either calling `(debug)' in your code or doing `M-x debug-on-entry' or
>> setting `debug-on-error' or `debug-on-quit' to non-nil.]
>

I can't answer why Drew uses debug, but I use it frequently simply because
for many problems it is sufficient and I find it easier than setting up
edebug. I tend to switch to edebug if the problem proves to be tricky 
and the problem is not revealing itself via reading the code or debug
isn't giving the level of control/interaction I need. 

Probably the most common 'tool' I use is message. I personally don't
like stepping through lines of code watching variables change value to
find a problem. My preferred approach is to study the code and trace
through it in my head as most of the time, I find the bugs that are the
trickiest to fix are more about logic problems and errors in the
algorithm. Really understanding what the code does is the key and I find
studying the source to be more rewarding than stepping/tracing through
lines of code with a debugger because that doesn't give a high
enough/overall view of what was intended - sometimes, you need to see
the forest and not the trees.

Tim


-- 
tcross (at) rapttech dot com dot au

Re: using the debugger

[Perry Smith]

On Apr 8, 2011, at 5:14 PM, Tim X wrote:

> Probably the most common 'tool' I use is message.

Yep! I call it debug via printf.  Crude but often very quick.  And then I add in some local variable as a flag to turn all my messages on or off.  I've debug the same script, C code, lisp function, etc more than once more than once.

pedz

Re: using the debugger

[David Combs]

In article <mailman.3.1302286616.22287.help-gnu-emacs@gnu.org>,
Drew Adams <drew.adams@oracle.com> wrote:
>> Just curious -- why do you prefer debug over edebug?
>
...
...
>
>---
>
>FWIW, the one improvement, in particular, that I wish someone would make to the
>debugger (the debugger I use) is to have an option to control what `d' does on a
>macro or special form call - or to provide another key, say `s', that does what
>I want.
>
>I, and I suspect most users, typically want to use `c' when I get to a macro
>call, because I don't care to drill down through the macro expansion - I trust
>it most of the time.  But sometimes I don't notice in time and I hit `d'
>instead.
>
>Without such an enhancement I need to pay a little more attention, to stop
>hitting `d' and hit `c' when I get to a macro call.  In particular, `dolist' and
>similar are a pain because they involve two levels of macros, for `dolist' and
>for `block'.
>
>Sure, when you catch yourself already started down the rabbit hole you can hit
>`c' and `d' a bit to recuperate, but the point is that you have to pay a little
>attention during a part of the process that should be a no-brainer (autopilot).
>
>I filed an enhancement request for this back in 2009:
>http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3466,
>but no one ever responded.  Maybe someone on this list will feel like submitting
>a patch to improve the debugger this way. ;-)
>
>

Never used any emacs debugger -- but would a "backup" or "undo traversal step"
help?

Now, what it would do about variables you'd modified -- maybe it could
undo those too (one step at a time, backing up).

(Or might one or the other of the debuggers already have such
a feature?)

Looks to me like it'd be very helpful...

David