Smalltalk › Squeak › Squeak VM

Possible bug in FFICallbackThunk class>>#freeBlockInExecutablePage:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Bob Westergaard

Possible bug in FFICallbackThunk class>>#freeBlockInExecutablePage:

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?

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.

Regards,

-- Bob

Nicolas Cellier

Re: Possible bug in FFICallbackThunk class>>#freeBlockInExecutablePage:

Le mer. 8 juil. 2020 à 21:13, Bob Westergaard <[hidden email]> 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