From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: MS-Windows tester wanted for trunk Date: Tue, 16 Sep 2014 17:31:02 +0300 Message-ID: <83r3zb4oyh.fsf@gnu.org> References: <5417F9B8.9020503@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1410877908 17807 80.91.229.3 (16 Sep 2014 14:31:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Sep 2014 14:31:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 16 16:31:40 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XTtn8-0006zk-9E for ged-emacs-devel@m.gmane.org; Tue, 16 Sep 2014 16:31:38 +0200 Original-Received: from localhost ([::1]:38361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTtn7-0001et-RB for ged-emacs-devel@m.gmane.org; Tue, 16 Sep 2014 10:31:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52714) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTtmp-0001el-F5 for emacs-devel@gnu.org; Tue, 16 Sep 2014 10:31:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTtmg-0007Ui-K5 for emacs-devel@gnu.org; Tue, 16 Sep 2014 10:31:19 -0400 Original-Received: from mtaout28.012.net.il ([80.179.55.184]:46197) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTtmg-0007U4-5w for emacs-devel@gnu.org; Tue, 16 Sep 2014 10:31:10 -0400 Original-Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il (HyperSendmail v2007.08) id <0NC000P000888200@mtaout28.012.net.il> for emacs-devel@gnu.org; Tue, 16 Sep 2014 17:29:59 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NC000OKQ09ZW900@mtaout28.012.net.il>; Tue, 16 Sep 2014 17:29:59 +0300 (IDT) In-reply-to: <5417F9B8.9020503@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.184 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:174361 Archived-At: > Date: Tue, 16 Sep 2014 12:50:00 +0400 > From: Dmitry Antipov > > I have a plan to make USE_STACK_LISP_OBJECTS the default if ENABLE_CHECKING > in a week or so. On GNU/Linux, now I'm sure that there are no silly crashes, > and I would like to be sure on MS-Windows too. So I need help from someone > who can 1) bootstrap trunk revision >= 117888 with --enable-checking and > CPPFLAGS='-DUSE_STACK_LISP_OBJECTS -DGC_CHECK_MARKED_OBJECTS' and 2) check > whether the very basic editing doesn't cause crash. I tried this in the 32-bit Windows build. (I don't have 64-bit tools installed, so someone else will have to -- and should -- try that.) It builds and passes the test suite, but hits assertion violation during startup of a GUI session: lisp.h:930: Emacs fatal error: assertion failed: XTYPE (a) == type && XUNTAG (a, type) == ptr 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 0x01170998 in die ( msg=0x14bdd24 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14bdc54 "lisp.h", line=930) at alloc.c:7166 #2 0x010f751d in make_lisp_ptr (ptr=0x88da44, type=Lisp_Cons) at lisp.h:930 #3 0x011f334c in Fput_text_property (start=4, end=48, property=22521946, value=23735010, object=23762205) at textprop.c:1323 #4 0x010c095f in produce_charset (coding=0x88dce0, charbuf=0x88db0c, pos=12) at coding.c:7276 #5 0x010c0a0e in produce_annotation (coding=0x88dce0, pos=12) at coding.c:7319 #6 0x010c0dc6 in decode_coding (coding=0x88dce0) at coding.c:7414 #7 0x010c36b4 in decode_coding_object (coding=0x88dce0, src_object=93516561, from=0, from_byte=0, to=11, to_byte=11, dst_object=22453674) at coding.c:8140 #8 0x010c7c19 in code_convert_string (string=93516561, coding_system=23735042, dst_object=22453674, encodep=false, nocopy=false, norecord=true) at coding.c:9482 #9 0x010c7cb0 in code_convert_string_norecord (string=93516561, coding_system=23735042, encodep=false) at coding.c:9502 #10 0x01211a99 in intern_font_name (string=0x88e22c "Courier New") at w32font.c:289 #11 0x01213032 in w32_enumfont_pattern_entity (frame=24883893, logical_font=0x88e210, physical_font=0x88e028, font_type=4, requested_font=0x88e3cc, backend=22618330) at w32font.c:1085 #12 0x01213bf4 in add_font_entity_to_list (logical_font=0x88e210, physical_font=0x88e028, font_type=4, lParam=8971212) at w32font.c:1500 #13 0x752b247a in GDI32!CreateDIBPatternBrush () from C:\Windows\syswow64\gdi32.dll #14 0x752b23e3 in GDI32!CreateDIBPatternBrush () from C:\Windows\syswow64\gdi32.dll #15 0x752b259c in GDI32!EnumFontFamiliesExA () from C:\Windows\syswow64\gdi32.dll #16 0x752b256d in GDI32!EnumFontFamiliesExA () from C:\Windows\syswow64\gdi32.dll #17 0x012127ae in w32font_list_internal (f=0x17bb2b0 , font_spec=22562829, opentype_only=1) at w32font.c:833 #18 0x012297f9 in uniscribe_list (f=0x17bb2b0 , font_spec=22562829) at w32uniscribe.c:74 #19 0x011a7839 in font_list_entities (f=0x17bb2b0 , spec=24884317) at font.c:2804 #20 0x011a9560 in font_find_for_lface (f=0x17bb2b0 , attrs=0x88e5b4, spec=24884261, c=-1) at font.c:3281 #21 0x011a9883 in font_load_for_lface (f=0x17bb2b0 , attrs=0x88e5b4, spec=24884261) at font.c:3354 #22 0x011a99f2 in font_open_by_spec (f=0x17bb2b0 , spec=24884261) at font.c:3416 #23 0x011a9a30 in font_open_by_name (f=0x17bb2b0 , name=93516529) at font.c:3432 #24 0x01206706 in x_default_font_parameter ( f=0x17bb2b0 , parms=23986990) at w32fns.c:4382 #25 0x01206ebf in Fx_create_frame (parameters=23986990) at w32fns.c:4546 #26 0x0118f489 in Ffuncall (nargs=2, args=0x88e7e4) at eval.c:2726 #27 0x011d128c in exec_byte_code (bytestr=19697361, vector=19697381, maxdepth=16, args_template=22453642, nargs=0, args=0x0) at bytecode.c:920 #28 0x01190032 in funcall_lambda (fun=19697333, nargs=1, arg_vector=0x12c8ee5 ) at eval.c:2960 #29 0x0118f6c5 in Ffuncall (nargs=2, args=0x88eb24) at eval.c:2775 #30 0x011d128c in exec_byte_code (bytestr=20024961, vector=20024981, maxdepth=20, args_template=22453642, nargs=0, args=0x0) at bytecode.c:920 #31 0x01190032 in funcall_lambda (fun=20024933, nargs=1, arg_vector=0x1318e95 ) at eval.c:2960 #32 0x0118f6c5 in Ffuncall (nargs=2, args=0x88ee64) at eval.c:2775 #33 0x011d128c in exec_byte_code (bytestr=20022513, vector=20022533, maxdepth=24, args_template=22453642, nargs=0, args=0x0) at bytecode.c:920 #34 0x01190032 in funcall_lambda (fun=20022493, nargs=0, arg_vector=0x1318505 ) at eval.c:2960 #35 0x0118f6c5 in Ffuncall (nargs=1, args=0x88f1a4) at eval.c:2775 #36 0x011d128c in exec_byte_code (bytestr=19717209, vector=19717229, maxdepth=68, args_template=0, nargs=0, args=0x88f51c) at bytecode.c:920 #37 0x0118fc6e in funcall_lambda (fun=19717189, nargs=0, arg_vector=0x88f51c) at eval.c:2894 #38 0x0118f6c5 in Ffuncall (nargs=1, args=0x88f518) at eval.c:2775 #39 0x011d128c in exec_byte_code (bytestr=19715473, vector=19715493, maxdepth=48, args_template=0, nargs=0, args=0x88f7c0) at bytecode.c:920 #40 0x0118fc6e in funcall_lambda (fun=19715453, nargs=0, arg_vector=0x88f7c0) at eval.c:2894 #41 0x0118f98d in apply_lambda (fun=19715453, args=22453642) at eval.c:2835 #42 0x0118e3e7 in eval_sub (form=23582334) at eval.c:2226 #43 0x0118da07 in Feval (form=23582334, lexical=22453642) at eval.c:1999 #44 0x010ff33b in top_level_2 () at keyboard.c:1205 #45 0x0118c468 in internal_condition_case (bfun=0x10ff31e , handlers=22507210, hfun=0x10feeb6 ) at eval.c:1350 #46 0x010ff36f in top_level_1 (ignore=22453642) at keyboard.c:1213 #47 0x0118ba00 in internal_catch (tag=22504570, func=0x10ff33d , arg=22453642) at eval.c:1111 #48 0x010ff2a1 in command_loop () at keyboard.c:1174 #49 0x010fea53 in recursive_edit_1 () at keyboard.c:785 #50 0x010fec0f in Frecursive_edit () at keyboard.c:856 #51 0x010fcb2c in main (argc=2, argv=0xcd20a0) at emacs.c:1642 Lisp Backtrace: "x-create-frame" (0x88e7e8) "x-create-frame-with-faces" (0x88eb28) "make-frame" (0x88ee68) "frame-initialize" (0x88f1a8) "command-line" (0x88f51c) "normal-top-level" (0x88f7c0) (gdb) up #1 0x01170998 in die ( msg=0x14bdd24 "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14bdc54 "lisp.h", line=930) at alloc.c:7166 7166 terminate_due_to_signal (SIGABRT, INT_MAX); (gdb) #2 0x010f751d in make_lisp_ptr (ptr=0x88da44, type=Lisp_Cons) at lisp.h:930 930 eassert (XTYPE (a) == type && XUNTAG (a, type) == ptr); (gdb) p a $1 = 8968774 (gdb) xtype Lisp_Cons (gdb) p XUNTAG(a,Lisp_Cons) $2 = (void *) 0x88da40 (gdb) The -nw session does work. This page: http://www.peterstock.co.uk/games/mingw_sse/ seems to suggest it's a problem with our functions that are used as callbacks: GCC aligns the stack to 16-byte alignment once at startup, and assumes that this remains in effect for the duration of the program. But when our function is called as a callback from a Windows DLL, that alignment could be disrupted, since Windows itself doesn't guarantee such a high alignment, it only specifies 4-byte alignment. So, as suggested by that page, I marked the callback functions in w32font.c with '__attribute__((force_align_arg_pointer))', and then Emacs comes up normally. This attribute is available in GCC since v4.2. So the conclusion is that, at least for 32-bit Windows builds, the alignment of union Aligned_Cons is not enough to produce the effect you want, and additional measures are necessary. I don't expect this to be a problem in 64-bit Windows builds, because there Windows does enforce 16-byte alignment of the stack. But, as I already said, I didn't test that. This could be an issue in other x86 32-bit builds (probably not on GNU/Linux, though, and not if GCC is the compiler), because AFAIK the x86 ABI specifies a 4-byte stack alignment.