Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Nov 2024 19:48:36 +0100
> 
> I'm using scratch/igc on and off since some weeks for work (mostly
> Dart/Flutter code edition with lsp-mode, quite stressing for the GC
> system). Today it crashed, so I launched it again under gdb, and there
> it SIGSEGVs consistently while processing the init files. That means
> that it SIGSEGVs at the same point every time I try.

SIGSEGV is used by MPS to implement memory barriers.  The file
src/.gdbinit on the branch has this:

  # Pass on signals used by MPS to suspend threads.
  if defined_HAVE_MPS
    # Print SIGSEGV for now, since it makes the logs more useful.  Don't
    # stop, though.
    handle SIGSEGV nostop print pass
    handle SIGXFSZ nostop noprint pass
    handle SIGXCPU nostop noprint pass
  end

So if you don't want to see these segfaults, change

    handle SIGSEGV nostop print pass
to
    handle SIGSEGV nostop noprint pass

> So I went to build it in debug mode to obtain a good backtrace, but the
> build fails:
> 
> ../../emacs/src/marker.c: In function ‘buf_bytepos_to_charpos’:
> ../../emacs/src/marker.c:389:18: error: invalid operands to binary && (have 
> ‘int’ and ‘Lisp_Object’)
>   389 |       if (record && BUF_MARKERS (b))
>       |           ~~~~~~ ^~
>       |           |
>       |           int

I tried to fix this now, please try again.

> So right now here igc runs when executed from the shell, but crashes on
> startup when executed from gdb. And builds succesfully in release mode,
> but doesn't in debug mode.
> 
> I wonder if either my build config is too infrequent or nobody is
> testing igc lately?

The segfaults you see are not real, they are arranged by MPS
deliberately.