Menu
▾
▴
Re: [xmlvm-users] No dependence on NSAutoreleasePool
|
From: Joshua M. <xm...@me...> - 2010-03-28 08:50:29
|
Thanks for the project -- it was very easy to get running. After some investigation, it looks like the call to NSMutableArray objectEnumerator causes an object to be allocated in the auto release pool. I verified it by experiment, but it also looks to be how the NSCollection classes work: http://svn.opengroupware.org/SOPE/trunk/libFoundation/Foundation/NSDictionary.m - (NSEnumerator*)objectEnumerator { return AUTORELEASE([[_NSDictionaryObjectEnumerator alloc] initWithDictionary:self]); } The reference code is doing its job perfectly. The NsMutableArray is also OK. Eventually, if the thread terminated it would cause all the itereators that were added to the autorelease pool to be freed. Basically the call stack is: run thread // creates an auto release pool, releases after its callees come back. ... loop forever creating iterators in the auto release pool, effectively never freeing the memory the iterators used. I am too tired to think of a clever solution at the moment, but I will look at it tomorrow. If you want a workaround, just use a for loop rather than an iterator in that thread :/ It seems somewhat weird that the enumerators work this way in obj c, because it creates this probably in normal objective c... Course its nice to not have to worry about freeing enumerators.... -- Joshua Melcon 2010/3/27 Paul Poley <bay...@gm...>: > Sure thing. I've attached an Eclipse project. It starts the UI & then runs > a background thread, which infinitely loops. Inside the loop, a method is > called so that anything allocated can be released, which wouldn't otherwise > happen until the loop ended (that fact is unrelated to our discussion). > Inside the method, an ArrayList is allocated & iterated. Nothing is > actually added to it. > When compiling against revision 977, memory usage remains consistent. When > compiling against revision 981, memory usage is quickly increased. I use > the OSX "Activity Monitor" to check memory usage. > Thanks Josh! > Paul Poley > > > 2010/3/27 Joshua Melcon <xm...@me...> >> >> Hi Paul, >> >> I attempted to produce a leak with the array list iterator today using >> a few variations of code similar to: >> >> ArrayList<InternalClass> a = new ArrayList<InternalClass>(); >> for(int x=0;x<10000;x++) >> { >> a.add(new InternalClass()); >> } >> for(InternalClass x:a) >> { >> x.toString(); >> } >> >> I am unable to see any leaking objects. >> >> Additionally, I inspected the array list iterator code -- it seems >> work when I step through it. >> >> In order to debug this issue I think that I need some help from you. >> If you could create a self contained example that causes a memory leak >> I would be more than happy to figure out what is going on. >> >> Thanks, >> >> -- Joshua Melcon >> >> >> >> 2010/3/27 Paul Poley <bay...@gm...>: >> > 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 >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > 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 >> > >> > > > |
