<div dir="ltr">Hi,<div><br><div>I believe there is a bug in FFICallbackThunk class>>#freeBlockInExecutablePage: (in Alien-Core). </div><div>If there are multiple pages allocated, it is possible that the address comparison with the end of  the executable page will mistakenly pass.  What will end up happening is that you'll get an #unsignedByteAt:put: failure ('bad index') error during finalization when the section of that page is being marked as free.</div><div><br></div><div>For example, I saw the failure where the address being freed was 1785856 (16r1B4000).  There was a page at 16r1B3000, so the check for this address evaluates to true.  This ends up trying to use 4097 as the index (dataSize is 4096 here).</div>





<div><br></div><div>    (address >= alienAddress</div>    and: [alienAddress + alienPage dataSize >= address]) ifTrue:<div>        [alienPage unsignedByteAt: address - alienAddress + 1 put: 0.<br></div><div>    ...</div><div><br></div><div><div>The newest version I found on squeak source was Alien-Core-nice.104 and the test is the same.</div><div></div></div><div><br></div><div>I changed >= to > here and the problem went away for me:</div><br>    (address >= alienAddress<br>     and: [alienAddress + alienPage dataSize > address]) ifTrue: <div><br></div><div>Is my reading of this correct?</div><div><br></div><div>Since we are here, why do #initializeX64 and #initializeX64Win64 end their methods with sending #primThunkEntryAddress and doing nothing with the returned result? Is there a side-effect going on here?  It looks to me like a possible copy and paste error.</div><div><br></div><div>Regards,</div><div>-- Bob</div></div></div>