bug#1077: bug#670: bug#1077: 23.0.60; x-create-frame: (wrong-type-argument number-or-marker-p nil)

["Drew Adams" <drew.adams@oracle.com>]

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