Menu
▾
▴
Re: [xmlvm-users] No dependence on NSAutoreleasePool
|
From: Paul P. <bay...@gm...> - 2010-03-27 21:22:14
|
Hi All, I was just making some suggested modifications to a couple of my patches. After I was done, I was testing to make sure I didn't introduce any memory leaks. Unfortunately, the code seemed to have a lot of leaks. Upon digging in, the first leak I found was in ArrayList's iterator(), which didn't leak before & nothing had changed (side note: that existed before my patches). When I first tested & submitted my patches, they were using the auto-release pool. So I reverted to revision 977 before the auto-release pool was removed & all the leaks went away. Has anyone else observed a similar effect? For now I will need to continue using the old version. Perhaps we can set up a branch separate from trunk that removes the auto-release pool until it's been fully baked? Thanks a bunch! I appreciate the effort! Paul Poley 2010/3/26 Arno Puder <ar...@pu...> > > I just committed Joshua's fix. > > Arno > > > On 3/25/10 10:49 PM, Joshua Melcon wrote: > > Ok, I understand now. Yes that is a bug -- and an interesting one. > > Basically, its doing: > > > > > > R1 = object; // R1 has one retain > > Temp = R1; / > > R1 = object.subobject > > Release Temp (causing an implicit release of the object now in R1) > > retain R1 (so we don't lose it). > > > > Basically, the fix is to just emit the retain instruction before the > > rtmp release. In the future, we will notice that the back to back > > retain/release is not necessacry. > > > > http://xmlvm-reviews.appspot.com/33001 is a fix -- i will submit it to > > the trunk after the review completes. > > > > Panayotis: Thanks for finding the bug! I appreciate the feedback, as > > well as your clear description of the issue and how to reproduce it. > > Please let me know if you find anything else. > > > > all :) > > -- Joshua Melcon > > > > > > > > On Thu, Mar 25, 2010 at 3:06 PM, Panayotis Katsaloulis > > <pan...@pa...> wrote: > >> Yes these applications work. > >> > >> If you just try to convert the java source code I gave to you though, > you > >> will see the error :) > >> Just try ;) > >> To be fair, I've also checked a lot of code, from my own appplications > and > >> test cases and this was the only problem found :) > >> > >> Still, it is a bug ;) > >> > >> > >> > >> -- > >> Panayotis > >> 25 Μαρ 2010, 9:12 μ.μ., ο/η Joshua Melcon<xm...@me...> έγραψε: > >> > >> If the last retain is failing it indicates that there is an issue > related to > >> the releasing /retaining/nulling of size_org_xmlvm_iphone_CGSize. > >> > >> I have run Xokoban, Afireworks, and another CCed program and not > encountered > >> any problems. It is possible that you have found a case which we do not > >> handle correctly that doesn't show up in those programs. Later tonight > I > >> can attempt to reproduce this error using one of our demo apps -- > >> > >> Could you confirm that the Xokoban and Afireworks demo apps are working > for > >> you? > >> > >> Thanks, > >> > >> > >> -- Joshua Melcon > >> > >> > >> 2010/3/25 Panayotis Katsaloulis<pan...@pa...> > >>> > >>> On 25 Μαρ 2010, at 8:02 μ.μ., Joshua Melcon wrote: > >>> > >>>> _r2.o = [((org_xmlvm_iphone_UIView*) _r0.o) getFrame__]; // R2 > comes > >>>> back ref count += 1 because its a get function > >>>> _rtmp.o = _r2.o; // We are overwriting R2 on the next line, so we > >>>> need to free our +1 afterwords > >>>> _r2.o = ((org_xmlvm_iphone_CGRect*) _r2.o)->size_org_xmlvm_iphone_ > >>>> CGSize; // R2 has a new value, the old r2 (in tmp) is not needed > >>>> [_rtmp.o release]; _rtmp.o = [NSNull null]; // release the += from > >>>> the first line > >>>> [_r2.o retain]; // retaining the value from _r2, presumably > because > >>>> we will be returning soon (can't tell without the rest of the code). > >>>> > >>>> But, based on this code sequence, everything looks correct? How does > >>>> _r2.o retain break things? > >>> > >>> > >>> It says that it tries to retain am already fee'd object. > >>> > >>> Try it for yourself and see ;) > >>> > >>> > ------------------------------------------------------------------------------ > >>> Download Intel® Parallel Studio Eval > >>> Try the new software tools for yourself. Speed compiling, find bugs > >>> proactively, and fine-tune applications for parallel performance. > >>> See why Intel Parallel Studio got high marks during beta. > >>> http://p.sf.net/sfu/intel-sw-dev > >>> _______________________________________________ > >>> xmlvm-users mailing list > >>> xml...@li... > >>> https://lists.sourceforge.net/lists/listinfo/xmlvm-users > >> > >> > > > > > ------------------------------------------------------------------------------ > > Download Intel® Parallel Studio Eval > > Try the new software tools for yourself. Speed compiling, find bugs > > proactively, and fine-tune applications for parallel performance. > > See why Intel Parallel Studio got high marks during beta. > > http://p.sf.net/sfu/intel-sw-dev > > _______________________________________________ > > xmlvm-users mailing list > > xml...@li... > > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > xmlvm-users mailing list > xml...@li... > https://lists.sourceforge.net/lists/listinfo/xmlvm-users > |
