Zombie 对象的内部原理

#Original (English)

Source: https://www.mikeash.com/pyblog/friday-qa-2011-05-20-the-inner-life-of-zombies.html

It’s Friday again, that Fridayest of days, and this week that means it’s time for another Friday Q&A. Samuel Goodwin suggested discussing how NSZombie works, and that’s the topic I will discuss today.

Zombie Overview As you may recall, an Objective-C object is just a block of allocated memory. The first pointer-sized chunk of that block is the isa pointer, which points to the object’s class. The rest of the block contains the object’s instance variables.

When an object is deallocated, the block of memory which contains it is freed. Normally this means that it’s simply marked as being available for reuse. If you’ve screwed up and kept a pointer to this deallocated object, many mysterious things can happen.

In some cases, code which tries to use the deallocated object will work just fine. If the deallocated memory hasn’t actually been overwritten yet, it will still behave like a normal Objective-C object.

Frequently, the deallocated memory will be reused to hold a new object. In this case, the old pointer ends up pointing to this new object. Attempts to use the old pointer will send messages to the new object instead, with confusing results. This is why one of the most common symptoms of a memory management error is a mystery object, like a random NSString, showing up where you expected to see something else.

Occasionally, the memory will be overwritten with something that’s not an object, and your code crashes. This is the best outcome of the three, since it fails more quickly and makes it more clear what’s going wrong, but it also tends to be rare.

Zombies greatly improve the diagnostics available for this common scenario. Instead of simply leaving the deallocated memory alone, zombies take it over and replace it with an object which traps all attempts to access it. Thus the term “zombie”: the dead object is resurrected to a sort of unlife. When a zombie object is messaged, it logs an error and crashes, providing a convenient backtrace so you can see exactly where the problem lies.

Using Zombies Zombies can be enabled by setting the NSZombieEnabled environment variable to YES. Run the app in gdb, and it will crash on any attempted access to a dead object. Be careful, though: by default, zombies are never deallocated, so your app’s memory usage can become extremely high.

Another useful option is the Zombies instruments in Instruments. This enables zombies and also tracks objects’ retain counts so that you can go back and see the retain/release activity for any improperly messaged object.

Investigating Zombies Let’s take a look at what these things are doing behind the scenes. To help with the investigation, I wrote a small function to dump the contents of an object:

1
    void Dump(NSString *msg, id obj, int size)
2
    {
3
        NSString *s = [NSString stringWithFormat: @"%@ malloc_size %d - %@", msg, (int)malloc_size(obj), [NSData dataWithBytes: obj length: size]];
4
        printf("%s\n", [s UTF8String]);
5
    }

Let’s create an NSObject and log it before and after being destroyed:

1
    id obj = [[NSObject alloc] init];
2
    int size = malloc_size(obj);
3
    Dump(@"Fresh NSObject", obj, size);
4
    [obj release];
5
    Dump(@"Destroyed NSObject", obj, size);

1
    Fresh NSObject malloc_size 16 - <68046370 ff7f0000 00000000 00000000>
2
    Destroyed NSObject malloc_size 0 - <68046370 ff7f0000 00000000 00000000>

Let’s try another one with zombies enabled:

1
    Fresh NSObject malloc_size 16 - <68046370 ff7f0000 00000000 00000000>
2
    Destroyed NSObject malloc_size 16 - <d0011100 01000000 00000000 00000000>

The second eight bytes is just unused here. Let’s write a quick dummy class that uses it and see how it behaves:

1
    @interface Dummy : NSObject
2
    {
3
        uintptr_t secondEight;
4
    }
5
    @end

1
    @implementation Dummy
2
    - (id)init
3
    {
4
        if((self = [super init]))
5
            secondEight = 0xdeadbeefcafebabeULL;
6
        return self;
7
    }
8
    @end

1
    obj = [[Dummy alloc] init];
2
    size = malloc_size(obj);
3
    Dump(@"Fresh Dummy", obj, size);
4
    [obj release];
5
    Dump(@"Destroyed Dummy", obj, size);

1
    Fresh Dummy malloc_size 16 - <28110000 01000000 bebafeca efbeadde>
2
    Destroyed Dummy malloc_size 0 - <28110000 01000000 bebafeca efbeadde>

Here’s a run with zombies:

1
    Fresh Dummy malloc_size 16 - <28110000 01000000 bebafeca efbeadde>
2
    Destroyed Dummy malloc_size 16 - <e0071100 01000000 bebafeca efbeadde>

1
    NSLog(@"%s", class_getName(object_getClass(obj)));

Let’s see just what this class contains. Here’s a function which will dump out various information about a class:

1
    void DumpClass(Class c)
2
    {
3
        printf("Dumping class %s\n", class_getName(c));
4

5
        printf("Superclass: %s\n", class_getName(class_getSuperclass(c)));
6

7
        printf("Ivars:\n");
8
        Ivar *ivars = class_copyIvarList(c, NULL);
9
        for(Ivar *cursor = ivars; cursor && *cursor; cursor++)
10
            printf("    %s %s %d\n", ivar_getName(*cursor), ivar_getTypeEncoding(*cursor), (int)ivar_getOffset(*cursor));
11
        free(ivars);
12

13
        printf("Methods:\n");
14
        Method *methods = class_copyMethodList(c, NULL);
15
        for(Method *cursor = methods; cursor && *cursor; cursor++)
16
            fprintf(stderr, "    %s %s\n", sel_getName(method_getName(*cursor)), method_getTypeEncoding(*cursor));
17
        free(methods);
18
    }

1
    DumpClass(object_getClass(obj));

1
    Dumping class _NSZombie_Dummy
2
    Superclass: nil
3
    Ivars:
4
        isa # 0
5
    Methods:

What, then, happens when we try to message an instance of this empty class? I put [obj self] in the code after destroying the object and then ran it in gdb. Here’s the result:

1
    2011-05-19 14:42:39.427 a.out[62888:a0f] *** -[Dummy self]: message sent to deallocated instance 0x1001106b0
2

3
    Program received signal SIGTRAP, Trace/breakpoint trap.
4
    0x00007fff82a4d6c6 in ___forwarding___ ()
5
    (gdb) bt
6
    #0  0x00007fff82a4d6c6 in ___forwarding___ ()
7
    #1  0x00007fff82a49a68 in __forwarding_prep_0___ ()
8
    #2  0x0000000100001c49 in main (argc=1, argv=0x7fff5fbff690) at zomb.m:62

The forwarding mechanism is throwing a SIGTRAP because the class doesn’t implement the minimum necessary forwarding methods. What’s logging “message sent to deallocated instance”, though? Let’s put a breakpoint on CFLog and find out:

1
    Breakpoint 2, 0x00007fff82a98327 in CFLog ()
2
    (gdb) bt
3
    #0  0x00007fff82a98327 in CFLog ()
4
    #1  0x00007fff82a4d6c5 in ___forwarding___ ()
5
    #2  0x00007fff82a49a68 in __forwarding_prep_0___ ()
6
    #3  0x0000000100001c49 in main (argc=1, argv=0x7fff5fbff690) at zomb.m:62
7
    (gdb) cont
8
    Continuing.
9
    2011-05-19 15:45:03.905 a.out[62938:a0f] *** -[Dummy self]: message sent to deallocated instance 0x1001106b0

Conclusion Zombies are a really useful tool for debugging memory problems. Under the hood, zombies work by rewriting the object’s isa pointer to point to a special zombie class associated with the original. When a message is sent to an instance of the special zombie class, it gets trapped by the runtime’s message forwarding system which then logs the event and crashes the app.

That wraps things up for today. Come back in two more weeks for the next one, just in time for WWDC. In the meantime, as always, keep sending me your ideas for topics.