capturing backtraces

capturing backtraces

[Nic Ferrier]

I want to capture the backtrace that was current at the time of an error
into a list, string or buffer.

Something like:

  (condition-case err
     (thing-that-causes-errors)
    (error (setq saved-backtrace 
              (way-to-get-backtrace-from-error err))))

Where the function way-to-get-backtrace-from-error represents a function
that can get the backtrace from an error.


Anyone have a clue how I can do that?

I asked this question before and Stefan referred me to
macroexp--backtrace
(http://lists.gnu.org/archive/html/emacs-devel/2014-05/msg00268.html)
which uses backtrace-frame. That function doesn't seem to be able to get
the backtrace from the point of the error though:

 (defun nic-error ()
   (let ((x 1))
     (error "MEH")))

 (condition-case err
     (nic-error)
   (error (backtrace-frame 1)))

 => (nil condition-case err (nic-error) (error (backtrace-frame 1)))

that's not what I want at all, as you can see it grabs the current
backtrace of the currently executing stack.

We must be able to do this though because the debugger does it to
display the backtrace that happened to cause an error when we have
debug-on-error turned on.


Anyone?


Nic

Re: capturing backtraces

[Nic Ferrier]

Nic Ferrier <nferrier@ferrier.me.uk> writes:

>   (condition-case err
>      (thing-that-causes-errors)
>     (error (setq saved-backtrace 
>               (way-to-get-backtrace-from-error err))))
>
> Where the function way-to-get-backtrace-from-error represents a function
> that can get the backtrace from an error.

Aha. Something like this works:

 (defun nic-error ()
   (let ((x 1))
     (error "MEH")))

 (defvar nic-args nil)

 (flet ((debug (&rest args)
          (setq nic-args args)))
   (condition-case err
       (nic-error)
     ((debug error) "blah")))

It seems a bit odd having to specify the debugger to capture the
backtrace.

I guess I could make a new condition-case like macro that did this
routinely.

Wouldn't it be better to just grab the backtrace whenever an error
occurs and put it in a global or push it on to a global list?


Nic

Re: capturing backtraces

[Samuel Bronson]

> Wouldn't it be better to just grab the backtrace whenever an error
> occurs and put it in a global or push it on to a global list?

Yes. Yes it would.

Re: capturing backtraces

[Stefan Monnier]

 > (flet ((debug (&rest args)
 >          (setq nic-args args)))

Better bind the `debugger' variable.

> Wouldn't it be better to just grab the backtrace whenever an error
> occurs and put it in a global or push it on to a global list?

Depends what you mean by better: the normal representation of the
backtrace is transient (embedded in the C stack), so that would require
converting it to an Elisp list upon every call to Fsignal.

IOW, you'd have to pay for it all the time, even tho it's very rarely
used (as a percentage of the number of times Fsignal is called).

But we could probably arrange for something less hackish than rebinding
`debug'.  Maybe a new debugger-extra-data-function which would be called
by Fsignal and whose return value would be added data to the condition
that's being signaled (so you'd receive it in the `err' variable of your
condition-case).


        Stefan

Re: capturing backtraces

[Nic Ferrier]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>  > (flet ((debug (&rest args)
>  >          (setq nic-args args)))
>
> Better bind the `debugger' variable.
>
>> Wouldn't it be better to just grab the backtrace whenever an error
>> occurs and put it in a global or push it on to a global list?
>
> Depends what you mean by better: the normal representation of the
> backtrace is transient (embedded in the C stack), so that would require
> converting it to an Elisp list upon every call to Fsignal.
>
> IOW, you'd have to pay for it all the time, even tho it's very rarely
> used (as a percentage of the number of times Fsignal is called).
>
> But we could probably arrange for something less hackish than rebinding
> `debug'.  Maybe a new debugger-extra-data-function which would be called
> by Fsignal and whose return value would be added data to the condition
> that's being signaled (so you'd receive it in the `err' variable of your
> condition-case).

We could just have a variable to decide whether the signal should do
that or not.

A bit like binding the debugger variable, but not quite so extreme.

I will probably setq the debugger variable for now, to achieve what I
want.

But I think I still have to arrange for the condition-cases to have the
debug symbol, which means I have to write the code in a particular way
just for this reason.


Nic

Re: capturing backtraces

[Nic Ferrier]

Oh well.

I wrote this:

 (defmacro try (form &rest body)
   "Try FORM and eval BODY if it fails.

 Within BODY `backtrace' will return the backtrace including the
 stack which caused the problem.  This can be used for actually
 debugging the problem."
   (declare (indent 1))
   (let ((ret-var (make-symbol "ret-var")))
     `(let* (,ret-var
             (debug-on-error t)
             (debugger
              (lambda (&rest args)
                (setq ,ret-var (progn ,@body)))))
        (condition-case err
            (setq ,ret-var (progn ,form))
          ((debug error)))
        ,ret-var)))

To be used like this:

 (try
   (something-that-causes-an-error)
  (handle-the-error
     possibly-doing
     (with-output-to-string (backtrace))))

It's not perfect because the backtrace you get like that includes the
stuff after the debugger enters. It's slightly odd behaviour. If I
understand it correctly the debugger is entered directly from the
error. So the debugger appears to be a continuance (I don't mean a
Scheme continuation) of the stack which caused the error.

I wonder if I can repeatedly do this, if errors need to be properly
"quit" somehow.

I'll give it a go in marmalade, that's quite a stressful environment for
this sort of thing.


Nic