Operations on SequenceableCollections and subclasses can corrupt objects
Anytime elements are inserted or removed from a SequenceableCollection or any of it's subclasses (including Array, OrderedCollection, and SortedCollection) with a size greater than 2034, there is a very slight risk that it may become corrupted or the gem crash with a SIGSEGV.
Large collections are internally represented as a tree structure containing LargeObjectNodes. Only the LargeObjectNode containing the relevant part of a collection need be loaded into the VM, saving space and avoiding the need to load the entire collection. But operations such as insert and remove may require more of the LargeObjectNodes to be loaded as elements are shuffled up or down to make space or replace inserted/removed elements. If an in-gem GC is triggered by the loading of additional LargeObjectNodes, there is a small risk that internal references to objects will not be properly updated. As objects are shifted in memory during the GC, the references will now point to the wrong place within the object. Memory references may fail with SIGSEGV, and if new data is written to these objects, it may be written in the wrong place, silently corrupting the object.
Workaround
Download and file-in the following code from ftp://ftp.gemtalksystems.com/pub/patches/bug45358.gs
This patch creates method SequenceableCollection>>_bug45358, and modifies appropriate methods to call it as needed.
The method _bug45358 touches each LargeObjectNode of the collection by doing a no-op write to the first element, making sure that they are all loaded into the VM and avoiding the bug. This will result in a small performance impact and a greater load on the VM's memory, potentially causing out-of-memory errors. There will also be a greater volume of tranlog entries as the no-op write will force all the LargeObjectNodes to be written to the tranlogs during a commit.
Code available at ftp://ftp.gemtalksystems.com/pub/patches/bug45358.gs
Last updated: 6/9/15