From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#10025: 24.0.91; Lisp debugger not working right Date: Tue, 20 Nov 2012 03:32:17 +0100 Message-ID: <87lidxc8cu.fsf@web.de> References: <20158.31264.608000.429932@gargle.gargle.HOWL> <87txsn4pjk.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1353378720 25401 80.91.229.3 (20 Nov 2012 02:32:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 20 Nov 2012 02:32:00 +0000 (UTC) To: 10025@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Nov 20 03:32:11 2012 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TaddD-00036Y-1a for geb-bug-gnu-emacs@m.gmane.org; Tue, 20 Nov 2012 03:32:11 +0100 Original-Received: from localhost ([::1]:60105 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tadd2-0007fd-Kq for geb-bug-gnu-emacs@m.gmane.org; Mon, 19 Nov 2012 21:32:00 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:55127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tadd0-0007fV-1h for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2012 21:31:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tadcy-0007e9-Qf for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2012 21:31:57 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:45771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tadcy-0007e4-ND for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2012 21:31:56 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1Tade2-0001cs-Qw for bug-gnu-emacs@gnu.org; Mon, 19 Nov 2012 21:33:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 20 Nov 2012 02:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 10025 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 10025-submit@debbugs.gnu.org id=B10025.13533787786240 (code B ref 10025); Tue, 20 Nov 2012 02:33:02 +0000 Original-Received: (at 10025) by debbugs.gnu.org; 20 Nov 2012 02:32:58 +0000 Original-Received: from localhost ([127.0.0.1]:56022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Taddx-0001cV-U5 for submit@debbugs.gnu.org; Mon, 19 Nov 2012 21:32:58 -0500 Original-Received: from mout.web.de ([212.227.17.12]:50023) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Taddo-0001cJ-4Z for 10025@debbugs.gnu.org; Mon, 19 Nov 2012 21:32:51 -0500 Original-Received: from drachen.dragon ([89.204.139.79]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0LoHP7-1T3miJ2d0D-00g5Js; Tue, 20 Nov 2012 03:31:39 +0100 In-Reply-To: <87txsn4pjk.fsf@web.de> (Michael Heerdegen's message of "Sun, 18 Nov 2012 03:15:25 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-Provags-ID: V02:K0:hsMDU6zm55Ob4v4JSyAoG+ixZP7xVnEKV2e9OAU+d94 bbrps+ICwl5uyD3RQK5R4QoytHHDCGUV43emGWybDhgndZPd0T oxFFjVWrr7eHhPkglk/S/XekuSCjgVoAOx1VcPDnGMsH6/pt82 MLvBDkA2Z12AYlcdt9yskGaz7xGhU1dtOJg/a6qke/ULiZbtOU FhCHZ+O6eEe0icYBVgggfMby7rEOBPMDvSE3LUcNOY= X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:67191 Archived-At: 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 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.