We've had several reports of the weak dictionary not keeping tally in sync with the contents. This should be fixed in 7.8 builds (OpentalkBase(7.8 - 2)). I'll extract the changes as a patch and post it here shortly.
"Mark Plas"<[hidden email]> wrote: > Since using VW7.7, we sometimes encounter an endless loop in OtWeakKeyDictionary. > > This is what the stack looks like: > > ... > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > optimized [] in Opentalk.OtWeakKeyDictionary>>at:ifAbsent: > BlockClosure>>ensure: > optimized [] in RecursionLock>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > RecursionLock>>critical: > Opentalk.OtWeakKeyDictionary>>at:ifAbsent: > optimized [] in Opentalk.ObjectTable>>export:for: > BlockClosure>>ensure: > optimized [] in RecursionLock>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > RecursionLock>>critical: > Opentalk.ObjectTable>>export:for: > Opentalk.ConnectionAdaptor(Opentalk.BasicObjectAdaptor)>>export: > Opentalk.TCPTransport(Opentalk.Transport)>>export: > Opentalk.TCPTransport(Opentalk.RequestTransport)>>export: > Opentalk.STSTStream>>marshalObjectAsObjRef: > Opentalk.STSTStream>>marshalPassByReferenceObject: > Opentalk.STSTStream>>marshalObjectRecursively: > Opentalk.STSTStream>>nextPutSTSTReply: > optimized [] in Opentalk.STSTStream class>>initializeSpecialTypeDispatchTable > Opentalk.STSTStream>>marshalTaggedObject:with: > Opentalk.STSTStream>>marshalObjectRecursively: > optimized [] in Opentalk.STSTStream>>marshalObject: > BlockClosure>>on:do: > Opentalk.STSTStream>>marshalObject: > Opentalk.STSTMarshaler>>marshalTransportPayloadOf:into: > Opentalk.TCPTransport(Opentalk.RequestTransport)>>createTransportPackageFrom: > optimized [] in Opentalk.RequestTransport>>sendPackage: > BlockClosure>>ensure: > optimized [] in RecursionLock>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > RecursionLock>>critical: > Opentalk.TCPTransport(Opentalk.RequestTransport)>>sendPackage: > Opentalk.STSTReply(Opentalk.RemoteReply)>>send: > optimized [] in Opentalk.RemoteRequest>>sendReply:for: > BlockClosure>>on:do: > Opentalk.STSTRequest(Opentalk.RemoteRequest)>>sendReply:for: > Opentalk.STSTRequest(Opentalk.RemoteRequest)>>evaluateFor: > Opentalk.STSTRequest>>evaluateFor: > optimized [] in Opentalk.RemoteMessage>>dispatchFor: > BlockClosure>>on:do: > Opentalk.STSTRequest(Opentalk.RemoteMessage)>>dispatchFor: > optimized [] in Opentalk.RemoteRequest>>dispatchFor: > BlockClosure>>on:do: > optimized [] in Process class>>forBlock:priority: > > > We cannot reproduce it on demand, but here is some information I can provide for one case where it ran into the endless loop: > > The capacity of the dictionary is 101. > The tally of the dictionary is 40. > The slots in the #keys array are all /NOT NIL/. > the #shrinkBound is 0.1 (this is a default value) > > When the #findKeyOrNil: method gets invoked, it tries to look for an empty slot, but even though there is enough room left (tally < capacity), it doesn't find an empty spot because all slots in the #keys array are filled in with non-NIL values. Because no free slot is found, it tries to grow the dictionary but it doesn't grow it because the check in #grow: > > self tally / self capacity > self growBound > > returns false. Then it tries to do the findKeyOrNil: again and starts to loop until VW runs out of memory. > > I've noticed that the growing/shrinking behavior on OtWeakKeyDictionary has changed compared to vw7.4.1 & vw7.6. Perhaps this explains the loop? > > Is there a fix for this? > > Thanks, > Mark _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Thanks Martin!
-----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email] Sent: dinsdag 2 maart 2010 15:04 To: Mark Plas Cc: [hidden email]; vwnc NC Subject: [vw7.7] Opentalk.OtWeakKeyDictionary bug? We've had several reports of the weak dictionary not keeping tally in sync with the contents. This should be fixed in 7.8 builds (OpentalkBase(7.8 - 2)). I'll extract the changes as a patch and post it here shortly. "Mark Plas"<[hidden email]> wrote: > Since using VW7.7, we sometimes encounter an endless loop in OtWeakKeyDictionary. > > This is what the stack looks like: > > ... > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > Opentalk.OtWeakKeyDictionary>>findKeyOrNil: > optimized [] in Opentalk.OtWeakKeyDictionary>>at:ifAbsent: > BlockClosure>>ensure: > optimized [] in RecursionLock>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > RecursionLock>>critical: > Opentalk.OtWeakKeyDictionary>>at:ifAbsent: > optimized [] in Opentalk.ObjectTable>>export:for: > BlockClosure>>ensure: > optimized [] in RecursionLock>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > RecursionLock>>critical: > Opentalk.ObjectTable>>export:for: > Opentalk.ConnectionAdaptor(Opentalk.BasicObjectAdaptor)>>export: > Opentalk.TCPTransport(Opentalk.Transport)>>export: > Opentalk.TCPTransport(Opentalk.RequestTransport)>>export: > Opentalk.STSTStream>>marshalObjectAsObjRef: > Opentalk.STSTStream>>marshalPassByReferenceObject: > Opentalk.STSTStream>>marshalObjectRecursively: > Opentalk.STSTStream>>nextPutSTSTReply: > optimized [] in Opentalk.STSTStream class>>initializeSpecialTypeDispatchTable > Opentalk.STSTStream>>marshalTaggedObject:with: > Opentalk.STSTStream>>marshalObjectRecursively: > optimized [] in Opentalk.STSTStream>>marshalObject: > BlockClosure>>on:do: > Opentalk.STSTStream>>marshalObject: > Opentalk.STSTMarshaler>>marshalTransportPayloadOf:into: > Opentalk.TCPTransport(Opentalk.RequestTransport)>>createTransportPackageFrom: > optimized [] in Opentalk.RequestTransport>>sendPackage: > BlockClosure>>ensure: > optimized [] in RecursionLock>>critical: > BlockClosure>>ensure: > Semaphore>>critical: > RecursionLock>>critical: > Opentalk.TCPTransport(Opentalk.RequestTransport)>>sendPackage: > Opentalk.STSTReply(Opentalk.RemoteReply)>>send: > optimized [] in Opentalk.RemoteRequest>>sendReply:for: > BlockClosure>>on:do: > Opentalk.STSTRequest(Opentalk.RemoteRequest)>>sendReply:for: > Opentalk.STSTRequest(Opentalk.RemoteRequest)>>evaluateFor: > Opentalk.STSTRequest>>evaluateFor: > optimized [] in Opentalk.RemoteMessage>>dispatchFor: > BlockClosure>>on:do: > Opentalk.STSTRequest(Opentalk.RemoteMessage)>>dispatchFor: > optimized [] in Opentalk.RemoteRequest>>dispatchFor: > BlockClosure>>on:do: > optimized [] in Process class>>forBlock:priority: > > > We cannot reproduce it on demand, but here is some information I can provide for one case where it ran into the endless loop: > > The capacity of the dictionary is 101. > The tally of the dictionary is 40. > The slots in the #keys array are all /NOT NIL/. > the #shrinkBound is 0.1 (this is a default value) > > When the #findKeyOrNil: method gets invoked, it tries to look for an empty slot, but even though there is enough room left (tally < capacity), it doesn't find an empty spot because all slots in the #keys array are filled in with non-NIL values. Because no free slot is found, it tries to grow the dictionary but it doesn't grow it because the check in #grow: > > self tally / self capacity > self growBound > > returns false. Then it tries to do the findKeyOrNil: again and starts to loop until VW runs out of memory. > > I've noticed that the growing/shrinking behavior on OtWeakKeyDictionary has changed compared to vw7.4.1 & vw7.6. Perhaps this explains the loop? > > Is there a fix for this? > > Thanks, > Mark _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |