MS-Windows tester wanted for trunk

MS-Windows tester wanted for trunk

[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.

Thanks in advance,
Dmitry

Re: MS-Windows tester wanted for trunk

[Chris Zheng]

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

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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.

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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.

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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.

Re: MS-Windows tester wanted for trunk

[Chris Zheng]

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 ?? ()

Re: MS-Windows tester wanted for trunk

[Chris Zheng]

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 ?? ()

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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?

Re: MS-Windows tester wanted for trunk

[Dmitry Antipov]

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

Re: MS-Windows tester wanted for trunk

[Dmitry Antipov]

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

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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?

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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).

Re: MS-Windows tester wanted for trunk

[Ken Brown]

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

Re: MS-Windows tester wanted for trunk

[Chris Zheng]

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

Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> 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).

Clang ? [Was: Re: MS-Windows tester wanted for trunk]

[Dmitry Antipov]

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

Re: Clang ? [Was: Re: MS-Windows tester wanted for trunk]

[Paul Eggert]

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.

Re: Clang ? [Was: Re: MS-Windows tester wanted for trunk]

[Dmitry Antipov]

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