Subject: bug#34655: 26.1.92; Segfault in module with --module-assertions

From: Eli Zaretskii <[email-masked]>
Date: Sun, 17 Mar 2019 19:08:01 +0200

> From: "Basil L. Contovounesios" <[email-masked]>
> Cc: <[email-masked]>, Philipp Stephani <[email-masked]>
> Date: Sun, 17 Mar 2019 16:38:58 +0000
> 
> These reveal that value_to_lisp eventually returns a corrupted string,
> but I don't know why.

Did you try to identify the code which causes the corruption, i.e. the
data is valid before that code runs, and invalid after that?  If not,
can you try?  The way to do that is by painstakingly stepping through
the code while examining the relevant data, possibly with help of
watchpoints and displays set up by the GDB "display" command.

> I've seen comments in src/fileio.c referring to string-relocation
> during GC; could this be at play here?

It could be, if your module code holds onto C pointers to Lisp string
data while Emacs runs parts of the interpreter which could GC.  Does
that happen anywhere in your code or in the code involved in
module-assertions?

> Either way, do you have any suggestions on how to proceed?

See above.

I tried at the time to reproduce your problem, and failed.  But I did
that on Windows, where I needed to replace the non-existent realpath
by an equivalent function, so it's not a faithful reproduction.  I
will see if I can find time to look at this on a GNU machine, unless
someone beats me to it.

> 8. bt full
> 9. f 2
> 10. p p
> 11. pr [#<INVALID_LISP_OBJECT 0x03059c90>]
> 12. xpr

Why did you expect 'p' to be a valid Lisp object?  It's actually a
pointer to a Lisp object, i.e. try

  (gdb) p *p
  (gdb) xpr