Phil, I've now looked into this and hopefully fixed it in CVS.
saveState gets a new segment of memory from the system each time it is called and copies everything that is reachable from the root into that. As well being written out the segment needs to be retained as a whole since if a child state is created the child relies on all the contents of the parent being at a fixed location. If saveState is called more than once a new segment is created and most, if not all, of the existing segment is copied into it. It is possible, though, that some data may not be copied over because it is only reachable from the stacks of running threads. Rather than delete existing segments they are turned into "local" heap segments. These local segments are managed by the normal garbage collector and the GC may deallocate and return them to the system pool if they are no longer required. The solution to these "Out of Memory" exceptions is simply to call FullGC between calls to saveState and that's what I've done. The segfault was as a result of not handling cleanly the case of being unable to allocate a new segment part-way through the state saving, and I've fixed that.
Let me know if there are still problems. Regards, David
Philip Clayton wrote:
David,
We have noticed some interesting behaviour with the state saving in Poly/ML 5.2/5.2.1--- possibly a sign that something isn't quite as intended.
If poly is started and the command
PolyML.SaveState.saveState "test";
is repeatedly entered, a segmentation fault eventually occurs. On my machine it always happens after 22 times. With the debug level set to 2 or 3, we get:
Bad pointer 0x0d479050 found Aborted
If we enter
PolyML.fullGC ();
just before the 22nd go, there is no segmentation fault. However, continuing to enter the original save state command results in the exception
Exception- SysErr ("Out of Memory", SOME ENOMEM) raised
after 8 more goes.
We found this example more by chance. We have had a few other repeatable segmentation faults when saving the state but on very large examples and these are hard to reduce down. (They may be related to the above issue.) In each case, the segmentation fault could be avoided by executing PolyML.fullGC first. Generally, if we cannot create an SML script that generates an error, what is the best way to track down an issue?
Thanks, Phil