bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#14062: 24.3.50; emacs_backtrace.txt


From: Eli Zaretskii
Subject: bug#14062: 24.3.50; emacs_backtrace.txt
Date: Mon, 15 Apr 2013 10:35:07 +0300

> Date: Thu, 28 Mar 2013 11:25:39 +0200
> From: Eli Zaretskii <address@hidden>
> Cc: address@hidden, address@hidden
> 
> > From: "Drew Adams" <address@hidden>
> > Cc: <address@hidden>
> > 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]