bug#14062: 24.3.50; emacs_backtrace.txt

bug#14062: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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@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'
 

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@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?

bug#14062: 24.3.50; emacs_backtrace.txt

[Dani Moncayo]

On Wed, Mar 27, 2013 at 7:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: "Drew Adams" <drew.adams@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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 27 Mar 2013 10:45:26 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Drew Adams <drew.adams@oracle.com>, 14062@debbugs.gnu.org
> 
> On Wed, Mar 27, 2013 at 7:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> From: "Drew Adams" <drew.adams@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@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <14062@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").

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Thu, 28 Mar 2013 11:25:39 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14062@debbugs.gnu.org, dmoncayo@gmail.com
> 
> > From: "Drew Adams" <drew.adams@oracle.com>
> > Cc: <14062@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Mon, Apr 15, 2013 at 9:35 AM, Eli Zaretskii <eliz@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Mon, 15 Apr 2013 13:54:03 +0200
> Cc: Drew Adams <drew.adams@oracle.com>, 14062@debbugs.gnu.org, 
> 	Dani Moncayo Melgar <dmoncayo@gmail.com>
> 
> On Mon, Apr 15, 2013 at 9:35 AM, Eli Zaretskii <eliz@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > 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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 14:40:46 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, Juanma Barranquero <lekktu@gmail.com>, 
>  14062@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics]

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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 17:53:26 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, lekktu@gmail.com, 14062@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > 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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Mon, 15 Apr 2013 21:22:00 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: drew.adams@oracle.com, lekktu@gmail.com, 14062@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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@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'

bug#14062: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

??
??: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@4 at w32fns.c:2580
??
??:0

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

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

bug#14062: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Yay! 

> the cause for the assertion violation is now crystal clear, and I
> will commit a work-around soon.

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

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

bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > 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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 04 May 2013 14:27:23 +0200
> From: martin rudalics <rudalics@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.

bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics]

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

bug#14062: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Sat, 04 May 2013 14:45:14 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 14062@debbugs.gnu.org, drew.adams@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?

bug#14062: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > 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

bug#14062: 24.3.50; emacs_backtrace.txt

[Drew Adams]

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

bug#14062: 24.3.50; emacs_backtrace.txt

[Drew Adams]

> 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