[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Reproduceable Segmentation fault while saving images (#444)

[Eliot Miranda]

John, one could easily add that facility, but I believe that the problem is more likely to do with dangling pointers than FreeType writing into the heap.  I suspect that what happens is that on a previous save or restart, pointers to C memory that was allocated in the run before the current one are not invalidated and still used.  I believe the problem is that the FFI is not being used properly and that it is not at fault.  Instead, stale pointers are being followed abd memory corruption occurring.

As I said above the necessity is in checking that a valid image is created and that stake pointers are invalidated.

This is an age old problem with Smalltalk programs that use external memory, external handles, descriptors, etc. There is a style which desks well with this and it should be followed.

1. when creating references to external C memory that may persist across a snapshot (such as to an opened external font object), the object that references the external memory should be registered in some set.

2. The Smalltalk system sends a post-snapshot resumption message to any and all classes that register for this service, with an  argument that indicates whether the system is continuing after a snapshot or loading the snapshot in a fresh run.

3. When loading the snapshot in a fresh run all objects that reference external C memory are visited very early in system startup and each ensures that it invalidates any and all pointers to external memory, file descriptors, etc.

Using this style we do not have to close and reopen around a snapshot, but we do have to perform the invalidation early enough so that there is no chance of accessing anything external before all invalidations are complete.

Further, using a registry of objects is much much better than using, for example, allInstances because typically there are few (tens, hundreds at most, not thousands) of objects that reference external resources, and they may be of various classes, so the registry is able to reference them in more or less linear time in the size of the registry, independent of image size, while using allInstances accesses objects in time proportional to the product of the number of classes and the image size.  Clearly this does not scale as the system gets more complex and the image size grows.  Startup time is very important.  I led the VisualWorks team through this exercise and we were able to reduce start up times from hundreds of milliseconds to forty milliseconds (IIRC) in the VW 3.0 timeframe.


-- 
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/444#issuecomment-553879690
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20191114/02be4aa8/attachment.html>