mikeash.com pyblog/friday-qa-2014-11-07-lets-build-nszombie.html comments

bob - 2014-12-04 09:06:23

Thu, 04 Dec 2014 09:06:23 GMT

I wonder if it would be useful to create a zombie that doesn't prevent deallocation -- it would still catch incorrect message sends for a while, up until the memory gets overwritten. And since it doesn't leak, it can be used in production. What do you think?

Connor Sadler - 2014-11-11 11:29:03

Tue, 11 Nov 2014 11:29:03 GMT

I enjoyed the tags ;]

Brent Royal-Gordon - 2014-11-09 21:10:23

Sun, 09 Nov 2014 21:10:23 GMT

Rather than dynamically installing +initialize and -methodSignatureForSelector:, couldn't you just write an MAZombie base class and have all of your individual zombie classes subclass it? It seems like that would reduce the amount of runtime magic you need to write for each zombie class.

Also, I believe this implementation of zombies won't call -.cxx_destruct, which is used by ARC. Would it be a good idea to call that in ZombieDealloc?

mikeash - 2014-11-08 02:29:53

Sat, 08 Nov 2014 02:29:53 GMT

Rick: The CF stuff is a big problem, and one that NSZombie actually shared for many years. The requirement to call super is related, and I don't think NSZombie will catch that either. Once you start doing custom allocators it's hard to hook stuff reliably. You could swizzle dealloc, but how will you stop the memory from being deallocated? You still need to run the rest of the dealloc code for things to work properly. And you're right, I originally meant to get this article out last week but didn't quite make it!

Konstantin Anoshkin: You're right, we could safely assume there's enough storage for another pointer in the real world. But I didn't like to make that assumption, partly just because it's messy, and partly because there's nothing that says Apple couldn't decide to use a more fine-grained allocator for objects that don't have any extra ivars. In a real implementation, assuming you're only running it for debugging and you check with malloc_size before you start overwriting stuff, it would be fine.

Konstantin Anoshkin - 2014-11-07 20:52:42

Fri, 07 Nov 2014 20:52:42 GMT

"If the original class had no additional instance variables, then there's no space that can be repurposed for storage."

Technically speaking, the granularity of malloc() on Darwin is 16 bytes, which is a minimum space occupied by an Obj-C object (barring evil custom +alloc implementations, of course). The isa variable on a 64-bit system occupies 8 bytes, which still leaves 8 bytes for a pointer to the original class. In other words, that's a great opportunity for optimization for 99.9% cases on all currently supported Apple systems. Just my 2 cents.

Avi Drissman - 2014-11-07 17:40:53

Fri, 07 Nov 2014 17:40:53 GMT

If you want to see a different implementation of zombies, including a treadmill, one that has been hardened by shipping it for years, check out the Chromium version:

https://chromium.googlesource.com/chromium/src/+/master/chrome/common/mac/objc_zombie.mm

Disclosure: I'm on the Chrome team, though I never worked on the zombie implementation.

Rick - 2014-11-07 17:31:27

Fri, 07 Nov 2014 17:31:27 GMT

Cool. Sounds like there's a couple of weak points, though: 1. The CF bridging weirdness you mentioned. 2. Zombify requires a class' dealloc implementation to call super. Could one swizzle dealloc instead? You'd need a place to catch the loading/registering of every class to swizzle its dealloc, though.

Also, this article is a week late. October is for zombies... Now we need articles on NSTurkey. Or NSPumpkinSpiceLatte, or something... :)