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. Cheers Philippe

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

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

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.

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

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

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

On 05 Sep 2011, at 17:31, Lukas Renggli wrote:

The jobs are rebuilding right now.

The builds are OK now it seems. Sven

...

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

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