[Top][All Lists]

[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

> > 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))

   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)

   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)

   5067:  if (dpyinfo->reference_count > 0)

   5268:      && XINT (Vhourglass_delay) > 0)
   5271:           && XFLOAT_DATA (Vhourglass_delay) > 0)

   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:

   1075:          while (ptr > approx && isdigit (*ptr))

   1585:  if (FRAME_W32_WINDOW (f) != 0 && f->border_width > 0)

   2360:  if (virt_key < VK_CLEAR || virt_key > VK_DELETE)
   2366:  if (virt_key >= VK_PRIOR && virt_key <= VK_DOWN)

   5067:  if (dpyinfo->reference_count > 0)

   5268:      && XINT (Vhourglass_delay) > 0)
   5271:           && XFLOAT_DATA (Vhourglass_delay) > 0)

   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.

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]