I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: Teleplace VM 1.0.15 (release) from Oct 4, 2010 Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. -Brian T 0x8fceec M [] in Semaphore>critical: 451980788: a(n) Semaphore 0x8fcf0c M BlockClosure>ensure: 474826064: a(n) BlockClosure 0x8fcf2c M Semaphore>critical: 451980788: a(n) Semaphore 0x8fcf48 M DelayWaitTimeout(Delay)>unschedule 474825444: a(n) DelayWaitTimeout 0x8fcf60 M [] in DelayWaitTimeout>wait 474825444: a(n) DelayWaitTimeout 0x8fcf80 M BlockClosure>ensure: 474825564: a(n) BlockClosure 0x8fcf9c M DelayWaitTimeout>wait 474825444: a(n) DelayWaitTimeout 0x8fcfb8 M Semaphore>waitTimeoutMSecs: 473341640: a(n) Semaphore 0x8fcfe4 M Socket>waitForConnectionFor:ifTimedOut: 473341616: a(n) Socket 0x8fd004 M Socket>waitForAcceptFor: 473341616: a(n) Socket 0x8fd028 M ZnMultiThreadedServer>serveConnectionsOn: 473340944: a(n) ZnMultiThreadedServer 0x8fd04c I [] in ZnMultiThreadedServer>listenLoop 473340944: a(n) ZnMultiThreadedServer 0x8fd06c M BlockClosure>ifCurtailed: 473341896: a(n) BlockClosure 0x8fd090 I ZnMultiThreadedServer>listenLoop 473340944: a(n) ZnMultiThreadedServer 0x8fd0b0 I [] in ZnMultiThreadedServer(ZnSingleThreadedServer)>start 473340944: a(n) ZnMultiThreadedServer 0x8fd0d0 I [] in BlockClosure>newProcess 473341224: a(n) BlockClosure 0x8f7090 I ProcessorScheduler class>idleProcess 434630368: a(n) ProcessorScheduler class 0x8f70b0 I [] in ProcessorScheduler class>startUp 434630368: a(n) ProcessorScheduler class 0x8f70d0 I [] in BlockClosure>newProcess 458657424: a(n) BlockClosure Printing all processes: Process 0x1b568f6c priority 10 0x8f7090 I ProcessorScheduler class>idleProcess 434630368: a(n) ProcessorScheduler class 0x8f70b0 I [] in ProcessorScheduler class>startUp 434630368: a(n) ProcessorScheduler class 0x8f70d0 I [] in BlockClosure>newProcess 458657424: a(n) BlockClosure Process 0x1b617dec priority 50 0x8f1090 I WeakArray class>finalizationProcess 434630788: a(n) WeakArray class 0x8f10b0 I [] in WeakArray class>restartFinalizationProcess 434630788: a(n) WeakArray class 0x8f10d0 I [] in BlockClosure>newProcess 459373840: a(n) BlockClosure Process 0x1b6159c8 priority 60 0x8f3fd8 M [] in Semaphore>critical: 451980788: a(n) Semaphore 0x8f3ff8 M BlockClosure>ensure: 473703736: a(n) BlockClosure 0x8f4018 M Semaphore>critical: 451980788: a(n) Semaphore 0x8f4034 M Delay>schedule 459364884: a(n) Delay 0x8f404c M Delay>wait 459364884: a(n) Delay 0x8f4064 M InputEventPollingFetcher>waitForInput 435076220: a(n) InputEventPollingFetcher 0x8f4090 I InputEventPollingFetcher(InputEventFetcher)>eventLoop 435076220: a(n) InputEventPollingFetcher 0x8f40b0 I [] in InputEventPollingFetcher(InputEventFetcher)>installEventLoop 435076220: a(n) InputEventPollingFetcher 0x8f40d0 I [] in BlockClosure>newProcess 459364588: a(n) BlockClosure Process 0x19fbcaa4 priority 40 0x8f4b6c M [] in Semaphore>critical: 451980788: a(n) Semaphore 0x8f4b8c M BlockClosure>ensure: 473745092: a(n) BlockClosure 0x8f4bac M Semaphore>critical: 451980788: a(n) Semaphore 0x8f4bc8 M DelayWaitTimeout(Delay)>schedule 473744728: a(n) DelayWaitTimeout 0x8f4be0 M [] in DelayWaitTimeout>wait 473744728: a(n) DelayWaitTimeout 0x8f4c00 M BlockClosure>ensure: 473744848: a(n) BlockClosure 0x8f4c1c M DelayWaitTimeout>wait 473744728: a(n) DelayWaitTimeout 0x8f4c38 M Semaphore>waitTimeoutMSecs: 473339724: a(n) Semaphore 0x8f4c60 I NetNameResolver class>waitForCompletionUntil: 434630188: a(n) NetNameResolver class 0x8f4c88 M [] in NetNameResolver class>addressForName:timeout: 434630188: a(n) NetNameResolver class 0x8f4ca8 M [] in Semaphore>critical: 433798980: a(n) Semaphore 0x8f4cc8 M BlockClosure>ensure: 473744680: a(n) BlockClosure 0x8f4ce8 M Semaphore>critical: 433798980: a(n) Semaphore 0x8f4d0c M NetNameResolver class>addressForName:timeout: 434630188: a(n) NetNameResolver class 0x8f4d38 I SocketStream class>openConnectionToHostNamed:port: 434657256: a(n) SocketStream class 0x8f4d64 I ZnNetworkingUtils>socketStreamToHostNamed:port: 439484636: a(n) ZnNetworkingUtils 0x8f4d84 M ZnNetworkingUtils>socketStreamToUrlDirectly: 439484636: a(n) ZnNetworkingUtils 0x8f4da0 M ZnNetworkingUtils>socketStreamToUrl: 439484636: a(n) ZnNetworkingUtils 0x8f4dc4 I ZnNetworkingUtils class>socketStreamToUrl: 436369344: a(n) ZnNetworkingUtils class 0x8f4df0 I ZnUserAgent>openConnection 473719764: a(n) ZnUserAgent 0x8f4e1c I [] in ZnUserAgent>method:for:headers:data:limit: 473719764: a(n) ZnUserAgent 0x8f4e38 M BlockClosure>on:do: 473744280: a(n) BlockClosure 0x8f4e64 I ZnUserAgent>method:for:headers:data:limit: 473719764: a(n) ZnUserAgent 0x8f4e9c I ZnUserAgent>method:for:headers:data: 473719764: a(n) ZnUserAgent 0x8f4ecc I ZnUserAgent>delete:headers: 473719764: a(n) ZnUserAgent 0x8f4ef4 I ZnUserAgent>delete: 473719764: a(n) ZnUserAgent 0x8f4f18 M [] in ZnUserAgentTests>testDelete 459672096: a(n) ZnUserAgentTests 0x8f4f38 M BlockClosure>ensure: 473341072: a(n) BlockClosure 0x8f4f5c M ZnUserAgentTests>testDelete 459672096: a(n) ZnUserAgentTests 0x8f4f74 M ZnUserAgentTests(TestCase)>performTest 459672096: a(n) ZnUserAgentTests 0x8f4f8c M [] in ZnUserAgentTests(TestCase)>runCase 459672096: a(n) ZnUserAgentTests 0x8f4fac M BlockClosure>ensure: 473340896: a(n) BlockClosure 0x8f4fc8 M ZnUserAgentTests(TestCase)>runCase 459672096: a(n) ZnUserAgentTests 0x8f4fe4 M [] in TestResult>runCase: 459609256: a(n) TestResult 0x8f5000 M BlockClosure>on:do: 473340688: a(n) BlockClosure 0x8f5020 M TestResult>runCase: 459609256: a(n) TestResult 0x8f503c M ZnUserAgentTests(TestCase)>run: 459672096: a(n) ZnUserAgentTests 0x8f5058 M TestRunner>runTest: 459541056: a(n) TestRunner 0x8f5074 M [] in TestRunner>runSuite: 459541056: a(n) TestRunner 0x8f50ac M [] in OrderedCollection(Collection)>do:displayingProgress:every: 459609472: a(n) OrderedCollection 0x8f50cc M OrderedCollection>do: 459609472: a(n) OrderedCollection 0x8efb08 M [] in OrderedCollection(Collection)>do:displayingProgress:every: 459609472: a(n) OrderedCollection 0x8efb2c M [] in ProgressInitiationException>defaultMorphicAction 472809788: a(n) ProgressInitiationException 0x8efb48 M BlockClosure>on:do: 472810620: a(n) BlockClosure 0x8efb70 M [] in ProgressInitiationException>defaultMorphicAction 472809788: a(n) ProgressInitiationException 0x8efb90 M BlockClosure>ensure: 472810484: a(n) BlockClosure 0x8efbb4 M ProgressInitiationException>defaultMorphicAction 472809788: a(n) ProgressInitiationException 0x8efbcc M MorphicUIManager>progressInitiationExceptionDefaultAction: 435697136: a(n) MorphicUIManager 0x8efbe8 M ProgressInitiationException>defaultAction 472809788: a(n) ProgressInitiationException 0x8efc04 M UndefinedObject>handleSignal: 433782788: a(n) UndefinedObject 0x8efc24 M MethodContext(ContextPart)>handleSignal: 460115692: a(n) MethodContext 0x8efc40 M ProgressInitiationException(Exception)>signal 472809788: a(n) ProgressInitiationException 0x8efc58 M ProgressInitiationException>display:at:from:to:during: 472809788: a(n) ProgressInitiationException 0x8efc84 M ProgressInitiationException class>display:at:from:to:during: 436259476: a(n) ProgressInitiationException class 0x8efcb0 M ByteString(String)>displayProgressAt:from:to:during: 444517592: a(n) ByteString 0x8efce4 M OrderedCollection(Collection)>do:displayingProgress:every: 459609472: a(n) OrderedCollection 0x8efd08 M OrderedCollection(Collection)>do:displayingProgress: 459609472: a(n) OrderedCollection 0x8efd38 I [] in TestRunner>basicRunSuite:do: 459541056: a(n) TestRunner 0x8efd58 M BlockClosure>ensure: 472809576: a(n) BlockClosure 0x8efd7c I TestRunner>basicRunSuite:do: 459541056: a(n) TestRunner 0x8efda4 I TestRunner>runSuite: 459541056: a(n) TestRunner 0x8efdc0 M TestRunner>runAll 459541056: a(n) TestRunner 0x8efde0 I PluggableButtonMorph>performAction 459567968: a(n) PluggableButtonMorph 0x8efdfc M [] in PluggableButtonMorph>mouseUp: 459567968: a(n) PluggableButtonMorph 0x8efe20 M Array(SequenceableCollection)>do: 459609112: a(n) Array 0x8efe48 I PluggableButtonMorph>mouseUp: 459567968: a(n) PluggableButtonMorph 0x8efe64 M PluggableButtonMorph(Morph)>handleMouseUp: 459567968: a(n) PluggableButtonMorph 0x8efe80 M MouseButtonEvent>sentTo: 459609072: a(n) MouseButtonEvent 0x8efe9c M PluggableButtonMorph(Morph)>handleEvent: 459567968: a(n) PluggableButtonMorph 0x8efeb8 M PluggableButtonMorph(Morph)>handleFocusEvent: 459567968: a(n) PluggableButtonMorph 0x8efee0 M [] in HandMorph>sendFocusEvent:to:clear: 435026948: a(n) HandMorph 0x8efefc M [] in PasteUpMorph>becomeActiveDuring: 435476532: a(n) PasteUpMorph 0x8eff18 M BlockClosure>on:do: 459609020: a(n) BlockClosure 0x8eff44 M PasteUpMorph>becomeActiveDuring: 435476532: a(n) PasteUpMorph 0x8eff68 M HandMorph>sendFocusEvent:to:clear: 435026948: a(n) HandMorph 0x8eff90 M HandMorph>sendEvent:focus:clear: 435026948: a(n) HandMorph 0x8effb4 M HandMorph>sendMouseEvent: 435026948: a(n) HandMorph 0x8effd8 M HandMorph>handleEvent: 435026948: a(n) HandMorph 0x8f0004 M HandMorph>processEvents 435026948: a(n) HandMorph 0x8f001c M [] in WorldState>doOneCycleNowFor: 435645020: a(n) WorldState 0x8f0040 M Array(SequenceableCollection)>do: 433796144: a(n) Array 0x8f005c M WorldState>handsDo: 435645020: a(n) WorldState 0x8f0078 M WorldState>doOneCycleNowFor: 435645020: a(n) WorldState 0x8f0094 M WorldState>doOneCycleFor: 435645020: a(n) WorldState 0x8f00b0 M PasteUpMorph>doOneCycle 435476532: a(n) PasteUpMorph 0x8f00d0 I [] in Project class>? 435884876: a(n) Project class 435931716 s [] in BlockClosure>? Process 0x1af0afd4 priority 80 0x8f20b0 M Delay class>handleTimerEvent 434636128: a(n) Delay class 0x8f20d0 I Delay class>runTimerEventLoop 434636128: a(n) Delay class 451980936 s [] in Delay class>startTimerEventLoop 451981172 s [] in BlockClosure>newProcess Process 0x1b568da0 priority 60 0x8f3090 I SmalltalkImage>lowSpaceWatcher 438033300: a(n) SmalltalkImage 0x8f30b0 I [] in SmalltalkImage>installLowSpaceWatcher 438033300: a(n) SmalltalkImage 0x8f30d0 I [] in BlockClosure>newProcess 458656964: a(n) BlockClosure Printing recent primitives: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: ... (Lots of these from the recent primitives) relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: relinquishProcessorForMicroseconds: ### Socket [3173c8] Handle: 264 Type: 0 State: 1 Error: 0 readSema: 5 writeSema: 6 connSema: 4 Pending accepts: 0 Read Watcher Op: 4 Write Watcher Op: 0 Close pending: 0 In read select: 1 In write select: 0 Pharo 1.3 hang.JPG (255K) Download Attachment |
On 28 Jun 2011, at 18:35, Brian Tabone wrote: > I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > > Teleplace VM 1.0.15 (release) from Oct 4, 2010 > Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. It seems that ZnUserAgentTests>>#testDelete fails for you. It works for me and for the regular integration/build servers, does the windows slave pass this test ? Sven |
In reply to this post by Brian Tabone-2
On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > On 28 Jun 2011, at 18:35, Brian Tabone wrote: > >> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: >> >> Teleplace VM 1.0.15 (release) from Oct 4, 2010 >> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) >> >> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > > It seems that ZnUserAgentTests>>#testDelete fails for you. > > It works for me and for the regular integration/build servers, does the windows slave pass this test ? > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > >> >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: >> >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: >>> >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) >>> >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. >> >> It seems that ZnUserAgentTests>>#testDelete fails for you. >> >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? >> > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. OK, Marcus, I don't want to push, you'll let us know when it is ready. Brian, Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? Does the whole test suite always fail at the same test ? Sven |
Sven, I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. -Brian From: Sven Van Caekenberghe <[hidden email]> To: [hidden email] Sent: Tuesday, June 28, 2011 1:48 PM Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > >> >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: >> >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: >>> >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) >>> >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. >> >> It seems that ZnUserAgentTests>>#testDelete fails for you. >> >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? >> > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. OK, Marcus, I don't want to push, you'll let us know when it is ready. Brian, Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? Does the whole test suite always fail at the same test ? Sven Pharo 1.3 test without Zn.JPG (198K) Download Attachment Pharo 1.3 VM crash.JPG (44K) Download Attachment crash.dmp (27K) Download Attachment |
In reply to this post by Sven Van Caekenberghe
On Jun 28, 2011, at 9:20 PM, Brian Tabone wrote: > Sven, > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. > I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. > The VM seems to be very old... we need to do these tests with the current code base... > -Brian > > From: Sven Van Caekenberghe <[hidden email]> > To: [hidden email] > Sent: Tuesday, June 28, 2011 1:48 PM > Subject: Re: [Pharo-project] Re Please test Pharo 1.3! > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > >> > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > >> > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > >>> > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > >>> > >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > >> > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > >> > >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? > >> > > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > Brian, > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? > > Does the whole test suite always fail at the same test ? > > Sven > > > > > > <Pharo 1.3 test without Zn.JPG><Pharo 1.3 VM crash.JPG><crash.dmp> -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Yes, can you try with the last one from http://www.mirandabanda.org/files/Cog/VM/ ?
On Tue, Jun 28, 2011 at 9:27 PM, Marcus Denker <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
In reply to this post by Brian Tabone-2
Checking dump file it looks like a known crash with Cog. Several times I saw crashes related to "CompiledMethod(Object)>becomeForward: 123450824: a(n) CompiledMethod"
Stack: Smalltalk stack dump: 0x936f6c M CompiledMethod(Object)>becomeForward: 123450824: a(n) CompiledMethod 0x936f98 I CompiledMethod>setSourcePointer: 123450824: a(n) CompiledMethod 0x936fb4 M CompiledMethod>setSourcePosition:inFile: 123450824: a(n) CompiledMethod 0x936fdc M CompiledMethod>putSource:fromParseNode:inFile:withPreamble: 123450824: a(n) CompiledMethod 0x937004 M CompiledMethod>putSource:fromParseNode:class:category:withStamp:inFile:priorMethod: 123450824: a(n) CompiledMethod 0x937038 M Metaclass(ClassDescription)>logMethodSource:forMethodWithNode:inCategory:withStamp:notifying: 123252764: a(n) Metaclass 0x93706c I MethodAddition>writeSourceToLog 123434384: a(n) MethodAddition 0x93708c I MethodAddition>createCompiledMethod 123434384: a(n) MethodAddition 0x9370b0 I MCMethodDefinition>addMethodAdditionTo: 117453400: a(n) MCMethodDefinition 0x9370d0 M [] in MCPackageLoader>tryToLoad: 121841256: a(n) MCPackageLoader 0x8f48c0 M BlockClosure>on:do: 123434340: a(n) BlockClosure 0x8f48e8 I MCPackageLoader>tryToLoad: 121841256: a(n) MCPackageLoader 0x8f4904 M [] in MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f493c M [] in OrderedCollection(Collection)>do:displayingProgress:every: 121975920: a(n) OrderedCollection 0x8f495c M OrderedCollection>do: 121975920: a(n) OrderedCollection 0x8f498c M [] in OrderedCollection(Collection)>do:displayingProgress:every: 121975920: a(n) OrderedCollection 0x8f49b0 M [] in ProgressInitiationException>defaultMorphicAction 123309096: a(n) ProgressInitiationException 0x8f49cc M BlockClosure>on:do: 123331824: a(n) BlockClosure 0x8f49f4 M [] in ProgressInitiationException>defaultMorphicAction 123309096: a(n) ProgressInitiationException 0x8f4a14 M BlockClosure>ensure: 123331688: a(n) BlockClosure 0x8f4a38 M ProgressInitiationException>defaultMorphicAction 123309096: a(n) ProgressInitiationException 0x8f4a50 M MorphicUIManager>progressInitiationExceptionDefaultAction: 80294140: a(n) MorphicUIManager 0x8f4a6c M ProgressInitiationException>defaultAction 123309096: a(n) ProgressInitiationException 0x8f4a88 M UndefinedObject>handleSignal: 78381060: a(n) UndefinedObject 0x8f4aa8 M MethodContext(ContextPart)>handleSignal: 104675620: a(n) MethodContext 0x8f4ac8 M MethodContext(ContextPart)>handleSignal: 117365292: a(n) MethodContext 0x8f4ae8 M MethodContext(ContextPart)>handleSignal: 121697844: a(n) MethodContext 0x8f4b08 M MethodContext(ContextPart)>handleSignal: 123155732: a(n) MethodContext 0x8f4b24 M ProgressInitiationException(Exception)>signal 123309096: a(n) ProgressInitiationException 0x8f4b3c M ProgressInitiationException>display:at:from:to:during: 123309096: a(n) ProgressInitiationException 0x8f4b68 M ProgressInitiationException class>display:at:from:to:during: 80856472: a(n) ProgressInitiationException class 0x8f4b94 M ByteString(String)>displayProgressAt:from:to:during: 89108292: a(n) ByteString 0x8f4bc8 M OrderedCollection(Collection)>do:displayingProgress:every: 121975920: a(n) OrderedCollection 0x8f4bec M OrderedCollection(Collection)>do:displayingProgress: 121975920: a(n) OrderedCollection 0x8f4c0c M [] in MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f4c28 M BlockClosure>on:do: 123154900: a(n) BlockClosure 0x8f4c50 I [] in MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f4c70 M BlockClosure>ensure: 123154776: a(n) BlockClosure 0x8f4c94 I MCPackageLoader>basicLoad 121841256: a(n) MCPackageLoader 0x8f4cb4 I [] in MCPackageLoader>loadWithNameLike: 121841256: a(n) MCPackageLoader 0x8f4cd8 I [] in MCPackageLoader>useChangeSetNamed:during: 121841256: a(n) MCPackageLoader 0x8f4cf8 M BlockClosure>ensure: 123154580: a(n) BlockClosure 0x8f4d24 I MCPackageLoader>useChangeSetNamed:during: 121841256: a(n) MCPackageLoader 0x8f4d4c I MCPackageLoader>useNewChangeSetNamedLike:during: 121841256: a(n) MCPackageLoader 0x8f4d74 I MCPackageLoader>loadWithNameLike: 121841256: a(n) MCPackageLoader 0x8f4d9c I MCVersionLoader>loadWithNameLike: 121632208: a(n) MCVersionLoader 0x8f4dc0 I MCVersionLoader>load 121632208: a(n) MCVersionLoader 0x8f4de0 I GoferLoad>execute 121632192: a(n) GoferLoad 0x8f4e08 I Gofer>execute:do: 121439760: a(n) Gofer 0x8f4e30 I Gofer>execute: 121439760: a(n) Gofer 0x8f4e54 I Gofer>load 121439760: a(n) Gofer 0x8f4e80 M MetacelloGoferBasedLoaderTest>testNestedLoad1 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4e98 M MetacelloGoferBasedLoaderTest(TestCase)>performTest 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4eb0 M [] in MetacelloGoferBasedLoaderTest(TestCase)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4ed0 M BlockClosure>ensure: 121439724: a(n) BlockClosure 0x8f4eec M MetacelloGoferBasedLoaderTest(TestCase)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4f04 M [] in MetacelloGoferBasedLoaderTest(MetacelloDictionaryRepositoryTest)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4f20 M [] in SystemChangeNotifier>doSilently: 78407412: a(n) SystemChangeNotifier 0x8f4f40 M BlockClosure>ensure: 121438364: a(n) BlockClosure 0x8f4f5c M SystemChangeNotifier>doSilently: 78407412: a(n) SystemChangeNotifier 0x8f4f80 I [] in MetacelloGoferBasedLoaderTest(MetacelloDictionaryRepositoryTest)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4fa0 M BlockClosure>ensure: 121438128: a(n) BlockClosure 0x8f4fc8 I MetacelloGoferBasedLoaderTest(MetacelloDictionaryRepositoryTest)>runCase 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f4fe4 M [] in TestResult>runCase: 104170712: a(n) TestResult 0x8f5000 M BlockClosure>on:do: 121437812: a(n) BlockClosure 0x8f5020 M TestResult>runCase: 104170712: a(n) TestResult 0x8f503c M MetacelloGoferBasedLoaderTest(TestCase)>run: 104569172: a(n) MetacelloGoferBasedLoaderTest 0x8f5058 M TestRunner>runTest: 104102048: a(n) TestRunner 0x8f5074 M [] in TestRunner>runSuite: 104102048: a(n) TestRunner 0x8f50ac M [] in OrderedCollection(Collection)>do:displayingProgress:every: 104171212: a(n) OrderedCollection 0x8f50cc M OrderedCollection>do: 104171212: a(n) OrderedCollection 0x8efb10 M [] in OrderedCollection(Collection)>do:displayingProgress:every: 104171212: a(n) OrderedCollection 0x8efb34 M [] in ProgressInitiationException>defaultMorphicAction 117364284: a(n) ProgressInitiationException 0x8efb50 M BlockClosure>on:do: 117365116: a(n) BlockClosure 0x8efb78 M [] in ProgressInitiationException>defaultMorphicAction 117364284: a(n) ProgressInitiationException 0x8efb98 M BlockClosure>ensure: 117364980: a(n) BlockClosure 0x8efbbc M ProgressInitiationException>defaultMorphicAction 117364284: a(n) ProgressInitiationException 0x8efbd4 M MorphicUIManager>progressInitiationExceptionDefaultAction: 80294140: a(n) MorphicUIManager 0x8efbf0 M ProgressInitiationException>defaultAction 117364284: a(n) ProgressInitiationException 0x8efc0c M UndefinedObject>handleSignal: 78381060: a(n) UndefinedObject 0x8efc2c M MethodContext(ContextPart)>handleSignal: 104675620: a(n) MethodContext 0x8efc48 M ProgressInitiationException(Exception)>signal 117364284: a(n) ProgressInitiationException 0x8efc60 M ProgressInitiationException>display:at:from:to:during: 117364284: a(n) ProgressInitiationException 0x8efc8c M ProgressInitiationException class>display:at:from:to:during: 80856472: a(n) ProgressInitiationException class 0x8efcb8 M ByteString(String)>displayProgressAt:from:to:during: 89108292: a(n) ByteString 0x8efcec M OrderedCollection(Collection)>do:displayingProgress:every: 104171212: a(n) OrderedCollection 0x8efd10 M OrderedCollection(Collection)>do:displayingProgress: 104171212: a(n) OrderedCollection 0x8efd40 I [] in TestRunner>basicRunSuite:do: 104102048: a(n) TestRunner 0x8efd60 M BlockClosure>ensure: 117364072: a(n) BlockClosure 0x8efd84 I TestRunner>basicRunSuite:do: 104102048: a(n) TestRunner 0x8efdac I TestRunner>runSuite: 104102048: a(n) TestRunner 0x8efdc8 M TestRunner>runAll 104102048: a(n) TestRunner 0x8efde8 I PluggableButtonMorph>performAction 104128960: a(n) PluggableButtonMorph 0x8efe04 M [] in PluggableButtonMorph>mouseUp: 104128960: a(n) PluggableButtonMorph 0x8efe28 M Array(SequenceableCollection)>do: 104170568: a(n) Array 0x8efe48 M PluggableButtonMorph>mouseUp: 104128960: a(n) PluggableButtonMorph 0x8efe64 M PluggableButtonMorph(Morph)>handleMouseUp: 104128960: a(n) PluggableButtonMorph 0x8efe80 M MouseButtonEvent>sentTo: 104170528: a(n) MouseButtonEvent 0x8efe9c M PluggableButtonMorph(Morph)>handleEvent: 104128960: a(n) PluggableButtonMorph 0x8efeb8 M PluggableButtonMorph(Morph)>handleFocusEvent: 104128960: a(n) PluggableButtonMorph 0x8efee0 M [] in HandMorph>sendFocusEvent:to:clear: 79625104: a(n) HandMorph 0x8efefc M [] in PasteUpMorph>becomeActiveDuring: 80073648: a(n) PasteUpMorph 0x8eff18 M BlockClosure>on:do: 104170476: a(n) BlockClosure 0x8eff44 M PasteUpMorph>becomeActiveDuring: 80073648: a(n) PasteUpMorph 0x8eff68 M HandMorph>sendFocusEvent:to:clear: 79625104: a(n) HandMorph 0x8eff90 M HandMorph>sendEvent:focus:clear: 79625104: a(n) HandMorph 0x8effb4 M HandMorph>sendMouseEvent: 79625104: a(n) HandMorph 0x8effd8 M HandMorph>handleEvent: 79625104: a(n) HandMorph 0x8f0004 M HandMorph>processEvents 79625104: a(n) HandMorph 0x8f001c M [] in WorldState>doOneCycleNowFor: 80242024: a(n) WorldState 0x8f0040 M Array(SequenceableCollection)>do: 78394416: a(n) Array 0x8f005c M WorldState>handsDo: 80242024: a(n) WorldState 0x8f0078 M WorldState>doOneCycleNowFor: 80242024: a(n) WorldState 0x8f0094 M WorldState>doOneCycleFor: 80242024: a(n) WorldState 0x8f00b0 M PasteUpMorph>doOneCycle 80073648: a(n) PasteUpMorph 0x8f00d0 I [] in Project class>? 80481880: a(n) Project class 80528720 s [] in BlockClosure>? On Tue, Jun 28, 2011 at 9:20 PM, Brian Tabone <[hidden email]> wrote:
-- Mariano http://marianopeck.wordpress.com |
In reply to this post by Marcus Denker-4
On Jun 28, 2011, at 9:47 PM, Mariano Martinez Peck wrote: > Yes, can you try with the last one from http://www.mirandabanda.org/files/Cog/VM/ ? > I will update the VMs of the Pharo one-click later this week. Marcus > On Tue, Jun 28, 2011 at 9:27 PM, Marcus Denker <[hidden email]> wrote: > > On Jun 28, 2011, at 9:20 PM, Brian Tabone wrote: > > > Sven, > > > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. > > I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. > > > The VM seems to be very old... we need to do these tests with the current code base... > > > -Brian > > > > From: Sven Van Caekenberghe <[hidden email]> > > To: [hidden email] > > Sent: Tuesday, June 28, 2011 1:48 PM > > Subject: Re: [Pharo-project] Re Please test Pharo 1.3! > > > > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > > > >> > > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > > >> > > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > > >>> > > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > >>> > > >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > > >> > > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > > >> > > >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? > > >> > > > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. > > > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > > > Brian, > > > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? > > > > Does the whole test suite always fail at the same test ? > > > > Sven > > > > > > > > > > > > <Pharo 1.3 test without Zn.JPG><Pharo 1.3 VM crash.JPG><crash.dmp> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Is the end result going to be the same as copying the contents of /coglinux/lib/squeak/3.9-7/ into the one-click's Contents/Linux directory? There is other stuff under Resources, but (now that I actually look at it), it appears to be MacOS related??
I don't want to rush it, make a mess, and start reporting "bugs" that the result of my own misdeeds. Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Marcus Denker [[hidden email]] Sent: Tuesday, June 28, 2011 3:50 PM To: [hidden email] Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On Jun 28, 2011, at 9:47 PM, Mariano Martinez Peck wrote: > Yes, can you try with the last one from http://www.mirandabanda.org/files/Cog/VM/ ? > I will update the VMs of the Pharo one-click later this week. Marcus > On Tue, Jun 28, 2011 at 9:27 PM, Marcus Denker <[hidden email]> wrote: > > On Jun 28, 2011, at 9:20 PM, Brian Tabone wrote: > > > Sven, > > > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. > > I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. > > > The VM seems to be very old... we need to do these tests with the current code base... > > > -Brian > > > > From: Sven Van Caekenberghe <[hidden email]> > > To: [hidden email] > > Sent: Tuesday, June 28, 2011 1:48 PM > > Subject: Re: [Pharo-project] Re Please test Pharo 1.3! > > > > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > > > >> > > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > > >> > > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > > >>> > > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > > >>> > > >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > > >> > > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > > >> > > >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? > > >> > > > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. > > > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > > > Brian, > > > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? > > > > Does the whole test suite always fail at the same test ? > > > > Sven > > > > > > > > > > > > <Pharo 1.3 test without Zn.JPG><Pharo 1.3 VM crash.JPG><crash.dmp> > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
In reply to this post by Marcus Denker-4
Marcus, I have run all tests against http://www.mirandabanda.org/files/Cog/VM/VM.r2437/nsvmwin.zip, crashed the VM. I tried running Zn* and 151 ran and passed. I then tested all but the Zn* and got further along but had another VM crash. crash2.dmp and Pharo 1.3 VM crash 2 are from this last run. VM info: Cog VM 4.0.0 (release) from Jun 19, 2011 Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) -Brian From: Marcus Denker <[hidden email]> To: [hidden email]; Brian Tabone <[hidden email]> Sent: Tuesday, June 28, 2011 2:27 PM Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On Jun 28, 2011, at 9:20 PM, Brian Tabone wrote: > Sven, > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. > I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. > The VM seems to be very old... we need to do these tests with the current code base... > -Brian > > From: Sven Van Caekenberghe <[hidden email]> > To: [hidden email] > Sent: Tuesday, June 28, 2011 1:48 PM > Subject: Re: [Pharo-project] Re Please test Pharo 1.3! > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > >> > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > >> > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > >>> > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > >>> > >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > >> > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > >> > >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? > >> > > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > Brian, > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? > > Does the whole test suite always fail at the same test ? > > Sven > > > > > > <Pharo 1.3 test without Zn.JPG><Pharo 1.3 VM crash.JPG><crash.dmp> -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. crash.dmp (16K) Download Attachment Pharo 1.3 VM crash with latest CogVM.JPG (225K) Download Attachment Pharo 1.3 VM crash 2 with latest VM.JPG (233K) Download Attachment crash2.dmp (31K) Download Attachment |
Note the double slash in the path the dump file (see CogVM.jpg). Is it real, or perhaps just introduced as the path is assembled to display in the dialog? Since you are posting files, they are presumably getting written to disk somewhere.
________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Brian Tabone [[hidden email]] Sent: Tuesday, June 28, 2011 4:11 PM To: [hidden email] Subject: Re: [Pharo-project] Re Please test Pharo 1.3! Marcus, I have run all tests against http://www.mirandabanda.org/files/Cog/VM/VM.r2437/nsvmwin.zip, crashed the VM. I tried running Zn* and 151 ran and passed. I then tested all but the Zn* and got further along but had another VM crash. crash2.dmp and Pharo 1.3 VM crash 2 are from this last run. VM info: Cog VM 4.0.0 (release) from Jun 19, 2011 Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) -Brian ________________________________ From: Marcus Denker <[hidden email]> To: [hidden email]; Brian Tabone <[hidden email]> Sent: Tuesday, June 28, 2011 2:27 PM Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On Jun 28, 2011, at 9:20 PM, Brian Tabone wrote: > Sven, > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. > I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. > The VM seems to be very old... we need to do these tests with the current code base... > -Brian > > From: Sven Van Caekenberghe <[hidden email]<mailto:[hidden email]>> > To: [hidden email]<mailto:[hidden email]> > Sent: Tuesday, June 28, 2011 1:48 PM > Subject: Re: [Pharo-project] Re Please test Pharo 1.3! > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > >> > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > >> > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > >>> > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > >>> > >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > >> > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > >> > >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? > >> > > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > Brian, > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? > > Does the whole test suite always fail at the same test ? > > Sven > > > > > > <Pharo 1.3 test without Zn.JPG><Pharo 1.3 VM crash.JPG><crash.dmp> -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
In reply to this post by Brian Tabone-2
On Tue, Jun 28, 2011 at 1:11 PM, Brian Tabone <[hidden email]> wrote:
Why are you using the Newspeak VM to run Pharo?
-- best, Eliot |
In reply to this post by Marcus Denker-4
On Jun 28, 2011, at 10:07 PM, Schwab,Wilhelm K wrote: > Is the end result going to be the same as copying the contents of /coglinux/lib/squeak/3.9-7/ into the one-click's Contents/Linux directory? There is other stuff under Resources, but (now that I actually look at it), it appears to be MacOS related?? > > I don't want to rush it, make a mess, and start reporting "bugs" that the result of my own misdeeds. > We need to provide the right setup out of the box. This "dowload that vm there, but change this and take into account that" never work and will never work. We will get there... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
In reply to this post by Schwab,Wilhelm K
Looks like the crash handler is injecting that extra backslash in the filename, the crash dump files are making it on to disk without issue. -Brian From: "Schwab,Wilhelm K" <[hidden email]> To: "[hidden email]" <[hidden email]>; Brian Tabone <[hidden email]> Sent: Tuesday, June 28, 2011 3:25 PM Subject: RE: [Pharo-project] Re Please test Pharo 1.3! Note the double slash in the path the dump file (see CogVM.jpg). Is it real, or perhaps just introduced as the path is assembled to display in the dialog? Since you are posting files, they are presumably getting written to disk somewhere. ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Brian Tabone [[hidden email]] Sent: Tuesday, June 28, 2011 4:11 PM To: [hidden email] Subject: Re: [Pharo-project] Re Please test Pharo 1.3! Marcus, I have run all tests against http://www.mirandabanda.org/files/Cog/VM/VM.r2437/nsvmwin.zip, crashed the VM. I tried running Zn* and 151 ran and passed. I then tested all but the Zn* and got further along but had another VM crash. crash2.dmp and Pharo 1.3 VM crash 2 are from this last run. VM info: Cog VM 4.0.0 (release) from Jun 19, 2011 Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) -Brian ________________________________ From: Marcus Denker <[hidden email]> To: [hidden email]; Brian Tabone <[hidden email]> Sent: Tuesday, June 28, 2011 2:27 PM Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On Jun 28, 2011, at 9:20 PM, Brian Tabone wrote: > Sven, > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all (and only) Zn* tests and 151 ran and 151 passed. > I then ran all tests except Zn* and it ran much further up until the VM crashed. crash snapshots and the small dmp file attached. > The VM seems to be very old... we need to do these tests with the current code base... > -Brian > > From: Sven Van Caekenberghe <[hidden email]<mailto:[hidden email]>> > To: [hidden email]<mailto:[hidden email]> > Sent: Tuesday, June 28, 2011 1:48 PM > Subject: Re: [Pharo-project] Re Please test Pharo 1.3! > > > On 28 Jun 2011, at 19:54, Marcus Denker wrote: > > > > > On Jun 28, 2011, at 7:50 PM, Sven Van Caekenberghe wrote: > > > >> > >> On 28 Jun 2011, at 18:35, Brian Tabone wrote: > >> > >>> I ran the full test suite on Pharo 1.3 (one click image) on Win 7 64, and it appears that the image hangs up on a socket read. Below is some information from the F2 console window, I dumped stacks, processes, primitives, and socket info. The image does not respond to alt - . (no user interrupt window ever displays). Attached is a screenshot of the image where it hangs. The VM reports its version as: > >>> > >>> Teleplace VM 1.0.15 (release) from Oct 4, 2010 > >>> Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > >>> > >>> Sorry if this is a duplicate or known issue, just figured I should be on the safe side and report it. > >> > >> It seems that ZnUserAgentTests>>#testDelete fails for you. > >> > >> It works for me and for the regular integration/build servers, does the windows slave pass this test ? > >> > > The windows slave does not yet run tests.. we will add that ASAP now that it is up and running. > > OK, Marcus, I don't want to push, you'll let us know when it is ready. > > Brian, > > Does the ZnUserAgentTests>>#testDelete succeed when you run it in isolation ? > > Does the whole test suite always fail at the same test ? > > Sven > > > > > > <Pharo 1.3 test without Zn.JPG><Pharo 1.3 VM crash.JPG><crash.dmp> -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
In reply to this post by Marcus Denker-4
Marcus,
I'm happy to wait, precisely because it is VERY easy to make a mess of things by copying files into unfamiliar folders - that's why I asked :) Take your time, and THANKS to all who bring us the CI servers! Bill ________________________________________ From: [hidden email] [[hidden email]] On Behalf Of Marcus Denker [[hidden email]] Sent: Tuesday, June 28, 2011 4:30 PM To: [hidden email] Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On Jun 28, 2011, at 10:07 PM, Schwab,Wilhelm K wrote: > Is the end result going to be the same as copying the contents of /coglinux/lib/squeak/3.9-7/ into the one-click's Contents/Linux directory? There is other stuff under Resources, but (now that I actually look at it), it appears to be MacOS related?? > > I don't want to rush it, make a mess, and start reporting "bugs" that the result of my own misdeeds. > We need to provide the right setup out of the box. This "dowload that vm there, but change this and take into account that" never work and will never work. We will get there... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
In reply to this post by Eliot Miranda-2
Eliot, Running on the newest cogwin vm I could find (http://www.mirandabanda.org/files/Cog/VM/VM.r2434/cogwin.zip), I still get the lockup in the VM (stack dump below) when I run all tests. When I turn off Zn* and run all other tests, I get a crash (snapshot and dmp attached). VM version info: Cog VM 4.0.0 (release) from Jun 17 2011 Compiler: gcc 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) -Brian 0x90cf1c M Semaphore>critical: 708356544: a(n) Semaphore 0x90cf38 M DelayWaitTimeout(Delay)>unschedule 729655500: a(n) DelayWaitTimeout 0x90cf50 M [] in DelayWaitTimeout>wait 729655500: a(n) DelayWaitTimeout 0x90cf70 M BlockClosure>ensure: 729655620: a(n) BlockClosure 0x90cf8c M DelayWaitTimeout>wait 729655500: a(n) DelayWaitTimeout 0x90cfa8 M Semaphore>waitTimeoutMSecs: 729655068: a(n) Semaphore 0x90cfd4 M Socket>waitForConnectionFor:ifTimedOut: 729655044: a(n) Socket 0x90cffc I Socket>waitForAcceptFor: 729655044: a(n) Socket 0x90d028 I ZnMultiThreadedServer>serveConnectionsOn: 729654372: a(n) ZnMultiThreadedServer 0x90d04c I [] in ZnMultiThreadedServer>listenLoop 729654372: a(n) ZnMultiThreadedServer 0x90d06c M BlockClosure>ifCurtailed: 729655324: a(n) BlockClosure 0x90d090 I ZnMultiThreadedServer>listenLoop 729654372: a(n) ZnMultiThreadedServer 0x90d0b0 I [] in ZnMultiThreadedServer(ZnSingleThreadedServer)>start 729654372: a(n) ZnMultiThreadedServer 0x90d0d0 I [] in BlockClosure>newProcess 729654652: a(n) BlockClosure From: Eliot Miranda <[hidden email]> To: [hidden email]; Brian Tabone <[hidden email]> Sent: Tuesday, June 28, 2011 3:25 PM Subject: Re: [Pharo-project] Re Please test Pharo 1.3! On Tue, Jun 28, 2011 at 1:11 PM, Brian Tabone <[hidden email]> wrote:
Why are you using the Newspeak VM to run Pharo?
-- best, Eliot crash.dmp (32K) Download Attachment Pharo 1.3 VM crash on cogwin latest.JPG (205K) Download Attachment |
In reply to this post by Brian Tabone-2
On 28 June 2011 22:20, Brian Tabone <[hidden email]> wrote:
> Sven, > > I have now tried ZnUserAgentTests>>#testDelete by itself and it ran and > succeeded, I then ran all ZnUserAgentTests and it passed. I then ran all > (and only) Zn* tests and 151 ran and 151 passed. > I then ran all tests except Zn* and it ran much further up until the VM > crashed. crash snapshots and the small dmp file attached. > Yes, a well known crash with 0x936f6c M CompiledMethod(Object)>becomeForward: 123450824: a(n) CompiledMethod > -Brian -- Best regards, Igor Stasenko AKA sig. |
I tried to run pharo-1.3 image on windows using this VM:
https://pharo-ic.lille.inria.fr/hudson/job/CogWin32/ and yes, it hangs (with 100% cpu load) on following: 0x19d00c M Semaphore>critical: 287877560: a(n) Semaphore 0x19d028 M DelayWaitTimeout(Delay)>schedule 309700876: a(n) DelayWaitTimeout 0x19d040 M [] in DelayWaitTimeout>wait 309700876: a(n) DelayWaitTimeout 0x19d060 M BlockClosure>ensure: 309700996: a(n) BlockClosure 0x19d07c M DelayWaitTimeout>wait 309700876: a(n) DelayWaitTimeout 0x19d098 M Semaphore>waitTimeoutMSecs: 309171644: a(n) Semaphore 0x19d0c4 M Socket>waitForConnectionFor:ifTimedOut: 309171620: a(n) Socket 0x19d0e4 M Socket>waitForAcceptFor: 309171620: a(n) Socket 0x19d108 M ZnMultiThreadedServer>serveConnectionsOn: 309170948: a(n) ZnMultiThreadedServer 0x19d12c I [] in ZnMultiThreadedServer>listenLoop 309170948: a(n) ZnMultiThreadedServer 0x19d14c M BlockClosure>ifCurtailed: 309171900: a(n) BlockClosure 0x19d170 I ZnMultiThreadedServer>listenLoop 309170948: a(n) ZnMultiThreadedServer 0x19d190 I [] in ZnMultiThreadedServer(ZnSingleThreadedServer)>start 309170948: a(n) ZnMultiThreadedServer 0x19d1b0 I [] in BlockClosure>newProcess 309171228: a(n) BlockClosure so this is not a problem with VM, since it responding but something with ZnServerYaddaYadda -- Best regards, Igor Stasenko AKA sig. |
Spending 100% CPU in delay wait sounds rather weird, doesn't it ?
Probably my miss interpretation of stack below... Nicolas 2011/6/29 Igor Stasenko <[hidden email]>: > I tried to run pharo-1.3 image on windows using this VM: > https://pharo-ic.lille.inria.fr/hudson/job/CogWin32/ > > and yes, it hangs (with 100% cpu load) on following: > > 0x19d00c M Semaphore>critical: 287877560: a(n) Semaphore > 0x19d028 M DelayWaitTimeout(Delay)>schedule 309700876: a(n) DelayWaitTimeout > 0x19d040 M [] in DelayWaitTimeout>wait 309700876: a(n) DelayWaitTimeout > 0x19d060 M BlockClosure>ensure: 309700996: a(n) BlockClosure > 0x19d07c M DelayWaitTimeout>wait 309700876: a(n) DelayWaitTimeout > 0x19d098 M Semaphore>waitTimeoutMSecs: 309171644: a(n) Semaphore > 0x19d0c4 M Socket>waitForConnectionFor:ifTimedOut: 309171620: a(n) Socket > 0x19d0e4 M Socket>waitForAcceptFor: 309171620: a(n) Socket > 0x19d108 M ZnMultiThreadedServer>serveConnectionsOn: 309170948: a(n) > ZnMultiThreadedServer > 0x19d12c I [] in ZnMultiThreadedServer>listenLoop 309170948: a(n) > ZnMultiThreadedServer > 0x19d14c M BlockClosure>ifCurtailed: 309171900: a(n) BlockClosure > 0x19d170 I ZnMultiThreadedServer>listenLoop 309170948: a(n) > ZnMultiThreadedServer > 0x19d190 I [] in ZnMultiThreadedServer(ZnSingleThreadedServer)>start > 309170948: a(n) ZnMultiThreadedServer > 0x19d1b0 I [] in BlockClosure>newProcess 309171228: a(n) BlockClosure > > so this is not a problem with VM, since it responding but something > with ZnServerYaddaYadda > > > -- > Best regards, > Igor Stasenko AKA sig. > > |
Free forum by Nabble | Edit this page |