Re: Fix to long-standing crashes in GC

[Luc Teirlinck <teirllm@dms.auburn.edu>]

Eli Zaretskii wrote:

   If you can show where's the text that assumes that, i.e. is not clear
   to someone who doesn't have a good knowledge about Emacs memory
   management, I'm sure someone will try to improve those parts of the
   text.

For instance:

    Once you discover the corrupted Lisp object or data structure, it is
    useful to look at it in a fresh Emacs session and compare its contents
    with a session that you are debugging.

Except that to notice that a Lisp object is corrupted you have to
_already_ know how its contents look in a fresh Emacs session.  Many
Elisp programmers do not have a very good knowledge about the very low
level C structure of various Lisp objects.

As an example, when I tried to debug a recent gc crash, the very first
thing I noticed was that the immediate cause of the abort was that the
garbage collector was trying to mark a Lisp_Misc_Free object.  That
_was_ the problem, I did not need to look any further.  Except that at
the time I did not know that this was not supposed to happen.  (I know
now.)  I did not even know what a Lisp_Misc_Free object was.  (I know
now.)  So I went through all of the last_marked array, without any
idea of what to look for, that is: how do you recognize a "corrupted
Lisp object or data structure"?

When you see:

(gdb) p last_marked_index
$1 = 18
(gdb) p last_marked[17]
$2 = 143587538
(gdb) pr
#<EMACS BUG: INVALID DATATYPE (MISC 0x0002) Save your buffers
immediately and please report this bug>

_then_ things are pretty obvious.  But that is not always the case.

Other more concrete ambiguous stuff:

    This is not easy since GC changes the tag bits and relocates strings
    which make it hard to look at Lisp objects with commands such as `pr'.
    It is sometimes necessary to convert Lisp_Object variables into
    pointers to C struct's manually.

It says "It is sometimes necessary...".  When?

When I see:

pr

that is, no output, I can guess it is necessary.

What if I see:

pr
""

I know from experience that I still have to use xstring in that case,
even though the empty string is a perfectly valid return value.  But
xstring often reveals a different real value anyway.  Is this a bug in
pr or is this normal?

What if I see

pr
"dired-find-file"

Can I trust _this_ or should I still use xstring, that is, should the
above have said: "It is always necessary, to be safe,..."?

Sincerely,

Luc.