Re: MS-Windows tester wanted for trunk

[Eli Zaretskii]

> Date: Tue, 16 Sep 2014 12:50:00 +0400
> From: Dmitry Antipov <address@hidden>
> 
> 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.