new Cog VMs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Philippe Marschall-2-3
On 02.01.2011 16:50, Eliot Miranda wrote:
> Hi Philippe,
>
>     what image, what OS and what directories are the vm and image
> installed in (yes it can make a difference).

- Pharo 1.1.1
- $uname -a
Linux 2.6.36-gentoo-r4 #1 SMP PREEMPT Sun Dec 12 19:02:46 CET 2010
x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
- image lies in some subdirectory of the user home, Cog is extracted in
the same folder, so it's under coglinux/

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Eliot Miranda-2
Hi All,

    looks like there are issues running Cog on 64-bit linux.  I only have a 32-bit one to hand so it'll be a while before I can look at this.

BTW, it would really help if when people post bugs they give
- a URL to the image and changes, not just a name like Pharo 1.1.1.  A pointer to the exact bits eliminates any possibility that I will fetch the wrong image and not be able to reproduce
- the exact directory something is installed in, not just the name but the full path, and whether it is remote ounted or not.  I just fixed a crash on windows for Torsten that didn't show on a remote-mounted drive but caused a hard crash if installed as c:\pharo.  So saying "its in coglinux/" isn;t being precise enough.

TIA


best
Eliot

On Sun, Jan 2, 2011 at 11:01 AM, Philippe Marschall <[hidden email]> wrote:
On 02.01.2011 16:50, Eliot Miranda wrote:
> Hi Philippe,
>
>     what image, what OS and what directories are the vm and image
> installed in (yes it can make a difference).

- Pharo 1.1.1
- $uname -a
Linux 2.6.36-gentoo-r4 #1 SMP PREEMPT Sun Dec 12 19:02:46 CET 2010
x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
- image lies in some subdirectory of the user home, Cog is extracted in
the same folder, so it's under coglinux/

Cheers
Philippe



Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Eliot Miranda-2
In reply to this post by mkobetic
Hi Martin, Hi All,

    so find new VMs in VM.r2341/.  The linux crashes (certainly the one you suffered from Martin) seem to be caused by an optimization bug (but they could be caused by bad code generation, creating something that assumes ordering constraints which C doesn't guarantee).  I suspect the former because I don't see the crash when running exactly the same VM and image from a different directory; provoking the crash requires a particular path (go figure; I haven't pinned this down yet).

So my "fix" is preventing a complex function being inlined into the main interpreter loop, removing the sources of some warnings, and lowering the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of this "fix".  I've violated the Deutsch criterion by not diagnosing the cause of the bug so I can't stand behind this fix; it's a hack that appears to work and may have merely pushed the real bug further underground.  Alas I don't have time to do a better job. Hopefully it'll get those of you on linux going again.

best
Eliot

On Sat, Jan 1, 2011 at 11:16 PM, <[hidden email]> wrote:
I'm probably doing something obviously wrong, but I have no luck with the Cog VM. It crashes immediately on startup even with the stock OneClick image. I downloaded the Pharo-1.1.1 OneClick images. Fetched the latest coglinux.tgz (r2340), untarred it into the pharo directory and just trying to run it from the top-level pharo directory as:

       coglinux/squeak Contents/Resources/pharo.image

crashes immediately (with or without the -vm-display-X11 option). This is on latest Fedora 14. The old VM seems to have no problem when I try to run it the same way:

       Contents/Linux/squeakvm Contents/Resources/pharo.image

seems to start just fine. I can copy the stack dump from the crash, but since most seem to be running fine, I suspect I'm just not doing it right. What am I missing ?

Thanks,

Martin

"Eliot Miranda"<[hidden email]> wrote:
>    there are new versions of both the SimpleStackBasedCogit and the
> StackToRegisterMappingCogit Cog VMs in
> VM.r2339/<http://www.mirandabanda.org/files/Cog/VM/VM.r2339/>
>  & VM.r2340/ <http://www.mirandabanda.org/files/Cog/VM/VM.r2340/> respectively.
>  These contain fixes for rounding bug causing underestimate of openPICSize
> and resultant hard crashes, seen e.g. by trying to recover lost changes in a
> Pharo 1.2 image installed on c:\pharo.  If you're trying to reproduce Cog
> crashes please upgrade to one of tthese two VMs.


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: new Cog VMs

Igor Stasenko
On 3 January 2011 00:15, Eliot Miranda <[hidden email]> wrote:

> Hi Martin, Hi All,
>     so find new VMs in VM.r2341/.  The linux crashes (certainly the one you
> suffered from Martin) seem to be caused by an optimization bug (but they
> could be caused by bad code generation, creating something that assumes
> ordering constraints which C doesn't guarantee).  I suspect the former
> because I don't see the crash when running exactly the same VM and image
> from a different directory; provoking the crash requires a particular path
> (go figure; I haven't pinned this down yet).
> So my "fix" is preventing a complex function being inlined into the main
> interpreter loop, removing the sources of some warnings, and lowering the
> optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build
> environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of this
> "fix".  I've violated the Deutsch criterion by not diagnosing the cause of
> the bug so I can't stand behind this fix; it's a hack that appears to work
> and may have merely pushed the real bug further underground.  Alas I don't
> have time to do a better job. Hopefully it'll get those of you on linux
> going again.

Eliot, if you remember, i also had crash issues on linux, and pinned down it to
removing optimization from <something>heartbeat.c while keeping
gcc3x-cointerp.c to use
 same optimization flags as for rest of files.

I will start coding cmake config for Cog during next week and will be
able to check my previous
observations again.

> best
> Eliot
> On Sat, Jan 1, 2011 at 11:16 PM, <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

mkobetic
In reply to this post by Eliot Miranda-2
"Eliot Miranda"<[hidden email]> wrote:
>     so find new VMs in
> VM.r2341/<http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>.

Yup, much better on my end. Thanks!

Martin

Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Andres Valloud-4
In reply to this post by Eliot Miranda-2
That sounds familiar... are there bitfields next to a memory allocation
zone boundary?  GCC will issue read instructions that read off the
bitfield (documented in the manual --- can't really complain), so you
can get a segfault reading a bitfield if GCC emits instructions at
compile time that read off the allocation edge at run time...

On 1/2/11 10:09 , Eliot Miranda wrote:

> Hi All,
>
>      looks like there are issues running Cog on 64-bit linux.  I only
> have a 32-bit one to hand so it'll be a while before I can look at this.
>
> BTW, it would really help if when people post bugs they give
> - a URL to the image and changes, not just a name like Pharo 1.1.1.  A
> pointer to the exact bits eliminates any possibility that I will fetch
> the wrong image and not be able to reproduce
> - the exact directory something is installed in, not just the name but
> the full path, and whether it is remote ounted or not.  I just fixed a
> crash on windows for Torsten that didn't show on a remote-mounted drive
> but caused a hard crash if installed as c:\pharo.  So saying "its in
> coglinux/" isn;t being precise enough.
>
> TIA
>
>
> best
> Eliot
>
> On Sun, Jan 2, 2011 at 11:01 AM, Philippe Marschall <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 02.01.2011 16:50, Eliot Miranda wrote:
>      > Hi Philippe,
>      >
>      >     what image, what OS and what directories are the vm and image
>      > installed in (yes it can make a difference).
>
>     - Pharo 1.1.1
>     - $uname -a
>     Linux 2.6.36-gentoo-r4 #1 SMP PREEMPT Sun Dec 12 19:02:46 CET 2010
>     x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux
>     - image lies in some subdirectory of the user home, Cog is extracted in
>     the same folder, so it's under coglinux/
>
>     Cheers
>     Philippe
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Eliot Miranda-2
In reply to this post by Mariano Martinez Peck
The MethodContext>>numArgs is I guess to be expected because there's no implementation so far.  Find attached.

'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 2 January 2011 at 2:23:32 pm'!

!MethodContext methodsFor: 'accessing' stamp: 'eem 1/2/2011 14:23'!
numArgs 
"Answer the number of arguments required to evaluate this method or block."

^closureOrNil ifNil: [method numArgs] ifNotNil: [closureOrNil numArgs]! !


On Sun, Jan 2, 2011 at 2:49 AM, Mariano Martinez Peck <[hidden email]> wrote:
Hi Eliot. Running:

- Mac OS
- VM r2340
- PharoCore 1.2  12288 

Running all tests I got this DNU.
It is reproducable running the test  testClosureRestart  which seems to pass well in previous VMs.

Cheers

Mariano

THERE_BE_DRAGONS_HERE
MessageNotUnderstood: MethodContext>>numArgs
2 January 2011 11:38:31 am

VM: Mac OS - intel - 1065 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.41] Croquet Cog 3.0.0
Image: Pharo1.2beta [Latest update: #12288]

SecurityManager state:
Restricted: false
FileAccess: true
SocketAccess: true
Working Dir /Users/mariano/Pharo/imagenes/PharoCore-1.2beta-12283
Trusted Dir /foobar/tooBar/forSqueak/bogus/
Untrusted Dir /Users/mariano/Library/Preferences/Croquet/Internet/Untrusted

MethodContext(Object)>>doesNotUnderstand: #numArgs
    Receiver: [| b |
self assert: 10 == a.
    self assert: nil == b.
    b := a + 20.
    firstTimeThrough
        ifT...etc...
    Arguments and temporary variables:
        t1:     numArgs
        t2:     nil
        t3:     nil
    Receiver's instance variables:
        sender:     nil
        pc:     nil
        stackp:     3
        method:     (MethodContextTest>>#privRestartBlockTest "a CompiledMethod(700186624)"...etc...
        closureOrNil:     [| b |
self assert: 10 == a.
    self assert: nil == b.
    b := a + 20...etc...
        receiver:     MethodContextTest>>#testClosureRestart



--- The full stack ---
MethodContext(Object)>>doesNotUnderstand: #numArgs
------------------------------------------------------------




On Sun, Jan 2, 2011 at 8:52 AM, Philippe Marschall <[hidden email]> wrote:
On 01.01.2011 21:38, Eliot Miranda wrote:
> Hi All,
>
>    there are new versions of both the SimpleStackBasedCogit and the
> StackToRegisterMappingCogit Cog VMs in VM.r2337/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2337/> & VM.r2338/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2338/> respectively.
>  These contain fixes for another bad pc mapping bug that could cause
> hard crashes when jitting on a backward branch in a looping interpreted
> method.  If you're trying to reproduce Cog crashes please upgrade to one
> of tthese two VMs.
>
> TIA
> and happy new 2011, P.S.  according to an FBF
> RT @dpp RT @giuliodeluise 2011 is a prime number & the sum of 11
> consecutive prime numbers: 2011=157+163+167+173+179+181+191+193+197+199+211

Crashes right at start up:

Segmentation fault



Smalltalk stack dump:
0xff8aafb4 M Error class(Exception class)>handles: -1246542340: a(n)
Error class
0xff8aafdc M MethodContext(ContextPart)>handleSignal: -1220670568: a(n)
MethodContext
0xff8aaffc M MethodContext(ContextPart)>handleSignal: -1216945468: a(n)
MethodContext
0xff8ab020 I UnhandledError(Exception)>signal -1216945236: a(n)
UnhandledError
0xff8ab040 I UnhandledError class>signalForException: -1246541380: a(n)
UnhandledError class
0xff8ab064 I MessageNotUnderstood(Error)>defaultAction -1216945688: a(n)
MessageNotUnderstood
0xff8ab084 I MessageNotUnderstood>defaultAction -1216945688: a(n)
MessageNotUnderstood
0xff8ab0a8 I UndefinedObject>handleSignal: -1247481852: a(n) UndefinedObject
0xff8ab0cc I MessageNotUnderstood(Exception)>pass -1216945688: a(n)
MessageNotUnderstood
0xff8ab0f8 I [] in PasteUpMorph>becomeActiveDuring: -1245846436: a(n)
PasteUpMorph
0xff8ab11c I BlockClosure>valueWithPossibleArgs: -1221000224: a(n)
BlockClosure
0xff8ab13c M [] in MethodContext(ContextPart)>handleSignal: -1220670568:
a(n) MethodContext
0xff8ab15c M BlockClosure>ensure: -1216945284: a(n) BlockClosure
0xff8ab17c M MethodContext(ContextPart)>handleSignal: -1220670568: a(n)
MethodContext
0xff8ab1a4 I MethodContext(ContextPart)>handleSignal: -1216945468: a(n)
MethodContext
0xff8ab1c8 I MessageNotUnderstood(Exception)>signal -1216945688: a(n)
MessageNotUnderstood
0xff8ab1f0 I ProcessorScheduler(Object)>doesNotUnderstand: >=
-1247476532: a(n) ProcessorScheduler
0xff8ab210 M Process>priority: -1216945752: a(n) Process
0xff8ab238 I BlockClosure>forkAt: -1216945972: a(n) BlockClosure
0xff8ab25c I
InputEventPollingFetcher(InputEventFetcher)>installEventLoop
-1246030580: a(n) InputEventPollingFetcher
0xff8ab280 I InputEventPollingFetcher(InputEventFetcher)>startUp
-1246030580: a(n) InputEventPollingFetcher
0xff8ab2a0 I InputEventFetcher class>startUp -1246046280: a(n)
InputEventFetcher class
0xff8ab2b8 M InputEventFetcher class(Behavior)>startUp: -1246046280:
a(n) InputEventFetcher class
0xff8ab2e0 M [] in SmalltalkImage>send:toClassesNamedIn:with:
-1242015264: a(n) SmalltalkImage
0xff8ab2fc M BlockClosure>on:do: -1216946688: a(n) BlockClosure
0xff8ab32c M [] in SmalltalkImage>send:toClassesNamedIn:with:
-1242015264: a(n) SmalltalkImage
0xff8ab354 I OrderedCollection>do: -1241999736: a(n) OrderedCollection
0xff8ab37c I SmalltalkImage>send:toClassesNamedIn:with: -1242015264:
a(n) SmalltalkImage
0xff8ab3a8 I SmalltalkImage>processStartUpList: -1242015264: a(n)
SmalltalkImage
0xff8ab3d4 I SmalltalkImage>snapshot:andQuit:embedded: -1242015264: a(n)
SmalltalkImage
-1220672224 s SmalltalkImage>snapshot:andQuit:
-1220672132 s WorldState class>saveAndQuit
-1220672040 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
-1220671948 s BlockClosure>ensure:
-1220999860 s CursorWithMask(Cursor)>showWhile:
-1220999972 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
-1220671856 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp:
-1220671764 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp:
-1220671672 s MouseButtonEvent>sentTo:
-1220671580 s ToggleMenuItemMorph(Morph)>handleEvent:
-1220671488 s MorphicEventDispatcher>dispatchDefault:with:
-1220671396 s MorphicEventDispatcher>dispatchEvent:with:
-1220671304 s ToggleMenuItemMorph(Morph)>processEvent:using:
-1220671212 s MorphicEventDispatcher>dispatchDefault:with:
-1220671120 s MorphicEventDispatcher>dispatchEvent:with:
-1220671028 s MenuMorph(Morph)>processEvent:using:
-1220670936 s MenuMorph(Morph)>processEvent:
-1220670844 s MenuMorph>handleFocusEvent:
-1220670752 s [] in HandMorph>sendFocusEvent:to:clear:
-1220670660 s [] in PasteUpMorph>becomeActiveDuring:
-1220670568 s BlockClosure>on:do:
-1221000336 s PasteUpMorph>becomeActiveDuring:
-1221000456 s HandMorph>sendFocusEvent:to:clear:
-1220670476 s HandMorph>sendEvent:focus:clear:
-1221000572 s HandMorph>sendMouseEvent:
-1221000664 s HandMorph>handleEvent:
-1220670384 s HandMorph>processEvents
-1220670292 s [] in WorldState>doOneCycleNowFor:
-1220670200 s Array(SequenceableCollection)>do:
-1220670108 s WorldState>handsDo:
-1221001008 s WorldState>doOneCycleNowFor:
-1220670016 s WorldState>doOneCycleFor:
-1220669924 s PasteUpMorph>doOneCycle
-1221589100 s [] in Project class>spawnNewProcess
-1221602884 s [] in BlockClosure>newProcess

Most recent primitives
basicNew
size
at:
basicNew:
decompress:fromByteArray:at:
beCursorWithMask:
vmParameterAt:put:
vmParameterAt:put:
setGCBiasToGrowGCLimit:
setGCBiasToGrow:
ensure:
valueNoContextSwitch
wait
value
specialObjectsArray
new:
at:put:
value
signal
basicNew
new:
at:
value:
basicIdentityHash
on:do:
value
perform:with:
millisecondClockValue
signal
value:
size
size
bitShift:
\\
\\
\\
\\
\\
perform:with:
shallowCopy
subclasses
new:
new:
new:
//
value:
value:
value:
=
=
value:
value:
at:put:
value:
at:put:
addAll:
-
+
+
+
size
at:
do:
do:
value:
getSystemAttribute:
compare:with:collated:
value:
value:
platformName
=
=
value:
value:
getSystemAttribute:
compare:with:collated:
determineActivePlatformStartingAt:
determineActivePlatformStartingAt:
basicNew
value:
value:
value:
value:
perform:with:
actualScreenSize
species
species
supportsDisplayDepth:
new:
basicNew
beDisplay
value:
perform:with:
isMemberOf:
value:
perform:with:
basicNew
critical:
critical:
wait
wait
specialObjectsArray
species
new:
replaceFrom:to:with:startingAt:
specialObjectsArray
at:put:
at:put:
primSetInputSemaphore:
suspend
findNextUnwindContextUpTo:
value:
bottomContext
objectAt:
basicNew:
basicNew
basicNew
findNextHandlerContextStarting
tempAt:
nextHandlerContext
handleSignal:
isKindOf:
tempAt:put:
tempAt:put:
tempAt:put:
valueWithArguments:
findNextHandlerContextStarting
basicNew
findNextHandlerContextStarting
tempAt:
findNextHandlerContextStarting
tempAt:
Abgebrochen

Cheers
Philippe





MethodContext-numArgs.st (450 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 03.01.2011 00:15, Eliot Miranda wrote:

> Hi Martin, Hi All,
>
>     so find new VMs in VM.r2341/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2341/>.  The linux crashes
> (certainly the one you suffered from Martin) seem to be caused by an
> optimization bug (but they could be caused by bad code generation,
> creating something that assumes ordering constraints which C doesn't
> guarantee).  I suspect the former because I don't see the crash when
> running exactly the same VM and image from a different directory;
> provoking the crash requires a particular path (go figure; I haven't
> pinned this down yet).
>
> So my "fix" is preventing a complex function being inlined into the main
> interpreter loop, removing the sources of some warnings, and lowering
> the optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my
> build environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of
> this "fix".  I've violated the Deutsch criterion by not diagnosing the
> cause of the bug so I can't stand behind this fix; it's a hack that
> appears to work and may have merely pushed the real bug further
> underground.  Alas I don't have time to do a better job. Hopefully it'll
> get those of you on linux going again.

That fixes my Linux crash issues.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Stéphane Ducasse
In reply to this post by Eliot Miranda-2
Thanks
        http://code.google.com/p/pharo/issues/detail?id=3504

Stef


On Jan 3, 2011, at 8:38 PM, Eliot Miranda wrote:

> The MethodContext>>numArgs is I guess to be expected because there's no implementation so far.  Find attached.
>
> 'From Pharo-1.1.1-- of 12 September 2010 [Latest update: #11414] on 2 January 2011 at 2:23:32 pm'!
>
> !MethodContext methodsFor: 'accessing' stamp: 'eem 1/2/2011 14:23'!
> numArgs
> "Answer the number of arguments required to evaluate this method or block."
>
> ^closureOrNil ifNil: [method numArgs] ifNotNil: [closureOrNil numArgs]! !
>
>
> On Sun, Jan 2, 2011 at 2:49 AM, Mariano Martinez Peck <[hidden email]> wrote:
> Hi Eliot. Running:
>
> - Mac OS
> - VM r2340
> - PharoCore 1.2  12288  
>
> Running all tests I got this DNU.
> It is reproducable running the test  testClosureRestart  which seems to pass well in previous VMs.
>
> Cheers
>
> Mariano
>
> THERE_BE_DRAGONS_HERE
> MessageNotUnderstood: MethodContext>>numArgs
> 2 January 2011 11:38:31 am
>
> VM: Mac OS - intel - 1065 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.41] Croquet Cog 3.0.0
> Image: Pharo1.2beta [Latest update: #12288]
>
> SecurityManager state:
> Restricted: false
> FileAccess: true
> SocketAccess: true
> Working Dir /Users/mariano/Pharo/imagenes/PharoCore-1.2beta-12283
> Trusted Dir /foobar/tooBar/forSqueak/bogus/
> Untrusted Dir /Users/mariano/Library/Preferences/Croquet/Internet/Untrusted
>
> MethodContext(Object)>>doesNotUnderstand: #numArgs
>     Receiver: [| b |
> self assert: 10 == a.
>     self assert: nil == b.
>     b := a + 20.
>     firstTimeThrough
>         ifT...etc...
>     Arguments and temporary variables:
>         t1:     numArgs
>         t2:     nil
>         t3:     nil
>     Receiver's instance variables:
>         sender:     nil
>         pc:     nil
>         stackp:     3
>         method:     (MethodContextTest>>#privRestartBlockTest "a CompiledMethod(700186624)"...etc...
>         closureOrNil:     [| b |
> self assert: 10 == a.
>     self assert: nil == b.
>     b := a + 20...etc...
>         receiver:     MethodContextTest>>#testClosureRestart
>
>
>
> --- The full stack ---
> MethodContext(Object)>>doesNotUnderstand: #numArgs
> ------------------------------------------------------------
>
>
>
>
> On Sun, Jan 2, 2011 at 8:52 AM, Philippe Marschall <[hidden email]> wrote:
> On 01.01.2011 21:38, Eliot Miranda wrote:
> > Hi All,
> >
> >    there are new versions of both the SimpleStackBasedCogit and the
> > StackToRegisterMappingCogit Cog VMs in VM.r2337/
> > <http://www.mirandabanda.org/files/Cog/VM/VM.r2337/> & VM.r2338/
> > <http://www.mirandabanda.org/files/Cog/VM/VM.r2338/> respectively.
> >  These contain fixes for another bad pc mapping bug that could cause
> > hard crashes when jitting on a backward branch in a looping interpreted
> > method.  If you're trying to reproduce Cog crashes please upgrade to one
> > of tthese two VMs.
> >
> > TIA
> > and happy new 2011, P.S.  according to an FBF
> > RT @dpp RT @giuliodeluise 2011 is a prime number & the sum of 11
> > consecutive prime numbers: 2011=157+163+167+173+179+181+191+193+197+199+211
>
> Crashes right at start up:
>
> Segmentation fault
>
>
>
> Smalltalk stack dump:
> 0xff8aafb4 M Error class(Exception class)>handles: -1246542340: a(n)
> Error class
> 0xff8aafdc M MethodContext(ContextPart)>handleSignal: -1220670568: a(n)
> MethodContext
> 0xff8aaffc M MethodContext(ContextPart)>handleSignal: -1216945468: a(n)
> MethodContext
> 0xff8ab020 I UnhandledError(Exception)>signal -1216945236: a(n)
> UnhandledError
> 0xff8ab040 I UnhandledError class>signalForException: -1246541380: a(n)
> UnhandledError class
> 0xff8ab064 I MessageNotUnderstood(Error)>defaultAction -1216945688: a(n)
> MessageNotUnderstood
> 0xff8ab084 I MessageNotUnderstood>defaultAction -1216945688: a(n)
> MessageNotUnderstood
> 0xff8ab0a8 I UndefinedObject>handleSignal: -1247481852: a(n) UndefinedObject
> 0xff8ab0cc I MessageNotUnderstood(Exception)>pass -1216945688: a(n)
> MessageNotUnderstood
> 0xff8ab0f8 I [] in PasteUpMorph>becomeActiveDuring: -1245846436: a(n)
> PasteUpMorph
> 0xff8ab11c I BlockClosure>valueWithPossibleArgs: -1221000224: a(n)
> BlockClosure
> 0xff8ab13c M [] in MethodContext(ContextPart)>handleSignal: -1220670568:
> a(n) MethodContext
> 0xff8ab15c M BlockClosure>ensure: -1216945284: a(n) BlockClosure
> 0xff8ab17c M MethodContext(ContextPart)>handleSignal: -1220670568: a(n)
> MethodContext
> 0xff8ab1a4 I MethodContext(ContextPart)>handleSignal: -1216945468: a(n)
> MethodContext
> 0xff8ab1c8 I MessageNotUnderstood(Exception)>signal -1216945688: a(n)
> MessageNotUnderstood
> 0xff8ab1f0 I ProcessorScheduler(Object)>doesNotUnderstand: >=
> -1247476532: a(n) ProcessorScheduler
> 0xff8ab210 M Process>priority: -1216945752: a(n) Process
> 0xff8ab238 I BlockClosure>forkAt: -1216945972: a(n) BlockClosure
> 0xff8ab25c I
> InputEventPollingFetcher(InputEventFetcher)>installEventLoop
> -1246030580: a(n) InputEventPollingFetcher
> 0xff8ab280 I InputEventPollingFetcher(InputEventFetcher)>startUp
> -1246030580: a(n) InputEventPollingFetcher
> 0xff8ab2a0 I InputEventFetcher class>startUp -1246046280: a(n)
> InputEventFetcher class
> 0xff8ab2b8 M InputEventFetcher class(Behavior)>startUp: -1246046280:
> a(n) InputEventFetcher class
> 0xff8ab2e0 M [] in SmalltalkImage>send:toClassesNamedIn:with:
> -1242015264: a(n) SmalltalkImage
> 0xff8ab2fc M BlockClosure>on:do: -1216946688: a(n) BlockClosure
> 0xff8ab32c M [] in SmalltalkImage>send:toClassesNamedIn:with:
> -1242015264: a(n) SmalltalkImage
> 0xff8ab354 I OrderedCollection>do: -1241999736: a(n) OrderedCollection
> 0xff8ab37c I SmalltalkImage>send:toClassesNamedIn:with: -1242015264:
> a(n) SmalltalkImage
> 0xff8ab3a8 I SmalltalkImage>processStartUpList: -1242015264: a(n)
> SmalltalkImage
> 0xff8ab3d4 I SmalltalkImage>snapshot:andQuit:embedded: -1242015264: a(n)
> SmalltalkImage
> -1220672224 s SmalltalkImage>snapshot:andQuit:
> -1220672132 s WorldState class>saveAndQuit
> -1220672040 s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
> -1220671948 s BlockClosure>ensure:
> -1220999860 s CursorWithMask(Cursor)>showWhile:
> -1220999972 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
> -1220671856 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp:
> -1220671764 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp:
> -1220671672 s MouseButtonEvent>sentTo:
> -1220671580 s ToggleMenuItemMorph(Morph)>handleEvent:
> -1220671488 s MorphicEventDispatcher>dispatchDefault:with:
> -1220671396 s MorphicEventDispatcher>dispatchEvent:with:
> -1220671304 s ToggleMenuItemMorph(Morph)>processEvent:using:
> -1220671212 s MorphicEventDispatcher>dispatchDefault:with:
> -1220671120 s MorphicEventDispatcher>dispatchEvent:with:
> -1220671028 s MenuMorph(Morph)>processEvent:using:
> -1220670936 s MenuMorph(Morph)>processEvent:
> -1220670844 s MenuMorph>handleFocusEvent:
> -1220670752 s [] in HandMorph>sendFocusEvent:to:clear:
> -1220670660 s [] in PasteUpMorph>becomeActiveDuring:
> -1220670568 s BlockClosure>on:do:
> -1221000336 s PasteUpMorph>becomeActiveDuring:
> -1221000456 s HandMorph>sendFocusEvent:to:clear:
> -1220670476 s HandMorph>sendEvent:focus:clear:
> -1221000572 s HandMorph>sendMouseEvent:
> -1221000664 s HandMorph>handleEvent:
> -1220670384 s HandMorph>processEvents
> -1220670292 s [] in WorldState>doOneCycleNowFor:
> -1220670200 s Array(SequenceableCollection)>do:
> -1220670108 s WorldState>handsDo:
> -1221001008 s WorldState>doOneCycleNowFor:
> -1220670016 s WorldState>doOneCycleFor:
> -1220669924 s PasteUpMorph>doOneCycle
> -1221589100 s [] in Project class>spawnNewProcess
> -1221602884 s [] in BlockClosure>newProcess
>
> Most recent primitives
> basicNew
> size
> at:
> basicNew:
> decompress:fromByteArray:at:
> beCursorWithMask:
> vmParameterAt:put:
> vmParameterAt:put:
> setGCBiasToGrowGCLimit:
> setGCBiasToGrow:
> ensure:
> valueNoContextSwitch
> wait
> value
> specialObjectsArray
> new:
> at:put:
> value
> signal
> basicNew
> new:
> at:
> value:
> basicIdentityHash
> on:do:
> value
> perform:with:
> millisecondClockValue
> signal
> value:
> size
> size
> bitShift:
> \\
> \\
> \\
> \\
> \\
> perform:with:
> shallowCopy
> subclasses
> new:
> new:
> new:
> //
> value:
> value:
> value:
> =
> =
> value:
> value:
> at:put:
> value:
> at:put:
> addAll:
> -
> +
> +
> +
> size
> at:
> do:
> do:
> value:
> getSystemAttribute:
> compare:with:collated:
> value:
> value:
> platformName
> =
> =
> value:
> value:
> getSystemAttribute:
> compare:with:collated:
> determineActivePlatformStartingAt:
> determineActivePlatformStartingAt:
> basicNew
> value:
> value:
> value:
> value:
> perform:with:
> actualScreenSize
> species
> species
> supportsDisplayDepth:
> new:
> basicNew
> beDisplay
> value:
> perform:with:
> isMemberOf:
> value:
> perform:with:
> basicNew
> critical:
> critical:
> wait
> wait
> specialObjectsArray
> species
> new:
> replaceFrom:to:with:startingAt:
> specialObjectsArray
> at:put:
> at:put:
> primSetInputSemaphore:
> suspend
> findNextUnwindContextUpTo:
> value:
> bottomContext
> objectAt:
> basicNew:
> basicNew
> basicNew
> findNextHandlerContextStarting
> tempAt:
> nextHandlerContext
> handleSignal:
> isKindOf:
> tempAt:put:
> tempAt:put:
> tempAt:put:
> valueWithArguments:
> findNextHandlerContextStarting
> basicNew
> findNextHandlerContextStarting
> tempAt:
> findNextHandlerContextStarting
> tempAt:
> Abgebrochen
>
> Cheers
> Philippe
>
>
>
>
> <MethodContext-numArgs.st>


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
Hi All,

    find new VMs in VM.r2344/ (SimpleStackBasedCogit) and VM.r2345/ (StackToRegisterMappingCogit) and VMMaker-oscog-45.  These fix a bug that could cause crashes when converting an interpreted method to a machine-code method on backward branch (i.e. when the Vm detects an interpreted method is looping).  

I hope there are no new issues with VM.r2344/ (SimpleStackBasedCogit).  However, Matthew Fulmer has found that on linux the VM.r2343/ VM.r2345/ (StackToRegisterMappingCogit) VMs crash immediately loading Squeak4.2-10856-beta.image.  I can reproduce this but haven't had time to investigate.  The StackToRegisterMappingCogit VMs do start up this image on Mac and Windows.

Agan thanks for pounding on these.  I may not be able to attend to the linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next weekend. Apologies.

best
Eliot

On Thu, Dec 30, 2010 at 6:02 PM, Eliot Miranda <[hidden email]> wrote:
Hi All,

     I've released a new version of Cog that has a substantially improved code generator along the lines of Peter Deutsch's HPS (VisualWorks) and various of Ian Piumarta's VMs.  These all use a simple tecnique to identify constant references in bytecode and to support a register-based calling convention.  While this does produce faster code it tends to accelerate low-level code much more than high-level code as you can see by the following benchmarks:

SimpleStackBasedCogit: [1 to: 100000000 do: [:i|]] timeToRun 691
StackToRegisterMappingCogit: [1 to: 100000000 do: [:i|]] timeToRun 192
192 - 691 / 6.91 -72%

SimpleStackBasedCogit: 0 tinyBenchmarks '753495217 bytecodes/sec; 64769127 sends/sec'
StackToRegisterMappingCogit: 0 tinyBenchmarks '931756141 bytecodes/sec; 128157989 sends/sec'
931756141 - 753495217 / 7534952.17 -24%
128157989 - 64769127 / 647691.27 -98%

SimpleStackBasedCogit: [Compiler recompileAll] timeToRun 47013 (no transcript
StackToRegisterMappingCogit: [Compiler recompileAll] timeToRun 43406 (no transcript)
43406 - 47013 / 470.13 -7.67234594686576

The status of this code is essentially beta.  The test suite runs the same on the new code generator as on the old, but I think there are still bugs because I get the occasional transient error.  I am therefore very interested in any reproducible errors you can find.

The VMs (http://www.mirandabanda.org/files/Cog/VM/VM.r2334/) contain a few other important changes: 

- a bug fix to bytecode<->native pc mappng that produced incorrect results for methods containing blocks with ^-returns in them.  One symptom is incorrect highlighting of the pc in the debugger, althoguh symptoms could be much serious.

- jitting interpreted methods on backward branches.  Currently any interpreted method that performs more than 20 backward branches will be considered for JIT compilation and if it is suitable (default, <= 60 literals) will be compiled to native code.

- new callback support.  I need to commit some changes to the Alien package to provide access to this but essentially the VM's callback support is now able to be ported to architectures with register-based calling conventions (ARM, PowerPC, SPARC etc).  I'll try and get the Alien code released soon, and to back-port the changes to the standard VM before the end of the holiday.

One thing that is still /not/ fixed is the lack of a SoundPlugin on win32.  Apologies.  I'll try and get a fix for this before the end of the holidays too, but time might be too tight.  There are other priorities such as harmonising the standard and Cog VMs for the 4.2 release.

best
Eliot


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: new Cog VMs

Eliot Miranda-2
In reply to this post by Igor Stasenko
Hi Igor,  Hi All,

On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <[hidden email]> wrote:
On 3 January 2011 00:15, Eliot Miranda <[hidden email]> wrote:
> Hi Martin, Hi All,
>     so find new VMs in VM.r2341/.  The linux crashes (certainly the one you
> suffered from Martin) seem to be caused by an optimization bug (but they
> could be caused by bad code generation, creating something that assumes
> ordering constraints which C doesn't guarantee).  I suspect the former
> because I don't see the crash when running exactly the same VM and image
> from a different directory; provoking the crash requires a particular path
> (go figure; I haven't pinned this down yet).
> So my "fix" is preventing a complex function being inlined into the main
> interpreter loop, removing the sources of some warnings, and lowering the
> optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my build
> environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of this
> "fix".  I've violated the Deutsch criterion by not diagnosing the cause of
> the bug so I can't stand behind this fix; it's a hack that appears to work
> and may have merely pushed the real bug further underground.  Alas I don't
> have time to do a better job. Hopefully it'll get those of you on linux
> going again.

Eliot, if you remember, i also had crash issues on linux, and pinned down it to
removing optimization from <something>heartbeat.c while keeping
gcc3x-cointerp.c to use
 same optimization flags as for rest of files.

Indeed, quite right.  I happened to add a flag to turn off the heartbeat so I could debug the crash Matthew was seeing in starting up Squeak4.2-10856-beta.image (since single-stepping through machine code always gets interrupted by the heartbeat, it being an interval timer) and lo and behold the bug went away.  This is very worrying because it appears to imply that there's a serious bug in the linux kernel/gcc since delivering a software interrupt shouldn't corrupt registers, but it clearly does.  I'll try and pass it by someone who's an expert in this area.

Anyway, now find a new linux VM in VM.r2346/ that seems fine with the interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2.  Running this VM on CentOS 5.3 under Parallels I get
    2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0 unexpected passes
for the full test suite in Squeak4.2-10856-beta.image.

So have at it.

best
Eliot


I will start coding cmake config for Cog during next week and will be
able to check my previous
observations again.

> best
> Eliot
> On Sat, Jan 1, 2011 at 11:16 PM, <[hidden email]> wrote:

--
Best regards,
Igor Stasenko AKA sig.


Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: new Cog VMs

Andres Valloud-4
> Indeed, quite right.  I happened to add a flag to turn off the heartbeat
> so I could debug the crash Matthew was seeing in starting up
> Squeak4.2-10856-beta.image (since single-stepping through machine code
> always gets interrupted by the heartbeat, it being an interval timer)
> and lo and behold the bug went away.  This is very worrying because it
> appears to imply that there's a serious bug in the linux kernel/gcc
> since delivering a software interrupt shouldn't corrupt registers, but
> it clearly does.  I'll try and pass it by someone who's an expert in
> this area.

Or the signal handler functions do not comply with the relevant
specifications, e.g.: signal handlers that do not preserve the value of
errno, signal handlers that use a function not in the list of approved
safe functions you can call from a signal handler as per the Single Unix
Specification, etc...

Andres.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: new Cog VMs

Igor Stasenko
In reply to this post by Eliot Miranda-2
On 11 January 2011 04:42, Eliot Miranda <[hidden email]> wrote:

> Hi Igor,  Hi All,
>
> On Sun, Jan 2, 2011 at 4:11 PM, Igor Stasenko <[hidden email]> wrote:
>>
>> On 3 January 2011 00:15, Eliot Miranda <[hidden email]> wrote:
>> > Hi Martin, Hi All,
>> >     so find new VMs in VM.r2341/.  The linux crashes (certainly the one
>> > you
>> > suffered from Martin) seem to be caused by an optimization bug (but they
>> > could be caused by bad code generation, creating something that assumes
>> > ordering constraints which C doesn't guarantee).  I suspect the former
>> > because I don't see the crash when running exactly the same VM and image
>> > from a different directory; provoking the crash requires a particular
>> > path
>> > (go figure; I haven't pinned this down yet).
>> > So my "fix" is preventing a complex function being inlined into the main
>> > interpreter loop, removing the sources of some warnings, and lowering
>> > the
>> > optimization level of the gcc3x-cointerp.c file to -O1 from -O2 (my
>> > build
>> > environment, CentOS Linux 5.3, uses gcc 4.1.2).  I'm not proud of this
>> > "fix".  I've violated the Deutsch criterion by not diagnosing the cause
>> > of
>> > the bug so I can't stand behind this fix; it's a hack that appears to
>> > work
>> > and may have merely pushed the real bug further underground.  Alas I
>> > don't
>> > have time to do a better job. Hopefully it'll get those of you on linux
>> > going again.
>>
>> Eliot, if you remember, i also had crash issues on linux, and pinned down
>> it to
>> removing optimization from <something>heartbeat.c while keeping
>> gcc3x-cointerp.c to use
>>  same optimization flags as for rest of files.
>
> Indeed, quite right.  I happened to add a flag to turn off the heartbeat so
> I could debug the crash Matthew was seeing in starting up
> Squeak4.2-10856-beta.image (since single-stepping through machine code
> always gets interrupted by the heartbeat, it being an interval timer) and lo
> and behold the bug went away.  This is very worrying because it appears to
> imply that there's a serious bug in the linux kernel/gcc since delivering a
> software interrupt shouldn't corrupt registers, but it clearly does.  I'll
> try and pass it by someone who's an expert in this area.
> Anyway, now find a new linux VM in VM.r2346/ that seems fine with the
> interpreter and the cogit compiled at -02 but the heartbeat compiled at -O2.
>  Running this VM on CentOS 5.3 under Parallels I get
>     2839 run, 2796 passes, 7 expected failures, 24 failures, 11 errors, 0
> unexpected passes
> for the full test suite in Squeak4.2-10856-beta.image.
> So have at it.

Great! Nice to see that we can deal with elusive bugs :)

> best
> Eliot
>>
>> I will start coding cmake config for Cog during next week and will be
>> able to check my previous
>> observations again.
>>
>> > best
>> > Eliot
>> > On Sat, Jan 1, 2011 at 11:16 PM, <[hidden email]> wrote:
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>



--
Best regards,
Igor Stasenko AKA sig.

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: new Cog VMs

Eliot Miranda-2
In reply to this post by Andres Valloud-4


On Mon, Jan 10, 2011 at 11:31 PM, Andres Valloud <[hidden email]> wrote:
Indeed, quite right.  I happened to add a flag to turn off the heartbeat
so I could debug the crash Matthew was seeing in starting up
Squeak4.2-10856-beta.image (since single-stepping through machine code
always gets interrupted by the heartbeat, it being an interval timer)
and lo and behold the bug went away.  This is very worrying because it
appears to imply that there's a serious bug in the linux kernel/gcc
since delivering a software interrupt shouldn't corrupt registers, but
it clearly does.  I'll try and pass it by someone who's an expert in
this area.

Or the signal handler functions do not comply with the relevant specifications, e.g.: signal handlers that do not preserve the value of errno, signal handlers that use a function not in the list of approved safe functions you can call from a signal handler as per the Single Unix Specification, etc...

Good point.  The signal handler essentially calls gettimeofday (not on the approved list but time is) and sets a couple of variables (current 64-bit microsecond time, stackLimit).  But it does not preserve errno.  I don't want to avoid calling gettimeofday and can see no harm in it; it's equivalent internally to time providing it doesn't use its TIMEZONE arg (which it doesn't).  But the signal handler /doesn't/ preserve errno and doing so is a very good idea and easy to do.  Thanks.


Andres.


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Philippe Marschall-2-3
In reply to this post by Eliot Miranda-2
On 10.01.2011 01:28, Eliot Miranda wrote:

> Hi All,
>
>     find new VMs in VM.r2344/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit)
> and VM.r2345/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit)
> and VMMaker-oscog-45.  These fix a bug that could cause crashes when
> converting an interpreted method to a machine-code method on backward
> branch (i.e. when the Vm detects an interpreted method is looping).  
>
> I hope there are no new issues with VM.r2344/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2344/> (SimpleStackBasedCogit).
>  However, Matthew Fulmer has found that on linux the VM.r2343/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2343/> VM.r2345/
> <http://www.mirandabanda.org/files/Cog/VM/VM.r2345/> (StackToRegisterMappingCogit)
> VMs crash immediately loading Squeak4.2-10856-beta.image.  I can
> reproduce this but haven't had time to investigate.
>  The StackToRegisterMappingCogit VMs do start up this image on Mac and
> Windows.
>
> Agan thanks for pounding on these.  I may not be able to attend to the
> linux/StackToRegisterMappingCogit/Squeak4.2-10856-beta.image until next
> weekend. Apologies.

r2346 fixes the issues I sometimes had with when the stack would be
messed up the first time a method is executed.

Cheers
Philippe


Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
Hi All,

   I've uploaded new VMs to VM.r2348/ (SimpleStackBasedCogit) and VM.r2349/ (StackToRegisterMappingCogit). The former are simply to be up-to-date with svn & Monticello.  The latter also fix a bad bug with the StackToRegisterMappingCogit where e.g. 16r10 bitOr: 16r20 would evaluate to 1.   I've smoke-tested the 2349 VMs on the Squeak4.2 beta test suite and things look good.

best
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] Re: new Cog VMs

Andres Valloud-4
In reply to this post by Eliot Miranda-2
>     Or the signal handler functions do not comply with the relevant
>     specifications, e.g.: signal handlers that do not preserve the value
>     of errno, signal handlers that use a function not in the list of
>     approved safe functions you can call from a signal handler as per
>     the Single Unix Specification, etc...
>
>
> Good point.  The signal handler essentially calls gettimeofday (not on
> the approved list but time is) and sets a couple of variables (current
> 64-bit microsecond time, stackLimit).  But it does not preserve errno.
>   I don't want to avoid calling gettimeofday and can see no harm in it;
> it's equivalent internally to time providing it doesn't use its TIMEZONE
> arg (which it doesn't).  But the signal handler /doesn't/ preserve errno
> and doing so is a very good idea and easy to do.  Thanks.

Ok, but note that calling a function not on the list of approved
functions results in undefined behavior.  So, maybe later on you change
the optimization level and the VM doesn't work, or you change some other
unrelated code and the VM segfaults, etc... maybe it's less painful to
just bite the bullet and obey the spec.

Andres.

12