[Vm-dev] BitBltSimulation buffer overrun
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
> 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.
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
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...
More information about the Vm-dev