[Vm-dev] BitBltSimulation buffer overrun

[Nicolas Cellier]

The sole problem is whether a single chalk mark will cover all the possible
cases of failures...
Let's cross fingers.

Le lun. 16 sept. 2019 à 18:38, Fabio Niephaus <lists at fniephaus.com> a
écrit :

>
>
>
> On Fri, Sep 13, 2019 at 9:03 PM Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
>>
>> Hehe, I think I fixed it in VMMaker.oscog-nice.2563
>> The ultimate tool for understanding and debugging this was pen and paper!
>> I don't know how young techies will do ;)
>>
>
> Great, I ported your fixes to GraalSqueak which contains a Java version of
> BitBlt. Glad that I could remove a few workarounds to avoid some
> IndexOutOfBounds errors, but even better that those segfaults are gone.
>
> Well done!
>
> Fabio
>
>
>>
>>
>>
>> Le mer. 4 sept. 2019 à 21:24, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> a écrit :
>>
>>>
>>>
>>>
>>> Le mer. 4 sept. 2019 à 20:16, tim Rowledge <tim at rowledge.org> a écrit :
>>>
>>>>
>>>>
>>>>
>>>> > On 2019-09-04, at 11:00 AM, Nicolas Cellier <
>>>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>>> >
>>>> > tim
>>>> > Do we ever use the extra word that we read? I don't think so, we
>>>> don't generate funny artefacts.
>>>> > But we could try and test that now that we know how to trigger it
>>>> (statistically).
>>>>
>>>> We certainly shouldn't use that extra word.
>>>>
>>>> Unless something has gone horribly wrong, the only time this is an
>>>> issue is on the last fetch of the last row of a BLT. So we *could* consider
>>>> splitting out the last row and only for that last row include a check for
>>>> the last word, and only for that word include a 'stick 0 in'.
>>>>
>>>> Yes, possibly, but then one also has to check the first row whenever
>>> vDir = -1 (checkSourceOverlap).
>>> I said a hell of a stateful branchful code, but you know it even better
>>> than I ;)
>>>
>>> Since this is an assert for the debug, perhaps the smart thing to do is
>>>> make the assert test more thoughtful in some manner. The typical case
>>>> simply doesn't matter, since all we do is load a wasted word. Where things
>>>> do need some care is at the end of object memory and page boundaries etc.
>>>>
>>>> tim
>>>> --
>>>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>>>> No single raindrop believes it is to blame for the flood
>>>>
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190916/a746aa52/attachment.html>