Debugging problem with GOODS 80 in 3.8-6665

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging problem with GOODS 80 in 3.8-6665

Ken Causey-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Debugging problem with GOODS 80 in 3.8-6665

Ken Causey-3
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
Reply | Threaded
Open this post in threaded view
|

Re: Debugging problem with GOODS 80 in 3.8-6665

cdavidshaffer
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


Reply | Threaded
Open this post in threaded view
|

RE: Debugging problem with GOODS 80 in 3.8-6665

Ramon Leon
>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
Reply | Threaded
Open this post in threaded view
|

Re: Debugging problem with GOODS 80 in 3.8-6665

cdavidshaffer
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


Reply | Threaded
Open this post in threaded view
|

Re: Debugging problem with GOODS 80 in 3.8-6665

Ken Causey-3
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?
It's that I have a referance to an instance of KKDatabase in an instance
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