Re: xscheme bug

[Brian of ASTD-CP <brian@topaz.rutgers.edu>]

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  . . . . . . . . . brian@topaz.jpl.nasa.gov. . .
. . . JPL Computer Graphics Lab. . . . (818) 397-9207. . . . . . . .