This is using the latest .cmm package in MagmaTester
When trying to clean up a broken image, the following code causes a problem The code is in SystemNavigation-#obsoleteBehaviours
test example that should reproduce the problem, having performed a MagmaSession cleanUp already.
SystemNavigation default allObjectsDo: [ :ob | isBehaviour ].
This understandably generates a MessageNotUnderstood error, on all Instances of MagmaMutatingProxy. The doesNotUnderstand: method attempts to reify the object, if it fails it retrys and if that fails it, signals the error. At this point one can only assume that the defaultAction on a MessageNotUnderstood exception eventually ends up calling MagmaMutatingProxy-#doesNotUnderstand:
best regards
Keith _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi Keith!
We have stumbled over this problem in Gjallar work from time to time - but only during development. I ended up inventing a doit to toast all those Processes - need to nil out the context IIRC - whenever it occurred. But it can be painful because with a couple of thousand Processes the system gets a tad painful to even type in.
It would be nice if we could get rid of this - it is annoying. :)
regards, Göran
Göran, if I remember correctly, the problem you had was a MagmaSession cleanUp had been run (to dereference MagmaSessions from old MethodContexts) so they could be garbage collected. This method becomeForwards the sessions to nil. Then, later, some proxy's referencing those sessions were "activated".
So what is the root problem here and what should be the solution? Maybe get rid of the need for MagmaSession>>#cleanUp, so that MagmaSessions get GC'd on their own in the first place? A session naturally GC'd would mean no possibility of any proxy's referencing it.
Chasing pointers on some of my stray MagmaSessions show they all reference from a chain originating in the "EventManager" and finally directly linked from a MethodContext. The cleanUp method simply nils out the MethodContext's #receiver: and that does the trick.
So what is the EventManager and why does it hold on to these MethodContexts? If someone knows a solution I'd be happy to include it in r40.
thanks.. Chris
On 5/9/07, Göran Krampe goran@krampe.se wrote:
Hi Keith!
We have stumbled over this problem in Gjallar work from time to time - but only during development. I ended up inventing a doit to toast all those Processes - need to nil out the context IIRC - whenever it occurred. But it can be painful because with a couple of thousand Processes the system gets a tad painful to even type in.
It would be nice if we could get rid of this - it is annoying. :)
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
So what is the EventManager and why does it hold on to these MethodContexts? If someone knows a solution I'd be happy to include it in r40.
Hi Chris,
I've run into this EventManager issue before when not using Magma. At that time I traced it into the ECompletion stuff. I tried tracking down exactly why it was holding on to this stuff, but didn't really succeed. I think it was setting triggers for when you ask for completions and not releasing it - but I'm not really sure.
The ECController is part of ECompletion, though.
-Chris
magma@lists.squeakfoundation.org
-
Chris Cunningham -
Chris Muller -
Göran Krampe -
Keith Hodges