[Vm-dev] Integer overflow with BitBlt rule 20 and depth 32
eliot.miranda at gmail.com
Mon Oct 26 20:27:47 UTC 2009
On Mon, Oct 26, 2009 at 1:04 PM, Juan Vuletich <juan at jvuletich.org> wrote:
> Hi Eliot,
> Eliot Miranda wrote:
>> Hi Juan,
>> On Mon, Oct 26, 2009 at 11:07 AM, Juan Vuletich <juan at jvuletich.org<mailto:
>> juan at jvuletich.org>> wrote:
>> Eliot Miranda wrote:
>> On Mon, Oct 26, 2009 at 6:01 AM, Juan Vuletich
>> <juan at jvuletich.org <mailto:juan at jvuletich.org>
>> <mailto:juan at jvuletich.org <mailto:juan at jvuletich.org>>> wrote:
>> Hi Folks,
>> I've just opened http://bugs.squeak.org/view.php?id=7407 ,
>> with a
>> description of the problem, several tests (based on Henrik's
>> scripts) and the fix I propose.
>> David T. Lewis wrote:
>> On Sat, Oct 24, 2009 at 10:40:17AM -0300, Juan
>> Vuletich wrote:
>> What worries me a bit is the other changes
>> I needed
>> to do
>> to be able to run the Smalltalk BitBlt simulation
>> and to
>> do the translation. These are:
>> BitBltSimulator >> #oopForPointer: "May be harmless"
>> CArrayAccessor >> #long32At: "Why is this
>> CArrayAccessor >> #long32At:put: "Why is this
>> I am just guessing here, but I think that BitBltSimulator
>> expects to
>> be used with an interpreter simulator, so perhaps if you
>> initialize it
>> with a simulator there will be no need to add these
>> sim := BitBltSimulator new setInterpreter:
>> InterpreterSimulator new
>> Given that BitBltSimulation calls #isIntegerObject: it
>> looks like
>> the ivar interpreterProxy should hold an InterpreterProxy
>> (as it
>> already does) and not an InterpreterSimulator. I did not add my
>> patch to make simulation work to Mantis, as I'm not sure
>> about them.
>> When simulating the interpreterProxy inst var should hold the
>> InterpreterSimulator, not the proxy.
>> Maybe it should be an InterpreterSimulator when simulating the
>> whole interpreter. When calling #copyBitsSimulated, it is set to
>> an InterpreterProxy in #copyBitsFrom: .
>> Anyway, I'm asking for help on making #copyBitsSimulated work
>> again, like it should do when called from BitBltTest. If nobody
>> can help with that, I guess I'll open a Mantis issue for this
>> problem, in the hope that some day it gets fixed.
>> Well with my current VM I see no problems; all 10 tests are green. What
>> is the bug that you see? How can I reproduce it?
> Thank you for caring about this issue!
> I apologize for not being clear. Check #testAlphaCompositingSimulated and
> #testAlphaCompositing2Simulated. Both do nothing if BitBltSimulation is not
> there. If you load VMMaker, both tests give errors. The VM in use should be
> irrelevant, this is pure Smalltalk.
I understand that. I have an image containing BitBltSimulation and 5
different VMs :) I'm developing Cog, a faster Squeak VM. In my image with
BitBltSimulation present all 10 BitBltTest tests pass. But I have done some
work on the simulator.
I am asking you to help me reproduce the bug and then I can export the fixes
from my VM to fix VMMaker. What version of VMMaker are you using?
> It is a very bad idea to have a test do nothing under default conditions!
> (i.e. no special packages such as VMMaker loaded) That's why I moved both to
> a new class, that should be part of VMMaker, and removed that silly check
> for BitBltSimulation. This is included in the stuff I attached to
> http://bugs.squeak.org/view.php?id=7407 .
> Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev