[Vm-dev] About Cog on linux

[Eliot Miranda]

On Wed, Feb 9, 2011 at 10:48 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> 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?


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.





> 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 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110209/f6a4e2f3/attachment-0001.htm