igc: trying to chase a crash

igc: trying to chase a crash

[Óscar Fuentes]

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.

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

$ gcc --version
gcc (Debian 14.2.0-8) 14.2.0

$ uname -a
Linux sky 6.11.5-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.11.5-1 (2024-10-27) x86_64 GNU/Linux

$ ../emacs/configure CPPFLAGS=-I/home/oscar/lib/mps/include LDFLAGS=-L/home/oscar/lib/mps/lib --with-native-compilation --with-tree-sitter --without-toolkit-scroll-bars --with-x-toolkit=lucid --with-modules --without-imagemagick --with-mps=yes --enable-checking='yes,glyphs' --enable-check-lisp-object-type CFLAGS='-O0 -g3'

The igc/branch is updated (commit 0756b1f2f5452d715396f).

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?

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.

Re: igc: trying to chase a crash

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

> 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 does it make sense to run igc under gdb for obtaining backtraces when
it crashes?

>>   389 |       if (record && BUF_MARKERS (b))
>>       |           ~~~~~~ ^~
>>       |           |
>>       |           int
>
> I tried to fix this now, please try again.

Thanks. That instance compiles now, but then...

../../emacs/src/fns.c: In function ‘weak_hash_remove_from_table’:
../../emacs/src/fns.c:5789:26: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
 5789 |               && hashval == WEAK_HASH_HASH (h, i)
      |                          ^~ ~~~~~~~~~~~~~~~~~~~~~
      |                             |
      |                             Lisp_Object

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Nov 2024 20:53:03 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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 does it make sense to run igc under gdb for obtaining backtraces when
> it crashes?

Yes, it does.  Because if you hit a real segfault, it will stop again.

> 
> >>   389 |       if (record && BUF_MARKERS (b))
> >>       |           ~~~~~~ ^~
> >>       |           |
> >>       |           int
> >
> > I tried to fix this now, please try again.
> 
> Thanks. That instance compiles now, but then...
> 
> ../../emacs/src/fns.c: In function ‘weak_hash_remove_from_table’:
> ../../emacs/src/fns.c:5789:26: error: invalid operands to binary == (have ‘Lisp_Object’ and ‘Lisp_Object’)
>  5789 |               && hashval == WEAK_HASH_HASH (h, i)
>       |                          ^~ ~~~~~~~~~~~~~~~~~~~~~
>       |                             |
>       |                             Lisp_Object

Fixed.

How about if you say "make -k", so that we see all the problems at
once, not one by one?

Re: igc: trying to chase a crash

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> So does it make sense to run igc under gdb for obtaining backtraces when
>> it crashes?
>
> Yes, it does.  Because if you hit a real segfault, it will stop again.

Ok, thanks.

> Fixed.
>
> How about if you say "make -k", so that we see all the problems at
> once, not one by one?

:-)

Loading mwheel...
Pure Lisp storage overflowed

Error: error ("Cannot continue, pure space overflowed")
  defalias(mouse-wheel--get-scroll-window #[257 "\30127\0\10\203\16\0\302\1!\202\20\0\303 \304\1!\205\34\0\305\306\2!\307\"\310\1!\2054\0\311 \211@\1A\312\313\314\3\5#\5\315\316$\266\203\266\2020\206=\0\302\1!\207" [mouse-wheel-follow-mouse found mwheel-event-window selected-window window-live-p frame-parameter window-frame mouse-wheel-frame frame-live-p mouse-absolute-pixel-position walk-window-tree make-closure #[257 "\302\1\303\304\211$\211@\301X\205)\0\301\305\28X\205)\0\211A@\300X\205)\0\300\306\28X\205)\0\307\310\3\"\207" [V0 V1 window-edges nil t 2 3 throw found] 6 "\n\n(fn WINDOW-1)"] nil t] 11 "Return window for mouse wheel event EVENT.\nIf `mouse-wheel-follow-mouse' is non-nil, return the window that\nthe mouse pointer is over.  Otherwise, return the currently\nactive window.\n\n
 (fn EVENT)"])
  load("mwheel")
  (if (fboundp 'x-create-frame) (load "mwheel"))
  load("loadup.el")
Cannot continue, pure space overflowed

ok, ok... setting SYSTEM_PURESIZE_EXTRA fixes that and the build
completes. But I'm surprised to be the first to report these problems.
Is the igc project dormant? Are there people interested on bug reports
about igc?

Re: igc: trying to chase a crash

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Mon, 25 Nov 2024 21:51:03 +0100
> 
> > How about if you say "make -k", so that we see all the problems at
> > once, not one by one?
> 
> :-)
> 
> Loading mwheel...
> Pure Lisp storage overflowed
> 
> Error: error ("Cannot continue, pure space overflowed")
>   defalias(mouse-wheel--get-scroll-window #[257 "\30127\0\10\203\16\0\302\1!\202\20\0\303 \304\1!\205\34\0\305\306\2!\307\"\310\1!\2054\0\311 \211@\1A\312\313\314\3\5#\5\315\316$\266\203\266\2020\206=\0\302\1!\207" [mouse-wheel-follow-mouse found mwheel-event-window selected-window window-live-p frame-parameter window-frame mouse-wheel-frame frame-live-p mouse-absolute-pixel-position walk-window-tree make-closure #[257 "\302\1\303\304\211$\211@\301X\205)\0\301\305\28X\205)\0\211A@\300X\205)\0\300\306\28X\205)\0\307\310\3\"\207" [V0 V1 window-edges nil t 2 3 throw found] 6 "\n\n(fn WINDOW-1)"] nil t] 11 "Return window for mouse wheel event EVENT.\nIf `mouse-wheel-follow-mouse' is non-nil, return the window that\nthe mouse pointer is over.  Otherwise, return the currently\nactive window.\n
 \n(fn EVENT)"])
>   load("mwheel")
>   (if (fboundp 'x-create-frame) (load "mwheel"))
>   load("loadup.el")
> Cannot continue, pure space overflowed
> 
> ok, ok... setting SYSTEM_PURESIZE_EXTRA fixes that and the build
> completes.

Please tell by how much you needed to enlarge the pure space (the
minimum increment that fixes the build).

> But I'm surprised to be the first to report these problems.
> Is the igc project dormant?

No.  I guess there's not a lot of people who build it with
enable-checking and enable-check-lisp-object-type, that's all.

> Are there people interested on bug reports about igc?

Yes, of course.

Re: igc: trying to chase a crash

[Gerd Möllmann]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Is the igc project dormant? 

It's not very active lately, yes. And judging from the number of reports
lately, which I think equals 1, it either has a very low number of bugs,
or a very low number of users. So I'd say neither users nor developers
are pushing things forward at the moment. Don't know more either, it's
just what I'm observing.

For me personally, I can say that I'm using igc daily, for months now,
on macOS, in my fork, and it's working very well. But that's of course
only the system in my office and so on.

> Are there people interested on bug reports about igc?

I am interested, but I'm also macOS-only, so I'm not of much help with
other platforms. (And macOS as a Mach system is quite different in some
important low-level aspects like signal handling vs. Mach exception
handling.)