Hi,
I hit a rather strange problem while searching for a reference path to an object. An RcEqualityIndex defined on an RcIdentityBag is holding onto an instance that should not be there. It seems it is part of the array of its internal components… When I try to remove the index or invoke #cleanupBag, an error is thrown: #isEmpty is not understood by that instance (obviously, the code of those methods is iterating over the internal bags, sending #isEmpty …). What can I do to clean this situation? (this is GS 2.4.4.1) The RcIdentityBag itself appears to be functioning properly (for now). thanks Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
> The RcIdentityBag itself appears to be functioning properly (for now). I have to retract that. Iterating over the collection throws the same error. However, getting objects from it via the index works fine. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
> On 09 Jan 2015, at 13:16, Johan Brichau <[hidden email]> wrote: > > >> The RcIdentityBag itself appears to be functioning properly (for now). > > I have to retract that. Iterating over the collection throws the same error. However, getting objects from it via the index works fine. Ok, I have now explicitly replaced the wrong object in the components array of the RcIdentityBag by an IdentityBag instance. This fixed the issue, and I ran a cleanupBag and auditIndexes afterwards, saying all is OK We’re never explicitly touching the components of RcIdentityBag and it’s the first time I encounter such an issue. I could only retrieve all objects from the collection by using the select: message, which probably uses the index. Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Hey Johan,
Well, Bill has checked around and this kind of thing does not look like anything we've seen before. We're curious what kind of object was causing the problem. Since you've worked around the problem, I think that we are still interested in taking a shot at trying to figure out what might have happened. If you have the tranlogs for that stone (and the inclination) you could ship the tranlogs to us, tell us the oop of the collection and the slot that you patched (and ideally the oop of the bad boy object) and we might be able to learn something about what happened by analyzing the tranlogs ... of course, we don't know how long that object has been there and unless the oop shows up in some recognizable pattern of commits we might not be able to learn anything at all. So if you have the time (and inclination) to package up the tranlogs, we can take a shot... Dale On 01/09/2015 03:54 AM, Johan Brichau via Glass wrote: > Hi, > > I hit a rather strange problem while searching for a reference path to an object. > > An RcEqualityIndex defined on an RcIdentityBag is holding onto an instance that should not be there. It seems it is part of the array of its internal components… > When I try to remove the index or invoke #cleanupBag, an error is thrown: #isEmpty is not understood by that instance (obviously, the code of those methods is iterating over the internal bags, sending #isEmpty …). > > What can I do to clean this situation? (this is GS 2.4.4.1) > The RcIdentityBag itself appears to be functioning properly (for now). > > thanks > Johan > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Hi Dale,
Unfortunately, the moment it happened seems to be weeks ago. Pretty sure I don't have the tranlogs anymore of that. Its a production db and its running fine since the retrieval of objects works from that set. I only discovered it because I was doing maintenance on a backup. I did the fix on the copy and should still fix the production repo. The manipulation of the component collection inside the rcbag is not something I'm confident about. But it seems to work. Are there other recommendations for me to do when doing this fix? Thanks. Johan (sent from my mobile) > On 09 Jan 2015, at 19:11, Dale Henrichs via Glass <[hidden email]> wrote: > > Hey Johan, > > Well, Bill has checked around and this kind of thing does not look like anything we've seen before. > > We're curious what kind of object was causing the problem. > > Since you've worked around the problem, I think that we are still interested in taking a shot at trying to figure out what might have happened. If you have the tranlogs for that stone (and the inclination) you could ship the tranlogs to us, tell us the oop of the collection and the slot that you patched (and ideally the oop of the bad boy object) and we might be able to learn something about what happened by analyzing the tranlogs ... of course, we don't know how long that object has been there and unless the oop shows up in some recognizable pattern of commits we might not be able to learn anything at all. So if you have the time (and inclination) to package up the tranlogs, we can take a shot... > > Dale > >> On 01/09/2015 03:54 AM, Johan Brichau via Glass wrote: >> Hi, >> >> I hit a rather strange problem while searching for a reference path to an object. >> >> An RcEqualityIndex defined on an RcIdentityBag is holding onto an instance that should not be there. It seems it is part of the array of its internal components… >> When I try to remove the index or invoke #cleanupBag, an error is thrown: #isEmpty is not understood by that instance (obviously, the code of those methods is iterating over the internal bags, sending #isEmpty …). >> >> What can I do to clean this situation? (this is GS 2.4.4.1) >> The RcIdentityBag itself appears to be functioning properly (for now). >> >> thanks >> Johan >> >> _______________________________________________ >> Glass mailing list >> [hidden email] >> http://lists.gemtalksystems.com/mailman/listinfo/glass > > _______________________________________________ > Glass mailing list > [hidden email] > http://lists.gemtalksystems.com/mailman/listinfo/glass Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
> On 09 Jan 2015, at 19:11, Dale Henrichs via Glass <[hidden email]> wrote: > > We're curious what kind of object was causing the problem. It was an instance of a subclass of WATask. Yes... I'm pretty sure we did not put it inside the collection :) Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Administrator
|
In reply to this post by GLASS mailing list
You should save a reference to the object you are replacing so that we can later analyse what it was and why it was wrong. e.g. Globals at: #BadRcBagElement put: ... |
In reply to this post by GLASS mailing list
Johan,
This sounds like a gs/reclaim bug. Do you happen to be running epoch gc? We haven't found references to explicit bugs that fit this scenario (where an object swaps identity with another object), but you are running on a fairly old version of GemStone ... upgrading to 2.4.6 would get you the latest set of bug fixes, but since we haven't characterized the issue, we can't know if this is a known bug or not... Dale On 01/09/2015 01:54 PM, Johan Brichau wrote: >> On 09 Jan 2015, at 19:11, Dale Henrichs via Glass <[hidden email]> wrote: >> >> We're curious what kind of object was causing the problem. > It was an instance of a subclass of WATask. > Yes... I'm pretty sure we did not put it inside the collection :) > > Johan _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |