bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Drew Adams]

I don't have more info about this.  I did only this:
emacs.exe -nw -Q --debug-init

Then I did C-x d to visit a directory.  Then C-x 5 2.  If you try that
you'll probably get the same crash.  I get it systematically.


In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600)
 of 2011-04-25 on 3249CTO
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.5) --no-opt --cflags
-Ic:/imagesupport/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Dired by name

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<menu-bar> <help-menu> <menu-bar> <help-menu> M-x r 
e p o r t <tab> <return>

Recent messages:
("C:\\Emacs-24-2011-04-25-lex\\bin\\emacs.exe" "C:\\drews-lisp-20")
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail format-spec rfc822 mml easymenu
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045
ietf-drums mailabbrev mail-utils gmm-utils mailheader emacsbug url-util
url-parse auth-source eieio byte-opt bytecomp byte-compile cconv
macroexp assoc gnus-util time-date password-cache url-vars mm-util
mail-prsvr dired regexp-opt tooltip ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset
image fringe lisp-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer button faces cus-face files text-properties overlay
md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Sat, 30 Apr 2011 09:04:18 -0700
> 
> I don't have more info about this.  I did only this:
> emacs.exe -nw -Q --debug-init
> 
> Then I did C-x d to visit a directory.  Then C-x 5 2.  If you try that
> you'll probably get the same crash.  I get it systematically.

I cannot reproduce this with today's build.  Sorry.

Does it matter which directory you visit with "C-x d"?

Btw, why do you use --debug-init if you also use -Q?

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Drew Adams]

> > I don't have more info about this.  I did only this:
> > emacs.exe -nw -Q --debug-init
> > 
> > Then I did C-x d to visit a directory.  Then C-x 5 2.  If 
> > you try that you'll probably get the same crash.  I get it systematically.
> 
> I cannot reproduce this with today's build.  Sorry.

OK, too bad. I was hoping you would be able to.
If I get some time later I'll try to do the gdb thing.

> Does it matter which directory you visit with "C-x d"?

Dunno. Actually, I did this:
emacs.exe -nw -Q --debug-init "C:\my-dir"
Then I immediately did C-x 5 2.

(Yes, I should have said that to begin with.)

> Btw, why do you use --debug-init if you also use -Q?

Dunno; just habit, I guess.

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Juanma Barranquero]

On Sat, Apr 30, 2011 at 19:49, Drew Adams <drew.adams@oracle.com> wrote:

> Dunno. Actually, I did this:
> emacs.exe -nw -Q --debug-init "C:\my-dir"
> Then I immediately did C-x 5 2.

Reproducible. "--debug-init" is unnecessary.

Breakpoint 1, w32_abort () at w32fns.c:7184
7184      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:7184
#1  0x0108ff2d in adjust_frame_glyphs_for_frame_redisplay
(f=0x332e400) at dispnew.c:2156
#2  0x0108f7c9 in adjust_frame_glyphs (f=0x332e400) at dispnew.c:1953
#3  0x0108f41d in adjust_glyphs (f=0x332e400) at dispnew.c:1896
#4  0x0126e345 in Fmake_terminal_frame (parms=52115482) at frame.c:727
#5  0x01036f1c in Ffuncall (nargs=2, args=0x88f1b0) at eval.c:3036
#6  0x01123f08 in exec_byte_code (bytestr=20196561, vector=20196677,
maxdepth=16, args_template=52115482, nargs=0, args=0x0) at
bytecode.c:783
#7  0x01037e85 in funcall_lambda (fun=20196533, nargs=1,
arg_vector=0x88f3f4) at eval.c:3269
#8  0x01037323 in Ffuncall (nargs=2, args=0x88f3f0) at eval.c:3085
#9  0x01123f08 in exec_byte_code (bytestr=20584809, vector=20584973,
maxdepth=20, args_template=52115482, nargs=0, args=0x0) at
bytecode.c:783
#10 0x01037e85 in funcall_lambda (fun=20584781, nargs=0,
arg_vector=0x88f648) at eval.c:3269
#11 0x01037323 in Ffuncall (nargs=1, args=0x88f644) at eval.c:3085
#12 0x01123f08 in exec_byte_code (bytestr=20584569, vector=20584613,
maxdepth=8, args_template=52115482, nargs=0, args=0x0) at
bytecode.c:783
#13 0x01037e85 in funcall_lambda (fun=20584541, nargs=0,
arg_vector=0x88f8c4) at eval.c:3269
#14 0x01037323 in Ffuncall (nargs=1, args=0x88f8c0) at eval.c:3085
#15 0x0103637a in apply1 (fn=56794050, arg=52115482) at eval.c:2771
#16 0x011210ec in Fcall_interactively (function=56794050,
record_flag=52115482, keys=52136709) at callint.c:379
#17 0x01036ffc in Ffuncall (nargs=4, args=0x88fb30) at eval.c:3043
#18 0x01036486 in call3 (fn=52280442, arg1=56794050, arg2=52115482,
arg3=52115482) at eval.c:2835
#19 0x0101fdea in Fcommand_execute (cmd=56794050,
record_flag=52115482, keys=52115482, special=52115482) at
keyboard.c:10263
#20 0x01006270 in command_loop_1 () at keyboard.c:1561
#21 0x01032d83 in internal_condition_case (bfun=0x100540b
<command_loop_1>, handlers=52169210, hfun=0x1004c35 <cmd_error>) at
eval.c:1507
#22 0x01005071 in command_loop_2 (ignore=52115482) at keyboard.c:1156
#23 0x01032743 in internal_catch (tag=52167234, func=0x100504e
<command_loop_2>, arg=52115482) at eval.c:1261
#24 0x01005029 in command_loop () at keyboard.c:1135
#25 0x010045f3 in recursive_edit_1 () at keyboard.c:756
#26 0x01004915 in Frecursive_edit () at keyboard.c:820
#27 0x0100279c in main (argc=4, argv=0x331a8) at emacs.c:1685
Lisp Backtrace:
"make-terminal-frame" (0x88f1b4)
"tty-create-frame-with-faces" (0x88f3f4)
"make-frame" (0x88f648)
"make-frame-command" (0x88f8c4)
"call-interactively" (0x88fb34)
(gdb) frame 1
#1  0x0108ff2d in adjust_frame_glyphs_for_frame_redisplay
(f=0x332e400) at dispnew.c:2156
2156          xassert (matrix_dim.width == FRAME_COLS (f)
(gdb) p matrix_dim.width
$1 = 10
(gdb) p f->text_cols
$2 = 10
(gdb) p matrix_dim.height
$3 = 11
(gdb) p f->text_lines
$4 = 10

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sat, 30 Apr 2011 20:21:51 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>, 8596@debbugs.gnu.org
> 
> On Sat, Apr 30, 2011 at 19:49, Drew Adams <drew.adams@oracle.com> wrote:
> 
> > Dunno. Actually, I did this:
> > emacs.exe -nw -Q --debug-init "C:\my-dir"
> > Then I immediately did C-x 5 2.
> 
> Reproducible. "--debug-init" is unnecessary.

Actually, even "C:\my-dir" is unnecessary.  The reason I couldn't at
first reproduce it is that I tried that in a normal optimized build.
But the xassert that aborts is only compiled under -DENABLE_CHECKING.

I think this happens because w32 lacks a proper implementation of
get_tty_size.  So the new frame starts with bogus dimensions 10x10,
and then the height gets incremented by 1 due to the menu bar, which
triggers the abort.

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Juanma Barranquero]

On Sat, Apr 30, 2011 at 22:32, Eli Zaretskii <eliz@gnu.org> wrote:

> I think this happens because w32 lacks a proper implementation of
> get_tty_size.

That's not hard to fix, is it?

But, I cannot find the oldest Windows release supporting
GetConsoleScreenBufferInfo. Most online references do not go farther
than the oldest supported release, Windows 2K.

    Juanma


=== modified file 'src/sysdep.c'
--- src/sysdep.c	2011-04-26 06:17:52 +0000
+++ src/sysdep.c	2011-04-30 21:23:28 +0000
@@ -1138,6 +1138,16 @@
     }

 #else
+#ifdef WINDOWSNT
+  CONSOLE_SCREEN_BUFFER_INFO info;
+  if (GetConsoleScreenBufferInfo (GetStdHandle (STD_OUTPUT_HANDLE), &info))
+    {
+      *widthp = info.srWindow.Right - info.srWindow.Left + 1;
+      *heightp = info.srWindow.Bottom - info.srWindow.Top + 1;
+    }
+  else
+    * widthp = *heightp = 0;
+#else
 #ifdef MSDOS
   *widthp = ScreenCols ();
   *heightp = ScreenRows ();
@@ -1145,6 +1155,7 @@
   *widthp = 0;
   *heightp = 0;
 #endif
+#endif /* not WINDOWSNT */
 #endif /* not SunOS-style */
 #endif /* not BSD-style */
 }

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Juanma Barranquero]

On Sat, Apr 30, 2011 at 23:30, Juanma Barranquero <lekktu@gmail.com> wrote:

> But, I cannot find the oldest Windows release supporting
> GetConsoleScreenBufferInfo. Most online references do not go farther
> than the oldest supported release, Windows 2K.

According to this "reference"
(http://winapi.freetechsecrets.com/win32/WIN32GetConsoleScreenBufferInfo.htm)
it existed in W95 and NT 3.1.

But, as for the bug... why does not happen on emacs-23?  There,
matrix_dim is 10x10, not 10x11 as in the trunk.

    Juanma

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 1 May 2011 00:14:47 +0200
> Cc: drew.adams@oracle.com, 8596@debbugs.gnu.org
> 
> On Sat, Apr 30, 2011 at 23:30, Juanma Barranquero <lekktu@gmail.com> wrote:
> 
> > But, I cannot find the oldest Windows release supporting
> > GetConsoleScreenBufferInfo. Most online references do not go farther
> > than the oldest supported release, Windows 2K.
> 
> According to this "reference"
> (http://winapi.freetechsecrets.com/win32/WIN32GetConsoleScreenBufferInfo.htm)
> it existed in W95 and NT 3.1.

Yes, it's available in all versions of Windows.

> But, as for the bug... why does not happen on emacs-23?  There,
> matrix_dim is 10x10, not 10x11 as in the trunk.

Are you saying that before this line:

  /* Add in menu bar lines, if any.  */
  matrix_dim.height += top_window_y;

matrix_dim.height is 9?  Or maybe top_window_y is zero?

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Juanma Barranquero]

On Sun, May 1, 2011 at 05:03, Eli Zaretskii <eliz@gnu.org> wrote:

> Are you saying that before this line:
>
>  /* Add in menu bar lines, if any.  */
>  matrix_dim.height += top_window_y;
>
> matrix_dim.height is 9?  Or maybe top_window_y is zero?

(gdb) n
2341      matrix_dim.height += top_window_y;
(gdb) p matrix_dim
$8 = {
  width = 10,
  height = 10
}
(gdb) p top_window_y
$9 = 0
(gdb)

    Juanma

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 1 May 2011 17:49:01 +0200
> Cc: drew.adams@oracle.com, 8596@debbugs.gnu.org
> 
> (gdb) p top_window_y
> $9 = 0

So FRAME_MENU_BAR_LINES returns zero in Emacs 23 for terminal frames,
is that right?  (Sorry, I have no Emacs 23 compiled for debugging to
see that myself.)

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Juanma Barranquero]

On Sun, May 1, 2011 at 18:47, Eli Zaretskii <eliz@gnu.org> wrote:

> So FRAME_MENU_BAR_LINES returns zero in Emacs 23 for terminal frames,
> is that right?

Yes.

> (Sorry, I have no Emacs 23 compiled for debugging to
> see that myself.)

No problem.

Do I install the get_tty_size change, or are you digging deeper into
the bug's causes?

    Juanma

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Sun, 1 May 2011 22:15:59 +0200
> Cc: drew.adams@oracle.com, 8596@debbugs.gnu.org
> 
> Do I install the get_tty_size change, or are you digging deeper into
> the bug's causes?

Go ahead and install it, it's a good change anyway.  And if it
prevents the crash, you can close the bug as well.  I think I know why
FRAME_MENU_BAR_LINES was changed in Emacs 24.

Thanks.

bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q

[Juanma Barranquero]

On Mon, May 2, 2011 at 05:09, Eli Zaretskii <eliz@gnu.org> wrote:

> Go ahead and install it, it's a good change anyway.  And if it
> prevents the crash, you can close the bug as well.

Done.