[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: xscheme bug
In article <362@nyit.UUCP> zilla@nyit.UUCP (John Lewis) writes:
|| there is a bug in xscheme0.17's (restore) function. the bug is
|| that garbage collection should be inhibited during the main part of
|| xlirestore(). This is because the image is restored in node-array
|| order, rather than obarray order. For example, strings may be
|| restored before the symbols which refer to them, and a gc before
|| the corresponding symbol is restored will remove the string (set
|| its type to FREE). routines called in xlirestore (e.g.
|| getvspace()) can trigger gc.
|| A fix is simply to set a flag inhibiting gc during the main part
|| of xlirestore. dbetz confirmed that this is a reasonable fix.
I'm glad someone brought this up again. This bug has been around
since 0.16, and a similar fix has been proposed before. This fix
D O E S N O T W O R K
at least, it does not work if you are restoring a work space requiring
more than a single vector segment (your workspace might be this big
if you have a lot of symbols).
The irony of the situation is that the bigger your workspace, the more
likely you are to need save/restore.
My analysis of the problem is incomplete, but my preliminary
indications are as follows:
* gc(), as a side effect, through gc_protect() and compact(), causes
the attributes of "vscurrent", the current vector segment, to
be set correctly, and it also sets the values of two global
variables, "vfree" and "vtop".
* If you inhibit garbage collection during restore, those variables
are not set correctly.
* Thus, on the first attempt to get more vector memory on behalf of
xlirestore(), xscheme errors with the message "insufficient
vector space". Really, there is more memory available. In fact,
malloc just returned a pointer to it. But "vfree" and "vtop" are
left pointing to the prior FULL segment, so when xscheme tries to
use the new vector memory, it finds it is STILL full.
I don't have a good solution to this. I don't even have a kludge
work around (yet). Anyone care to take a crack at solving this one?
. . . Brian Beckman . . . . . . . . . firstname.lastname@example.org. . .
. . . JPL Computer Graphics Lab. . . . (818) 397-9207. . . . . . . .
- xscheme bug
- From: John Lewis <email@example.com>