Re: [Pharo-project] Re Please test Pharo 1.3!
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. -- 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 <sven@beta9.be> To: Pharo-project@lists.gforge.inria.fr 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
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 <brian_tabone@yahoo.com>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.
-Brian
------------------------------ *From:* Sven Van Caekenberghe <sven@beta9.be> *To:* Pharo-project@lists.gforge.inria.fr *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
-- Mariano http://marianopeck.wordpress.com
On 28 June 2011 22:20, Brian Tabone <brian_tabone@yahoo.com> 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 <siguctua@gmail.com>:
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.
On 29 June 2011 01:37, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:
Spending 100% CPU in delay wait sounds rather weird, doesn't it ? Probably my miss interpretation of stack below...
Well, it could be something else. i just see the CPU load from VM which completely takes one core. Perhaps the semaphore wait primitive failing and we got a tight loop.
Nicolas
2011/6/29 Igor Stasenko <siguctua@gmail.com>:
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.
-- Best regards, Igor Stasenko AKA sig.
participants (6)
-
Brian Tabone -
Igor Stasenko -
Marcus Denker -
Mariano Martinez Peck -
Nicolas Cellier -
Sven Van Caekenberghe