bug#11291: 24.1.50; crash from `read-from-minibuffer'

bug#11291: 24.1.50; crash from `read-from-minibuffer'

[Drew Adams]

Dunno whether this will help.  No, I cannot keep the session open until
I hear back from you.  I opened gdb and hit `bt' to get a backtrace.  I tried to
print the selected_window at the point where it seemed like perhaps it was
trying to get the buffer of a window (?).

Probably the info here won't tell you enough, but I don't know what commands to
use to get you the info you might need.
 
Anyway, here is the backtrace from gdb.  The Lisp function
`old-read-from-minibuffer' is just a `defalias' at startup to
the built-in C function `read-from-minibuffer', as follows:
 
(unless (fboundp 'old-read-from-minibuffer)
  (defalias 'old-read-from-minibuffer (symbol-function 'read-from-minibuffer)))
 

$ ./gdb -p 768
GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 768
[New Thread 768.0x1794]
[New Thread 768.0x170]
[New Thread 768.0xbc4]
Reading symbols from C:\Emacs-24-2012-04-19\bin\emacs.exe...done.
[Switching to Thread 768.0xbc4]
Warning: c:\drews-lisp-20\bin/../lwlib: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from
terminal]
Environment variable "DISPLAY" not defined.
TERM = cygwin
.gdbinit:1328: Error in sourced command file:
No symbol "Vsystem_type" in current context.
(gdb) c
Continuing.
 
Program received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 768.0x170]
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
#1  0x0114efb6 in w32_abort () at w32fns.c:7210
#2  0x01041d97 in die (msg=0x1543718 "assertion failed: BUFFERP
(((w))->buffer)",
    file=0x1542569 "w32fns.c", line=3009) at alloc.c:6378
#3  0x01145e22 in w32_wnd_proc (hwnd=0x1d061a, msg=269, wParam=0, lParam=0)
    at w32fns.c:3009
#4  0x7e418734 in USER32!GetDC () from C:\WINDOWS\system32\user32.dll
#5  0x001d061a in ?? ()
#6  0x0000010d in ?? ()
#7  0x00000000 in ?? ()
 
Lisp Backtrace:
"old-read-from-minibuffer" (0x83e2b4)
"read-from-minibuffer" (0x83e5b4)
"icicle-lisp-vanilla-completing-read" (0x83e8b4)
"byte-code" (0x83eb24)
"completing-read" (0x83eee0)
"let" (0x83f1bc)
"eval" (0x83f314)
"pp-eval-expression" (0x83f604)
"pp-eval-last-sexp" (0x83f944)
"call-interactively" (0x83fb74)
 (gdb) frame 3
#3  0x01145e22 in w32_wnd_proc (hwnd=0x1d061a, msg=269, wParam=0, lParam=0)
    at w32fns.c:3009
3009    w32fns.c: No such file or directory.
        in w32fns.c
(gdb) p selected_window
$2 = 65412101
(gdb) xtype
Lisp_Vectorlike
There is no member named size.
(gdb)

In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-04-19 on MARVIN
Bzr revision: 107968 monnier@iro.umontreal.ca-20120419220225-gijdcbfxuiqy5dhb
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (4.6) --no-opt --enable-checking --cflags
 -ID:/devel/emacs/libs/libXpm-3.5.8/include
 -ID:/devel/emacs/libs/libXpm-3.5.8/src
 -ID:/devel/emacs/libs/libpng-dev_1.4.3-1/include
 -ID:/devel/emacs/libs/zlib-dev_1.2.5-2/include
 -ID:/devel/emacs/libs/giflib-4.1.4-1/include
 -ID:/devel/emacs/libs/jpeg-6b-4/include
 -ID:/devel/emacs/libs/tiff-3.8.2-1/include
 -ID:/devel/emacs/libs/gnutls-3.0.9/include
 -ID:/devel/emacs/libs/libiconv-1.13.1-1-dev/include
 -ID:/devel/emacs/libs/libxml2-2.7.8/include/libxml2'
 

bug#11291: 24.1.50; crash from `read-from-minibuffer'

[Drew Adams]

I seem to be seeing this (or a similar) crash a lot, since I changed today to
the Windows binary built on 4/19 instead of the last pretest.  Dunno whether
this helps, and take it with a grain of salt since I haven't yet used the build
much.

bug#11291: 24.1.50; crash from `read-from-minibuffer'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 20 Apr 2012 18:04:58 -0700
> 
> I seem to be seeing this (or a similar) crash a lot, since I changed today to
> the Windows binary built on 4/19 instead of the last pretest.

Probably because the pretest was built in a way that disables
assertions.  IOW, the pretest binary simply does not check these
conditions, so it doesn't abort when they are violated.

bug#11291: 24.1.50; crash from `read-from-minibuffer'

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Fri, 20 Apr 2012 17:57:57 -0700
> 
> Dunno whether this will help.  No, I cannot keep the session open until
> I hear back from you.

Why not?  If you explain why you cannot do that, perhaps we could come
up with some suggestions that would let you work around whatever
difficulties you have that force you to close the crashed session.

It is 100% impossible to fix a bug that is not reproducible if you
cannot look around in the debugger and tell us details we need to
know.  Please try to find a way to leave the session open for a while.

> I opened gdb and hit `bt' to get a backtrace.

This backtrace makes no sense to me.  It says that Emacs crashed in
w32_wnd_proc, a function that runs in a separate thread used to get
Windows messages that Emacs needs to process.  These messages include
(but are not limited to) keyboard input, which seems to be compatible
with the Lisp backtrace.  However, the exact place where it crashed,
i.e. line 3009 of w32fns.c, is part of processing the
WM_IME_STARTCOMPOSITION message, which is related to the Windows Input
Method Manager, something I'm quite sure you don't use and in fact
most probably don't have installed, let alone activated.

Moreover, unless I'm missing something, I cannot figure out how any of
the code lines around 3009 could trigger the assertion of BUFFERP (w),
because the macros that could do that seem to check this condition in
advance.

Christoph, were the 4/19 binaries compiled with optimizations, per
chance?  That could explain why the backtrace makes no sense.

bug#11291: 24.1.50; crash from `read-from-minibuffer'

[Glenn Morris]

Eli Zaretskii wrote:

> It is 100% impossible to fix a bug that is not reproducible if you
> cannot look around in the debugger and tell us details we need to know.