* MS-Windows tester wanted for trunk
@ 2014-09-16 8:50 Dmitry Antipov
2014-09-16 13:10 ` Chris Zheng
` (2 more replies)
0 siblings, 3 replies; 18+ messages in thread
From: Dmitry Antipov @ 2014-09-16 8:50 UTC (permalink / raw
To: Emacs development discussions
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.
Thanks in advance,
Dmitry
^ 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: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
* 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 ` MS-Windows tester wanted for trunk Eli Zaretskii
@ 2014-09-16 14:38 ` Eli Zaretskii
2 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-16 14:38 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.
I'd suggest to make this opt-out feature instead. If you make it
opt-in, you risk missing problems on some configurations used by a
small number of people who don't build with --enable-checking.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 13:10 ` Chris Zheng
@ 2014-09-16 14:48 ` Eli Zaretskii
2014-09-16 14:54 ` Chris Zheng
2014-09-16 14:56 ` Chris Zheng
0 siblings, 2 replies; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-16 14:48 UTC (permalink / raw
To: Chris Zheng; +Cc: dmantipov, emacs-devel
> Date: Tue, 16 Sep 2014 21:10:33 +0800
> From: Chris Zheng <chriszheng99@gmail.com>
> Cc: emacs-devel@gnu.org
>
> 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.
Crashes with which signal? GDB should announce that when you run
under it.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 14:48 ` Eli Zaretskii
@ 2014-09-16 14:54 ` Chris Zheng
2014-09-16 14:56 ` Chris Zheng
1 sibling, 0 replies; 18+ messages in thread
From: Chris Zheng @ 2014-09-16 14:54 UTC (permalink / raw
To: eliz; +Cc: dmantipov, emacs-devel
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: MS-Windows tester wanted for trunk
Date: Tue, 16 Sep 2014 17:48:04 +0300
> Crashes with which signal? GDB should announce that when you run
> under it.
Oh, my fault. Here it is.
Program received signal SIGSEGV, Segmentation fault.
0x0000000456ac7198 in ?? ()
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 14:48 ` Eli Zaretskii
2014-09-16 14:54 ` Chris Zheng
@ 2014-09-16 14:56 ` Chris Zheng
2014-09-16 15:10 ` Eli Zaretskii
1 sibling, 1 reply; 18+ messages in thread
From: Chris Zheng @ 2014-09-16 14:56 UTC (permalink / raw
To: eliz; +Cc: dmantipov, emacs-devel
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: MS-Windows tester wanted for trunk
Date: Tue, 16 Sep 2014 17:48:04 +0300
> Crashes with which signal? GDB should announce that when you run
> under it.
Oh, my fault. Here it is.
Program received signal SIGSEGV, Segmentation fault.
0x0000000456ac7198 in ?? ()
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 14:56 ` Chris Zheng
@ 2014-09-16 15:10 ` Eli Zaretskii
2014-09-17 9:28 ` Chris Zheng
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-16 15:10 UTC (permalink / raw
To: Chris Zheng; +Cc: dmantipov, emacs-devel
> Date: Tue, 16 Sep 2014 22:56:37 +0800
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> From: Chris Zheng <chriszheng99@gmail.com>
>
> From: Eli Zaretskii <eliz@gnu.org>
> Subject: Re: MS-Windows tester wanted for trunk
> Date: Tue, 16 Sep 2014 17:48:04 +0300
>
> > Crashes with which signal? GDB should announce that when you run
> > under it.
>
> Oh, my fault. Here it is.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0000000456ac7198 in ?? ()
OK. If you continue (e.g., with "make -k"), does it succeed to finish
the bootstrap, and if so, can you start a session and evaluate the
problematic code, the one that called 'log', in the scratch buffer?
Also, any idea where did that __fu0_log come from?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 14:31 ` MS-Windows tester wanted for trunk Eli Zaretskii
@ 2014-09-16 15:24 ` Dmitry Antipov
2014-09-16 15:58 ` Eli Zaretskii
2014-09-16 15:46 ` Dmitry Antipov
1 sibling, 1 reply; 18+ messages in thread
From: Dmitry Antipov @ 2014-09-16 15:24 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
On 09/16/2014 06:31 PM, Eli Zaretskii wrote:
> 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.
Do we have the same issue with alloca? If not, whether it will be
simpler to define scoped_cons to local_cons for 32-bit Windows builds?
> 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.
Hm...I'll try 32-bit builds with clang and icc. BTW, both of them mimics
GCC quite well, so I will be very surprised with an issues here.
Dmitry
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 14:31 ` MS-Windows tester wanted for trunk Eli Zaretskii
2014-09-16 15:24 ` Dmitry Antipov
@ 2014-09-16 15:46 ` Dmitry Antipov
2014-09-16 16:03 ` Eli Zaretskii
1 sibling, 1 reply; 18+ messages in thread
From: Dmitry Antipov @ 2014-09-16 15:46 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
On 09/16/2014 06:31 PM, Eli Zaretskii wrote:
> 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.
From GCC manual, as of 4.8:
-mstackrealign
Realign the stack at entry. On the Intel x86, the -mstackrealign option generates an alternate prologue and epilogue
that realigns the run-time stack if necessary. This supports mixing legacy codes that keep 4-byte stack alignment with
modern codes that keep 16-byte stack alignment for SSE compatibility. See also the attribute
"force_align_arg_pointer", applicable to individual functions.
Dmitry
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 15:24 ` Dmitry Antipov
@ 2014-09-16 15:58 ` Eli Zaretskii
2014-09-16 20:40 ` Ken Brown
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-16 15:58 UTC (permalink / raw
To: Dmitry Antipov, Ken Brown; +Cc: emacs-devel
> Date: Tue, 16 Sep 2014 19:24:28 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> On 09/16/2014 06:31 PM, Eli Zaretskii wrote:
>
> > 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.
>
> Do we have the same issue with alloca?
No, not as long as our functions are called only by our functions, not
as callbacks from Windows DLLs.
> If not, whether it will be simpler to define scoped_cons to
> local_cons for 32-bit Windows builds?
You'll have to educate me about the difference, sorry. I can try
whatever you want.
> > 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.
>
> Hm...I'll try 32-bit builds with clang and icc. BTW, both of them mimics
> GCC quite well, so I will be very surprised with an issues here.
I think the 32-bit Cygwin-w32 build might also be affected, as it uses
the same w32font.c code. Ken, can you try that, please?
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 15:46 ` Dmitry Antipov
@ 2014-09-16 16:03 ` Eli Zaretskii
0 siblings, 0 replies; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-16 16:03 UTC (permalink / raw
To: Dmitry Antipov; +Cc: emacs-devel
> Date: Tue, 16 Sep 2014 19:46:27 +0400
> From: Dmitry Antipov <dmantipov@yandex.ru>
> CC: emacs-devel@gnu.org
>
> On 09/16/2014 06:31 PM, Eli Zaretskii wrote:
>
> > 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.
>
> From GCC manual, as of 4.8:
>
> -mstackrealign
>
> Realign the stack at entry.
That's the other solution suggested by the URL I cited. But it's too
expensive: it adds the realignment overhead to _every_ function call.
By contrast, the number of callback functions we have is quite small,
and even if we decorate all of them with force_align_arg_pointer
(which isn't strictly necessary, AFAIU, since most of them don't cons
Lisp data), that's just a handful of functions that are not
performance-critical.
Is it possible to prevent this problem by using an intermediate local
variable with a suitable alignment (sorry if this is a silly question,
but I have only a very vague idea about alignment).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 15:58 ` Eli Zaretskii
@ 2014-09-16 20:40 ` Ken Brown
0 siblings, 0 replies; 18+ messages in thread
From: Ken Brown @ 2014-09-16 20:40 UTC (permalink / raw
To: Eli Zaretskii, Dmitry Antipov; +Cc: emacs-devel
On 9/16/2014 11:58 AM, Eli Zaretskii wrote:
> I think the 32-bit Cygwin-w32 build might also be affected, as it uses
> the same w32font.c code. Ken, can you try that, please?
It starts up and seems to run fine. I'll give it a more thorough test
later, but so far I think it's OK.
Ken
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-16 15:10 ` Eli Zaretskii
@ 2014-09-17 9:28 ` Chris Zheng
2014-09-17 10:03 ` Eli Zaretskii
0 siblings, 1 reply; 18+ messages in thread
From: Chris Zheng @ 2014-09-17 9:28 UTC (permalink / raw
To: eliz; +Cc: dmantipov, emacs-devel
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: MS-Windows tester wanted for trunk
Date: Tue, 16 Sep 2014 18:10:17 +0300
Hi Eli,
> OK. If you continue (e.g., with "make -k"), does it succeed to finish
> the bootstrap, and if so, can you start a session and evaluate the
> problematic code, the one that called 'log', in the scratch buffer?
Thanks for your hints. I have located the crash was coused by
`(ceiling (/ (ceiling (/ (log value) (log 2))) 8.0))' in
/lisp/erc/erc-dcc.el. But I then realized that the bug was more
likely in my system because the simple C code like
double d = 2.00;
d = log (d);
will result in crash. And the crash finally disappeared when I
updated my build system. It seems a bug in the header of MinGW and
has been resolved.
> Also, any idea where did that __fu0_log come from?
Maybe It is generated by GCC.
Wishes,
Chris
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: MS-Windows tester wanted for trunk
2014-09-17 9:28 ` Chris Zheng
@ 2014-09-17 10:03 ` Eli Zaretskii
2014-09-17 16:56 ` Clang ? [Was: Re: MS-Windows tester wanted for trunk] Dmitry Antipov
0 siblings, 1 reply; 18+ messages in thread
From: Eli Zaretskii @ 2014-09-17 10:03 UTC (permalink / raw
To: Chris Zheng; +Cc: dmantipov, emacs-devel
> Date: Wed, 17 Sep 2014 17:28:00 +0800
> Cc: dmantipov@yandex.ru, emacs-devel@gnu.org
> From: Chris Zheng <chriszheng99@gmail.com>
>
> > OK. If you continue (e.g., with "make -k"), does it succeed to finish
> > the bootstrap, and if so, can you start a session and evaluate the
> > problematic code, the one that called 'log', in the scratch buffer?
>
> Thanks for your hints. I have located the crash was coused by
> `(ceiling (/ (ceiling (/ (log value) (log 2))) 8.0))' in
> /lisp/erc/erc-dcc.el. But I then realized that the bug was more
> likely in my system because the simple C code like
> double d = 2.00;
> d = log (d);
> will result in crash. And the crash finally disappeared when I
> updated my build system. It seems a bug in the header of MinGW and
> has been resolved.
Great, thank you for your efforts.
So I guess the conclusion is that only the 32-bit Windows builds are
affected by this problem.
I still think other 32-bit platforms should be tested as well.
> > Also, any idea where did that __fu0_log come from?
>
> Maybe It is generated by GCC.
Probably. But it isn't important now (I thought it might be a part of
the puzzle, but evidently it isn't).
^ permalink raw reply [flat|nested] 18+ messages in thread
* Clang ? [Was: Re: MS-Windows tester wanted for trunk]
2014-09-17 10:03 ` Eli Zaretskii
@ 2014-09-17 16:56 ` Dmitry Antipov
2014-09-18 1:05 ` Paul Eggert
0 siblings, 1 reply; 18+ messages in thread
From: Dmitry Antipov @ 2014-09-17 16:56 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
On 09/17/2014 02:03 PM, Eli Zaretskii wrote:
> I still think other 32-bit platforms should be tested as well.
And may be other compilers too. Currently I'm facing weird problem
with clang - USE_STACK_LISP_OBJECTS doesn't work neither in 32- nor
in 64-bit code beyond -O0 because addresses returned by alloca are
definitely unaligned. I tried 3.4 as well as current dev. snapshot
(3.6.0 trunk 217949), with the same poor results. Can someone check
clang too?
Dmitry
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Clang ? [Was: Re: MS-Windows tester wanted for trunk]
2014-09-17 16:56 ` Clang ? [Was: Re: MS-Windows tester wanted for trunk] Dmitry Antipov
@ 2014-09-18 1:05 ` Paul Eggert
2014-09-24 14:45 ` Dmitry Antipov
0 siblings, 1 reply; 18+ messages in thread
From: Paul Eggert @ 2014-09-18 1:05 UTC (permalink / raw
To: Dmitry Antipov; +Cc: emacs-devel
Dmitry Antipov wrote:
> Can someone check clang too?
I observed the same problem on Ubuntu 14.04.1 LTS with clang 3.4, and
installed a workaround as trunk bzr 117897. It's not quite as fast as
with GCC, but it's good enough.
^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: Clang ? [Was: Re: MS-Windows tester wanted for trunk]
2014-09-18 1:05 ` Paul Eggert
@ 2014-09-24 14:45 ` Dmitry Antipov
0 siblings, 0 replies; 18+ messages in thread
From: Dmitry Antipov @ 2014-09-24 14:45 UTC (permalink / raw
To: Paul Eggert; +Cc: emacs-devel
On 09/18/2014 05:05 AM, Paul Eggert wrote:
> I observed the same problem on Ubuntu 14.04.1 LTS with clang 3.4
AFAICS clang 3.6.0 (trunk 218380) works on GNU/Linux with USE_STACK_LISP_OBJECTS
at -O1, -O2 and -O3 -march=native -mtune=native. Anyway, since clang is known to
have some unstability at this area, let's not USE_STACK_LISP_OBJECTS until ... hm,
may be 3.6.0 release.
Dmitry
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2014-09-24 14:45 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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:54 ` Chris Zheng
2014-09-16 14:56 ` Chris Zheng
2014-09-16 15:10 ` Eli Zaretskii
2014-09-17 9:28 ` Chris Zheng
2014-09-17 10:03 ` Eli Zaretskii
2014-09-17 16:56 ` Clang ? [Was: Re: MS-Windows tester wanted for trunk] Dmitry Antipov
2014-09-18 1:05 ` Paul Eggert
2014-09-24 14:45 ` Dmitry Antipov
2014-09-16 14:31 ` MS-Windows tester wanted for trunk Eli Zaretskii
2014-09-16 15:24 ` Dmitry Antipov
2014-09-16 15:58 ` Eli Zaretskii
2014-09-16 20:40 ` Ken Brown
2014-09-16 15:46 ` Dmitry Antipov
2014-09-16 16:03 ` Eli Zaretskii
2014-09-16 14:38 ` 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.