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

[Eli Zaretskii <eliz@gnu.org>]

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