zilla@nyit.UUCP (John Lewis) (10/16/89)
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.
brian@topaz.jpl.nasa.gov (Brian of ASTD-CP) (10/17/89)
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. . . . . . . .