From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.bugs Subject: bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil) Date: Sat, 27 Nov 2010 15:32:49 -0800 Message-ID: References: <003e01c9257c$a385d800$0200a8c0@us.oracle.com> <009701c9263f$9cce7120$0200a8c0@us.oracle.com> <000001c94cc1$e10e9c40$0200a8c0@us.oracle.com> <8F1F8998D60341099C4204B7BDD8AD4F@us.oracle.com> <96BC00F728B94AC18A15EA95B66C5248@us.oracle.com> <83zksv5g7j.fsf@gnu.org> <0A475933984F4CDA855D91C8B7639E3B@us.oracle.com> <83fwum5xzk.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1290901509 26974 80.91.229.12 (27 Nov 2010 23:45:09 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 27 Nov 2010 23:45:09 +0000 (UTC) Cc: 1077@debbugs.gnu.org To: "'Eli Zaretskii'" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Nov 28 00:45:03 2010 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1PMURw-0006Md-0d for geb-bug-gnu-emacs@m.gmane.org; Sun, 28 Nov 2010 00:45:00 +0100 Original-Received: from localhost ([127.0.0.1]:55671 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMURv-00044p-8V for geb-bug-gnu-emacs@m.gmane.org; Sat, 27 Nov 2010 18:44:59 -0500 Original-Received: from [140.186.70.92] (port=43586 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PMURq-00044g-4Q for bug-gnu-emacs@gnu.org; Sat, 27 Nov 2010 18:44:55 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PMURo-0005dl-9x for bug-gnu-emacs@gnu.org; Sat, 27 Nov 2010 18:44:53 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:48541) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PMURo-0005dg-42 for bug-gnu-emacs@gnu.org; Sat, 27 Nov 2010 18:44:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1PMUDU-0003lO-3n; Sat, 27 Nov 2010 18:30:04 -0500 X-Loop: help-debbugs@gnu.org Resent-From: "Drew Adams" Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 27 Nov 2010 23:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 1077 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 1077-submit@debbugs.gnu.org id=B1077.129090054314366 (code B ref 1077); Sat, 27 Nov 2010 23:30:03 +0000 Original-Received: (at 1077) by debbugs.gnu.org; 27 Nov 2010 23:29:03 +0000 Original-Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PMUCU-0003jf-Ap for submit@debbugs.gnu.org; Sat, 27 Nov 2010 18:29:02 -0500 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1PMUCS-0003jM-BB for 1077@debbugs.gnu.org; Sat, 27 Nov 2010 18:29:01 -0500 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id oARNYSLG013971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 27 Nov 2010 23:34:29 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id oARMfmOH021464; Sat, 27 Nov 2010 23:34:27 GMT Original-Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 818627711290900758; Sat, 27 Nov 2010 15:32:38 -0800 Original-Received: from dradamslap1 (/10.159.217.122) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 27 Nov 2010 15:32:37 -0800 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <83fwum5xzk.fsf@gnu.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcuObtTsApmAyYSrT+2wPmemvajqPgABQxJQ X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Sat, 27 Nov 2010 18:30:04 -0500 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) 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: , Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:41944 Archived-At: > Can you install GDB (from the MinGW site) and run Emacs under it? If > you can install GDB, I can send instructions for how to attach it to > Emacs and set a breakpoint where we want it. When the breakpoint > breaks, I can tell how to provide the information needed for > identifying the code which barfs. (Note: there is a reproducible recipe from emacs -Q at the end.) No, I cannot install GDB, but if you point me to a Windows binary for it I will be glad to try that. (I also get multiple crashes per day for the latest dev builds, so... BTW, why does the question asking whether I want to debug with GDB have `Yes' as the default value if I don't have GDB installed? That obliges users to pick up the mouse and click `No' instead of just hitting RET. If you try to answer `Yes' you just get into trouble: That provokes a Microsoft error, letting you send lots of interesting info to MS for `GNU Emacs: The extensible self-documenting text editor'. I.e., `Yes' => `Send Error Report' or `Don't Send'.) > My only other idea is to define a Lisp function `error' (which will > override the primitive) with the same signature as the primitive, > edebug-defun it, and hope that when the problem happens again, you > will be able to see from the Lisp backtrace who throws the error. I did that (though I don't see how/why it would help). I tried this: (defun orig-error (&rest args) (while t (signal 'error (list (apply 'format args))))) (defun error (&rest args) (apply #'orig-error args)) I tried that with each of the following variants: 1. Adding `(debug)' at the beginning of the `error' code. 2. `M-x debug-on-entry RET error RET'. 3. `M-x edebug-defun error RET'. I also tried defining `error' without invoking the original: (defun error (&rest args) (message "ERROR args: %S" args)) In all cases I got the same backtrace that I have posted before. Apparently only Lisp calls to `error' can be so traced, which is what I would expect. > > Do you see _any_ indication there that anyone has tried to > > look at the C code of the function in question, and at its > > changes during the time period in question? > > From the beginning I pointed to that code, but I am the > > only one in thread to speak about it. > > The fact that you are the only one to post there does not mean no one > else tried to figure it out. It just means no one had anything > intelligent to say about it. I guess you're speaking for yourself. So I guess you already checked the possible places in that code where a `>' comparison is made, and could not see how any of them could end up trying to compare a nil arg. I tried that (looking at all occurrences of `>' in w32fns.c). If the problem is really in that file (it isn't necessarily), then maybe one of the following lines is where the error gets raised. (I'm using the C source code from the 23.2 release.) x_to_w32_color (but first has wrong literal number comparison): 1033: if (value < 0.0 || value > 1.0) 1075: while (ptr > approx && isdigit (*ptr)) x_set_border_pixel: 1585: if (FRAME_W32_WINDOW (f) != 0 && f->border_width > 0) x_set_tool_bar_lines (but >=, not >, and guarded by INTEGERP): 1760: if (INTEGERP (value) && XINT (value) >= 0) map_keypad_keys: 2360: if (virt_key < VK_CLEAR || virt_key > VK_DELETE) 2366: if (virt_key >= VK_PRIOR && virt_key <= VK_DOWN) w32_wnd_proc (but comparison against literal nums != 0): 3041: if (wParam > 255 || !lispy_function_keys[wParam]) 3088: while (--add >= 0) 3226: if (w32_num_mouse_buttons > 2) 3290: if (w32_num_mouse_buttons > 2) x-display-visual-class (but literal comparison != 0): 4874: else if (dpyinfo->n_planes * dpyinfo->n_cbits > 8) x-close-connection: 5067: if (dpyinfo->reference_count > 0) hourglass_started: 5268: && XINT (Vhourglass_delay) > 0) 5271: && XFLOAT_DATA (Vhourglass_delay) > 0) x-show-tip: 5867: && XINT (XCAR (Vx_max_tooltip_size)) > 0 5869: && XINT (XCDR (Vx_max_tooltip_size)) > 0) x-file-dialog (but wrong literal comparison): 6139: if (w32_major_version > 4 && w32_major_version < 95) w32-send-sys-command (but wrong literal comparison): 6354: > 32) w32_parse_hot_key (but wrong literal comparisons): 6422: if (vk_code < 0 || vk_code > 255) w32-battery-status (but wrong literal comparison): 6690: if (system_status.BatteryLifePercent > 100) Pruning those that test against other numerical literals than 0, etc., that leaves only these few lines: x_to_w32_color: 1075: while (ptr > approx && isdigit (*ptr)) x_set_border_pixel: 1585: if (FRAME_W32_WINDOW (f) != 0 && f->border_width > 0) map_keypad_keys: 2360: if (virt_key < VK_CLEAR || virt_key > VK_DELETE) 2366: if (virt_key >= VK_PRIOR && virt_key <= VK_DOWN) x-close-connection: 5067: if (dpyinfo->reference_count > 0) hourglass_started: 5268: && XINT (Vhourglass_delay) > 0) 5271: && XFLOAT_DATA (Vhourglass_delay) > 0) x-show-tip: 5867: && XINT (XCAR (Vx_max_tooltip_size)) > 0 5869: && XINT (XCDR (Vx_max_tooltip_size)) > 0) It is possible that the problematic code is in a different file, called by something from this file. But those few locations above might be a good place to start checking. Noticing the last one, I tried enabling tooltip-mode (normally I have it disabled), but the problem remained. ---- If you want a reproducible test case from emacs -Q, here is one. It requires that you download some files, but nothing else special. 1. Download the Icicles files and the following libraries, from Emacs wiki. http://www.emacswiki.org/emacs/hexrgb.el http://www.emacswiki.org/emacs/oneonone.el http://www.emacswiki.org/emacs/icicles.el http://www.emacswiki.org/emacs/icicles-cmd1.el http://www.emacswiki.org/emacs/icicles-cmd2.el http://www.emacswiki.org/emacs/icicles-face.el http://www.emacswiki.org/emacs/icicles-fn.el http://www.emacswiki.org/emacs/icicles-mac.el http://www.emacswiki.org/emacs/icicles-mcmd.el http://www.emacswiki.org/emacs/icicles-mode.el http://www.emacswiki.org/emacs/icicles-opt.el http://www.emacswiki.org/emacs/icicles-var.el 2. Run this command starting in the directory where you put the libraries (e.g. make a Windows shortcut): runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs" 3. M-: (add-to-list 'load-path ".") 4. M-x load-library icicles 5. M-x icy-mode 6. M-: (setq debug-on-error t) 7. C-h f f o r w TAB down down C-M-down That should be enough to bring up the backtrace. #6 is a key step. If you don't do #6, or if after provoking the error you do (setq debug-on-error nil) and then try step #7 again, there is no problem. So it seems that the error in question is one that is ignored (e.g. via condition-case) unless debug-on-error is t. When that is non-nil, Emacs tries to show the *Backtrace* buffer in a new frame. Dunno whether that is the frame creation for *Backtrace* that is problematic. From experimenting, it seems it can be any new frame. FYI: You can use C-g to cancel out of completing. For testing, you might want to kill buffers *Help* and *Backtrace* after one test, before the next (that should also remove their frames). Dunno if that is needed, but sometimes the error does not show up even with `debug-on-error' = nil if the frame it is trying to display (e.g. *Help*, in particular) already exists. (But that is not true for the *Backtrace* frame - even if it exists already the error is raised.) This seems to be a bug about `x-create-frame' - if no new frame is created then no error is raised.