GNU bug report logs - #14666
24.3.50; emacs_backtrace.txt

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 14666 in the body.
You can then email your comments to 14666 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Drew Adams <drew.adams <at> oracle.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 08:04:28 -0700 (PDT)

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

Message #8 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Drew Adams <drew.adams <at> oracle.com>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 17:14:43 +0200

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 <at> 4 at w32fns.c:2643
0x755133a6: ??
??:0
0x77579eee: ??
??:0
0x77579ec1: ??
??:0

Message #11 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14666 <at> debbugs.gnu.org, drew.adams <at> oracle.com
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 19:10:26 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Wed, 19 Jun 2013 17:14:43 +0200
> Cc: 14666 <at> 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?

Message #14 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: lekktu <at> gmail.com
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 19:47:23 +0300

> Date: Wed, 19 Jun 2013 19:10:26 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 14666 <at> 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.

Message #17 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 18:48:38 +0200

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

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

Should that be possible?

Message #20 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 20:08:50 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Wed, 19 Jun 2013 18:48:38 +0200
> Cc: 14666 <at> debbugs.gnu.org
> 
> On Wed, Jun 19, 2013 at 6:47 PM, Eli Zaretskii <eliz <at> 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?

Message #23 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 19:23:12 +0200

On Wed, Jun 19, 2013 at 7:08 PM, Eli Zaretskii <eliz <at> 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

Message #26 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 19:44:16 +0200

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

Message #29 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 19:57:21 +0200

> 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

Message #32 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 20:46:16 +0200

On Wed, Jun 19, 2013 at 7:57 PM, martin rudalics <rudalics <at> 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

Message #35 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 22:44:33 +0300

> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Wed, 19 Jun 2013 19:23:12 +0200
> Cc: 14666 <at> 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...

Message #38 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 21:46:08 +0200

On Wed, Jun 19, 2013 at 9:44 PM, Eli Zaretskii <eliz <at> 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.

Message #41 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 22:47:16 +0300

> Date: Wed, 19 Jun 2013 19:44:16 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 14666 <at> 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?

Message #44 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: lekktu <at> gmail.com, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 22:51:49 +0300

> Date: Wed, 19 Jun 2013 19:57:21 +0200
> From: martin rudalics <rudalics <at> gmx.at>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 14666 <at> 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.

Message #47 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 22:03:35 +0200

On Wed, Jun 19, 2013 at 9:44 PM, Eli Zaretskii <eliz <at> 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.

Message #50 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: lekktu <at> gmail.com, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 22:58:57 +0200

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

Message #53 received at 14666 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 14666 <at> debbugs.gnu.org
Subject: Re: bug#14666: 24.3.50; emacs_backtrace.txt
Date: Wed, 19 Jun 2013 22:59:03 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.