[Vm-dev] Another JIT + GCC issue?

[Igor Stasenko]

On 6 April 2012 09:50, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
>
> Le 6 avril 2012 09:02, Igor Stasenko <siguctua at gmail.com> a écrit :
>>
>> On 5 April 2012 20:04, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>
>>> Hi Igor,
>>>
>>> On Thu, Apr 5, 2012 at 9:14 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>>>
>>>>
>>>> Hi Eliot & all,
>>>>
>>>> i & Esteban were investigating what is wrong with crash on windoze
>>>> (see http://code.google.com/p/pharo/issues/detail?id=5568)
>>>>
>>>> what we found:
>>>>
>>>> - a stack vm runs given snippet well.
>>>> - a cog vm crashing horribly or throws an exception  (see below)
>>>>
>>>> - if i set -O1 optimization for gcc3x-cointerp.c then everything is _FINE_
>>>> but if you build with -O2, there is interesting issue with this.
>>>>
>>>> If you start a fresh 1.4 image and run a following snippet in workspace:
>>>>
>>>> | oldm window aForm startPoint endPoint |
>>>> oldm := DisplayObject>>#slideFrom:to:nSteps:delay: .
>>>> "self assert: (DisplayObject>>#slideFrom:to:nSteps:delay:  ~~oldm)."
>>>> window := SystemWindow allInstances first.
>>>> aForm := window imageForm offset: 0 at 0.
>>>> startPoint := (-194 at 61).
>>>> endPoint := (276.0 at 134.0).
>>>> aForm
>>>>        slideFrom: startPoint
>>>>        to: endPoint
>>>>        nSteps: 12
>>>>        delay: 15.
>>>>
>>>> At first run it shows a DNU: Smallinteger>>DNU #extent: (or just crashes).
>>>>
>>>> It looks like something happens with stack, since receiver should be a Point,
>>>> and if you open the debugger and evaluate the corresponding line:
>>>> newLoc := locationBlock value
>>>> it will print
>>>> (-76 at 79)
>>>> as expected
>>>>
>>>> next, if you close the debugger and run the very same doit again, bug
>>>> disappears and no longer reproducible, and everything works as it
>>>> should be.
>>>> So, i presume it is related to place where a compiled method is jit-ed
>>>> for a first time, and invoked .. but if it is already jited ,
>>>> everything runs smoothly.
>>>>
>>>> The compiler version i using on my machine: gcc.exe (GCC) 4.6.1
>>>> The compiler used on jenkins slave machine: GCC 4.5.2
>>>>
>>>> And, of course, concerning why this doesn't crashing on Eliot's VMs :
>>>> well, since it is related to compiler optimization(s),
>>>> and VM code is a lil-bit different in a branch we using on Jenkins, it
>>>> could happen that this is not an issue in one case, while causing
>>>> problems in another one.
>>>> Another option (not necessary impossible), that we missed some
>>>> critical fix when merging code from Eliot's branch :)
>>>
>>>
>>> One thing to do would be to compile my source tree with your compiler.  I compile my windows VM using gcc 3.4.x, so that mine doesn't crash could be to do with that.  My source tree is http://www.squeakvm.org/svn/squeak/branches/Cog.
>>>
>>
>> any idea how to install this version of gcc in mingw?
>>
>
> It's more simple to install an older version of mingw with this compiler.
>
well, but i don't like to break existing installation.
because installing this stuff is pain.

oh.. wait .. i can actually copy the virtualbox image mess with it and
then throw it awaay.

> Nicolas


-- 
Best regards,
Igor Stasenko.