[Vm-dev] Possible bug in FFICallbackThunk class>>#freeBlockInExecutablePage:

Bob Westergaard bwestergaard at gmail.com
Wed Jul 8 19:12:53 UTC 2020


I believe there is a bug in FFICallbackThunk
class>>#freeBlockInExecutablePage: (in Alien-Core).
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.

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).

    (address >= alienAddress
    and: [alienAddress + alienPage dataSize >= address]) ifTrue:
        [alienPage unsignedByteAt: address - alienAddress + 1 put: 0.

The newest version I found on squeak source was Alien-Core-nice.104 and the
test is the same.

I changed >= to > here and the problem went away for me:

    (address >= alienAddress
     and: [alienAddress + alienPage dataSize > address]) ifTrue:

Is my reading of this correct?

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.

-- Bob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200708/0fde809c/attachment.html>

More information about the Vm-dev mailing list