25

I appear to have some overzealous releasing going on in my obj-C app - getting error message

"-[myobj release]: message sent to deallocated instance 0x5633b0"

. I know the class of the object instance causing the problem, but this class is used all over to create many instances.

My thought is I could put some logging in the init method of the class to log whatever "0x5633b0" corresponds to which should help me track down where the instance is being created.

What exactly is the "0x5633b0" and is there any way I can get access to that value in the code to log it?

Thanks.

Srikar Appalaraju
  • 71,928
  • 54
  • 216
  • 264

7 Answers7

42

What worked best for me when I ran into similar problems recently was the following:

  1. Under under Project->Edit Active Executable -> Arguments tab -> Environment variables section I added and set to YES the following variables: NSAutoreleaseFreedObjectCheckEnabled, NSZombieEnabled and NSDebugEnabled.

  2. Under the Run menu, I selected Enable Guard Malloc.

With these settings the debugger provided more hints on what's wrong with my code.

(I found these tips here)

Good luck, Ori

Shmidt
  • 16,436
  • 18
  • 88
  • 136
Ori
  • 12,800
  • 4
  • 33
  • 32
  • 5
    Enable Guard Malloc doesn't work when debugging on a device, at least I can't and this post confirm it: https://discussions.apple.com/thread/1572993?start=0&tstart=0 – JeroenEijkhof Aug 21 '11 at 05:23
  • @JeroenEijkhof is right. Guard malloc don't work in device. And they can be enabled in the 'diagnostice' tab, no need to set in env var. But NSAutoreleaseFreedObjectCheckEnabled may need to set as env var. – karim Oct 03 '14 at 08:00
30

0x5633b0 is likely the address of object in question (the value of self). You can use NSLog or printf with %p to print it.

Logan Capaldo
  • 39,555
  • 5
  • 63
  • 78
  • 1
    That was it - I just needed a way to get the address of the object somehow. I added: NSLog(@"INIT %p", self); to my init method and was able to tell which instance was causing the problem. Thanks. –  Mar 02 '09 at 04:08
  • 3
    You can add a breakpoint to : "-[_NSZombie methodSignatureForSelector:]" to make your debugger halt when "message sent to deallocated instance..." is logged. – ıɾuǝʞ Aug 28 '12 at 16:20
  • 1
    hey kenji Can you please help in [_NSZombie methodSignatureForSelector: with some sort of example – Anand Sep 07 '12 at 09:47
13

0x5633b0 is likely the address of the deallocated object (the value of myobj). You can use NSLog or printf with %p to print it.

You can also use the instruments profiler to find the deallocated object.

1. Start the profiler:

enter image description here

2. Select the "Zombies" and start the profiler.

enter image description here

3. Click through the simulator until you hit your "deallocated error case"

enter image description here

leviathan
  • 11,080
  • 5
  • 42
  • 40
11

In the debugger, type info symbol 0x5633b0 and you'll get some indication as to what object it is. One other thing that might be helpful is backtrace which will give you a stack trace. All in all, this blog entry has some great tips.

bbrown
  • 6,370
  • 5
  • 37
  • 43
  • 3
    With `lldb` is `image lookup --address 0x1ec4` or the short version `im loo -a 0x1ec4`. – amb Jan 29 '13 at 20:25
0

Consider using the NSZombieEnabled flag.

You will then know what is this deallocated object you're sending a message.

Community
  • 1
  • 1
nst
  • 3,862
  • 1
  • 31
  • 40
0

you can also add these to environment variables:
MallocStackLoggingNoCompact 1

and write in the gdb console:
info malloc-history <paste-address-here>

Reference: here

rptwsthi
  • 10,094
  • 10
  • 68
  • 109
LolaRun
  • 5,526
  • 6
  • 33
  • 45
-12

You're not managing your memory properly -- you're calling release/autorelease on some object more times than you're calling retain. Make sure you're following all of the rules laid out in the Memory Management Programming Guide for Cocoa.

0x5633b0 is just the address of the memory location at which the object is stored. One thing you can try to do is to add some code to the init method:

- (void) init
{
    if(self == (MyClass*)0x5633b0)
        NSLog(@"Allocated object at address 0x5633b0");  // put a breakpoint on this line
    // do rest of init...
}

If you have any other init methods (e.g. initWithCoder:, which is called for objects instantiated from a XIB), make sure to put this snippet in those methods as well. Put a breakpoint on the NSLog line, and then see when it gets hit. Note that it may get hit several times, if an object is allocated at that address, deallocated, and then another object happens to be reallocated at the same address. The last hit before the crash is the one you want.

Adam Rosenfield
  • 390,455
  • 97
  • 512
  • 589
  • 13
    How do you know the symbol's address beforehand? Isn't it different each time you run the code. At least that's I've noticed. Using something like "info symbol 0xabcdfg" in the debugger console gave me better results than your probosal. – leviathan Jan 18 '11 at 10:15