[Vm-dev] [OpenSmalltalk/opensmalltalk-vm] Armv8 crash in MVC (Issue #617)

[Nicolas Cellier]

fastPathBottomToTop does not do much... It just reverse the line order.
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f5f0e7d98effd7217dded6ed9397b2cac1f787ad/platforms/Cross/plugins/BitBltPlugin/BitBltGeneric.c#L517

I foresee two cases where it could fail:
- the fast operation by itself has a BUG (whatether BottomToTop or not)
- some integer operations are carried on a larger integer type, transforming negative pitch into a large positive int

The later is possible because `srcPitch` and `dstPitch` are declared usqInt in `operation_t`
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f5f0e7d98effd7217dded6ed9397b2cac1f787ad/platforms/Cross/plugins/BitBltPlugin/BitBltDispatch.h#L98

`usqInt` is 64bits on ARM64, so far so good, unfortunately those variables are copied to 32 bits local temps in 
https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/f5f0e7d98effd7217dded6ed9397b2cac1f787ad/platforms/Cross/plugins/BitBltPlugin/BitBltInternal.h#L137

I think that it is the mistake, because pointer arithmetic in 64 bits will be performed with 64 bits size_t, and the uint32_t will just move the pointer a large amount forward (2^32-pitch) instead of backward (-pitch).

So I think that declaring the local `srcPitch` and `dstPitch` as `usqInt` instead of `uint32_t` might fix the bug.

I have no ARM64 at hand to play with, so up to you to verify the hypothesis.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/617#issuecomment-1063371033
You are receiving this because you commented.

Message ID: <OpenSmalltalk/opensmalltalk-vm/issues/617/1063371033 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20220309/6552c5f9/attachment.html>