Just had the VM crash on me - did nothing serious, just debugging some stuff. Any ideas?
0x000c2dbc updatePointersInRangeFromto + 268 (crt.c:355) 0x000b6f1c becomewithtwoWaycopyHash + 252 (crt.c:355) 0x000b72c0 primitiveArrayBecome + 48 (crt.c:355) 0x000ca67c interpret + 6892 (crt.c:355)
This is latest Mac OS 3.8 VM ...
- Bert -
On 5-Dec-05, at 8:45 AM, Bert Freudenberg wrote:
Just had the VM crash on me - did nothing serious, just debugging some stuff. Any ideas?
Despite the work I did some months ago on the become prim there are still pathological cases where I wasn't able to think of a way to fully guard the prim.
From prepareForwardingTableForBecoming: array1 with: array2 twoWay: twoWayFlag
"Important note on multiple references to same object - since the preparation of fwdBlocks is NOT idempotent we get VM crashes if the same object is referenced more than once in such a way as to require multiple fwdBlocks. oop1 forwardBecome: oop1 is ok since only a single fwdBlock is needed. oop1 become: oop1 would fail because the second fwdBlock woudl not have the actual object header but rather the mutated ref to the first fwdBlock. Further problems can arise with an array1 or array2 that refer multiply to the same object. This would notbe expected input for programmer writen code but might arise from automatic usage such as in ImageSegment loading. To avoid the simple and rather common case of oop1 become*: oop1, we skip such pairs and simply avoid making fwdBlocks - it is redundant anyway"
The prim needs some guarding in the image to try to check for problem cases. It's just too convoluted to be sensibly done in the VM.
tim
squeak-dev@lists.squeakfoundation.org