* Current trunk aborts with MinGW @ 2014-09-30 8:25 martin rudalics 2014-09-30 13:01 ` Andy Moreton ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: martin rudalics @ 2014-09-30 8:25 UTC (permalink / raw) To: emacs-devel 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 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:02 ` Eli Zaretskii 2014-09-30 13:59 ` Eli Zaretskii 2014-09-30 14:33 ` Stefan Monnier 2 siblings, 2 replies; 17+ messages in thread From: Andy Moreton @ 2014-09-30 13:01 UTC (permalink / raw) To: emacs-devel On Tue 30 Sep 2014, martin rudalics wrote: > A MinGW build of current trunk aborts here as follows: You have not given enough details: 1) which revision of trunk ? 2) which mingw toolchain and gcc version ? 3) which build options ? 4) what did you do to provoke the bug ? mingw32 32bit and mingw64 64bit builds work for me at trunk r117982. AndyM ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 13:01 ` Andy Moreton @ 2014-09-30 13:51 ` martin rudalics 2014-09-30 14:19 ` Andy Moreton 2014-09-30 14:44 ` Eli Zaretskii 2014-09-30 14:02 ` Eli Zaretskii 1 sibling, 2 replies; 17+ messages in thread From: martin rudalics @ 2014-09-30 13:51 UTC (permalink / raw) To: Andy Moreton, emacs-devel > 1) which revision of trunk ? I tried revisions 117981 and now 117983. > 2) which mingw toolchain and gcc version ? gcc version 4.6.2. I have no idea what a mingw toolchain version is. > 3) which build options ? CPPFLAGS='-DGLYPH_DEBUG=1' CFLAGS='-O0 -g3' ./configure --prefix=/c/emacs/quickfixes --enable-checking=yes --enable-check-lisp-object-type=yes > 4) what did you do to provoke the bug ? I invoked emacs -Q. The problem is in this part of frame.c tem = display_x_get_resource (dpyinfo, SCOPED_STRING (attribute), SCOPED_STRING (class), Qnil, Qnil); but I have no idea how to investigate this. martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 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 1 sibling, 1 reply; 17+ messages in thread From: Andy Moreton @ 2014-09-30 14:19 UTC (permalink / raw) To: emacs-devel On Tue 30 Sep 2014, martin rudalics wrote: >> 1) which revision of trunk ? > > I tried revisions 117981 and now 117983. > >> 2) which mingw toolchain and gcc version ? > > gcc version 4.6.2. I have no idea what a mingw toolchain version is. There are several toolchains: a) The Mingw project (www.mingw.org): - 32bit gcc (i686-pc-mingw32) b) The Mingw64 project (mingw-w64.sourceforge.net): - 32bit gcc (i686-w64-mingw32) - 64bit gcc (x86_64-w64-mingw32) It helps to know which one you are using as well as the gcc version. > The problem is in this part of frame.c > > tem = display_x_get_resource > (dpyinfo, SCOPED_STRING (attribute), > SCOPED_STRING (class), Qnil, Qnil); > > but I have no idea how to investigate this. Eli has analysed the cause of this, and his patch will hopefully fix your problem (and several other obscure crashes seen recently). AndyM ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 14:19 ` Andy Moreton @ 2014-09-30 15:57 ` martin rudalics 0 siblings, 0 replies; 17+ messages in thread From: martin rudalics @ 2014-09-30 15:57 UTC (permalink / raw) To: Andy Moreton, emacs-devel >> I have no idea what a mingw toolchain version is. > > There are several toolchains: > > a) The Mingw project (www.mingw.org): > - 32bit gcc (i686-pc-mingw32) > > b) The Mingw64 project (mingw-w64.sourceforge.net): > - 32bit gcc (i686-w64-mingw32) > - 64bit gcc (x86_64-w64-mingw32) Aha ... that thing printed by `emacs-version' or `system-configuration'. It's "i686-pc-mingw32" here. Couldn't you try to write a function that provides more meaningful information here? I always consider w32 bug reports inferior to the ones for GNU/Linux which IMHO are not entirely optimal either. Basically, it would be fine to have one function that gets me, in a nicely formatted way, - the operating system, - the revision number, - the build options, - the build environment, - the date of the build that is, most of the things you asked for. martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 13:51 ` martin rudalics 2014-09-30 14:19 ` Andy Moreton @ 2014-09-30 14:44 ` Eli Zaretskii 2014-09-30 15:58 ` martin rudalics 1 sibling, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 14:44 UTC (permalink / raw) To: martin rudalics; +Cc: andrewjmoreton, emacs-devel > Date: Tue, 30 Sep 2014 15:51:55 +0200 > From: martin rudalics <rudalics@gmx.at> > > The problem is in this part of frame.c > > tem = display_x_get_resource > (dpyinfo, SCOPED_STRING (attribute), > SCOPED_STRING (class), Qnil, Qnil); > > but I have no idea how to investigate this. When one of the functions that create "scoped" Lisp objects aborts, the first thing to look at is the addresses of the stack variables: if they are not 8-byte aligned, that's the reason. For example: > #1 0x01173d6b in die (msg=0x14bb004 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14baf34 "lisp.h", line=926) at alloc.c:7111 See the address of 'msg'? It's clearly aligned on a 4-byte boundary. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 14:44 ` Eli Zaretskii @ 2014-09-30 15:58 ` martin rudalics 2014-09-30 16:07 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2014-09-30 15:58 UTC (permalink / raw) To: Eli Zaretskii; +Cc: andrewjmoreton, emacs-devel > When one of the functions that create "scoped" Lisp objects aborts, > the first thing to look at is the addresses of the stack variables: > if they are not 8-byte aligned, that's the reason. For example: > >> #1 0x01173d6b in die (msg=0x14bb004 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14baf34 "lisp.h", line=926) at alloc.c:7111 > > See the address of 'msg'? It's clearly aligned on a 4-byte boundary. I wouldn't even have known that 0x14bb004 denotes a stack address. And then look whether it ends with "4" or "C" ... Thanks, martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 15:58 ` martin rudalics @ 2014-09-30 16:07 ` Eli Zaretskii 2014-09-30 16:24 ` martin rudalics 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 16:07 UTC (permalink / raw) To: martin rudalics; +Cc: andrewjmoreton, emacs-devel > Date: Tue, 30 Sep 2014 17:58:18 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: andrewjmoreton@gmail.com, emacs-devel@gnu.org > > > When one of the functions that create "scoped" Lisp objects aborts, > > the first thing to look at is the addresses of the stack variables: > > if they are not 8-byte aligned, that's the reason. For example: > > > >> #1 0x01173d6b in die (msg=0x14bb004 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14baf34 "lisp.h", line=926) at alloc.c:7111 > > > > See the address of 'msg'? It's clearly aligned on a 4-byte boundary. > > I wouldn't even have known that 0x14bb004 denotes a stack address. You know that by looking at the source, where 'die' is called. The variable that is passed as the 1st argument to 'die' is a local variable in the function that calls 'die', so it is on the stack. > And then look whether it ends with "4" or "C" ... I didn't mean to say you should have known. I explained this so you could do that in the future. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 16:07 ` Eli Zaretskii @ 2014-09-30 16:24 ` martin rudalics 0 siblings, 0 replies; 17+ messages in thread From: martin rudalics @ 2014-09-30 16:24 UTC (permalink / raw) To: Eli Zaretskii; +Cc: andrewjmoreton, emacs-devel > I didn't mean to say you should have known. I explained this so you > could do that in the future. OK. I'll try to do that from now on. Thanks again, martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 13:01 ` Andy Moreton 2014-09-30 13:51 ` martin rudalics @ 2014-09-30 14:02 ` Eli Zaretskii 1 sibling, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 14:02 UTC (permalink / raw) To: Andy Moreton; +Cc: emacs-devel > From: Andy Moreton <andrewjmoreton@gmail.com> > Date: Tue, 30 Sep 2014 14:01:46 +0100 > > mingw32 32bit and mingw64 64bit builds work for me at trunk r117982. For me as well, but that's by sheer luck. The immediate cause of the assertion violation is that we try to create a Lisp object on the stack, and the stack is not 8-byte aligned, because we are in a separate thread started by CreateThread, where the x86 32-bit ABI does not guarantee more than 4-byte alignment. But the real problem is that we shouldn't be creating Lisp objects at all in any thread but the main one, because that's non-reentrant. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 8:25 Current trunk aborts with MinGW martin rudalics 2014-09-30 13:01 ` Andy Moreton @ 2014-09-30 13:59 ` Eli Zaretskii 2014-09-30 14:11 ` martin rudalics 2014-09-30 14:33 ` Stefan Monnier 2 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 13:59 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel > 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); } ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 13:59 ` Eli Zaretskii @ 2014-09-30 14:11 ` martin rudalics 2014-09-30 14:36 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2014-09-30 14:11 UTC (permalink / raw) To: Eli Zaretskii; +Cc: emacs-devel > 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. Thank you, works now. martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 14:11 ` martin rudalics @ 2014-09-30 14:36 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 14:36 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel > Date: Tue, 30 Sep 2014 16:11:56 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: emacs-devel@gnu.org > > > 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. > > Thank you, works now. Thanks for testing (and we are lucky you saw this in the first place). ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 8:25 Current trunk aborts with MinGW martin rudalics 2014-09-30 13:01 ` Andy Moreton 2014-09-30 13:59 ` Eli Zaretskii @ 2014-09-30 14:33 ` Stefan Monnier 2014-09-30 14:42 ` Eli Zaretskii 2 siblings, 1 reply; 17+ messages in thread From: Stefan Monnier @ 2014-09-30 14:33 UTC (permalink / raw) To: martin rudalics; +Cc: emacs-devel > A MinGW build of current trunk aborts here as follows: So all that work on optimizing the code did pay off, in the end. Stefan ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 14:33 ` Stefan Monnier @ 2014-09-30 14:42 ` Eli Zaretskii 2014-09-30 15:57 ` martin rudalics 0 siblings, 1 reply; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 14:42 UTC (permalink / raw) To: Stefan Monnier; +Cc: rudalics, emacs-devel > From: Stefan Monnier <monnier@iro.umontreal.ca> > Date: Tue, 30 Sep 2014 10:33:35 -0400 > Cc: emacs-devel <emacs-devel@gnu.org> > > > A MinGW build of current trunk aborts here as follows: > > So all that work on optimizing the code did pay off, in the end. Yep, definitely. (I just couldn't believe my eyes when I saw in Martin's backtrace make_lisp_ptr being called from w32_msg_pump.) We could also add a test to functions which allocate memory for Lisp objects that they are called in the main thread. Patches for that are welcome. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 14:42 ` Eli Zaretskii @ 2014-09-30 15:57 ` martin rudalics 2014-09-30 17:41 ` Eli Zaretskii 0 siblings, 1 reply; 17+ messages in thread From: martin rudalics @ 2014-09-30 15:57 UTC (permalink / raw) To: Eli Zaretskii, Stefan Monnier; +Cc: emacs-devel > We could also add a test to functions which allocate memory for Lisp > objects that they are called in the main thread. Patches for that are > welcome. Very welcome, indeed. martin ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: Current trunk aborts with MinGW 2014-09-30 15:57 ` martin rudalics @ 2014-09-30 17:41 ` Eli Zaretskii 0 siblings, 0 replies; 17+ messages in thread From: Eli Zaretskii @ 2014-09-30 17:41 UTC (permalink / raw) To: martin rudalics; +Cc: monnier, emacs-devel > Date: Tue, 30 Sep 2014 17:57:46 +0200 > From: martin rudalics <rudalics@gmx.at> > CC: emacs-devel@gnu.org > > > We could also add a test to functions which allocate memory for Lisp > > objects that they are called in the main thread. Patches for that are > > welcome. > > Very welcome, indeed. The thread ID of the main thread is recorded in the variable dwMainThreadId, and the ID of the current thread can be obtained by calling GetCurrentThreadId. If dwMainThreadId is zero, it either was not yet initialized, or we are running in batch mode, where this variable is never set (because Emacs runs single-threaded in batch mode); in both cases, the test should be bypassed. I think using the above info, adding such a test should be easy. Volunteers are welcome. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2014-09-30 17:41 UTC | newest] Thread overview: 17+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 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 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
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.