[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argume
From: |
Drew Adams |
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.
- bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Drew Adams, 2010/11/26
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Eli Zaretskii, 2010/11/27
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Drew Adams, 2010/11/27
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Eli Zaretskii, 2010/11/27
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil),
Drew Adams <=
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Eli Zaretskii, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), martin rudalics, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Eli Zaretskii, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), martin rudalics, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Drew Adams, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Drew Adams, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Eli Zaretskii, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Drew Adams, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Eli Zaretskii, 2010/11/28
- bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil), Drew Adams, 2010/11/28