macOS RetainCount of 17057120 right after alloc/init....

[jctj]

I can post the code later if that would be helpful, but when I check retainCount immediately after allocating and initilizing a new object, I get a retainCount of 17057120. Obviously, I am trying to track down why none of my objects get dealloc'd - I have 4 or 5 NSMutableArrays which could own any given object (any number of them could own the object) and using the retainCount function would be very helpful to figure out where I am inadvertantly bumping up the retain count by one (or more).

If I use a simpler version, using the exact same object, the retainCount function returns exactly what it ought to - the proper retain count of the object as it goes through its life cycle. But in my main version I get 17057120 (or larger) right after it is allocated. My main version is running a separate thread when the object is allocated, if that makes any difference.

I realize I should post my code with this - and I will if that is needed - but I was hoping the number returned would be instantly recognized and the problem known.

Thank you in advance for any help on this.

 

[chown33]

Post your code. Especially if it's threaded.

There are reasons why a newly alloc/init'ed object might have a retain count other than 1, but 17057120 seems wacky given the complete lack of context. Especially since it's a threaded lack of context.

 

[lee1210]

Trying to topeka that number returned no usable search results, so code would help. If this is an NSNumber with a value of less than 19 or so, this is expected behavior, the runtime keeps copies of this object around permanently.

retainCount is unlikely to be your friend, and your issues with dealloc may not be for the reasons you think.

From the memory management guide:

You should not tie management of system resources to object lifetimes; see “Resource Management” (page
18).
When an application terminates, objects may not be sent a dealloc message. Because the process’s memory is automatically cleared on exit, it is more efficient simply to allow the operating system to clean up resources than to invoke all the memory management methods.

As you said, code makes this easier. If you can post it, do.

-Lee

 

[Sydde]

Trying to topeka that number returned no usable search results, so code would help. If this is an NSNumber with a value of less than 19 or so, this is expected behavior, the runtime keeps copies of this object around permanently.

Does this mean that if I do [NSNumber numberWithInt:12] 20 times, they will all reference the same object? Or will I just get 20 instances of NSNumber that indirectly reference the base object?

 

[gnasher729]

Does this mean that if I do [NSNumber numberWithInt:12] 20 times, they will all reference the same object?

Yes. And you can release it as much as you like, it won't go away. Just like @"astring" will never go away and report a nonsense number as the retain count. Then of course your retain counts will be nonsense anyway if garbage collection is turned on.

 

[jared_kipe]

What kind of objects are being kept in the arrays?

NS* objects? or your own custom objects?

 

[xStep]

This seems familiar. As if I did this yesterday and I think it was due to a bad format setup in my NSLog string for the type returned by retainCount.

If you want help, post the code snippet.

 

[jared_kipe]

This seems familiar. As if I did this yesterday and I think it was due to a bad format setup in my NSLog string for the type returned by retainCount.

If you want help, post the code snippet.

HA thats awesome. But I can't think of any formatters that would give that output for an unsigned int that is presumably == 1.

 

[lee1210]

HA thats awesome. But I can't think of any formatters that would give that output for an unsigned int that is presumably == 1.

0x1044560 seems like a valid 32-bit memory address... if you printed a pointer as a decimal...

-Lee

 

[jared_kipe]

0x1044560 seems like a valid 32-bit memory address... if you printed a pointer as a decimal...

-Lee

I thought of that, but the OP seems to indicate that it is 17057120 everytime he runs it, and probably for multiple objects.

Otherwise I would HOPE that one would describe the problem as some arbitrarily high random number...

 

[Sander]

Trying to topeka that number

LOL

 

[jctj]

The answer....

After doing the paper/pencil drill for hours, and having reviewed all of my retain/release events, I was at wit's end. I wrote a much shorter, simpler demo program using the same custom objects as my regular - failing - program.

It worked just fine. I was stumped.

Finally, in desperation (I couldn't very well post the working-fine demo program, now could I?), I deleted the NIB file and re-created, from scratch, my GUI. And it worked. Problem disappeared. I was able to get correct retainCount's in the program and in the debugger. (Before, with the bad NIB file, if I used "p (int) [myObject retainCount]" in the debugger I would get a message that "that object does not respond to that message" or something along those lines.

Arg. That was painful.

 

[simplebeep]

Weird. I had a similarly inexplicable interface-related problem. Whenever I tried to set the font of my text box, all the text in it would disappear for thirty seconds. I could still type in it, but the insertion point wouldn't be there, and I couldn't see what I was typing. Thirty seconds later, all the text would come back (including the nonsense keys I had typed in confusion).

Fresh out of ideas, I deleted and re-created the text view, and everything instantly worked perfectly.