Package: emacs;
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Fri, 3 Oct 2008 17:30:02 UTC
Severity: normal
Tags: moreinfo
Merged with 670
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: "Drew Adams" <drew.adams <at> oracle.com> To: "'Eli Zaretskii'" <eliz <at> gnu.org> Cc: 1077 <at> debbugs.gnu.org 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
> 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.