On 3 Apr 2011, at 11:59, Fred Kiefer wrote: > On 30.03.2011 10:54, Fred Kiefer wrote: >> When running GSTest and checking the memory usage with the build in >> memory panel, I noticed that when the NSAimation test is running we seem >> to be leaking GSMutableArray objects. I remember resolving an issue in >> that test a long time ago and I was convinced that this test wont leak >> objects. Looks like something changes since then. >> Could somebody please check, whether changed behaviour in base leads to >> this result? >> I don't think this potential bug is a release stopper. But it would be >> good to understand whether this is specific to my machine (64 bit >> OpenSuse 11.4) or a general problem. > > I think I found the reason for this leak, but I would prefer for Richard to > look into this before applying a patch. > > I think it is the class GSRunLoopThreadInfo (in NSThread.m) that leaks its > ivar performers. A simple RELEASE(performers) in the dealloc method should > fix this.
Great ... thanks very much. That's well spotted. > I also had a quick look into the fire method and don't quite understand why > we copy the array there. Wouldn't it be much fast to replace the ivar with a > new empty array and reuse the original array in the loop? > But this isn't a bug fix and shouldn't go in now. I agree that replacing would be faster ... but perhaps I was contemplating using imp caching ... for which we'd want to keep the same object to avoid having to re-cache later. I suspect that optimisation either way is not really worthwhile, but we could look into it later. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
