all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: emacs-devel@gnu.org
Subject: Re: Current trunk aborts with MinGW
Date: Tue, 30 Sep 2014 16:59:02 +0300	[thread overview]
Message-ID: <83zjdhky55.fsf@gnu.org> (raw)
In-Reply-To: <542A690D.9080500@gmx.at>

> Date: Tue, 30 Sep 2014 10:25:49 +0200
> From: martin rudalics <rudalics@gmx.at>
> 
> A MinGW build of current trunk aborts here as follows:
> 
> 
> Breakpoint 1, terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:361
> 361	  signal (sig, SIG_DFL);
> (gdb) bt
> #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:361
> #1  0x01173d6b in die (msg=0x14bb004 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14baf34 "lisp.h", line=926) at alloc.c:7111
> #2  0x010f9651 in make_lisp_ptr (ptr=0x4a7fe0c, type=Lisp_String) at lisp.h:926
> #3  0x0101b2a2 in x_get_arg (dpyinfo=0x206d800, alist=..., param=..., attribute=0x14de8e4 "left", class=0x14de8df "Left", type=RES_TYPE_NUMBER) at frame.c:4152
> #4  0x01202cc9 in w32_createwindow (f=0x16c70b8) at w32fns.c:1987
> #5  0x01203b0e in w32_msg_pump (msg_buf=0x4a7ff54) at w32fns.c:2519
> #6  0x01204067 in w32_msg_worker@4 (arg=0x0) at w32fns.c:2724
> #7  0x7c80b683 in KERNEL32!GetModuleFileNameA () from C:\WINDOWS\system32\kernel32.dll
> #8  0x00000000 in ?? ()
> 
> Lisp Backtrace:
> "x-create-frame" (0x82e7c8)
> "x-create-frame-with-faces" (0x82eb18)
> "make-frame" (0x82ee68)
> "frame-initialize" (0x82f1b8)
> "command-line" (0x82f53c)
> "normal-top-level" (0x82f800)
> 
> 
> Help welcome, martin

So I think we are very lucky to have this exposed before the release
of 24.4, because this reveals a fatal flaw in our code for the last 6
years: we are consing Lisp objects in a thread other than the main
(a.k.a. "Lisp") thread.  This is an absolute no-no, and can explain
any number of weird crash reports we had in the meantime, especially
from users whose Emacs usage patterns create frames a lot.

I fixed this in the emacs-24 branch (r117524).  The patch is below for
those who need this for the trunk and cannot wait for the merge.

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2014-07-12 09:25:29 +0000
+++ src/w32fns.c	2014-09-30 13:53:24 +0000
@@ -1911,13 +1911,12 @@ w32_createscrollbar (struct frame *f, st
 }
 
 static void
-w32_createwindow (struct frame *f)
+w32_createwindow (struct frame *f, int *coords)
 {
   HWND hwnd;
   RECT rect;
-  Lisp_Object top = Qunbound;
-  Lisp_Object left = Qunbound;
-  struct w32_display_info *dpyinfo = &one_w32_display_info;
+  int top;
+  int left;
 
   rect.left = rect.top = 0;
   rect.right = FRAME_PIXEL_WIDTH (f);
@@ -1932,25 +1931,21 @@ w32_createwindow (struct frame *f)
 
   if (f->size_hint_flags & USPosition || f->size_hint_flags & PPosition)
     {
-      XSETINT (left, f->left_pos);
-      XSETINT (top, f->top_pos);
+      left = f->left_pos;
+      top = f->top_pos;
     }
-  else if (EQ (left, Qunbound) && EQ (top, Qunbound))
+  else
     {
-      /* When called with RES_TYPE_NUMBER, w32_get_arg will return zero
-	 for anything that is not a number and is not Qunbound.  */
-      left = x_get_arg (dpyinfo, Qnil, Qleft, "left", "Left", RES_TYPE_NUMBER);
-      top = x_get_arg (dpyinfo, Qnil, Qtop, "top", "Top", RES_TYPE_NUMBER);
+      left = coords[0];
+      top = coords[1];
     }
 
   FRAME_W32_WINDOW (f) = hwnd
     = CreateWindow (EMACS_CLASS,
 		    f->namebuf,
 		    f->output_data.w32->dwStyle | WS_CLIPCHILDREN,
-		    EQ (left, Qunbound) ? CW_USEDEFAULT : XINT (left),
-		    EQ (top, Qunbound) ? CW_USEDEFAULT : XINT (top),
-		    rect.right - rect.left,
-		    rect.bottom - rect.top,
+		    left, top,
+		    rect.right - rect.left, rect.bottom - rect.top,
 		    NULL,
 		    NULL,
 		    hinst,
@@ -2468,7 +2463,8 @@ w32_msg_pump (deferred_msg * msg_buf)
                  the patch for XP is not publicly available until XP SP3,
                  and older versions will never be patched.  */
               CoInitialize (NULL);
-	      w32_createwindow ((struct frame *) msg.wParam);
+	      w32_createwindow ((struct frame *) msg.wParam,
+				(int *) msg.lParam);
 	      if (!PostThreadMessage (dwMainThreadId, WM_EMACS_DONE, 0, 0))
 		emacs_abort ();
 	      break;
@@ -4069,8 +4065,25 @@ static void
 my_create_window (struct frame * f)
 {
   MSG msg;
+  static int coords[2];
+  Lisp_Object left, top;
+  struct w32_display_info *dpyinfo = &one_w32_display_info;
+
+  /* When called with RES_TYPE_NUMBER, x_get_arg will return zero for
+     anything that is not a number and is not Qunbound.  */
+  left = x_get_arg (dpyinfo, Qnil, Qleft, "left", "Left", RES_TYPE_NUMBER);
+  top = x_get_arg (dpyinfo, Qnil, Qtop, "top", "Top", RES_TYPE_NUMBER);
+  if (EQ (left, Qunbound))
+    coords[0] = CW_USEDEFAULT;
+  else
+    coords[0] = XINT (left);
+  if (EQ (top, Qunbound))
+    coords[1] = CW_USEDEFAULT;
+  else
+    coords[1] = XINT (top);
 
-  if (!PostThreadMessage (dwWindowsThreadId, WM_EMACS_CREATEWINDOW, (WPARAM)f, 0))
+  if (!PostThreadMessage (dwWindowsThreadId, WM_EMACS_CREATEWINDOW,
+			  (WPARAM)f, (LPARAM)coords))
     emacs_abort ();
   GetMessage (&msg, NULL, WM_EMACS_DONE, WM_EMACS_DONE);
 }




  parent reply	other threads:[~2014-09-30 13:59 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30  8:25 Current trunk aborts with MinGW martin rudalics
2014-09-30 13:01 ` Andy Moreton
2014-09-30 13:51   ` martin rudalics
2014-09-30 14:19     ` Andy Moreton
2014-09-30 15:57       ` martin rudalics
2014-09-30 14:44     ` Eli Zaretskii
2014-09-30 15:58       ` martin rudalics
2014-09-30 16:07         ` Eli Zaretskii
2014-09-30 16:24           ` martin rudalics
2014-09-30 14:02   ` Eli Zaretskii
2014-09-30 13:59 ` Eli Zaretskii [this message]
2014-09-30 14:11   ` martin rudalics
2014-09-30 14:36     ` Eli Zaretskii
2014-09-30 14:33 ` Stefan Monnier
2014-09-30 14:42   ` Eli Zaretskii
2014-09-30 15:57     ` martin rudalics
2014-09-30 17:41       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83zjdhky55.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.