Re: create an autorelease pool in the init-method and release it in the dealloc-method ..?

d an object to the autorelease pool or don't own the object it > gets released automatically after an event cycle. > > is that correct? Almost. Whenever an object is added to the autorelease pool, it gets released when that autorelease pool pops. NSApplication and UIApplication

Re: create an autorelease pool in the init-method and release it in the dealloc-method ..?

tml%23//apple_ref/doc/uid/2047-CJBFBEDI>) whenever I add an object to the autorelease pool or don't own the object it gets released automatically after an event cycle. is that correct? So I only have to worry about objects I own, that are objects I allocate with alloc (I don't

Re: create an autorelease pool in the init-method and release it in the dealloc-method ..?

; On May 14, 2011, at 6:19 PM, Nick Zitzmann wrote: > > On May 14, 2011, at 5:43 PM, Martin Batholdy wrote: > >> I still have trouble understanding the autorelease pool. >> >> Lets assume an object Z has a method where it gets a string y and returns >> ano

Re: create an autorelease pool in the init-method and release it in the dealloc-method ..?

On May 14, 2011, at 5:43 PM, Martin Batholdy wrote: > I still have trouble understanding the autorelease pool. > > Lets assume an object Z has a method where it gets a string y and returns > another string x. > > Now when an instance of this object is created and the method

create an autorelease pool in the init-method and release it in the dealloc-method ..?

Hi, I still have trouble understanding the autorelease pool. Lets assume an object Z has a method where it gets a string y and returns another string x. Now when an instance of this object is created and the method is invoked, x is returned and is used somewhere else. Now this method of

Re: autorelease pool comprehension

:date, hours, nil]]; > [pool release]; > } > } while ( rc == SQLITE_ROW ); > > Why were the NSNumber objects not released when the pool was released? I made > sure that the app had been rebuilt and that I was debugging the app with the > autorelease pool code. D

Re: autorelease pool comprehension

On 30 Mar 2011, at 9:53 AM, Apple Developer wrote: > Why were the NSNumber objects not released when the pool was released? They are being kept alive because they are (indirectly) members of 'list', which I assume is released by a containing autorelease p

Re: autorelease pool comprehension

hen the pool was released? I made > sure that the app had been rebuilt and that I was debugging the app with the > autorelease pool code. Does the debugger have anything to do with it? Is > there any way I can observe proper behavior? What am I doing wrong? NSArray retains its content. Y

Re: autorelease pool comprehension

ell, until 'list' was released, none of the other objects would be as well. > What am I doing wrong? I don't think there is anything you are "doing" wrong, but you may need to refresh your understanding of retain-count based memory management. All an autorelease pool

autorelease pool comprehension

arrayWithObjects:date, hours, nil]]; [pool release]; } } while ( rc == SQLITE_ROW ); Why were the NSNumber objects not released when the pool was released? I made sure that the app had been rebuilt and that I was debugging the app with the autorelease pool code. Does the debugger have anything to do

Re: Autorelease Pool Question.

On Aug 25, 2010, at 5:08 AM, Mr. Gecko wrote: > I do not do garbage collection because I am building for 10.4. Why, because I > have 10.4 customers. -drain is still available on 10.4. -- David Duncan ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple

Re: Autorelease Pool Question.

n 2010-08-24, at 10:44 PM, Mr. Gecko wrote: > >> I am wondering if releasing the autorelease pool is the same as draining. If >> it's not, will releasing cause the objects not to be released? I am just >> wondering as I am using release in my applications and it wou

Re: Autorelease Pool Question.

It is the same if you are not doing garbage collection (drain hints the gc) drain is the safer bet for all environments On 2010-08-24, at 10:44 PM, Mr. Gecko wrote: > I am wondering if releasing the autorelease pool is the same as draining. If > it's not, will releasing cause the obj

Autorelease Pool Question.

I am wondering if releasing the autorelease pool is the same as draining. If it's not, will releasing cause the objects not to be released? I am just wondering as I am using release in my applications and it would be bad if it didn't release the obj

autorelease pool crash

My application is RubyCocoa based. Sometimes I'm getting the following message, which precedes the crash: *** attempt to pop an unknown autorelease pool What situation can cause this message? Thanks, Nava ___ Cocoa-dev mailing list (Coco

Re: Autorelease pool

Am Do.,08.10.2009 um 16:36 schrieb Michael Süssner: Hi , thanks a lot for your tips. after having read the bible and some experiments I have learned how to do it correctly. Here the conclusion for the rest of the world: NSMutableArray *vPolyArray = [[NSMutableArray alloc] initWithCapaci

Re: Autorelease pool

Hi , thanks a lot for your tips. after having read the bible and some experiments I have learned how to do it correctly. Here the conclusion for the rest of the world: NSMutableArray *vPolyArray = [[NSMutableArray alloc] initWithCapacity: 6]; vPolygon = [[[PolygonShape alloc] ini

Re: Autorelease pool

On Oct 7, 2009, at 2:53 PM, Michael Süssner wrote: After my test program has passed successfully the drain method of the autorelease buffer is called and "sometimes" I get the following error: Program received signal: “EXC_BAD_ACCESS”. sharedlibrary apply-load-rules all How can I track wh

Re: Autorelease pool

On 08.10.2009, at 00:12, Dave Carrigan wrote: Read and re-read the memory management rules until you start dreaming about them. Then you will start on the path to enlightenment :-) Wax on ... wax off. Wax on ... wax off. ... ... sorry, wrong kind of enlightenment. -- Uli Kusterer Sole

Re: Autorelease pool

On Oct 7, 2009, at 2:53 PM, Michael Süssner wrote: NSArray *vPolyArray = [NSArray arrayWithObjects: [[PolygonShape alloc] initWithNumberOfSides:4 minimumNumberOfSides:3 maximumNumberOfSides:7], [[PolygonShape alloc] initWithNumberOfSides:6 minimumNumberOfSides:5 maximu

Re: Autorelease pool

On Wed, Oct 7, 2009 at 2:53 PM, Michael Süssner wrote: > I habe created a small shell programm using Cocoa Foundation class for test > purposes. > > After my test program has passed successfully the drain method of the > autorelease buffer is called and "sometimes" I get the following error: > Pro

Re: Autorelease pool

On Oct 7, 2009, at 3:53 PM, Michael Süssner wrote: How can I track which object has already been release: You can't. Read up on the memory management rules; you've made a few mistakes in your code (assuming you're not using GC).

Autorelease pool

I habe created a small shell programm using Cocoa Foundation class for test purposes. After my test program has passed successfully the drain method of the autorelease buffer is called and "sometimes" I get the following error: Program received signal: “EXC_BAD_ACCESS”. sharedlibrary apply-

Re: Puzzling run loop/autorelease pool question

Having my own autorelease pool in my call-back is an approach that I tried, and it worked, but I was unsatisfied because from my understanding of run loops and autorelease pools, it didn't seem like it should be necessary. Because my app is a Cocoa app, and everything is happening o

Re: Puzzling run loop/autorelease pool question

rk for ever, I still think you're better off wrapping your C callbacks with your own NSAutoreleasePool; nothing really guarantees that an autorelease pool will exist when you're in a C callback that you've added directly to the runloop via a

Re: Puzzling run loop/autorelease pool question

interface so it makes no guarantee that an autorelease pool will even exist, let alone whether it will drain it. Bear in mind, that when your events are triggered no other Objective-C code runs except for yours; it's all done in CoreFoundation's runloop code. Anyway, to solve it, all you

Re: Puzzling run loop/autorelease pool question

ver app is just sitting there in > the background logging notifications to the console, any autoreleased > objects created just pile up in the autorelease pool. Clicking in the > observing app's window, or even just activating it then triggers a massive > release festival. > >

Re: Puzzling run loop/autorelease pool question

I've uploaded a project that demonstrates the problem to _murat ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the m

Puzzling run loop/autorelease pool question

sed objects created just pile up in the autorelease pool. Clicking in the observing app's window, or even just activating it then triggers a massive release festival. I suppose one explanation is that my run loop is stalled because it thinks there is nothing to process, but

Re: do i need to create autorelease pool?

On Sun, Mar 1, 2009 at 9:58 PM, Memo Akten wrote: > Michael, so does this mean that CFRunLoopTimer and NSTimer don't behave the > same way? I always assumed 'toll-free bridged' meant that you could use them > interchangeably, the NSxxx were just Cocoa wrappers for the CF stuff, but it > seems beha

Re: do i need to create autorelease pool?

e the same way? I always assumed 'toll-free bridged' meant that you could use them interchangeably, the NSxxx were just Cocoa wrappers for the CF stuff, but it seems behavior is not the same... And just to re-iterate, I do not need to create an autorelease pool around my timerFired c

Re: do i need to create autorelease pool?

On Wed, Feb 25, 2009 at 8:45 PM, Peter N Lewis wrote: > OK, I will certainly defer to Michael's deeper knowledge on this stuff, Oh no, don't do that > but > I thought Leopard plugged most of the normal case holes for requiring an > auto release pool, so I wrote up this test case: > > #import

Re: do i need to create autorelease pool?

At 11:44 -0500 25/2/09, Michael Ash wrote: On Wed, Feb 25, 2009 at 12:00 AM, Peter N Lewis wrote: The Application Kit creates an autorelease pool on the main thread at the beginning of every cycle of the event loop, and drains it at the end, thereby releasing any autoreleased objects

Re: do i need to create autorelease pool?

Ah ok, thats what I wasn't sure about, whether or not the pool would be released after every timer update. So if no events come in for a few seconds, I"ll have my runloops autorelease pool swelling up - which is not desired. My solution of creating my own autorelease pool befo

Re: do i need to create autorelease pool?

On Wed, Feb 25, 2009 at 12:00 AM, Peter N Lewis wrote: >> The Application Kit creates an autorelease pool on the main thread at the >> beginning of every cycle of the event loop, and drains it at the end, >> thereby releasing any autoreleased objects generated while proc

Re: do i need to create autorelease pool?

I know what autorelease pools are and how they work so my question isn't about that. In my iPhone app I create a NSTimer to run at 60fps, in it I update a bunch of stuff and draw opengl. Currently I have: -(void) timerLoop { // create autorelease pool in case anything nee

do i need to create autorelease pool?

I know what autorelease pools are and how they work so my question isn't about that. In my iPhone app I create a NSTimer to run at 60fps, in it I update a bunch of stuff and draw opengl. Currently I have: -(void) timerLoop { // create autorelease pool in case anything nee

Re: How Does Autorelease Pool Work?

On Dec 29, 2008, at 9:00 AM, Oleg Krupnov wrote: I am a newbie to Cocoa Memory Management (have been using GC so far), and I'd like to make sure that my understanding is correct. - It follows that the actual releasing of objects registered in the auto-release pool is deferred until the ent

How Does Autorelease Pool Work?

I am a newbie to Cocoa Memory Management (have been using GC so far), and I'd like to make sure that my understanding is correct. Let's assume, for the sake of simplicity, that I don't explicitly create nested auto-released pools, don't detach new threads, use Cocoa and AppKit etc., and rely on th

Re: Main Thread autorelease pool, memory usage question?

call will never return, and the autorelease pool will never drain. An NSTimer firing does not involve a literal NSEvent, and that method won't return. You can work around it by posting an application defined event at the end of whatever code you have that you'd expect to behave like an e

Re: Main Thread autorelease pool, memory usage question?

f the user > clicking in the app appears to trigger an interrupt, allowing memory to be > released or the main thread to manage its autorelease pools. Couple of > questions: > > 1) Why is the main thread not managing the autorelease pool(s) without this > user interrupt? > 2) Is

Re: Main Thread autorelease pool, memory usage question?

The key part is the call to next_EVENT_matchingMask. That means that if there are no literal NSEvents to process, that call will never return, and the autorelease pool will never drain. An NSTimer firing does not involve a literal NSEvent, and that method won't return. You can work ar

Main Thread autorelease pool, memory usage question?

memory to be released or the main thread to manage its autorelease pools. Couple of questions: 1) Why is the main thread not managing the autorelease pool(s) without this user interrupt? 2) Is there a way to trigger the main thread to cleanup its autorelease pools? 3) If not, is there a way

Re: Unexpected behaviour with autorelease pool

On 15 Dec 2008, at 00:09, Michael Ash wrote: On Sun, Dec 14, 2008 at 12:55 PM, Krishna Kotecha wrote: Shouldn't this code be causing an error at some point? And if not, why not? Any insights or explanations any one has on this would be appreciated. All C programmers (and therefore all O

Re: Unexpected behaviour with autorelease pool

ory consumption at reasonable levels. This is documented and discussed, and should hardly be a surprise. That you alloc/init your objects instead of using convenience constructors is no surprise. You *cannot* rely on code you do not control not to autorelease objects just because you're using

Re: Unexpected behaviour with autorelease pool

On Sun, Dec 14, 2008 at 12:55 PM, Krishna Kotecha wrote: > Shouldn't this code be causing an error at some point? And if not, why not? > > Any insights or explanations any one has on this would be appreciated. All C programmers (and therefore all Objective-C programmers) must be familiar with the

Re: Unexpected behaviour with autorelease pool

our framework should be able to create themselves without putting a big restraint on the system. What big constraint? I think you mean a tiny constraint magnified many times over by your own deliberate iteration. When you do that, you are responsible for draining the autorelease pool on

Re: Unexpected behaviour with autorelease pool

Hi, Just wanted to thank everyone who responded to my question. I'm trying to get the memory management stuff down cold, hence I was breaking the memory management rules in my Counter class and was perplexed by the results I got. The explanations here have certainly helped increase my understandi

Re: Unexpected behaviour with autorelease pool

er by your own deliberate iteration. When you do that, you are responsible for draining the autorelease pool on a regular basis. But even with lots of iteration, I don't see the big constraint. I actually did run your code. It completed in under 40 milliseconds with no evident strain

Re: Unexpected behaviour with autorelease pool

On 14 Dec 2008, at 23:27, Ken Thomases wrote: On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote: If your system doesn't crash/hangs before you can stop it, then you will see that the app is consuming memory like the Americans are consuming oil. And according to me, my program respects

Re: Unexpected behaviour with autorelease pool

On 14 Dec 2008, at 23:27, Ken Thomases wrote: On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote: If your system doesn't crash/hangs before you can stop it, then you will see that the app is consuming memory like the Americans are consuming oil. And according to me, my program respect

Re: Unexpected behaviour with autorelease pool

On Dec 14, 2008, at 4:17 PM, Filip van der Meeren wrote: If your system doesn't crash/hangs before you can stop it, then you will see that the app is consuming memory like the Americans are consuming oil. And according to me, my program respects the Memory Management rules. So I say there i

Re: Unexpected behaviour with autorelease pool

I suggest you run my code, on your system. Do not start up leaks, start up Activity Monitor and watch your memory closely. If your system doesn't crash/hangs before you can stop it, then you will see that the app is consuming memory like the Americans are consuming oil. And according to me,

Re: Unexpected behaviour with autorelease pool

On Dec 14, 2008, at 4:01 PM, Filip van der Meeren wrote: NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSNumber *n = nil; NSInteger wh = 0; srand(time(NULL)); for(int i = 0; i < 100 * 1000; ++i) { n = [[NSNumber alloc] initWithInt:rand()]; if([n retainCount])

Re: Unexpected behaviour with autorelease pool

If you allocate the object yourself, like the following: NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSNumber *n = nil; NSInteger wh = 0; srand(time(NULL)); for(int i = 0; i < 100 * 1000; ++i) { n = [[NSNumber alloc] initWithInt:rand()]; if([n retainCount])

Re: Unexpected behaviour with autorelease pool

Thank you, I was just replying to your mail ;-) Filip van der Meeren fi...@code2develop.com http://www.sourceforge.net/projects/perlmanager http://www.sourceforge.net/projects/xlinterpreter On 14 Dec 2008, at 22:49, Nick Zitzmann wrote: On Dec 14, 2008, at 10:55 AM, Krishna Kotecha wrote: -

Re: Unexpected behaviour with autorelease pool

Le 14 déc. 08 à 22:36, Filip van der Meeren a écrit : I think I have found the answer to your question; when executing the following code, I get a few strange results... NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSNumber *n0 = [NSNumber numberWithInt:1]; NSLog(@"n0: %d",

Re: Unexpected behaviour with autorelease pool

On Dec 14, 2008, at 10:55 AM, Krishna Kotecha wrote: -(void) dealloc { [counter release]; [super dealloc]; } Guess what I overlooked? My apologies; Flip is probably correct. Nick Zitzmann ___ Cocoa-dev mailing list

Re: Unexpected behaviour with autorelease pool

On Dec 14, 2008, at 3:36 PM, Filip van der Meeren wrote: I think I have found the answer to your question; when executing the following code, I get a few strange results... NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSNumber *n0 = [NSNumber numberWithInt:1]; NSLog(@"n0: %d"

Re: Unexpected behaviour with autorelease pool

I think I have found the answer to your question; when executing the following code, I get a few strange results... NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; NSNumber *n0 = [NSNumber numberWithInt:1]; NSLog(@"n0: %d", [n0 retainCount]); [n0 release]; NSLog(@"n0: %d", [n0 re

Re: Unexpected behavior with autorelease pool

On Dec 14, 2008, at 10:55 AM, Krishna Kotecha wrote: As the comment say, I would expect an error to occur due the fact Counter:dealloc: is releasing an autorelease object. However the application exits cleanly. Shouldn't this code be causing an error at some point? And if not, why not?

Unexpected behaviour with autorelease pool

Hi, I am seeing some unexpected behaviour and was hoping someone might be able to shed some light on this. I have a basic Counter class. The relevant methods for the problem are: -init { if (self = [super init]) { //counter = [[NSNumber alloc] init]; counter = [NSNumber numberWithInt:0]; // let