GNU bug report logs -
#14062
24.3.50; emacs_backtrace.txt
Previous Next
Reported by: "Drew Adams" <drew.adams <at> oracle.com>
Date: Tue, 26 Mar 2013 23:36:02 UTC
Severity: normal
Merged with 14205
Found in version 24.3.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14062 in the body.
You can then email your comments to 14062 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Tue, 26 Mar 2013 23:36:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 26 Mar 2013 23:36:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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 eliz <at> gnu.org-20130323093300-rjs0dgskxm9u0ya4
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'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Wed, 27 Mar 2013 07:01:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Tue, 26 Mar 2013 16:33:22 -0700
>
> Still crashing, with a newer build from the other backtraces I sent earlier
> today.
What URL did you download the binaries from?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Wed, 27 Mar 2013 09:48:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 14062 <at> debbugs.gnu.org (full text, mbox):
On Wed, Mar 27, 2013 at 7:57 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: "Drew Adams" <drew.adams <at> oracle.com>
>> Date: Tue, 26 Mar 2013 16:33:22 -0700
>>
>> Still crashing, with a newer build from the other backtraces I sent earlier
>> today.
>
> What URL did you download the binaries from?
From here:
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8
And FWIW:
C:\emacs>addr2line -e c:\emacs\emacs-24.3.50\bin\emacs.exe < c:\emacs\bt.txt
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
??:0
--
Dani Moncayo
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Wed, 27 Mar 2013 12:24:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 27 Mar 2013 10:45:26 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: Drew Adams <drew.adams <at> oracle.com>, 14062 <at> debbugs.gnu.org
>
> On Wed, Mar 27, 2013 at 7:57 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> From: "Drew Adams" <drew.adams <at> oracle.com>
> >> Date: Tue, 26 Mar 2013 16:33:22 -0700
> >>
> >> Still crashing, with a newer build from the other backtraces I sent earlier
> >> today.
> >
> > What URL did you download the binaries from?
>
> >From here:
> https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8
Thanks.
> And FWIW:
>
> C:\emacs>addr2line -e c:\emacs\emacs-24.3.50\bin\emacs.exe < c:\emacs\bt.txt
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
> ??:0
Something is wrong with your addr2line command or with something else,
because I get
??
??:0
w32_backtrace at C:\emacs\trunk\src/w32fns.c:7711
emacs_abort at C:\emacs\trunk\src/w32fns.c:7743
terminate_due_to_signal at C:\emacs\trunk\src/emacs.c:343
die at C:\emacs\trunk\src/alloc.c:6523
w32_wnd_proc at C:\emacs\trunk\src/w32fns.c:3159
??
??:0
??
??:0
??
??:0
??
??:0
w32_msg_pump at C:\emacs\trunk\src/w32fns.c:2489
w32_msg_worker <at> 4 at C:\emacs\trunk\src/w32fns.c:2615
??
??:0
which is unfortunately identical to the one from yesterday. Line 3159
of w32fns.c is here:
case WM_IME_STARTCOMPOSITION:
if (!set_ime_composition_window_fn)
goto dflt;
else
{
COMPOSITIONFORM form;
HIMC context;
struct window *w;
f = x_window_to_frame (dpyinfo, hwnd);
w = XWINDOW (FRAME_SELECTED_WINDOW (f));
form.dwStyle = CFS_RECT;
form.ptCurrentPos.x = w32_system_caret_x;
form.ptCurrentPos.y = w32_system_caret_y;
form.rcArea.left = WINDOW_TEXT_TO_FRAME_PIXEL_X (w, 0);
form.rcArea.top = (WINDOW_TOP_EDGE_Y (w)
+ WINDOW_HEADER_LINE_HEIGHT (w)); <<<<<<<<<<<
form.rcArea.right = (WINDOW_BOX_RIGHT_EDGE_X (w)
- WINDOW_RIGHT_MARGIN_WIDTH (w)
- WINDOW_RIGHT_FRINGE_WIDTH (w));
form.rcArea.bottom = (WINDOW_BOTTOM_EDGE_Y (w)
- WINDOW_MODE_LINE_HEIGHT (w));
context = get_ime_context_fn (hwnd);
which doesn't make sense, because I doubt that Drew invokes Windows
Input Method Editor in any way, shape or form. So how a
WM_IME_STARTCOMPOSITION message got sent to our window procedure is a
mystery to me. And what could be the problem with WINDOW_TOP_EDGE_Y
or with WINDOW_HEADER_LINE_HEIGHT is also not clear.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Wed, 27 Mar 2013 13:40:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> What URL did you download the binaries from?
I think it was this one (from Dani), choosing the one from 2013-03-23:
https://www.dropbox.com/sh/7jr3vbv9tm1zod0/jPuvfrJAe8
When I pick up an Emacs binary I typically get the most recent one I can find,
among those available at that URL and this one (from Juanma):
https://www.dropbox.com/sh/3pgcb3iiy8s9irl/c171Xhsd99
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Wed, 27 Mar 2013 13:42:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> which doesn't make sense, because I doubt that Drew invokes Windows
> Input Method Editor in any way, shape or form.
Not that I know of, at least. No idea what it is.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs.
(Thu, 28 Mar 2013 09:28:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Cc: <14062 <at> debbugs.gnu.org>
> Date: Wed, 27 Mar 2013 06:39:17 -0700
>
> > which doesn't make sense, because I doubt that Drew invokes Windows
> > Input Method Editor in any way, shape or form.
>
> Not that I know of, at least. No idea what it is.
Nevertheless, if one is consistently told they are drunk, one should
go to bed. So I added in trunk revision 112167 some debugging code to
that place which will hopefully help us understand what is going on.
Let's see if the crashes in that code still persist (in which case we
will have higher-accuracy data wrt what exactly causes these assertion
violations) or move to another place in the code (a.k.a. "Heisenbug").
Merged 14062 14205.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Mon, 15 Apr 2013 06:00:02 GMT)
Full text and
rfc822 format available.
Merged 14062 14205.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org.
(Mon, 15 Apr 2013 06:00:03 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 07:40:02 GMT)
Full text and
rfc822 format available.
Message #30 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 28 Mar 2013 11:25:39 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 14062 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
>
> > From: "Drew Adams" <drew.adams <at> oracle.com>
> > Cc: <14062 <at> debbugs.gnu.org>
> > Date: Wed, 27 Mar 2013 06:39:17 -0700
> >
> > > which doesn't make sense, because I doubt that Drew invokes Windows
> > > Input Method Editor in any way, shape or form.
> >
> > Not that I know of, at least. No idea what it is.
>
> Nevertheless, if one is consistently told they are drunk, one should
> go to bed. So I added in trunk revision 112167 some debugging code to
> that place which will hopefully help us understand what is going on.
Which paid off with this report from bug #14205:
> w32_backtrace at w32fns.c:7685
> emacs_abort at w32fns.c:7717
> terminate_due_to_signal at emacs.c:343
> die at alloc.c:6522
> w32_wnd_proc at w32fns.c:3133
The crash seems to be here:
int wwhlp= WINDOW_WANTS_HEADER_LINE_P (w);
Here's the definition of WINDOW_WANTS_HEADER_LINE_P:
#define WINDOW_WANTS_HEADER_LINE_P(W) \
(!MINI_WINDOW_P ((W)) \
&& !(W)->pseudo_window_p \
&& FRAME_WANTS_MODELINE_P (XFRAME (WINDOW_FRAME ((W)))) \
&& BUFFERP (W->contents) \
&& !NILP (BVAR (XBUFFER (W->contents), header_line_format)) \
&& WINDOW_TOTAL_LINES (W) > 1 \
+ !NILP (BVAR (XBUFFER (W->contents), mode_line_format)))
The only parts that can abort here are XFRAME and XBUFFER. But
W->contents is already tested to be a buffer by BUFFERP, which should
be done before XBUFFER, as the expression should be evaluated left to
right, correct? As for XFRAME, this line earlier in the code:
struct frame *wf = WINDOW_XFRAME (w);
already verifies that w's frame is fine.
Nevertheless, the backtrace address indicates that the assertion that
failed was in XBUFFER. Are the instructions allowed to be issued out
of order in this case, perhaps on several processing units in
parallel?
If XBUFFER is indeed the problem, then this means that this snippet,
around line 3115 of w32fns.c:
f = x_window_to_frame (dpyinfo, hwnd);
w = XWINDOW (FRAME_SELECTED_WINDOW (f));
produces a non-leaf window in w. Can a frame's selected window be
non-leaf?
Anyway, I added in trunk revision 112287 some more debugging code to
point out which assertions are violated. Let's see what that gets us.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 11:59:01 GMT)
Full text and
rfc822 format available.
Message #33 received at 14062 <at> debbugs.gnu.org (full text, mbox):
On Mon, Apr 15, 2013 at 9:35 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> Anyway, I added in trunk revision 112287 some more debugging code to
> point out which assertions are violated. Let's see what that gets us.
emacs-20130415-r112292-bin-i386.zip is on its way to my Dropbox.
Should be uploaded in 20 minutes or so.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 12:35:02 GMT)
Full text and
rfc822 format available.
Message #36 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 15 Apr 2013 13:54:03 +0200
> Cc: Drew Adams <drew.adams <at> oracle.com>, 14062 <at> debbugs.gnu.org,
> Dani Moncayo Melgar <dmoncayo <at> gmail.com>
>
> On Mon, Apr 15, 2013 at 9:35 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>
> > Anyway, I added in trunk revision 112287 some more debugging code to
> > point out which assertions are violated. Let's see what that gets us.
>
> emacs-20130415-r112292-bin-i386.zip is on its way to my Dropbox.
> Should be uploaded in 20 minutes or so.
Thank you. The assertion I added is quite rude, but I must be 110%
sure I understand the problem to be able to provide a reliable
solution for it. If BUFFERP is indeed the problem, it should be easy
to fix.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 12:46:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> If XBUFFER is indeed the problem, then this means that this snippet,
> around line 3115 of w32fns.c:
>
> f = x_window_to_frame (dpyinfo, hwnd);
> w = XWINDOW (FRAME_SELECTED_WINDOW (f));
>
> produces a non-leaf window in w. Can a frame's selected window be
> non-leaf?
I could imagine lots of things including dead windows. But it would be
a strange coincidence if it were a non-leaf window. What drives you to
this question?
> Anyway, I added in trunk revision 112287 some more debugging code to
> point out which assertions are violated. Let's see what that gets us.
But you also added some parentheses so now we might not be able to find
out whether it was just due to badly written macros ;-)
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 14:23:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 15 Apr 2013 14:40:46 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, Juanma Barranquero <lekktu <at> gmail.com>,
> 14062 <at> debbugs.gnu.org
>
> > If XBUFFER is indeed the problem, then this means that this snippet,
> > around line 3115 of w32fns.c:
> >
> > f = x_window_to_frame (dpyinfo, hwnd);
> > w = XWINDOW (FRAME_SELECTED_WINDOW (f));
> >
> > produces a non-leaf window in w. Can a frame's selected window be
> > non-leaf?
>
> I could imagine lots of things including dead windows.
Are these "things", including dead windows, allowed to be the selected
window of a frame that gets input messages from Windows, i.e. is at
least visible, if not in the foreground?
> But it would be a strange coincidence if it were a non-leaf window.
> What drives you to this question?
Only a non-leaf window can have its w->contents be something other
than a buffer, right? If BUFFERP(w->contents) returns zero and
XBUFFER hits an assertion violation, what else can this window be
except non-leaf?
> > Anyway, I added in trunk revision 112287 some more debugging code to
> > point out which assertions are violated. Let's see what that gets us.
>
> But you also added some parentheses so now we might not be able to find
> out whether it was just due to badly written macros ;-)
I don't think so. I examined the preprocessed source, and didn't see
any instance of missing parentheses. I added some just so someone who
looks at the macros won't wonder, like I did, whether this could be
the problem.
But even if you are right, and the problem will now disappear, we can
still resolve this bug by simply going back to the original code.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 15:58:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 14062 <at> debbugs.gnu.org (full text, mbox):
>> I could imagine lots of things including dead windows.
>
> Are these "things", including dead windows, allowed to be the selected
> window of a frame that gets input messages from Windows, i.e. is at
> least visible, if not in the foreground?
Hopefully never. Non-leaf and deleted windows are only used by the
window management and the redisplay code (the latter could also employ a
simple list of live windows instead). And deleted windows are only
allowed in saved window configurations.
Conceptually, the selected window must be always a leaf window. During
a deletion this invariant might get temporarily violated until another
leaf window has been selected. Maybe that's what we are hitting here.
An internal window is a priori never selected.
>> But it would be a strange coincidence if it were a non-leaf window.
>> What drives you to this question?
>
> Only a non-leaf window can have its w->contents be something other
> than a buffer, right? If BUFFERP(w->contents) returns zero
... for an internal window w->contents _must_ be another window, only
for deleted windows this can be nil (but Dmitry would have to verify
this, I didn't look at his last changes yet) ...
> and
> XBUFFER hits an assertion violation, what else can this window be
> except non-leaf?
A window with an uninitialized contents field. Such windows exist from
the moment they are allocated by make_window until they either get a
child or a buffer in the contents field.
> I don't think so. I examined the preprocessed source, and didn't see
> any instance of missing parentheses. I added some just so someone who
> looks at the macros won't wonder, like I did, whether this could be
> the problem.
>
> But even if you are right, and the problem will now disappear, we can
> still resolve this bug by simply going back to the original code.
I don't think the problem will disappear this way.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 16:27:01 GMT)
Full text and
rfc822 format available.
Message #48 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 15 Apr 2013 17:53:26 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, lekktu <at> gmail.com, 14062 <at> debbugs.gnu.org
>
> > Only a non-leaf window can have its w->contents be something other
> > than a buffer, right? If BUFFERP(w->contents) returns zero
>
> ... for an internal window w->contents _must_ be another window, only
> for deleted windows this can be nil (but Dmitry would have to verify
> this, I didn't look at his last changes yet) ...
But for nil, BUFFERP will return zero, and the code that uses XBUFFER
should not be called, IMO.
> > and
> > XBUFFER hits an assertion violation, what else can this window be
> > except non-leaf?
>
> A window with an uninitialized contents field. Such windows exist from
> the moment they are allocated by make_window until they either get a
> child or a buffer in the contents field.
But the uninitialized contents field should be zero, no? Again, it
should not pass the BUFFERP test.
So the mystery still stands.
> > I don't think so. I examined the preprocessed source, and didn't see
> > any instance of missing parentheses. I added some just so someone who
> > looks at the macros won't wonder, like I did, whether this could be
> > the problem.
> >
> > But even if you are right, and the problem will now disappear, we can
> > still resolve this bug by simply going back to the original code.
>
> I don't think the problem will disappear this way.
Neither do I.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 15 Apr 2013 19:27:02 GMT)
Full text and
rfc822 format available.
Message #51 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> But for nil, BUFFERP will return zero, and the code that uses XBUFFER
> should not be called, IMO.
[...]
> But the uninitialized contents field should be zero, no? Again, it
> should not pass the BUFFERP test.
>
> So the mystery still stands.
You mean that the w->contents argument of XBUFFER _always_ passes the
BUFFERP test first and then fails at the assertion in XBUFFER? How can
that make sense?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Tue, 16 Apr 2013 06:13:02 GMT)
Full text and
rfc822 format available.
Message #54 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 15 Apr 2013 21:22:00 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: drew.adams <at> oracle.com, lekktu <at> gmail.com, 14062 <at> debbugs.gnu.org
>
> > But for nil, BUFFERP will return zero, and the code that uses XBUFFER
> > should not be called, IMO.
> [...]
> > But the uninitialized contents field should be zero, no? Again, it
> > should not pass the BUFFERP test.
> >
> > So the mystery still stands.
>
> You mean that the w->contents argument of XBUFFER _always_ passes the
> BUFFERP test first and then fails at the assertion in XBUFFER?
Yes, see the definition of the WINDOW_WANTS_HEADER_LINE_P macro, where
we have:
&& BUFFERP (W->contents) \
&& !NILP (BVAR (XBUFFER (W->contents), header_line_format)) \
Should a condition be always evaluated left to right? Or is a
processor allowed to issue these two parts in parallel, if it has more
than one processing unit available?
> How can that make sense?
Exactly my question. But the evidence is unequivocal: the assertion
in XBUFFER is the one that aborts. I disassembled the code to make
sure I got that correctly. This was an unoptimized build, so any
tricks with folding several different calls into one don't happen.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 22 Apr 2013 16:10:01 GMT)
Full text and
rfc822 format available.
Message #57 received at 14062 <at> debbugs.gnu.org (full text, mbox):
Got another backtrace that is similar but not the same. Eli & Martin suggested
that this is probably the right bug to report it to.
Backtrace:
0x011594EF
0x01159561
0x01001459
0x01021A5E
0x0114EEB8
0x7E418730
0x7E418812
0x7E4189C9
0x7E418A0C
0x0114DA69
0x0114DD08
0x7C80B725
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-04-17 on ODIEONE
Bzr revision: 112320 monnier <at> iro.umontreal.ca-20130418001233-g6wsqi5bpq2hsd0k
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 22 Apr 2013 16:18:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 14062 <at> debbugs.gnu.org (full text, mbox):
??
??: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
??
??:0
??
??:0
??
??:0
??
??:0
w32_msg_pump at w32fns.c:2454
w32_msg_worker <at> 4 at w32fns.c:2580
??
??:0
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 22 Apr 2013 18:11:01 GMT)
Full text and
rfc822 format available.
Message #63 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 22 Apr 2013 18:12:13 +0200
> Cc: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>, 14062 <at> 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.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 22 Apr 2013 18:24:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 14062 <at> debbugs.gnu.org (full text, mbox):
Yay!
> the cause for the assertion violation is now crystal clear, and I
> will commit a work-around soon.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 04 May 2013 10:30:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Sat, 04 May 2013 10:30:03 GMT)
Full text and
rfc822 format available.
Message #71 received at 14062-done <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 22 Apr 2013 21:05:53 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 14062 <at> debbugs.gnu.org
>
> > From: Juanma Barranquero <lekktu <at> gmail.com>
> > Date: Mon, 22 Apr 2013 18:12:13 +0200
> > Cc: Eli Zaretskii <eliz <at> gnu.org>, martin rudalics <rudalics <at> gmx.at>, 14062 <at> 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.
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Sat, 04 May 2013 10:30:03 GMT)
Full text and
rfc822 format available.
Notification sent
to
"Drew Adams" <drew.adams <at> oracle.com>:
bug acknowledged by developer.
(Sat, 04 May 2013 10:30:04 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Sat, 04 May 2013 12:29:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> 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 fail to understand what FRAME_WANTS_MODELINE_P is good for. I
removed it in my code long ago.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Sat, 04 May 2013 12:35:02 GMT)
Full text and
rfc822 format available.
Message #82 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 May 2013 14:27:23 +0200
> From: martin rudalics <rudalics <at> gmx.at>
>
> > 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 fail to understand what FRAME_WANTS_MODELINE_P is good for. I
> removed it in my code long ago.
It causes the header line to disappear when the window is too small to
show both the modeline and the header line. The limit of the window
size where that happens obviously should be different depending on
whether the window does or does not have a modeline.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Sat, 04 May 2013 12:47:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 14062 <at> debbugs.gnu.org (full text, mbox):
>> I fail to understand what FRAME_WANTS_MODELINE_P is good for. I
>> removed it in my code long ago.
>
> It causes the header line to disappear when the window is too small to
> show both the modeline and the header line. The limit of the window
> size where that happens obviously should be different depending on
> whether the window does or does not have a modeline.
IIUC what you talk about here is WINDOW_WANTS_MODELINE_P. Or am I
missing something?
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Sat, 04 May 2013 13:21:02 GMT)
Full text and
rfc822 format available.
Message #88 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 04 May 2013 14:45:14 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: 14062 <at> debbugs.gnu.org, drew.adams <at> oracle.com
>
> >> I fail to understand what FRAME_WANTS_MODELINE_P is good for. I
> >> removed it in my code long ago.
> >
> > It causes the header line to disappear when the window is too small to
> > show both the modeline and the header line. The limit of the window
> > size where that happens obviously should be different depending on
> > whether the window does or does not have a modeline.
>
> IIUC what you talk about here is WINDOW_WANTS_MODELINE_P.
Sorry, I was actually talking about something else entirely: about
this:
+ !NILP (BVAR (XBUFFER ((W)->contents), mode_line_format))
As for FRAME_WANTS_MODELINE_P, it's zero for minibuffer frames and
tooltip frames. Are you saying that these frames should be able to
have header lines?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Sat, 04 May 2013 14:41:03 GMT)
Full text and
rfc822 format available.
Message #91 received at 14062-done <at> debbugs.gnu.org (full text, mbox):
> I'm closing the bug. Feel free to reopen if we get aborts around line
> 3186 in w32fns.c.
Great! Thanks, Eli, for persevering and tracking this down (and fixing it).
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Sat, 04 May 2013 19:01:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Sorry, I was actually talking about something else entirely: about
> this:
>
> + !NILP (BVAR (XBUFFER ((W)->contents), mode_line_format))
>
> As for FRAME_WANTS_MODELINE_P, it's zero for minibuffer frames and
> tooltip frames. Are you saying that these frames should be able to
> have header lines?
No. As far as minibuffer frames are concerned, these should be excluded
by the !MINI_WINDOW_P ((W)) conjunct since make_minibuffer_frame sets
XWINDOW (mini_window)->mini = 1. I forgot about tooltip windows though.
Note that frame.h has this
/* 0 means, if this frame has just one window,
show no modeline for that window. */
unsigned wants_modeline : 1;
and we set this to 0 in make_minibuffer_frame but we don't set this for
tooltip frames - that's why I didn't find it in the first place.
Moreover, the comment insinuates that when the frame has two windows we
might want to show a modeline so WINDOW_WANTS_MODELINE_P would have to
check that (I doubt that such frames exist in practice though).
Finally, frame.h also has this comment
/* Not really implemented. */
#define FRAME_WANTS_MODELINE_P(f) (f)->wants_modeline
which only adds to my confusion.
martin
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 13 May 2013 17:35:02 GMT)
Full text and
rfc822 format available.
Message #97 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> From: "Drew Adams" <drew.adams <at> oracle.com>
> Date: Sat, 11 May 2013 13:01:55 -0700
>
> Backtrace:
> 0x011596ED
> 0x0115975F
> 0x010E82C7
> 0x0101596C
> 0x01015146
> 0x0101329A
> 0x0100F0E2
> 0x01015837
> 0x01014F59
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010141F5
> 0x011CA1B5
> 0x011CA735
> 0x011D3CA9
> 0x01016530
> 0x010E5C83
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010141F5
> 0x01025C4C
> 0x01010C39
> 0x0102606A
> 0x01014038
> 0x010260BE
> 0x0102486D
> 0x01010C39
> 0x01023814
> 0x01010696
> 0x0102377D
> 0x01022D88
> 0x010C2439
> 0x010C3143
> 0x01014D87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x010E454E
> 0x01012F1D
> 0x01010696
> 0x010E5D12
> 0x0101596C
> 0x01014E87
> 0x010E517E
> 0x0101596C
> 0x01014E87
> 0x01012C92
> 0x01010B57
> 0x010E5DBB
> 0x0101596C
> 0x01014E87
> 0x010141A0
> 0x010E8FF2
> 0x01014B45
> ...
I think this part was with an earlier binary, not the one you reported
(because the result of using this backtrace doesn't make any sense at
all). What was the previous version you used? My guess is it was
emacs-20130502-r112438-bin-i386.zip, which brings us to something very
similar to bug #14236, #13154, and #13980:
emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7822
emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7831
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1958
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
apply_lambda at C:\Devel\emacs\repo\build\src/eval.c:2783
eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2084
Fprogn at C:\Devel\emacs\repo\build\src/eval.c:359
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2899
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2735
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
call0 at C:\Devel\emacs\repo\build\src/eval.c:2453
select_frame_norecord at C:\Devel\emacs\repo\build\src/window.c:3091
set_window_buffer at C:\Devel\emacs\repo\build\src/window.c:3177
delete_all_child_windows at C:\Devel\emacs\repo\build\src/window.c:5885
unbind_to at C:\Devel\emacs\repo\build\src/eval.c:3097
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1066
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
call0 at C:\Devel\emacs\repo\build\src/eval.c:2453
safe_run_hooks_1 at C:\Devel\emacs\repo\build\src/keyboard.c:1875
internal_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1193
safe_run_hook_funcall at C:\Devel\emacs\repo\build\src/keyboard.c:1930
run_hook_with_args at C:\Devel\emacs\repo\build\src/eval.c:2398
safe_run_hooks at C:\Devel\emacs\repo\build\src/keyboard.c:1947
command_loop_1 at C:\Devel\emacs\repo\build\src/keyboard.c:1592
internal_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1193
command_loop_2 at C:\Devel\emacs\repo\build\src/keyboard.c:1167
internal_catch at C:\Devel\emacs\repo\build\src/eval.c:964
command_loop at C:\Devel\emacs\repo\build\src/keyboard.c:1138
recursive_edit_1 at C:\Devel\emacs\repo\build\src/keyboard.c:779
read_minibuf at C:\Devel\emacs\repo\build\src/minibuf.c:678
Fread_from_minibuffer at C:\Devel\emacs\repo\build\src/minibuf.c:980
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2700
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
Fbyte_code at C:\Devel\emacs\repo\build\src/bytecode.c:475
eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2045
internal_catch at C:\Devel\emacs\repo\build\src/eval.c:964
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1081
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:900
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
eval_sub at C:\Devel\emacs\repo\build\src/eval.c:2011
internal_lisp_condition_case at C:\Devel\emacs\repo\build\src/eval.c:1147
exec_byte_code at C:\Devel\emacs\repo\build\src/bytecode.c:1096
funcall_lambda at C:\Devel\emacs\repo\build\src/eval.c:2906
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2723
apply1 at C:\Devel\emacs\repo\build\src/eval.c:2435
Fcall_interactively at C:\Devel\emacs\repo\build\src/callint.c:378
Ffuncall at C:\Devel\emacs\repo\build\src/eval.c:2681
> Backtrace:
> 0x011594ED
> 0x0115955F
> 0x01001459
> 0x01021A5E
> 0x0114F2B6
> 0x7E418730
> 0x7E418812
> 0x7E4189C9
> 0x7E418A0C
> 0x0114DB00
> 0x0114DD9F
> 0x7C80B725
This part translates into this:
w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7739
emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7771
terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343
die at C:\Devel\emacs\repo\build\src/alloc.c:6522
w32_wnd_proc at C:\Devel\emacs\repo\build\src/w32fns.c:3187
Which means my fix for bug #14062 did not solve it. Hmm...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Mon, 13 May 2013 18:08:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> I think this part was with an earlier binary, not the one you reported
> (because the result of using this backtrace doesn't make any sense at
> all).
I don't think so. After the crash I brought up the same version to report it.
I typically use only one Emacs 24 build at a time, the latest one I have (unless
it is totally unusable).
If I ever mistake the version (e.g. what crashed vs what I reported from) then
it would likely be a completely different release (e.g. Emacs 23 vs 24). Not
necessarily, but likely.
> What was the previous version you used?
The previous binary I have to the one I reported about (from 5/10), is from 5/4:
In GNU Emacs 24.3.50.1 (i386-mingw-nt5.1.2600)
of 2013-05-04 on ODIEONE
Bzr revision: 112449 monnier <at> iro.umontreal.ca-20130504193419-kbd4imjj1yxr5ksz
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
`configure --with-gcc (4.7) --no-opt --enable-checking --cflags
-IC:/Devel/emacs/build/include --ldflags -LC:/Devel/emacs/build/lib'
> My guess is it was
> emacs-20130502-r112438-bin-i386.zip, which brings us to something very
> similar to bug #14236, #13154, and #13980
No, I have no binary from 5/2. The one I have prior to 5/4 is from 4/26.
HTH.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#14062; Package
emacs,w32.
(Tue, 14 May 2013 14:13:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 14062 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 13 May 2013 20:33:13 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 14389 <at> debbugs.gnu.org, 14062 <at> debbugs.gnu.org, 13980 <at> debbugs.gnu.org
>
> > Backtrace:
> > 0x011594ED
> > 0x0115955F
> > 0x01001459
> > 0x01021A5E
> > 0x0114F2B6
> > 0x7E418730
> > 0x7E418812
> > 0x7E4189C9
> > 0x7E418A0C
> > 0x0114DB00
> > 0x0114DD9F
> > 0x7C80B725
>
> This part translates into this:
>
> w32_backtrace at C:\Devel\emacs\repo\build\src/w32fns.c:7739
> emacs_abort at C:\Devel\emacs\repo\build\src/w32fns.c:7771
> terminate_due_to_signal at C:\Devel\emacs\repo\build\src/emacs.c:343
> die at C:\Devel\emacs\repo\build\src/alloc.c:6522
> w32_wnd_proc at C:\Devel\emacs\repo\build\src/w32fns.c:3187
>
> Which means my fix for bug #14062 did not solve it. Hmm...
Trunk revision 112580 is another attempt at solving this bug.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Wed, 12 Jun 2013 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 10 years and 327 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.