all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* bug#14666: 24.3.50; emacs_backtrace.txt
@ 2013-06-19 15:04 Drew Adams
  2013-06-19 15:14 ` Juanma Barranquero
  0 siblings, 1 reply; 17+ messages in thread
From: Drew Adams @ 2013-06-19 15:04 UTC (permalink / raw)
  To: 14666

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'





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 15:04 bug#14666: 24.3.50; emacs_backtrace.txt Drew Adams
@ 2013-06-19 15:14 ` Juanma Barranquero
  2013-06-19 16:10   ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Juanma Barranquero @ 2013-06-19 15:14 UTC (permalink / raw)
  To: Drew Adams; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 15:14 ` Juanma Barranquero
@ 2013-06-19 16:10   ` Eli Zaretskii
  2013-06-19 16:47     ` Eli Zaretskii
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-06-19 16:10 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 16:10   ` Eli Zaretskii
@ 2013-06-19 16:47     ` Eli Zaretskii
  2013-06-19 16:48       ` Juanma Barranquero
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-06-19 16:47 UTC (permalink / raw)
  To: lekktu; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 16:47     ` Eli Zaretskii
@ 2013-06-19 16:48       ` Juanma Barranquero
  2013-06-19 17:08         ` Eli Zaretskii
  2013-06-19 17:44         ` martin rudalics
  0 siblings, 2 replies; 17+ messages in thread
From: Juanma Barranquero @ 2013-06-19 16:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14666

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?





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 16:48       ` Juanma Barranquero
@ 2013-06-19 17:08         ` Eli Zaretskii
  2013-06-19 17:23           ` Juanma Barranquero
  2013-06-19 17:44         ` martin rudalics
  1 sibling, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-06-19 17:08 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 17:08         ` Eli Zaretskii
@ 2013-06-19 17:23           ` Juanma Barranquero
  2013-06-19 17:57             ` martin rudalics
  2013-06-19 19:44             ` Eli Zaretskii
  0 siblings, 2 replies; 17+ messages in thread
From: Juanma Barranquero @ 2013-06-19 17:23 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 16:48       ` Juanma Barranquero
  2013-06-19 17:08         ` Eli Zaretskii
@ 2013-06-19 17:44         ` martin rudalics
  2013-06-19 19:47           ` Eli Zaretskii
  1 sibling, 1 reply; 17+ messages in thread
From: martin rudalics @ 2013-06-19 17:44 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 17:23           ` Juanma Barranquero
@ 2013-06-19 17:57             ` martin rudalics
  2013-06-19 18:46               ` Juanma Barranquero
  2013-06-19 19:51               ` Eli Zaretskii
  2013-06-19 19:44             ` Eli Zaretskii
  1 sibling, 2 replies; 17+ messages in thread
From: martin rudalics @ 2013-06-19 17:57 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 14666

 > 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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 17:57             ` martin rudalics
@ 2013-06-19 18:46               ` Juanma Barranquero
  2013-06-19 20:59                 ` martin rudalics
  2013-06-19 19:51               ` Eli Zaretskii
  1 sibling, 1 reply; 17+ messages in thread
From: Juanma Barranquero @ 2013-06-19 18:46 UTC (permalink / raw)
  To: martin rudalics; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 17:23           ` Juanma Barranquero
  2013-06-19 17:57             ` martin rudalics
@ 2013-06-19 19:44             ` Eli Zaretskii
  2013-06-19 19:46               ` Juanma Barranquero
  2013-06-19 20:03               ` Juanma Barranquero
  1 sibling, 2 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-06-19 19:44 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 19:44             ` Eli Zaretskii
@ 2013-06-19 19:46               ` Juanma Barranquero
  2013-06-19 20:03               ` Juanma Barranquero
  1 sibling, 0 replies; 17+ messages in thread
From: Juanma Barranquero @ 2013-06-19 19:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14666

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 17:44         ` martin rudalics
@ 2013-06-19 19:47           ` Eli Zaretskii
  2013-06-19 20:58             ` martin rudalics
  0 siblings, 1 reply; 17+ messages in thread
From: Eli Zaretskii @ 2013-06-19 19:47 UTC (permalink / raw)
  To: martin rudalics; +Cc: lekktu, 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 17:57             ` martin rudalics
  2013-06-19 18:46               ` Juanma Barranquero
@ 2013-06-19 19:51               ` Eli Zaretskii
  1 sibling, 0 replies; 17+ messages in thread
From: Eli Zaretskii @ 2013-06-19 19:51 UTC (permalink / raw)
  To: martin rudalics; +Cc: lekktu, 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 19:44             ` Eli Zaretskii
  2013-06-19 19:46               ` Juanma Barranquero
@ 2013-06-19 20:03               ` Juanma Barranquero
  1 sibling, 0 replies; 17+ messages in thread
From: Juanma Barranquero @ 2013-06-19 20:03 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 14666

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.





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 19:47           ` Eli Zaretskii
@ 2013-06-19 20:58             ` martin rudalics
  0 siblings, 0 replies; 17+ messages in thread
From: martin rudalics @ 2013-06-19 20:58 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: lekktu, 14666

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





^ permalink raw reply	[flat|nested] 17+ messages in thread

* bug#14666: 24.3.50; emacs_backtrace.txt
  2013-06-19 18:46               ` Juanma Barranquero
@ 2013-06-19 20:59                 ` martin rudalics
  0 siblings, 0 replies; 17+ messages in thread
From: martin rudalics @ 2013-06-19 20:59 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: 14666

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






^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2013-06-19 20:59 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-06-19 15:04 bug#14666: 24.3.50; emacs_backtrace.txt Drew Adams
2013-06-19 15:14 ` Juanma Barranquero
2013-06-19 16:10   ` Eli Zaretskii
2013-06-19 16:47     ` Eli Zaretskii
2013-06-19 16:48       ` Juanma Barranquero
2013-06-19 17:08         ` Eli Zaretskii
2013-06-19 17:23           ` Juanma Barranquero
2013-06-19 17:57             ` martin rudalics
2013-06-19 18:46               ` Juanma Barranquero
2013-06-19 20:59                 ` martin rudalics
2013-06-19 19:51               ` Eli Zaretskii
2013-06-19 19:44             ` Eli Zaretskii
2013-06-19 19:46               ` Juanma Barranquero
2013-06-19 20:03               ` Juanma Barranquero
2013-06-19 17:44         ` martin rudalics
2013-06-19 19:47           ` Eli Zaretskii
2013-06-19 20:58             ` martin rudalics

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.