[Vm-dev] BitBltSimulation buffer overrun

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Sep 4 18:00:01 UTC 2019


Le mer. 4 sept. 2019 à 18:57, tim Rowledge <tim at rowledge.org> a écrit :

>
>
>
> > On 2019-09-04, at 12:48 AM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
> >
> >
> > It seems to me that it's got something to do with 64bits shifter...
> > No time to simulate the VM now, if someone want to take it, it's a good
> exercize...
> >
>
> It's highly likely to be a side-effect of the prefetch stuff; we've had
> 'fun' with this for decades. IIRC there was some real fun on Mac OS years
> ago if the bitmap memory happened to end just on a page boundary  - or
> something of that sort.
>
> yes, that happens very rarely, but that might happen and SEGV

Basically if the mode involves reading the destination bitmap then we end
> up with the last pixel trying to read a word *after* the end of the bitmap.
> Obviously the clipping etc values are supposed to result in those bits
> (generally a header for the next object in memory of course) getting
> ignored. It can be amusing if the code is subtly wrong and dodgy bits get
> into your Forms.
>
> 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).

I think that Eliot spent some time to debug and eliminate most overrun
cases in 2018 (every BitBltSimulation is stamped eem 2018).
But it's a hell of a low level code mixing a bunch of states with a bunch
of branches with a very imperative programming style...
I don't know if the code is provable by a machine, but for a human brain,
it's far more above the average capabilities ;)
Maybe it's write only kind, even for Dan himself!


--
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> Computer possessed? Try DEVICE=C:\EXOR.SYS
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20190904/5a5bcd83/attachment.html>


More information about the Vm-dev mailing list