Community
Participate
Working Groups
In a memory snapshot there were 44.482 listeners installed in a single EclipseContext; 35.580 of them were of type TrackableComputationExt. These TrackableComputationExt objects retained about 17 MB of data. Currently I am not able to find any place where listeners are added to the collection of listeners. Seems to be 'magic'. And, there seems to be no place where listeners are removed from a context.
Found. The EclipseContext listeners are only modified outside of the class, namely, in Computation. The class add a listener to the context when startListening(...) is called. TrackableComputationExt calls this method but fails to remove the listener afterwards.
Those numbers seem way too high. However, I don't think it's a problem that the call to startListening() does not have a corresponding stopListening() call. The problem must be somewhere else, for example if we create TrackableComputationExt objects multiple times, for the same context and the same purpose.
Created attachment 173500 [details] patch Actually the problem is in Computation.stopListening(...). This method doesn't do what it is supposed to do. It never removes the listener. Please check if the code related to bug 304859 (see comments in class Computation) can be removed.
I was too quick. My patch doesn't solve the problem, but I still think the patch is correct. I am doing some further investigation.
I have a question: When a part is activated, the theme engine updates the context with some values. As a result, for example, CSSPropertyInnerKeylineSWTHandler.applyCSSProperty(...) gets called. This method fetches the css context, sets the 'innerKeyline' value, and then injects the context into the renderer: ContextInjectionFactory.inject(renderer, context); This looks like a bug to me. Shouldn't this method be called only once? (i.e. not every time the property changes) The problem is that inject(...) will install a TrackAndRun for the relevant Requestors. But, tracking has already been activted with the previous call to inject(...), so that no injection would be necessary. Afterw the renewed call of inject(...) there will be two trackers, because the requesting object is still alive. Am I missing something?
(In reply to comment #5) > ContextInjectionFactory.inject(renderer, context); > > This looks like a bug to me. Shouldn't this method be called only once? Yes, looks like a bug to me too. See bug 318798 comment 8. Bogdan is going to change this code to just do a java.lang.reflect.Method.invoke() instead of the heavyweight context stuff.
This should fix the memory leak.
(In reply to comment #5) > I have a question: > When a part is activated, the theme engine updates the context with some > values. As a result, for example, > CSSPropertyInnerKeylineSWTHandler.applyCSSProperty(...) gets called. This > method fetches the css context, sets the 'innerKeyline' value, and then injects > the context into the renderer: > ContextInjectionFactory.inject(renderer, context); > This looks like a bug to me. Yes, this is the bug 313950.
Created attachment 173571 [details] Patch O2 Yes, let's remove changes made for the bug 304859 and add explicit listener removal as suggested by Stefan. That should clear the picture a bit.
Patch applied to CVS Head. The CSS classes over-using injection will be tracked in the bug 313950.
