bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 22 Apr 2013 21:05:53 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14062@debbugs.gnu.org
> 
> > From: Juanma Barranquero <lekktu@gmail.com>
> > Date: Mon, 22 Apr 2013 18:12:13 +0200
> > Cc: Eli Zaretskii <eliz@gnu.org>, martin rudalics <rudalics@gmx.at>, 14062@debbugs.gnu.org
> > 
> > ??
> > ??:0
> > w32_backtrace at w32fns.c:7687
> > emacs_abort at w32fns.c:7719
> > terminate_due_to_signal at emacs.c:343
> > die at alloc.c:6522
> > w32_wnd_proc at w32fns.c:3127
> 
> Thanks!  the trap worked again!  This is here:
> 
>   #ifdef ENABLE_CHECKING
> 	    /* Temporary code to catch crashes in computing form.rcArea.top.  */
> 	    eassert (FRAMEP (w->frame));
> 	    eassert (BUFFERP (w->contents));  <<<<<<<<<<<<<<<<<<<<<<<<
> 
> So the cause for the assertion violation is now crystal clear, and I
> will commit a work-around soon.  (I still don't understand how such a
> window ended up here, and why didn't the BUFFERP test in
> WINDOW_WANTS_HEADER_LINE_P catch the problem before XBUFFER aborted.)

After staring at the code again, I might be able to explain to myself
why the BUFFERP test was not enough.  I rearranged the tests in the
WINDOW_WANTS_HEADER_LINE_P macro so that hopefully this will not
happen again.

I've also removed the temporary code in w32fns.c used to track these
violations at fine resolution.  The changes are committed as trunk
revision 112447.

I also think I understand now how come Emacs gets the
WM_IME_STARTCOMPOSITION message: we send it to ourselves in
w32_draw_window_cursor, i.e. every time we are about to draw the
cursor.

I'm closing the bug.  Feel free to reopen if we get aborts around line
3186 in w32fns.c.