[Pharo-project] Zinc crashing image at start up
Hi I have now had two images rendered unusable because Zinc crashes them at start up. Debug log attached. Cheers Philippe
Looks like it tries to destroy socket which were left from previous session, and of course fails because in newly started image the socket handle invalid. On 2 September 2011 14:26, Lukas Renggli <renggli@gmail.com> wrote:
I have now had two images rendered unusable because Zinc crashes them at start up. Debug log attached.
+1, I had a similar problem at some point from an image built on Jenkins.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko AKA sig.
On 2 September 2011 17:27, Philippe Marschall <kustos@gmx.net> wrote:
On 02.09.2011 15:39, Igor Stasenko wrote:
Looks like it tries to destroy socket which were left from previous session, and of course fails because in newly started image the socket handle invalid.
Sure, but that should signal #primitiveFailed, not segfault the vm.
according to log, there is a primitive fail. do you have a crash.dmp log?
Cheers Philippe
-- Best regards, Igor Stasenko AKA sig.
On 02.09.2011 17:19, Igor Stasenko wrote:
On 2 September 2011 17:27, Philippe Marschall <kustos@gmx.net> wrote:
On 02.09.2011 15:39, Igor Stasenko wrote:
Looks like it tries to destroy socket which were left from previous session, and of course fails because in newly started image the socket handle invalid.
Sure, but that should signal #primitiveFailed, not segfault the vm.
according to log, there is a primitive fail. do you have a crash.dmp log?
No
On 3 September 2011 12:57, Philippe Marschall <kustos@gmx.net> wrote:
On 02.09.2011 17:19, Igor Stasenko wrote:
On 2 September 2011 17:27, Philippe Marschall <kustos@gmx.net> wrote:
On 02.09.2011 15:39, Igor Stasenko wrote:
Looks like it tries to destroy socket which were left from previous session, and of course fails because in newly started image the socket handle invalid.
Sure, but that should signal #primitiveFailed, not segfault the vm.
according to log, there is a primitive fail. do you have a crash.dmp log?
No
just want to clear, is it segfaults or just quits because of error at startup? -- Best regards, Igor Stasenko AKA sig.
On 03.09.2011 13:57, Igor Stasenko wrote:
On 3 September 2011 12:57, Philippe Marschall <kustos@gmx.net> wrote:
On 02.09.2011 17:19, Igor Stasenko wrote:
On 2 September 2011 17:27, Philippe Marschall <kustos@gmx.net> wrote:
On 02.09.2011 15:39, Igor Stasenko wrote:
Looks like it tries to destroy socket which were left from previous session, and of course fails because in newly started image the socket handle invalid.
Sure, but that should signal #primitiveFailed, not segfault the vm.
according to log, there is a primitive fail. do you have a crash.dmp log?
No
just want to clear, is it segfaults or just quits because of error at startup?
Not sure, how can I tell the difference? Cheers Philippe
On 02 Sep 2011, at 13:26, Lukas Renggli wrote:
+1, I had a similar problem at some point from an image built on Jenkins.
The current version of ZnMultiThreadedServer does not hold references to all the connections (worker processes) it creates. This has several implications. A running server that is #register-ed will receive #start/#stop on image save/startup and will close/reopen its server socket correctly. However, it (currently) cannot do the same for (kept-alive) connections with open sockets in worker processes. Hence it might happen occasionally that such processes survive and keep working with dead connections/sockets. Apparently this now leads to a crash rather than a normal error. It would be better if this were prevented. I will have a look to see if I can keep track of these connections and worker processes in a weak data structure so that they can be managed better. The workaround (this is what I do) is not to save images with working server(s) and to start the server(s) from the startup script. See for example: http://zn.stfx.eu/zn/pharo-server.sh Sven
It would be better if this were prevented. I will have a look to see if I can keep track of these connections and worker processes in a weak data structure so that they can be managed better.
Better no weak data structures. The listener process could more efficiently cleanup unused workers, no?
The workaround (this is what I do) is not to save images with working server(s) and to start the server(s) from the startup script. See for example: http://zn.stfx.eu/zn/pharo-server.sh
Doesn't really work in many production setups and/or if you want to use Zinc during development. Lukas -- Lukas Renggli www.lukas-renggli.ch
what you can do is at image startup , is invalidate all sockets. On 3 September 2011 00:01, Lukas Renggli <renggli@gmail.com> wrote:
It would be better if this were prevented. I will have a look to see if I can keep track of these connections and worker processes in a weak data structure so that they can be managed better.
Better no weak data structures. The listener process could more efficiently cleanup unused workers, no?
The workaround (this is what I do) is not to save images with working server(s) and to start the server(s) from the startup script. See for example: http://zn.stfx.eu/zn/pharo-server.sh
Doesn't really work in many production setups and/or if you want to use Zinc during development.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Best regards, Igor Stasenko AKA sig.
On 02 Sep 2011, at 23:01, Lukas Renggli wrote:
It would be better if this were prevented. I will have a look to see if I can keep track of these connections and worker processes in a weak data structure so that they can be managed better.
Better no weak data structures. The listener process could more efficiently cleanup unused workers, no?
Yeah, the idea of the weak data structure was to have a fallback to the current situation in case something went wrong when explicitely managing the connections. The current implementation now uses a normal ordered collection. It passes all tests. Note that this version of Zn is way further than what is in 1.3, it also contains a brand new client I am working on and some important code already uses this new client. This needs some more testing before it can be included I guess (although it works for me). I know the Seaside builds use the latest Zn. Igor, as far as I could see, I only got nice PrimitiveFailed's. Sven A new version of Zinc-HTTP was added to project Zinc HTTP Components: http://www.squeaksource.com/ZincHTTPComponents/Zinc-HTTP-SvenVanCaekenberghe... ==================== Summary ==================== Name: Zinc-HTTP-SvenVanCaekenberghe.189 Author: SvenVanCaekenberghe Time: 4 September 2011, 3:20:15 pm UUID: b4f2d979-0097-4dc8-bde9-23edda15a3f9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.188 Added some new internal functionality to ZnMultiThreadedServer: To keep track of all its open client connections (socket streams) (#socketStreamOn: and #closeSocketStream) so that they can all be force closed (#closeAllConnections) when the server stops (#stop). This is necessary because on image save the worker processes and socket streams are frozen and fail when they start up afterwards due to illegal socket handles. Note that #readRequestSafely: was extended and #writeResponseSafely:on: was introduced to handle several exceptions, most notably PrimitiveFailed, in the situation where a socket stream is force closed on a live process using that stream. This can be observed in #testTimeout. The timeouts on reading/writing socket streams take care of closing connections that are kept open too long. Maybe the server side timeouts should be even shorter to conserve resources.
Yeah, the idea of the weak data structure was to have a fallback to the current situation in case something went wrong when explicitely managing the connections. The current implementation now uses a normal ordered collection. It passes all tests.
Sounds great!
Note that this version of Zn is way further than what is in 1.3, it also contains a brand new client I am working on and some important code already uses this new client. This needs some more testing before it can be included I guess (although it works for me). I know the Seaside builds use the latest Zn.
Yes, I update Zn for the Seaside build to the latest version. Lukas -- Lukas Renggli www.lukas-renggli.ch
Hi Sven, There seems to be a new problem with Zinc when building Seaside. Not sure what it is: + build.sh -i seaside3 -s seaside3-zinc -o seaside3-zinc build.sh: Execution aborted (/usr/local/bin/cog) THERE_BE_DRAGONS_HERE PrimitiveFailed: primitive #signal in a Semaphore() failed 4 September 2011 5:53:45 pm VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog.35] Image: Pharo1.3 [Latest update: #13298] Semaphore(Object)>>primitiveFailed: Receiver: a Semaphore() Arguments and temporary variables: selector: #signal Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 1073741823 Semaphore(Object)>>primitiveFailed Receiver: a Semaphore() Arguments and temporary variables: Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 1073741823 Semaphore>>signal Receiver: a Semaphore() Arguments and temporary variables: Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 1073741823 [FinishedDelay := self. TimingSemaphore signal] in DelayWaitTimeout(Delay)>>unschedule Receiver: a DelayWaitTimeout(282210 msecs) Arguments and temporary variables: Receiver's instance variables: delayDuration: 282210 resumptionTime: nil delaySemaphore: a Semaphore() beingWaitedOn: false process: a Process in nil expired: true [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: Receiver: a Semaphore() Arguments and temporary variables: <<error during printing> Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 0 BlockClosure>>ensure: Receiver: [caught := true. self wait. blockValue := mutuallyExcludedBlock value] Arguments and temporary variables: aBlock: [caught ifTrue: [self signal]] complete: nil returnValue: nil Receiver's instance variables: outerContext: Semaphore>>critical: startpc: 42 numArgs: 0 Semaphore>>critical: Receiver: a Semaphore() Arguments and temporary variables: <<error during printing> Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 0 DelayWaitTimeout(Delay)>>unschedule Receiver: a DelayWaitTimeout(282210 msecs) Arguments and temporary variables: Receiver's instance variables: delayDuration: 282210 resumptionTime: nil delaySemaphore: a Semaphore() beingWaitedOn: false process: a Process in nil expired: true [self unschedule] in DelayWaitTimeout>>wait Receiver: a DelayWaitTimeout(282210 msecs) Arguments and temporary variables: Receiver's instance variables: delayDuration: 282210 resumptionTime: nil delaySemaphore: a Semaphore() beingWaitedOn: false process: a Process in nil expired: true BlockClosure>>ensure: Receiver: [self schedule. beingWaitedOn ifTrue: [delaySemaphore wait] ifFalse: [expired := true...etc... Arguments and temporary variables: aBlock: [self unschedule] complete: true returnValue: true Receiver's instance variables: outerContext: DelayWaitTimeout>>wait startpc: 41 numArgs: 0 DelayWaitTimeout>>wait Receiver: a DelayWaitTimeout(282210 msecs) Arguments and temporary variables: Receiver's instance variables: delayDuration: 282210 resumptionTime: nil delaySemaphore: a Semaphore() beingWaitedOn: false process: a Process in nil expired: true Semaphore>>waitTimeoutMSecs: Receiver: a Semaphore() Arguments and temporary variables: anInteger: 282210 d: a DelayWaitTimeout(282210 msecs) Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 0 Socket>>waitForConnectionFor:ifTimedOut: Receiver: a Socket[waitingForConnection] Arguments and temporary variables: timeout: 300 timeoutBlock: [^ nil] startTime: 3617674 msecsDelta: 300000 msecsEllapsed: 17790 status: 1 Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[230 40 102 78 0 0 0 0 64 77 219 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>waitForAcceptFor: Receiver: a Socket[waitingForConnection] Arguments and temporary variables: timeout: 300 Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[230 40 102 78 0 0 0 0 64 77 219 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(stopped 8080) Arguments and temporary variables: listeningSocket: a Socket[waitingForConnection] stream: nil socket: nil Receiver's instance variables: port: 8080 process: nil serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil lock: a Mutex connections: an OrderedCollection() [[serverSocket isValid ifFalse: [^ self listenLoop]. self serveConnectionsOn: serverSocket] repeat. nil] in ZnMultiThreadedServer>>listenLoop Receiver: a ZnMultiThreadedServer(stopped 8080) Arguments and temporary variables: Receiver's instance variables: port: 8080 process: nil serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil lock: a Mutex connections: an OrderedCollection() BlockClosure>>ifCurtailed: Receiver: [[serverSocket isValid ifFalse: [^ self listenLoop]. self serveConnectionsOn: serverSoc...etc... Arguments and temporary variables: aBlock: [self releaseServerSocket] complete: nil result: nil Receiver's instance variables: outerContext: ZnMultiThreadedServer>>listenLoop startpc: 52 numArgs: 0 ZnMultiThreadedServer>>listenLoop Receiver: a ZnMultiThreadedServer(stopped 8080) Arguments and temporary variables: Receiver's instance variables: port: 8080 process: nil serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil lock: a Mutex connections: an OrderedCollection() [[self listenLoop] repeat. nil] in ZnMultiThreadedServer(ZnSingleThreadedServer)>>start Receiver: a ZnMultiThreadedServer(stopped 8080) Arguments and temporary variables: Receiver's instance variables: port: 8080 process: nil serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil lock: a Mutex connections: an OrderedCollection() [self value. Processor terminateActive] in BlockClosure>>newProcess Receiver: [[self listenLoop] repeat. nil] Arguments and temporary variables: Receiver's instance variables: outerContext: ZnMultiThreadedServer(ZnSingleThreadedServer)>>start startpc: 77 numArgs: 0 --- The full stack --- Semaphore(Object)>>primitiveFailed: Semaphore(Object)>>primitiveFailed Semaphore>>signal [FinishedDelay := self. TimingSemaphore signal] in DelayWaitTimeout(Delay)>>unschedule [caught := true. self wait. blockValue := mutuallyExcludedBlock value] in Semaphore>>critical: BlockClosure>>ensure: Semaphore>>critical: DelayWaitTimeout(Delay)>>unschedule [self unschedule] in DelayWaitTimeout>>wait BlockClosure>>ensure: DelayWaitTimeout>>wait Semaphore>>waitTimeoutMSecs: Socket>>waitForConnectionFor:ifTimedOut: Socket>>waitForAcceptFor: ZnMultiThreadedServer>>serveConnectionsOn: [[serverSocket isValid ifFalse: [^ self listenLoop]. self serveConnectionsOn: serverSocket] repeat. nil] in ZnMultiThreadedServer>>listenLoop BlockClosure>>ifCurtailed: ZnMultiThreadedServer>>listenLoop [[self listenLoop] repeat. nil] in ZnMultiThreadedServer(ZnSingleThreadedServer)>>start [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------------------------------------ Processes and their stacks: Process: a Process in Process>>resume stack: Process>>resume BlockClosure>>forkAt:named: ZnMultiThreadedServer(ZnSingleThreadedServer)>>start ZnZincServerAdaptor>>basicStart [aServerAdaptor basicStart] in WAServerManager>>start: BlockClosure>>ifCurtailed: WAServerManager>>start: ZnZincServerAdaptor(WAServerAdaptor)>>start UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: Compiler class>>evaluate:for:notifying:logged: Compiler class>>evaluate:for:logged: Compiler class>>evaluate:logged: [| chunk | val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. Compiler evaluate: chunk logged: true]] in [:bar | [self atEnd] whileFalse: [bar value: self position. self skipSeparators. [| chunk | val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. Compiler evaluate: chunk logged: true]] on: InMidstOfFileinNotification do: [:ex | ex resume: true]. self skipStyleChunk]. self close] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: BlockClosure>>on:do: [:bar | [self atEnd] whileFalse: [bar value: self position. self skipSeparators. [| chunk | val := (self peekFor: $!) ifTrue: [(Compiler evaluate: self nextChunk logged: false) scanFrom: self] ifFalse: [chunk := self nextChunk. self checkForPreamble: chunk. Compiler evaluate: chunk logged: true]] on: InMidstOfFileinNotification do: [:ex | ex resume: true]. self skipStyleChunk]. self close] in RWBinaryOrTextStream(PositionableStream)>>fileInAnnouncing: NonInteractiveUIManager>>progressInitiationExceptionDefaultAction: ProgressInitiationException>>defaultAction UndefinedObject>>handleSignal: ProgressInitiationException(Exception)>>signal ------------------------------ Process: a Process in Delay class>>handleTimerEvent stack: Delay class>>handleTimerEvent Delay class>>runTimerEventLoop [self runTimerEventLoop] in Delay class>>startTimerEventLoop [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------ Process: a Process in SmalltalkImage>>lowSpaceWatcher stack: SmalltalkImage>>lowSpaceWatcher [self lowSpaceWatcher] in SmalltalkImage>>installLowSpaceWatcher [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------ Process: a Process in ProcessorScheduler class>>idleProcess stack: ProcessorScheduler class>>idleProcess [self idleProcess] in ProcessorScheduler class>>startUp [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------ Process: a Process in [delaySemaphore wait] in Delay>>wait stack: [delaySemaphore wait] in Delay>>wait BlockClosure>>ifCurtailed: Delay>>wait InputEventPollingFetcher>>waitForInput InputEventPollingFetcher(InputEventFetcher)>>eventLoop [self eventLoop] in InputEventPollingFetcher(InputEventFetcher)>>installEventLoop [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------ Process: a Process in WeakArray class>>finalizationProcess stack: WeakArray class>>finalizationProcess [self finalizationProcess] in WeakArray class>>restartFinalizationProcess [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------ Process: a Process in [delaySemaphore wait] in Delay>>wait stack: [delaySemaphore wait] in Delay>>wait BlockClosure>>ifCurtailed: Delay>>wait GRPharoPlatform>>cometWait CTPusher class>>pingProcess [[self pingProcess] repeat. nil] in CTPusher class>>startUp [self value. Processor terminateActive] in BlockClosure>>newProcess ------------------------------ Process: a Process in nil stack: Array(SequenceableCollection)>>do: [:logger | logger nextPutAll: 'Processes and their stacks: '; cr. Process allInstances do: [:each | | ctx | logger nextPutAll: 'Process: '; print: each; cr; nextPutAll: ' stack:'; cr; cr. ctx := each isActiveProcess ifTrue: [thisContext sender] ifFalse: [each suspendedContext]. ctx ifNotNil: [(ctx stackOfSize: 20) do: [:s | logger print: s; cr]]. logger nextPutAll: '------------------------------'; cr; cr]] in [Smalltalk logError: aString inContext: aContext. Smalltalk logDuring: [:logger | logger nextPutAll: 'Processes and their stacks: '; cr. Process allInstances do: [:each | | ctx | logger nextPutAll: 'Process: '; print: each; cr; nextPutAll: ' stack:'; cr; cr. ctx := each isActiveProcess ifTrue: [thisContext sender] ifFalse: [each suspendedContext]. ctx ifNotNil: [(ctx stackOfSize: 20) do: [:s | logger print: s; cr]]. logger nextPutAll: '------------------------------'; cr; cr]]] in NonInteractiveUIManager>>quitFrom:withMessage: [logStream := self openLog. aMonadicBlock value: logStream] in SmalltalkImage>>logDuring: BlockClosure>>ensure: SmalltalkImage>>logDuring: [Smalltalk logError: aString inContext: aContext. Smalltalk logDuring: [:logger | logger nextPutAll: 'Processes and their stacks: '; cr. Process allInstances do: [:each | | ctx | logger nextPutAll: 'Process: '; print: each; cr; nextPutAll: ' stack:'; cr; cr. ctx := each isActiveProcess ifTrue: [thisContext sender] ifFalse: [each suspendedContext]. ctx ifNotNil: [(ctx stackOfSize: 20) do: [:s | logger print: s; cr]]. logger nextPutAll: '------------------------------'; cr; cr]]] in NonInteractiveUIManager>>quitFrom:withMessage: BlockClosure>>ensure: NonInteractiveUIManager>>quitFrom:withMessage: NonInteractiveUIManager>>unhandledErrorDefaultAction: UnhandledError>>defaultAction UndefinedObject>>handleSignal: UnhandledError(Exception)>>signal UnhandledError class>>signalForException: PrimitiveFailed(Error)>>defaultAction UndefinedObject>>handleSignal: PrimitiveFailed(Exception)>>signal PrimitiveFailed class(SelectorException class)>>signalFor: Semaphore(Object)>>primitiveFailed: Semaphore(Object)>>primitiveFailed Semaphore>>signal ------------------------------ /srv/jenkins/builder/build.sh: line 170: 4882 Killed exec "$PHARO_VM" $PHARO_PARAM "$OUTPUT_IMAGE" "$OUTPUT_SCRIPT" Build step 'Execute shell' marked build as failure [CHECKSTYLE] Skipping publisher since build result is FAILURE Archiving artifacts Recording test results Finished: FAILURE On 4 September 2011 16:33, Lukas Renggli <renggli@gmail.com> wrote:
Yeah, the idea of the weak data structure was to have a fallback to the current situation in case something went wrong when explicitely managing the connections. The current implementation now uses a normal ordered collection. It passes all tests.
Sounds great!
Note that this version of Zn is way further than what is in 1.3, it also contains a brand new client I am working on and some important code already uses this new client. This needs some more testing before it can be included I guess (although it works for me). I know the Seaside builds use the latest Zn.
Yes, I update Zn for the Seaside build to the latest version.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
-- Lukas Renggli www.lukas-renggli.ch
Lukas, On 04 Sep 2011, at 18:17, Lukas Renggli wrote:
There seems to be a new problem with Zinc when building Seaside. Not sure what it is:
Strange indeed. I just downloaded the lastest base seaside3 image from http://jenkins.lukas-renggli.ch and executed the builder/scripts/seaside3-zinc.st code manually and the server started and worked as expected. The PrimitiveFailed seems to be in (server) Socket>>#waitForAcceptFor: but nothing was changed in the code calling that, or in surrounding error handlers. I am correct to assume that the crash is while starting the server ? Or is it later during the save image ? Sven
Strange indeed. I just downloaded the lastest base seaside3 image from http://jenkins.lukas-renggli.ch and executed the builder/scripts/seaside3-zinc.st code manually and the server started and worked as expected.
The strange thing is that it happened in both builds, Seaside 3.0 and 3.1.
The PrimitiveFailed seems to be in (server) Socket>>#waitForAcceptFor: but nothing was changed in the code calling that, or in surrounding error handlers.
I am correct to assume that the crash is while starting the server ? Or is it later during the save image ?
Yes, the stack trace is while starting the server. Lukas -- Lukas Renggli www.lukas-renggli.ch
On 04 Sep 2011, at 20:27, Lukas Renggli wrote:
Strange indeed. I just downloaded the lastest base seaside3 image from http://jenkins.lukas-renggli.ch and executed the builder/scripts/seaside3-zinc.st code manually and the server started and worked as expected.
The strange thing is that it happened in both builds, Seaside 3.0 and 3.1.
Yeah, I saw that too, kind of rules out chance, too bad.
The PrimitiveFailed seems to be in (server) Socket>>#waitForAcceptFor: but nothing was changed in the code calling that, or in surrounding error handlers.
I am correct to assume that the crash is while starting the server ? Or is it later during the save image ?
Yes, the stack trace is while starting the server.
Just looking at the code, I can't think of an explanation (since it worked before). The last diff is pretty small, all in one class. Could it be VM related ? Can I download the exact same VM that you are using, but that would be a linux one I guess ? Maybe I should set up a build process in my virtual Ubuntu but that will take some time. I took the seaside-zinc image but that was the previous one so that didn't help. I want to help but where should I start ? Any suggestions ? Sven
Just looking at the code, I can't think of an explanation (since it worked before). The last diff is pretty small, all in one class.
Could it be VM related ? Can I download the exact same VM that you are using, but that would be a linux one I guess ? Maybe I should set up a build process in my virtual Ubuntu but that will take some time.
I am using an old Cog VM from Eliot's site http://www.mirandabanda.org/files/Cog/VM/VM.r2370/. I haven't updated it for months.
I took the seaside-zinc image but that was the previous one so that didn't help.
I want to help but where should I start ? Any suggestions ?
I don't know. Sorry. Lukas -- Lukas Renggli www.lukas-renggli.ch
On 04 Sep 2011, at 21:33, Lukas Renggli wrote:
Just looking at the code, I can't think of an explanation (since it worked before). The last diff is pretty small, all in one class.
Could it be VM related ? Can I download the exact same VM that you are using, but that would be a linux one I guess ? Maybe I should set up a build process in my virtual Ubuntu but that will take some time.
I am using an old Cog VM from Eliot's site http://www.mirandabanda.org/files/Cog/VM/VM.r2370/. I haven't updated it for months.
I took the seaside-zinc image but that was the previous one so that didn't help.
I want to help but where should I start ? Any suggestions ?
I don't know. Sorry.
Lukas
OK, thanks for the extra info. I'll see what I can do tomorrow, after thinking about this a bit. If I can't reproduce this, I can't debug it. Sven
On 04 Sep 2011, at 22:35, Sven Van Caekenberghe wrote:
OK, thanks for the extra info. I'll see what I can do tomorrow, after thinking about this a bit. If I can't reproduce this, I can't debug it.
I am really very confused and don't understand what is happening, but here is what I found out: Starting from the partial build artifact seaside3.[image|changes] #720 from http://jenkins.lukas-renggli.ch and using the VM http://www.mirandabanda.org/files/Cog/VM/VM.r2370/ on my Ubuntu 11.04 I finally could replicate a problem loading builder/scripts/seaside3-zinc.st. Now the hang (100% cpu, no crash or any log to be seen) only happens in two cases: running from the command line (as in the build script): ./coglinux/bin/squeak -nodisplay -nosound seaside3.image /home/sven/Smalltalk/builder/scripts/seaside3-zinc.st or doing a file in of this file using the File Browser in Pharo. Executing the same code manually (selecting it and performing a doit) works fine. Note to replicate this you have to use a specific version, as in Gofer new squeaksource: 'ZincHTTPComponents'; version: 'Zinc-HTTP-SvenVanCaekenberghe.191'; package: 'Zinc-Seaside'; load. And then starting the Seaside adapter in one go. On Mac OS X, I cannot reproduce this at all. The difference between the working version (188) and the failing ones (up until 191) is very small IMHO, that's what is so strange. So I decided to revert back by pushing down the connection management functionality of ZnMultiThreadedServer to a new subclass called ZnManagingMultiThreadedServer. Now the code difference between working and failing code is even smaller. Note also that the server is just started, it is not yet receiving any connections! Any help would be appreciated ;-) Lukas, I think you could try to rebuild the failing Seaside jobs. Sven
Note to replicate this you have to use a specific version, as in
Gofer new     squeaksource: 'ZincHTTPComponents';     version: 'Zinc-HTTP-SvenVanCaekenberghe.191';     package: 'Zinc-Seaside';     load.
And then starting the Seaside adapter in one go.
On Mac OS X, I cannot reproduce this at all.
With Cog on some systems we had initially problems with Kom because the sockets were closed in a separate thread and we had to wait for that thread to terminate. I don't think Zn has any asynchronous behaviors. Or would it help to wait a second before the image is saved?
So I decided to revert back by pushing down the connection management functionality of ZnMultiThreadedServer to a new subclass called ZnManagingMultiThreadedServer. Now the code difference between working and failing code is even smaller. Note also that the server is just started, it is not yet receiving any connections!
Any help would be appreciated ;-)
Lukas, I think you could try to rebuild the failing Seaside jobs.
Thank you for looking into this. The jobs are rebuilding right now. Lukas -- Lukas Renggli www.lukas-renggli.ch
On Mon, Sep 5, 2011 at 5:46 AM, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 04 Sep 2011, at 22:35, Sven Van Caekenberghe wrote:
OK, thanks for the extra info. I'll see what I can do tomorrow, after thinking about this a bit. If I can't reproduce this, I can't debug it.
I am really very confused and don't understand what is happening, but here is what I found out:
Starting from the partial build artifact seaside3.[image|changes] #720 from http://jenkins.lukas-renggli.ch and using the VM http://www.mirandabanda.org/files/Cog/VM/VM.r2370/ on my Ubuntu 11.04 I finally could replicate a problem loading builder/scripts/seaside3-zinc.st .
2370 is old, from 18 March 2011. The current version is 2489 from 22 August. Why are you using 2370?
Now the hang (100% cpu, no crash or any log to be seen) only happens in two cases:
running from the command line (as in the build script):
./coglinux/bin/squeak -nodisplay -nosound seaside3.image /home/sven/Smalltalk/builder/scripts/seaside3-zinc.st
or doing a file in of this file using the File Browser in Pharo.
Executing the same code manually (selecting it and performing a doit) works fine.
Note to replicate this you have to use a specific version, as in
Gofer new squeaksource: 'ZincHTTPComponents'; version: 'Zinc-HTTP-SvenVanCaekenberghe.191'; package: 'Zinc-Seaside'; load.
And then starting the Seaside adapter in one go.
On Mac OS X, I cannot reproduce this at all.
The difference between the working version (188) and the failing ones (up until 191) is very small IMHO, that's what is so strange.
So I decided to revert back by pushing down the connection management functionality of ZnMultiThreadedServer to a new subclass called ZnManagingMultiThreadedServer. Now the code difference between working and failing code is even smaller. Note also that the server is just started, it is not yet receiving any connections!
Any help would be appreciated ;-)
Lukas, I think you could try to rebuild the failing Seaside jobs.
Sven
-- best, Eliot
Starting from the partial build artifact seaside3.[image|changes] #720 from http://jenkins.lukas-renggli.ch and using the VM http://www.mirandabanda.org/files/Cog/VM/VM.r2370/ on my Ubuntu 11.04 I finally could replicate a problem loading builder/scripts/seaside3-zinc.st.
2370 is old, from 18 March 2011. Â The current version is 2489 from 22 August. Â Why are you using 2370?
Hi Eliot, I am lazy. I don't update the VMs on my servers that often. If you think this helps with the socket issues, I am of course all for updating it right away? Lukas
Now the hang (100% cpu, no crash or any log to be seen) only happens in two cases:
running from the command line (as in the build script):
./coglinux/bin/squeak -nodisplay -nosound seaside3.image /home/sven/Smalltalk/builder/scripts/seaside3-zinc.st
or doing a file in of this file using the File Browser in Pharo.
Executing the same code manually (selecting it and performing a doit) works fine.
Note to replicate this you have to use a specific version, as in
Gofer new     squeaksource: 'ZincHTTPComponents';     version: 'Zinc-HTTP-SvenVanCaekenberghe.191';     package: 'Zinc-Seaside';     load.
And then starting the Seaside adapter in one go.
On Mac OS X, I cannot reproduce this at all.
The difference between the working version (188) and the failing ones (up until 191) is very small IMHO, that's what is so strange.
So I decided to revert back by pushing down the connection management functionality of ZnMultiThreadedServer to a new subclass called ZnManagingMultiThreadedServer. Now the code difference between working and failing code is even smaller. Note also that the server is just started, it is not yet receiving any connections!
Any help would be appreciated ;-)
Lukas, I think you could try to rebuild the failing Seaside jobs.
Sven
-- best, Eliot
-- Lukas Renggli www.lukas-renggli.ch
On 5 September 2011 17:49, Lukas Renggli <renggli@gmail.com> wrote:
Starting from the partial build artifact seaside3.[image|changes] #720 from http://jenkins.lukas-renggli.ch and using the VM http://www.mirandabanda.org/files/Cog/VM/VM.r2370/ on my Ubuntu 11.04 I finally could replicate a problem loading builder/scripts/seaside3-zinc.st.
2370 is old, from 18 March 2011. Â The current version is 2489 from 22 August. Â Why are you using 2370?
Hi Eliot,
I am lazy. I don't update the VMs on my servers that often. If you think this helps with the socket issues, I am of course all for updating it right away?
I recommend you to update. The latest VMs containing a couple of critical bug fixes , which makes a lot of difference. Not sure it will help with sockets issue, but at least it will help getting an up to date feedback :)
Lukas
-- Best regards, Igor Stasenko AKA sig.
On Mon, Sep 5, 2011 at 8:57 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 5 September 2011 17:49, Lukas Renggli <renggli@gmail.com> wrote:
Starting from the partial build artifact seaside3.[image|changes] #720 from http://jenkins.lukas-renggli.ch and using the VM http://www.mirandabanda.org/files/Cog/VM/VM.r2370/ on my Ubuntu 11.04 I finally could replicate a problem loading builder/scripts/ seaside3-zinc.st.
2370 is old, from 18 March 2011. The current version is 2489 from 22 August. Why are you using 2370?
Hi Eliot,
I am lazy. I don't update the VMs on my servers that often. If you think this helps with the socket issues, I am of course all for updating it right away?
I recommend you to update. The latest VMs containing a couple of critical bug fixes , which makes a lot of difference. Not sure it will help with sockets issue, but at least it will help getting an up to date feedback :)
!right! :)
Lukas
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
On 05 Sep 2011, at 17:57, Igor Stasenko wrote:
I recommend you to update. The latest VMs containing a couple of critical bug fixes , which makes a lot of difference. Not sure it will help with sockets issue, but at least it will help getting an up to date feedback :)
It makes no difference: using the http://www.mirandabanda.org/files/Cog/VM/VM.r2489/ VM to start the base seaside3 image and doing a filein of the following hangs: "Zinc Server" Gofer new squeaksource: 'ZincHTTPComponents'; version: 'Zinc-HTTP-SvenVanCaekenberghe.191'; package: 'Zinc-Seaside'; load. ! "Start Zinc" (ZnZincServerAdaptor port: 8080) codec: GRPharoUtf8Codec new; start. Executing the same code from a workspace (without the !) just works. Beats me. Sven
On Sep 5, 2011, at 7:36 PM, Sven Van Caekenberghe wrote:
On 05 Sep 2011, at 17:57, Igor Stasenko wrote:
I recommend you to update. The latest VMs containing a couple of critical bug fixes , which makes a lot of difference. Not sure it will help with sockets issue, but at least it will help getting an up to date feedback :)
It makes no difference: using the http://www.mirandabanda.org/files/Cog/VM/VM.r2489/ VM to start the base seaside3 image and doing a filein of the following hangs:
"Zinc Server" Gofer new squeaksource: 'ZincHTTPComponents'; version: 'Zinc-HTTP-SvenVanCaekenberghe.191'; package: 'Zinc-Seaside'; load. ! "Start Zinc" (ZnZincServerAdaptor port: 8080) codec: GRPharoUtf8Codec new; start.
Executing the same code from a workspace (without the !) just works. Beats me.
Really. Really strange. If you replace with 1/0 you get the same? I mean if an error occurs? Stef
2011/9/5 Sven Van Caekenberghe <sven@beta9.be>:
On 05 Sep 2011, at 17:57, Igor Stasenko wrote:
I recommend you to update. The latest VMs containing a couple of critical bug fixes , which makes a lot of difference. Not sure it will help with sockets issue, but at least it will help getting an up to date  feedback :)
It makes no difference: using the http://www.mirandabanda.org/files/Cog/VM/VM.r2489/ VM to start the base seaside3 image and doing a filein of the following hangs:
"Zinc Server" Gofer new     squeaksource: 'ZincHTTPComponents';     version: 'Zinc-HTTP-SvenVanCaekenberghe.191';     package: 'Zinc-Seaside';     load. ! "Start Zinc" (ZnZincServerAdaptor port: 8080)     codec: GRPharoUtf8Codec new;     start.
Executing the same code from a workspace (without the !) just works. Beats me.
Sven
FileStream>>fileIn fileIn "Guarantee that the receiver is readOnly before fileIn for efficiency and to eliminate remote sharing conflicts." self readOnly. self fileInAnnouncing: 'Loading ', self localName You could try to surround workspace evaluation and see how it goes : - with progress bar/announcement things, but without file open/close - with a file open/readOnly copy/close but without progress notification Nicolas
Thanks for the suggestions, Stéphane: yes ordinary exceptions where thrown from a file in Nicolas: I can now reproduce the problem in a workspace as well The following code, evaluated from a workspace hangs Pharo (1.3 One-Click): ZnServer removeFromSystem. Gofer new squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; load. (Smalltalk at: #ZnServer) startDefaultOn: 1701. Apparently, just loading the code using gofer and starting the server is not enough to cause problems; there has to be a significant change, hence the removeFromSystem, before trouble begins. Since the progress bar says 'Initializing..' could there be something wrong with ZnServer class>>#initialize ? It looks harmless to me. Could someone please confirm this crash/hang ? This reminds me of the other problem that we had with the units tests, where the trait compilation tests before a Zn test involving a server caused problems. I still don't see a relations, but there has to be something very strange going on here. Sven
http://code.google.com/p/pharo/issues/detail?id=4768 On 06 Sep 2011, at 15:33, Sven Van Caekenberghe wrote:
The following code, evaluated from a workspace hangs Pharo (1.3 One-Click):
ZnServer removeFromSystem. Gofer new squeaksource: 'ZincHTTPComponents'; package: 'Zinc-HTTP'; load. (Smalltalk at: #ZnServer) startDefaultOn: 1701.
Apparently, just loading the code using gofer and starting the server is not enough to cause problems; there has to be a significant change, hence the removeFromSystem, before trouble begins.
Since the progress bar says 'Initializing..' could there be something wrong with ZnServer class>>#initialize ? It looks harmless to me.
Could someone please confirm this crash/hang ?
This reminds me of the other problem that we had with the units tests, where the trait compilation tests before a Zn test involving a server caused problems.
I still don't see a relations, but there has to be something very strange going on here.
participants (7)
-
Eliot Miranda -
Igor Stasenko -
Lukas Renggli -
Nicolas Cellier -
Philippe Marschall -
Stéphane Ducasse -
Sven Van Caekenberghe