bug#10025: 24.0.91; Lisp debugger not working right

[Michael Heerdegen]

Hello,

@Stefan: I CC'd you intentionally, because I think you can help here.

I think I found out the reason for this.  This is the problem: when
you use `debug-on-entry' and the debugger is invoked by an instrumented
function, a wrong frame is flagged:

> Uday S Reddy <u.s.reddy@cs.bham.ac.uk> writes:

> > (defun a ()
> >   (b)
> >   (c))
> >
> > (defun b ()
> >   (message "b entered"))
> >
> > (defun c ()
> >   (message "c entered"))
> >
> > Place a debug-on-entry on `b' and `c'
> >
> > When `b' is entered, the backtrace buffer shows:
> > -----
> > Debugger entered--entering a function:
> >   b()
> > * a()
> >   eval((a) nil)
> >   eval-expression((a) nil)
> >   call-interactively(eval-expression nil nil)
> > -----
> > Note that there is a spurious breakpoint on `a', and no breakpoint
> > on `b'.

The crucial point are the hardcoded frame numbers in this part of the
code of `debug':

>             (when (eq (car debugger-args) 'debug)
>               ;; Skip the frames for backtrace-debug, byte-code,
>               ;; and implement-debug-on-entry.
>               (backtrace-debug 4 t)
>               ;; Place an extra debug-on-exit for macro's.
>               (when (eq 'lambda (car-safe (cadr (backtrace-frame 4))))
>                 (backtrace-debug 5 t)))

My assumption is that these numbers must be decreased by 1, because the
number of frames to be skipped (these frames belong to the code run by
`implement-debug-on-entry') is 3 now instead of 4.

The bug doesn't appear in the Emacs 23.4.1 I have installed here.  To
find the difference, I changed the

  (backtrace-debug 4 t)

line to

  (backtrace-debug 0 t)

in the version of debug.el both in 24 and in 23.  This lets me see all
active frames when the debugger has been entered.  It is important to
use always a compiled version of debug, because uncompiled code would
cause another number of frames!

I follow the recipe above and call (a).  I get in 24:

Debugger entered--returning value: t
  backtrace-debug(0 t)
  debug(debug)
  implement-debug-on-entry()
  b()
  a()
  eval((a))
  icicle-pp-eval-expression((a) nil)
  call-interactively(icicle-pp-eval-expression)
  my-eval-M-:()
  call-interactively(my-eval-M-: nil nil)

whereby in Emacs 23, it looks like that:

Debugger entered--returning value: t
  backtrace-debug(0 t)
  byte-code("\306.      
@\307=\203!.\310\311\312\"\210\313\314!\211.A@)\242\315=\203!.\310\316\312\"\210\317
!\210\320 \210\321 
!\210\f\203d.\322ed\".V\203W.eb\210\323.\245y\210`..db\210\323.\245.Zy\210..`|\210)\324c\210eb\210\325\326\327
 \"\210\330\306!\210\325\331!\210\332\312....\325\331!\210\212\333 
\210+\332\207" [unread-command-char debugger-args x debugger-buffer 
noninteractive debugger-batch-max-lines -1 debug backtrace-debug 0 t 
backtrace-frame 4 lambda 5 pop-to-buffer debugger-mode debugger-setup-buffer 
count-lines 2 "...\n" message "%s" buffer-string kill-emacs "" nil 
recursive-edit middlestart buffer-read-only standard-output] 4)
  debug(debug)
  implement-debug-on-entry()
  b()
  a()
  eval((a))
  eval-expression((a) nil)
  call-interactively(eval-expression nil nil)

Indeed, one additional frame below the b() call.

Now, something interesting:  I byte compile the modified 23 version of
debug.el with emacs 24 and load the result in 23.  Then, calling (a) in
23 also looks like this:

Debugger entered--returning value: t
  backtrace-debug(0 t)
  debug(debug)
  implement-debug-on-entry()
  b()
  a()
  eval((a))
  eval-expression((a) nil)
  call-interactively(eval-expression nil nil)

Conclusion: the difference in the number of frames to skip is not caused
by a change in debug.el, but due to the different kind of code the
compiler produces.

I don't know much about the byte compiler and how it works.  Stefan: is
it, in your opinion, right to decrease the frame numbers in `debug'?  Is
there a way to make the code more reliable (more independent from the
byte compiler?) to avoid this problem in the future?


Thanks, and regards,

Michael.