Building the igc branch on MS-Windows

Building the igc branch on MS-Windows

[Eli Zaretskii]

I took a stab on this.

MPS doesn't support MinGW on MS-Windows OOTB, so I needed to create a
new platform configuration for it.  That took awhile, but eventually
the build worked and all the tests passed.

For the first build, I configured without tree-sitter, without native
compilation, and without wide-ints.  So this is supposed to be the
simplest 32-bit configuration possible.

Building Emacs, I has a few relatively simple problems to get it to
compile without any warnings and errors (see my commit a few minutes
ago), but then bootstrap-emacs aborts in pbootstrap phase due to
assertion violation inside MPS:

  Loading d:/gnu/git/emacs/feature/lisp/faces.el (source)...

  poolamc.c:1291: Emacs fatal error: assertion failed: p == clientLimit

  Backtrace:
  012aa172
  012aa205
  01122089
  011b25a7
  0127eae0
  01331a29
  Makefile:1011: recipe for target `bootstrap-emacs.pdmp' failed

and I have no idea where to go from here.  (I'll later try to install
a debug version of libmps and step with GDB through the code which
hits the assertion violation, but I doubt that I will be any wiser
after that, as the significance of what the function
amcSegScanNailedRange, which hits the assertion, does evades me.)

One thing that might be related is that I configured MPS with
MPS_PF_ALIGN = 4, because a build with align of 8 would sometimes fail
some of the tests.

Did someone try a 32-bit build on GNU/Linux?  Maybe the above isn't
Windows-specific, but has something to do with 32-bit builds?

Two other relevant issues, which _are_ specific to Windows:

  . Emacs on MS-Windows has its own implementation of malloc (see
    w32heap.c).  I don't think this should be a problem, as MPS
    advertises itself as being capable of coexisting with malloc and
    other allocators, but I thought I'd mention it anyway.
  . Emacs on MS-Windows uses an emulation of mmap, and the related
    code in buffer.c, for allocation of buffer text.  Most other
    builds of Emacs don't use mmap, so maybe there's some code not
    executed on any other platform where this branch was built and
    tested.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> I took a stab on this.
>
> MPS doesn't support MinGW on MS-Windows OOTB, so I needed to create a
> new platform configuration for it.  That took awhile, but eventually
> the build worked and all the tests passed.

Wow! 👍👍👍😀😀😀

Thanks for doing this!

>   Loading d:/gnu/git/emacs/feature/lisp/faces.el (source)...
>
>   poolamc.c:1291: Emacs fatal error: assertion failed: p == clientLimit
>
> and I have no idea where to go from here.  (I'll later try to install
> a debug version of libmps and step with GDB through the code which
> hits the assertion violation, but I doubt that I will be any wiser
> after that, as the significance of what the function
> amcSegScanNailedRange, which hits the assertion, does evades me.)

I think -lmps-debug will definitely help. It has many more assertions
and might detect a problem much earlier.

> One thing that might be related is that I configured MPS with
> MPS_PF_ALIGN = 4, because a build with align of 8 would sometimes fail
> some of the tests.

Can't say something to that, I'm afraid.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 24 Apr 2024 17:20:53 +0200
> 
> >   Loading d:/gnu/git/emacs/feature/lisp/faces.el (source)...
> >
> >   poolamc.c:1291: Emacs fatal error: assertion failed: p == clientLimit
> >
> > and I have no idea where to go from here.  (I'll later try to install
> > a debug version of libmps and step with GDB through the code which
> > hits the assertion violation, but I doubt that I will be any wiser
> > after that, as the significance of what the function
> > amcSegScanNailedRange, which hits the assertion, does evades me.)
> 
> I think -lmps-debug will definitely help. It has many more assertions
> and might detect a problem much earlier.

I linked with -lmps-debug, and I got this assertion instead:

  Loading d:/gnu/git/emacs/feature/lisp/faces.el (source)...

  nailboard.c:205: Emacs fatal error: assertion failed: i < nailboardLevelBits(nailboardNails(board), level)

Does this give more information about a possible reason?  The relevant
code in MPS is this:

  static Index nailboardIndex(Nailboard board, Index level, Addr addr)
  {
    Index i = AddrOffset(RangeBase(&board->range), addr)
      >> (board->alignShift + level * LEVEL_SHIFT);
    AVER_CRITICAL(i < nailboardLevelBits(nailboardNails(board), level));
    return i;
  }

and LEVEL_SHIFT is

  /* Log2 of scale factor between levels. <design/nailboard#.impl.scale>. */
  #define LEVEL_SHIFT MPS_WORD_SHIFT

and MPS_WORD_SHIFT is 5 for this platform (as for all the other 32-bit
platforms defined in mpstd.h).

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> I linked with -lmps-debug, and I got this assertion instead:
>
>   Loading d:/gnu/git/emacs/feature/lisp/faces.el (source)...
>
>   nailboard.c:205: Emacs fatal error: assertion failed: i <
>   nailboardLevelBits(nailboardNails(board), level)

I think what they call a nailboard has something to do with pinning
objects, i.e. preventing objects from moving in memory. Not that that
info is immediately useful...

> Does this give more information about a possible reason?  The relevant
> code in MPS is this:
>
>   static Index nailboardIndex(Nailboard board, Index level, Addr addr)
>   {
>     Index i = AddrOffset(RangeBase(&board->range), addr)
>       >> (board->alignShift + level * LEVEL_SHIFT);
>     AVER_CRITICAL(i < nailboardLevelBits(nailboardNails(board), level));
>     return i;
>   }
>
> and LEVEL_SHIFT is
>
>   /* Log2 of scale factor between levels. <design/nailboard#.impl.scale>. */
>   #define LEVEL_SHIFT MPS_WORD_SHIFT
>
> and MPS_WORD_SHIFT is 5 for this platform (as for all the other 32-bit
> platforms defined in mpstd.h).

Doesn't tell me anything. I've not yet tried to understand the internals
of MPS.

Could you please walk up the stack frames? Is something from us there?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Could you please walk up the stack frames? Is something from us there?

In case we're not on the stack: At some point in the MPS call stack, it
should be calling one of our callback functions (dftl_scan, ...) . It
has a kind of OO way of doing that, I think you will recognize it
quickly. Maybe one can deduce something from what's going on there.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 24 Apr 2024 18:48:25 +0200
> 
> Could you please walk up the stack frames? Is something from us there?

Quite a lot, actually.  Here's the entire backtrace, for your fun:

  Loading d:/gnu/git/emacs/feature/lisp/faces.el (source)...

  nailboard.c:205: Emacs fatal error: assertion failed: i < nailboardLevelBits(nailboardNails(board), level)

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22,
      backtrace_limit=2147483647) at emacs.c:443
  443       signal (sig, SIG_DFL);
  (gdb) bt
  #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:443
  #1  0x006225ab in die (
      msg=0xc09de8 <dbgpoolFileSrcIdStruct+16> "i < nailboardLevelBits(nailboardNails(board), level)", file=0xc09e1d <dbgpoolFileSrcIdStruct+69> "nailboard.c",
      line=205) at alloc.c:8334
  #2  0x006eeae4 in igc_assert_fail (
      file=0xc09e1d <dbgpoolFileSrcIdStruct+69> "nailboard.c", line=205,
      msg=0xc09de8 <dbgpoolFileSrcIdStruct+16> "i < nailboardLevelBits(nailboardNails(board), level)") at igc.c:78
  #3  0x007f7539 in mps_lib_assert_fail (
      file=file@entry=0xc09e1d <dbgpoolFileSrcIdStruct+69> "nailboard.c",
      line=line@entry=205,
      condition=condition@entry=0xc09de8 <dbgpoolFileSrcIdStruct+16> "i < nailboardLevelBits(nailboardNails(board), level)") at mpsliban.c:87
  #4  0x008071f1 in nailboardIndex (board=board@entry=0x9ba51ec,
      level=level@entry=2, addr=addr@entry=0xa01e007) at nailboard.c:205
  #5  0x00807224 in nailboardIndexRange (
      ibaseReturn=ibaseReturn@entry=0x656f5ec,
      ilimitReturn=ilimitReturn@entry=0x656f5e8, board=board@entry=0x9ba51ec,
      level=level@entry=2, base=base@entry=0xa01dfd8,
      limit=limit@entry=0xa01e008) at nailboard.c:232
  #6  0x00807b12 in NailboardIsResRange (board=board@entry=0x9ba51ec,
      base=0xa01dfd8, limit=0xa01e008) at nailboard.c:350
  #7  0x007f0892 in amcPinnedInterior (amc=amc@entry=0x9a56250, board=0x9ba51ec,
      base=base@entry=0xa01dfd8, limit=limit@entry=0xa01e008) at poolamc.c:681
  #8  0x007eed88 in amcSegFix (seg=0x9a57490, ss=0x656f814, refIO=0x656f6cc)
      at poolamc.c:1604
  #9  0x007d5d16 in SegFix (seg=0x9a57490, ss=0x656f814, refIO=0x656f6cc)
      at seg.c:793
  #10 0x007e435b in _mps_fix2 (mps_ss=0x656f818, mps_ref_io=0x656f700)
      at trace.c:1433
  #11 0x006ef08a in fix_lisp_obj (ss=0x656f818, pobj=0xcd1aec <globals+396>)
      at igc.c:428
  #12 0x006ef27b in scan_staticvec (ss=0x656f818, start=0xccf940 <staticvec>,
      end=0xcd1940 <consing_until_gc>, closure=0x0) at igc.c:534
  #13 0x007e4a21 in TraceScanArea (ss=ss@entry=0x656f814,
      base=0xccf940 <staticvec>, limit=0xcd1940 <consing_until_gc>,
      scan_area=0x6ef20b <scan_staticvec>, closure=0x0) at trace.c:1566
  #14 0x007ce8fa in RootScan (ss=ss@entry=0x656f814, root=root@entry=0x9a569e8)
      at root.c:540
  #15 0x007e1d3e in traceScanRootRes (ts=ts@entry=1, rank=rank@entry=1,
      arena=arena@entry=0x1f0000, root=root@entry=0x9a569e8) at trace.c:528
  #16 0x007e1d82 in traceScanRoot (ts=1, rank=1, arena=0x1f0000,
      root=root@entry=0x9a569e8) at trace.c:545
  #17 0x007e1f43 in rootFlip (root=0x9a569e8, p=0x656f934) at trace.c:580
  #18 0x007cecdb in RootsIterate (arena=arena@entry=0x1f0008,
      f=f@entry=0x7e1de8 <rootFlip>, p=p@entry=0x656f934) at root.c:665
  #19 0x007e24c3 in traceFlip (trace=trace@entry=0x1f0518) at trace.c:652
  #20 0x007e4cae in TraceStart (trace=0x1f0518, mortality=0.79999999542474498,
      finishingTime=finishingTime@entry=32785058) at trace.c:1694
  #21 0x007c16e3 in PolicyStartTrace (traceReturn=traceReturn@entry=0x656fa2c,
      collectWorldReturn=collectWorldReturn@entry=0x656fa5c,
      arena=arena@entry=0x1f0000,
      collectWorldAllowed=collectWorldAllowed@entry=1) at policy.c:335
  #22 0x007e5550 in TracePoll (workReturn=workReturn@entry=0x656fa58,
      collectWorldReturn=collectWorldReturn@entry=0x656fa5c,
      globals=globals@entry=0x1f0008, collectWorldAllowed=1) at trace.c:1840
  #23 0x007b128c in ArenaPoll (globals=globals@entry=0x1f0008) at global.c:745
  #24 0x007bdac1 in mps_ap_fill (p_o=0x656fb1c, mps_ap=0x9a56c10, size=16)
      at mpsi.c:1097
  #25 0x006f3426 in alloc (size=16, type=IGC_OBJ_CONS, pvec_type=PVEC_FREE)
      at igc.c:2486
  #26 0x006f3537 in igc_make_cons (car=XIL(0x12d11ffb), cdr=XIL(0xa041e4b))
      at igc.c:2510
  #27 0x0061f399 in Fcons (car=XIL(0x12d11ffb), cdr=XIL(0xa041e4b))
      at alloc.c:2924
  #28 0x00657389 in funcall_lambda (fun=XIL(0xa04e21b), nargs=2,
      arg_vector=0x656fc64) at eval.c:3264
  #29 0x00656615 in funcall_general (fun=XIL(0xa04e22b), numargs=2,
      args=0x656fc64) at eval.c:2994
  #30 0x00656804 in Ffuncall (nargs=3, args=0x656fc60) at eval.c:3032
  #31 0x00655d61 in Fapply (nargs=2, args=0x656fcd8) at eval.c:2703
  #32 0x0065623a in apply1 (fn=XIL(0xa04e22b), arg=XIL(0x11aa72bb))
      at eval.c:2919
  #33 0x00655896 in eval_sub (form=XIL(0x11aa728b)) at eval.c:2619
  #34 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #35 0x00650a15 in Fif (args=XIL(0x12d11fcb)) at eval.c:395
  #36 0x00655117 in eval_sub (form=XIL(0x12d11fdb)) at eval.c:2486
  #37 0x006558b9 in eval_sub (form=XIL(0x11aa721b)) at eval.c:2621
  #38 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #39 0x00652152 in Flet (args=XIL(0x11aa712b)) at eval.c:1047
  #40 0x00655117 in eval_sub (form=XIL(0x11aa70ab)) at eval.c:2486
  #41 0x00650b10 in Fprogn (body=XIL(0x12d1122b)) at eval.c:439
  #42 0x00652152 in Flet (args=XIL(0x12d1124b)) at eval.c:1047
  #43 0x00655117 in eval_sub (form=XIL(0x12d1125b)) at eval.c:2486
  #44 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #45 0x00650b36 in prog_ignore (body=XIL(0x12d1126b)) at eval.c:450
  #46 0x006521ad in Fwhile (args=XIL(0x12d1127b)) at eval.c:1068
  #47 0x00655117 in eval_sub (form=XIL(0x12d1128b)) at eval.c:2486
  #48 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #49 0x00652152 in Flet (args=XIL(0x12d112ab)) at eval.c:1047
  #50 0x00655117 in eval_sub (form=XIL(0x12d112bb)) at eval.c:2486
  #51 0x006558b9 in eval_sub (form=XIL(0x11aa704b)) at eval.c:2621
  #52 0x00650b10 in Fprogn (body=XIL(0x11aa772b)) at eval.c:439
  #53 0x00652152 in Flet (args=XIL(0x11aa703b)) at eval.c:1047
  #54 0x00655117 in eval_sub (form=XIL(0x11aa6dcb)) at eval.c:2486
  #55 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #56 0x00650a9a in Fcond (args=XIL(0x11aa774b)) at eval.c:419
  #57 0x00655117 in eval_sub (form=XIL(0x11aa6a1b)) at eval.c:2486
  #58 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #59 0x006574d8 in funcall_lambda (fun=XIL(0x11aa7d23), nargs=3,
      arg_vector=0x6570a20) at eval.c:3283
  #60 0x00656f4d in apply_lambda (fun=XIL(0x11aa7d33), args=XIL(0x11aa7fd3),
      count=4672) at eval.c:3154
  #61 0x00655915 in eval_sub (form=XIL(0x11aa7fc3)) at eval.c:2625
  #62 0x00651c4e in FletX (args=XIL(0x11aa802b)) at eval.c:955
  #63 0x00655117 in eval_sub (form=XIL(0x11aa7f03)) at eval.c:2486
  #64 0x00650b10 in Fprogn (body=XIL(0x12d080bb)) at eval.c:439
  #65 0x00652152 in Flet (args=XIL(0x12d080db)) at eval.c:1047
  #66 0x00655117 in eval_sub (form=XIL(0x12d080eb)) at eval.c:2486
  #67 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #68 0x00650b36 in prog_ignore (body=XIL(0x12d080fb)) at eval.c:450
  #69 0x006521ad in Fwhile (args=XIL(0x12d0810b)) at eval.c:1068
  #70 0x00655117 in eval_sub (form=XIL(0x12d0811b)) at eval.c:2486
  #71 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #72 0x00652152 in Flet (args=XIL(0x12d0813b)) at eval.c:1047
  #73 0x00655117 in eval_sub (form=XIL(0x12d0814b)) at eval.c:2486
  #74 0x006558b9 in eval_sub (form=XIL(0x11aa7ec3)) at eval.c:2621
  #75 0x00650b10 in Fprogn (body=XIL(0x11aa82eb)) at eval.c:439
  #76 0x00652152 in Flet (args=XIL(0x11aa7eb3)) at eval.c:1047
  #77 0x00655117 in eval_sub (form=XIL(0x11aa7e03)) at eval.c:2486
  #78 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #79 0x006574d8 in funcall_lambda (fun=XIL(0x11aa877b), nargs=3,
      arg_vector=0x65713e0) at eval.c:3283
  #80 0x00656f4d in apply_lambda (fun=XIL(0x11aa878b), args=XIL(0x11ab7e0b),
      count=4480) at eval.c:3154
  #81 0x00655915 in eval_sub (form=XIL(0x11ab7dfb)) at eval.c:2625
  #82 0x00651c4e in FletX (args=XIL(0x11ab7f6b)) at eval.c:955
  #83 0x00655117 in eval_sub (form=XIL(0x11ab7d8b)) at eval.c:2486
  #84 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #85 0x00650a9a in Fcond (args=XIL(0x11ab84bb)) at eval.c:419
  #86 0x00655117 in eval_sub (form=XIL(0x11ab6b6b)) at eval.c:2486
  #87 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #88 0x00651dee in FletX (args=XIL(0x11ab6b5b)) at eval.c:979
  #89 0x00655117 in eval_sub (form=XIL(0x11ab69bb)) at eval.c:2486
  #90 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #91 0x00650a9a in Fcond (args=XIL(0x11ab8833)) at eval.c:419
  #92 0x00655117 in eval_sub (form=XIL(0x11ab544b)) at eval.c:2486
  #93 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #94 0x006574d8 in funcall_lambda (fun=XIL(0x11ab8dcb), nargs=4,
      arg_vector=0x6571ab0) at eval.c:3283
  #95 0x00656f4d in apply_lambda (fun=XIL(0x11ab8ddb), args=XIL(0x11aa2cf3),
      count=4352) at eval.c:3154
  #96 0x00655915 in eval_sub (form=XIL(0x11aa2cc3)) at eval.c:2625
  #97 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #98 0x00651dee in FletX (args=XIL(0x11aa2cb3)) at eval.c:979
  #99 0x00655117 in eval_sub (form=XIL(0x11aa2b13)) at eval.c:2486
  #100 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #101 0x00655117 in eval_sub (form=XIL(0x12d0352b)) at eval.c:2486
  #102 0x006509f5 in Fif (args=XIL(0x12d0354b)) at eval.c:394
  #103 0x00655117 in eval_sub (form=XIL(0x12d0355b)) at eval.c:2486
  #104 0x006558b9 in eval_sub (form=XIL(0x11aa2a93)) at eval.c:2621
  #105 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #106 0x006574d8 in funcall_lambda (fun=XIL(0x11aa3233), nargs=1,
      arg_vector=0x65720d0) at eval.c:3283
  #107 0x00656f4d in apply_lambda (fun=XIL(0x11aa3243), args=XIL(0x11ab847b),
      count=4240) at eval.c:3154
  #108 0x00655915 in eval_sub (form=XIL(0x11ab846b)) at eval.c:2625
  #109 0x00656ef1 in apply_lambda (fun=XIL(0x11aa29bb), args=XIL(0x11ab83fb),
      count=4224) at eval.c:3149
  #110 0x00655915 in eval_sub (form=XIL(0x11ab7f7b)) at eval.c:2625
  #111 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #112 0x00651dee in FletX (args=XIL(0x11ab7f6b)) at eval.c:979
  #113 0x00655117 in eval_sub (form=XIL(0x11ab7d8b)) at eval.c:2486
  #114 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #115 0x00650a9a in Fcond (args=XIL(0x11ab84bb)) at eval.c:419
  #116 0x00655117 in eval_sub (form=XIL(0x11ab6b6b)) at eval.c:2486
  #117 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #118 0x00651dee in FletX (args=XIL(0x11ab6b5b)) at eval.c:979
  #119 0x00655117 in eval_sub (form=XIL(0x11ab69bb)) at eval.c:2486
  #120 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #121 0x00650a9a in Fcond (args=XIL(0x11ab8833)) at eval.c:419
  #122 0x00655117 in eval_sub (form=XIL(0x11ab544b)) at eval.c:2486
  #123 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #124 0x006574d8 in funcall_lambda (fun=XIL(0x11ab8dcb), nargs=4,
      arg_vector=0x6572900) at eval.c:3283
  #125 0x00656f4d in apply_lambda (fun=XIL(0x11ab8ddb), args=XIL(0x11aa2cf3),
      count=4096) at eval.c:3154
  #126 0x00655915 in eval_sub (form=XIL(0x11aa2cc3)) at eval.c:2625
  #127 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #128 0x00651dee in FletX (args=XIL(0x11aa2cb3)) at eval.c:979
  #129 0x00655117 in eval_sub (form=XIL(0x11aa2b13)) at eval.c:2486
  #130 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #131 0x00655117 in eval_sub (form=XIL(0x12cedd9b)) at eval.c:2486
  #132 0x006509f5 in Fif (args=XIL(0x12ceddbb)) at eval.c:394
  #133 0x00655117 in eval_sub (form=XIL(0x12ceddcb)) at eval.c:2486
  #134 0x006558b9 in eval_sub (form=XIL(0x11aa2a93)) at eval.c:2621
  #135 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #136 0x006574d8 in funcall_lambda (fun=XIL(0x11aa3233), nargs=1,
      arg_vector=0x6572f20) at eval.c:3283
  #137 0x00656f4d in apply_lambda (fun=XIL(0x11aa3243), args=XIL(0x11ab847b),
      count=3984) at eval.c:3154
  #138 0x00655915 in eval_sub (form=XIL(0x11ab846b)) at eval.c:2625
  #139 0x00656ef1 in apply_lambda (fun=XIL(0x11aa29bb), args=XIL(0x11ab83fb),
      count=3968) at eval.c:3149
  #140 0x00655915 in eval_sub (form=XIL(0x11ab7f7b)) at eval.c:2625
  #141 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #142 0x00651dee in FletX (args=XIL(0x11ab7f6b)) at eval.c:979
  #143 0x00655117 in eval_sub (form=XIL(0x11ab7d8b)) at eval.c:2486
  #144 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #145 0x00650a9a in Fcond (args=XIL(0x11ab84bb)) at eval.c:419
  #146 0x00655117 in eval_sub (form=XIL(0x11ab6b6b)) at eval.c:2486
  #147 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #148 0x00651dee in FletX (args=XIL(0x11ab6b5b)) at eval.c:979
  #149 0x00655117 in eval_sub (form=XIL(0x11ab69bb)) at eval.c:2486
  #150 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #151 0x00650a9a in Fcond (args=XIL(0x11ab8833)) at eval.c:419
  #152 0x00655117 in eval_sub (form=XIL(0x11ab544b)) at eval.c:2486
  #153 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #154 0x006574d8 in funcall_lambda (fun=XIL(0x11ab8dcb), nargs=4,
      arg_vector=0x6573750) at eval.c:3283
  #155 0x00656f4d in apply_lambda (fun=XIL(0x11ab8ddb), args=XIL(0x11aa2cf3),
      count=3840) at eval.c:3154
  #156 0x00655915 in eval_sub (form=XIL(0x11aa2cc3)) at eval.c:2625
  #157 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #158 0x00651dee in FletX (args=XIL(0x11aa2cb3)) at eval.c:979
  #159 0x00655117 in eval_sub (form=XIL(0x11aa2b13)) at eval.c:2486
  #160 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #161 0x00655117 in eval_sub (form=XIL(0x12cd824b)) at eval.c:2486
  #162 0x006509f5 in Fif (args=XIL(0x12cd826b)) at eval.c:394
  #163 0x00655117 in eval_sub (form=XIL(0x12cd827b)) at eval.c:2486
  #164 0x006558b9 in eval_sub (form=XIL(0x11aa2a93)) at eval.c:2621
  #165 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #166 0x006574d8 in funcall_lambda (fun=XIL(0x11aa3233), nargs=1,
      arg_vector=0x6573d70) at eval.c:3283
  #167 0x00656f4d in apply_lambda (fun=XIL(0x11aa3243), args=XIL(0x11ab847b),
      count=3728) at eval.c:3154
  #168 0x00655915 in eval_sub (form=XIL(0x11ab846b)) at eval.c:2625
  #169 0x00656ef1 in apply_lambda (fun=XIL(0x11aa29bb), args=XIL(0x11ab83fb),
      count=3712) at eval.c:3149
  #170 0x00655915 in eval_sub (form=XIL(0x11ab7f7b)) at eval.c:2625
  #171 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #172 0x00651dee in FletX (args=XIL(0x11ab7f6b)) at eval.c:979
  #173 0x00655117 in eval_sub (form=XIL(0x11ab7d8b)) at eval.c:2486
  #174 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #175 0x00650a9a in Fcond (args=XIL(0x11ab84bb)) at eval.c:419
  #176 0x00655117 in eval_sub (form=XIL(0x11ab6b6b)) at eval.c:2486
  #177 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #178 0x00651dee in FletX (args=XIL(0x11ab6b5b)) at eval.c:979
  #179 0x00655117 in eval_sub (form=XIL(0x11ab69bb)) at eval.c:2486
  #180 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #181 0x00650a9a in Fcond (args=XIL(0x11ab8833)) at eval.c:419
  #182 0x00655117 in eval_sub (form=XIL(0x11ab544b)) at eval.c:2486
  #183 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #184 0x006574d8 in funcall_lambda (fun=XIL(0x11ab8dcb), nargs=4,
      arg_vector=0x65745a0) at eval.c:3283
  #185 0x00656f4d in apply_lambda (fun=XIL(0x11ab8ddb), args=XIL(0x11aa2cf3),
      count=3584) at eval.c:3154
  #186 0x00655915 in eval_sub (form=XIL(0x11aa2cc3)) at eval.c:2625
  #187 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #188 0x00651dee in FletX (args=XIL(0x11aa2cb3)) at eval.c:979
  #189 0x00655117 in eval_sub (form=XIL(0x11aa2b13)) at eval.c:2486
  #190 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #191 0x00655117 in eval_sub (form=XIL(0x12cc231b)) at eval.c:2486
  #192 0x006509f5 in Fif (args=XIL(0x12cc233b)) at eval.c:394
  #193 0x00655117 in eval_sub (form=XIL(0x12cc234b)) at eval.c:2486
  #194 0x006558b9 in eval_sub (form=XIL(0x11aa2a93)) at eval.c:2621
  #195 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #196 0x006574d8 in funcall_lambda (fun=XIL(0x11aa3233), nargs=1,
      arg_vector=0x6574bc0) at eval.c:3283
  #197 0x00656f4d in apply_lambda (fun=XIL(0x11aa3243), args=XIL(0x11a9ced3),
      count=3472) at eval.c:3154
  #198 0x00655915 in eval_sub (form=XIL(0x11a9ca13)) at eval.c:2625
  #199 0x00651c4e in FletX (args=XIL(0x11a9cf03)) at eval.c:955
  #200 0x00655117 in eval_sub (form=XIL(0x11a9c973)) at eval.c:2486
  #201 0x00651c4e in FletX (args=XIL(0x12caa82b)) at eval.c:955
  #202 0x00655117 in eval_sub (form=XIL(0x12caa83b)) at eval.c:2486
  #203 0x006558b9 in eval_sub (form=XIL(0x11a9c933)) at eval.c:2621
  #204 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #205 0x006574d8 in funcall_lambda (fun=XIL(0x11a9dffb), nargs=2,
      arg_vector=0x65750b0) at eval.c:3283
  #206 0x00656f4d in apply_lambda (fun=XIL(0x11a9e00b), args=XIL(0x11a9ec03),
      count=3360) at eval.c:3154
  #207 0x00655915 in eval_sub (form=XIL(0x11a9ebf3)) at eval.c:2625
  #208 0x00651c4e in FletX (args=XIL(0x11a9ed53)) at eval.c:955
  #209 0x00655117 in eval_sub (form=XIL(0x11a9e0cb)) at eval.c:2486
  #210 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #211 0x006574d8 in funcall_lambda (fun=XIL(0x11a9f213), nargs=2,
      arg_vector=0x65753a0) at eval.c:3283
  #212 0x00656f4d in apply_lambda (fun=XIL(0x11a9f223), args=XIL(0x11a924e3),
      count=3296) at eval.c:3154
  #213 0x00655915 in eval_sub (form=XIL(0x11a924d3)) at eval.c:2625
  #214 0x00651fb3 in Flet (args=XIL(0x11a92523)) at eval.c:1017
  #215 0x00655117 in eval_sub (form=XIL(0x11a924b3)) at eval.c:2486
  #216 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #217 0x00650a15 in Fif (args=XIL(0x11a92473)) at eval.c:395
  #218 0x00655117 in eval_sub (form=XIL(0x11a92393)) at eval.c:2486
  #219 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #220 0x00652152 in Flet (args=XIL(0x11a92383)) at eval.c:1047
  #221 0x00655117 in eval_sub (form=XIL(0x11a922f3)) at eval.c:2486
  #222 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #223 0x006574d8 in funcall_lambda (fun=XIL(0x11a92f53), nargs=13,
      arg_vector=0x65759e4) at eval.c:3283
  #224 0x00656615 in funcall_general (fun=XIL(0x11a92f63), numargs=13,
      args=0x65759e4) at eval.c:2994
  #225 0x00656804 in Ffuncall (nargs=14, args=0x65759e0) at eval.c:3032
  #226 0x00655d61 in Fapply (nargs=2, args=0x6575a90) at eval.c:2703
  #227 0x006552b4 in eval_sub (form=XIL(0x11b46a83)) at eval.c:2507
  #228 0x006509f5 in Fif (args=XIL(0x11b46a73)) at eval.c:394
  #229 0x00655117 in eval_sub (form=XIL(0x11b469f3)) at eval.c:2486
  #230 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #231 0x00650a9a in Fcond (args=XIL(0x11b46b23)) at eval.c:419
  #232 0x00655117 in eval_sub (form=XIL(0x11b46873)) at eval.c:2486
  #233 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #234 0x00652152 in Flet (args=XIL(0x11b46863)) at eval.c:1047
  #235 0x00655117 in eval_sub (form=XIL(0x11b467a3)) at eval.c:2486
  #236 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #237 0x00650a15 in Fif (args=XIL(0x11b46783)) at eval.c:395
  #238 0x00655117 in eval_sub (form=XIL(0x11b466e3)) at eval.c:2486
  #239 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #240 0x00650a15 in Fif (args=XIL(0x11b465f3)) at eval.c:395
  #241 0x00655117 in eval_sub (form=XIL(0x11b465e3)) at eval.c:2486
  #242 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #243 0x00651dee in FletX (args=XIL(0x11b465d3)) at eval.c:979
  #244 0x00655117 in eval_sub (form=XIL(0x11b46513)) at eval.c:2486
  #245 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #246 0x00650a9a in Fcond (args=XIL(0x11b46b83)) at eval.c:419
  #247 0x00655117 in eval_sub (form=XIL(0x11b464d3)) at eval.c:2486
  #248 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #249 0x006574d8 in funcall_lambda (fun=XIL(0x11b54f3b), nargs=2,
      arg_vector=0x65764f0) at eval.c:3283
  #250 0x00656f4d in apply_lambda (fun=XIL(0x11b54f4b), args=XIL(0x11b550e3),
      count=3008) at eval.c:3154
  #251 0x00655915 in eval_sub (form=XIL(0x11b550d3)) at eval.c:2625
  #252 0x00650c6a in Fsetq (args=XIL(0x11b550c3)) at eval.c:486
  #253 0x00655117 in eval_sub (form=XIL(0x11b550b3)) at eval.c:2486
  #254 0x0065535c in eval_sub (form=XIL(0x11b55093)) at eval.c:2523
  #255 0x0065535c in eval_sub (form=XIL(0x11b55083)) at eval.c:2523
  #256 0x006521b8 in Fwhile (args=XIL(0x11b55133)) at eval.c:1065
  #257 0x00655117 in eval_sub (form=XIL(0x11b55073)) at eval.c:2486
  #258 0x00650b10 in Fprogn (body=XIL(0x11b554f3)) at eval.c:439
  #259 0x00651dee in FletX (args=XIL(0x11b55063)) at eval.c:979
  #260 0x00655117 in eval_sub (form=XIL(0x11b55013)) at eval.c:2486
  #261 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #262 0x006574d8 in funcall_lambda (fun=XIL(0x11b5ec7b), nargs=2,
      arg_vector=0x6576c00) at eval.c:3283
  #263 0x00656f4d in apply_lambda (fun=XIL(0x11b5ec8b), args=XIL(0x11c87b83),
      count=2864) at eval.c:3154
  #264 0x00655915 in eval_sub (form=XIL(0x11c87b73)) at eval.c:2625
  #265 0x00650c6a in Fsetq (args=XIL(0x11c87b63)) at eval.c:486
  #266 0x00655117 in eval_sub (form=XIL(0x11c87b53)) at eval.c:2486
  #267 0x00650b10 in Fprogn (body=XIL(0x127108db)) at eval.c:439
  #268 0x00650a15 in Fif (args=XIL(0x127108ab)) at eval.c:395
  #269 0x00655117 in eval_sub (form=XIL(0x1271089b)) at eval.c:2486
  #270 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #271 0x00652152 in Flet (args=XIL(0x1271095b)) at eval.c:1047
  #272 0x00655117 in eval_sub (form=XIL(0x127109cb)) at eval.c:2486
  #273 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #274 0x006574d8 in funcall_lambda (fun=XIL(0x12710b2b), nargs=1,
      arg_vector=0x65771a0) at eval.c:3283
  #275 0x00656f4d in apply_lambda (fun=XIL(0x12710b3b), args=XIL(0x11afbef3),
      count=2768) at eval.c:3154
  #276 0x00655915 in eval_sub (form=XIL(0x11afbee3)) at eval.c:2625
  #277 0x006509f5 in Fif (args=XIL(0x11b0213b)) at eval.c:394
  #278 0x00655117 in eval_sub (form=XIL(0x11b0212b)) at eval.c:2486
  #279 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #280 0x00655117 in eval_sub (form=XIL(0x11b0330b)) at eval.c:2486
  #281 0x00650c6a in Fsetq (args=XIL(0x11b0337b)) at eval.c:486
  #282 0x00655117 in eval_sub (form=XIL(0x11b0338b)) at eval.c:2486
  #283 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #284 0x00655117 in eval_sub (form=XIL(0x11b033cb)) at eval.c:2486
  #285 0x00650b10 in Fprogn (body=XIL(0x11b093db)) at eval.c:439
  #286 0x00650b36 in prog_ignore (body=XIL(0x11b033fb)) at eval.c:450
  #287 0x006521ad in Fwhile (args=XIL(0x11b033eb)) at eval.c:1068
  #288 0x00655117 in eval_sub (form=XIL(0x11b033db)) at eval.c:2486
  #289 0x00650b10 in Fprogn (body=XIL(0x11afd80b)) at eval.c:439
  #290 0x00651dee in FletX (args=XIL(0x11b0aa4b)) at eval.c:979
  #291 0x00655117 in eval_sub (form=XIL(0x11b0aabb)) at eval.c:2486
  #292 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #293 0x006574d8 in funcall_lambda (fun=XIL(0x11b0ac1b), nargs=2,
      arg_vector=0x6577a60) at eval.c:3283
  #294 0x00656f4d in apply_lambda (fun=XIL(0x11b0ac2b), args=XIL(0x11b0ad93),
      count=2624) at eval.c:3154
  #295 0x00655915 in eval_sub (form=XIL(0x11b0ad83)) at eval.c:2625
  #296 0x006509f5 in Fif (args=XIL(0x11b0ad73)) at eval.c:394
  #297 0x00655117 in eval_sub (form=XIL(0x11b0ad43)) at eval.c:2486
  #298 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #299 0x00655117 in eval_sub (form=XIL(0x11b0c33b)) at eval.c:2486
  #300 0x00650c6a in Fsetq (args=XIL(0x11b101cb)) at eval.c:486
  #301 0x00655117 in eval_sub (form=XIL(0x11b101db)) at eval.c:2486
  #302 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #303 0x00655117 in eval_sub (form=XIL(0x11b1021b)) at eval.c:2486
  #304 0x00650b10 in Fprogn (body=XIL(0x11b1622b)) at eval.c:439
  #305 0x00650b36 in prog_ignore (body=XIL(0x11b1024b)) at eval.c:450
  #306 0x006521ad in Fwhile (args=XIL(0x11b1023b)) at eval.c:1068
  #307 0x00655117 in eval_sub (form=XIL(0x11b1022b)) at eval.c:2486
  #308 0x00650b10 in Fprogn (body=XIL(0x11b0c65b)) at eval.c:439
  #309 0x00651dee in FletX (args=XIL(0x11b1789b)) at eval.c:979
  #310 0x00655117 in eval_sub (form=XIL(0x11b1790b)) at eval.c:2486
  #311 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #312 0x006574d8 in funcall_lambda (fun=XIL(0x11b17a6b), nargs=2,
      arg_vector=0x6578330) at eval.c:3283
  #313 0x00656f4d in apply_lambda (fun=XIL(0x11b17a7b), args=XIL(0x11c890ab),
      count=2480) at eval.c:3154
  #314 0x00655915 in eval_sub (form=XIL(0x11c8909b)) at eval.c:2625
  #315 0x00656ef1 in apply_lambda (fun=XIL(0x11adec1b), args=XIL(0x11c890cb),
      count=2464) at eval.c:3149
  #316 0x00655915 in eval_sub (form=XIL(0x11c8908b)) at eval.c:2625
  #317 0x00656ef1 in apply_lambda (fun=XIL(0x11adec1b), args=XIL(0x11c8907b),
      count=2448) at eval.c:3149
  #318 0x00655915 in eval_sub (form=XIL(0x11c8906b)) at eval.c:2625
  #319 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #320 0x00652152 in Flet (args=XIL(0x11c8905b)) at eval.c:1047
  #321 0x00655117 in eval_sub (form=XIL(0x11c8901b)) at eval.c:2486
  #322 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #323 0x00652152 in Flet (args=XIL(0x124547fb)) at eval.c:1047
  #324 0x00655117 in eval_sub (form=XIL(0x120f4f8b)) at eval.c:2486
  #325 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #326 0x00651dee in FletX (args=XIL(0x120f739b)) at eval.c:979
  #327 0x00655117 in eval_sub (form=XIL(0x120f73ab)) at eval.c:2486
  #328 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #329 0x00655117 in eval_sub (form=XIL(0x120f8b2b)) at eval.c:2486
  #330 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #331 0x00651dee in FletX (args=XIL(0x120f9d0b)) at eval.c:979
  #332 0x00655117 in eval_sub (form=XIL(0x120f9d1b)) at eval.c:2486
  #333 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #334 0x00650a9a in Fcond (args=XIL(0x126e327b)) at eval.c:419
  #335 0x00655117 in eval_sub (form=XIL(0x1270fd9b)) at eval.c:2486
  #336 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #337 0x00651dee in FletX (args=XIL(0x1270fe3b)) at eval.c:979
  #338 0x00655117 in eval_sub (form=XIL(0x1270feab)) at eval.c:2486
  #339 0x006509f5 in Fif (args=XIL(0x1270fecb)) at eval.c:394
  #340 0x00655117 in eval_sub (form=XIL(0x1270febb)) at eval.c:2486
  #341 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #342 0x00651dee in FletX (args=XIL(0x1271072b)) at eval.c:979
  #343 0x00655117 in eval_sub (form=XIL(0x1271079b)) at eval.c:2486
  #344 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #345 0x00652152 in Flet (args=XIL(0x1271081b)) at eval.c:1047
  #346 0x00655117 in eval_sub (form=XIL(0x1271088b)) at eval.c:2486
  #347 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #348 0x00650a15 in Fif (args=XIL(0x127108ab)) at eval.c:395
  #349 0x00655117 in eval_sub (form=XIL(0x1271089b)) at eval.c:2486
  #350 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #351 0x00652152 in Flet (args=XIL(0x1271095b)) at eval.c:1047
  #352 0x00655117 in eval_sub (form=XIL(0x127109cb)) at eval.c:2486
  #353 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #354 0x006574d8 in funcall_lambda (fun=XIL(0x12710b2b), nargs=1,
      arg_vector=0x65797a0) at eval.c:3283
  #355 0x00656f4d in apply_lambda (fun=XIL(0x12710b3b), args=XIL(0x11afbef3),
      count=2096) at eval.c:3154
  #356 0x00655915 in eval_sub (form=XIL(0x11afbee3)) at eval.c:2625
  #357 0x006509f5 in Fif (args=XIL(0x11b0213b)) at eval.c:394
  #358 0x00655117 in eval_sub (form=XIL(0x11b0212b)) at eval.c:2486
  #359 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #360 0x00655117 in eval_sub (form=XIL(0x11b0330b)) at eval.c:2486
  #361 0x00650c6a in Fsetq (args=XIL(0x11b0337b)) at eval.c:486
  #362 0x00655117 in eval_sub (form=XIL(0x11b0338b)) at eval.c:2486
  #363 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #364 0x00655117 in eval_sub (form=XIL(0x11b033cb)) at eval.c:2486
  #365 0x00650b10 in Fprogn (body=XIL(0x11b093db)) at eval.c:439
  #366 0x00650b36 in prog_ignore (body=XIL(0x11b033fb)) at eval.c:450
  #367 0x006521ad in Fwhile (args=XIL(0x11b033eb)) at eval.c:1068
  #368 0x00655117 in eval_sub (form=XIL(0x11b033db)) at eval.c:2486
  #369 0x00650b10 in Fprogn (body=XIL(0x11afd80b)) at eval.c:439
  #370 0x00651dee in FletX (args=XIL(0x11b0aa4b)) at eval.c:979
  #371 0x00655117 in eval_sub (form=XIL(0x11b0aabb)) at eval.c:2486
  #372 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #373 0x006574d8 in funcall_lambda (fun=XIL(0x11b0ac1b), nargs=2,
      arg_vector=0x657a060) at eval.c:3283
  #374 0x00656f4d in apply_lambda (fun=XIL(0x11b0ac2b), args=XIL(0x11c88c8b),
      count=1952) at eval.c:3154
  #375 0x00655915 in eval_sub (form=XIL(0x11c88c7b)) at eval.c:2625
  #376 0x00656ef1 in apply_lambda (fun=XIL(0x11adec1b), args=XIL(0x11c88cab),
      count=1936) at eval.c:3149
  #377 0x00655915 in eval_sub (form=XIL(0x11c88c6b)) at eval.c:2625
  #378 0x00656ef1 in apply_lambda (fun=XIL(0x11adec1b), args=XIL(0x11c88c5b),
      count=1920) at eval.c:3149
  #379 0x00655915 in eval_sub (form=XIL(0x11c88c4b)) at eval.c:2625
  #380 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #381 0x00652152 in Flet (args=XIL(0x11c88c3b)) at eval.c:1047
  #382 0x00655117 in eval_sub (form=XIL(0x11c88bfb)) at eval.c:2486
  #383 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #384 0x00652152 in Flet (args=XIL(0x12482cfb)) at eval.c:1047
  #385 0x00655117 in eval_sub (form=XIL(0x1203aedb)) at eval.c:2486
  #386 0x006509f5 in Fif (args=XIL(0x1203bcdb)) at eval.c:394
  #387 0x00655117 in eval_sub (form=XIL(0x1203bceb)) at eval.c:2486
  #388 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #389 0x00651dee in FletX (args=XIL(0x1203cecb)) at eval.c:979
  #390 0x00655117 in eval_sub (form=XIL(0x1203cedb)) at eval.c:2486
  #391 0x006509f5 in Fif (args=XIL(0x1203dc0b)) at eval.c:394
  #392 0x00655117 in eval_sub (form=XIL(0x1203dc1b)) at eval.c:2486
  #393 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #394 0x00651dee in FletX (args=XIL(0x1203edfb)) at eval.c:979
  #395 0x00655117 in eval_sub (form=XIL(0x1203ee0b)) at eval.c:2486
  #396 0x006509f5 in Fif (args=XIL(0x1203fafb)) at eval.c:394
  #397 0x00655117 in eval_sub (form=XIL(0x1203fb0b)) at eval.c:2486
  #398 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #399 0x00651dee in FletX (args=XIL(0x12040ceb)) at eval.c:979
  #400 0x00655117 in eval_sub (form=XIL(0x12040cfb)) at eval.c:2486
  #401 0x006509f5 in Fif (args=XIL(0x120419eb)) at eval.c:394
  #402 0x00655117 in eval_sub (form=XIL(0x120419fb)) at eval.c:2486
  #403 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #404 0x00651dee in FletX (args=XIL(0x12042bdb)) at eval.c:979
  #405 0x00655117 in eval_sub (form=XIL(0x12042beb)) at eval.c:2486
  #406 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #407 0x00650a9a in Fcond (args=XIL(0x126e325b)) at eval.c:419
  #408 0x00655117 in eval_sub (form=XIL(0x1270fd9b)) at eval.c:2486
  #409 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #410 0x00651dee in FletX (args=XIL(0x1270fe3b)) at eval.c:979
  #411 0x00655117 in eval_sub (form=XIL(0x1270feab)) at eval.c:2486
  #412 0x006509f5 in Fif (args=XIL(0x1270fecb)) at eval.c:394
  #413 0x00655117 in eval_sub (form=XIL(0x1270febb)) at eval.c:2486
  #414 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #415 0x00651dee in FletX (args=XIL(0x1271072b)) at eval.c:979
  #416 0x00655117 in eval_sub (form=XIL(0x1271079b)) at eval.c:2486
  #417 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #418 0x00652152 in Flet (args=XIL(0x1271081b)) at eval.c:1047
  #419 0x00655117 in eval_sub (form=XIL(0x1271088b)) at eval.c:2486
  #420 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #421 0x00650a15 in Fif (args=XIL(0x127108ab)) at eval.c:395
  #422 0x00655117 in eval_sub (form=XIL(0x1271089b)) at eval.c:2486
  #423 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #424 0x00652152 in Flet (args=XIL(0x1271095b)) at eval.c:1047
  #425 0x00655117 in eval_sub (form=XIL(0x127109cb)) at eval.c:2486
  #426 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #427 0x006574d8 in funcall_lambda (fun=XIL(0x12710b2b), nargs=1,
      arg_vector=0x657bab0) at eval.c:3283
  #428 0x00656f4d in apply_lambda (fun=XIL(0x12710b3b), args=XIL(0x11afbef3),
      count=1456) at eval.c:3154
  #429 0x00655915 in eval_sub (form=XIL(0x11afbee3)) at eval.c:2625
  #430 0x006509f5 in Fif (args=XIL(0x11b0213b)) at eval.c:394
  #431 0x00655117 in eval_sub (form=XIL(0x11b0212b)) at eval.c:2486
  #432 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #433 0x00655117 in eval_sub (form=XIL(0x11b0330b)) at eval.c:2486
  #434 0x00650c6a in Fsetq (args=XIL(0x11b0337b)) at eval.c:486
  #435 0x00655117 in eval_sub (form=XIL(0x11b0338b)) at eval.c:2486
  #436 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #437 0x00655117 in eval_sub (form=XIL(0x11b033cb)) at eval.c:2486
  #438 0x00650b10 in Fprogn (body=XIL(0x11b093db)) at eval.c:439
  #439 0x00650b36 in prog_ignore (body=XIL(0x11b033fb)) at eval.c:450
  #440 0x006521ad in Fwhile (args=XIL(0x11b033eb)) at eval.c:1068
  #441 0x00655117 in eval_sub (form=XIL(0x11b033db)) at eval.c:2486
  #442 0x00650b10 in Fprogn (body=XIL(0x11afd80b)) at eval.c:439
  #443 0x00651dee in FletX (args=XIL(0x11b0aa4b)) at eval.c:979
  #444 0x00655117 in eval_sub (form=XIL(0x11b0aabb)) at eval.c:2486
  #445 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #446 0x006574d8 in funcall_lambda (fun=XIL(0x11b0ac1b), nargs=2,
      arg_vector=0x657c370) at eval.c:3283
  #447 0x00656f4d in apply_lambda (fun=XIL(0x11b0ac2b), args=XIL(0x11c8b193),
      count=1312) at eval.c:3154
  #448 0x00655915 in eval_sub (form=XIL(0x11c8b183)) at eval.c:2625
  #449 0x006509f5 in Fif (args=XIL(0x1257bb4b)) at eval.c:394
  #450 0x00655117 in eval_sub (form=XIL(0x1257bb3b)) at eval.c:2486
  #451 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #452 0x00652152 in Flet (args=XIL(0x125814eb)) at eval.c:1047
  #453 0x00655117 in eval_sub (form=XIL(0x1258155b)) at eval.c:2486
  #454 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #455 0x006574d8 in funcall_lambda (fun=XIL(0x12ca82cb), nargs=1,
      arg_vector=0x657c844) at eval.c:3283
  #456 0x00656615 in funcall_general (fun=XIL(0x12ca82db), numargs=1,
      args=0x657c844) at eval.c:2994
  #457 0x00656804 in Ffuncall (nargs=2, args=0x657c840) at eval.c:3032
  #458 0x006552b4 in eval_sub (form=XIL(0x1270fcfb)) at eval.c:2507
  #459 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #460 0x00650a9a in Fcond (args=XIL(0x1270fd2b)) at eval.c:419
  #461 0x00655117 in eval_sub (form=XIL(0x1270fd9b)) at eval.c:2486
  #462 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #463 0x00651dee in FletX (args=XIL(0x1270fe3b)) at eval.c:979
  #464 0x00655117 in eval_sub (form=XIL(0x1270feab)) at eval.c:2486
  #465 0x006509f5 in Fif (args=XIL(0x1270fecb)) at eval.c:394
  #466 0x00655117 in eval_sub (form=XIL(0x1270febb)) at eval.c:2486
  #467 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #468 0x00651dee in FletX (args=XIL(0x1271072b)) at eval.c:979
  #469 0x00655117 in eval_sub (form=XIL(0x1271079b)) at eval.c:2486
  #470 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #471 0x00652152 in Flet (args=XIL(0x1271081b)) at eval.c:1047
  #472 0x00655117 in eval_sub (form=XIL(0x1271088b)) at eval.c:2486
  #473 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #474 0x00650a15 in Fif (args=XIL(0x127108ab)) at eval.c:395
  #475 0x00655117 in eval_sub (form=XIL(0x1271089b)) at eval.c:2486
  #476 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #477 0x00652152 in Flet (args=XIL(0x1271095b)) at eval.c:1047
  #478 0x00655117 in eval_sub (form=XIL(0x127109cb)) at eval.c:2486
  #479 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #480 0x006574d8 in funcall_lambda (fun=XIL(0x12710b2b), nargs=1,
      arg_vector=0x657d300) at eval.c:3283
  #481 0x00656f4d in apply_lambda (fun=XIL(0x12710b3b), args=XIL(0x127131fb),
      count=1008) at eval.c:3154
  #482 0x00655915 in eval_sub (form=XIL(0x127131eb)) at eval.c:2625
  #483 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #484 0x00652152 in Flet (args=XIL(0x127131db)) at eval.c:1047
  #485 0x00655117 in eval_sub (form=XIL(0x1271319b)) at eval.c:2486
  #486 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #487 0x006574d8 in funcall_lambda (fun=XIL(0x1271510b), nargs=1,
      arg_vector=0x657d630) at eval.c:3283
  #488 0x00656f4d in apply_lambda (fun=XIL(0x1271511b), args=XIL(0x12a1dd53),
      count=944) at eval.c:3154
  #489 0x00655915 in eval_sub (form=XIL(0x12a1dd43)) at eval.c:2625
  #490 0x006509f5 in Fif (args=XIL(0x12a1dd33)) at eval.c:394
  #491 0x00655117 in eval_sub (form=XIL(0x12a1dd23)) at eval.c:2486
  #492 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #493 0x00652152 in Flet (args=XIL(0x12a1dd13)) at eval.c:1047
  #494 0x00655117 in eval_sub (form=XIL(0x12a1dca3)) at eval.c:2486
  #495 0x00652d7d in internal_lisp_condition_case (var=XIL(0x9350758),
      bodyform=XIL(0x12a1dca3), handlers=XIL(0x12a1de5b)) at eval.c:1498
  #496 0x0065282d in Fcondition_case (args=XIL(0x12a1dc93)) at eval.c:1370
  #497 0x00655117 in eval_sub (form=XIL(0x12a1dc83)) at eval.c:2486
  #498 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #499 0x00650a9a in Fcond (args=XIL(0x12a1de7b)) at eval.c:419
  #500 0x00655117 in eval_sub (form=XIL(0x12a2e94b)) at eval.c:2486
  #501 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #502 0x006574d8 in funcall_lambda (fun=XIL(0x12a2eabb), nargs=2,
      arg_vector=0x657ddc8) at eval.c:3283
  #503 0x00656615 in funcall_general (fun=XIL(0x12a2eacb), numargs=2,
      args=0x657ddc8) at eval.c:2994
  #504 0x00656804 in Ffuncall (nargs=3, args=0x657ddc4) at eval.c:3032
  #505 0x00690361 in readevalloop_eager_expand_eval (val=XIL(0x12ca807b),
      macroexpand=XIL(0x4e30)) at lread.c:2418
  #506 0x00690ae8 in readevalloop (readcharfun=XIL(0x12b0153d), infile0=0x0,
      sourcename=XIL(0x12b013ec), printflag=false, unibyte=XIL(0),
      readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2600
  #507 0x00690e0f in Feval_buffer (buffer=XIL(0x12b0153d), printflag=XIL(0),
      filename=XIL(0x12b013ec), unibyte=XIL(0), do_allow_print=XIL(0x18))
      at lread.c:2673
  #508 0x006554d7 in eval_sub (form=XIL(0xa3184cb)) at eval.c:2549
  #509 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #510 0x00650a15 in Fif (args=XIL(0xa31842b)) at eval.c:395
  #511 0x00655117 in eval_sub (form=XIL(0xa31841b)) at eval.c:2486
  #512 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #513 0x00652152 in Flet (args=XIL(0xa31840b)) at eval.c:1047
  #514 0x00655117 in eval_sub (form=XIL(0xa3183cb)) at eval.c:2486
  #515 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #516 0x00652152 in Flet (args=XIL(0xa3180d3)) at eval.c:1047
  #517 0x00655117 in eval_sub (form=XIL(0xa317f73)) at eval.c:2486
  #518 0x006527b0 in Funwind_protect (args=XIL(0xa31859b)) at eval.c:1328
  #519 0x00655117 in eval_sub (form=XIL(0xa317f63)) at eval.c:2486
  #520 0x00650b10 in Fprogn (body=XIL(0xa31865b)) at eval.c:439
  #521 0x00652152 in Flet (args=XIL(0xa317db3)) at eval.c:1047
  #522 0x00655117 in eval_sub (form=XIL(0xa317c93)) at eval.c:2486
  #523 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #524 0x00650a15 in Fif (args=XIL(0xa317b8b)) at eval.c:395
  #525 0x00655117 in eval_sub (form=XIL(0xa317b3b)) at eval.c:2486
  #526 0x00650b10 in Fprogn (body=XIL(0)) at eval.c:439
  #527 0x006574d8 in funcall_lambda (fun=XIL(0xa318c5b), nargs=4,
      arg_vector=0x657edd8) at eval.c:3283
  #528 0x00656615 in funcall_general (fun=XIL(0xa318c6b), numargs=4,
      args=0x657edd8) at eval.c:2994
  #529 0x00656804 in Ffuncall (nargs=5, args=0x657edd4) at eval.c:3032
  #530 0x0068eaa2 in Fload (file=XIL(0x12b01164), noerror=XIL(0),
      nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1681
  #531 0x006554d7 in eval_sub (form=XIL(0x12b01153)) at eval.c:2549
  #532 0x00690af8 in readevalloop (readcharfun=XIL(0x4080), infile0=0x657f6e8,
      sourcename=XIL(0xa01e18c), printflag=false, unibyte=XIL(0),
      readfun=XIL(0), start=XIL(0), end=XIL(0)) at lread.c:2602
  #533 0x0068ee5b in Fload (file=XIL(0xa01dfac), noerror=XIL(0),
      nomessage=XIL(0), nosuffix=XIL(0), must_suffix=XIL(0)) at lread.c:1793
  #534 0x006554d7 in eval_sub (form=XIL(0xa01dfd3)) at eval.c:2549
  #535 0x00654c45 in Feval (form=XIL(0xa01dfd3), lexical=XIL(0x18))
      at eval.c:2396
  #536 0x00599024 in top_level_2 () at keyboard.c:1184
  #537 0x00652ed1 in internal_condition_case (bfun=0x598fb9 <top_level_2>,
      handlers=XIL(0x48), hfun=0x598846 <cmd_error>) at eval.c:1544
  #538 0x0059907d in top_level_1 (ignore=XIL(0)) at keyboard.c:1196
  #539 0x00652502 in internal_catch (tag=XIL(0x8790),
      func=0x59903b <top_level_1>, arg=XIL(0)) at eval.c:1224
  #540 0x00598ef9 in command_loop () at keyboard.c:1145
  #541 0x00598394 in recursive_edit_1 () at keyboard.c:754
  #542 0x00598595 in Frecursive_edit () at keyboard.c:837
  #543 0x0059485b in main (argc=9, argv=0x81e25f8) at emacs.c:2626

  Lisp Backtrace:
  0xa04e228 Lisp type 3
  "push" (0x656fd60)
  "if" (0x656fea0)
  "unless" (0x656ff80)
  "let" (0x6570100)
  "let" (0x6570280)
  "while" (0x65703e0)
  "let" (0x6570560)
  "dolist" (0x6570640)
  "let" (0x65707d0)
  "cond" (0x6570910)
  "pcase--split-match" (0x6570a20)
  "let*" (0x6570c00)
  "let" (0x6570d80)
  "while" (0x6570ee0)
  "let" (0x6571060)
  "dolist" (0x6571140)
  "let" (0x65712d0)
  "pcase--split-rest" (0x65713e0)
  "let*" (0x65715c0)
  "cond" (0x6571700)
  "let*" (0x6571860)
  "cond" (0x65719a0)
  "pcase--u1" (0x6571ab0)
  "let*" (0x6571cc0)
  "progn" (0x6571dd0)
  "if" (0x6571ee0)
  "when" (0x6571fc0)
  "pcase--u" (0x65720d0)
  "pcase--if" (0x65722b0)
  "let*" (0x6572410)
  "cond" (0x6572550)
  "let*" (0x65726b0)
  "cond" (0x65727f0)
  "pcase--u1" (0x6572900)
  "let*" (0x6572b10)
  "progn" (0x6572c20)
  "if" (0x6572d30)
  "when" (0x6572e10)
  "pcase--u" (0x6572f20)
  "pcase--if" (0x6573100)
  "let*" (0x6573260)
  "cond" (0x65733a0)
  "let*" (0x6573500)
  "cond" (0x6573640)
  "pcase--u1" (0x6573750)
  "let*" (0x6573960)
  "progn" (0x6573a70)
  "if" (0x6573b80)
  "when" (0x6573c60)
  "pcase--u" (0x6573d70)
  "pcase--if" (0x6573f50)
  "let*" (0x65740b0)
  "cond" (0x65741f0)
  "let*" (0x6574350)
  "cond" (0x6574490)
  "pcase--u1" (0x65745a0)
  "let*" (0x65747b0)
  "progn" (0x65748c0)
  "if" (0x65749d0)
  "when" (0x6574ab0)
  "pcase--u" (0x6574bc0)
  "let*" (0x6574d90)
  "let*" (0x6574ec0)
  "macroexp-let2" (0x6574fa0)
  "pcase-compile-patterns" (0x65750b0)
  "let*" (0x6575290)
  "pcase--expand" (0x65753a0)
  "let" (0x65755a0)
  "if" (0x65756e0)
  "let" (0x6575860)
  0x11a92f60 Lisp type 3
  "apply" (0x6575a90)
  "if" (0x6575c00)
  "cond" (0x6575d40)
  "let" (0x6575ec0)
  "if" (0x6576000)
  "if" (0x6576140)
  "let*" (0x65762a0)
  "cond" (0x65763e0)
  "macroexpand-1" (0x65764f0)
  "setq" (0x65766c0)
  "eq" (0x65767a0)
  "not" (0x6576880)
  "while" (0x6576990)
  "let*" (0x6576af0)
  "macroexp-macroexpand" (0x6576c00)
  "setq" (0x6576dd0)
  "if" (0x6576f10)
  "let" (0x6577090)
  "macroexp--expand-all" (0x65771a0)
  "if" (0x6577350)
  "progn" (0x6577460)
  "setq" (0x6577580)
  "progn" (0x6577690)
  "while" (0x65777f0)
  "let*" (0x6577950)
  "macroexp--all-forms" (0x6577a60)
  "if" (0x6577c20)
  "progn" (0x6577d30)
  "setq" (0x6577e50)
  "progn" (0x6577f60)
  "while" (0x65780c0)
  "let*" (0x6578220)
  "macroexp--all-clauses" (0x6578330)
  "macroexp--cons" (0x6578520)
  "macroexp--cons" (0x6578660)
  "let" (0x65787e0)
  "let" (0x6578970)
  "let*" (0x6578ad0)
  "progn" (0x6578be0)
  "let*" (0x6578d40)
  "cond" (0x6578e80)
  "let*" (0x6578fe0)
  "if" (0x65790f0)
  "let*" (0x6579250)
  "let" (0x65793d0)
  "if" (0x6579510)
  "let" (0x6579690)
  "macroexp--expand-all" (0x65797a0)
  "if" (0x6579950)
  "progn" (0x6579a60)
  "setq" (0x6579b80)
  "progn" (0x6579c90)
  "while" (0x6579df0)
  "let*" (0x6579f50)
  "macroexp--all-forms" (0x657a060)
  "macroexp--cons" (0x657a250)
  "macroexp--cons" (0x657a390)
  "let" (0x657a510)
  "let" (0x657a690)
  "if" (0x657a7a0)
  "let*" (0x657a900)
  "if" (0x657aa10)
  "let*" (0x657ab70)
  "if" (0x657ac80)
  "let*" (0x657ade0)
  "if" (0x657aef0)
  "let*" (0x657b050)
  "cond" (0x657b190)
  "let*" (0x657b2f0)
  "if" (0x657b400)
  "let*" (0x657b560)
  "let" (0x657b6e0)
  "if" (0x657b820)
  "let" (0x657b9a0)
  "macroexp--expand-all" (0x657bab0)
  "if" (0x657bc60)
  "progn" (0x657bd70)
  "setq" (0x657be90)
  "progn" (0x657bfa0)
  "while" (0x657c100)
  "let*" (0x657c260)
  "macroexp--all-forms" (0x657c370)
  "if" (0x657c530)
  "let" (0x657c6b0)
  0x12ca82d8 Lisp type 3
  "funcall" (0x657c840)
  "cond" (0x657c9e0)
  "let*" (0x657cb40)
  "if" (0x657cc50)
  "let*" (0x657cdb0)
  "let" (0x657cf30)
  "if" (0x657d070)
  "let" (0x657d1f0)
  "macroexp--expand-all" (0x657d300)
  "let" (0x657d520)
  "macroexpand--all-toplevel" (0x657d630)
  "if" (0x657d7e0)
  "let" (0x657d960)
  "condition-case" (0x657db00)
  "cond" (0x657dc40)
  "internal-macroexpand-for-load" (0x657ddc8)
  "eval-buffer" (0x657df50)
  "if" (0x657e0b0)
  "let" (0x657e230)
  "let" (0x657e3c0)
  "unwind-protect" (0x657e4d0)
  "let" (0x657e660)
  "if" (0x657e7a0)
  "load-with-code-conversion" (0x657edd8)
  "load" (0x657efe0)
  "load" (0x657f7e0)
  (gdb) fr 4
  #4  0x008071f1 in nailboardIndex (board=board@entry=0x9ba51ec,
      level=level@entry=2, addr=addr@entry=0xa01e007) at nailboard.c:205
  205       AVER_CRITICAL(i < nailboardLevelBits(nailboardNails(board), level));
  (gdb) l
  200
  201     static Index nailboardIndex(Nailboard board, Index level, Addr addr)
  202     {
  203       Index i = AddrOffset(RangeBase(&board->range), addr)
  204         >> (board->alignShift + level * LEVEL_SHIFT);
  205       AVER_CRITICAL(i < nailboardLevelBits(nailboardNails(board), level));
  206       return i;
  207     }
  208
  209
  (gdb) p i
  $1 = 1
  (gdb) p board->alignShift
  $2 = 3

I later established that nailboardLevelBits(nailboardNails(board), level)
also yields 1, thus violating the assertion.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 24 Apr 2024 18:48:25 +0200
>> 
>> Could you please walk up the stack frames? Is something from us there?
>
> Quite a lot, actually.  Here's the entire backtrace, for your fun:

>   #10 0x007e435b in _mps_fix2 (mps_ss=0x656f818, mps_ref_io=0x656f700)
>       at trace.c:1433
>   #11 0x006ef08a in fix_lisp_obj (ss=0x656f818, pobj=0xcd1aec <globals+396>)
>       at igc.c:428
>   #12 0x006ef27b in scan_staticvec (ss=0x656f818, start=0xccf940 <staticvec>,
>       end=0xcd1940 <consing_until_gc>, closure=0x0) at igc.c:534

Ah, finally familiar territory ;-). #

Seriously, this looks like (more down the stack) we're in the process of
allocating a cons, MPS finds it must collect, and things get rolling. In
#12, we're processing staticvec, fix_lisp_obj is called for processing
one of the entries, MPS_FIX12 is called and finds something is wrong.

If I had to make an uneducated guess, it doesn't like the reference we
pass to it.

The thing is that MPS_FIX1 should return true if a reference is
interesting for MPS_FIX2'ing it. My understanding of the docs would be
"if and only if" there reference is interesting for MPS_FIX2, but I
wouldn't swear that the docs says "iff". I think they don't say that
explicitly.

Anyway. In fact, I had cases before where I couldn't pass any arbitrary
reference to MPS_FIX1, because it would "falsely" return true, and
MPS_FIX2 would then complain.

That's the background/history of is_mps in igc.c.

Or IOW, I would propose to see what's special about the pointer in #12.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

[-- Attachment #1: Type: text/plain, Size: 281 bytes --]

> Did someone try a 32-bit build on GNU/Linux?  Maybe the above isn't
> Windows-specific, but has something to do with 32-bit builds?

I did a 32-bit build.  The build completed (curiously), but the
resulting Emacs fails on the first GC cycle.  The backtrace is attached.

Helmut


[-- Attachment #2: i686-session.txt --]
[-- Type: text/plain, Size: 5750 bytes --]

#0  0xf7fc7589 in __kernel_vsyscall ()
#1  0xf7c8a2e7 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2  0xf7c39111 in raise () from /lib/i386-linux-gnu/libc.so.6
#3  0x56656273 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647)
    at emacs.c:480
#4  0x566f65f0 in die (
    msg=0x568a6ec8 "i < nailboardLevelBits(nailboardNails(board), level)", 
    file=0x568a7064 "nailboard.c", line=205) at alloc.c:8334
#5  0x567c3a8a in igc_assert_fail (file=0x568a7064 "nailboard.c", line=205, 
    msg=0x568a6ec8 "i < nailboardLevelBits(nailboardNails(board), level)")
    at igc.c:84
#6  0x5684aa0a in mps_lib_assert_fail (file=0x568a7064 "nailboard.c", 
    line=205, 
    condition=0x568a6ec8 "i < nailboardLevelBits(nailboardNails(board), level)") at mpsliban.c:87
#7  0x5685829f in nailboardIndex (board=board@entry=0xe803eb14, 
    level=level@entry=2, addr=addr@entry=0xf79b6087) at nailboard.c:205
#8  0x568582d5 in nailboardIndexRange (
    ibaseReturn=ibaseReturn@entry=0xffffcbac, 
    ilimitReturn=ilimitReturn@entry=0xffffcba8, board=board@entry=0xe803eb14, 
    level=2, base=0xf79b5bf8, limit=0xf79b6088) at nailboard.c:232
#9  0x56858bf9 in NailboardIsResRange (board=<optimized out>, base=0xf79b5bf8, 
    limit=0xf79b6088) at nailboard.c:350
(More stack frames follow...)
(gdb) ba
#0  0xf7fc7589 in __kernel_vsyscall ()
#1  0xf7c8a2e7 in ?? () from /lib/i386-linux-gnu/libc.so.6
#2  0xf7c39111 in raise () from /lib/i386-linux-gnu/libc.so.6
#3  0x56656273 in terminate_due_to_signal (sig=6, backtrace_limit=2147483647)
    at emacs.c:480
#4  0x566f65f0 in die (
    msg=0x568a6ec8 "i < nailboardLevelBits(nailboardNails(board), level)", 
    file=0x568a7064 "nailboard.c", line=205) at alloc.c:8334
#5  0x567c3a8a in igc_assert_fail (file=0x568a7064 "nailboard.c", line=205, 
    msg=0x568a6ec8 "i < nailboardLevelBits(nailboardNails(board), level)")
    at igc.c:84
#6  0x5684aa0a in mps_lib_assert_fail (file=0x568a7064 "nailboard.c", 
    line=205, 
    condition=0x568a6ec8 "i < nailboardLevelBits(nailboardNails(board), level)") at mpsliban.c:87
#7  0x5685829f in nailboardIndex (board=board@entry=0xe803eb14, 
    level=level@entry=2, addr=addr@entry=0xf79b6087) at nailboard.c:205
#8  0x568582d5 in nailboardIndexRange (
    ibaseReturn=ibaseReturn@entry=0xffffcbac, 
    ilimitReturn=ilimitReturn@entry=0xffffcba8, board=board@entry=0xe803eb14, 
    level=2, base=0xf79b5bf8, limit=0xf79b6088) at nailboard.c:232
#9  0x56858bf9 in NailboardIsResRange (board=<optimized out>, base=0xf79b5bf8, 
    limit=0xf79b6088) at nailboard.c:350
#10 0x568441b2 in amcPinnedInterior (amc=0xe8000250, board=0xe803eb14, 
    base=0xf79b5bf8, limit=0xf79b6088) at poolamc.c:681
#11 0x56842ad6 in amcSegFix (seg=0xe80292f4, ss=0xffffce14, refIO=0xffffccbc)
    at poolamc.c:1604
#12 0x56829d25 in SegFix (seg=0xe80292f4, ss=0xffffce14, refIO=0xffffccbc)
    at seg.c:793
#13 0x5683762b in _mps_fix2 (mps_ss=0xffffce18, mps_ref_io=0xffffccf0)
    at trace.c:1433
#14 0x567c4152 in fix_lisp_obj (ss=0xffffce18, pobj=0x56cbcaac <echo_buffer+4>)
    at igc.c:434
#15 0x567c437a in scan_staticvec (ss=0xffffce18, start=0x56d0a2a0 <staticvec>, 
    end=0x56d0c2a0 <staticidx>, closure=0x0) at igc.c:540
#16 0x56837da8 in TraceScanArea (ss=0xffffce14, base=0x56d0a2a0 <staticvec>, 
    limit=0x56d0c2a0 <staticidx>, scan_area=0x567c42ff <scan_staticvec>, 
    closure=0x0) at trace.c:1566
#17 0x56823cce in RootScan (ss=0xffffce14, root=0xe80009a0) at root.c:540
#18 0x568354ae in traceScanRootRes (ts=ts@entry=1, rank=rank@entry=1, 
    arena=arena@entry=0xf7fc0000, root=0xe80009a0) at trace.c:528
#19 0x56835670 in traceScanRoot (root=0xe80009a0, arena=0xf7fc0000, rank=1, 
    ts=1) at trace.c:545
#20 rootFlip (root=0xe80009a0, p=0xffffcf30) at trace.c:580
#21 0x568240bd in RootsIterate (arena=0xf7fc0004, f=0x568354d4 <rootFlip>, 
    p=0xffffcf30) at root.c:665
#22 0x56838678 in traceFlip (trace=0xf7fc04fc) at trace.c:652
#23 TraceStart (trace=0xf7fc04fc, mortality=0.79999994469287583, 
    finishingTime=255124633) at trace.c:1694
#24 0x568392bf in TraceStartCollectAll (traceReturn=0xffffcfec, 
    arena=<optimized out>, why=4) at trace.c:1794
#25 0x5683a974 in ArenaStartCollect (globals=0xf7fc0004, why=4)
    at traceanc.c:634
#26 0x5683a9ed in ArenaCollect (globals=0xf7fc0004, why=4) at traceanc.c:652
#27 0x56812d12 in mps_arena_collect (arena=0xf7fc0000) at mpsi.c:313
#28 0x567c8aad in igc_collect () at igc.c:2520
#29 0x567c8adc in Figc__collect () at igc.c:2528
#30 0x5672eede in eval_sub (form=0xe8b1aedb) at eval.c:2532
#31 0x5672e674 in Feval (form=0xe8b1aedb, lexical=0x18) at eval.c:2396
#32 0x567307f8 in funcall_subr (subr=0x56cb9a80 <Seval>, numargs=2, 
    args=0xe722d0e8) at eval.c:3102
#33 0x5678344a in exec_byte_code (fun=0xe756f4c5, args_template=513, nargs=1, 
    args=0xe722d19c) at bytecode.c:829
#34 0x56730e30 in funcall_lambda (fun=0xe77adced, nargs=0, 
    arg_vector=0xffffd580) at eval.c:3200
#35 0x56730c3d in apply_lambda (fun=0xe77adced, args=0x0, count=64)
    at eval.c:3154
#36 0x5672f19b in eval_sub (form=0xe78791cb) at eval.c:2582
#37 0x5672e674 in Feval (form=0xe78791cb, lexical=0x18) at eval.c:2396
#38 0x5665e2c0 in top_level_2 () at keyboard.c:1184
#39 0x5672c526 in internal_condition_case (bfun=0x5665e244 <top_level_2>, 
    handlers=0x48, hfun=0x5665d980 <cmd_error>) at eval.c:1544
#40 0x5665e328 in top_level_1 (ignore=0x0) at keyboard.c:1196
#41 0x5672b9e0 in internal_catch (tag=0x71d0, func=0x5665e2db <top_level_1>, 
    arg=0x0) at eval.c:1224
#42 0x5665e160 in command_loop () at keyboard.c:1145
#43 0x5665d3df in recursive_edit_1 () at keyboard.c:754
#44 0x5665d63f in Frecursive_edit () at keyboard.c:837
#45 0x56658f1d in main (argc=3, argv=0xffffd9b4) at emacs.c:2626

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Date: Thu, 25 Apr 2024 06:54:50 +0200
> 
> > Did someone try a 32-bit build on GNU/Linux?  Maybe the above isn't
> > Windows-specific, but has something to do with 32-bit builds?
> 
> I did a 32-bit build.  The build completed (curiously), but the
> resulting Emacs fails on the first GC cycle.  The backtrace is attached.

Thanks.  The assertion violation is identical to what I get.  So I
think we have now confirmed that the problem is due to something that
is wrong in a 32-bit build of Emacs, and not specific to MS-Windows.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 24 Apr 2024 21:44:54 +0200
> 
> Or IOW, I would propose to see what's special about the pointer in #12.

"Special" in what way?  Since I can reproduce this at will, I can tell
you anything you want to know about that, just ask.  What do you want
to know about it?

The relevant portion of the backtrace is:

  #8  0x007eed88 in amcSegFix (seg=0x9a57490, ss=0x656f814, refIO=0x656f6cc)
      at poolamc.c:1604
  #9  0x007d5d16 in SegFix (seg=0x9a57490, ss=0x656f814, refIO=0x656f6cc)
      at seg.c:793
  #10 0x007e435b in _mps_fix2 (mps_ss=0x656f818, mps_ref_io=0x656f700)
      at trace.c:1433
  #11 0x006ef08a in fix_lisp_obj (ss=0x656f818, pobj=0xcd1aec <globals+396>)
      at igc.c:428
  #12 0x006ef27b in scan_staticvec (ss=0x656f818, start=0xccf940 <staticvec>,
      end=0xcd1940 <consing_until_gc>, closure=0x0) at igc.c:534
  #13 0x007e4a21 in TraceScanArea (ss=ss@entry=0x656f814,
      base=0xccf940 <staticvec>, limit=0xcd1940 <consing_until_gc>,
      scan_area=0x6ef20b <scan_staticvec>, closure=0x0) at trace.c:1566

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 24 Apr 2024 21:44:54 +0200
>> 
>> Or IOW, I would propose to see what's special about the pointer in #12.
>
> "Special" in what way?  

Good question. I must admit that I don't know what MPS_FIX1 "let's
through" that MPS_FIX2 doesn't like.

One could for example see in which general direction the pointer points
(is in DATA, is it pdumper_object_p, is_mps, ...). Or maybe control
stack? Or alignment?

Can you read something out the MPS code? Maybe there is a comment
somewhere shedding some light on what it doesn't like?

> Since I can reproduce this at will, I can tell you anything you want
> to know about that, just ask. What do you want to know about it?
>
> The relevant portion of the backtrace is:
>
>   #8  0x007eed88 in amcSegFix (seg=0x9a57490, ss=0x656f814, refIO=0x656f6cc)
>       at poolamc.c:1604
>   #9  0x007d5d16 in SegFix (seg=0x9a57490, ss=0x656f814, refIO=0x656f6cc)
>       at seg.c:793
>   #10 0x007e435b in _mps_fix2 (mps_ss=0x656f818, mps_ref_io=0x656f700)
>       at trace.c:1433
>   #11 0x006ef08a in fix_lisp_obj (ss=0x656f818, pobj=0xcd1aec <globals+396>)
>       at igc.c:428
>   #12 0x006ef27b in scan_staticvec (ss=0x656f818, start=0xccf940 <staticvec>,
>       end=0xcd1940 <consing_until_gc>, closure=0x0) at igc.c:534
>   #13 0x007e4a21 in TraceScanArea (ss=ss@entry=0x656f814,
>       base=0xccf940 <staticvec>, limit=0xcd1940 <consing_until_gc>,
>       scan_area=0x6ef20b <scan_staticvec>, closure=0x0) at trace.c:1566

Hm, don't know. Does staticidx look good? Is the reference tagged? If
so, what type is it? Can you determine if the Lisp obj looks ok?
There is also the igc_header in front of the object which one could look
at.

BTW, how large is that header in your case?

Are you using the default settings when building MPS? If not, maybe it
would be a good idea to start from there.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

On Thu, Apr 25 2024, Eli Zaretskii wrote:

>> I did a 32-bit build.  The build completed (curiously), but the
>> resulting Emacs fails on the first GC cycle.  The backtrace is attached.
>
> Thanks.  The assertion violation is identical to what I get.  So I
> think we have now confirmed that the problem is due to something that
> is wrong in a 32-bit build of Emacs, and not specific to MS-Windows.

The to_bytes function looks suspisious.  Here it helps to change it to:

 static mps_word_t
 to_bytes (mps_word_t nwords)
 {
-  return nwords << 3;
+  return nwords * sizeof (mps_word_t);
 }
 

Helmut

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

 The to_bytes function looks suspisious.  Here it helps to change it to:
>
>  static mps_word_t
>  to_bytes (mps_word_t nwords)
>  {
> -  return nwords << 3;
> +  return nwords * sizeof (mps_word_t);
>  }

Oops 

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Thu, 25 Apr 2024 09:39:45 +0200
> 
> Helmut Eller <eller.helmut@gmail.com> writes:
> 
>  The to_bytes function looks suspisious.  Here it helps to change it to:
> >
> >  static mps_word_t
> >  to_bytes (mps_word_t nwords)
> >  {
> > -  return nwords << 3;
> > +  return nwords * sizeof (mps_word_t);
> >  }
> 
> Oops 

I installed that, since it unbreaks the build: all the Lisp files are
now compiled successfully, and the build runs to completion.

The resulting Emacs starts up, but then crashes due to some problem
with Lisp strings.  I show below two backtraces from two crashes, they
are different, but in both cases the crash is because the contents of
what is supposed to be a 'struct Lisp string" appears to be garbled.
In both cases, the recipe is simple:

  emacs -Q
  C-x C-f src/xdisp.c RET
  Lean on C-v to scroll through the buffer

Sometimes the crash happens only after I release C-v, wait for a few
seconds, then lean on C-v again; not sure if this is relevant or just
a coincidence.

Here are the two backtraces.  Note that "xbacktrace" also reports a
bad address, which probably means some significant issue with Lisp
strings in general(??).

Could be some alignment problem?  MPS seems to use alignment of 4 on
32-bit platforms, but AFAIR Emacs wants alignment of 8 for Lisp
objects?

Backtrace #1:

  Thread 1 received signal SIGSEGV, Segmentation fault.
  0x00853bc6 in igc_make_string (nchars=74, nbytes=74, unibyte=false,
      clear=false) at igc.c:2683
  2683      s->u.s.data = alloc_string_data (nbytes, clear);
  (gdb) bt
  #0  0x00853bc6 in igc_make_string (nchars=74, nbytes=74, unibyte=false,
      clear=false) at igc.c:2683
  #1  0x00853c0c in igc_make_multibyte_string (nchars=74, nbytes=74, clear=false)
      at igc.c:2690
  #2  0x0077f302 in make_clear_multibyte_string (nchars=74, nbytes=74,
      clearit=false) at alloc.c:2633
  #3  0x0077f28c in make_clear_string (length=74, clearit=false) at alloc.c:2610
  #4  0x0077f2da in make_uninit_string (length=74) at alloc.c:2621
  #5  0x007bef43 in Fcopy_sequence (arg=XIL(0xa5d8c44)) at fns.c:791
  #6  0x0076569d in compile_pattern_1 (cp=0xdf8c88 <searchbufs+616>,
      pattern=XIL(0xa5d8c44), translate=XIL(0), posix=false) at search.c:131
  #7  0x00765a26 in compile_pattern (pattern=XIL(0xa5d8c44),
      regp=0xcfbd14 <main_thread+84>, translate=XIL(0), posix=false,
      multibyte=true) at search.c:236
  #8  0x00767754 in search_buffer_re (string=XIL(0xa5d8c44), pos=375685,
      pos_byte=375685, lim=376227, lim_byte=376227, n=1, trt=XIL(0),
      inverse_trt=XIL(0), posix=false) at search.c:1168
  #9  0x00768803 in search_buffer (string=XIL(0xa5d8c44), pos=375685,
      pos_byte=375685, lim=376227, lim_byte=376227, n=1, RE=true, trt=XIL(0),
      inverse_trt=XIL(0), posix=false) at search.c:1531
  #10 0x007674ab in search_command (string=XIL(0xa5d8c44),
      bound=make_fixnum(376227), noerror=XIL(0x18ce0ac8), count=XIL(0),
      direction=1, RE=true, posix=false) at search.c:1070
  #11 0x00769b5b in Fre_search_forward (regexp=XIL(0xa5d8c44),
      bound=make_fixnum(376227), noerror=XIL(0x18ce0ac8), count=XIL(0))
      at search.c:2298
  #12 0x007b6b49 in funcall_subr (subr=0xd02dc0 <Sre_search_forward>, numargs=3,
      args=0x1a2a732c) at eval.c:3106
  #13 0x00808e62 in exec_byte_code (fun=XIL(0xa4f0555), args_template=0,
      nargs=0, args=0x1a2a73c8) at bytecode.c:829
  #14 0x007b7126 in funcall_lambda (fun=XIL(0x12cbe14d), nargs=1,
      arg_vector=0x1a2a7100) at eval.c:3200
  #15 0x007b653c in funcall_general (fun=XIL(0x12cbe14d), numargs=1,
      args=0x1a2a7100) at eval.c:2982
  #16 0x007b681c in Ffuncall (nargs=2, args=0x1a2a70fc) at eval.c:3032
  #17 0x007b5f0b in run_hook_wrapped_funcall (nargs=2, args=0x1a2a70fc)
      at eval.c:2810
  #18 0x007b6173 in run_hook_with_args (nargs=2, args=0x1a2a70fc,
      funcall=0x7b5ed5 <run_hook_wrapped_funcall>) at eval.c:2891
  #19 0x007b5f48 in Frun_hook_wrapped (nargs=2, args=0x1a2a70fc) at eval.c:2825
  #20 0x007b6d16 in funcall_subr (subr=0xd050c0 <Srun_hook_wrapped>, numargs=2,
      args=0x1a2a70fc) at eval.c:3123
  #21 0x00808e62 in exec_byte_code (fun=XIL(0x19b3a5ad), args_template=514,
      nargs=2, args=0x1a2a7094) at bytecode.c:829
  #22 0x007b7126 in funcall_lambda (fun=XIL(0x19b39f85), nargs=1,
      arg_vector=0x66dae1c) at eval.c:3200
  #23 0x007b653c in funcall_general (fun=XIL(0x19b39f85), numargs=1,
      args=0x66dae1c) at eval.c:2982
  #24 0x007b681c in Ffuncall (nargs=2, args=0x66dae18) at eval.c:3032
  #25 0x007b3118 in internal_condition_case_n (bfun=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66dae18, handlers=XIL(0x18),
      hfun=0x606089 <dsafe_eval_handler>) at eval.c:1624
  #26 0x0060617d in dsafe__call (inhibit_quit=false, f=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66dae18) at xdisp.c:3067
  #27 0x00606231 in dsafe_call1 (f=XIL(0x18d07c08), arg=make_fixnum(374707))
      at xdisp.c:3097
  #28 0x00609e95 in handle_fontified_prop (it=0x66dbe3c) at xdisp.c:4616
  #29 0x00608b51 in handle_stop (it=0x66dbe3c) at xdisp.c:4136
  #30 0x00616553 in next_element_from_buffer (it=0x66dbe3c) at xdisp.c:9643
  #31 0x00612cfc in get_next_display_element (it=0x66dbe3c) at xdisp.c:8209
  #32 0x006443c2 in display_line (it=0x66dbe3c, cursor_vpos=0) at xdisp.c:25295
  #33 0x0063736f in try_window (window=XIL(0xa21c62d), pos=..., flags=0)
      at xdisp.c:21136
  #34 0x006338b3 in redisplay_window (window=XIL(0xa21c62d),
      just_this_one_p=true) at xdisp.c:20245
  #35 0x0062c8aa in redisplay_window_1 (window=XIL(0xa21c62d)) at xdisp.c:18023
  #36 0x007b2f9a in internal_condition_case_1 (
      bfun=0x62c865 <redisplay_window_1>, arg=XIL(0xa21c62d),
      handlers=XIL(0x19d2108b), hfun=0x62c6ed <redisplay_window_error>)
      at eval.c:1568
  #37 0x0062b7eb in redisplay_internal () at xdisp.c:17512
  #38 0x0062913c in redisplay () at xdisp.c:16562
  #39 0x006fca1e in read_char (commandflag=1, map=XIL(0x12cbd183),
      prev_event=XIL(0), used_mouse_menu=0x66df657, end_time=0x0)
      at keyboard.c:2678
  #40 0x0070ec99 in read_key_sequence (keybuf=0x66df7b0, prompt=XIL(0),
      dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true, prevent_redisplay=false,
      disable_text_conversion_p=false) at keyboard.c:10727
  #41 0x006f9791 in command_loop_1 () at keyboard.c:1429
  #42 0x007b2ee9 in internal_condition_case (bfun=0x6f9377 <command_loop_1>,
      handlers=XIL(0x48), hfun=0x6f8846 <cmd_error>) at eval.c:1544
  #43 0x006f8f91 in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #44 0x007b251a in internal_catch (tag=XIL(0x8790),
      func=0x6f8f6f <command_loop_2>, arg=XIL(0x48)) at eval.c:1224
  #45 0x006f8f27 in command_loop () at keyboard.c:1146
  #46 0x006f8394 in recursive_edit_1 () at keyboard.c:754
  #47 0x006f8595 in Frecursive_edit () at keyboard.c:837
  #48 0x006f485b in main (argc=2, argv=0x6752570) at emacs.c:2626

  Lisp Backtrace:
  "re-search-forward" (0x1a2a732c)
  Cannot access memory at address 0xa50535c
  (gdb) l
  2678    igc_make_string (size_t nchars, size_t nbytes, bool unibyte, bool clear)
  2679    {
  2680      struct Lisp_String *s = alloc (sizeof *s, IGC_OBJ_STRING, PVEC_FREE);
  2681      s->u.s.size = nchars;
  2682      s->u.s.size_byte = unibyte ? -1 : nbytes;
  2683      s->u.s.data = alloc_string_data (nbytes, clear);
  2684      return make_lisp_ptr (s, Lisp_String);
  2685    }
  2686
  2687    Lisp_Object
  (gdb) p s
  $1 = (struct Lisp_String *) 0x12d13ea8
  (gdb) p s->u
  Cannot access memory at address 0x12d13ea8
  (gdb) p *s
  Cannot access memory at address 0x12d13ea8

Backtrace #2:

  Thread 1 received signal SIGSEGV, Segmentation fault.
  SDATA (string=XIL(0xa5d535c)) at lisp.h:1689
  1689      return XSTRING (string)->u.s.data;
  (gdb) bt
  #0  SDATA (string=XIL(0xa5d535c)) at lisp.h:1689
  #1  0x007bef54 in Fcopy_sequence (arg=XIL(0xa5d535c)) at fns.c:792
  #2  0x0076569d in compile_pattern_1 (cp=0xdf8ef0 <searchbufs+1232>,
      pattern=XIL(0xa5d535c), translate=XIL(0), posix=false) at search.c:131
  #3  0x00765a26 in compile_pattern (pattern=XIL(0xa5d535c),
      regp=0xcfbd14 <main_thread+84>, translate=XIL(0), posix=false,
      multibyte=true) at search.c:236
  #4  0x00767754 in search_buffer_re (string=XIL(0xa5d535c), pos=377153,
      pos_byte=377153, lim=377161, lim_byte=377161, n=1, trt=XIL(0),
      inverse_trt=XIL(0), posix=false) at search.c:1168
  #5  0x00768803 in search_buffer (string=XIL(0xa5d535c), pos=377153,
      pos_byte=377153, lim=377161, lim_byte=377161, n=1, RE=true, trt=XIL(0),
      inverse_trt=XIL(0), posix=false) at search.c:1531
  #6  0x007674ab in search_command (string=XIL(0xa5d535c),
      bound=make_fixnum(377161), noerror=XIL(0x96ca4c0), count=XIL(0),
      direction=1, RE=true, posix=false) at search.c:1070
  #7  0x00769b5b in Fre_search_forward (regexp=XIL(0xa5d535c),
      bound=make_fixnum(377161), noerror=XIL(0x96ca4c0), count=XIL(0))
      at search.c:2298
  #8  0x007b6b49 in funcall_subr (subr=0xd02dc0 <Sre_search_forward>, numargs=3,
      args=0x1a2af4c8) at eval.c:3106
  #9  0x00808e62 in exec_byte_code (fun=XIL(0xa4fc955), args_template=1537,
      nargs=3, args=0x1a2af478) at bytecode.c:829
  #10 0x007b7126 in funcall_lambda (fun=XIL(0x12cd385d), nargs=1,
      arg_vector=0x1a2af180) at eval.c:3200
  #11 0x007b653c in funcall_general (fun=XIL(0x12cd385d), numargs=1,
      args=0x1a2af180) at eval.c:2982
  #12 0x007b681c in Ffuncall (nargs=2, args=0x1a2af17c) at eval.c:3032
  #13 0x007b5f0b in run_hook_wrapped_funcall (nargs=2, args=0x1a2af17c)
      at eval.c:2810
  #14 0x007b6173 in run_hook_with_args (nargs=2, args=0x1a2af17c,
      funcall=0x7b5ed5 <run_hook_wrapped_funcall>) at eval.c:2891
  #15 0x007b5f48 in Frun_hook_wrapped (nargs=2, args=0x1a2af17c) at eval.c:2825
  #16 0x007b6d16 in funcall_subr (subr=0xd050c0 <Srun_hook_wrapped>, numargs=2,
      args=0x1a2af17c) at eval.c:3123
  #17 0x00808e62 in exec_byte_code (fun=XIL(0x19b3a5ad), args_template=514,
      nargs=2, args=0x1a2af114) at bytecode.c:829
  #18 0x007b7126 in funcall_lambda (fun=XIL(0x19b39f85), nargs=1,
      arg_vector=0x66d81ec) at eval.c:3200
  #19 0x007b653c in funcall_general (fun=XIL(0x19b39f85), numargs=1,
      args=0x66d81ec) at eval.c:2982
  #20 0x007b681c in Ffuncall (nargs=2, args=0x66d81e8) at eval.c:3032
  #21 0x007b3118 in internal_condition_case_n (bfun=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66d81e8, handlers=XIL(0x18),
      hfun=0x606089 <dsafe_eval_handler>) at eval.c:1624
  #22 0x0060617d in dsafe__call (inhibit_quit=false, f=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66d81e8) at xdisp.c:3067
  #23 0x00606231 in dsafe_call1 (f=XIL(0x18d07c08), arg=make_fixnum(376207))
      at xdisp.c:3097
  #24 0x00609e95 in handle_fontified_prop (it=0x66dde28) at xdisp.c:4616
  #25 0x00608b51 in handle_stop (it=0x66dde28) at xdisp.c:4136
  #26 0x00616553 in next_element_from_buffer (it=0x66dde28) at xdisp.c:9643
  #27 0x00612cfc in get_next_display_element (it=0x66dde28) at xdisp.c:8209
  #28 0x00616fe7 in move_it_in_display_line_to (it=0x66dde28,
      to_charpos=1253211, to_x=-1, op=MOVE_TO_POS) at xdisp.c:10000
  #29 0x00619b08 in move_it_to (it=0x66dde28, to_charpos=1253211, to_x=-1,
      to_y=512, to_vpos=-1, op=10) at xdisp.c:10734
  #30 0x00683b52 in window_scroll_pixel_based (window=XIL(0xa21c62d), n=1,
      whole=true, noerror=false) at window.c:5961
  #31 0x00682bab in window_scroll (window=XIL(0xa21c62d), n=1, whole=true,
      noerror=false) at window.c:5652
  #32 0x00685d51 in scroll_command (window=XIL(0xa21c62d), n=XIL(0), direction=1)
      at window.c:6464
  #33 0x00685eaa in Fscroll_up (arg=XIL(0)) at window.c:6491
  #34 0x007b6ac2 in funcall_subr (subr=0xcff860 <Sscroll_up>, numargs=1,
      args=0x1a2af098) at eval.c:3100
  #35 0x00808e62 in exec_byte_code (fun=XIL(0x19b404bd), args_template=256,
      nargs=1, args=0x66df14c) at bytecode.c:829
  #36 0x007b7126 in funcall_lambda (fun=XIL(0x19b404bd), nargs=1,
      arg_vector=0x66df148) at eval.c:3200
  #37 0x007b653c in funcall_general (fun=XIL(0x19b404bd), numargs=1,
      args=0x66df148) at eval.c:2982
  #38 0x007b681c in Ffuncall (nargs=2, args=0x66df144) at eval.c:3032
  #39 0x007ac581 in Ffuncall_interactively (nargs=2, args=0x66df144)
      at callint.c:250
  #40 0x007b6d16 in funcall_subr (subr=0xd04ba0 <Sfuncall_interactively>,
      numargs=2, args=0x66df144) at eval.c:3123
  #41 0x007b64f1 in funcall_general (fun=XIL(0xd04ba5), numargs=2,
      args=0x66df144) at eval.c:2978
  #42 0x007b681c in Ffuncall (nargs=3, args=0x66df140) at eval.c:3032
  #43 0x007ae7f5 in Fcall_interactively (function=XIL(0x18d0e030),
      record_flag=XIL(0), keys=XIL(0xa424aa5)) at callint.c:789
  #44 0x007b6b10 in funcall_subr (subr=0xd04bc0 <Scall_interactively>,
      numargs=3, args=0x1a2af050) at eval.c:3104
  #45 0x00808e62 in exec_byte_code (fun=XIL(0x19eef345), args_template=1025,
      nargs=1, args=0x66df884) at bytecode.c:829
  #46 0x007b7126 in funcall_lambda (fun=XIL(0x19eef345), nargs=1,
      arg_vector=0x66df880) at eval.c:3200
  #47 0x007b653c in funcall_general (fun=XIL(0x19eef345), numargs=1,
      args=0x66df880) at eval.c:2982
  #48 0x007b681c in Ffuncall (nargs=2, args=0x66df87c) at eval.c:3032
  #49 0x006f9b74 in command_loop_1 () at keyboard.c:1550
  #50 0x007b2ee9 in internal_condition_case (bfun=0x6f9377 <command_loop_1>,
      handlers=XIL(0x48), hfun=0x6f8846 <cmd_error>) at eval.c:1544
  #51 0x006f8f91 in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #52 0x007b251a in internal_catch (tag=XIL(0x8790),
      func=0x6f8f6f <command_loop_2>, arg=XIL(0x48)) at eval.c:1224
  #53 0x006f8f27 in command_loop () at keyboard.c:1146
  #54 0x006f8394 in recursive_edit_1 () at keyboard.c:754
  #55 0x006f8595 in Frecursive_edit () at keyboard.c:837
  #56 0x006f485b in main (argc=2, argv=0x84d2570) at emacs.c:2626

  Lisp Backtrace:
  "re-search-forward" (0x1a2af4c8)
  Cannot access memory at address 0xa4fc35c
  (gdb) p string
  $1 = XIL(0xa5d535c)
  (gdb) xstring
  $2 = (struct Lisp_String *) 0xa5d5358
  Cannot access memory at address 0xa5d5364
  (gdb) ptype struct Lisp_String
  type = struct Lisp_String {
      union {
	  struct {...} s;
	  struct Lisp_String *next;
	  char gcaligned;
      } u;
  }
  (gdb) l
  1684       potentially GC.  */
  1685
  1686    INLINE unsigned char *
  1687    SDATA (Lisp_Object string)
  1688    {
  1689      return XSTRING (string)->u.s.data;
  1690    }
  1691    INLINE char *
  1692    SSDATA (Lisp_Object string)
  1693    {
  (gdb) p $2->u
  Cannot access memory at address 0xa5d5358

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> Date: Thu, 25 Apr 2024 13:34:45 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
> 
> Here are the two backtraces.  Note that "xbacktrace" also reports a
> bad address, which probably means some significant issue with Lisp
> strings in general(??).

One more backtrace below, obtained like the ones before, by scrolling
through xdisp.c.  This one doesn't seem to be due to Lisp strings, but
something that could actually be specific to MS-Windows.  At least the
comment there says so; Gerd, can you tell more about that comment and
what it means?

  igc.c:1584: Emacs fatal error: assertion failed: !"other"

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=22,
      backtrace_limit=2147483647) at emacs.c:443
  443       signal (sig, SIG_DFL);
  (gdb) bt
  #0  terminate_due_to_signal (sig=22, backtrace_limit=2147483647) at emacs.c:443
  #1  0x007825ab in die (msg=0xd46437 <i_fwd+1475> "!\"other\"",
      file=0xd4616a <i_fwd+758> "igc.c", line=1584) at alloc.c:8334
  #2  0x0084eca0 in igc_assert_fail (file=0xd4616a <i_fwd+758> "igc.c",
      line=1584, msg=0xd46437 <i_fwd+1475> "!\"other\"") at igc.c:84
  #3  0x00851f38 in fix_other (ss=0x66da1d4, o=0x13250008) at igc.c:1584
  #4  0x0085222c in fix_vector (ss=0x66da1d4, v=0x13250008) at igc.c:1661
  #5  0x00850e75 in dflt_scanx (ss=0x66da1d4, base_start=0x13250000,
      base_limit=0x13252000, closure=0x0) at igc.c:1202
  #6  0x0085109c in dflt_scan (ss=0x66da1d4, base_start=0x13250000,
      base_limit=0x13252000) at igc.c:1245
  #7  0x00944e32 in TraceScanFormat (ss=ss@entry=0x66da1d0,
      base=base@entry=0x13250000, limit=limit@entry=0x13252000) at trace.c:1539
  #8  0x0094faf1 in amcSegScan (totalReturn=0x66da22c, seg=0x9ca59c8,
      ss=0x66da1d0) at poolamc.c:1440
  #9  0x00935f8e in SegScan (totalReturn=totalReturn@entry=0x66da22c,
      seg=seg@entry=0x9ca59c8, ss=ss@entry=0x66da1d0) at seg.c:775
  #10 0x00944208 in traceScanSegRes (ts=ts@entry=1, rank=rank@entry=1,
      arena=arena@entry=0x1f0000, seg=seg@entry=0x9ca59c8) at trace.c:1205
  #11 0x00944381 in traceScanSeg (ts=1, rank=1, arena=arena@entry=0x1f0000,
      seg=0x9ca59c8) at trace.c:1267
  #12 0x0094571a in TraceAdvance (trace=0x1f0518) at trace.c:1728
  #13 0x00945a10 in TracePoll (workReturn=workReturn@entry=0x66da308,
      collectWorldReturn=collectWorldReturn@entry=0x66da30c,
      globals=globals@entry=0x1f0008, collectWorldAllowed=1) at trace.c:1849
  #14 0x009117d0 in ArenaPoll (globals=globals@entry=0x1f0008) at global.c:745
  #15 0x0091e005 in mps_ap_fill (p_o=0x66da3cc, mps_ap=0x9b16c10, size=32)
      at mpsi.c:1097
  #16 0x00853862 in alloc (size=32, type=IGC_OBJ_VECTOR, pvec_type=PVEC_MARKER)
      at igc.c:2590
  #17 0x00853c8b in igc_alloc_pseudovector (nwords_mem=5, nwords_lisp=0,
      nwords_zero=0, tag=PVEC_MARKER) at igc.c:2710
  #18 0x0077f998 in allocate_pseudovector (memlen=5, lisplen=0, zerolen=0,
      tag=PVEC_MARKER) at alloc.c:3782
  #19 0x007800bd in Fmake_marker () at alloc.c:4150
  #20 0x0076b26b in Fmatch_data (integers=XIL(0), reuse=XIL(0), reseat=XIL(0))
      at search.c:2913
  #21 0x007b6b10 in funcall_subr (subr=0xd02e80 <Smatch_data>, numargs=0,
      args=0x1a2024b8) at eval.c:3104
  #22 0x00808e62 in exec_byte_code (fun=XIL(0x19ab914d), args_template=0,
      nargs=0, args=0x1a2024b8) at bytecode.c:829
  #23 0x007b7126 in funcall_lambda (fun=XIL(0x12cb16d5), nargs=1,
      arg_vector=0x1a202100) at eval.c:3200
  #24 0x007b653c in funcall_general (fun=XIL(0x12cb16d5), numargs=1,
      args=0x1a202100) at eval.c:2982
  #25 0x007b681c in Ffuncall (nargs=2, args=0x1a2020fc) at eval.c:3032
  #26 0x007b5f0b in run_hook_wrapped_funcall (nargs=2, args=0x1a2020fc)
      at eval.c:2810
  #27 0x007b6173 in run_hook_with_args (nargs=2, args=0x1a2020fc,
      funcall=0x7b5ed5 <run_hook_wrapped_funcall>) at eval.c:2891
  #28 0x007b5f48 in Frun_hook_wrapped (nargs=2, args=0x1a2020fc) at eval.c:2825
  #29 0x007b6d16 in funcall_subr (subr=0xd050c0 <Srun_hook_wrapped>, numargs=2,
      args=0x1a2020fc) at eval.c:3123
  #30 0x00808e62 in exec_byte_code (fun=XIL(0x19a9a5ad), args_template=514,
      nargs=2, args=0x1a202094) at bytecode.c:829
  #31 0x007b7126 in funcall_lambda (fun=XIL(0x19a99f85), nargs=1,
      arg_vector=0x66dae1c) at eval.c:3200
  #32 0x007b653c in funcall_general (fun=XIL(0x19a99f85), numargs=1,
      args=0x66dae1c) at eval.c:2982
  #33 0x007b681c in Ffuncall (nargs=2, args=0x66dae18) at eval.c:3032
  #34 0x007b3118 in internal_condition_case_n (bfun=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66dae18, handlers=XIL(0x18),
      hfun=0x606089 <dsafe_eval_handler>) at eval.c:1624
  #35 0x0060617d in dsafe__call (inhibit_quit=false, f=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66dae18) at xdisp.c:3067
  #36 0x00606231 in dsafe_call1 (f=XIL(0x18c67c08), arg=make_fixnum(374707))
      at xdisp.c:3097
  #37 0x00609e95 in handle_fontified_prop (it=0x66dbe3c) at xdisp.c:4616
  #38 0x00608b51 in handle_stop (it=0x66dbe3c) at xdisp.c:4136
  #39 0x00616553 in next_element_from_buffer (it=0x66dbe3c) at xdisp.c:9643
  #40 0x00612cfc in get_next_display_element (it=0x66dbe3c) at xdisp.c:8209
  #41 0x006443c2 in display_line (it=0x66dbe3c, cursor_vpos=0) at xdisp.c:25295
  #42 0x0063736f in try_window (window=XIL(0xa21c62d), pos=..., flags=0)
      at xdisp.c:21136
  #43 0x006338b3 in redisplay_window (window=XIL(0xa21c62d),
      just_this_one_p=true) at xdisp.c:20245
  #44 0x0062c8aa in redisplay_window_1 (window=XIL(0xa21c62d)) at xdisp.c:18023
  #45 0x007b2f9a in internal_condition_case_1 (
      bfun=0x62c865 <redisplay_window_1>, arg=XIL(0xa21c62d),
      handlers=XIL(0x19c8108b), hfun=0x62c6ed <redisplay_window_error>)
      at eval.c:1568
  #46 0x0062b7eb in redisplay_internal () at xdisp.c:17512
  #47 0x0062913c in redisplay () at xdisp.c:16562
  #48 0x006fca1e in read_char (commandflag=1, map=XIL(0x12cb0713),
      prev_event=XIL(0), used_mouse_menu=0x66df657, end_time=0x0)
      at keyboard.c:2678
  #49 0x0070ec99 in read_key_sequence (keybuf=0x66df7b0, prompt=XIL(0),
      dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true, prevent_redisplay=false,
      disable_text_conversion_p=false) at keyboard.c:10727
  #50 0x006f9791 in command_loop_1 () at keyboard.c:1429
  #51 0x007b2ee9 in internal_condition_case (bfun=0x6f9377 <command_loop_1>,
      handlers=XIL(0x48), hfun=0x6f8846 <cmd_error>) at eval.c:1544
  #52 0x006f8f91 in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #53 0x007b251a in internal_catch (tag=XIL(0x8790),
      func=0x6f8f6f <command_loop_2>, arg=XIL(0x48)) at eval.c:1224
  #54 0x006f8f27 in command_loop () at keyboard.c:1146
  #55 0x006f8394 in recursive_edit_1 () at keyboard.c:754
  #56 0x006f8595 in Frecursive_edit () at keyboard.c:837
  #57 0x006f485b in main (argc=2, argv=0x80e2570) at emacs.c:2626

  Lisp Backtrace:
  "match-data" (0x1a2024b8)
  "c-beginning-of-macro" (0x1a202480)
  "c-append-to-state-cache" (0x1a202434)
  "c-parse-state-1" (0x1a2023e8)
  "c-parse-state" (0x1a2023c0)
  "c-get-fontification-context" (0x1a202374)
  0x12cbd610 PVEC_COMPILED
  "c-find-decl-spots" (0x1a2022a8)
  "c-font-lock-declarations" (0x1a20223c)
  "font-lock-fontify-keywords-region" (0x1a2021ec)
  "font-lock-default-fontify-region" (0x1a2021b0)
  "c-font-lock-fontify-region" (0x1a202174)
  "font-lock-fontify-region" (0x1a202138)
  0x12cb16d0 PVEC_COMPILED
  "run-hook-wrapped" (0x1a2020fc)
  "jit-lock--run-functions" (0x1a20208c)
  "jit-lock-fontify-now" (0x1a202040)
  "jit-lock-function" (0x66dae1c)
  "redisplay_internal (C function)" (0x0)
  (gdb) fr 3
  #3  0x00851f38 in fix_other (ss=0x66da1d4, o=0x13250008) at igc.c:1584
  1584        igc_assert (!"other");
  (gdb) l
  1579    {
  1580      MPS_SCAN_BEGIN (ss)
  1581      {
  1582        IGC_FIX_CALL_FN (ss, struct Lisp_Vector, o, fix_vectorlike);
  1583        // Not used on macOS. Some scroll bar stuff in w32?
  1584        igc_assert (!"other");
  1585      }
  1586      MPS_SCAN_END (ss);
  1587      return MPS_RES_OK;
  1588    }

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> Date: Thu, 25 Apr 2024 14:09:07 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> CC: emacs-devel@gnu.org
> 
> One more backtrace below, obtained like the ones before, by scrolling
> through xdisp.c.

And two more.  These seem to be related to bytecode, so probably are
the same problem as with Lisp strings.

  Thread 1 received signal SIGSEGV, Segmentation fault.
  0x0080c321 in exec_byte_code (fun=XIL(0xa4fc5cd), args_template=1537, nargs=3,
      args=0x1a1b03f8) at bytecode.c:1787
  1787              PUSH (vectorp[op - Bconstant]);
  (gdb) bt
  #0  0x0080c321 in exec_byte_code (fun=XIL(0xa4fc5cd), args_template=1537,
      nargs=3, args=0x1a1b03f8) at bytecode.c:1787
  #1  0x007b7126 in funcall_lambda (fun=XIL(0x12cfcf45), nargs=1,
      arg_vector=0x1a1b0100) at eval.c:3200
  #2  0x007b653c in funcall_general (fun=XIL(0x12cfcf45), numargs=1,
      args=0x1a1b0100) at eval.c:2982
  #3  0x007b681c in Ffuncall (nargs=2, args=0x1a1b00fc) at eval.c:3032
  #4  0x007b5f0b in run_hook_wrapped_funcall (nargs=2, args=0x1a1b00fc)
      at eval.c:2810
  #5  0x007b6173 in run_hook_with_args (nargs=2, args=0x1a1b00fc,
      funcall=0x7b5ed5 <run_hook_wrapped_funcall>) at eval.c:2891
  #6  0x007b5f48 in Frun_hook_wrapped (nargs=2, args=0x1a1b00fc) at eval.c:2825
  #7  0x007b6d16 in funcall_subr (subr=0xd050c0 <Srun_hook_wrapped>, numargs=2,
      args=0x1a1b00fc) at eval.c:3123
  #8  0x00808e62 in exec_byte_code (fun=XIL(0x19a4a5ad), args_template=514,
      nargs=2, args=0x1a1b0094) at bytecode.c:829
  #9  0x007b7126 in funcall_lambda (fun=XIL(0x19a49f85), nargs=1,
      arg_vector=0x66dae1c) at eval.c:3200
  #10 0x007b653c in funcall_general (fun=XIL(0x19a49f85), numargs=1,
      args=0x66dae1c) at eval.c:2982
  #11 0x007b681c in Ffuncall (nargs=2, args=0x66dae18) at eval.c:3032
  #12 0x007b3118 in internal_condition_case_n (bfun=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66dae18, handlers=XIL(0x18),
      hfun=0x606089 <dsafe_eval_handler>) at eval.c:1624
  #13 0x0060617d in dsafe__call (inhibit_quit=false, f=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66dae18) at xdisp.c:3067
  #14 0x00606231 in dsafe_call1 (f=XIL(0x18c17c08), arg=make_fixnum(376207))
      at xdisp.c:3097
  #15 0x00609e95 in handle_fontified_prop (it=0x66dbe3c) at xdisp.c:4616
  #16 0x00608b51 in handle_stop (it=0x66dbe3c) at xdisp.c:4136
  #17 0x00616553 in next_element_from_buffer (it=0x66dbe3c) at xdisp.c:9643
  #18 0x00612cfc in get_next_display_element (it=0x66dbe3c) at xdisp.c:8209
  #19 0x006443c2 in display_line (it=0x66dbe3c, cursor_vpos=0) at xdisp.c:25295
  #20 0x0063736f in try_window (window=XIL(0xa21c62d), pos=..., flags=0)
      at xdisp.c:21136
  #21 0x006338b3 in redisplay_window (window=XIL(0xa21c62d),
      just_this_one_p=true) at xdisp.c:20245
  #22 0x0062c8aa in redisplay_window_1 (window=XIL(0xa21c62d)) at xdisp.c:18023
  #23 0x007b2f9a in internal_condition_case_1 (
      bfun=0x62c865 <redisplay_window_1>, arg=XIL(0xa21c62d),
      handlers=XIL(0x19c3108b), hfun=0x62c6ed <redisplay_window_error>)
      at eval.c:1568
  #24 0x0062b7eb in redisplay_internal () at xdisp.c:17512
  #25 0x0062913c in redisplay () at xdisp.c:16562
  #26 0x006fca1e in read_char (commandflag=1, map=XIL(0x12cfbddb),
      prev_event=XIL(0), used_mouse_menu=0x66df657, end_time=0x0)
      at keyboard.c:2678
  #27 0x0070ec99 in read_key_sequence (keybuf=0x66df7b0, prompt=XIL(0),
      dont_downcase_last=false, can_return_switch_frame=true,
      fix_current_buffer=true, prevent_redisplay=false,
      disable_text_conversion_p=false) at keyboard.c:10727
  #28 0x006f9791 in command_loop_1 () at keyboard.c:1429
  #29 0x007b2ee9 in internal_condition_case (bfun=0x6f9377 <command_loop_1>,
      handlers=XIL(0x48), hfun=0x6f8846 <cmd_error>) at eval.c:1544
  #30 0x006f8f91 in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #31 0x007b251a in internal_catch (tag=XIL(0x8790),
      func=0x6f8f6f <command_loop_2>, arg=XIL(0x48)) at eval.c:1224
  #32 0x006f8f27 in command_loop () at keyboard.c:1146
  #33 0x006f8394 in recursive_edit_1 () at keyboard.c:754
  #34 0x006f8595 in Frecursive_edit () at keyboard.c:837
  #35 0x006f485b in main (argc=2, argv=0x592570) at emacs.c:2626

  Lisp Backtrace:
  Cannot access memory at address 0xa4fbfd4
  (gdb) fr 3
  #3  0x007b681c in Ffuncall (nargs=2, args=0x1a1b00fc) at eval.c:3032
  3032      Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
  (gdb) p args[0]
  $1 = XIL(0x12cfcf45)
  (gdb) xtype
  Lisp_Vectorlike
  Cannot access memory at address 0x12cfcf40
  (gdb) fr 11
  #11 0x007b681c in Ffuncall (nargs=2, args=0x66dae18) at eval.c:3032
  3032      Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
  (gdb) p args[0]
  $2 = XIL(0x18c17c08)
  (gdb) xtype
  Lisp_Symbol
  (gdb) xsymbol
  $3 = (struct Lisp_Symbol *) 0x19a49f68
  "jit-lock-function"
  (gdb) fr 0
  #0  0x0080c321 in exec_byte_code (fun=XIL(0xa4fc5cd), args_template=1537,
      nargs=3, args=0x1a1b03f8) at bytecode.c:1787
  1787              PUSH (vectorp[op - Bconstant]);
  (gdb) l
  1782            CASE_DEFAULT
  1783            CASE (Bconstant):
  1784              if (BYTE_CODE_SAFE
  1785                  && ! (Bconstant <= op && op < Bconstant + const_length))
  1786                emacs_abort ();
  1787              PUSH (vectorp[op - Bconstant]);
  1788              NEXT;
  1789            }
  1790        }
  1791
  (gdb) p vectorp
  $4 = (Lisp_Object *) 0xa4fc4fc
  (gdb) p op-Bconstant
  $5 = 19
  (gdb) p vectorp[0]
  Cannot access memory at address 0xa4fc4fc


  Thread 1 received signal SIGSEGV, Segmentation fault.
  0x0080b226 in exec_byte_code (fun=XIL(0xa4edefd), args_template=0, nargs=0,
      args=0x1a0fb58c) at bytecode.c:1434
  1434              PUSH (make_fixed_natnum (BEGV));
  (gdb) bt
  #0  0x0080b226 in exec_byte_code (fun=XIL(0xa4edefd), args_template=0,
      nargs=0, args=0x1a0fb58c) at bytecode.c:1434
  #1  0x007b7126 in funcall_lambda (fun=XIL(0x12cd5925), nargs=1,
      arg_vector=0x1a0fb180) at eval.c:3200
  #2  0x007b653c in funcall_general (fun=XIL(0x12cd5925), numargs=1,
      args=0x1a0fb180) at eval.c:2982
  #3  0x007b681c in Ffuncall (nargs=2, args=0x1a0fb17c) at eval.c:3032
  #4  0x007b5f0b in run_hook_wrapped_funcall (nargs=2, args=0x1a0fb17c)
      at eval.c:2810
  #5  0x007b6173 in run_hook_with_args (nargs=2, args=0x1a0fb17c,
      funcall=0x7b5ed5 <run_hook_wrapped_funcall>) at eval.c:2891
  #6  0x007b5f48 in Frun_hook_wrapped (nargs=2, args=0x1a0fb17c) at eval.c:2825
  #7  0x007b6d16 in funcall_subr (subr=0xd050c0 <Srun_hook_wrapped>, numargs=2,
      args=0x1a0fb17c) at eval.c:3123
  #8  0x00808e62 in exec_byte_code (fun=XIL(0x1988a5ad), args_template=514,
      nargs=2, args=0x1a0fb114) at bytecode.c:829
  #9  0x007b7126 in funcall_lambda (fun=XIL(0x19889f85), nargs=1,
      arg_vector=0x66d67fc) at eval.c:3200
  #10 0x007b653c in funcall_general (fun=XIL(0x19889f85), numargs=1,
      args=0x66d67fc) at eval.c:2982
  #11 0x007b681c in Ffuncall (nargs=2, args=0x66d67f8) at eval.c:3032
  #12 0x007b3118 in internal_condition_case_n (bfun=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66d67f8, handlers=XIL(0x18),
      hfun=0x606089 <dsafe_eval_handler>) at eval.c:1624
  #13 0x0060617d in dsafe__call (inhibit_quit=false, f=0x7b6698 <Ffuncall>,
      nargs=2, args=0x66d67f8) at xdisp.c:3067
  #14 0x00606231 in dsafe_call1 (f=XIL(0x18a57c08), arg=make_fixnum(960261))
      at xdisp.c:3097
  #15 0x00609e95 in handle_fontified_prop (it=0x66dc418) at xdisp.c:4616
  #16 0x00608b51 in handle_stop (it=0x66dc418) at xdisp.c:4136
  #17 0x00616553 in next_element_from_buffer (it=0x66dc418) at xdisp.c:9643
  #18 0x00612cfc in get_next_display_element (it=0x66dc418) at xdisp.c:8209
  #19 0x00616fe7 in move_it_in_display_line_to (it=0x66dc418, to_charpos=961261,
      to_x=-1, op=(MOVE_TO_VPOS | MOVE_TO_POS)) at xdisp.c:10000
  #20 0x00619927 in move_it_to (it=0x66dc418, to_charpos=961261, to_x=-1,
      to_y=-1, to_vpos=1, op=12) at xdisp.c:10673
  #21 0x0061a788 in move_it_vertically_backward (it=0x66dde28, dy=512)
      at xdisp.c:11033
  #22 0x00683a21 in window_scroll_pixel_based (window=XIL(0xa21c62d), n=-1,
      whole=true, noerror=false) at window.c:5938
  #23 0x00682bab in window_scroll (window=XIL(0xa21c62d), n=-1, whole=true,
      noerror=false) at window.c:5652
  #24 0x00685d51 in scroll_command (window=XIL(0xa21c62d), n=XIL(0),
      direction=-1) at window.c:6464
  #25 0x00685eda in Fscroll_down (arg=XIL(0)) at window.c:6504
  #26 0x007b6ac2 in funcall_subr (subr=0xcff880 <Sscroll_down>, numargs=1,
      args=0x1a0fb098) at eval.c:3100
  #27 0x00808e62 in exec_byte_code (fun=XIL(0x1989031d), args_template=256,
      nargs=1, args=0x66df14c) at bytecode.c:829
  #28 0x007b7126 in funcall_lambda (fun=XIL(0x1989031d), nargs=1,
      arg_vector=0x66df148) at eval.c:3200
  #29 0x007b653c in funcall_general (fun=XIL(0x1989031d), numargs=1,
      args=0x66df148) at eval.c:2982
  #30 0x007b681c in Ffuncall (nargs=2, args=0x66df144) at eval.c:3032
  #31 0x007ac581 in Ffuncall_interactively (nargs=2, args=0x66df144)
      at callint.c:250
  #32 0x007b6d16 in funcall_subr (subr=0xd04ba0 <Sfuncall_interactively>,
      numargs=2, args=0x66df144) at eval.c:3123
  #33 0x007b64f1 in funcall_general (fun=XIL(0xd04ba5), numargs=2,
      args=0x66df144) at eval.c:2978
  #34 0x007b681c in Ffuncall (nargs=3, args=0x66df140) at eval.c:3032
  #35 0x007ae7f5 in Fcall_interactively (function=XIL(0x18a5dee0),
      record_flag=XIL(0), keys=XIL(0xa424665)) at callint.c:789
  #36 0x007b6b10 in funcall_subr (subr=0xd04bc0 <Scall_interactively>,
      numargs=3, args=0x1a0fb050) at eval.c:3104
  #37 0x00808e62 in exec_byte_code (fun=XIL(0x19c3f345), args_template=1025,
      nargs=1, args=0x66df884) at bytecode.c:829
  #38 0x007b7126 in funcall_lambda (fun=XIL(0x19c3f345), nargs=1,
      arg_vector=0x66df880) at eval.c:3200
  #39 0x007b653c in funcall_general (fun=XIL(0x19c3f345), numargs=1,
      args=0x66df880) at eval.c:2982
  #40 0x007b681c in Ffuncall (nargs=2, args=0x66df87c) at eval.c:3032
  #41 0x006f9b74 in command_loop_1 () at keyboard.c:1550
  #42 0x007b2ee9 in internal_condition_case (bfun=0x6f9377 <command_loop_1>,
      handlers=XIL(0x48), hfun=0x6f8846 <cmd_error>) at eval.c:1544
  #43 0x006f8f91 in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #44 0x007b251a in internal_catch (tag=XIL(0x8790),
      func=0x6f8f6f <command_loop_2>, arg=XIL(0x48)) at eval.c:1224
  #45 0x006f8f27 in command_loop () at keyboard.c:1146
  #46 0x006f8394 in recursive_edit_1 () at keyboard.c:754
  #47 0x006f8595 in Frecursive_edit () at keyboard.c:837
  #48 0x006f485b in main (argc=2, argv=0x1f2570) at emacs.c:2626

  Lisp Backtrace:
  Cannot access memory at address 0xa51064c

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 09:39:45 +0200
>> 
>> Helmut Eller <eller.helmut@gmail.com> writes:
>> 
>>  The to_bytes function looks suspisious.  Here it helps to change it to:
>> >
>> >  static mps_word_t
>> >  to_bytes (mps_word_t nwords)
>> >  {
>> > -  return nwords << 3;
>> > +  return nwords * sizeof (mps_word_t);
>> >  }
>> 
>> Oops 
>
> I installed that, since it unbreaks the build: all the Lisp files are
> now compiled successfully, and the build runs to completion.

Great!

> The resulting Emacs starts up, but then crashes due to some problem
> with Lisp strings.  I show below two backtraces from two crashes, they
> are different, but in both cases the crash is because the contents of
> what is supposed to be a 'struct Lisp string" appears to be garbled.
> In both cases, the recipe is simple:
>
>   emacs -Q
>   C-x C-f src/xdisp.c RET
>   Lean on C-v to scroll through the buffer

Not too bad that it starts at all :-). I didn't do much to ensure that
works so far.

> Sometimes the crash happens only after I release C-v, wait for a few
> seconds, then lean on C-v again; not sure if this is relevant or just
> a coincidence.

Yeah there a probably a number of data structures containing
Lisp_Objects and alike in the GUI code that are currently not traced.
Twice so if they don't exist on macOS.

> Here are the two backtraces.  Note that "xbacktrace" also reports a
> bad address, which probably means some significant issue with Lisp
> strings in general(??).
>
> Could be some alignment problem?  MPS seems to use alignment of 4 on
> 32-bit platforms, but AFAIR Emacs wants alignment of 8 for Lisp
> objects?

The alignment of MPS objects is specified around line 2761 in igc.c

    MPS_ARGS_ADD (args, MPS_KEY_FMT_ALIGN, IGC_ALIGN);

IGC_ALIGN == GCALIGNMENT at present, which is 8 for me (USE_LSB_TAG).

>
> Backtrace #1:
> Backtrace #2:

No idea at the moment, but we should make sure to trace everything
reachable in a GUI frames first. Before that's done, it's basically
guaranteed to crash at soem point.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Thu, 25 Apr 2024 13:34:45 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
>> 
>> Here are the two backtraces.  Note that "xbacktrace" also reports a
>> bad address, which probably means some significant issue with Lisp
>> strings in general(??).
>
> One more backtrace below, obtained like the ones before, by scrolling
> through xdisp.c.  This one doesn't seem to be due to Lisp strings, but
> something that could actually be specific to MS-Windows.  At least the
> comment there says so; Gerd, can you tell more about that comment and
> what it means?
>
>   igc.c:1584: Emacs fatal error: assertion failed: !"other"

This type of Lisp object is not used on macOS at all. The assert is a
friendly reminder that I don't know what to do with it :-).

Re: Building the igc branch on MS-Windows

[Helmut Eller]

On Thu, Apr 25 2024, Eli Zaretskii wrote:

>   emacs -Q
>   C-x C-f src/xdisp.c RET
>   Lean on C-v to scroll through the buffer

This crashes for me too.  But only with the GTK GUI; in TTY mode it
works.  I even found an easier way to let the GUI version crash:

./src/emacs -Q src/xdisp.c -eval '(igc--collect)'

Helmut

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

On 2024-04-25 14:35, Helmut Eller wrote:
> On Thu, Apr 25 2024, Eli Zaretskii wrote:
> 
>>    emacs -Q
>>    C-x C-f src/xdisp.c RET
>>    Lean on C-v to scroll through the buffer
> 
> This crashes for me too.  But only with the GTK GUI; in TTY mode it
> works.  I even found an easier way to let the GUI version crash:
> 
> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)'


I would start by investigating what stuff reachable from struct frame is 
and is not traced, which depends a bit on the platform. Also font stuff 
probably, terminals, scroll bar things (at least in NS I know there is 
something), and I don't know what else.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Apr 2024 13:59:22 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Date: Thu, 25 Apr 2024 13:34:45 +0300
> >> From: Eli Zaretskii <eliz@gnu.org>
> >> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
> >> 
> >> Here are the two backtraces.  Note that "xbacktrace" also reports a
> >> bad address, which probably means some significant issue with Lisp
> >> strings in general(??).
> >
> > One more backtrace below, obtained like the ones before, by scrolling
> > through xdisp.c.  This one doesn't seem to be due to Lisp strings, but
> > something that could actually be specific to MS-Windows.  At least the
> > comment there says so; Gerd, can you tell more about that comment and
> > what it means?
> >
> >   igc.c:1584: Emacs fatal error: assertion failed: !"other"
> 
> This type of Lisp object is not used on macOS at all.

Which type is that?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Apr 2024 13:55:53 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Could be some alignment problem?  MPS seems to use alignment of 4 on
> > 32-bit platforms, but AFAIR Emacs wants alignment of 8 for Lisp
> > objects?
> 
> The alignment of MPS objects is specified around line 2761 in igc.c

(FTR: it's line 2908 now.)

> 
>     MPS_ARGS_ADD (args, MPS_KEY_FMT_ALIGN, IGC_ALIGN);
> 
> IGC_ALIGN == GCALIGNMENT at present, which is 8 for me (USE_LSB_TAG).

It's 8 for me as well, since that's Emacs's requirement since about
forever.  But you are on a 64-bit platform, where MPS uses alignment
of 8, whereas I'm on 32-bit, where MPS uses alignment of 4.  Can this
be a problem for some reason?

> > Backtrace #1:
> > Backtrace #2:
> 
> No idea at the moment, but we should make sure to trace everything
> reachable in a GUI frames first. Before that's done, it's basically
> guaranteed to crash at soem point.

Ah, okay.  I wasn't aware that such basics are not yet covered.  So,
with the display stuff out of scope, what else is worth testing in
this build?  Byte compilation works, as is shown by building the
entire tree.  Tree-sitter support needs finalizers to be ... ahm
... finalized first.  What else is there that is supposed to work with
the current source?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

On 2024-04-25 15:22, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 13:59:22 +0200
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> Date: Thu, 25 Apr 2024 13:34:45 +0300
>>>> From: Eli Zaretskii <eliz@gnu.org>
>>>> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
>>>>
>>>> Here are the two backtraces.  Note that "xbacktrace" also reports a
>>>> bad address, which probably means some significant issue with Lisp
>>>> strings in general(??).
>>>
>>> One more backtrace below, obtained like the ones before, by scrolling
>>> through xdisp.c.  This one doesn't seem to be due to Lisp strings, but
>>> something that could actually be specific to MS-Windows.  At least the
>>> comment there says so; Gerd, can you tell more about that comment and
>>> what it means?
>>>
>>>    igc.c:1584: Emacs fatal error: assertion failed: !"other"
>>
>> This type of Lisp object is not used on macOS at all.
> 
> Which type is that?

PVEC_OTHER, don't know to what struct that maps.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 13:55:53 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Could be some alignment problem?  MPS seems to use alignment of 4 on
>> > 32-bit platforms, but AFAIR Emacs wants alignment of 8 for Lisp
>> > objects?
>> 
>> The alignment of MPS objects is specified around line 2761 in igc.c
>
> (FTR: it's line 2908 now.)

Yes, I'm a bit lagging behind because I didn't want to rock the boat
while debugging the native compilation.

>>     MPS_ARGS_ADD (args, MPS_KEY_FMT_ALIGN, IGC_ALIGN);
>> 
>> IGC_ALIGN == GCALIGNMENT at present, which is 8 for me (USE_LSB_TAG).
>
> It's 8 for me as well, since that's Emacs's requirement since about
> forever.  But you are on a 64-bit platform, where MPS uses alignment
> of 8, whereas I'm on 32-bit, where MPS uses alignment of 4.  Can this
> be a problem for some reason?

I don't think so since we specify our own alignment.

>> > Backtrace #1:
>> > Backtrace #2:
>> 
>> No idea at the moment, but we should make sure to trace everything
>> reachable in a GUI frames first. Before that's done, it's basically
>> guaranteed to crash at soem point.
>
> Ah, okay.  I wasn't aware that such basics are not yet covered.  So,
> with the display stuff out of scope, what else is worth testing in
> this build?  

The glyph matrix stuff might actually work, for some value of work. Also
faces/cache. It's more the output_data stuff, fonts, maybe. Where things were
obvious, I tried to do at least something, like install ambig roots, and
such.

> Byte compilation works, as is shown by building the entire tree.
> Tree-sitter support needs finalizers to be ... ahm ... finalized
> first. What else is there that is supposed to work with the current
> source?

Great! I'm not using treesitter, so I haven't checked, but
the finalizers are there and should finalize, at least in theory.

Also interesting woujld be if igc_on_idle is called in the right place,
or if it could/should be called elsewhere. Igc_on_idle does 100ms of GC
work, and processes MPS messages (finalization, GC start, ...).

My plan after getting native-comp working, would have been to tackle
interactive use. Alas, I tripped over an LLDB problem yesterday that I
want to get out of the way first.

Anyway. Another interesting question would be how to possibly automate
(random) testing of the GUI somehow. Do we have something that goe sin
that direction?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Thu, 25 Apr 2024 16:00:21 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Byte compilation works, as is shown by building the entire tree.
> > Tree-sitter support needs finalizers to be ... ahm ... finalized
> > first. What else is there that is supposed to work with the current
> > source?
> 
> Great! I'm not using treesitter, so I haven't checked, but
> the finalizers are there and should finalize, at least in theory.

OK, I will build with tree-sitter then and see how that works.

> Also interesting woujld be if igc_on_idle is called in the right place,
> or if it could/should be called elsewhere. Igc_on_idle does 100ms of GC
> work, and processes MPS messages (finalization, GC start, ...).

I'll take a look.

> My plan after getting native-comp working, would have been to tackle
> interactive use. Alas, I tripped over an LLDB problem yesterday that I
> want to get out of the way first.
> 
> Anyway. Another interesting question would be how to possibly automate
> (random) testing of the GUI somehow. Do we have something that goe sin
> that direction?

No, we don't have any automated testing of GUI, unfortunately.
There's test/src/xdisp-tests.el, which attempts to test what little
that can be done in batch mode, and there are a few tests in
test/manual/, which must be run interactively.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Thu, 25 Apr 2024 16:00:21 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Byte compilation works, as is shown by building the entire tree.
>> > Tree-sitter support needs finalizers to be ... ahm ... finalized
>> > first. What else is there that is supposed to work with the current
>> > source?
>> 
>> Great! I'm not using treesitter, so I haven't checked, but
>> the finalizers are there and should finalize, at least in theory.
>
> OK, I will build with tree-sitter then and see how that works.
>
>> Also interesting woujld be if igc_on_idle is called in the right place,
>> or if it could/should be called elsewhere. Igc_on_idle does 100ms of GC
>> work, and processes MPS messages (finalization, GC start, ...).
>
> I'll take a look.
>
>> My plan after getting native-comp working, would have been to tackle
>> interactive use. Alas, I tripped over an LLDB problem yesterday that I
>> want to get out of the way first.
>> 
>> Anyway. Another interesting question would be how to possibly automate
>> (random) testing of the GUI somehow. Do we have something that goe sin
>> that direction?
>
> No, we don't have any automated testing of GUI, unfortunately.
> There's test/src/xdisp-tests.el, which attempts to test what little
> that can be done in batch mode, and there are a few tests in
> test/manual/, which must be run interactively.

Thanks!

Re: Building the igc branch on MS-Windows

[Helmut Eller]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Thu, Apr 25 2024, Gerd Möllmann wrote:

>> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)'
>
> I would start by investigating what stuff reachable from struct frame
> is and is not traced, which depends a bit on the platform. Also font
> stuff probably, terminals, scroll bar things (at least in NS I know
> there is something), and I don't know what else.

The problem was a corrupted font.  I added the code below and it now
survives the first GC cycle.  In general, fix_frame must scan the same
fields as mark_frame in alloc.c does.  Is that about right?  Since MPS
wants the address of the fields (instead the value), some creativity may
be required.  Is that also right?  Or can I stupidly copy what
mark_frame does?

Helmut


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: igc.diff --]
[-- Type: text/x-diff, Size: 742 bytes --]

diff --git a/src/igc.c b/src/igc.c
index c2dd837a455..2f0c78eb589 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -45,6 +45,9 @@
 #include "thread.h"
 #include "treesit.h"
 #include "puresize.h"
+#ifdef HAVE_WINDOW_SYSTEM
+#include TERM_HEADER
+#endif /* HAVE_WINDOW_SYSTEM */
 
 #ifndef USE_LSB_TAG
 # error "USE_LSB_TAG required"
@@ -1316,6 +1319,15 @@ fix_frame (mps_ss_t ss, struct frame *f)
     IGC_FIX12_RAW (ss, &f->face_cache);
     if (f->terminal)
       IGC_FIX12_RAW (ss, &f->terminal);
+#ifdef HAVE_WINDOW_SYSTEM
+    if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
+      {
+	struct font *font = FRAME_FONT (f);
+	if (font)
+	  IGC_FIX12_RAW(ss, &FRAME_FONT (f));
+      }
+#endif
+
   }
   MPS_SCAN_END (ss);
   return MPS_RES_OK;

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Thu, Apr 25 2024, Gerd Möllmann wrote:
>
>>> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)'
>>
>> I would start by investigating what stuff reachable from struct frame
>> is and is not traced, which depends a bit on the platform. Also font
>> stuff probably, terminals, scroll bar things (at least in NS I know
>> there is something), and I don't know what else.
>
> The problem was a corrupted font.  I added the code below and it now
> survives the first GC cycle.  

Great! :-)

> In general, fix_frame must scan the same fields as mark_frame in
> alloc.c does. Is that about right? 

Yes, plus it must also fix pointers to interesting objects, which
mark_frame doesn't need to do. LIke you did with the font.

(Some objects I ahve also moved to MPS, which were previously malloc'd,
itree_tree for examole, but I think I got these covered already
(itree_node, for example.))

> Since MPS wants the address of the fields (instead the value), some
> creativity may be required. Is that also right? Or can I stupidly copy
> what mark_frame does?

Basically yes. The address of the fields is only needed because MPS_FIX2
can give us a new address, which we then have to store where the
reference comes from.

(Consider your change pushed in 1s :-).

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 09:18:59 +0200
> 
> >> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)'
> >
> > I would start by investigating what stuff reachable from struct frame
> > is and is not traced, which depends a bit on the platform. Also font
> > stuff probably, terminals, scroll bar things (at least in NS I know
> > there is something), and I don't know what else.
> 
> The problem was a corrupted font.  I added the code below and it now
> survives the first GC cycle.  In general, fix_frame must scan the same
> fields as mark_frame in alloc.c does.  Is that about right?  Since MPS
> wants the address of the fields (instead the value), some creativity may
> be required.  Is that also right?  Or can I stupidly copy what
> mark_frame does?

Thanks, I cannot answer all of the questions above, but I nevertheless
installed this in your name, with one difference:

> +    if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
> +      {
> +	struct font *font = FRAME_FONT (f);
> +	if (font)
> +	  IGC_FIX12_RAW(ss, &FRAME_FONT (f));

You already used FRAME_FONT, so not necessary to use it again:

    if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
      {
	struct font *font = FRAME_FONT (f);
	if (font)
	  IGC_FIX12_RAW(ss, &font);  <<<<<<<<<<<<<<<<<<<<<
      }

However, the crashes while scrolling through xdisp.c are still there.
I just had 2 of them; backtraces below.  It sounds like the first one
is due to Lisp strings, but the second one is related to markers.

  igc.c:1584: Emacs fatal error: assertion failed: !"other"

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
  442     {
  (gdb) bt
  #0  terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
  #1  0x00858430 in die (msg=msg@entry=0xde4937 <i_fwd+1479> "!\"other\"",
      file=file@entry=0xde4500 <i_fwd+400> "igc.c", line=line@entry=1584)
      at alloc.c:8334
  #2  0x00911482 in igc_assert_fail (msg=0xde4937 <i_fwd+1479> "!\"other\"",
      line=1584, file=0xde4500 <i_fwd+400> "igc.c") at igc.c:84
  #3  fix_other (o=0x13ca4008, ss=0x6fb83c8) at igc.c:1584
  #4  fix_vector (v=0x13ca4008, ss=0x6fb83c8) at igc.c:1661
  #5  dflt_scanx (ss=ss@entry=0x6fb83c8, base_start=<optimized out>,
      base_start@entry=0x13ca4000, base_limit=base_limit@entry=0x13ca6000,
      closure=closure@entry=0x0) at igc.c:1202
  #6  0x009116c2 in dflt_scan (ss=0x6fb83c8, base_start=0x13ca4000,
      base_limit=0x13ca6000) at igc.c:1245
  #7  0x009defa6 in TraceScanFormat (limit=0x13ca6000, base=0x13ca4000,
      ss=0x6fb83c4) at trace.c:1539
  #8  amcSegScan (totalReturn=0x6fb83c0, seg=0xa4b538c, ss=0x6fb83c4)
      at poolamc.c:1440
  #9  0x009feb25 in traceScanSegRes (seg=0xa4b538c, arena=0x1f0000,
      rank=<optimized out>, ts=1) at trace.c:1205
  #10 traceScanSegRes (ts=1, rank=<optimized out>, arena=0x1f0000, seg=0xa4b538c)
      at trace.c:1182
  #11 0x009fecf9 in traceScanSeg (ts=1, rank=1, arena=0x1f0000, seg=0xa4b538c)
      at trace.c:1267
  #12 0x009ff5a2 in TraceAdvance (trace=<optimized out>) at trace.c:1728
  #13 0x00a0c6ef in TracePoll (workReturn=workReturn@entry=0x6fb850c,
      collectWorldReturn=collectWorldReturn@entry=0x6fb8508,
      globals=globals@entry=0x1f0008, collectWorldAllowed=1) at trace.c:1849
  #14 0x00a0c8b7 in ArenaPoll (globals=globals@entry=0x1f0008) at global.c:745
  #15 0x00a0d047 in mps_ap_fill (p_o=p_o@entry=0x6fb85dc,
      mps_ap=mps_ap@entry=0xa306c88, size=size@entry=480) at mpsi.c:1097
  #16 0x0090fbe8 in alloc (size=480, size@entry=468,
      type=type@entry=IGC_OBJ_STRING_DATA, pvec_type=pvec_type@entry=PVEC_FREE)
      at igc.c:2590
  #17 0x00911ded in alloc_string_data (clear=false, nbytes=467) at igc.c:2638
  #18 igc_make_string (nchars=nchars@entry=467, nbytes=nbytes@entry=467,
      unibyte=unibyte@entry=false, clear=clear@entry=false) at igc.c:2683
  #19 0x00911e36 in igc_make_multibyte_string (nchars=nchars@entry=467,
      nbytes=nbytes@entry=467, clear=clear@entry=false) at igc.c:2690
  #20 0x00858799 in make_clear_multibyte_string (clearit=false, nbytes=467,
      nchars=467) at alloc.c:2633
  #21 make_clear_string (length=length@entry=467, clearit=clearit@entry=false)
      at alloc.c:2610
  #22 0x008587dc in make_clear_string (clearit=<optimized out>,
      length=<optimized out>) at alloc.c:2619
  #23 0x0088e42d in Fcopy_sequence (arg=arg@entry=XIL(0xade568c)) at fns.c:791
  #24 0x0084096d in compile_pattern_1 (posix=<optimized out>, translate=XIL(0),
      pattern=XIL(0xade568c), cp=0xe76f5c <searchbufs+3388>) at search.c:131
  #25 compile_pattern (pattern=XIL(0xade568c), regp=0xd9cbf4 <main_thread+84>,
      translate=XIL(0), posix=posix@entry=false, multibyte=multibyte@entry=true)
      at search.c:236
  #26 0x00840bb8 in looking_at_1 (string=<optimized out>, posix=<optimized out>,
      modify_data=<optimized out>) at search.c:281
  #27 0x008d60b5 in exec_byte_code (fun=XIL(0xda3f25),
      fun@entry=XIL(0x134c2b85), args_template=513, nargs=nargs@entry=1,
      args=0x1a9fa50c, args@entry=0x1a9fa100) at lisp.h:751
  #28 0x008882b8 in funcall_lambda (fun=XIL(0x134c2b85), nargs=nargs@entry=1,
      arg_vector=arg_vector@entry=0x1a9fa100) at eval.c:3200
  #29 0x008887da in funcall_general (fun=<optimized out>,
      numargs=numargs@entry=1, args=args@entry=0x1a9fa100) at eval.c:2994
  #30 0x00883f45 in Ffuncall (args=0x1a9fa0fc, nargs=2) at eval.c:3032
  #31 Ffuncall (nargs=2, args=0x1a9fa0fc) at eval.c:3006
  #32 0x00884733 in run_hook_wrapped_funcall (nargs=nargs@entry=2,
      args=args@entry=0x1a9fa0fc) at eval.c:2810
  #33 0x00882c6f in run_hook_with_args (nargs=2, args=0x1a9fa0fc,
      funcall=0x884710 <run_hook_wrapped_funcall>) at eval.c:2891
  #34 0x00882f2d in Frun_hook_wrapped (nargs=2, args=0x1a9fa0fc) at eval.c:2825
  #35 0x008d60b5 in exec_byte_code (fun=XIL(0xda5d45),
      fun@entry=XIL(0x1a28a13d), args_template=514, nargs=2, nargs@entry=1,
      args=0x1a9fa0fc, args@entry=0x6fb8adc) at lisp.h:751
  #36 0x008882b8 in funcall_lambda (fun=XIL(0x1a28a13d), nargs=nargs@entry=1,
      arg_vector=arg_vector@entry=0x6fb8adc) at eval.c:3200
  #37 0x008887da in funcall_general (fun=<optimized out>,
      numargs=numargs@entry=1, args=args@entry=0x6fb8adc) at eval.c:2994
  #38 0x00883f45 in Ffuncall (args=0x6fb8ad8, nargs=2) at eval.c:3032
  #39 Ffuncall (nargs=2, args=0x6fb8ad8) at eval.c:3006
  #40 0x00882605 in internal_condition_case_n (
      bfun=bfun@entry=0x883e4a <Ffuncall>, nargs=nargs@entry=2,
      args=args@entry=0x6fb8ad8, handlers=handlers@entry=XIL(0x18),
      hfun=hfun@entry=0x72a268 <dsafe_eval_handler>) at eval.c:1624
  #41 0x00710eef in dsafe__call (inhibit_quit=inhibit_quit@entry=false,
      f=0x883e4a <Ffuncall>, nargs=nargs@entry=2, args=args@entry=0x6fb8ad8)
      at lisp.h:1178
  #42 0x00710f55 in dsafe__call (args=0x6fb8ad8, nargs=2, f=<optimized out>,
      inhibit_quit=false) at xdisp.c:3056
  #43 dsafe_call1 (f=f@entry=XIL(0x193da700), arg=arg@entry=make_fixnum(371707))
      at xdisp.c:3097
  #44 0x00728f47 in handle_fontified_prop (it=0x6fba6d0) at xdisp.c:4616
  #45 handle_fontified_prop (it=<optimized out>) at xdisp.c:4532
  #46 0x0072d708 in handle_stop (it=it@entry=0x6fba6d0) at xdisp.c:4136
  #47 0x0073983e in next_element_from_buffer (it=0x6fba6d0) at xdisp.c:9643
  #48 0x007370ab in get_next_display_element (it=it@entry=0x6fba6d0)
      at xdisp.c:8209
  #49 0x00740d46 in display_line (it=it@entry=0x6fba6d0,
      cursor_vpos=cursor_vpos@entry=0) at xdisp.c:25295
  #50 0x007475c1 in try_window (window=<optimized out>,
      window@entry=XIL(0xaa1c62d), pos=..., flags=<optimized out>, flags@entry=0)
      at xdisp.c:21136
  #51 0x00768505 in redisplay_window (window=window@entry=XIL(0xaa1c62d),
      just_this_one_p=just_this_one_p@entry=true) at xdisp.c:20245
  #52 0x0076cab8 in redisplay_window_1 (window=XIL(0xaa1c62d)) at xdisp.c:18023
  #53 0x008824bb in internal_condition_case_1 (
      bfun=bfun@entry=0x76ca80 <redisplay_window_1>, arg=XIL(0xaa1c62d),
      handlers=XIL(0x1a471243),
      hfun=hfun@entry=0x716297 <redisplay_window_error>) at eval.c:1568
  #54 0x0075124e in redisplay_internal () at xdisp.c:17512
  #55 0x00752463 in redisplay () at xdisp.c:16562
  #56 0x007f6088 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=XIL(0x134c1bd3),
      prev_event=<optimized out>, used_mouse_menu=<optimized out>,
      used_mouse_menu@entry=0x6fbf7fb, end_time=<optimized out>,
      end_time@entry=0x0) at keyboard.c:2678
  #57 0x007f96bd in read_key_sequence (keybuf=keybuf@entry=0x6fbf8d8,
      prompt=prompt@entry=XIL(0),
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #58 0x007fb24b in command_loop_1 () at lisp.h:1178
  #59 0x0088241d in internal_condition_case (
      bfun=bfun@entry=0x7fb090 <command_loop_1>,
      handlers=handlers@entry=XIL(0x48), hfun=hfun@entry=0x7ee3d6 <cmd_error>)
      at eval.c:1544
  #60 0x007e46eb in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #61 0x00882337 in internal_catch (tag=tag@entry=XIL(0x8790),
      func=func@entry=0x7e46cb <command_loop_2>, arg=arg@entry=XIL(0x48))
      at eval.c:1224
  #62 0x007e468b in command_loop () at lisp.h:1178
  #63 0x007edf91 in recursive_edit_1 () at keyboard.c:754
  #64 0x007ee281 in Frecursive_edit () at keyboard.c:837
  #65 0x00a1dcff in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626

  Lisp Backtrace:

  eval.c:120: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
  442     {
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (backtrace_function) will be abandoned.
  When the function is done executing, GDB will silently stop.


  igc.c:1598: Emacs fatal error: assertion failed: !"other"

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
  442     {
  (gdb) bt
  #0  terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
  #1  0x00f987e0 in die (msg=msg@entry=0x152ea77 <i_fwd+1479> "!\"other\"",
      file=file@entry=0x152e640 <i_fwd+400> "igc.c", line=line@entry=1598)
      at alloc.c:8334
  #2  0x01051a92 in igc_assert_fail (msg=0x152ea77 <i_fwd+1479> "!\"other\"",
      line=1598, file=0x152e640 <i_fwd+400> "igc.c") at igc.c:87
  #3  fix_other (o=0x13cac008, ss=0xbf8478) at igc.c:1598
  #4  fix_vector (v=0x13cac008, ss=0xbf8478) at igc.c:1675
  #5  dflt_scanx (ss=ss@entry=0xbf8478, base_start=<optimized out>,
      base_start@entry=0x13cac000, base_limit=base_limit@entry=0x13cae000,
      closure=closure@entry=0x0) at igc.c:1207
  #6  0x01051d1d in dflt_scan (ss=0xbf8478, base_start=0x13cac000,
      base_limit=0x13cae000) at igc.c:1250
  #7  0x01128ea6 in TraceScanFormat (limit=0x13cae000, base=0x13cac000,
      ss=0xbf8474) at trace.c:1539
  #8  amcSegScan (totalReturn=0xbf8470, seg=0xa47cf34, ss=0xbf8474)
      at poolamc.c:1440
  #9  0x01148a25 in traceScanSegRes (seg=0xa47cf34, arena=0x1f0000,
      rank=<optimized out>, ts=1) at trace.c:1205
  #10 traceScanSegRes (ts=1, rank=<optimized out>, arena=0x1f0000, seg=0xa47cf34)
      at trace.c:1182
  #11 0x01148bf9 in traceScanSeg (ts=1, rank=1, arena=0x1f0000, seg=0xa47cf34)
      at trace.c:1267
  #12 0x011494a2 in TraceAdvance (trace=<optimized out>) at trace.c:1728
  #13 0x011565ef in TracePoll (workReturn=workReturn@entry=0xbf85bc,
      collectWorldReturn=collectWorldReturn@entry=0xbf85b8,
      globals=globals@entry=0x1f0008, collectWorldAllowed=1) at trace.c:1849
  #14 0x011567b7 in ArenaPoll (globals=globals@entry=0x1f0008) at global.c:745
  #15 0x01156f47 in mps_ap_fill (p_o=p_o@entry=0xbf868c,
      mps_ap=mps_ap@entry=0xa2d6c10, size=size@entry=32) at mpsi.c:1097
  #16 0x010501d8 in alloc (size=32, size@entry=24,
      type=type@entry=IGC_OBJ_VECTOR, pvec_type=pvec_type@entry=PVEC_MARKER)
      at igc.c:2604
  #17 0x01052500 in igc_alloc_pseudovector (nwords_mem=5, nwords_lisp=0,
      nwords_zero=0, tag=PVEC_MARKER) at igc.c:2724
  #18 0x00f99644 in allocate_pseudovector (memlen=<optimized out>,
      memlen@entry=5, lisplen=<optimized out>, lisplen@entry=0,
      zerolen=<optimized out>, zerolen@entry=0, tag=<optimized out>,
      tag@entry=PVEC_MARKER) at alloc.c:3782
  #19 0x00f999de in build_marker (buf=0xac4fcf8, charpos=373093, bytepos=373093)
      at alloc.c:4173
  #20 0x00fbe591 in Fpoint_marker () at editfns.c:202
  #21 save_excursion_save (pdl=0x1ba190b0) at editfns.c:782
  #22 0x00fc3c24 in record_unwind_protect_excursion () at eval.c:3600
  #23 0x010160ac in exec_byte_code (fun=XIL(0x14edf25),
      fun@entry=XIL(0x1349542d), args_template=256, nargs=nargs@entry=1,
      args=0x1a9c13b8, args@entry=0x1a9c1100) at bytecode.c:944
  #24 0x00fc86b8 in funcall_lambda (fun=XIL(0x1349542d), nargs=nargs@entry=1,
      arg_vector=arg_vector@entry=0x1a9c1100) at eval.c:3200
  #25 0x00fc8bda in funcall_general (fun=<optimized out>,
      numargs=numargs@entry=1, args=args@entry=0x1a9c1100) at eval.c:2994
  #26 0x00fc4345 in Ffuncall (args=0x1a9c10fc, nargs=2) at eval.c:3032
  #27 Ffuncall (nargs=2, args=0x1a9c10fc) at eval.c:3006
  #28 0x00fc4b33 in run_hook_wrapped_funcall (nargs=nargs@entry=2,
      args=args@entry=0x1a9c10fc) at eval.c:2810
  #29 0x00fc306f in run_hook_with_args (nargs=2, args=0x1a9c10fc,
      funcall=0xfc4b10 <run_hook_wrapped_funcall>) at eval.c:2891
  #30 0x00fc332d in Frun_hook_wrapped (nargs=2, args=0x1a9c10fc) at eval.c:2825
  #31 0x010166a5 in exec_byte_code (fun=XIL(0x14efd45),
      fun@entry=XIL(0x1a25a1b5), args_template=514, nargs=2, nargs@entry=1,
      args=0x1a9c10fc, args@entry=0xbf8adc) at lisp.h:751
  #32 0x00fc86b8 in funcall_lambda (fun=XIL(0x1a25a1b5), nargs=nargs@entry=1,
      arg_vector=arg_vector@entry=0xbf8adc) at eval.c:3200
  #33 0x00fc8bda in funcall_general (fun=<optimized out>,
      numargs=numargs@entry=1, args=args@entry=0xbf8adc) at eval.c:2994
  #34 0x00fc4345 in Ffuncall (args=0xbf8ad8, nargs=2) at eval.c:3032
  #35 Ffuncall (nargs=2, args=0xbf8ad8) at eval.c:3006
  #36 0x00fc2a05 in internal_condition_case_n (
      bfun=bfun@entry=0xfc424a <Ffuncall>, nargs=nargs@entry=2,
      args=args@entry=0xbf8ad8, handlers=handlers@entry=XIL(0x18),
      hfun=hfun@entry=0xe6a268 <dsafe_eval_handler>) at eval.c:1624
  #37 0x00e50eef in dsafe__call (inhibit_quit=inhibit_quit@entry=false,
      f=0xfc424a <Ffuncall>, nargs=nargs@entry=2, args=args@entry=0xbf8ad8)
      at lisp.h:1178
  #38 0x00e50f55 in dsafe__call (args=0xbf8ad8, nargs=2, f=<optimized out>,
      inhibit_quit=false) at xdisp.c:3056
  #39 dsafe_call1 (f=f@entry=XIL(0x18c5d618), arg=arg@entry=make_fixnum(371707))
      at xdisp.c:3097
  #40 0x00e68f47 in handle_fontified_prop (it=0xbfa6d0) at xdisp.c:4616
  #41 handle_fontified_prop (it=<optimized out>) at xdisp.c:4532
  #42 0x00e6d708 in handle_stop (it=it@entry=0xbfa6d0) at xdisp.c:4136
  #43 0x00e7983e in next_element_from_buffer (it=0xbfa6d0) at xdisp.c:9643
  #44 0x00e770ab in get_next_display_element (it=it@entry=0xbfa6d0)
      at xdisp.c:8209
  #45 0x00e80d46 in display_line (it=it@entry=0xbfa6d0,
      cursor_vpos=cursor_vpos@entry=0) at xdisp.c:25295
  #46 0x00e875c1 in try_window (window=<optimized out>,
      window@entry=XIL(0xaa1c62d), pos=..., flags=<optimized out>, flags@entry=0)
      at xdisp.c:21136
  #47 0x00ea8505 in redisplay_window (window=window@entry=XIL(0xaa1c62d),
      just_this_one_p=just_this_one_p@entry=true) at xdisp.c:20245
  #48 0x00eacab8 in redisplay_window_1 (window=XIL(0xaa1c62d)) at xdisp.c:18023
  #49 0x00fc28bb in internal_condition_case_1 (
      bfun=bfun@entry=0xeaca80 <redisplay_window_1>, arg=XIL(0xaa1c62d),
      handlers=XIL(0x1a4410b3),
      hfun=hfun@entry=0xe56297 <redisplay_window_error>) at eval.c:1568
  #50 0x00e9124e in redisplay_internal () at xdisp.c:17512
  #51 0x00e92463 in redisplay () at xdisp.c:16562
  #52 0x00f36088 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=XIL(0x13494483),
      prev_event=<optimized out>, used_mouse_menu=<optimized out>,
      used_mouse_menu@entry=0xbff7fb, end_time=<optimized out>,
      end_time@entry=0x0) at keyboard.c:2678
  #53 0x00f396bd in read_key_sequence (keybuf=keybuf@entry=0xbff8d8,
      prompt=prompt@entry=XIL(0),
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #54 0x00f3b24b in command_loop_1 () at lisp.h:1178
  #55 0x00fc281d in internal_condition_case (
      bfun=bfun@entry=0xf3b090 <command_loop_1>,
      handlers=handlers@entry=XIL(0x48), hfun=hfun@entry=0xf2e3d6 <cmd_error>)
      at eval.c:1544
  #56 0x00f246eb in command_loop_2 (handlers=XIL(0x48)) at keyboard.c:1168
  #57 0x00fc2737 in internal_catch (tag=tag@entry=XIL(0x8790),
      func=func@entry=0xf246cb <command_loop_2>, arg=arg@entry=XIL(0x48))
      at eval.c:1224
  #58 0x00f2468b in command_loop () at lisp.h:1178
  #59 0x00f2df91 in recursive_edit_1 () at keyboard.c:754
  #60 0x00f2e281 in Frecursive_edit () at keyboard.c:837
  #61 0x01167bff in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626
  [New Thread 106112.0x1a944]

  Lisp Backtrace:
  [New Thread 106112.0x1956c]

  eval.c:120: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE

  Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
  442     {
  The program being debugged stopped while in a function called from GDB.
  Evaluation of the expression containing the function
  (backtrace_function) will be abandoned.
  When the function is done executing, GDB will silently stop.
  (gdb)

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 26 Apr 2024 09:18:59 +0200
>> 
>> >> ./src/emacs -Q src/xdisp.c -eval '(igc--collect)'
>> >
>> > I would start by investigating what stuff reachable from struct frame
>> > is and is not traced, which depends a bit on the platform. Also font
>> > stuff probably, terminals, scroll bar things (at least in NS I know
>> > there is something), and I don't know what else.
>> 
>> The problem was a corrupted font.  I added the code below and it now
>> survives the first GC cycle.  In general, fix_frame must scan the same
>> fields as mark_frame in alloc.c does.  Is that about right?  Since MPS
>> wants the address of the fields (instead the value), some creativity may
>> be required.  Is that also right?  Or can I stupidly copy what
>> mark_frame does?
>
> Thanks, I cannot answer all of the questions above, but I nevertheless
> installed this in your name, with one difference:

Oh, I see, that's why the path didn't apply :-).
 
> However, the crashes while scrolling through xdisp.c are still there.
> I just had 2 of them; backtraces below.  It sounds like the first one
> is due to Lisp strings, but the second one is related to markers.
>
>   igc.c:1584: Emacs fatal error: assertion failed: !"other"

That's the PVEC_OTHER we talked about.

Maybe it would be a good idea to take the assert !"other" out for the
moment?

>   eval.c:120: Emacs fatal error: assertion failed: pdl->kind == SPECPDL_BACKTRACE
>
>   Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
>       backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
>   442     {
>   The program being debugged stopped while in a function called from GDB.
>   Evaluation of the expression containing the function
>   (backtrace_function) will be abandoned.
>   When the function is done executing, GDB will silently stop.

This is from the xbacktrace calling into Emacs.

And now it's becoming fun :-).

Our GC callbacks are called from MPS, in its thread. Fix_... are
subroutines of dftl_scan, which is the scanning callback. When we fail,
MPS is in some state we don't really know. And Emacs does its thing
handling the failure, which uses MPS (it allocates, for example).

Which basically means, after a failing assertion in a callback, we are
basically hosed. Memory barriers may exist, locks may not have been
released, and heaven knows...

Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
There is igc_postmorten which can be called from the debugger. That at
least lifts the memory barriers.

Does that make sense?

I think we should first get to a state where we don't fail asserts,
because it's hard to tell if followup errors are "real", so to say.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

> installed this in your name, with one difference:
>
>> +    if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
>> +      {
>> +	struct font *font = FRAME_FONT (f);
>> +	if (font)
>> +	  IGC_FIX12_RAW(ss, &FRAME_FONT (f));
>
> You already used FRAME_FONT, so not necessary to use it again:
>
>     if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
>       {
> 	struct font *font = FRAME_FONT (f);
> 	if (font)
> 	  IGC_FIX12_RAW(ss, &font);  <<<<<<<<<<<<<<<<<<<<<
>       }

I think this change introduced a bug.  Remember that MPS is moving
GC. So it sometimes needs to update the pointer in the struct that we
are scanning.  We have to give it the address of the field, not the
address of some local variable on the stack. Perhaps clearer is this:

	struct font **font = &FRAME_FONT (f);
	if (*font)
	  IGC_FIX12_RAW(ss, font);

> However, the crashes while scrolling through xdisp.c are still there.
> I just had 2 of them; backtraces below.  It sounds like the first one
> is due to Lisp strings, but the second one is related to markers.
>
>   igc.c:1584: Emacs fatal error: assertion failed: !"other"

Yes, I see this too.  I will try to write some code to reproduce
this without needing manual input.

Helmut

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

>>   igc.c:1584: Emacs fatal error: assertion failed: !"other"
>
> Yes, I see this too.  I will try to write some code to reproduce
> this without needing manual input.

That's the PVEC_OTHER. I should have made that !"PVEC_OTHER" or
something, sorry.

I've found it being used now in the module code and w32. Once it seems
to be a struct module_global_reference, and on w32 a struct scroll_bar.
No idea how one can tell what if it's one or the other. Strange.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

On Fri, Apr 26 2024, Gerd Möllmann wrote:

> Maybe it would be a good idea to take the assert !"other" out for the
> moment?

Unlikely.

> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
> There is igc_postmorten which can be called from the debugger. That at
> least lifts the memory barriers.

I guess I need to have a deeper look at MPS documentation better someday.

> Does that make sense?
>
> I think we should first get to a state where we don't fail asserts,
> because it's hard to tell if followup errors are "real", so to say.

One way to reproduce this (or something very similar) is this:

./src/emacs -Q src/xdisp.c -eval
 '(progn (igc--collect) (redisplay) (igc--collect)'

Unfortunately, redisplay is a relatively big function.  Are there any
good places in the display code where I could insert an explicit call to
igc_collect so that it crashes earlier?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> Unfortunately, redisplay is a relatively big function.  Are there any
> good places in the display code where I could insert an explicit call to
> igc_collect so that it crashes earlier?

Maybe put it where redisplay calls Lisp? That would be dsafe_call, I
think.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 10:11:28 +0200
> 
> >   igc.c:1584: Emacs fatal error: assertion failed: !"other"
> 
> That's the PVEC_OTHER we talked about.
> 
> Maybe it would be a good idea to take the assert !"other" out for the
> moment?

No, we should instead solve that.  Moving assertions out of the way
just sweeps real problems under the carpet, which makes little sense
to me.  These problems need to be solved, or else they will pile up
for no good reason.  It isn't like we are going to release this branch
soon, so avoiding these aborts has no useful purpose, IMO.

> >   Thread 1 hit Breakpoint 1, terminate_due_to_signal (sig=sig@entry=22,
> >       backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:442
> >   442     {
> >   The program being debugged stopped while in a function called from GDB.
> >   Evaluation of the expression containing the function
> >   (backtrace_function) will be abandoned.
> >   When the function is done executing, GDB will silently stop.
> 
> This is from the xbacktrace calling into Emacs.

Yes, I know.

> And now it's becoming fun :-).
> 
> Our GC callbacks are called from MPS, in its thread. Fix_... are
> subroutines of dftl_scan, which is the scanning callback. When we fail,
> MPS is in some state we don't really know. And Emacs does its thing
> handling the failure, which uses MPS (it allocates, for example).
> 
> Which basically means, after a failing assertion in a callback, we are
> basically hosed. Memory barriers may exist, locks may not have been
> released, and heaven knows...

xbacktrace (and some of the other .gdbinit commands, like "pp", which
calls into Emacs) are known not to work reliably when Emacs crashed,
so the fact that this happens here is not a surprise to me.

> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
> There is igc_postmorten which can be called from the debugger. That at
> least lifts the memory barriers.
> 
> Does that make sense?

Yes, it does.  Maybe xbacktrace should do that automatically?  What
are the downsides of calling igc_postmorten?

> I think we should first get to a state where we don't fail asserts,
> because it's hard to tell if followup errors are "real", so to say.

Agreed.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 10:12:58 +0200
> 
> >     if (FRAME_WINDOW_P (f) && FRAME_OUTPUT_DATA (f))
> >       {
> > 	struct font *font = FRAME_FONT (f);
> > 	if (font)
> > 	  IGC_FIX12_RAW(ss, &font);  <<<<<<<<<<<<<<<<<<<<<
> >       }
> 
> I think this change introduced a bug.  Remember that MPS is moving
> GC. So it sometimes needs to update the pointer in the struct that we
> are scanning.  We have to give it the address of the field, not the
> address of some local variable on the stack. Perhaps clearer is this:
> 
> 	struct font **font = &FRAME_FONT (f);
> 	if (*font)
> 	  IGC_FIX12_RAW(ss, font);

Done.

> > However, the crashes while scrolling through xdisp.c are still there.
> > I just had 2 of them; backtraces below.  It sounds like the first one
> > is due to Lisp strings, but the second one is related to markers.
> >
> >   igc.c:1584: Emacs fatal error: assertion failed: !"other"
> 
> Yes, I see this too.  I will try to write some code to reproduce
> this without needing manual input.

Thanks.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 11:13:30 +0200
> 
> > I think we should first get to a state where we don't fail asserts,
> > because it's hard to tell if followup errors are "real", so to say.
> 
> One way to reproduce this (or something very similar) is this:
> 
> ./src/emacs -Q src/xdisp.c -eval
>  '(progn (igc--collect) (redisplay) (igc--collect)'
> 
> Unfortunately, redisplay is a relatively big function.  Are there any
> good places in the display code where I could insert an explicit call to
> igc_collect so that it crashes earlier?

If this is due to scroll bars, I'd try inserting these calls in
redisplay_window, and if that does work, then near its end where it
calls redeem_scroll_bar_hook.  Note that redisplay_internal calls
condemn_scroll_bars_hook, which could also be relevant.  And finally,
there's set_vertical_scroll_bar (called from redisplay_window).

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Helmut Eller <eller.helmut@gmail.com>,  emacs-devel@gnu.org
>> Date: Fri, 26 Apr 2024 10:11:28 +0200
>> 
>> >   igc.c:1584: Emacs fatal error: assertion failed: !"other"
>> 
>> That's the PVEC_OTHER we talked about.
>> 
>> Maybe it would be a good idea to take the assert !"other" out for the
>> moment?
>
> No, we should instead solve that.  Moving assertions out of the way
> just sweeps real problems under the carpet, which makes little sense
> to me.  These problems need to be solved, or else they will pile up
> for no good reason.  It isn't like we are going to release this branch
> soon, so avoiding these aborts has no useful purpose, IMO.

I've meanwhile pushed something that handles the use of PVEC_OTHER in
modules. Nothing done for the scroll_bar struct in w32. Caution: I
remved the assert.

> xbacktrace (and some of the other .gdbinit commands, like "pp", which
> calls into Emacs) are known not to work reliably when Emacs crashed,
> so the fact that this happens here is not a surprise to me.

Ok.
>
>> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
>> There is igc_postmorten which can be called from the debugger. That at
>> least lifts the memory barriers.
>> 
>> Does that make sense?
>
> Yes, it does.  Maybe xbacktrace should do that automatically?  What
> are the downsides of calling igc_postmorten?

I'd say that xpostmortem wouldn't make sense during normal debugging,
when MPS is not dead in the water. I don't think one can get out of that
state again.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 12:56:29 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > No, we should instead solve that.  Moving assertions out of the way
> > just sweeps real problems under the carpet, which makes little sense
> > to me.  These problems need to be solved, or else they will pile up
> > for no good reason.  It isn't like we are going to release this branch
> > soon, so avoiding these aborts has no useful purpose, IMO.
> 
> I've meanwhile pushed something that handles the use of PVEC_OTHER in
> modules. Nothing done for the scroll_bar struct in w32. Caution: I
> remved the assert.

Why did you do that?  What possible useful purpose can that serve?  If
the assertion gets in the way of what you are looking at, you can
always remove it locally, can't you?

> >> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
> >> There is igc_postmorten which can be called from the debugger. That at
> >> least lifts the memory barriers.
> >> 
> >> Does that make sense?
> >
> > Yes, it does.  Maybe xbacktrace should do that automatically?  What
> > are the downsides of calling igc_postmorten?
> 
> I'd say that xpostmortem wouldn't make sense during normal debugging,
> when MPS is not dead in the water. I don't think one can get out of that
> state again.

I don't follow.  How is debugging problems with GC different from
"normal debugging"?

In any case, I asked about the downsides of calling igc_postmorten,
which I think is crucial to understand for making this decision.  If
there are no significant downsides, then doing so is a net win, no?

Re: Building the igc branch on MS-Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 26 Apr 2024 11:13:30 +0200
>> 
>> > I think we should first get to a state where we don't fail asserts,
>> > because it's hard to tell if followup errors are "real", so to say.
>> 
>> One way to reproduce this (or something very similar) is this:
>> 
>> ./src/emacs -Q src/xdisp.c -eval
>>  '(progn (igc--collect) (redisplay) (igc--collect)'
>> 
>> Unfortunately, redisplay is a relatively big function.  Are there any
>> good places in the display code where I could insert an explicit call to
>> igc_collect so that it crashes earlier?
>
> If this is due to scroll bars, I'd try inserting these calls in
> redisplay_window, and if that does work, then near its end where it
> calls redeem_scroll_bar_hook.  Note that redisplay_internal calls
> condemn_scroll_bars_hook, which could also be relevant.  And finally,
> there's set_vertical_scroll_bar (called from redisplay_window).

It could easily be related to scroll bars, since the implementation of
scroll bars on X liberally creates PVEC_OTHER objects that are subject
to garbage collection.  No special handling is required of the GC,
because the only objects after the Lisp area of the pseudovector are X
identifiers and miscellaneous integers.

On another score, as I searched for other references to PVEC_OTHER, I
did notice that there remains the other matter of module references,
which probably needs to be revisited for this new GC scheme.  If the
existing design is to be left intact, the PVEC_OTHERs created there must
be "pinned" so that they are never moved by the garbage collector, but
not having studied the igc branch beyond the superficials I cannot say
how that is best accomplished.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 12:56:29 +0200
> 
> I've meanwhile pushed something that handles the use of PVEC_OTHER in
> modules. Nothing done for the scroll_bar struct in w32. Caution: I
> remved the assert.

This still crashes while scrolling through xdisp.c, but with a
different backtrace.  I've noticed that it crashes after GC kicks in
and releases a large amount of memory (about 100MB).  Here's the
backtrace:

  Thread 1 received signal SIGSEGV, Segmentation fault.
  XCAR (c=0xab5ca1b) at lisp.h:751
  751       return lisp_h_XLP (o);
  (gdb) bt
  #0  XCAR (c=0xab5ca1b) at lisp.h:751
  #1  assoc_no_quit (key=<optimized out>, alist=0xab5ca1b) at fns.c:2032
  #2  0x00cbc12d in font_list_entities (f=0xaa1c478, spec=0xa84227d)
      at font.c:2795
  #3  0x00cbce93 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
      attrs=<optimized out>, attrs@entry=0x743a2b0, spec=<optimized out>,
      spec@entry=0xa8421dd, c=<optimized out>, c@entry=-1) at font.c:3316
  #4  0x00cbe3c4 in font_load_for_lface (f=f@entry=0xaa1c478,
      attrs=attrs@entry=0x743a2b0, spec=spec@entry=0xa8421dd) at font.c:3396
  #5  0x00bedf2b in realize_gui_face (cache=0x13ca1f88, attrs=0x743a2b0)
      at xfaces.c:6216
  #6  realize_face (cache=cache@entry=0x13ca1f88, attrs=attrs@entry=0x743a2b0,
      former_face_id=former_face_id@entry=-1) at xfaces.c:6053
  #7  0x00befdb3 in lookup_face (f=f@entry=0xaa1c478, attr=attr@entry=0x743a2b0)
      at xfaces.c:4989
  #8  0x00bf2dcc in face_at_string_position (w=0xaa1c628,
      string=<optimized out>, string@entry=0x1a30b7d4, pos=pos@entry=1,
      bufpos=bufpos@entry=0, endptr=endptr@entry=0x743a37c,
      base_face_id=MODE_LINE_ACTIVE_FACE_ID, mouse_p=mouse_p@entry=false,
      attr_filter=attr_filter@entry=0) at xfaces.c:6930
  #9  0x00b59268 in display_string (string=string@entry=0x13cbb010 "xdisp.c",
      lisp_string=0xac546fc, face_string=face_string@entry=0x1a30b7d4,
      face_string_pos=face_string_pos@entry=1, start=start@entry=0,
      it=it@entry=0x743a690, field_width=field_width@entry=12,
      precision=precision@entry=-13, max_x=max_x@entry=0,
      multibyte=multibyte@entry=0) at xdisp.c:29116
  #10 0x00b5a299 in display_mode_element (it=it@entry=0x743a690,
      depth=<optimized out>, depth@entry=3, field_width=<optimized out>,
      precision=<optimized out>, precision@entry=-13, elt=<optimized out>,
      elt@entry=0x1a30b7d4, props=<optimized out>, props@entry=0x0,
      risky=<optimized out>, risky@entry=false) at xdisp.c:27788
  #11 0x00b5b5ff in display_mode_element (it=it@entry=0x743a690, depth=3,
      depth@entry=1, field_width=0, precision=precision@entry=-13,
      elt=<optimized out>, elt@entry=0x1903ec10, props=props@entry=0x0,
      risky=risky@entry=false) at xdisp.c:27965
  #12 0x00b5b5ff in display_mode_element (it=it@entry=0x743a690, depth=1,
      depth@entry=0, field_width=field_width@entry=0,
      precision=precision@entry=0, elt=<optimized out>, elt@entry=0x1a40e953,
      props=props@entry=0x0, risky=risky@entry=false) at xdisp.c:27965
  #13 0x00b5cba9 in display_mode_line (w=w@entry=0xaa1c628,
      face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x1a40e953) at lisp.h:1178
  #14 0x00b5f695 in display_mode_lines (w=w@entry=0xaa1c628) at xdisp.c:27303
  #15 0x00b77df2 in redisplay_window (window=window@entry=0xaa1c62d,
      just_this_one_p=just_this_one_p@entry=true) at xdisp.c:20924
  #16 0x00b7cab8 in redisplay_window_1 (window=0xaa1c62d) at xdisp.c:18023
  #17 0x00c928bb in internal_condition_case_1 (
      bfun=bfun@entry=0xb7ca80 <redisplay_window_1>, arg=0xaa1c62d,
      handlers=0x1a4810b3, hfun=hfun@entry=0xb26297 <redisplay_window_error>)
      at eval.c:1568
  #18 0x00b6124e in redisplay_internal () at xdisp.c:17512
  #19 0x00b62463 in redisplay () at xdisp.c:16562
  #20 0x00c06088 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=0x134a91a3, prev_event=<optimized out>,
      used_mouse_menu=<optimized out>, used_mouse_menu@entry=0x743f7fb,
      end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
  #21 0x00c096bd in read_key_sequence (keybuf=keybuf@entry=0x743f8d8,
      prompt=prompt@entry=0x0,
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #22 0x00c0b24b in command_loop_1 () at lisp.h:1178
  #23 0x00c9281d in internal_condition_case (
      bfun=bfun@entry=0xc0b090 <command_loop_1>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0xbfe3d6 <cmd_error>) at eval.c:1544
  #24 0x00bf46eb in command_loop_2 (handlers=0x48) at keyboard.c:1168
  #25 0x00c92737 in internal_catch (tag=tag@entry=0x8790,
      func=func@entry=0xbf46cb <command_loop_2>, arg=arg@entry=0x48)
      at eval.c:1224
  #26 0x00bf468b in command_loop () at lisp.h:1178
  #27 0x00bfdf91 in recursive_edit_1 () at keyboard.c:754
  #28 0x00bfe281 in Frecursive_edit () at keyboard.c:837
  #29 0x00e37bef in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626
  (gdb) p c
  $1 = (Lisp_Object) 0xab5ca1b
  (gdb) source src/.gdbinit
  warning: d:\gnu\git\emacs\feature/../lwlib: No such file or directory
  SIGINT is used by the debugger.
  Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
  Environment variable "DISPLAY" not defined.
  Environment variable "TERM" not defined.
  Breakpoint 1 at 0xbf4030: file emacs.c, line 442.
  (gdb) p c
  $2 = XIL(0xab5ca1b)
  (gdb) xtype
  Lisp_Cons
  (gdb) xcar
  Cannot access memory at address 0xab5ca18
  (gdb) p c
  $3 = XIL(0xab5ca1b)
  (gdb) xcdr
  Cannot access memory at address 0xab5ca1c
  (gdb)

Re: Building the igc branch on MS-Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> In any case, I asked about the downsides of calling igc_postmorten,
> which I think is crucial to understand for making this decision.  If
> there are no significant downsides, then doing so is a net win, no?

Isn't the downside that GC will never function again, and become unsafe
to invoke, after a call to igc_postmortem?  With the result that the
debuggee will not be usable as an editor, or indeed operate reliably at
all, after bt is called?

  https://memory-pool-system.readthedocs.io/en/latest/topic/arena.html#c.mps_arena_postmortem

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> I've meanwhile pushed something that handles the use of PVEC_OTHER in
>> modules. Nothing done for the scroll_bar struct in w32. Caution: I
>> remved the assert.
>
> Why did you do that?  What possible useful purpose can that serve?  If
> the assertion gets in the way of what you are looking at, you can
> always remove it locally, can't you?

Because PVEC_OTHER is handled fine now, except whatever w32 does in
addition or maybe instead (has it modules?)

>> >> Sometimes it helps to put MPS into a post-mortem state, as MPS calls it.
>> >> There is igc_postmorten which can be called from the debugger. That at
>> >> least lifts the memory barriers.
>> >> 
>> >> Does that make sense?
>> >
>> > Yes, it does.  Maybe xbacktrace should do that automatically?  What
>> > are the downsides of calling igc_postmorten?
>> 
>> I'd say that xpostmortem wouldn't make sense during normal debugging,
>> when MPS is not dead in the water. I don't think one can get out of that
>> state again.
>
> I don't follow.  How is debugging problems with GC different from
> "normal debugging"?

Imagine running Emacs under GDB and stopping at some breakpoint to debug
whatever. You want to xbacktrace and then proceed with continue. That
xbacktrace should not put MPS in post-mortem state.

> In any case, I asked about the downsides of calling igc_postmorten,
> which I think is crucial to understand for making this decision.  If
> there are no significant downsides, then doing so is a net win, no?

It's post-mortem = after death. MPS is then not in a usable state anymore.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> In any case, I asked about the downsides of calling igc_postmorten,
>> which I think is crucial to understand for making this decision.  If
>> there are no significant downsides, then doing so is a net win, no?
>
> Isn't the downside that GC will never function again, and become unsafe
> to invoke, after a call to igc_postmortem?  With the result that the
> debuggee will not be usable as an editor, or indeed operate reliably at
> all, after bt is called?
>
>   https://memory-pool-system.readthedocs.io/en/latest/topic/arena.html#c.mps_arena_postmortem

Exactly!

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> It could easily be related to scroll bars, since the implementation of
> scroll bars on X liberally creates PVEC_OTHER objects that are subject
> to garbage collection.  No special handling is required of the GC,
> because the only objects after the Lisp area of the pseudovector are X
> identifiers and miscellaneous integers.

Ah thanks. Can we somehow distinguish this from other uses of
PVEC_OTHER?

> On another score, as I searched for other references to PVEC_OTHER, I
> did notice that there remains the other matter of module references,
> which probably needs to be revisited for this new GC scheme.  If the
> existing design is to be left intact, the PVEC_OTHERs created there must
> be "pinned" so that they are never moved by the garbage collector, but
> not having studied the igc branch beyond the superficials I cannot say
> how that is best accomplished.

I tackled that with my last commit. The remaining problem is to
distinguish the different uses of PVEC_OTHER (maybe a simple enum). On
macOS, the module stuff is the only use.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 26 Apr 2024 12:56:29 +0200
>> 
>> I've meanwhile pushed something that handles the use of PVEC_OTHER in
>> modules. Nothing done for the scroll_bar struct in w32. Caution: I
>> remved the assert.
>
> This still crashes while scrolling through xdisp.c, but with a
> different backtrace.  I've noticed that it crashes after GC kicks in
> and releases a large amount of memory (about 100MB).  Here's the
> backtrace:
>
>   Thread 1 received signal SIGSEGV, Segmentation fault.
>   XCAR (c=0xab5ca1b) at lisp.h:751
>   751       return lisp_h_XLP (o);
>   (gdb) bt
>   #0  XCAR (c=0xab5ca1b) at lisp.h:751
>   #1  assoc_no_quit (key=<optimized out>, alist=0xab5ca1b) at fns.c:2032
>   #2  0x00cbc12d in font_list_entities (f=0xaa1c478, spec=0xa84227d)
>       at font.c:2795
>   #3  0x00cbce93 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
>       attrs=<optimized out>, attrs@entry=0x743a2b0, spec=<optimized out>,
>       spec@entry=0xa8421dd, c=<optimized out>, c@entry=-1) at font.c:3316

Looks to be like something "in the font department", something related
to fonts, contains references that are not yet traced. When a GC moves a
lot of stuff, these references are therefore updated because they are
not traces, therefore point to old locations, and ...

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>>> Date: Fri, 26 Apr 2024 12:56:29 +0200
>>> 
>>> I've meanwhile pushed something that handles the use of PVEC_OTHER in
>>> modules. Nothing done for the scroll_bar struct in w32. Caution: I
>>> remved the assert.
>>
>> This still crashes while scrolling through xdisp.c, but with a
>> different backtrace.  I've noticed that it crashes after GC kicks in
>> and releases a large amount of memory (about 100MB).  Here's the
>> backtrace:
>>
>>   Thread 1 received signal SIGSEGV, Segmentation fault.
>>   XCAR (c=0xab5ca1b) at lisp.h:751
>>   751       return lisp_h_XLP (o);
>>   (gdb) bt
>>   #0  XCAR (c=0xab5ca1b) at lisp.h:751
>>   #1  assoc_no_quit (key=<optimized out>, alist=0xab5ca1b) at fns.c:2032
>>   #2  0x00cbc12d in font_list_entities (f=0xaa1c478, spec=0xa84227d)
>>       at font.c:2795
>>   #3  0x00cbce93 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
>>       attrs=<optimized out>, attrs@entry=0x743a2b0, spec=<optimized out>,
>>       spec@entry=0xa8421dd, c=<optimized out>, c@entry=-1) at font.c:3316
>
> Looks to be like something "in the font department", something related
> to fonts, contains references that are not yet traced. When a GC moves a
> lot of stuff, these references are therefore updated because they are
                                               ^^^ not updated
> not traces, therefore point to old locations, and ...

Re: Building the igc branch on MS-Windows

[Po Lu]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Ah thanks.  Can we somehow distinguish this from other uses of
> PVEC_OTHER?

No, but we've still ample remaining space for pseudovector types, so
perhaps introducing a new pvec type for either scroll bars or module
references will fit the bill.  Personally, I would prefer giving module
references the more specific type and leaving scroll bars in peace, as
they truly are orthodox vectors requiring no special treatment of any
kind.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

I volunteer

Sent from my iPhone

> On 26. Apr 2024, at 15:43, Po Lu <luangruo@yahoo.com> wrote:
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
>> Ah thanks.  Can we somehow distinguish this from other uses of
>> PVEC_OTHER?
> 
> No, but we've still ample remaining space for pseudovector types, so
> perhaps introducing a new pvec type for either scroll bars or module
> references will fit the bill.  Personally, I would prefer giving module
> references the more specific type and leaving scroll bars in peace, as
> they truly are orthodox vectors requiring no special treatment of any
> kind.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Ah thanks.  Can we somehow distinguish this from other uses of
>> PVEC_OTHER?
>
> No, but we've still ample remaining space for pseudovector types, so
> perhaps introducing a new pvec type for either scroll bars or module
> references will fit the bill.  Personally, I would prefer giving module
> references the more specific type and leaving scroll bars in peace, as
> they truly are orthodox vectors requiring no special treatment of any
> kind.

Done.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   eller.helmut@gmail.com,
>   emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 19:38:20 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > In any case, I asked about the downsides of calling igc_postmorten,
> > which I think is crucial to understand for making this decision.  If
> > there are no significant downsides, then doing so is a net win, no?
> 
> Isn't the downside that GC will never function again, and become unsafe
> to invoke, after a call to igc_postmortem?  With the result that the
> debuggee will not be usable as an editor, or indeed operate reliably at
> all, after bt is called?

Even if that is true, how does this matter after Emacs crashed?
Especially if that happened due to MPS assertion violation?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Isn't the downside that GC will never function again, and become unsafe
>> to invoke, after a call to igc_postmortem?  With the result that the
>> debuggee will not be usable as an editor, or indeed operate reliably at
>> all, after bt is called?
>
> Even if that is true, how does this matter after Emacs crashed?
> Especially if that happened due to MPS assertion violation?

I'm sometimes using xbacktrace when Emacs hasn't crashed yet. For
example, when I'm at a breakpoint and want to see where I come from.
Then I might n, s, c etc.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

I have a nice test case, that crashes both GUI and tty versions.  Can
you reproduce this?

./src/emacs -nw -Q --eval
  '(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))'

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 14:58:10 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> I've meanwhile pushed something that handles the use of PVEC_OTHER in
> >> modules. Nothing done for the scroll_bar struct in w32. Caution: I
> >> remved the assert.
> >
> > Why did you do that?  What possible useful purpose can that serve?  If
> > the assertion gets in the way of what you are looking at, you can
> > always remove it locally, can't you?
> 
> Because PVEC_OTHER is handled fine now, except whatever w32 does in
> addition or maybe instead

Then maybe the assertion should be w32-only (if only w32 uses
PVEC_OTHER; I thought Helmut said he saw the same problem on
GNU/Linux?).  But removing it completely is not TRT, IMO.  We already
have quite a lot of code which was disabled under HAVE_MPS, and at
least some of that looks like workarounds for problems that got "low
priority".  I'm not sure this is a good way of making progress here,
especially since some of those #ifdef's could potentially cause
problems elsewhere.

I think we should methodically try to solve every problem we bump
into, without any priorities.  Priorities are fine when we want to
make a POC, to see if this is workable.  I think we are way past that
point, so leaving unsolved problems is no longer a useful methodology.

> (has it modules?)

Of course.  In a Windows build I have:

  load-suffixes
   => (".dll" ".elc" ".el")

> >> I'd say that xpostmortem wouldn't make sense during normal debugging,
> >> when MPS is not dead in the water. I don't think one can get out of that
> >> state again.
> >
> > I don't follow.  How is debugging problems with GC different from
> > "normal debugging"?
> 
> Imagine running Emacs under GDB and stopping at some breakpoint to debug
> whatever. You want to xbacktrace and then proceed with continue. That
> xbacktrace should not put MPS in post-mortem state.
> 
> > In any case, I asked about the downsides of calling igc_postmorten,
> > which I think is crucial to understand for making this decision.  If
> > there are no significant downsides, then doing so is a net win, no?
> 
> It's post-mortem = after death. MPS is then not in a usable state anymore.

It should have been obvious that I meant to do that after a crash.  I
admit I didn't say that explicitly, but I thought it was obvious.
Sorry.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Because PVEC_OTHER is handled fine now, except whatever w32 does in
>> addition or maybe instead
>
> Then maybe the assertion should be w32-only (if only w32 uses
> PVEC_OTHER; I thought Helmut said he saw the same problem on
> GNU/Linux?).  But removing it completely is not TRT, IMO.  We already
> have quite a lot of code which was disabled under HAVE_MPS, and at
> least some of that looks like workarounds for problems that got "low
> priority".  I'm not sure this is a good way of making progress here,
> especially since some of those #ifdef's could potentially cause
> problems elsewhere.

We've made progress since then. The code now uses a new PVEC type for
module references, and so we should be fine in all cases since the old
GC code doesn't do anything special for PVEC_OTHER. Only remaining check
that could to be done is if the scroll bar struct on w32 contains a
pointer to something that must be traced, but I find that highly
unlikely.

> I think we should methodically try to solve every problem we bump
> into, without any priorities.  Priorities are fine when we want to
> make a POC, to see if this is workable.  I think we are way past that
> point, so leaving unsolved problems is no longer a useful methodology.

Yeah, except for the native compilation, which I currently prioritize
for mysefl. I haven't made progress there, alas.

But otherwise, I must say I'm kind of impressed by us :-).

>> (has it modules?)
>
> Of course.  In a Windows build I have:
>
>   load-suffixes
>    => (".dll" ".elc" ".el")

Ah, ok. Thanks! DLLs, of course...

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> I have a nice test case, that crashes both GUI and tty versions.  Can
> you reproduce this?
>
> ./src/emacs -nw -Q --eval
>   '(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))'

Yep

.../emacs/savannah/igc % ./src/emacs -nw -Q --eval '(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))'
Fatal error 6: Aborted

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 17:01:15 +0200
> 
> 
> I have a nice test case, that crashes both GUI and tty versions.  Can
> you reproduce this?
> 
> ./src/emacs -nw -Q --eval
>   '(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))'

I can.  It crashes in both GUI and TTY cases, but with two very
different backtraces.  Here's the GUI case, it looks very similar to
what I see when scrolling through xdisp.c:

  Thread 1 received signal SIGSEGV, Segmentation fault.
  XCAR (c=0xab5ca1b) at lisp.h:751
  751       return lisp_h_XLP (o);
  (gdb) bt
  #0  XCAR (c=0xab5ca1b) at lisp.h:751
  #1  assoc_no_quit (key=<optimized out>, alist=0xab5ca1b) at fns.c:2032
  #2  0x00afc0ed in font_list_entities (f=0xaa1c478, spec=0xa843cb5)
      at font.c:2795
  #3  0x00afce53 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
      attrs=<optimized out>, attrs@entry=0x727a2b0, spec=<optimized out>,
      spec@entry=0xa843c15, c=<optimized out>, c@entry=-1) at font.c:3316
  #4  0x00afe384 in font_load_for_lface (f=f@entry=0xaa1c478,
      attrs=attrs@entry=0x727a2b0, spec=spec@entry=0xa843c15) at font.c:3396
  #5  0x00a2df2b in realize_gui_face (cache=0x13ca5f88, attrs=0x727a2b0)
      at xfaces.c:6216
  #6  realize_face (cache=cache@entry=0x13ca5f88, attrs=attrs@entry=0x727a2b0,
      former_face_id=former_face_id@entry=-1) at xfaces.c:6053
  #7  0x00a2fdb3 in lookup_face (f=f@entry=0xaa1c478, attr=attr@entry=0x727a2b0)
      at xfaces.c:4989
  #8  0x00a32dcc in face_at_string_position (w=0xaa1c628,
      string=<optimized out>, string@entry=0x1a14b7d4, pos=pos@entry=1,
      bufpos=bufpos@entry=0, endptr=endptr@entry=0x727a37c,
      base_face_id=MODE_LINE_ACTIVE_FACE_ID, mouse_p=mouse_p@entry=false,
      attr_filter=attr_filter@entry=0) at xfaces.c:6930
  #9  0x00999268 in display_string (string=string@entry=0x13cbe338 "xdisp.c",
      lisp_string=0xac58f6c, face_string=face_string@entry=0x1a14b7d4,
      face_string_pos=face_string_pos@entry=1, start=start@entry=0,
      it=it@entry=0x727a690, field_width=field_width@entry=12,
      precision=precision@entry=-13, max_x=max_x@entry=0,
      multibyte=multibyte@entry=0) at xdisp.c:29116
  #10 0x0099a299 in display_mode_element (it=it@entry=0x727a690,
      depth=<optimized out>, depth@entry=3, field_width=<optimized out>,
      precision=<optimized out>, precision@entry=-13, elt=<optimized out>,
      elt@entry=0x1a14b7d4, props=<optimized out>, props@entry=0x0,
      risky=<optimized out>, risky@entry=false) at xdisp.c:27788
  #11 0x0099b5ff in display_mode_element (it=it@entry=0x727a690, depth=3,
      depth@entry=1, field_width=0, precision=precision@entry=-13,
      elt=<optimized out>, elt@entry=0x1903ec10, props=props@entry=0x0,
      risky=risky@entry=false) at xdisp.c:27965
  #12 0x0099b5ff in display_mode_element (it=it@entry=0x727a690, depth=1,
      depth@entry=0, field_width=field_width@entry=0,
      precision=precision@entry=0, elt=<optimized out>, elt@entry=0x1a24e953,
      props=props@entry=0x0, risky=risky@entry=false) at xdisp.c:27965
  #13 0x0099cba9 in display_mode_line (w=w@entry=0xaa1c628,
      face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x1a24e953) at lisp.h:1179
  #14 0x0099f695 in display_mode_lines (w=w@entry=0xaa1c628) at xdisp.c:27303
  #15 0x009b7df2 in redisplay_window (window=window@entry=0xaa1c62d,
      just_this_one_p=just_this_one_p@entry=true) at xdisp.c:20924
  #16 0x009bcab8 in redisplay_window_1 (window=0xaa1c62d) at xdisp.c:18023
  #17 0x00ad289b in internal_condition_case_1 (
      bfun=bfun@entry=0x9bca80 <redisplay_window_1>, arg=0xaa1c62d,
      handlers=0x1a2c10c3, hfun=hfun@entry=0x966297 <redisplay_window_error>)
      at eval.c:1568
  #18 0x009a124e in redisplay_internal () at xdisp.c:17512
  #19 0x009a2463 in redisplay () at xdisp.c:16562
  #20 0x00a46088 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=0x134aabc3, prev_event=<optimized out>,
      used_mouse_menu=<optimized out>, used_mouse_menu@entry=0x727f7fb,
      end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
  #21 0x00a496bd in read_key_sequence (keybuf=keybuf@entry=0x727f8d8,
      prompt=prompt@entry=0x0,
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #22 0x00a4b24b in command_loop_1 () at lisp.h:1179
  #23 0x00ad27fd in internal_condition_case (
      bfun=bfun@entry=0xa4b090 <command_loop_1>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0xa3e3d6 <cmd_error>) at eval.c:1544
  #24 0x00a346eb in command_loop_2 (handlers=0x48) at keyboard.c:1168
  #25 0x00ad2717 in internal_catch (tag=tag@entry=0x87a8,
      func=func@entry=0xa346cb <command_loop_2>, arg=arg@entry=0x48)
      at eval.c:1224
  #26 0x00a3468b in command_loop () at lisp.h:1179
  #27 0x00a3df91 in recursive_edit_1 () at keyboard.c:754
  #28 0x00a3e281 in Frecursive_edit () at keyboard.c:837
  #29 0x00c77c0f in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626
  (gdb) q
  A debugging session is active.

	  Inferior 1 [process 85368] will be killed.

  Quit anyway? (y or n) y

  d:\gnu\git\emacs\feature>gdb ./src/emacs.exe
  GNU gdb (MinGW32 GDB) 14.1
  Copyright (C) 2023 Free Software Foundation, Inc.
  License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
  This is free software: you are free to change and redistribute it.
  There is NO WARRANTY, to the extent permitted by law.
  Type "show copying" and "show warranty" for details.
  This GDB was configured as "i686-pc-mingw32".
  Type "show configuration" for configuration details.
  For bug reporting instructions, please see:
  <https://www.gnu.org/software/gdb/bugs/>.
  Find the GDB manual and other documentation resources online at:
      <http://www.gnu.org/software/gdb/documentation/>.

  For help, type "help".
  Type "apropos word" to search for commands related to "word"...
  Reading symbols from ./src/emacs.exe...
  <lo-file) (redisplay) (igc--collect) (forward-line))"
  Starting program: d:\gnu\git\emacs\feature\src\emacs.exe -Q --eval "(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))"
  [New Thread 102324.0x18470]
  [New Thread 102324.0x1a438]
  [New Thread 102324.0x19768]
  warning: Enabling Low Fragmentation Heap failed: error 87
  [New Thread 102324.0x18630]
  [New Thread 102324.0x124e4]
  [New Thread 102324.0x19da4]
  [Thread 102324.0x19da4 exited with code 1]
  [New Thread 102324.0x1adc4]
  [Thread 102324.0x1adc4 exited with code 1]
  [New Thread 102324.0x1a0a4]
  [Thread 102324.0x1a0a4 exited with code 1]
  [New Thread 102324.0x196b4]
  [Thread 102324.0x196b4 exited with code 1]
  [New Thread 102324.0x182ec]
  [Thread 102324.0x182ec exited with code 1]
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  warning: ScriptGetFontScriptTags failed with 0x8007000e
  *** MPS GC start: Client requests: immediate full collection.

  Thread 1 received signal SIGSEGV, Segmentation fault.
  XCAR (c=0xb2c6f33) at lisp.h:751
  751       return lisp_h_XLP (o);
  (gdb) bt
  #0  XCAR (c=0xb2c6f33) at lisp.h:751
  #1  assoc_no_quit (key=<optimized out>, alist=0xb2c6f33) at fns.c:2032
  #2  0x00afc0ed in font_list_entities (f=0xaa1c478, spec=0xa8217a5)
      at font.c:2795
  #3  0x00afce53 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
      attrs=<optimized out>, attrs@entry=0x727a2b0, spec=<optimized out>,
      spec@entry=0xa821705, c=<optimized out>, c@entry=-1) at font.c:3316
  #4  0x00afe384 in font_load_for_lface (f=f@entry=0xaa1c478,
      attrs=attrs@entry=0x727a2b0, spec=spec@entry=0xa821705) at font.c:3396
  #5  0x00a2df2b in realize_gui_face (cache=0xc349f88, attrs=0x727a2b0)
      at xfaces.c:6216
  #6  realize_face (cache=cache@entry=0xc349f88, attrs=attrs@entry=0x727a2b0,
      former_face_id=former_face_id@entry=-1) at xfaces.c:6053
  #7  0x00a2fdb3 in lookup_face (f=f@entry=0xaa1c478, attr=attr@entry=0x727a2b0)
      at xfaces.c:4989
  #8  0x00a32dcc in face_at_string_position (w=0xc0007b0,
      string=<optimized out>, string@entry=0x1a32b7d4, pos=pos@entry=1,
      bufpos=bufpos@entry=0, endptr=endptr@entry=0x727a37c,
      base_face_id=MODE_LINE_ACTIVE_FACE_ID, mouse_p=mouse_p@entry=false,
      attr_filter=attr_filter@entry=0) at xfaces.c:6930
  #9  0x00999268 in display_string (string=string@entry=0xc0371e8 "HELLO",
      lisp_string=0xc03948c, face_string=face_string@entry=0x1a32b7d4,
      face_string_pos=face_string_pos@entry=1, start=start@entry=0,
      it=it@entry=0x727a690, field_width=field_width@entry=12,
      precision=precision@entry=-13, max_x=max_x@entry=0,
      multibyte=multibyte@entry=0) at xdisp.c:29116
  #10 0x0099a299 in display_mode_element (it=it@entry=0x727a690,
      depth=<optimized out>, depth@entry=3, field_width=<optimized out>,
      precision=<optimized out>, precision@entry=-13, elt=<optimized out>,
      elt@entry=0x1a32b7d4, props=<optimized out>, props@entry=0x0,
      risky=<optimized out>, risky@entry=false) at xdisp.c:27788
  #11 0x0099b5ff in display_mode_element (it=it@entry=0x727a690, depth=3,
      depth@entry=1, field_width=0, precision=precision@entry=-13,
      elt=<optimized out>, elt@entry=0x1921ec10, props=props@entry=0x0,
      risky=risky@entry=false) at xdisp.c:27965
  #12 0x0099b5ff in display_mode_element (it=it@entry=0x727a690, depth=1,
      depth@entry=0, field_width=field_width@entry=0,
      precision=precision@entry=0, elt=<optimized out>, elt@entry=0x1a42e953,
      props=props@entry=0x0, risky=risky@entry=false) at xdisp.c:27965
  #13 0x0099cba9 in display_mode_line (w=w@entry=0xc0007b0,
      face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x1a42e953) at lisp.h:1179
  #14 0x0099f695 in display_mode_lines (w=w@entry=0xc0007b0) at xdisp.c:27303
  #15 0x009b7df2 in redisplay_window (window=window@entry=0xc0007b5,
      just_this_one_p=just_this_one_p@entry=true) at xdisp.c:20924
  #16 0x009bcab8 in redisplay_window_1 (window=0xc0007b5) at xdisp.c:18023
  #17 0x00ad289b in internal_condition_case_1 (
      bfun=bfun@entry=0x9bca80 <redisplay_window_1>, arg=0xc0007b5,
      handlers=0x1a4a10c3, hfun=hfun@entry=0x966297 <redisplay_window_error>)
      at eval.c:1568
  #18 0x009a124e in redisplay_internal () at xdisp.c:17512
  #19 0x009a2463 in redisplay () at xdisp.c:16562
  #20 0x00a46088 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=0xa82060b, prev_event=<optimized out>,
      used_mouse_menu=<optimized out>, used_mouse_menu@entry=0x727f7fb,
      end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
  #21 0x00a496bd in read_key_sequence (keybuf=keybuf@entry=0x727f8d8,
      prompt=prompt@entry=0x0,
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #22 0x00a4b24b in command_loop_1 () at lisp.h:1179
  #23 0x00ad27fd in internal_condition_case (
      bfun=bfun@entry=0xa4b090 <command_loop_1>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0xa3e3d6 <cmd_error>) at eval.c:1544
  #24 0x00a346eb in command_loop_2 (handlers=0x48) at keyboard.c:1168
  #25 0x00ad2717 in internal_catch (tag=tag@entry=0x87a8,
      func=func@entry=0xa346cb <command_loop_2>, arg=arg@entry=0x48)
      at eval.c:1224
  #26 0x00a3468b in command_loop () at lisp.h:1179
  #27 0x00a3df91 in recursive_edit_1 () at keyboard.c:754
  #28 0x00a3e281 in Frecursive_edit () at keyboard.c:837
  #29 0x00c77c0f in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626

And here's the TTY case, it seems to hit assertion violation while
accessing a window object (this is a build with --enable-checking):

  Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
  0x75f45693 in KERNELBASE!DebugBreak () from C:\WINDOWS\SysWOW64\KernelBase.dll
  (gdb) thread 1
  [Switching to thread 1 (Thread 110144.0x1888c)]
  #0  0x75f45693 in KERNELBASE!DebugBreak ()
     from C:\WINDOWS\SysWOW64\KernelBase.dll
  (gdb) bt
  #0  0x75f45693 in KERNELBASE!DebugBreak ()
     from C:\WINDOWS\SysWOW64\KernelBase.dll
  #1  0x00b817b6 in emacs_abort () at w32fns.c:11262
  #2  0x00a34090 in terminate_due_to_signal (sig=sig@entry=22,
      backtrace_limit=backtrace_limit@entry=2147483647) at emacs.c:480
  #3  0x00aa87e0 in die (
      msg=msg@entry=0x1007e6c <frame_parms+2444> "WINDOWP (a)",
      file=file@entry=0x1007e63 <frame_parms+2435> "window.h",
      line=line@entry=491) at alloc.c:8337
  #4  0x009b6dd9 in XWINDOW (a=<optimized out>) at window.h:489
  #5  XWINDOW (a=<optimized out>) at window.h:489
  #6  redisplay_window (window=window@entry=0xb00022d,
      just_this_one_p=just_this_one_p@entry=false) at xdisp.c:21045
  #7  0x009bcaf4 in redisplay_window_0 (window=0xb00022d) at xdisp.c:18015
  #8  0x00ad289b in internal_condition_case_1 (
      bfun=bfun@entry=0x9bcabf <redisplay_window_0>, arg=arg@entry=0xb00022d,
      handlers=0x1a4310c3, hfun=hfun@entry=0x966297 <redisplay_window_error>)
      at eval.c:1568
  #9  0x00961eed in redisplay_windows (window=0xb00022d) at xdisp.c:17984
  #10 0x009a0f0f in redisplay_internal () at xdisp.c:17384
  #11 0x009a2463 in redisplay () at xdisp.c:16562
  #12 0x00a46088 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=0xa845e0b, prev_event=<optimized out>,
      used_mouse_menu=<optimized out>, used_mouse_menu@entry=0x727f7fb,
      end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
  #13 0x00a496bd in read_key_sequence (keybuf=keybuf@entry=0x727f8d8,
      prompt=prompt@entry=0x0,
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #14 0x00a4b24b in command_loop_1 () at lisp.h:1179
  #15 0x00ad27fd in internal_condition_case (
      bfun=bfun@entry=0xa4b090 <command_loop_1>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0xa3e3d6 <cmd_error>) at eval.c:1544
  #16 0x00a346eb in command_loop_2 (handlers=0x48) at keyboard.c:1168
  #17 0x00ad2717 in internal_catch (tag=tag@entry=0x87a8,
      func=func@entry=0xa346cb <command_loop_2>, arg=arg@entry=0x48)
      at eval.c:1224
  #18 0x00a3468b in command_loop () at lisp.h:1179
  #19 0x00a3df91 in recursive_edit_1 () at keyboard.c:754
  #20 0x00a3e281 in Frecursive_edit () at keyboard.c:837
  #21 0x00c77c0f in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> I have a nice test case, that crashes both GUI and tty versions.  Can
> you reproduce this?
>
> ./src/emacs -nw -Q --eval
>   '(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))'

For me, it's echo_area_window, which is AFAICS not staticpro'd (booooh
to myself). That leads to XWINDOW accessing a window that has been moved
away. Haven't had to look further.

There are quite some other global vars in xdisp.c that need staticpros.
And there are non-Lisp_Object which need something similar (struct
buffer *, for example). One could use

 void igc_root_create_exact_ptr (void *var_addr);

for them, or make them Lisp_Objects and staticpro.

Please let me know if someone of you wants to work on this.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 26 Apr 2024 17:01:15 +0200
>> 
>> 
>> I have a nice test case, that crashes both GUI and tty versions.  Can
>> you reproduce this?
>> 
>> ./src/emacs -nw -Q --eval
>>   '(progn (view-hello-file) (redisplay) (igc--collect) (forward-line))'
>
> I can.  It crashes in both GUI and TTY cases, but with two very
> different backtraces.  Here's the GUI case, it looks very similar to
> what I see when scrolling through xdisp.c:
>
>   Thread 1 received signal SIGSEGV, Segmentation fault.
>   XCAR (c=0xab5ca1b) at lisp.h:751
>   751       return lisp_h_XLP (o);
>   (gdb) bt
>   #0  XCAR (c=0xab5ca1b) at lisp.h:751
>   #1  assoc_no_quit (key=<optimized out>, alist=0xab5ca1b) at fns.c:2032
>   #2  0x00afc0ed in font_list_entities (f=0xaa1c478, spec=0xa843cb5)
>       at font.c:2795
>   #3  0x00afce53 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
>       attrs=<optimized out>, attrs@entry=0x727a2b0, spec=<optimized out>,
>       spec@entry=0xa843c15, c=<optimized out>, c@entry=-1) at font.c:3316

...

>   #13 0x0099cba9 in display_mode_line (w=w@entry=0xaa1c628,
>       face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x1a24e953) at
>       lisp.h:1179

I wonder if this could also be caused by the missing tracing of global
variables in xdisp.c that I mention in the other mail. I would propose
to fix that first.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

On Fri, Apr 26 2024, Gerd Möllmann wrote:

> For me, it's echo_area_window, which is AFAICS not staticpro'd (booooh
> to myself). That leads to XWINDOW accessing a window that has been moved
> away. Haven't had to look further.

What are the rules for staticpro?  Are they written up somewhere?  I
never needed that before.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

On Fri, Apr 26 2024, Gerd Möllmann wrote:

> Eli Zaretskii <eliz@gnu.org> writes:

>> I can.  It crashes in both GUI and TTY cases, but with two very
>> different backtraces.  Here's the GUI case, it looks very similar to
>> what I see when scrolling through xdisp.c:
[...]
>
> I wonder if this could also be caused by the missing tracing of global
> variables in xdisp.c that I mention in the other mail. I would propose
> to fix that first.

For me the GUI and TTY version have both something to do with
echo_area_window.  Though the function where XWINDOW is called with
echo_area_window as argument is for the TTY version redisplay_window and
for the GUI version hscroll_window_tree.

Helmut

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, Apr 26 2024, Gerd Möllmann wrote:
>
>> For me, it's echo_area_window, which is AFAICS not staticpro'd (booooh
>> to myself). That leads to XWINDOW accessing a window that has been moved
>> away. Haven't had to look further.
>
> What are the rules for staticpro?  Are they written up somewhere?  I
> never needed that before.

You would put them in syms_of_xdisp, and that's basically it.

  x = Qnil;
  staticpro (&x);
  y = Qnil;
  staticpro (&y);

It's probably a good idea to make sure the vars are initialized to
something before there is any chance that MPS sees them, or we actually,
when we trace them.

The calls to igc_..._var would also go there, also with inits.

Thanks!

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

> On Fri, Apr 26 2024, Gerd Möllmann wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I can.  It crashes in both GUI and TTY cases, but with two very
>>> different backtraces.  Here's the GUI case, it looks very similar to
>>> what I see when scrolling through xdisp.c:
> [...]
>>
>> I wonder if this could also be caused by the missing tracing of global
>> variables in xdisp.c that I mention in the other mail. I would propose
>> to fix that first.
>
> For me the GUI and TTY version have both something to do with
> echo_area_window.  Though the function where XWINDOW is called with
> echo_area_window as argument is for the TTY version redisplay_window and
> for the GUI version hscroll_window_tree.

Yeah, I'm afraid we must trace _all_ the candidate globals in xdisp.c.
Otherwise Emacs is likely to crash somewhere else, with another var, at
some point.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

[-- Attachment #1: Type: text/plain, Size: 192 bytes --]

> You would put them in syms_of_xdisp, and that's basically it.

Ok, I hope got them all.  The scratch_glyphs array was a bit weird.

With this, the test case no longer crashes.

Good night!


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Staticpro-more-global-vars-in-xdisp.c.patch --]
[-- Type: text/x-diff, Size: 1832 bytes --]

From 417c07ecdcdcab38c6fe733084ee35da3f8098ac Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@gmail.com>
Date: Fri, 26 Apr 2024 22:33:04 +0200
Subject: [PATCH] Staticpro more global vars in xdisp.c

---
 src/xdisp.c | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/src/xdisp.c b/src/xdisp.c
index 5fe16ab9536..4d33052d063 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -500,6 +500,9 @@ Copyright (C) 1985-2024 Free Software Foundation, Inc.
 #ifdef HAVE_WINDOW_SYSTEM
 #include TERM_HEADER
 #endif /* HAVE_WINDOW_SYSTEM */
+#ifdef HAVE_MPS
+#include "igc.h"
+#endif
 
 #ifndef FRAME_OUTPUT_DATA
 #define FRAME_OUTPUT_DATA(f) (NULL)
@@ -37391,6 +37394,37 @@ syms_of_xdisp (void)
   staticpro (&previous_help_echo_string);
   help_echo_pos = -1;
 
+#ifdef HAVE_MPS
+  this_line_buffer = NULL;
+  igc_root_create_exact_ptr (&this_line_buffer);
+  {
+    size_t len = (sizeof default_invis_vector
+		  / sizeof (default_invis_vector[0]));
+    for (size_t i = 0; i < len; i++)
+      {
+	default_invis_vector[i] = Qnil;
+	staticpro (&default_invis_vector[i]);
+      }
+  }
+  echo_area_window = Qnil;
+  staticpro (&echo_area_window);
+  {
+    size_t len = sizeof (scratch_glyphs) / sizeof (scratch_glyphs[0]);
+    for (size_t i = 0; i < len; i++)
+      {
+	Lisp_Object *ptr = &scratch_glyphs[i].object;
+	*ptr = Qnil;
+	staticpro (ptr);
+      }
+  }
+  displayed_buffer = NULL;
+  igc_root_create_exact_ptr (&displayed_buffer);
+  last_escape_glyph_frame = NULL;
+  igc_root_create_exact_ptr (&last_escape_glyph_frame);
+  last_glyphless_glyph_frame = NULL;
+  igc_root_create_exact_ptr (&last_glyphless_glyph_frame);
+#endif /* HAVE_MPS */
+
   DEFSYM (Qright_to_left, "right-to-left");
   DEFSYM (Qleft_to_right, "left-to-right");
   defsubr (&Sbidi_resolved_levels);
-- 
2.39.2

Re: Building the igc branch on MS-Windows

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Even if that is true, how does this matter after Emacs crashed?
> Especially if that happened due to MPS assertion violation?

bt is called in plenty of situations besides an irrecoverable crash.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

>> You would put them in syms_of_xdisp, and that's basically it.
>
> Ok, I hope got them all.  The scratch_glyphs array was a bit weird.
>
> With this, the test case no longer crashes.
>
> Good night!

Morning shift here: Pushed and 👍👍😀.

(And a wishlist entry for a debbugs-gnu-apply-patch that is just like "w
w" in Magit.)

Re: Building the igc branch on MS-Windows

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> (And a wishlist entry for a debbugs-gnu-apply-patch that is just like "w
> w" in Magit.)

https://docs.kyleam.com/piem/Overview.html

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> (And a wishlist entry for a debbugs-gnu-apply-patch that is just like "w
>> w" in Magit.)
>
> https://docs.kyleam.com/piem/Overview.html

You mean piem-am? Hm, that would almost be it. Except I don't want the
branch, at least not always...

Thanks!

Re: Building the igc branch on MS-Windows

[Ihor Radchenko]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

>> https://docs.kyleam.com/piem/Overview.html
>
> You mean piem-am?

Yes.

> ... Hm, that would almost be it. Except I don't want the
> branch, at least not always...

piem may use detached HEAD as an alternative if you leave the branch
name empty (may also configure `piem-default-branch-function' to default
to empty return value).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Ihor Radchenko <yantar92@posteo.net> writes:

>> ... Hm, that would almost be it. Except I don't want the
>> branch, at least not always...
>
> piem may use detached HEAD as an alternative if you leave the branch
> name empty (may also configure `piem-default-branch-function' to default
> to empty return value).

Ah, thanks, that looks good indeed!

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 26 Apr 2024 22:45:42 +0200
> 
> > You would put them in syms_of_xdisp, and that's basically it.
> 
> Ok, I hope got them all.  The scratch_glyphs array was a bit weird.
> 
> With this, the test case no longer crashes.

Thanks.

The -nw session now doesn't crash here as well, but the GUI session
still does, with the backtrace below, which is identical to the
backtrace I had before these changes.  So either this is specific to
the 32-bit build (did you try it?), or specific to MS-Windows.

  *** MPS GC start: Client requests: immediate full collection.

  Thread 1 received signal SIGSEGV, Segmentation fault.
  XCAR (c=0xb2c6f33) at lisp.h:751
  751       return lisp_h_XLP (o);
  (gdb) bt
  #0  XCAR (c=0xb2c6f33) at lisp.h:751
  #1  assoc_no_quit (key=<optimized out>, alist=0xb2c6f33) at fns.c:2032
  #2  0x0100c20d in font_list_entities (f=0xaa1c478, spec=0xa8217a5)
      at font.c:2795
  #3  0x0100cf73 in font_find_for_lface (f=<optimized out>, f@entry=0xaa1c478,
      attrs=<optimized out>, attrs@entry=0xbfa2b0, spec=<optimized out>,
      spec@entry=0xa821705, c=<optimized out>, c@entry=-1) at font.c:3316
  #4  0x0100e4a4 in font_load_for_lface (f=f@entry=0xaa1c478,
      attrs=attrs@entry=0xbfa2b0, spec=spec@entry=0xa821705) at font.c:3396
  #5  0x00f3e04b in realize_gui_face (cache=0xc2aff88, attrs=0xbfa2b0)
      at xfaces.c:6216
  #6  realize_face (cache=cache@entry=0xc2aff88, attrs=attrs@entry=0xbfa2b0,
      former_face_id=former_face_id@entry=-1) at xfaces.c:6053
  #7  0x00f3fed3 in lookup_face (f=f@entry=0xaa1c478, attr=attr@entry=0xbfa2b0)
      at xfaces.c:4989
  #8  0x00f42eec in face_at_string_position (w=0xc0007b0,
      string=<optimized out>, string@entry=0x1a3bb7d4, pos=pos@entry=1,
      bufpos=bufpos@entry=0, endptr=endptr@entry=0xbfa37c,
      base_face_id=MODE_LINE_ACTIVE_FACE_ID, mouse_p=mouse_p@entry=false,
      attr_filter=attr_filter@entry=0) at xfaces.c:6930
  #9  0x00ea92b8 in display_string (string=string@entry=0xc0371e8 "HELLO",
      lisp_string=0xc03948c, face_string=face_string@entry=0x1a3bb7d4,
      face_string_pos=face_string_pos@entry=1, start=start@entry=0,
      it=it@entry=0xbfa690, field_width=field_width@entry=12,
      precision=precision@entry=-13, max_x=max_x@entry=0,
      multibyte=multibyte@entry=0) at xdisp.c:29119
  #10 0x00eaa2e9 in display_mode_element (it=it@entry=0xbfa690,
      depth=<optimized out>, depth@entry=3, field_width=<optimized out>,
      precision=<optimized out>, precision@entry=-13, elt=<optimized out>,
      elt@entry=0x1a3bb7d4, props=<optimized out>, props@entry=0x0,
      risky=<optimized out>, risky@entry=false) at xdisp.c:27791
  #11 0x00eab64f in display_mode_element (it=it@entry=0xbfa690, depth=3,
      depth@entry=1, field_width=0, precision=precision@entry=-13,
      elt=<optimized out>, elt@entry=0x18d9ec10, props=props@entry=0x0,
      risky=risky@entry=false) at xdisp.c:27968
  #12 0x00eab64f in display_mode_element (it=it@entry=0xbfa690, depth=1,
      depth@entry=0, field_width=field_width@entry=0,
      precision=precision@entry=0, elt=<optimized out>, elt@entry=0x1a4be953,
      props=props@entry=0x0, risky=risky@entry=false) at xdisp.c:27968
  #13 0x00eacbf9 in display_mode_line (w=w@entry=0xc0007b0,
      face_id=MODE_LINE_ACTIVE_FACE_ID, format=0x1a4be953) at lisp.h:1179
  #14 0x00eaf6e5 in display_mode_lines (w=w@entry=0xc0007b0) at xdisp.c:27306
  #15 0x00ec7e42 in redisplay_window (window=window@entry=0xc0007b5,
      just_this_one_p=just_this_one_p@entry=true) at xdisp.c:20927
  #16 0x00eccb08 in redisplay_window_1 (window=0xc0007b5) at xdisp.c:18026
  #17 0x00fe29bb in internal_condition_case_1 (
      bfun=bfun@entry=0xeccad0 <redisplay_window_1>, arg=0xc0007b5,
      handlers=0x1a5310c3, hfun=hfun@entry=0xe76297 <redisplay_window_error>)
      at eval.c:1568
  #18 0x00eb129e in redisplay_internal () at xdisp.c:17515
  #19 0x00eb24b3 in redisplay () at xdisp.c:16565
  #20 0x00f561a8 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=0xa82060b, prev_event=<optimized out>,
      used_mouse_menu=<optimized out>, used_mouse_menu@entry=0xbff7fb,
      end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
  #21 0x00f597dd in read_key_sequence (keybuf=keybuf@entry=0xbff8d8,
      prompt=prompt@entry=0x0,
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #22 0x00f5b36b in command_loop_1 () at lisp.h:1179
  #23 0x00fe291d in internal_condition_case (
      bfun=bfun@entry=0xf5b1b0 <command_loop_1>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0xf4e4f6 <cmd_error>) at eval.c:1544
  #24 0x00f4480b in command_loop_2 (handlers=0x48) at keyboard.c:1168
  #25 0x00fe2837 in internal_catch (tag=tag@entry=0x87a8,
      func=func@entry=0xf447eb <command_loop_2>, arg=arg@entry=0x48)
      at eval.c:1224
  #26 0x00f447ab in command_loop () at lisp.h:1179
  #27 0x00f4e0b1 in recursive_edit_1 () at keyboard.c:754
  #28 0x00f4e3a1 in Frecursive_edit () at keyboard.c:837
  #29 0x01187d2f in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: gerd.moellmann@gmail.com,  eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 08:21:19 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Even if that is true, how does this matter after Emacs crashed?
> > Especially if that happened due to MPS assertion violation?
> 
> bt is called in plenty of situations besides an irrecoverable crash.

Which obviously means we should modify "xbacktrace" to notice when
Emacs has crashed, and act accordingly.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Helmut Eller <eller.helmut@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 07:26:37 +0200
> 
> Ihor Radchenko <yantar92@posteo.net> writes:
> 
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >> (And a wishlist entry for a debbugs-gnu-apply-patch that is just like "w
> >> w" in Magit.)
> >
> > https://docs.kyleam.com/piem/Overview.html
> 
> You mean piem-am? Hm, that would almost be it. Except I don't want the
> branch, at least not always...

Here's what I do:

  . mark the patch
  . M-| cd /path/to/git/repository && git am RET

This is so simple that I wonder why people need a specialized command
for that.  Moreover, with command-history active, I don't need to type
the command line more than once; after that M-p or M-r will find it
almost immediately.

(If the patch is not in the form of "git format-patch", then I need to
use "git apply" instead of "git am" above, and then manually write the
commit log message and commit with vc-dir, but the same manual work
would be needed in that case with any fancy command as well.)

Re: Building the igc branch on MS-Windows

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > https://docs.kyleam.com/piem/Overview.html
>> 
>> You mean piem-am? Hm, that would almost be it. Except I don't want the
>> branch, at least not always...
>
> Here's what I do:
>
>   . mark the patch
>   . M-| cd /path/to/git/repository && git am RET
>
> This is so simple that I wonder why people need a specialized command
> for that.  Moreover, with command-history active, I don't need to type
> the command line more than once; after that M-p or M-r will find it
> almost immediately.

piem also understands patches sent as attachments, even multiple attachments.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>>> ... Hm, that would almost be it. Except I don't want the
>>> branch, at least not always...
>>
>> piem may use detached HEAD as an alternative if you leave the branch
>> name empty (may also configure `piem-default-branch-function' to default
>> to empty return value).
>
> Ah, thanks, that looks good indeed!

Wow, that works like a charm!

  (use-package piem :straight (:host github
                                     :repo "emacsmirror/piem"
                                     :branch "master")
    :config
    (piem-gnus-mode 1))

Then piem-am in the Gnus article 👍

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Helmut Eller <eller.helmut@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>>   emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 07:26:37 +0200
>> 
>> Ihor Radchenko <yantar92@posteo.net> writes:
>> 
>> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>> >
>> >> (And a wishlist entry for a debbugs-gnu-apply-patch that is just like "w
>> >> w" in Magit.)
>> >
>> > https://docs.kyleam.com/piem/Overview.html
>> 
>> You mean piem-am? Hm, that would almost be it. Except I don't want the
>> branch, at least not always...
>
> Here's what I do:
>
>   . mark the patch
>   . M-| cd /path/to/git/repository && git am RET
>
> This is so simple that I wonder why people need a specialized command
> for that.  Moreover, with command-history active, I don't need to type
> the command line more than once; after that M-p or M-r will find it
> almost immediately.

For me It's laziness. With piem I can now M-x piem-am in the article,
then select the project (using vertico + orderless), then the branch
(vertico + orderless), then tell it the branch I want to create (or
not), and bam done. Nice!

The debbugs one does a bit too much for me, for example it also builds
(with the wrong make command on macOS (should be gmake). And VC is not
so my thing, also.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: gerd.moellmann@gmail.com,  eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 08:21:19 +0800
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Even if that is true, how does this matter after Emacs crashed?
>> > Especially if that happened due to MPS assertion violation?
>> 
>> bt is called in plenty of situations besides an irrecoverable crash.
>
> Which obviously means we should modify "xbacktrace" to notice when
> Emacs has crashed, and act accordingly.

Would it perhaps be an idea to let emacs_abort put MPS in pm state?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> Date: Sat, 27 Apr 2024 09:11:04 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: gerd.moellmann@gmail.com, emacs-devel@gnu.org
> 
>   *** MPS GC start: Client requests: immediate full collection.
> 
>   Thread 1 received signal SIGSEGV, Segmentation fault.
>   XCAR (c=0xb2c6f33) at lisp.h:751
>   751       return lisp_h_XLP (o);
>   (gdb) bt
>   #0  XCAR (c=0xb2c6f33) at lisp.h:751
>   #1  assoc_no_quit (key=<optimized out>, alist=0xb2c6f33) at fns.c:2032
>   #2  0x0100c20d in font_list_entities (f=0xaa1c478, spec=0xa8217a5)
>       at font.c:2795

The crash is here:

  for (; driver_list; driver_list = driver_list->next)
    if (driver_list->on
	&& (NILP (ftype) || EQ (driver_list->driver->type, ftype)))
      {
	Lisp_Object cache = font_get_cache (f, driver_list->driver);

	ASET (scratch_font_spec, FONT_TYPE_INDEX, driver_list->driver->type);
	val = assoc_no_quit (scratch_font_spec, XCDR (cache));

And font_get_cache does this on MS-Windows:

  Lisp_Object
  w32font_get_cache (struct frame *f)
  {
    struct w32_display_info *dpyinfo = FRAME_DISPLAY_INFO (f);

    return (dpyinfo->name_list_element);
  }

dpyinfo on MS-Windows is a single global variable
one_w32_display_info, so I made this change:

diff --git a/src/w32term.c b/src/w32term.c
index 7afd130..96f8530 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -7812,6 +7812,9 @@ #define LOAD_PROC(lib, fn) pfn##fn = (void *) GetProcAddress (lib, #fn)
 void
 syms_of_w32term (void)
 {
+  one_w32_display_info.name_list_element = Qnil;
+  staticpro (&one_w32_display_info.name_list_element);
+
   DEFSYM (Qvendor_specific_keysyms, "vendor-specific-keysyms");
 
   DEFSYM (Qadded, "added");

(Is this correct? should all Lisp members of global variables be
similarly staticpro'd?)

With this change, scrolling through xdisp.c now works (yay!), with the
following messages output several times to stderr:

  *** MPS GC start: Generation 0 of a chain has reached capacity: start a minor collection.
  *** MPS GC start: Opportunism: client predicts plenty of idle time, so start full collection.

(Btw, it would be nice to have these go to echo-area messages
instead.)

But the original Helmut's recipe still crashes, albeit with a
different backtrace:

  *** MPS GC start: Client requests: immediate full collection.

  Thread 1 received signal SIGSEGV, Segmentation fault.
  gui_produce_glyphs (it=0xbfa6b0) at xdisp.c:32587
  32587         boff = font->baseline_offset;
  (gdb) bt
  #0  gui_produce_glyphs (it=0xbfa6b0) at xdisp.c:32587
  #1  0x01030e47 in display_line (it=it@entry=0xbfa6b0,
      cursor_vpos=cursor_vpos@entry=1) at xdisp.c:25389
  #2  0x01037611 in try_window (window=<optimized out>, window@entry=0xc0007b5,
      pos=..., flags=<optimized out>, flags@entry=1) at xdisp.c:21139
  #3  0x01059947 in redisplay_window (window=window@entry=0xc0007b5,
      just_this_one_p=just_this_one_p@entry=false) at xdisp.c:20533
  #4  0x0105cb44 in redisplay_window_0 (window=0xc0007b5) at xdisp.c:18018
  #5  0x011729bb in internal_condition_case_1 (
      bfun=bfun@entry=0x105cb0f <redisplay_window_0>, arg=arg@entry=0xc0007b5,
      handlers=0x1a3e10c3, hfun=hfun@entry=0x1006297 <redisplay_window_error>)
      at eval.c:1568
  #6  0x01001eed in redisplay_windows (window=0xc0007b5) at xdisp.c:17987
  #7  0x01040f5f in redisplay_internal () at xdisp.c:17387
  #8  0x010424b3 in redisplay () at xdisp.c:16565
  #9  0x010e61a8 in read_char (commandflag=<optimized out>, commandflag@entry=1,
      map=<optimized out>, map@entry=0xa82060b, prev_event=<optimized out>,
      used_mouse_menu=<optimized out>, used_mouse_menu@entry=0xbff7fb,
      end_time=<optimized out>, end_time@entry=0x0) at keyboard.c:2678
  #10 0x010e97dd in read_key_sequence (keybuf=keybuf@entry=0xbff8d8,
      prompt=prompt@entry=0x0,
      dont_downcase_last=dont_downcase_last@entry=false,
      can_return_switch_frame=<optimized out>,
      can_return_switch_frame@entry=true, fix_current_buffer=<optimized out>,
      fix_current_buffer@entry=true, prevent_redisplay=<optimized out>,
      prevent_redisplay@entry=false, disable_text_conversion_p=false)
      at keyboard.c:10727
  #11 0x010eb36b in command_loop_1 () at lisp.h:1179
  #12 0x0117291d in internal_condition_case (
      bfun=bfun@entry=0x10eb1b0 <command_loop_1>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0x10de4f6 <cmd_error>) at eval.c:1544
  #13 0x010d480b in command_loop_2 (handlers=0x48) at keyboard.c:1168
  #14 0x01172837 in internal_catch (tag=tag@entry=0x87a8,
      func=func@entry=0x10d47eb <command_loop_2>, arg=arg@entry=0x48)
      at eval.c:1224
  #15 0x010d47ab in command_loop () at lisp.h:1179
  #16 0x010de0b1 in recursive_edit_1 () at keyboard.c:754
  #17 0x010de3a1 in Frecursive_edit () at keyboard.c:837
  #18 0x01317d3f in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626
  (gdb) p font
  $1 = (struct font *) 0xad2fce0
  (gdb) p *$
  Cannot access memory at address 0xad2fce0

So this is progress, but now the font structure of a face is invalid,
so some other protection is missing somewhere.  Any ideas?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>  eller.helmut@gmail.com,
>  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 06:29:23 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> > https://docs.kyleam.com/piem/Overview.html
> >> 
> >> You mean piem-am? Hm, that would almost be it. Except I don't want the
> >> branch, at least not always...
> >
> > Here's what I do:
> >
> >   . mark the patch
> >   . M-| cd /path/to/git/repository && git am RET
> >
> > This is so simple that I wonder why people need a specialized command
> > for that.  Moreover, with command-history active, I don't need to type
> > the command line more than once; after that M-p or M-r will find it
> > almost immediately.
> 
> piem also understands patches sent as attachments, even multiple attachments.

You are missing my point, I think.  I tried to explain it above.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Po Lu <luangruo@yahoo.com>,  eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 08:48:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: gerd.moellmann@gmail.com,  eller.helmut@gmail.com,  emacs-devel@gnu.org
> >> Date: Sat, 27 Apr 2024 08:21:19 +0800
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> > Even if that is true, how does this matter after Emacs crashed?
> >> > Especially if that happened due to MPS assertion violation?
> >> 
> >> bt is called in plenty of situations besides an irrecoverable crash.
> >
> > Which obviously means we should modify "xbacktrace" to notice when
> > Emacs has crashed, and act accordingly.
> 
> Would it perhaps be an idea to let emacs_abort put MPS in pm state?

Maybe, but not all aborts are GC-related.

I think more important is to do this inside SEGV handler.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> The -nw session now doesn't crash here as well, but the GUI session
> still does, with the backtrace below, which is identical to the
> backtrace I had before these changes.  So either this is specific to
> the 32-bit build (did you try it?), or specific to MS-Windows.

On macOS, I see something different:

Emacs starts fine, but when I C-n, C-p a bit, it gets an assertion in
face_for_char at fontset.c:976:4 which is the XSETFONT in this

      if (face->ascii_face->font)
	{
	  XSETFONT (font_object, face->ascii_face->font);
	  if (font_has_char (f, font_object, c))
	    return face->ascii_face->id;
	}

I bet the font is not traced. Will keep you up to date, but I have to do
the laundry first.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> Date: Sat, 27 Apr 2024 09:58:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
> 
>   (gdb) p font
>   $1 = (struct font *) 0xad2fce0
>   (gdb) p *$
>   Cannot access memory at address 0xad2fce0

How do we protect the font objects we create in xfaces.c from being
GC'ed?  AFAICT, the face's 'font' member is the 'struct font' part of
a Lisp font object, which comes from Lisp.  But when the Lisp object
is copied, does MPS update the 'font' pointer of a face?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> (Is this correct? should all Lisp members of global variables be
> similarly staticpro'd?)

LGTM, and yes all of them.

> With this change, scrolling through xdisp.c now works (yay!), with the
> following messages output several times to stderr:

Woohoo!

> So this is progress, but now the font structure of a face is invalid,
> so some other protection is missing somewhere.  Any ideas?

Maybe it's the ascii_font that I found in the other mail? If you give me
an hour I can look into this. Or you could check if fix_face does all it
needs to trace... And maybe fix_font.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 09:23:17 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So this is progress, but now the font structure of a face is invalid,
> > so some other protection is missing somewhere.  Any ideas?
> 
> Maybe it's the ascii_font that I found in the other mail? If you give me
> an hour I can look into this. Or you could check if fix_face does all it
> needs to trace... And maybe fix_font.

There's no fix_font, AFAICT.

In fix_face, I think these should be added to scan:

    struct font *font;
    struct face *next, *prev;
    struct face *ascii_face;
    void *extra;

If some of those are not needed to be scanned, then maybe I don't
understand the criteria for scan-ability?  Would you please explain
the basics here, like MPS 101 thing?

Re: Building the igc branch on MS-Windows

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> piem also understands patches sent as attachments, even multiple attachments.
>
> You are missing my point, I think.  I tried to explain it above.

Most likely, but we are getting off-topic here.

My initial point was to help Gerd's workflow while he is working on this
feature. AFAIU, he finds piem-am useful. Discussing whether there exist
even better workflow is something for another thread, if you want to
discuss it further.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 27 Apr 2024 09:58:00 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
>> 
>>   (gdb) p font
>>   $1 = (struct font *) 0xad2fce0
>>   (gdb) p *$
>>   Cannot access memory at address 0xad2fce0
>
> How do we protect the font objects we create in xfaces.c from being
> GC'ed?  AFAICT, the face's 'font' member is the 'struct font' part of
> a Lisp font object, which comes from Lisp.  But when the Lisp object
> is copied, does MPS update the 'font' pointer of a face?

I'm creating the MPS pools with support for interior pointers, i.e. a
pointer to somehwere inside of an object keeps the object alive. It's
not necessary that there exists a pointer to the object start.

Is that's what happening here?

(Not directly related, just to spread the info: This is necessary anyway
because I'm not using MPS in-band headers. With in-band headers, MPS
would itself do the calculations that I put into client_to_base, and
base_to_client. Base meaning the object start from the perspective of
MPS, and client meaning the object start from Emacs' POV. So, any
reference that Emacs holds is an interior pointer for MPS.

Also handy: a char * into string data keeps the data alive, and makes it
immovable if referenced ambigpusly (control stack). There is no need for
the pinning that is used for the old GC, which prevents string
compaction, or what I called it.)

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 09:23:17 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > So this is progress, but now the font structure of a face is invalid,
>> > so some other protection is missing somewhere.  Any ideas?
>> 
>> Maybe it's the ascii_font that I found in the other mail? If you give me
>> an hour I can look into this. Or you could check if fix_face does all it
>> needs to trace... And maybe fix_font.
>
> There's no fix_font, AFAICT.

Ah, okay, I misrememberd that, sorry. PVEC_FONT is currently traced as a
simple vectorlike, i.e. only Lisp_Object members.

There is one thing in struct font I'm not sure about. it has

  font -> font_driver -> Lisp_Object .type

where type is a symbol from DEFSYM under macOS. Being a DEFSYM means
it's immortal and immovable, of course, which means we don't need to
trace it. But strictly speaking it should be traced, just to not
introduce hidden assumptions. Or maybe it's already demanded somewhere
that that is always the case. And of course I have no idea what other
plaforms do...

> In fix_face, I think these should be added to scan:
>
>     struct font *font;
>     struct face *next, *prev;
>     struct face *ascii_face;

These three in any case, yes.

>     void *extra;

What that is I have no idea. 

> If some of those are not needed to be scanned, then maybe I don't
> understand the criteria for scan-ability?  Would you please explain
> the basics here, like MPS 101 thing?

Ok, it's easy, and you already did TRT.

References interesting for MPS are Lisp_Objects and pointers to objects
in MPS. The need for tracing pointer references is new compared to
non-MPS. It must be done because objects move in memory.

Tracing pointers to non-MPS objects is not necessary. Ideally, it costs
only some cycles. At least that's my understanding, that it does no
harm.

Wrt to tracing interior pointers I'm not entirely sure, because I had
one case only, so far: buffers have a pointer to their text, which is
either the address of own_text or the one of its base buffer. I've taken
the easy way out and compute the text pointer each time the buffer is
traced. Don't know ATM, hat the situation is with a face's font.

One related factoid is probably worth mentioning:

While our scanning callbacks run, MPS guarantees us exclusive access to
only those objects in the address range MPS calls us for. All other
objects are (potentially) behind read/write barriers. So we can't change
something in object A while scanning a different object B.

This does not hold for objects that are not managed by MPS. If B has a
pointer to malloc'd memory M, we can do with M what we want, but MPS
also doesn't protect M from other threads. We're on our own.

Reads a bit bumby. Hope it helps anyway.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 10:38:02 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How do we protect the font objects we create in xfaces.c from being
> > GC'ed?  AFAICT, the face's 'font' member is the 'struct font' part of
> > a Lisp font object, which comes from Lisp.  But when the Lisp object
> > is copied, does MPS update the 'font' pointer of a face?
> 
> I'm creating the MPS pools with support for interior pointers, i.e. a
> pointer to somehwere inside of an object keeps the object alive. It's
> not necessary that there exists a pointer to the object start.
> 
> Is that's what happening here?

Maybe.  If font objects are kept alive, and face->font is supposed to
be updated when the font object moves, by virtue of fix_face, then how
come face->font ends up pointing to inaccessible memory in Helmut's
recipe?

> (Not directly related, just to spread the info: This is necessary anyway
> because I'm not using MPS in-band headers. With in-band headers, MPS
> would itself do the calculations that I put into client_to_base, and
> base_to_client. Base meaning the object start from the perspective of
> MPS, and client meaning the object start from Emacs' POV. So, any
> reference that Emacs holds is an interior pointer for MPS.

Speaking about these two functions: are we sure struct member
alignment will not get in the way of these calculations?  AFAIR,
alignment of struct members is 8, even in 32-bit builds, is that
right?  While sizeof (struct igc_header) yields 8 in my build, I
wonder whether this is enough?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 11:04:40 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> There is one thing in struct font I'm not sure about. it has
> 
>   font -> font_driver -> Lisp_Object .type
> 
> where type is a symbol from DEFSYM under macOS.

Likewise in the w32 build: those symbols are defined via DEFSYM.

> > In fix_face, I think these should be added to scan:
> >
> >     struct font *font;
> >     struct face *next, *prev;
> >     struct face *ascii_face;
> 
> These three in any case, yes.
> 
> >     void *extra;
> 
> What that is I have no idea. 

See xftfont.c, which seems to be the only one using this.

I added both ascii_font and extra to fix_face, but the segfault is
still there.  What else can be done to dig into this crash?

> While our scanning callbacks run, MPS guarantees us exclusive access to
> only those objects in the address range MPS calls us for. All other
> objects are (potentially) behind read/write barriers. So we can't change
> something in object A while scanning a different object B.

I don't understand what you are saying here, because there are too
many unknowns: what are "our scanning callbacks"? what do you mean by
"exclusive access"? what is "the address range MPS calls us for"? what
does "behind read/write barriers" mean in practice? and could you show
a simple example of "can't change something in object A while scanning
a different object B" -- what are object A and object B here?

> This does not hold for objects that are not managed by MPS. If B has a
> pointer to malloc'd memory M, we can do with M what we want, but MPS
> also doesn't protect M from other threads. We're on our own.

What "other threads"?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> Date: Sat, 27 Apr 2024 14:44:57 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
> 
> I added both ascii_font and extra to fix_face, but the segfault is
> still there.  What else can be done to dig into this crash?

Not sure if this helps, but what I see  when Emacs crashes is that it
happens when the display code needs to use a face that is cached under
index 22 in the frame's face cache.  That face seems to be clobbered,
but all the 22 faces before it in the face cache are valid.  The
cache's 'used' count is 57, so index 22 should be valid.  It sounds
like some part of the cache was released or relocated, but we weren't
told about that.

Looking at the related parts in igc.c, I'm confused by how we handle
frames, their face caches, and the faces themselves.  We have:

  . fix_face
  . fix_face_cache
  . IGC_OBJ_FACE and IGC_OBJ_FACE_CACHE cases in dflt_scanx
  . call to IGC_FIX12_RAW (ss, &f->face_cache) in fix_frame
  . igc_make_face_cache (which seems to treat a face cache as a PVEC??)

Can you explain what each one of these do (or is supposed to do) in
the context of this puzzle?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm creating the MPS pools with support for interior pointers, i.e. a
>> pointer to somehwere inside of an object keeps the object alive. It's
>> not necessary that there exists a pointer to the object start.
>> 
>> Is that's what happening here?

I think I can answer my question above now. It's not like the buffer
text case. AFAICS, face->font is just a plain struct font pointer that
is obtained from XFONT_OBJECT. It's like any other reference from a Lisp
object to another, only that it is a pointer.

> Maybe.  If font objects are kept alive, and face->font is supposed to
> be updated when the font object moves, by virtue of fix_face, then how
> come face->font ends up pointing to inaccessible memory in Helmut's
> recipe?

Inaccessible memory in my experience so far means that the corresponding
object has either been moved by MPS, or it has been "freed", by not
copying it.

So, as an ansatz, let's assume the font in question has been moved. It
would follow, I think, that it is not a face->font right? Because
otherwise the reference to the the font would have been traced. The
question would be where the reference to the font comes from?

>> (Not directly related, just to spread the info: This is necessary anyway
>> because I'm not using MPS in-band headers. With in-band headers, MPS
>> would itself do the calculations that I put into client_to_base, and
>> base_to_client. Base meaning the object start from the perspective of
>> MPS, and client meaning the object start from Emacs' POV. So, any
>> reference that Emacs holds is an interior pointer for MPS.
>
> Speaking about these two functions: are we sure struct member
> alignment will not get in the way of these calculations?  AFAIR,
> alignment of struct members is 8, even in 32-bit builds, is that
> right?  While sizeof (struct igc_header) yields 8 in my build, I
> wonder whether this is enough?

I pass wrt the struct alignment. The size of igc_header is 8 here too, 1
word.

Re: Building the igc branch on MS-Windows

[Helmut Eller]

> backtrace I had before these changes.  So either this is specific to
> the 32-bit build (did you try it?), or specific to MS-Windows.

For the 32-bit build, I had to configure it --without-x because I don't
have the 32-bit GTK etc. installed.  But the TTY version worked.

I think I'm running into a problem with lface_id_to_name in xfaces.c.
This is apparently a dynamically allocated array of Lisp_Object.  How do
we trace this?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> >     void *extra;
>> 
>> What that is I have no idea. 
>
> See xftfont.c, which seems to be the only one using this.

Doesn't look like a reference to Lisp data to me, so I'd say we can
ignore it. Usual disclaimers.

> I added both ascii_font and extra to fix_face, but the segfault is
> still there.  What else can be done to dig into this crash?

Hm, I see nothing immediately obvious to do except collecting more info
where the font comes from.

>> While our scanning callbacks run, MPS guarantees us exclusive access to
>> only those objects in the address range MPS calls us for. All other
>> objects are (potentially) behind read/write barriers. So we can't change
>> something in object A while scanning a different object B.
>
> I don't understand what you are saying here, because there are too
> many unknowns: what are "our scanning callbacks"? what do you mean by
> "exclusive access"? what is "the address range MPS calls us for"? 

Ok, sorry.

Our scanning callbacks = functions we register with MPS: dflt_scan, the
various root scanning functions, like scan_staticvec ...

Exclusive access = other threads can't interfere

Address range MPS calls us for = the start and end address of the area
to scan are passed to dflt_scan, for example.

> what does "behind read/write barriers" mean in practice? and could you
> show a simple example of "can't change something in object A while
> scanning a different object B" -- what are object A and object B here?

The barries mean that we might get a SIGBUS or SIGSEGV when trying to
access something (read or write) outside of the scanned area (see
above).

I can't show an example, but maybe this help: Image we are scanning a
cons cell. We can then trace car and cdr as references, but we can't
follow the car and cdr to where tehy point. Let's say cdr is another
cons, then that cons is taboo.

>> This does not hold for objects that are not managed by MPS. If B has a
>> pointer to malloc'd memory M, we can do with M what we want, but MPS
>> also doesn't protect M from other threads. We're on our own.
>
> What "other threads"?

At the moment it's either the main thread or one of the threads created
with make-thread I think it is. Even if only one of these runs at a
time. The scanning is done concurrently in the MPS thread.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: gerd.moellmann@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 14:11:31 +0200
> 
> > backtrace I had before these changes.  So either this is specific to
> > the 32-bit build (did you try it?), or specific to MS-Windows.
> 
> For the 32-bit build, I had to configure it --without-x because I don't
> have the 32-bit GTK etc. installed.

Doesn't --with-x-toolkit=no work?  It should produce a GUI build which
doesn't use any toolkit, but instead uses our own X code to implement
the menus etc.

If you have Lucid, you could also try --with-x-toolkit=lucid -- that
should give you toolkit menus and scroll bars.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 14:09:26 +0200
> 
> Inaccessible memory in my experience so far means that the corresponding
> object has either been moved by MPS, or it has been "freed", by not
> copying it.
> 
> So, as an ansatz, let's assume the font in question has been moved. It
> would follow, I think, that it is not a face->font right? Because
> otherwise the reference to the the font would have been traced. The
> question would be where the reference to the font comes from?

It _is_ face->font.  We get to it like this:

  void
  gui_produce_glyphs (struct it *it)
  {
    int extra_line_spacing = it->extra_line_spacing;

    it->glyph_not_available_p = false;

    if (it->what == IT_CHARACTER)
      {
	unsigned char2b;
	struct face *face = FACE_FROM_ID (it->f, it->face_id);
	struct font *font = face->font; <<<<<<<<<<<<<<<<<<<<<<<<<<<<

IOW, the display iterator references a face by its ID, and we access
that face via the frame's face cache.  As I wrote in a previous
message, all the faces in the cache after index 21 are clobbered,
although the cache's 'used' count is 57, and the index of the
problematic face is 22.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 27 Apr 2024 14:44:57 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: eller.helmut@gmail.com, emacs-devel@gnu.org
>> 
>> I added both ascii_font and extra to fix_face, but the segfault is
>> still there.  What else can be done to dig into this crash?
>
> Not sure if this helps, but what I see  when Emacs crashes is that it
> happens when the display code needs to use a face that is cached under
> index 22 in the frame's face cache.  That face seems to be clobbered,
> but all the 22 faces before it in the face cache are valid.  The
> cache's 'used' count is 57, so index 22 should be valid.  It sounds
> like some part of the cache was released or relocated, but we weren't
> told about that.

Oh, that could explain the font problem, if we loose the face
referencing it.

> Looking at the related parts in igc.c, I'm confused by how we handle
> frames, their face caches, and the faces themselves.  We have:
>
>   . fix_face
>   . fix_face_cache
>   . IGC_OBJ_FACE and IGC_OBJ_FACE_CACHE cases in dflt_scanx
>   . call to IGC_FIX12_RAW (ss, &f->face_cache) in fix_frame
>   . igc_make_face_cache (which seems to treat a face cache as a PVEC??)
>
> Can you explain what each one of these do (or is supposed to do) in
> the context of this puzzle?

I can try, although it's several weeks old now :-).

And I must stress that getting as far as we are now wasn't originally
part of my experiment, so I did only what seemed more or less obvious.

I'll write something up, and send it in a separate mail. (I really don't
remember the details and have to collect them :-)).

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> Looking at the related parts in igc.c, I'm confused by how we handle
> frames, their face caches, and the faces themselves.  We have:
>
>   . fix_face
>   . fix_face_cache
>   . IGC_OBJ_FACE and IGC_OBJ_FACE_CACHE cases in dflt_scanx
>   . call to IGC_FIX12_RAW (ss, &f->face_cache) in fix_frame
>   . igc_make_face_cache (which seems to treat a face cache as a PVEC??)
>
> Can you explain what each one of these do (or is supposed to do) in
> the context of this puzzle?

I think this starts with struct face, and struct face_cache.

Faces are malloc'd in the non-MPS case, and allocated from MPS in the
MPS build (igc_make_face), so face is a non-Lisp, but MPS-managed, GC'd
object. Hence the existence of fix_face.

Reason for that change are the Lisp_Objects in struct face which need to
be traced.

Now that struct face is managed by MPS, we automatically land in
face_cache which holds struct face, which must now be traced. And boom,
face_cache lands in MPS and gets a fix_face_cache.

I think that explains what you asked?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 14:09:26 +0200
>> 
>> Inaccessible memory in my experience so far means that the corresponding
>> object has either been moved by MPS, or it has been "freed", by not
>> copying it.
>> 
>> So, as an ansatz, let's assume the font in question has been moved. It
>> would follow, I think, that it is not a face->font right? Because
>> otherwise the reference to the the font would have been traced. The
>> question would be where the reference to the font comes from?
>
> It _is_ face->font.  We get to it like this:
>
>   void
>   gui_produce_glyphs (struct it *it)
>   {
>     int extra_line_spacing = it->extra_line_spacing;
>
>     it->glyph_not_available_p = false;
>
>     if (it->what == IT_CHARACTER)
>       {
> 	unsigned char2b;
> 	struct face *face = FACE_FROM_ID (it->f, it->face_id);
> 	struct font *font = face->font; <<<<<<<<<<<<<<<<<<<<<<<<<<<<
>
> IOW, the display iterator references a face by its ID, and we access
> that face via the frame's face cache.  As I wrote in a previous
> message, all the faces in the cache after index 21 are clobbered,
> although the cache's 'used' count is 57, and the index of the
> problematic face is 22.

Good!

Can you something wrong ub fix_face_cache (please see the other mail I
sent)?

And then, do we have other references to face_cache than from the frame?
Maybe I've missed one?

Re: Building the igc branch on MS-Windows

[Helmut Eller]

> Doesn't --with-x-toolkit=no work?  It should produce a GUI build which
> doesn't use any toolkit, but instead uses our own X code to implement
> the menus etc.
>
> If you have Lucid, you could also try --with-x-toolkit=lucid -- that
> should give you toolkit menus and scroll bars.

I tried --with-x-toolkit=no but the headers weren't there, so I
installed them.  But now I get this:

checking for library containing tputs... no
configure: error: The required function 'tputs' was not found in any library.
The following libraries were tried (in order):
  libtinfo, libncurses, libterminfo, libcurses, libtermcap
Please try installing whichever of these libraries is most appropriate
for your system, together with its header files.
For example, a libncurses-dev(el) or similar package.


The libncurses-dev package is installed.  And I can also create a simple
binary with:

helmut@caladan:/tmp > cat x.c
#include <term.h>
int main (void) {
  tputs(0,0,0);
}
helmut@caladan:/tmp > i686-linux-gnu-gcc x.c -ltinfo
helmut@caladan:/tmp > ldd a.out 
        linux-gate.so.1 (0xf7ecd000)
        libtinfo.so.6 => /lib/i386-linux-gnu/libtinfo.so.6 (0xf7e75000)
        libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7c00000)
        /lib/ld-linux.so.2 (0xf7ecf000)

So I put the blame on the configure script for not finding it and will
stick to the --without-x version.

Helmut

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 11:04:40 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> There is one thing in struct font I'm not sure about. it has
>> 
>>   font -> font_driver -> Lisp_Object .type
>> 
>> where type is a symbol from DEFSYM under macOS.
>
> Likewise in the w32 build: those symbols are defined via DEFSYM.

I've added a fix_font, so we should be good now in any case.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 16:11:50 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> >> Date: Sat, 27 Apr 2024 11:04:40 +0200
> >> 
> >> Eli Zaretskii <eliz@gnu.org> writes:
> >> 
> >> There is one thing in struct font I'm not sure about. it has
> >> 
> >>   font -> font_driver -> Lisp_Object .type
> >> 
> >> where type is a symbol from DEFSYM under macOS.
> >
> > Likewise in the w32 build: those symbols are defined via DEFSYM.
> 
> I've added a fix_font, so we should be good now in any case.

It seems to crash:

  Thread 1 received signal SIGSEGV, Segmentation fault.
  fix_lisp_obj (ss=ss@entry=0x6fdf358, pobj=0x14379823) at igc.c:399
  399         mps_word_t word = *p;
  (gdb) bt
  #0  fix_lisp_obj (ss=ss@entry=0x6fdf358, pobj=0x14379823) at igc.c:399
  #1  0x008c19be in fix_font (f=0xc0397c0, ss=0x6fdf358) at igc.c:1617
  #2  fix_vector (v=0xc0397c0, ss=0x6fdf358) at igc.c:1741
  #3  dflt_scanx (ss=ss@entry=0x6fdf358, base_start=<optimized out>,
      base_start@entry=0xc038000, base_limit=base_limit@entry=0xc039d68,
      closure=closure@entry=0x0) at igc.c:1211
  #4  0x008c1e8b in dflt_scan (ss=0x6fdf358, base_start=0xc038000,
      base_limit=0xc039d68) at igc.c:1254
  #5  0x00998f79 in TraceScanFormat (limit=0xc039d68, base=0xc038000,
      ss=0x6fdf354) at trace.c:1539
  #6  amcSegScan (totalReturn=0x6fdf350, seg=0xa606cf0, ss=0x6fdf354)
      at poolamc.c:1427
  #7  0x009b8b95 in traceScanSegRes (seg=0xa606cf0, arena=0x1b0000,
      rank=<optimized out>, ts=1) at trace.c:1205
  #8  traceScanSegRes (ts=1, rank=<optimized out>, arena=0x1b0000, seg=0xa606cf0)
      at trace.c:1182
  #9  0x009b8d69 in traceScanSeg (ts=1, rank=1, arena=0x1b0000, seg=0xa606cf0)
      at trace.c:1267
  #10 0x009b9612 in TraceAdvance (trace=<optimized out>) at trace.c:1728
  #11 0x009c675f in TracePoll (workReturn=workReturn@entry=0x6fdf49c,
      collectWorldReturn=collectWorldReturn@entry=0x6fdf498,
      globals=globals@entry=0x1b0008, collectWorldAllowed=1) at trace.c:1849
  #12 0x009c6927 in ArenaPoll (globals=0x1b0008) at global.c:745
  #13 0x009c6ab8 in ArenaRelease (globals=<optimized out>,
      globals@entry=0x1b0008) at traceanc.c:531
  #14 0x009c6b22 in ArenaStartCollect (globals=globals@entry=0x1b0008,
      why=why@entry=4) at traceanc.c:637
  #15 0x009c6b74 in ArenaCollect (globals=globals@entry=0x1b0008,
      why=why@entry=4) at traceanc.c:652
  #16 0x009c6c16 in mps_arena_collect (arena=0x1b0000) at mpsi.c:313
  #17 0x008c22bd in igc_collect () at igc.c:2561
  #18 0x008c22d4 in Figc__collect () at igc.c:2569
  #19 0x008382f9 in eval_sub (form=0xabffb0b) at eval.c:2532
  #20 0x008385fc in Fprogn (body=0xabffb3b) at eval.c:439
  #21 0x008382a1 in eval_sub (form=form@entry=0xabffabb) at eval.c:2486
  #22 0x0083a3ee in Feval (form=0xabffabb, lexical=0x18) at eval.c:2396
  #23 0x008867d5 in exec_byte_code (fun=0xd5fe05 <Seval+5>,
      fun@entry=0x1a7ccb9d, args_template=513, nargs=2, nargs@entry=0,
      args=0x1ac6c0f8, args@entry=0x6fdf840) at lisp.h:751
  #24 0x00838798 in funcall_lambda (fun=fun@entry=0x1a7ccb9d,
      nargs=nargs@entry=0, arg_vector=arg_vector@entry=0x6fdf840) at eval.c:3200
  #25 0x008398a0 in apply_lambda (fun=fun@entry=0x1a7ccb9d,
      args=<optimized out>, count=count@entry=64) at eval.c:3154
  #26 0x00837e9d in eval_sub (form=form@entry=0x1a8a163b) at eval.c:2625
  #27 0x0083a3ee in Feval (form=0x1a8a163b, lexical=lexical@entry=0x18)
      at eval.c:2396
  #28 0x00794991 in top_level_2 () at lisp.h:1179
  #29 0x0083291d in internal_condition_case (
      bfun=bfun@entry=0x794970 <top_level_2>, handlers=handlers@entry=0x48,
      hfun=hfun@entry=0x79e4f6 <cmd_error>) at eval.c:1544
  #30 0x00795113 in top_level_1 (ignore=0x0) at lisp.h:1179
  #31 0x00832837 in internal_catch (tag=tag@entry=0x87a8,
      func=func@entry=0x7950ea <top_level_1>, arg=arg@entry=0x0) at eval.c:1224
  #32 0x0079478f in command_loop () at lisp.h:1179
  #33 0x0079e0b1 in recursive_edit_1 () at keyboard.c:754
  #34 0x0079e3a1 in Frecursive_edit () at keyboard.c:837
  #35 0x009d7d6f in main (argc=<optimized out>, argv=<optimized out>)
      at emacs.c:2626
  (gdb) l
  394     fix_lisp_obj (mps_ss_t ss, Lisp_Object *pobj)
  395     {
  396       MPS_SCAN_BEGIN (ss)
  397       {
  398         mps_word_t *p = (mps_word_t *) pobj;
  399         mps_word_t word = *p;
  400         mps_word_t tag = word & IGC_TAG_MASK;
  401
  402         if (tag == Lisp_Int0 || tag == Lisp_Int1)
  403           return MPS_RES_OK;
  (gdb) p p
  $1 = (mps_word_t *) 0x14379823
  (gdb) p pobj
  $2 = (Lisp_Object *) 0x14379823
  (gdb) p *$
  Cannot access memory at address 0x14379823
  (gdb) fr 1
  #1  0x008c19be in fix_font (f=0xc0397c0, ss=0x6fdf358) at igc.c:1617
  1617        IGC_FIX12_OBJ (ss, &driver->type);
  (gdb) p ss
  $8 = (mps_ss_t) 0x6fdf358
  (gdb) p driver->type
  value has been optimized out
  (gdb) p driver
  $9 = <optimized out>
  (gdb) p f->driver
  $10 = (const struct font_driver *) 0x14379823
  (gdb) p *f
  $11 = {header = {size = 1694498829}, props = {0x0, 0x6ab0, 0x9bacf48, 0x6210,
      0x4f80, 0x14102, 0x19082, 0x19102, 0x36, 0x0, 0x1ba, 0x0, 0xc03a1e3,
      0xaaa3826, 0x6, 0x4c, 0xffffffff}, min_width = 0, max_width = 178368312,
    pixel_size = 178937894, height = 6, space_width = 70, average_width = -1,
    ascent = 0, descent = 178368400, underline_thickness = 178933795,
    underline_position = 4, vertical_centering = 76,
    baseline_offset = 178378356, relative_compose = 178296867,
    default_ascent = 4, encoding_charset = 178363483,
    repertory_charset = 443397523, driver = 0x14379823}

Looks like the pointer to the font points to a bad object?

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 15:26:35 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> >> Date: Sat, 27 Apr 2024 14:09:26 +0200
> >> 
> >> Inaccessible memory in my experience so far means that the corresponding
> >> object has either been moved by MPS, or it has been "freed", by not
> >> copying it.
> >> 
> >> So, as an ansatz, let's assume the font in question has been moved. It
> >> would follow, I think, that it is not a face->font right? Because
> >> otherwise the reference to the the font would have been traced. The
> >> question would be where the reference to the font comes from?
> >
> > It _is_ face->font.  We get to it like this:
> >
> >   void
> >   gui_produce_glyphs (struct it *it)
> >   {
> >     int extra_line_spacing = it->extra_line_spacing;
> >
> >     it->glyph_not_available_p = false;
> >
> >     if (it->what == IT_CHARACTER)
> >       {
> > 	unsigned char2b;
> > 	struct face *face = FACE_FROM_ID (it->f, it->face_id);
> > 	struct font *font = face->font; <<<<<<<<<<<<<<<<<<<<<<<<<<<<
> >
> > IOW, the display iterator references a face by its ID, and we access
> > that face via the frame's face cache.  As I wrote in a previous
> > message, all the faces in the cache after index 21 are clobbered,
> > although the cache's 'used' count is 57, and the index of the
> > problematic face is 22.
> 
> Good!
> 
> Can you something wrong ub fix_face_cache (please see the other mail I
> sent)?

No.  But then I (still) don't feel I understand well enough what
fix_face_cache is supposed to do.

> And then, do we have other references to face_cache than from the frame?
> Maybe I've missed one?

I don't see any other references.  Maybe I'm missing one as well.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> I've added a fix_font, so we should be good now in any case.
>
> It seems to crash:
>
>   Thread 1 received signal SIGSEGV, Segmentation fault.
>   fix_lisp_obj (ss=ss@entry=0x6fdf358, pobj=0x14379823) at igc.c:399
>   399         mps_word_t word = *p;
>
> Looks like the pointer to the font points to a bad object?

Very strange. The font looks okay insofar as the header in dflt_scan
shows.

(lldb) p *header
(igc_header)  (obj_type = IGC_OBJ_VECTOR, pvec_type = PVEC_FONT, hash = 22015, nwords = 15)

But its contents are weird

(lldb) p *f
(font) {
  header = (size = 4611686019048144909)
  props = {
    [0] = NULL
    [1] = NULL
    [2] = NULL
    [3] = NULL
    [4] = 0x00000000023e3e30 (struct Lisp_Symbol *) $10 = 0x0000000102ffbbd8
    [5] = NULL
    [6] = NULL
    [7] = NULL
    [8] = NULL
    [9] = NULL
    [10] = NULL
    [11] = NULL
    [12] = NULL
    [13] = 0x00000006154b8808 (struct Lisp_Symbol *) $11 = 0x00000007160d05b0
    [14] = 0x0000000000000004 (struct Lisp_String *) $12 = NULL
    [15] = 0x000000000000005a (EMACS_INT) $13 = 22
    [16] = 0x0000000102fdcc6d (struct Lisp_Vector *) $14 = 0x0000000102fdcc68
  }
  min_width = 52631005

This one for example ^^^

  max_width = 1
  pixel_size = 2
  height = 0
  space_width = 357275656
  average_width = 6
  ascent = 4
  descent = 0
  underline_thickness = 0
  underline_position = 0
  vertical_centering = true
  baseline_offset = 1
  relative_compose = 0
  default_ascent = 0
  encoding_charset = 10
  repertory_charset = 0
  driver = 0x00000006154b9008
}

Re: Building the igc branch on MS-Windows

[Helmut Eller]

> But its contents are weird

In pdumper:

      /* There are three kinds of font objects that all use PVEC_FONT,
         distinguished by their size.  Font specs and entities are
         harmless data carriers that we can dump like other Lisp
         objects.  Fonts themselves are window-system-specific and
         need to be recreated on each startup.  */

could this be the reason?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I've added a fix_font, so we should be good now in any case.
>>
>> It seems to crash:
>>
>>   Thread 1 received signal SIGSEGV, Segmentation fault.
>>   fix_lisp_obj (ss=ss@entry=0x6fdf358, pobj=0x14379823) at igc.c:399
>>   399         mps_word_t word = *p;
>>
>> Looks like the pointer to the font points to a bad object?
>
> Very strange. The font looks okay insofar as the header in dflt_scan
> shows.
>
> (lldb) p *header
> (igc_header)  (obj_type = IGC_OBJ_VECTOR, pvec_type = PVEC_FONT, hash = 22015, nwords = 15)
>
> But its contents are weird
>
> (lldb) p *f
> (font) {
>   header = (size = 4611686019048144909)
>   props = {
>     [0] = NULL
>     [1] = NULL
>     [2] = NULL
>     [3] = NULL
>     [4] = 0x00000000023e3e30 (struct Lisp_Symbol *) $10 = 0x0000000102ffbbd8
>     [5] = NULL
>     [6] = NULL
>     [7] = NULL
>     [8] = NULL
>     [9] = NULL
>     [10] = NULL
>     [11] = NULL
>     [12] = NULL
>     [13] = 0x00000006154b8808 (struct Lisp_Symbol *) $11 = 0x00000007160d05b0
>     [14] = 0x0000000000000004 (struct Lisp_String *) $12 = NULL
>     [15] = 0x000000000000005a (EMACS_INT) $13 = 22
>     [16] = 0x0000000102fdcc6d (struct Lisp_Vector *) $14 = 0x0000000102fdcc68
>   }
>   min_width = 52631005
>
> This one for example ^^^
>
>   max_width = 1
>   pixel_size = 2
>   height = 0
>   space_width = 357275656
>   average_width = 6
>   ascent = 4
>   descent = 0
>   underline_thickness = 0
>   underline_position = 0
>   vertical_centering = true
>   baseline_offset = 1
>   relative_compose = 0
>   default_ascent = 0
>   encoding_charset = 10
>   repertory_charset = 0
>   driver = 0x00000006154b9008
> }

(lldb) p *header
(igc_header)  (obj_type = IGC_OBJ_VECTOR, pvec_type = PVEC_FONT, hash = 22015, nwords = 15)
(lldb) p sizeof (struct font)
(unsigned long) 216
(lldb) p sizeof (struct font) / 8
(unsigned long) 27
(lldb) p obj_size (sizeof (struct font))
(size_t) 224
(lldb) p to_words (224)
(mps_word_t) 28
(lldb)

Heh? That makes no sense at all.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> Can you something wrong ub fix_face_cache (please see the other mail I
>> sent)?
>
> No.  But then I (still) don't feel I understand well enough what
> fix_face_cache is supposed to do.

WE need to find all pointers to faces in the cache and call IGC_FIX on
them. AFAIR, there was no problem with the hashing when addresses change.

>
>> And then, do we have other references to face_cache than from the frame?
>> Maybe I've missed one?
>
> I don't see any other references.  Maybe I'm missing one as well.

Hm.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Helmut Eller <eller.helmut@gmail.com> writes:

>> But its contents are weird
>
> In pdumper:
>
>       /* There are three kinds of font objects that all use PVEC_FONT,
>          distinguished by their size.  Font specs and entities are
>          harmless data carriers that we can dump like other Lisp
>          objects.  Fonts themselves are window-system-specific and
>          need to be recreated on each startup.  */
>
> could this be the reason?

I think I spider. Unbelievable. Whoever did that should be shot. No
that's too mild. He shall use Visual C++ for one year :-).

Good catch! Thanks Helmut!

Remains the queston what to do...

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 17:29:44 +0200
> 
> Helmut Eller <eller.helmut@gmail.com> writes:
> 
> >> But its contents are weird
> >
> > In pdumper:
> >
> >       /* There are three kinds of font objects that all use PVEC_FONT,
> >          distinguished by their size.  Font specs and entities are
> >          harmless data carriers that we can dump like other Lisp
> >          objects.  Fonts themselves are window-system-specific and
> >          need to be recreated on each startup.  */
> >
> > could this be the reason?
> 
> I think I spider. Unbelievable. Whoever did that should be shot. No
> that's too mild. He shall use Visual C++ for one year :-).
> 
> Good catch! Thanks Helmut!

There's more, I think.  font.h says this near the end of 'struct font':

    /* Font-driver for the font.  */
    struct font_driver const *driver;

    /* There are more members in this structure, but they are private
       to the font-driver.  */
  };

And indeed, w32font.h does this:

  /* The actual structure for a w32 font, that can be cast to struct font.
     The Uniscribe backend extends this.  */
  struct w32font_info
  {
    struct font font;
    TEXTMETRICW metrics;
    unsigned int glyph_idx;
    struct w32_metric_cache **cached_metrics;
    int n_cache_blocks;
    HFONT hfont;
  };

And then w32uniscribe.c does

  /* Extension of w32font_info used by Uniscribe and HarfBuzz backends.  */
  struct uniscribe_font_info
  {
    struct w32font_info w32_font;
    /* This is used by the Uniscribe backend as a pointer to the script
       cache, and by the HarfBuzz backend as a pointer to a hb_font_t
       object.  */
    void *cache;
    /* This is used by the HarfBuzz backend to store the font scale.  */
    double scale;
  };

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 17:25:41 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Can you something wrong ub fix_face_cache (please see the other mail I
> >> sent)?
> >
> > No.  But then I (still) don't feel I understand well enough what
> > fix_face_cache is supposed to do.
> 
> WE need to find all pointers to faces in the cache and call IGC_FIX on
> them.

My problem is more basic: I don't understand what those *FIX* critters
do, for what purpose, and at what time do they run.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 17:29:44 +0200
>> 
>> Helmut Eller <eller.helmut@gmail.com> writes:
>> 
>> >> But its contents are weird
>> >
>> > In pdumper:
>> >
>> >       /* There are three kinds of font objects that all use PVEC_FONT,
>> >          distinguished by their size.  Font specs and entities are
>> >          harmless data carriers that we can dump like other Lisp
>> >          objects.  Fonts themselves are window-system-specific and
>> >          need to be recreated on each startup.  */
>> >
>> > could this be the reason?
>> 
>> I think I spider. Unbelievable. Whoever did that should be shot. No
>> that's too mild. He shall use Visual C++ for one year :-).
>> 
>> Good catch! Thanks Helmut!
>
> There's more, I think.  font.h says this near the end of 'struct font':
>
>     /* Font-driver for the font.  */
>     struct font_driver const *driver;
>
>     /* There are more members in this structure, but they are private
>        to the font-driver.  */
>   };
>
> And indeed, w32font.h does this:
>
>   /* The actual structure for a w32 font, that can be cast to struct font.
>      The Uniscribe backend extends this.  */
>   struct w32font_info
>   {
>     struct font font;
>     TEXTMETRICW metrics;
>     unsigned int glyph_idx;
>     struct w32_metric_cache **cached_metrics;
>     int n_cache_blocks;
>     HFONT hfont;
>   };
>
> And then w32uniscribe.c does
>
>   /* Extension of w32font_info used by Uniscribe and HarfBuzz backends.  */
>   struct uniscribe_font_info
>   {
>     struct w32font_info w32_font;
>     /* This is used by the Uniscribe backend as a pointer to the script
>        cache, and by the HarfBuzz backend as a pointer to a hb_font_t
>        object.  */
>     void *cache;
>     /* This is used by the HarfBuzz backend to store the font scale.  */
>     double scale;
>   };

And

#ifdef NS_IMPL_GNUSTEP
/* this extends font backend font */
struct nsfont_info
{
  struct font font;

  char *name;  /* PostScript name, uniquely identifies on NS systems */

  /* The following metrics are stored as float rather than int.  */

  float width;  /* Maximum advance for the font.  */
  float height;
  float underpos;
  float underwidth;
  float size;
#ifdef __OBJC__
  NSFont *nsfont;
#else /* ! OBJC */
  void *nsfont;
#endif
  char bold, ital;  /* convenience flags */
  char synthItal;
  XCharStruct max_bounds;
  /* We compute glyph codes and metrics on-demand in blocks of 256 indexed
     by hibyte, lobyte.  */
  unsigned int **glyphs; /* map Unicode index to glyph */
  struct font_metrics **metrics;
};
#endif

Re: Building the igc branch on MS-Windows

[Helmut Eller]

> My problem is more basic: I don't understand what those *FIX* critters
> do, for what purpose, and at what time do they run.

The basics are described int the MPS manual.  What is calld fix_<foo> it
igc is the scan method in the doc:

https://memory-pool-system.readthedocs.io/en/latest/guide/lang.html#the-scan-method

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 17:25:41 +0200
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Can you something wrong ub fix_face_cache (please see the other mail I
>> >> sent)?
>> >
>> > No.  But then I (still) don't feel I understand well enough what
>> > fix_face_cache is supposed to do.
>> 
>> WE need to find all pointers to faces in the cache and call IGC_FIX on
>> them.
>
> My problem is more basic: I don't understand what those *FIX* critters
> do, for what purpose, and at what time do they run.

The uppercase IGC_FIX... macros are just wrappers that make using
fix_lisp_obj and fix_raw easier, or even calling subroutines in the
first place, for which MPS requires the use of MPS_FIX_CALL.

All this is in subroutines of dflt_scan, and scan functions for roots.

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>>> Date: Sat, 27 Apr 2024 17:29:44 +0200
>>> 
>>> Helmut Eller <eller.helmut@gmail.com> writes:
>>> 
>>> >> But its contents are weird
>>> >
>>> > In pdumper:
>>> >
>>> >       /* There are three kinds of font objects that all use PVEC_FONT,
>>> >          distinguished by their size.  Font specs and entities are
>>> >          harmless data carriers that we can dump like other Lisp
>>> >          objects.  Fonts themselves are window-system-specific and
>>> >          need to be recreated on each startup.  */
>>> >
>>> > could this be the reason?
>>> 
>>> I think I spider. Unbelievable. Whoever did that should be shot. No
>>> that's too mild. He shall use Visual C++ for one year :-).
>>> 
>>> Good catch! Thanks Helmut!
>>
>> There's more, I think.  font.h says this near the end of 'struct font':
>>
>>     /* Font-driver for the font.  */
>>     struct font_driver const *driver;
>>
>>     /* There are more members in this structure, but they are private
>>        to the font-driver.  */
>>   };
>>
>> And indeed, w32font.h does this:
>>
>>   /* The actual structure for a w32 font, that can be cast to struct font.
>>      The Uniscribe backend extends this.  */
>>   struct w32font_info
>>   {
>>     struct font font;
>>     TEXTMETRICW metrics;
>>     unsigned int glyph_idx;
>>     struct w32_metric_cache **cached_metrics;
>>     int n_cache_blocks;
>>     HFONT hfont;
>>   };
>>
>> And then w32uniscribe.c does
>>
>>   /* Extension of w32font_info used by Uniscribe and HarfBuzz backends.  */
>>   struct uniscribe_font_info
>>   {
>>     struct w32font_info w32_font;
>>     /* This is used by the Uniscribe backend as a pointer to the script
>>        cache, and by the HarfBuzz backend as a pointer to a hb_font_t
>>        object.  */
>>     void *cache;
>>     /* This is used by the HarfBuzz backend to store the font scale.  */
>>     double scale;
>>   };
>
> And
>
> #ifdef NS_IMPL_GNUSTEP
> /* this extends font backend font */
> struct nsfont_info
> {
>   struct font font;
>
>   char *name;  /* PostScript name, uniquely identifies on NS systems */
>
>   /* The following metrics are stored as float rather than int.  */
>
>   float width;  /* Maximum advance for the font.  */
>   float height;
>   float underpos;
>   float underwidth;
>   float size;
> #ifdef __OBJC__
>   NSFont *nsfont;
> #else /* ! OBJC */
>   void *nsfont;
> #endif
>   char bold, ital;  /* convenience flags */
>   char synthItal;
>   XCharStruct max_bounds;
>   /* We compute glyph codes and metrics on-demand in blocks of 256 indexed
>      by hibyte, lobyte.  */
>   unsigned int **glyphs; /* map Unicode index to glyph */
>   struct font_metrics **metrics;
> };
> #endif

I have randomly reverted and reapplied commits and fix_font is gone
again. Sorry for the chaos, seems I'm a bit tired.

Re: Building the igc branch on MS-Windows

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
> Date: Sat, 27 Apr 2024 11:04:40 +0200
> 
> > If some of those are not needed to be scanned, then maybe I don't
> > understand the criteria for scan-ability?  Would you please explain
> > the basics here, like MPS 101 thing?
> 
> Ok, it's easy, and you already did TRT.
> 
> References interesting for MPS are Lisp_Objects and pointers to objects
> in MPS. The need for tracing pointer references is new compared to
> non-MPS. It must be done because objects move in memory.
> 
> Tracing pointers to non-MPS objects is not necessary. Ideally, it costs
> only some cycles. At least that's my understanding, that it does no
> harm.

Let me understand the meaning of this for our usual Emacs coding
style.  We use the following paradigm _a_lot_:

  struct window *w = XWINDOW (some_window);
  /* ... much later ... */
  do_something_with (w);

(The do_something_with doesn't have to be a function call, it could be
some comparison with another 'struct window' pointer, or dereferencing
w to access some field of 'struct window', etc.)

Given that now the some_window object can move in memory as result of
GC, what does it mean for code like above?  Will MPS magically update
the pointer in w to point to the new location, or use VM protection to
redirect any accesses to the pointer in w to the new location?  For
that matter, can GC even happen between XWINDOW and do_something_with?
Since GC is (AFAIU) asynchronous and runs in another thread, what can
trigger GC while the Lisp thread runs code like above?  Do we now have
to be cautious with accessing Lisp objects via their C pointers, like
we did until now with Lisp strings and buffer text?

Is the above a real issue, or is it already taken care of for us by
MPS?

Re: Building the igc branch on MS-Windows

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: eller.helmut@gmail.com,  emacs-devel@gnu.org
>> Date: Sat, 27 Apr 2024 11:04:40 +0200
>> 
>> > If some of those are not needed to be scanned, then maybe I don't
>> > understand the criteria for scan-ability?  Would you please explain
>> > the basics here, like MPS 101 thing?
>> 
>> Ok, it's easy, and you already did TRT.
>> 
>> References interesting for MPS are Lisp_Objects and pointers to objects
>> in MPS. The need for tracing pointer references is new compared to
>> non-MPS. It must be done because objects move in memory.
>> 
>> Tracing pointers to non-MPS objects is not necessary. Ideally, it costs
>> only some cycles. At least that's my understanding, that it does no
>> harm.
>
> Let me understand the meaning of this for our usual Emacs coding
> style.  We use the following paradigm _a_lot_:
>
>   struct window *w = XWINDOW (some_window);
>   /* ... much later ... */
>   do_something_with (w);
>
> (The do_something_with doesn't have to be a function call, it could be
> some comparison with another 'struct window' pointer, or dereferencing
> w to access some field of 'struct window', etc.)

Ok.

> Given that now the some_window object can move in memory as result of
> GC, what does it mean for code like above?  Will MPS magically update
> the pointer in w to point to the new location, or use VM protection to
> redirect any accesses to the pointer in w to the new location?  For
> that matter, can GC even happen between XWINDOW and do_something_with?
> Since GC is (AFAIU) asynchronous and runs in another thread, what can
> trigger GC while the Lisp thread runs code like above?  Do we now have
> to be cautious with accessing Lisp objects via their C pointers, like
> we did until now with Lisp strings and buffer text?
>
> Is the above a real issue, or is it already taken care of for us by
> MPS?

Yes, it is taken care of.

MPS scans the control stack as an ambiguous root. It is more or less
what the old GC does in that references found on the stack keep objects
alive. In addition to keeping objects alive, ambif references also
prevent moving these objects because we don't know if the reference is
"real" or just a random bit pattern. That's the "mostly" in the
mostly-copying idea, for which one could at one time get a patent :-(.