bug#74831: 31.0.50; scratch/igc: segfaults on startup when called under gdb

[Eli Zaretskii]

> From: Gregor Zattler <telegraph@gmx.net>
> Cc: 74831@debbugs.gnu.org
> Date: Thu, 12 Dec 2024 17:15:45 +0100
> 
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x0000555555779816 in XSETCDR (c=..., n=n@entry=...) at ./src/lisp.h:1605
> >> 1605         *xcdr_addr (c) = n;
> >
> > So what is the value of xcdr_addr(s) here?  It looks like
> > dereferencing it causes the segfault, so its value might give us some
> > hints.
> 
> sorry, I'm clueless:
> 
> (gdb) print xcdr_addr
> No symbol "xcdr_addr" in current context.

No, you should say

  (gdb) print xcdr_addr(c)

> > Also, where did you start GDB?  It looks like you started it not from
> > the Emacs' src/ directory,
> 
> I started it in the Emacs src directory::
> 
> (gdb) pwd
> Working directory /home/grfz/src/emacs-igc2/src.
> 
> because you once told me to do so for
> gdb.

That's strange, because if you did that, the backtrace command would
have shown a Lisp backtrace as well, which didn't happen.

> I now added
> 
>  -ex "source /home/grfz/src/emacs-igc2/src/.gdbinit"
> 
> to my gdb invocation and tried again.
> Now there are plenty of
> 
> Program received signal SIGSEGV, Segmentation fault.

That's expected.

> lines in GDBs output but Emacs runs and
> and (not so far) functions correct.
> 
> > before running Emacs.  That's because the MPS library uses SIGSEGV for
> > its memory barriers, and .gdbinit there makes sure such SIGSEGVs don't
> > stop Emacs.  IOW, this could be a false positive, not a real segfault.
> 
> That seemed to be the case.

Yes.

I think we can close this bug now.