This post is an update on my ongoing GC crash investigation. For an introduction see GC Crash Summary.

Thanks to Clément this issue is now resolved!

Clément wrote a nice explanation of the issue and how he tracked it down. Since I don’t want to lose the email I’ve taken the liberty of copying Clément’s reply in GC Crash Explanation.

I can’t add anything to the exaplanation, just a couple of additional notes on running a Pharo image inside the simulator…

The bug is reproducible in a minimal Pharo image, which makes life significantly simpler as the simulator currently doesn’t support FFI calls, and if it did there would be many more unknowns in terms of memory corruption. Being able to use the minimal Pharo image means:

• FreeType isn’t present. FreeType uses FFI and is currently suspected of memory corruption.
• The minimal image is only 14MB, vs 54MB for a full image, so the simulator starts up more quickly and is able to do scavenges and gc more quickly.
• FFI is being used more and more in the full image, so it avoids those complications.

OSPlatform>>currentWorkingDirectoryPathWithBuffer: is currently defined as:

currentWorkingDirectoryPathWithBuffer: aByteString
	<primitive: 'primitiveGetCurrentWorkingDirectory' module: '' error: ec>
	
	^ (self getPwdViaFFI: aByteString size: aByteString size) 
		ifNil:[ self error:'Insufficient buffer size to read current working directory: ' , aByteString size asString]

however since the module isn’t specified in the primitive definition it fails, falls through and always does a FFI call.

Changing it to:

currentWorkingDirectoryPathWithBuffer: aByteString
	<primitive: 'primitiveGetCurrentWorkingDirectory' module: 'UnixOSProcessPlugin' error: ec>
	
	^self primitiveFailed

works (on Unix).