bug#8562: Emacs 23.1 and later don't work in windows 98

[Eli Zaretskii]

> Date: Wed, 25 May 2011 04:01:22 +0200
> From: oslsachem <oslsachem@gmail.com>
> Cc: 8562@debbugs.gnu.org
> 
> > If total_lines and total_cols get the right values here, then please
> > set a watchpoint on these fields, or step through the code between the
> > above and where it aborts, and see where they are reset to zero.
> 
> http://www.speedyshare.com/files/28632428/Emacs-23.3GDBframe1.txt

This shows that my guess was wrong:

  (gdb) frame 1
  #1  0x01050284 in window_box_height (w=0x37f3c00) at xdisp.c:1104
  1104           xassert (height >= 0);
  (gdb) p height
  $1 = -482614272
  (gdb) p w->total_lines
  $2 = 32
  (gdb) p w->total_cols
  $3 = 40

The problem is not the window dimensions, which look fine, but
something else.  `height' is computed like this:

  int height = WINDOW_TOTAL_HEIGHT (w);

WINDOW_TOTAL_HEIGHT is defined like this:

  #define WINDOW_TOTAL_HEIGHT(W) \
    (WINDOW_TOTAL_LINES (W) * WINDOW_FRAME_LINE_HEIGHT (W))
  #define WINDOW_TOTAL_LINES(W) \
    (XFASTINT ((W)->total_lines))
  #define WINDOW_FRAME_LINE_HEIGHT(W) \
    (FRAME_LINE_HEIGHT (WINDOW_XFRAME ((W))))
  #define FRAME_LINE_HEIGHT(F) ((F)->line_height)

So the problem must be that FRAME_LINE_HEIGHT (WINDOW_XFRAME ((W)))
returns a negative value.  Can you verify that?  In frame #1, please
type "print f->line_height" and see if the value is negative or maybe a
large positive (which causes the multiplication in WINDOW_TOTAL_HEIGHT
to overflow).

If the value of f->line_height is indeed bogus, please put a
breakpoint in x_new_font, run Emacs again, and when the breakpoint
breaks, step through that function and see why it doesn't put a valid
value into this field.  This should happen on line 5280 of w32term.c:

  FRAME_LINE_HEIGHT (f) = font->height;

If this indeed assigns a bogus value, please show the contents of the
`font' structure ("print *font" at GDB prompt).

Thanks.