bug#14666: 24.3.50; emacs_backtrace.txt

bug#14666: 24.3.50; emacs_backtrace.txt

[Drew Adams]

Apologies if this is a duplicate.

Backtrace:
0x011ecbac
0x011ecc1e
0x010d9fe0
0x01151719
0x01147b6b
0x011e3ac1
0x76a662f6
0x76a66d36
0x76a677c0
0x76a67886
0x011e251e
0x011e27bd
0x755133a6
0x77579eee
0x77579ec1


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-06-17 on ODIEONE
Bzr revision: 113024 eliz@gnu.org-20130617163040-8hmzci370q4argze
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 CFLAGS=-O0 -g3 LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

bug#14666: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

0x00000bac: ??
??:0
0x011ecbac: w32_backtrace at w32fns.c:7741
0x011ecc1e: emacs_abort at w32fns.c:7773
0x010d9fe0: terminate_due_to_signal at emacs.c:350
0x01151719: die at alloc.c:6520
0x01147b6b: XBUFFER at lisp.h:820
0x011e3ac1: w32_wnd_proc at w32fns.c:3189
0x76a662f6: ??
??:0
0x76a66d36: ??
??:0
0x76a677c0: ??
??:0
0x76a67886: ??
??:0
0x011e251e: w32_msg_pump at w32fns.c:2517
0x011e27bd: w32_msg_worker@4 at w32fns.c:2643
0x755133a6: ??
??:0
0x77579eee: ??
??:0
0x77579ec1: ??
??:0

bug#14666: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 19 Jun 2013 17:14:43 +0200
> Cc: 14666@debbugs.gnu.org
> 
> 0x011ecbac: w32_backtrace at w32fns.c:7741
> 0x011ecc1e: emacs_abort at w32fns.c:7773
> 0x010d9fe0: terminate_due_to_signal at emacs.c:350
> 0x01151719: die at alloc.c:6520
> 0x01147b6b: XBUFFER at lisp.h:820
> 0x011e3ac1: w32_wnd_proc at w32fns.c:3189

I don't get it: it crashes here:

  LISP_INLINE struct buffer *
  XBUFFER (Lisp_Object a)
  {
    eassert (BUFFERP (a));
    return XUNTAG (a, Lisp_Vectorlike);  <<<<<<<<<<<<<<<
  }

I don't see how XUNTAG can crash, so the only possible cause that's
left is the assertion before that.  But how can the assertion be
false, when line 3189 of w32fns.c is only executed if w->contents _is_
a buffer?

bug#14666: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 19:10:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 14666@debbugs.gnu.org
> 
>   LISP_INLINE struct buffer *
>   XBUFFER (Lisp_Object a)
>   {
>     eassert (BUFFERP (a));
>     return XUNTAG (a, Lisp_Vectorlike);  <<<<<<<<<<<<<<<
>   }
> 
> I don't see how XUNTAG can crash, so the only possible cause that's
> left is the assertion before that.  But how can the assertion be
> false, when line 3189 of w32fns.c is only executed if w->contents _is_
> a buffer?

The only explanation is that another thread modified w->contents after
it was tested with BUFFERP.

bug#14666: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 6:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> The only explanation is that another thread modified w->contents after
> it was tested with BUFFERP.

Should that be possible?

bug#14666: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 19 Jun 2013 18:48:38 +0200
> Cc: 14666@debbugs.gnu.org
> 
> On Wed, Jun 19, 2013 at 6:47 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> > The only explanation is that another thread modified w->contents after
> > it was tested with BUFFERP.
> 
> Should that be possible?

"Should" in what sense?  w32_wnd_proc, the function in which this
happens, is the main window procedure for Emacs, and it runs in the
input thread, which is separate from the Lisp thread.  The code which
crashes is the only one in w32_wnd_proc that references buffers,
windows, and frames, which are objects that are manipulated (and
GC'ed) by the Lisp thread.

Did I answer your question?

bug#14666: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 7:08 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> "Should" in what sense?  w32_wnd_proc, the function in which this
> happens, is the main window procedure for Emacs, and it runs in the
> input thread, which is separate from the Lisp thread.  The code which
> crashes is the only one in w32_wnd_proc that references buffers,
> windows, and frames, which are objects that are manipulated (and
> GC'ed) by the Lisp thread.

I was afraid you'd say something like that :-)

> Did I answer your question?

More or less. It is obvious that using these macros in a place where
their assumptions can be violated is a no-no (as witnessed by this
crash).

Still, shouldn't that happen much more frequently? Or it is
WM_IME_STARTCOMPOSITION infrecuent? (I would've guessed it would
mostly show up in localized version of Windows, BTW...)

   J

bug#14666: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 > It is obvious that using these macros in a place where
 > their assumptions can be violated is a no-no (as witnessed by this
 > crash).

I don't think that macros are important here.  They simply obscure the
backtrace.  If the input thread wants to calculate a window's size and
the Lisp thread deletes the window under its feet, we're lost anyway.

martin

bug#14666: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 7:57 PM, martin rudalics <rudalics@gmx.at> wrote:

> If the input thread wants to calculate a window's size and
> the Lisp thread deletes the window under its feet, we're lost anyway.

Sure.

My point is that these macros hide what's happening. I suppose if someone writes

 if (BUFFERP (b))
    /* do something with b */

in the main window procedure of Emacs, it is easier to think about
race conditions and such than when using macros which hide lots and
lots of detail.

    J

bug#14666: 24.3.50; emacs_backtrace.txt

[martin rudalics]

>> If the input thread wants to calculate a window's size and
>> the Lisp thread deletes the window under its feet, we're lost anyway.
> 
> Sure.
> 
> My point is that these macros hide what's happening. I suppose if someone writes
> 
>  if (BUFFERP (b))
>     /* do something with b */
> 
> in the main window procedure of Emacs, it is easier to think about
> race conditions and such than when using macros which hide lots and
> lots of detail.

We fully agree.

martin

bug#14666: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 19:57:21 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 14666@debbugs.gnu.org
> 
>  > It is obvious that using these macros in a place where
>  > their assumptions can be violated is a no-no (as witnessed by this
>  > crash).
> 
> I don't think that macros are important here.  They simply obscure the
> backtrace.

Not only that.  They also evaluate the same expressions several times,
assuming that the same expression always evaluates to the same value.

> If the input thread wants to calculate a window's size and the Lisp
> thread deletes the window under its feet, we're lost anyway.

I don't think we are lost in this particular case, see the
documentation of ImmSetCompositionWindow function that is being called
here.

bug#14666: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> From: Juanma Barranquero <lekktu@gmail.com>
> Date: Wed, 19 Jun 2013 19:23:12 +0200
> Cc: 14666@debbugs.gnu.org
> 
> Still, shouldn't that happen much more frequently? Or it is
> WM_IME_STARTCOMPOSITION infrecuent? (I would've guessed it would
> mostly show up in localized version of Windows, BTW...)

That's what I thought originally, but then I found this in
w32_draw_window_cursor:

	  PostMessage (hwnd, WM_IME_STARTCOMPOSITION, 0, 0);

IOW, we send this message to ourselves each time we are about to draw
the cursor, which has got to be frequent enough...

bug#14666: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 9:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> That's what I thought originally, but then I found this in
> w32_draw_window_cursor:
>
>           PostMessage (hwnd, WM_IME_STARTCOMPOSITION, 0, 0);
>
> IOW, we send this message to ourselves each time we are about to draw
> the cursor, which has got to be frequent enough...

Then it's still more puzzling that Drew's crash does not happen more frequently.

bug#14666: 24.3.50; emacs_backtrace.txt

[Juanma Barranquero]

On Wed, Jun 19, 2013 at 9:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> That's what I thought originally, but then I found this in
> w32_draw_window_cursor:
>
>           PostMessage (hwnd, WM_IME_STARTCOMPOSITION, 0, 0);

As an aside, isn't a bit weird to go through all that hoopla for every
cursor movement, just in case the user is using an IME (which I bet
most do not and will never use). Seems to me like the kind of thing
that should depend on a w32-* variable.

bug#14666: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> The only explanation is that another thread modified w->contents after
 >> it was tested with BUFFERP.
 >
 > Should that be possible?

Not really.  w->contents can be only set to another buffer which would
still pass the assertion.  Hence any such "modification" would mean that
the window got collected in between the two checks.

martin

bug#14666: 24.3.50; emacs_backtrace.txt

[Eli Zaretskii]

> Date: Wed, 19 Jun 2013 19:44:16 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: Eli Zaretskii <eliz@gnu.org>, 14666@debbugs.gnu.org
> 
> w->contents can be only set to another buffer which would still pass
> the assertion.

Why cannot it be set to a window or to nil?

bug#14666: 24.3.50; emacs_backtrace.txt

[martin rudalics]

 >> w->contents can be only set to another buffer which would still pass
 >> the assertion.
 >
 > Why cannot it be set to a window or to nil?

A leaf window stays a leaf window until it gets deleted.  Even if such a
window survives in a window configuration it can be resurrected only as
a leaf window.

martin