[Vm-dev] Another JIT + GCC issue?

[Nicolas Cellier]

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.

Nicolas

>>>
>>>
>>> So, for the time till the cause of it can be found i will change the
>>> configuration to build windows Cog VMs gcc3x-cointerp.c with -O1 flag.
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.