[Vm-dev] About Cog on linux

[Igor Stasenko]

On 10 February 2011 19:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Thu, Feb 10, 2011 at 9:55 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>> On 10 February 2011 18:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> > Hi Igor,
>> >
>> > On Thu, Feb 10, 2011 at 1:03 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>> >>
>> >> On 9 February 2011 20:04, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >> >
>> >> >
>> >> > That's essentially what I see but the variability isn't between cmake and configure but between different runs of configure.  For example, you'll see that I released 2259 (SimpleStackBasedCogit) and 2361 (StackToRegisterMappingCogit) at the weekend.  That's because 2360 which had -O2 for gcc3x-cointerp.c crashed on startup on my test case (Squeak4.2-10856-beta.image) in one of the early performs as classes are sent startUp: on startup.  So I lowered optimization, checked-in 2361, built, checked it didn't crash and released.  However, now I try and rebuild exactly the same sources but using -O2 for gcc3x-cointerp.c I can't get it to crash.  This is exactly analogous to a few weeks back when I was convinced that the optimization level of the heartbeat caused it to crash if at -O2.  When Andreas asked me to reproduce on the internal Teleplace build I couldn't get it to repeat.  So something is very odd indeed, sensitive perhaps to the timestamp in the executable or some such.  However, now at least I know what I'm looking for and the next tie I build somethign that crashes on the test case I will attempt to debug.
>> >> >
>> >> >
>> >>
>> >> I tried today with debug info enabled (all source files are compiled with:
>> >>
>> >> compilerFlags
>> >>
>> >>        ^ '-g3 -O1 -msse2 -D_GNU_SOURCE -DDEBUG -DITIMER_HEARTBEAT=1
>> >>        -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=1'
>> >>
>> >> )
>> >>
>> >
>> > please change that to include -save-temps.  We can then see what the generated assembly and object files are and that will really help analyse.  Also, can you somehow freeze this source so that we can repeat the compilation exactly?  i.e. avoid generating a different version.c with a different date in it.  We must try and repeat the compilation exactly with no temporal or path-derived artifacts.
>> >
>> >\
>>
>> ok i made such config:
>>
>> ....results/Cog -version
>> 3.9-7 #1 <HERE IS SUPPOSED TO BE THE DATE> <HERE IS SUPPOSED TO BE gcc VERSION>
>> Croquet Closure Stack VM [StackInterpreter
>> VMMaker-oscog-IgorStasenko.Stasenko.49]
>> <FAKE FROZEN VERSION FOR DEBUGGING PURPOSES>
>> plugin path: /home/sig/vmbuild/build/results/ [default:
>> /home/sig/vmbuild/build/results/]
>>
>>
>> it also produces a lot of .i and .s files around build dir..
>
> Right.  That's what -save-temps does.  And that's useful data, especially in seeing what code gcc produces for different -O levels.
>
>>
>> You can try building it by loading CMakeVMMaker-IgorStasenko.27
>> package and doing:
>>
>> FixedVerSIDebugUnixConfig generateWithSources
>>
>> or tell me what to do next :)
>
> You need to try and produce one build that crashes and one build that doesn't (based e.g. on -O level).  When you have that compare the two up to the point of failure.

i can do that , but on two different architectures.
On linux it crashing , no matter what i do (as you can see even stack
based are crashing).

>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>

-- 
Best regards,
Igor Stasenko AKA sig.