I reported the issues already to Eliot Miranda, but maybe this here is a better way, so that others can recognise the fixes and integrate them.

I made now 3 changes in the current VMMaker.image. Please look at the SegFaultFixes.zip. It contains 3 changes on 3 methods.

### TMethod-protectToBeExcludedReceiversForInlining I needed to comment out the code, coz it is the only place where something is transformed to “self_in_inlined_method”, but there is no other reader/usage. The result was that the C code generator created code where the structure accesses like page->baseFP was corrupted and could not be compiled. Normally code like “page -> baseFP” is created, but with the activated smalltalk code there is code like “baseFP(self_in_inlined_method)” created and it cannot find the declaration of “self_in_inline_method"

### SpurMemoryManager-ensureRoomOnObjStackAt I changed "self growOldSpaceByAtLeast: ObjStackPageSlots” into "self growOldSpaceByAtLeast: ObjStackPageSlots * self bytesPerOop”, so that it grows with the right byte size and not slot size.

### SpurGenerationScavenger-growRememberedSet I changed "manager growOldSpaceByAtLeast: numSlots + 1024” to "manager growOldSpaceByAtLeast: (numSlots + 1024) * self bytesPerOop”, so that it grows with right byte size and not slot size. This was my original bug, where the VM crashes on my Linux system with a segmentation fault. The problem was that it tries multiple times to allocate a new remembered set, but it fails and grows then. But the growing does not use bytesize, it uses the number of slots and then the last "never failing" allocate fails again

[SegFaultFixes.zip](https://github.com/OpenSmalltalk/opensmalltalk-vm/files/14038474/SegFaultFix...)

There is another segmentation fault bug in the virtual machine, but hard to reproduce and not easy to find. It happens sometimes that an object-slot in future-space contains an object-pointer, where the sixth byte is modified. If I change this sixth byte back matching the other slots, then I can reach a valid object at this address. I don't guess that the probability is high that changing a sixth byte leads to a valid object address. So I assume there is somebody that corrupts this single byte. I have modified my virtual machine sources on C side, so that all memory accesses like longPointerAt() use now validation code, but this validation code was not triggered yet and the virtual machine did not crash again. If I know more I will create another issue. But just for the case, maybe somebody has an idea.