--- Begin Message ---
|
Subject: |
24.3.50; emacs_backtrace.txt |
|
Date: |
Tue, 26 Mar 2013 16:33:22 -0700 |
Still crashing, with a newer build from the other backtraces I sent earlier
today.
Backtrace:
0x01159634
0x011596A6
0x01001459
0x01021A98
0x0114F494
0x7E418730
0x7E418812
0x7E4189C9
0x7E418A0C
0x0114DC6F
0x0114DF0E
0x7C80B725
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-03-23 on VBOX
Bzr revision: 112115 address@hidden
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/emacs/libs/libXpm-3.5.10/include -IC:/emacs/libs/libXpm-3.5.10/src
-IC:/emacs/libs/libpng-dev_1.4.3-1_win32/include
-IC:/emacs/libs/zlib-dev_1.2.5-2_win32/include
-IC:/emacs/libs/giflib-4.1.4-1-lib/include
-IC:/emacs/libs/jpeg-6b-4-lib/include
-IC:/emacs/libs/tiff-3.8.2-1-lib/include
-IC:/emacs/libs/libxml2-2.7.8-w32-bin/include/libxml2
-IC:/emacs/libs/gnutls-3.1.10-w32/include
-IC:/emacs/libs/libiconv-1.14-2-mingw32-dev/include'
--- End Message ---
--- Begin Message ---
|
Subject: |
Re: bug#14062: 24.3.50; emacs_backtrace.txt |
|
Date: |
Sat, 04 May 2013 13:27:48 +0300 |
> Date: Mon, 22 Apr 2013 21:05:53 +0300
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden
>
> > From: Juanma Barranquero <address@hidden>
> > Date: Mon, 22 Apr 2013 18:12:13 +0200
> > Cc: Eli Zaretskii <address@hidden>, martin rudalics <address@hidden>,
> > address@hidden
> >
> > ??
> > ??: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.
--- End Message ---