[Vm-dev] BitBltSimulation buffer overrun

Fabio Niephaus lists at fniephaus.com
Wed Sep 25 08:12:29 UTC 2019


Hi Florin,

Thanks for your interest! Yes, we are still developing GraalSqueak in a
private repository at the moment, but we are currently working towards open
sourcing it for the MPLR paper presentation [1] mid October.

Best,
Fabio

[1]
https://conf.researchr.org/details/mplr-2019/mplr-2019-papers/2/GraalSqueak-Toward-a-Smalltalk-based-Tooling-Platform-for-Polyglot-Programming

On Wed, Sep 25, 2019 at 5:34 AM Florin Mateoc <florin.mateoc at gmail.com>
wrote:

>
> Hi Fabio,
>
> The only GraalSqueak repository I could find (which is also the one
> mentioned in the papers) is at https://github.com/hpi-swa/graalsqueak,
> but it has not been touched in the last two years.
> Is there a different public repository or are you only working on it in
> private?
>
> Thank you,
> Florin
>
> On Mon, Sep 16, 2019 at 11:38 AM Fabio Niephaus <lists at fniephaus.com>
> wrote:
>
>>
>>
>>
>> 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/20190925/26888f84/attachment.html>


More information about the Vm-dev mailing list