Hi, I'm having a problem with committing in GOODS 80 in 3.8-6665.
KKDatabase>>commit is choking on a primitive failure in Socket>>primeSocketSendDone. I initially ran into this on a 3.8a-1 unix vm, then tried it on a 3.9-7 unix vm where I also see the same behaviour. Using gdb with the 3.9-7 vm I find that socketValid is returning false because the SocketPtr's sessionID does not match thisNetSession. Unfortunately I don't know what this means. Can someone please give me a hand tracking down the problem? I should be on #squeak for the next 6 or 7 hours at least. Thank you. Ken P.S. I should also note that I'm using the GOODS server version 3.01 signature.asc (196 bytes) Download Attachment |
An update. It appears that between a quit and restart somehow the
socket is sticking around with the same sessionID. I'm not sure how this is possible. For now I'm working around it by not holding on to a KKDatabase instance in the saved image on shutdown. Ken On Thu, 2006-06-01 at 11:53 -0500, Ken Causey wrote: > Hi, I'm having a problem with committing in GOODS 80 in 3.8-6665. > KKDatabase>>commit is choking on a primitive failure in > Socket>>primeSocketSendDone. I initially ran into this on a 3.8a-1 unix > vm, then tried it on a 3.9-7 unix vm where I also see the same > behaviour. > > Using gdb with the 3.9-7 vm I find that socketValid is returning false > because the SocketPtr's sessionID does not match thisNetSession. > > Unfortunately I don't know what this means. Can someone please give me > a hand tracking down the problem? I should be on #squeak for the next 6 > or 7 hours at least. Thank you. > > Ken > > P.S. I should also note that I'm using the GOODS server version 3.01 signature.asc (196 bytes) Download Attachment |
Ken Causey wrote:
>An update. It appears that between a quit and restart somehow the >socket is sticking around with the same sessionID. I'm not sure how >this is possible. For now I'm working around it by not holding on to a >KKDatabase instance in the saved image on shutdown. > >Ken > > > I'd like to understand the problem since I'm trying to help maintain the GOODS client. Is it simply that you access a proxy or try to commit a GOODS session after a restart? BTW, I've published an updated client on SqueakSource. I'm not going to put it on SqueakMap yet since there is one issue with it: it doesn't work with the WriteBarrier package. If you're not using WriteBarrier I highly recommend updating since it adds a fix for #refresh and related methods. David |
>I'd like to understand the problem since I'm trying to help maintain the
>GOODS client. Is it simply that you access a proxy or try to commit a >GOODS session after a restart? >David In that case, I've got one for you, when I run ReleaseBuilder new fixObsoleteReferences. I get a primitive failure... - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - BlockContext>>ensure: MethodContext(ContextPart)>>handleSignal: MethodContext(ContextPart)>>handleSignal: Error(Exception)>>signal Error(Exception)>>signal: Socket(Object)>>error: Socket(Object)>>primitiveFailed Socket>>primSocketSendDone: Socket>>waitForSendDoneFor: Socket>>sendData: KKConnection>>sendCommand:withByte:withShort:withLong:withLong: KKConnection>>sendCommand:withShort:withLong: KKConnection>>objectsAt:copy:cluster: KKRecordCache>>loadObjectsStartingAt:do:ifAbsent: KKKeyCache>>loadObjectAt: [] in KKKeyCache>>at: {[self loadObjectAt: key]} PluggableDictionary(Dictionary)>>at:ifAbsent: And I just loaded your new release to make sure that hadn't been fixed, but nope, still blows up. Any ideas? winmail.dat (6K) Download Attachment |
Ramon Leon wrote:
>In that case, I've got one for you, when I run > >ReleaseBuilder new fixObsoleteReferences. > >I get a primitive failure... > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >BlockContext>>ensure: >MethodContext(ContextPart)>>handleSignal: >MethodContext(ContextPart)>>handleSignal: >Error(Exception)>>signal >Error(Exception)>>signal: >Socket(Object)>>error: >Socket(Object)>>primitiveFailed >Socket>>primSocketSendDone: >Socket>>waitForSendDoneFor: >Socket>>sendData: >KKConnection>>sendCommand:withByte:withShort:withLong:withLong: >KKConnection>>sendCommand:withShort:withLong: >KKConnection>>objectsAt:copy:cluster: >KKRecordCache>>loadObjectsStartingAt:do:ifAbsent: >KKKeyCache>>loadObjectAt: >[] in KKKeyCache>>at: {[self loadObjectAt: key]} >PluggableDictionary(Dictionary)>>at:ifAbsent: > >And I just loaded your new release to make sure that hadn't been fixed, but nope, still blows up. Any ideas? > > Well, yes and no. This is exactly the kind of problem I mentioned: you have a "dead proxy" (connection is closed) in your image and fixObsoleteReferences is sending it a message causing it to try to fault in the corresponding object. Right now the GOODS client doesn't really try to handle these errors. I have been thinking about, but not working on, a version which handles these errors differently. I don't have any idea yet what should be done though. Should a dead proxy silently swallow messages answering nil? I don't think that would be the right solution. Should it simply raise a notification and return nil if the notification is unhandled? That might be better...default to doing nothing but give the application a chance to handle the problem. In the mean time when I have problems like this I usually chase references down. First though I evaluate: "Clear all implicitly created variables in workspaces" Workspace allInstances collect: [:each | each setBindings: Dictionary new]. "Clear test case applications -- skip if you're not using SeasideTesting" SCComponentTestCase clearEntryPoints. "Clear seaside sessions -- skip if you're not using Seaside" WARegistry clearAllHandlers. SMSqueakMap default clearCaches . MCFileBasedRepository flushAllCaches. Smalltalk garbageCollect. Just to clean things up a bit. Often times that gets rid of the problematic object. HTH, David |
In reply to this post by cdavidshaffer
On Thu, 2006-06-01 at 22:20 -0400, David Shaffer wrote:
> Ken Causey wrote: > > >An update. It appears that between a quit and restart somehow the > >socket is sticking around with the same sessionID. I'm not sure how > >this is possible. For now I'm working around it by not holding on to a > >KKDatabase instance in the saved image on shutdown. > > > >Ken > > > > > > > I'd like to understand the problem since I'm trying to help maintain the > GOODS client. Is it simply that you access a proxy or try to commit a > GOODS session after a restart? variable when the image is saved on a 'Save and Quit'. Then when I restart Squeak with the same image and attempt a commit I get the failure because the sessionID has not been updated although the network connection has been stopped and then started resulting in thisNetSession being updated and then when socketValid() checks that they match, they don't, and so it considers the socket invalid. > BTW, I've published an updated client on SqueakSource. I'm not going to > put it on SqueakMap yet since there is one issue with it: it doesn't > work with the WriteBarrier package. If you're not using WriteBarrier I > highly recommend updating since it adds a fix for #refresh and related > methods. I'm not using WriteBarrier as of yet at least. Thanks I'll take a look at the new release. > > David > > > signature.asc (196 bytes) Download Attachment |
Free forum by Nabble | Edit this page |