About Cog on linux

It is really weird..
i using same sources for everything, except in one case i use
usual build steps, as in HowToBuild file,

while in another i using cmake configs.

So, the difference is in compiler flags etc.. but not in sources..
and as result, the one built using 'standard' steps runs well,
while built by cmake configs dies after few bytecodes interpreted:

 ./Cog ../generator.image

Segmentation fault



Smalltalk stack dump:
0xbfd61804 I [] in Debugger class>openContext:label:contents:
2005660708: a(n) Debugger class
0xbfd61830 I [] in StandardToolSet class>debugContext:label:contents:
2004064772: a(n) StandardToolSet class
0xbfd6185c I [] in ToolSet class>debugContext:label:contents:
2004049368: a(n) ToolSet class
0xbfd61888 I [] in MethodContext>cannotReturn: 2032713528: a(n) MethodContext
0xbfd618ac I [] in MessageNotUnderstood>message: 2032713492: a(n)
MessageNotUnderstood
0xbfd618dc I [] in UndefinedObject(Object)>doesNotUnderstand:
2003124228: a(n) UndefinedObject
0xbfd61904 I [] in UndefinedObject(Object)>mustBeBooleanIn:
2003124228: a(n) UndefinedObject
0xbfd61928 I UndefinedObject(Object)>mustBeBoolean 2003124228: a(n)
UndefinedObject
0xbfd61954 I [] in SmalltalkImage>snapshot:andQuit:embedded:
2005393456: a(n) SmalltalkImage
2032108624 s SmalltalkImage>snapshot:andQuit:
2032108320 s SmalltalkImage>saveImageInFileNamed:
2032108228 s SmalltalkImage>saveAs:
2016984776 s UndefinedObject>?
2016978028 s Compiler>evaluate:in:to:notifying:ifFail:logged:
2016977456 s Compiler class>evaluate:for:notifying:logged:
2016977364 s Compiler class>evaluate:for:logged:
2016977236 s Compiler class>evaluate:logged:
2016977144 s [] in RWBinaryOrTextStream(PositionableStream)>fileInAnnouncing:
2016977052 s BlockClosure>on:do:


as you can see it even don't leaves the #snapshot:andQuit:embedded:

Eliot, has you seen such before?

Any ideas?

I am really don't like having VM which stability depends on some
little flag(s).. and i guess you too.

--
Best regards,
Igor Stasenko AKA sig.

On 9 February 2011 20:04, Eliot Miranda <[hidden email]> 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'

)

sig@sig-VirtualBox:~/vmbuild/build$ ./results/Cog  ./generator.image
ioFindExternalFunctionIn(display_X11, 0x676918):
 ./results/Cog: undefined symbol: display_X11
ioFindExternalFunctionIn(sound_OSS, 0x676918):
 ./results/Cog: undefined symbol: sound_OSS
ioFindExternalFunctionIn(sound_MacOSX, 0x676918):
 ./results/Cog: undefined symbol: sound_MacOSX
ioFindExternalFunctionIn(sound_Sun, 0x676918):
 ./results/Cog: undefined symbol: sound_Sun
ioFindExternalFunctionIn(sound_pulse, 0x676918):
 ./results/Cog: undefined symbol: sound_pulse
ioFindExternalFunctionIn(sound_ALSA, 0x676918):
 ./results/Cog: undefined symbol: sound_ALSA
ioLoadModule(/home/sig/vmbuild/build/results/vm-sound-ALSA):
 /home/sig/vmbuild/build/results/vm-sound-ALSA: undefined symbol:
snd_mixer_selem_has_playback_volume
ioFindExternalFunctionIn(sound_null, 0x676918):
 ./results/Cog: undefined symbol: sound_null
uxAllocateMemory: pageSize 0x1000 (4096), mask 0xfffff000
uxAllocateMemory: /dev/zero descriptor -1
uxAllocateMemory: min heap 39664660, desired 58539092
uxAllocateMemory: mapping 0x40000000 bytes (1024 Mbytes)

(frameNumArgs((page->baseFP))) == numArgs 19611

((((aPage->baseFP)) + (frameStackedReceiverOffset((aPage->baseFP)))) +
(2 * BytesPerWord)) == ((aPage->baseAddress)) 43641

validStackPageBaseFrames() 19637

(frameNumArgs(localFP)) == GIV(argumentCount) 4985

!(frameIsBlockActivation(localFP)) 4986

(frameNumArgs(localFP)) == GIV(argumentCount) 4985

!(frameIsBlockActivation(localFP)) 4986

(frameNumArgs(localFP)) == GIV(argumentCount) 4985

!(frameIsBlockActivation(localFP)) 4986

Segmentation fault



Smalltalk stack dump:

0xbfeb4f6c I [] in MessageNotUnderstood>message: 2032401548: a(n)
MessageNotUnderstood
0xbfeb4f9c I [] in UndefinedObject(Object)>doesNotUnderstand:
2004271108: a(n) UndefinedObject
0xbfeb4fc4 I [] in UndefinedObject(Object)>mustBeBooleanIn:
2004271108: a(n) UndefinedObject
0xbfeb4fe8 I UndefinedObject(Object)>mustBeBoolean 2004271108: a(n)
UndefinedObject
0xbfeb5014 I [] in SmalltalkImage>snapshot:andQuit:embedded:
2006539444: a(n) SmalltalkImage
2032008288 s SmalltalkImage>snapshot:andQuit:
2032008176 s WorldState class>saveAndQuit
2032008064 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
2032007972 s BlockClosure>ensure:
2032007880 s CursorWithMask(Cursor)>showWhile:
2032007676 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
2032007584 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp:
2032007492 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp:
2032007356 s MouseButtonEvent>sentTo:
2032007264 s ToggleMenuItemMorph(Morph)>handleEvent:
2032007172 s MorphicEventDispatcher>dispatchDefault:with:
2032007080 s MorphicEventDispatcher>dispatchEvent:with:
2032006988 s ToggleMenuItemMorph(Morph)>processEvent:using:
2032006896 s MorphicEventDispatcher>dispatchDefault:with:
2032006788 s MorphicEventDispatcher>dispatchEvent:with:
2032006652 s MenuMorph(Morph)>processEvent:using:
2032006560 s MenuMorph(Morph)>processEvent:
2032006468 s MenuMorph>handleFocusEvent:
2032006376 s [] in HandMorph>sendFocusEvent:to:clear:
2032006284 s [] in PasteUpMorph>becomeActiveDuring:
2032006116 s BlockClosure>on:do:
2032005932 s PasteUpMorph>becomeActiveDuring:
2032005840 s HandMorph>sendFocusEvent:to:clear:
2032005748 s HandMorph>sendEvent:focus:clear:
2032005656 s HandMorph>sendMouseEvent:
2032005564 s HandMorph>handleEvent:
2032005288 s HandMorph>processEvents
2032005196 s [] in WorldState>doOneCycleNowFor:
2032005104 s Array(SequenceableCollection)>do:
2032005012 s WorldState>handsDo:
2032004920 s WorldState>doOneCycleNowFor:
2032004792 s WorldState>doOneCycleFor:
2032004700 s PasteUpMorph>doOneCycle
2006915672 s [] in Project class>?
2006915544 s [] in BlockClosure>?

Most recent primitives
basicNew
Aborted


So, it looks like something are not initialized correctly..

>
>>
>> Any ideas?
>
> If you can get cmake to run with the same flags as configure (!making sure to use -save-temps so we can look at generated assembler and object files!) and you can get one or other to crash on start-up then one can compare the two and hopefully find the elusive bug.
>

I just uploaded a fix for config which can build Cog VM:

CMakeVMMaker-IgorStasenko.24

load it into your image and issue

CogUnixConfig generate

or

CogDebugUnixConfig generate



it will generate cmake files in ../build directory (relative to
image's current dir).
(also you can use  #generateWithSources to generate VMMaker sources
along with build config)


cd to it, and do
cmake . && make

in results subdir you will find the built artifacts.

>>
>> I am really don't like having VM which stability depends on some
>> little flag(s).. and i guess you too.
>
> Damn right!!  Except it /doesn't/ depend on the optimization.  It is more subtle than that.  For example there was one build which Martin Kobetic found would crash on startup if the image path was something like /st/squeak/cog/myimage.image but not if it was /some/network/drive/and/hence/much/longer/myimage.image.
>
> confused, bewildered and disquieted,
> Eliot
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>

--

Best regards,
Igor Stasenko AKA sig.

On 10 February 2011 18:34, Eliot Miranda <[hidden email]> wrote:
>
> Hi Igor,
>
> On Thu, Feb 10, 2011 at 1:03 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 9 February 2011 20:04, Eliot Miranda <[hidden email]> 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..

You can try building it by loading CMakeVMMaker-IgorStasenko.27
package and doing:

FixedVerSIDebugUnixConfig generateWithSources

or tell me what to do next :)

--

Best regards,
Igor Stasenko AKA sig.

On 10 February 2011 19:38, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Thu, Feb 10, 2011 at 9:55 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 10 February 2011 18:34, Eliot Miranda <[hidden email]> wrote:
>> >
>> > Hi Igor,
>> >
>> > On Thu, Feb 10, 2011 at 1:03 AM, Igor Stasenko <[hidden email]> wrote:
>> >>
>> >> On 9 February 2011 20:04, Eliot Miranda <[hidden email]> 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.