[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fix to long-standing crashes in GC
From: |
Luc Teirlinck |
Subject: |
Re: Fix to long-standing crashes in GC |
Date: |
Mon, 24 May 2004 22:03:34 -0500 (CDT) |
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.
- Re: Fix to long-standing crashes in GC, (continued)
Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/14
- Re: Fix to long-standing crashes in GC, Lars Hansen, 2004/05/23
- Re: Fix to long-standing crashes in GC, Eli Zaretskii, 2004/05/23
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/23
- Re: Fix to long-standing crashes in GC, Lars Hansen, 2004/05/23
- Re: Fix to long-standing crashes in GC, Eli Zaretskii, 2004/05/24
- Re: Fix to long-standing crashes in GC,
Luc Teirlinck <=
- Re: Fix to long-standing crashes in GC, Eli Zaretskii, 2004/05/25
Re: Fix to long-standing crashes in GC, Robert Marshall, 2004/05/15
Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/17
- Re: Fix to long-standing crashes in GC, Luc Teirlinck, 2004/05/17
- Re: Fix to long-standing crashes in GC, Richard Stallman, 2004/05/18
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19
- Re: Fix to long-standing crashes in GC, Stefan Monnier, 2004/05/19
- Re: Fix to long-standing crashes in GC, Kim F. Storm, 2004/05/19