[Pharo-project] [BUG]Socket(Object)>>primitiveFailed:
here insert explanation of what you were doing, suspect changes you've made and so forth. 7 September 2011 8:24:30 pm VM: unix - i686 - linux-gnu - Croquet Closure Cog VM [CoInterpreter VMMaker.oscog-eem.112] Image: Pharo1.3 [Latest update: #13298] Socket(Object)>>primitiveFailed: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: selector: #primSocketSendDone: Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket(Object)>>primitiveFailed Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>primSocketSendDone: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: socketID: #[210 150 108 78 0 0 0 0 24 235 24 8] Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>waitForSendDoneFor: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: timeout: 45 startTime: 16100 msecsDelta: 45000 msecsEllapsed: nil sendDone: nil Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>sendSomeData:startIndex:count:for: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: aStringOrByteArray: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100...etc... startIndex: 1 count: 211 aTimeoutInSeconds: 45 bytesSent: nil Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>sendSomeData:startIndex:count: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: aStringOrByteArray: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100...etc... startIndex: 1 count: 211 Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() Socket>>sendData:count: Receiver: a Socket[invalidSocketHandle] Arguments and temporary variables: buffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68 97...etc... n: 211 sent: 0 Receiver's instance variables: semaphore: a Semaphore() socketHandle: #[210 150 108 78 0 0 0 0 24 235 24 8] readSemaphore: a Semaphore() writeSemaphore: a Semaphore() [socket sendData: outBuffer count: outNextToWrite - 1] in SocketStream>>flush Receiver: SocketStream[inbuf:4kb/outbuf:4kb] Arguments and temporary variables: Receiver's instance variables: recentlyRead: 798 socket: a Socket[invalidSocketHandle] inBuffer: #[71 69 84 32 47 115 116 97 116 117 115 47 87 65 73 109 97 103 101 83...etc... outBuffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68...etc... inNextToWrite: 799 outNextToWrite: 212 lastRead: 798 timeout: 30 autoFlush: false bufferSize: 4096 binary: true shouldSignal: true BlockClosure>>on:do: Receiver: [socket sendData: outBuffer count: outNextToWrite - 1] Arguments and temporary variables: exception: ConnectionTimedOut handlerAction: [:ex | shouldSignal ifTrue: []] handlerActive: true Receiver's instance variables: outerContext: SocketStream>>flush startpc: 60 numArgs: 0 SocketStream>>flush Receiver: SocketStream[inbuf:4kb/outbuf:4kb] Arguments and temporary variables: Receiver's instance variables: recentlyRead: 798 socket: a Socket[invalidSocketHandle] inBuffer: #[71 69 84 32 47 115 116 97 116 117 115 47 87 65 73 109 97 103 101 83...etc... outBuffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68...etc... inNextToWrite: 799 outNextToWrite: 212 lastRead: 798 timeout: 30 autoFlush: false bufferSize: 4096 binary: true shouldSignal: true SocketStream>>close Receiver: SocketStream[inbuf:4kb/outbuf:4kb] Arguments and temporary variables: Receiver's instance variables: recentlyRead: 798 socket: a Socket[invalidSocketHandle] inBuffer: #[71 69 84 32 47 115 116 97 116 117 115 47 87 65 73 109 97 103 101 83...etc... outBuffer: #[72 84 84 80 47 49 46 49 32 51 48 50 32 70 111 117 110 100 13 10 68...etc... inNextToWrite: 799 outNextToWrite: 212 lastRead: 798 timeout: 30 autoFlush: false bufferSize: 4096 binary: true shouldSignal: true [self log debug: 'Closing stream'. stream close] in [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(running 16624) Arguments and temporary variables: stream: SocketStream[inbuf:4kb/outbuf:4kb] Receiver's instance variables: port: 16624 process: a Process in [self schedule. beingWaitedOn ifTrue: [delaySemaphore ...etc... serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil MethodContext(ContextPart)>>resume: Receiver: BlockClosure>>on:do: Arguments and temporary variables: value: a ZnMultiThreadedServer(running 16624) ctxt: BlockClosure>>ensure: unwindBlock: [self log debug: 'Closing stream'. stream close] Receiver's instance variables: sender: nil pc: nil stackp: 3 method: (BlockClosure>>#on:do: "a CompiledMethod(137625600)") closureOrNil: nil receiver: [chain := thisContext sender cut: ctxt. ctxt jump] BlockClosure>>ensure: Receiver: [self executeRequestResponseLoopOn: stream] Arguments and temporary variables: aBlock: [self log debug: 'Closing stream'. stream close] complete: true returnValue: nil Receiver's instance variables: outerContext: [[self executeRequestResponseLoopOn: stream] ensure: [self log ...etc... startpc: 122 numArgs: 0 [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(running 16624) Arguments and temporary variables: stream: SocketStream[inbuf:4kb/outbuf:4kb] Receiver's instance variables: port: 16624 process: a Process in [self schedule. beingWaitedOn ifTrue: [delaySemaphore ...etc... serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil BlockClosure>>ifCurtailed: Receiver: [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. ...etc... Arguments and temporary variables: aBlock: [self log debug: 'Destroying socket'. socket destroy] complete: nil result: nil Receiver's instance variables: outerContext: [[[self executeRequestResponseLoopOn: stream] ensure: [self log...etc... startpc: 117 numArgs: 0 [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: Receiver: a ZnMultiThreadedServer(running 16624) Arguments and temporary variables: stream: SocketStream[inbuf:4kb/outbuf:4kb] socket: a Socket[invalidSocketHandle] Receiver's instance variables: port: 16624 process: a Process in [self schedule. beingWaitedOn ifTrue: [delaySemaphore ...etc... serverSocket: a Socket[waitingForConnection] delegate: a ZnSeasideServerAdaptorDelegate authenticator: nil log: a ZnLogSupport lastRequest: nil lastResponse: nil [self value. Processor terminateActive] in BlockClosure>>newProcess Receiver: [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'....etc... Arguments and temporary variables: Receiver's instance variables: outerContext: ZnMultiThreadedServer>>serveConnectionsOn: startpc: 112 numArgs: 0 --- The full stack --- Socket(Object)>>primitiveFailed: Socket(Object)>>primitiveFailed Socket>>primSocketSendDone: Socket>>waitForSendDoneFor: Socket>>sendSomeData:startIndex:count:for: Socket>>sendSomeData:startIndex:count: Socket>>sendData:count: [socket sendData: outBuffer count: outNextToWrite - 1] in SocketStream>>flush BlockClosure>>on:do: SocketStream>>flush SocketStream>>close [self log debug: 'Closing stream'. stream close] in [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: MethodContext(ContextPart)>>resume: BlockClosure>>ensure: [[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] in [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: BlockClosure>>ifCurtailed: [[[self executeRequestResponseLoopOn: stream] ensure: [self log debug: 'Closing stream'. stream close]] ifCurtailed: [self log debug: 'Destroying socket'. socket destroy]] in ZnMultiThreadedServer>>serveConnectionsOn: [self value. Processor terminateActive] in BlockClosure>>newProcess
Hi Laurent, On 07 Sep 2011, at 20:24, laurent.laffont@gmail.com wrote:
here insert explanation of what you were doing, suspect changes you've made and so forth.
What were you doing ? Is this something reproduceable ? Is this in a standard 1.3 or did you somehow upgrade Zn to the latest version ? Doing so might help (the primitive failed on close, flush is now swallowed). Sven
On Wed, Sep 7, 2011 at 9:04 PM, Sven Van Caekenberghe <sven@beta9.be> wrote:
Hi Laurent,
On 07 Sep 2011, at 20:24, laurent.laffont@gmail.com wrote:
here insert explanation of what you were doing, suspect changes you've made and so forth.
Haha I haven't seen the mail will go the list :) First time I use the mail out function. Anyway some explanations because this has corrupted my image. On SmallHarbour we use a modified VM (only SecurityPlugin - https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image can open only a given set of ports. Each image / account has an allocated port number, so when an image starts a .st file is given as argument which stop all seaside adaptors and then start Zinc Seaside adaptor on a given port. The problem is: if I have saved a image with a socket opened on port XX, then try to start it on SmallHarbour on port YY - given that XX is forbidden - image crashes. What were you doing ?
Is this something reproduceable ?
Yes.
Is this in a standard 1.3 or did you somehow upgrade Zn to the latest version ?
It's a 3 weeks old Pier 2 image from Lukas Jenkins server so I first want to get latest one and check if the problem is still here. Doing so might help (the primitive failed on close, flush is now swallowed).
OK thanks. Laurent.
Sven
On Sep 7, 2011, at 9:32 PM, laurent laffont wrote:
On Wed, Sep 7, 2011 at 9:04 PM, Sven Van Caekenberghe <sven@beta9.be> wrote: Hi Laurent,
On 07 Sep 2011, at 20:24, laurent.laffont@gmail.com wrote:
here insert explanation of what you were doing, suspect changes you've made and so forth.
Haha I haven't seen the mail will go the list :) First time I use the mail out function.
Anyway some explanations because this has corrupted my image.
On SmallHarbour we use a modified VM (only SecurityPlugin - https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image can open only a given set of ports. Each image / account has an allocated port number, so when an image starts a .st file is given as argument which stop all seaside adaptors and then start Zinc Seaside adaptor on a given port.
The problem is: if I have saved a image with a socket opened on port XX, then try to start it on SmallHarbour on port YY - given that XX is forbidden - image crashes.
It would be good that it does not crash :) do not mean crash or shutdown nicely. I mean if you are not in headless does it crash?
What were you doing ? Is this something reproduceable ?
Yes.
Is this in a standard 1.3 or did you somehow upgrade Zn to the latest version ?
It's a 3 weeks old Pier 2 image from Lukas Jenkins server so I first want to get latest one and check if the problem is still here.
Doing so might help (the primitive failed on close, flush is now swallowed).
OK thanks.
Laurent.
Sven
On Wed, Sep 7, 2011 at 9:45 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote: > > On Sep 7, 2011, at 9:32 PM, laurent laffont wrote: > > > On Wed, Sep 7, 2011 at 9:04 PM, Sven Van Caekenberghe <sven@beta9.be> > wrote: > > Hi Laurent, > > > > On 07 Sep 2011, at 20:24, laurent.laffont@gmail.com wrote: > > > > > here insert explanation of what you were doing, suspect changes you've > > > made and so forth. > > > > > > Haha I haven't seen the mail will go the list :) First time I use the > mail out function. > > > > Anyway some explanations because this has corrupted my image. > > > > On SmallHarbour we use a modified VM (only SecurityPlugin - > https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image > can open only a given set of ports. Each image / account has an allocated > port number, so when an image starts a .st file is given as argument which > stop all seaside adaptors and then start Zinc Seaside adaptor on a given > port. > > > > The problem is: if I have saved a image with a socket opened on port XX, > then try to start it on SmallHarbour on port YY - given that XX is forbidden > - image crashes. > > It would be good that it does not crash :) > do not mean crash or shutdown nicely. > I mean if you are not in headless does it crash? > Yes it crashes only in headless mode - the (not so?) funny thing is that daemontools restart it immediately, then crash, restart, crash, restart .... huge PharoDebug.log :) With display the debugger pops up with the stack trace that was sent. Laurent > > > > > > > What were you doing ? > > Is this something reproduceable ? > > > > Yes. > > > > > > Is this in a standard 1.3 or did you somehow upgrade Zn to the latest > version ? > > > > It's a 3 weeks old Pier 2 image from Lukas Jenkins server so I first want > to get latest one and check if the problem is still here. > > > > > > Doing so might help (the primitive failed on close, flush is now > swallowed). > > > > > > OK thanks. > > > > Laurent. > > > > > > Sven > > > > > > > > > > >
On 07 Sep 2011, at 21:32, laurent laffont wrote:
On SmallHarbour we use a modified VM (only SecurityPlugin - https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image can open only a given set of ports. Each image / account has an allocated port number, so when an image starts a .st file is given as argument which stop all seaside adaptors and then start Zinc Seaside adaptor on a given port.
The problem is: if I have saved a image with a socket opened on port XX, then try to start it on SmallHarbour on port YY - given that XX is forbidden - image crashes.
Apart from the fact that I think we have a serious problem here, see http://code.google.com/p/pharo/issues/detail?id=4768 (but nobody seems to care, no one even confirmed that this happens for them too) the workaround is (as I said to Lukas, and as I do myself) not to save images with a running server and just start the adaptor in a startup .st file. HTH, Sven
On Sep 7, 2011, at 11:27 PM, Sven Van Caekenberghe wrote:
On 07 Sep 2011, at 21:32, laurent laffont wrote:
On SmallHarbour we use a modified VM (only SecurityPlugin - https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image can open only a given set of ports. Each image / account has an allocated port number, so when an image starts a .st file is given as argument which stop all seaside adaptors and then start Zinc Seaside adaptor on a given port.
The problem is: if I have saved a image with a socket opened on port XX, then try to start it on SmallHarbour on port YY - given that XX is forbidden - image crashes.
Apart from the fact that I think we have a serious problem here, see
http://code.google.com/p/pharo/issues/detail?id=4768
(but nobody seems to care, no one even confirmed that this happens for them too)
This is not that nobody cares, this is that this is the week of the the restart of everything and spending days in travels and meetings. And yes we should really find the bug that hangs the tests on the server and that one. Stef
the workaround is (as I said to Lukas, and as I do myself) not to save images with a running server and just start the adaptor in a startup .st file.
HTH,
Sven
On Wed, Sep 7, 2011 at 11:27 PM, Sven Van Caekenberghe <sven@beta9.be>wrote: > > On 07 Sep 2011, at 21:32, laurent laffont wrote: > > > On SmallHarbour we use a modified VM (only SecurityPlugin - > https://gitorious.org/~laurentlaffont/cogvm/smallharbour ) so an image > can open only a given set of ports. Each image / account has an allocated > port number, so when an image starts a .st file is given as argument which > stop all seaside adaptors and then start Zinc Seaside adaptor on a given > port. > > > > The problem is: if I have saved a image with a socket opened on port XX, > then try to start it on SmallHarbour on port YY - given that XX is forbidden > - image crashes. > > Apart from the fact that I think we have a serious problem here, see > > http://code.google.com/p/pharo/issues/detail?id=4768 > > (but nobody seems to care, no one even confirmed that this happens for them > too) > Now I care :) As we use a modified VM I'll try to make it reproduceable easily. I will tell you. (Anyway on SmallHarbour server itself it's easy. If you want access .....) > the workaround is (as I said to Lukas, and as I do myself) not to save > images with a running server and just start the adaptor in a startup .st > file. > Yes but for Pier this is a problem as the image is autosaved so when you restart it through SmallHarbour web interface there's a running server. Laurent. > HTH, > > Sven > > >
participants (4)
-
laurent laffont -
laurent.laffont＠gmail.com
-
Stéphane Ducasse -
Sven Van Caekenberghe