[Vm-dev] Another JIT + GCC issue?

[Nicolas Cellier]

In my experience, installing MinGW is easy and you can install two
versions without side effects.
But then you'll have to play with the windows PATH variable...

Nicolas

Le 6 avril 2012 15:17, Igor Stasenko <siguctua at gmail.com> a écrit :
>
> 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.