* Re: MS-Windows tester wanted for trunk
2014-09-16 8:50 MS-Windows tester wanted for trunk Dmitry Antipov
@ 2014-09-16 13:10 ` Chris Zheng
2014-09-16 14:48 ` Eli Zaretskii
2014-09-16 14:31 ` MS-Windows tester wanted for trunk Eli Zaretskii
2014-09-16 14:38 ` Eli Zaretskii
2 siblings, 1 reply; 18+ messages in thread
From: Chris Zheng @ 2014-09-16 13:10 UTC (permalink / raw)
To: dmantipov; +Cc: emacs-devel
From: Dmitry Antipov <dmantipov@yandex.ru>
Subject: MS-Windows tester wanted for trunk
Date: Tue, 16 Sep 2014 12:50:00 +0400
Hi Dmitry,
> 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 have compiled the trunk under your instructions with MSYS2/MinGW-w64
toolchain. The build process runs smoothly expect crash when compile
lisp/erc/erc-xdcc.el. Running emacs.exe with
-Q --eval '(byte-compile-file "Z:\\build-emacs/lisp/erc/erc-xdcc.el")'
under gdb I get the following backtrace. Is this information
sufficient or should I file a bug report?
(gdb) bt
#0 0x0000000456ac7198 in ?? ()
#1 0x00000004001e8378 in __fu0_log () at floatfns.c:249
#2 0x00000004001e4f09 in Ffuncall (nargs=2, args=0x839bf8) at eval.c:2729
#3 0x0000000400234678 in exec_byte_code (bytestr=66180385, vector=64308597,
maxdepth=20, args_template=17187632874, nargs=0, args=0x0)
at bytecode.c:920
#4 0x00000004002337dc in Fbyte_code (bytestr=66180385, vector=64308597,
maxdepth=20) at bytecode.c:486
#5 0x00000004001e3848 in eval_sub (form=90082966) at eval.c:2187
#6 0x00000004001df3d6 in Fdefconst (args=90083222) at eval.c:812
#7 0x00000004001e34aa in eval_sub (form=90083238) at eval.c:2129
#8 0x0000000400219730 in readevalloop (readcharfun=17187760522,
stream=0x7fe56b2e2a0 <msvcrt!_iob+144>, sourcename=45541713,
printflag=false, unibyte=17187632874, readfun=17187632874,
start=17187632874, end=17187632874) at lread.c:1968
#9 0x0000000400217bb1 in Fload (file=65249313, noerror=17187632874,
nomessage=17187632930, nosuffix=17187632874, must_suffix=17187632930)
at lread.c:1363
#10 0x00000004001f2d3f in Frequire (feature=65224898, filename=17187632874,
noerror=17187632874) at fns.c:2923
#11 0x00000004001e4f35 in Ffuncall (nargs=2, args=0x83adb0) at eval.c:2733
#12 0x00000004001e3d6f in Fapply (nargs=2, args=0x83adb0) at eval.c:2295
#13 0x00000004001e4d9c in Ffuncall (nargs=3, args=0x83ada8) at eval.c:2706
#14 0x0000000400234678 in exec_byte_code (bytestr=45205169,
vector=17191185829, maxdepth=28, args_template=1028, nargs=1,
args=0x83b328) at bytecode.c:920
#15 0x00000004001e5753 in funcall_lambda (fun=17191424837, nargs=1,
arg_vector=0x83b320) at eval.c:2894
#16 0x00000004001e50f9 in Ffuncall (nargs=2, args=0x83b318) at eval.c:2775
#17 0x0000000400234678 in exec_byte_code (bytestr=45193761,
vector=17191420573, maxdepth=16, args_template=1028, nargs=1,
args=0x83b890) at bytecode.c:920
#18 0x00000004001e5753 in funcall_lambda (fun=17191420621, nargs=1,
arg_vector=0x83b888) at eval.c:2894
#19 0x00000004001e50f9 in Ffuncall (nargs=2, args=0x83b880) at eval.c:2775
#20 0x0000000400234678 in exec_byte_code (bytestr=45193441,
vector=17191420429, maxdepth=20, args_template=1028, nargs=1,
args=0x83be08) at bytecode.c:920
#21 0x00000004001e5753 in funcall_lambda (fun=17191420477, nargs=1,
arg_vector=0x83be00) at eval.c:2894
#22 0x00000004001e50f9 in Ffuncall (nargs=2, args=0x83bdf8) at eval.c:2775
#23 0x0000000400234678 in exec_byte_code (bytestr=17188106945,
vector=17191042261, maxdepth=40, args_template=2056, nargs=2,
args=0x83c3a8) at bytecode.c:920
#24 0x00000004001e5753 in funcall_lambda (fun=17191042365, nargs=2,
arg_vector=0x83c398) at eval.c:2894
#25 0x00000004001e50f9 in Ffuncall (nargs=3, args=0x83c390) at eval.c:2775
#26 0x0000000400234678 in exec_byte_code (bytestr=45193313,
vector=17189783869, maxdepth=16, args_template=1028, nargs=1,
args=0x83c910) at bytecode.c:920
#27 0x00000004001e5753 in funcall_lambda (fun=17191420525, nargs=1,
arg_vector=0x83c908) at eval.c:2894
#28 0x00000004001e50f9 in Ffuncall (nargs=2, args=0x83c900) at eval.c:2775
#29 0x0000000400234678 in exec_byte_code (bytestr=63770705,
vector=17191351109, maxdepth=16, args_template=0, nargs=0, args=0x83ce70)
at bytecode.c:920
#30 0x00000004001e5753 in funcall_lambda (fun=17191358533, nargs=0,
arg_vector=0x83ce70) at eval.c:2894
#31 0x00000004001e50f9 in Ffuncall (nargs=1, args=0x83ce68) at eval.c:2775
#32 0x0000000400234678 in exec_byte_code (bytestr=63795057,
vector=17191021837, maxdepth=4, args_template=0, nargs=0, args=0x83d3d8)
at bytecode.c:920
#33 0x00000004001e5753 in funcall_lambda (fun=17191437581, nargs=0,
arg_vector=0x83d3d8) at eval.c:2894
#34 0x00000004001e50f9 in Ffuncall (nargs=1, args=0x83d3d0) at eval.c:2775
#35 0x00000004001e36a4 in eval_sub (form=17192395654) at eval.c:2153
#36 0x00000004001e105b in internal_lisp_condition_case (var=63928594,
bodyform=17192395654, handlers=17192395382) at eval.c:1319
#37 0x0000000400235b4f in exec_byte_code (bytestr=63770161,
vector=17191407877, maxdepth=64, args_template=1028, nargs=1,
args=0x83dc38) at bytecode.c:1163
#38 0x00000004001e5753 in funcall_lambda (fun=17191408413, nargs=1,
arg_vector=0x83dc30) at eval.c:2894
#39 0x00000004001e50f9 in Ffuncall (nargs=2, args=0x83dc28) at eval.c:2775
#40 0x0000000400234678 in exec_byte_code (bytestr=45313569,
vector=17191144229, maxdepth=68, args_template=2052, nargs=1,
args=0x83e0c8) at bytecode.c:920
#41 0x00000004001e5753 in funcall_lambda (fun=17191400021, nargs=1,
arg_vector=0x83e0c0) at eval.c:2894
#42 0x00000004001e543c in apply_lambda (fun=17191400021, args=63552278)
at eval.c:2835
#43 0x00000004001e39e2 in eval_sub (form=63552262) at eval.c:2226
#44 0x00000004001e2de4 in Feval (form=63552262, lexical=17187632874)
at eval.c:1999
#45 0x00000004001e4f09 in Ffuncall (nargs=2, args=0x83e4c8) at eval.c:2729
#46 0x0000000400234678 in exec_byte_code (bytestr=17183593361,
vector=17183593397, maxdepth=92, args_template=1028, nargs=1,
args=0x83ea68) at bytecode.c:920
#47 0x00000004001e5753 in funcall_lambda (fun=17183593317, nargs=1,
arg_vector=0x83ea60) at eval.c:2894
#48 0x00000004001e50f9 in Ffuncall (nargs=2, args=0x83ea58) at eval.c:2775
#49 0x0000000400234678 in exec_byte_code (bytestr=17183567681,
vector=17183567717, maxdepth=68, args_template=0, nargs=0, args=0x83f038)
at bytecode.c:920
#50 0x00000004001e5753 in funcall_lambda (fun=17183567637, nargs=0,
arg_vector=0x83f038) at eval.c:2894
#51 0x00000004001e50f9 in Ffuncall (nargs=1, args=0x83f030) at eval.c:2775
#52 0x0000000400234678 in exec_byte_code (bytestr=17183564233,
vector=17183564269, maxdepth=48, args_template=0, nargs=0, args=0x83f4e0)
at bytecode.c:920
#53 0x00000004001e5753 in funcall_lambda (fun=17183564189, nargs=0,
arg_vector=0x83f4e0) at eval.c:2894
#54 0x00000004001e543c in apply_lambda (fun=17183564189, args=17187632874)
at eval.c:2835
#55 0x00000004001e39e2 in eval_sub (form=17187938854) at eval.c:2226
#56 0x00000004001e2de4 in Feval (form=17187938854, lexical=17187632874)
at eval.c:1999
#57 0x0000000400133c9f in top_level_2 () at keyboard.c:1205
#58 0x00000004001e11f1 in internal_condition_case (
bfun=0x400133c77 <top_level_2>, handlers=17187704418,
hfun=0x400133612 <cmd_error>) at eval.c:1350
#59 0x0000000400133cee in top_level_1 (ignore=17187632874) at keyboard.c:1213
#60 0x00000004001e0527 in internal_catch (tag=17187699682,
func=0x400133ca5 <top_level_1>, arg=17187632874) at eval.c:1111
#61 0x0000000400133bbd in command_loop () at keyboard.c:1174
#62 0x0000000400133070 in recursive_edit_1 () at keyboard.c:785
#63 0x00000004001332a5 in Frecursive_edit () at keyboard.c:856
#64 0x0000000400130833 in main (argc=4, argv=0x9854e0) at emacs.c:1642
Lisp Backtrace:
"log" (0x839c00)
"byte-code" (0x83a020)
"defconst" (0x83a268)
"require" (0x83adb8)
"apply" (0x83adb0)
"byte-compile-file-form-require" (0x83b320)
"byte-compile-file-form" (0x83b888)
0xb04238 PVEC_COMPILED
"byte-compile-recurse-toplevel" (0x83c398)
"byte-compile-toplevel-file-form" (0x83c908)
0xaf5040 PVEC_COMPILED
0xb08508 PVEC_COMPILED
"funcall" (0x83d3d0)
"byte-compile-from-buffer" (0x83dc30)
"byte-compile-file" (0x83e0c0)
"eval" (0x83e4d0)
"command-line-1" (0x83ea60)
"command-line" (0x83f038)
"normal-top-level" (0x83f4e0)
> Thanks in advance,
> Dmitry
>
Best wishes,
Chris
^ permalink raw reply [flat|nested] 18+ messages in thread* Re: MS-Windows tester wanted for trunk
2014-09-16 8:50 MS-Windows tester wanted for trunk Dmitry Antipov
2014-09-16 13:10 ` Chris Zheng
@ 2014-09-16 14:31 ` Eli Zaretskii
2014-09-16 15:24 ` Dmitry Antipov
2014-09-16 15:46 ` Dmitry Antipov
2014-09-16 14:38 ` Eli Zaretskii
2 siblings, 2 replies; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-16 14:31 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Tue, 16 Sep 2014 12:50:00 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
>
> 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 <VALMASK+212> "XTYPE (a) == type && XUNTAG (a, type) == ptr", file=0x14bdc54 <VALMASK+4> "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 <dumped_data+2441424>,
font_spec=22562829, opentype_only=1) at w32font.c:833
#18 0x012297f9 in uniscribe_list (f=0x17bb2b0 <dumped_data+2441424>,
font_spec=22562829) at w32uniscribe.c:74
#19 0x011a7839 in font_list_entities (f=0x17bb2b0 <dumped_data+2441424>,
spec=24884317) at font.c:2804
#20 0x011a9560 in font_find_for_lface (f=0x17bb2b0 <dumped_data+2441424>,
attrs=0x88e5b4, spec=24884261, c=-1) at font.c:3281
#21 0x011a9883 in font_load_for_lface (f=0x17bb2b0 <dumped_data+2441424>,
attrs=0x88e5b4, spec=24884261) at font.c:3354
#22 0x011a99f2 in font_open_by_spec (f=0x17bb2b0 <dumped_data+2441424>,
spec=24884261) at font.c:3416
#23 0x011a9a30 in font_open_by_name (f=0x17bb2b0 <dumped_data+2441424>,
name=93516529) at font.c:3432
#24 0x01206706 in x_default_font_parameter (
f=0x17bb2b0 <dumped_data+2441424>, 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 <pure+271525>) 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 <pure+599125>) 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 <pure+596677>) 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 <top_level_2>,
handlers=22507210, hfun=0x10feeb6 <cmd_error>) 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 <top_level_1>,
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 <VALMASK+212> "XTYPE (a) == type && XUNTAG (a, type) == ptr",
file=0x14bdc54 <VALMASK+4> "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.
^ permalink raw reply [flat|nested] 18+ messages in thread