[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eli Zaretskii
Subject: bug#34655: 26.1.92; Segfault in module with --module-assertions
Date: Sun, 17 Mar 2019 19:08:01 +0200

> From: "Basil L. Contovounesios" <address@hidden>
> Cc: <address@hidden>, Philipp Stephani <address@hidden>
> 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

> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]