Comments on: Using malloc to Debug Memory Misuse in Cocoa http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/ ...so google can index my head. Wed, 08 Feb 2012 15:29:18 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: harry.ee http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/comment-page-1/#comment-199489 harry.ee Tue, 27 Dec 2011 10:13:52 +0000 http://www.friday.com/bbum/?p=1703#comment-199489 Hi Bill, thanks for your blog. It helped me find incompatible designs between Garbage Collector Apps and NSInvocation (while using DO). I have random crashes when I call methods which return objects by reference. If you have any work around, any help will be appreciated. Hi Bill, thanks for your blog.
It helped me find incompatible designs between Garbage Collector Apps and NSInvocation (while using DO).
I have random crashes when I call methods which return objects by reference.
If you have any work around, any help will be appreciated.

]]> By: malloc Debugging : Light Year Blog http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/comment-page-1/#comment-192778 malloc Debugging : Light Year Blog Tue, 12 Jan 2010 21:39:07 +0000 http://www.friday.com/bbum/?p=1703#comment-192778 [...] Debugging Tuesday, January 12, 2010 Bill Bumgarner posted a nice tutorial on using malloc to debug memory misuse in Cocoa. I’ve run across these before when reading the malloc(1) man page, but it’s nice to [...] [...] Debugging Tuesday, January 12, 2010 Bill Bumgarner posted a nice tutorial on using malloc to debug memory misuse in Cocoa. I’ve run across these before when reading the malloc(1) man page, but it’s nice to [...]

]]> By: Sean M http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/comment-page-1/#comment-192765 Sean M Mon, 11 Jan 2010 18:36:49 +0000 http://www.friday.com/bbum/?p=1703#comment-192765 Bill, perhaps you'd have a definitive answer to this: is MallocPreScribble real? This page http://developer.apple.com/mac/library/releasenotes/DeveloperTools/RN-MallocOptions/index.html lists it as a newer feature, but the malloc man page does not mention it. IIRC, it was discussed on an apple list and the conclusion was that MallocPreScribble is bogus and that MallocScribble scribbles with new allocations and when deallocated. Bill, perhaps you’d have a definitive answer to this: is MallocPreScribble real? This page http://developer.apple.com/mac/library/releasenotes/DeveloperTools/RN-MallocOptions/index.html lists it as a newer feature, but the malloc man page does not mention it. IIRC, it was discussed on an apple list and the conclusion was that MallocPreScribble is bogus and that MallocScribble scribbles with new allocations and when deallocated.

]]> By: M. Noel http://www.friday.com/bbum/2010/01/10/using-malloc-to-debug-memory-misuse-in-cocoa/comment-page-1/#comment-192762 M. Noel Mon, 11 Jan 2010 05:07:46 +0000 http://www.friday.com/bbum/?p=1703#comment-192762 Thanks for the very helpful information. In particular, zombies have been a lifesaver for me, especially in the past year. Whenever I've used the leaks tool in the past, legitimate leaks in my own code have been buried beneath objects and strings in Apple frameworks (which I assume are false positives and not actual leaks). It sounds like the tool's been beefed up, and I'll have to give it another shot. I love the retain/release history for zombies in Instruments in 10.6, but it'd be nice to have a way to log retain/release information for my objects during my automated tests. In fact, I'd just settle for a deterministic way to automatically detect Cocoa leaks. Overriding operator new in C++ and using my own CFAllocator for CFTypeRefs has been helpful, but I haven't been able to come up with a surefire way to get that information for Cocoa objects the framework allocates on my behalf (like copied strings). Swizzling alloc/dealloc/retain/release/copy doesn't seem like it would work out very well, especially for class clusters, since unlike C++ operator new they're not actually guaranteed to allocate or deallocate, or even change a ref count. Any ideas? For example, is NSRecordAllocationEvent (from NSDebug.h) useful to third parties, and if so, are there any examples for how we'd use it? Anyhow, if you have any suggestions for how we should automate detecting Cocoa leaks, I'd love to hear it. Thanks for the very helpful information. In particular, zombies have been a lifesaver for me, especially in the past year.

Whenever I’ve used the leaks tool in the past, legitimate leaks in my own code have been buried beneath objects and strings in Apple frameworks (which I assume are false positives and not actual leaks). It sounds like the tool’s been beefed up, and I’ll have to give it another shot.

I love the retain/release history for zombies in Instruments in 10.6, but it’d be nice to have a way to log retain/release information for my objects during my automated tests. In fact, I’d just settle for a deterministic way to automatically detect Cocoa leaks. Overriding operator new in C++ and using my own CFAllocator for CFTypeRefs has been helpful, but I haven’t been able to come up with a surefire way to get that information for Cocoa objects the framework allocates on my behalf (like copied strings). Swizzling alloc/dealloc/retain/release/copy doesn’t seem like it would work out very well, especially for class clusters, since unlike C++ operator new they’re not actually guaranteed to allocate or deallocate, or even change a ref count. Any ideas? For example, is NSRecordAllocationEvent (from NSDebug.h) useful to third parties, and if so, are there any examples for how we’d use it? Anyhow, if you have any suggestions for how we should automate detecting Cocoa leaks, I’d love to hear it.

]]>