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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8596 in the body.
You can then email your comments to 8596 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
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.


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)

Message #8 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 8596 <at> debbugs.gnu.org
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sat, 30 Apr 2011 19:20:07 +0300

> From: "Drew Adams" <drew.adams <at> 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?

Message #11 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: "Drew Adams" <drew.adams <at> oracle.com>
To: "'Eli Zaretskii'" <eliz <at> gnu.org>
Cc: 8596 <at> debbugs.gnu.org
Subject: RE: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sat, 30 Apr 2011 10:49:44 -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.

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.

Message #14 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 8596 <at> debbugs.gnu.org
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sat, 30 Apr 2011 20:21:51 +0200

On Sat, Apr 30, 2011 at 19:49, Drew Adams <drew.adams <at> 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

Message #17 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sat, 30 Apr 2011 23:32:03 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sat, 30 Apr 2011 20:21:51 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 8596 <at> debbugs.gnu.org
> 
> On Sat, Apr 30, 2011 at 19:49, Drew Adams <drew.adams <at> 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.

Message #20 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sat, 30 Apr 2011 23:30:57 +0200

On Sat, Apr 30, 2011 at 22:32, Eli Zaretskii <eliz <at> 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 */
 }

Message #23 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sun, 1 May 2011 00:14:47 +0200

On Sat, Apr 30, 2011 at 23:30, Juanma Barranquero <lekktu <at> 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

Message #26 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sun, 01 May 2011 06:03:50 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 1 May 2011 00:14:47 +0200
> Cc: drew.adams <at> oracle.com, 8596 <at> debbugs.gnu.org
> 
> On Sat, Apr 30, 2011 at 23:30, Juanma Barranquero <lekktu <at> 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?

Message #29 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sun, 1 May 2011 17:49:01 +0200

On Sun, May 1, 2011 at 05:03, Eli Zaretskii <eliz <at> 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

Message #32 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sun, 01 May 2011 19:47:51 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 1 May 2011 17:49:01 +0200
> Cc: drew.adams <at> oracle.com, 8596 <at> 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.)

Message #35 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Sun, 1 May 2011 22:15:59 +0200

On Sun, May 1, 2011 at 18:47, Eli Zaretskii <eliz <at> 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

Message #38 received at 8596 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8596 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Mon, 02 May 2011 06:09:13 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 1 May 2011 22:15:59 +0200
> Cc: drew.adams <at> oracle.com, 8596 <at> 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.

Message #43 received at 8596-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 8596-done <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#8596: 24.0.50; crash when use C-x 5 2 with emacs -nw -Q
Date: Mon, 2 May 2011 05:58:40 +0200

On Mon, May 2, 2011 at 05:09, Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.