From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lute Kamstra Newsgroups: gmane.emacs.devel Subject: Lisp debugger problems. Date: Thu, 24 Feb 2005 01:16:48 +0100 Message-ID: <878y5eke1b.fsf@xs4all.nl> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1109205457 30896 80.91.229.2 (24 Feb 2005 00:37:37 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 24 Feb 2005 00:37:37 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 24 01:37:37 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1D470U-0002CH-5Q for ged-emacs-devel@m.gmane.org; Thu, 24 Feb 2005 01:37:30 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D47Hv-0001Br-UR for ged-emacs-devel@m.gmane.org; Wed, 23 Feb 2005 19:55:32 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D47GG-0000Xu-NZ for emacs-devel@gnu.org; Wed, 23 Feb 2005 19:53:49 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D47G9-0000Uj-6S for emacs-devel@gnu.org; Wed, 23 Feb 2005 19:53:41 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D47G8-0000Qo-Sf for emacs-devel@gnu.org; Wed, 23 Feb 2005 19:53:40 -0500 Original-Received: from [194.109.24.34] (helo=smtp-vbr14.xs4all.nl) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D46gT-0001qD-Gl for emacs-devel@gnu.org; Wed, 23 Feb 2005 19:16:49 -0500 Original-Received: from pijl (a80-127-67-124.adsl.xs4all.nl [80.127.67.124]) by smtp-vbr14.xs4all.nl (8.12.11/8.12.11) with ESMTP id j1O0GmsP040144 for ; Thu, 24 Feb 2005 01:16:48 +0100 (CET) (envelope-from Lute.Kamstra@xs4all.nl) Original-Received: from lute by pijl with local (Exim 3.36 #1 (Debian)) id 1D46gS-0000xc-00 for ; Thu, 24 Feb 2005 01:16:48 +0100 Original-To: emacs-devel@gnu.org User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) Original-Lines: 92 X-Virus-Scanned: by XS4ALL Virus Scanner X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org X-MailScanner-To: ged-emacs-devel@m.gmane.org Xref: main.gmane.org gmane.emacs.devel:33770 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:33770 I'm checking the documentation of the lisp debugger (lispref/debugging.texi) and I ran into some problems. The first problem is with canceling the effect of debug-on-error by redefining a function. The lisp manual currently explains that I can use debug-on-entry to let a function enter the debugger and that using cancel-debug-on-entry or redefining the function cancels this effect. However, in some cases, the debugger can cancel the effect of redefining a function behind your back. Here is an example: (defun fun1 () 1) => fun1 (defun fun2 () t) => fun2 (debug-on-entry 'fun1) => fun1 (symbol-function 'fun1) => (lambda nil (debug (quote debug)) 1) fun1 is now set up to break on entry. (defun fun1 () 2) => fun1 (symbol-function 'fun1) => (lambda nil 2) Redefining fun1 cancelled the effect of debug-on-entry. (debug-on-entry 'fun2) => fun2 (symbol-function 'fun1) => (lambda nil (debug (quote debug)) 2) debug-on-entry on fun2, caused fun1 to be set up to break on entry as well. This is confusing. The root of this problem appears to be the use of debug-function-list. The debugger uses this variable to store a list of functions that are set to break on entry. debug-on-entry adds its argument to this list and cancel-debug-on-entry removes its argument from this list. Redefining a function does not modify this list, however. So the debug-function-list might not reflect the actual situation. I think that it's probably a good idea to add a function that checks debug-function-list and removes any function that is not set to break on entry and to call this function before debug-function-list is used. I have some problems understanding the code in lisp/emacs-lisp/debug.el, however. There is this function debugger-reenable that sets all functions in debug-function-list to break on entry. I assume that this function is meant to work together with debugger-jump which cancels the effect of debug-on-entry for all functions in debug-function-list but does not modify the list itself. So the next time debug is called (scheduled by debugger-jump by means of debug-frame), it calls debugger-reenable to make the cancellation effect of debugger-jump temporary. This make sense to me. What I don't understand in why debug-on-entry and cancel-debug-on-entry call debugger-reenable as well (thus causing the strange behavior in the example above). What am I missing? A second problem I encountered is with debugger-jump. It is currently not documented in the lisp manual so I'm trying to figure out what it does. From what I understand, it is intended to work just like debugger-continue with the difference that it temporarily cancels the effect of debug-on-entry for all functions. This is not the case however: (defun funa () 1) (debug-on-entry 'funa) (funa) enters the debugger: ------ Buffer: *Backtrace* ------ Debugger entered--entering a function: * funa() eval((funa)) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp) ------ Buffer: *Backtrace* ------ When I now press j to invoke debugger-jump, I see: ------ Buffer: *Backtrace* ------ Debugger entered--returning value: nil funa() eval((funa)) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp) ------ Buffer: *Backtrace* ------ I would expect a return value of 1. When I press c instead of j (to invoke debugger-continue), the debugger does give a return value of 1. Is this a bug? Lute.