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

[Nicolas Cellier]

Le mer. 8 juil. 2020 à 21:13, Bob Westergaard <bwestergaard at gmail.com> a
écrit :

>
> Hi,
>
> 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?
>
> yes, if dataSize were 1, then we would have a single valid address in the
page, alienAddress <= address < alienAdress + 1
so I think that you are right.

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.
>
> I don't see any side effect here, you can safely remove.
For initializeX64Win64 I just did mimic the existing initializeX64
(Alien-nice.36) without questioning further...

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