902 words
Memory leaks are an evil topic when programming. I always strongly disliked the fact that you have to allocate and free memory yourself and make sure you don't lose your pointers to it in the meantime. However, since getting to know Cocoa programming and its semi-manual memory management concept I am much more comfortable with that aspect. You have simple rules regarding how you retain and release your object which you can stick to without too much hassle.
Apart from the alleged advantages in performance (which I don't know too much about – but have heard that doing a lot of autoreleaseing may slow down things as well), this approach still forces me to keep an eye on where my objects come from and go to. Thus, hopefully encouraging a more organised programming style and less sloppiness than I could get away with if I had full garbage collection at my service.
Recently, Dave pointed me to the leaks tool to make the point that programs like Safari or iTunes aren't free of memory leaks:
[kola114:~] ssp% leaks Safari Process 2106: 318875 nodes malloced for 77752 KB Process 2106: 612 leaks for 29024 total leaked bytes. ... [kola114:~] ssp% leaks iTunes Process 668: 64145 nodes malloced for 18385 KB Process 668: 1365 leaks for 94864 total leaked bytes. ... [kola114:~] ssp% leaks Finder Process 709: 94168 nodes malloced for 10964 KB Process 709: 1435 leaks for 125712 total leaked bytes.Whatever these numbers mean, it seems like the programs aren't perfect and the problem causing this is seemingly easy to track down. Despite this, those leaks don't look major enough to me to explain why OSX uses horrendous amounts of memory. Currently it clogs about 2GB of my hard drive with swap files
[kola114:~] ssp% ls -smk1 /var/vm
0 app_profile
65536 swapfile0
65536 swapfile1
131072 swapfile2
262144 swapfile3
524288 swapfile4
1048576 swapfile5
and I am not running any memory intensive applications right now. Activity Monitor claims that I am using 630MB of my RAM and 5,3GB of virtual memory. I still fail to comprehend what any of these numbers mean. Memory numbers were easy to understand in OS9. They are not in OSX – and they're much larger. A text or even program demonstrating what's actually going on in my computer's memory would be nice. An OS not pretending to use tons of memory would be even nicer.
Once I knew about the leaks tool, I ran it against my own applications. Indeed it turned out that my code wasn't perfect in that respect – no surprises there. As the tool can also output stack traces of the times when the allocations causing this are made, tracking down the leaks wasn't too hard. – Embarrassingly it turned out that two of my classes forgot to call [super dealloc] in their own dealloc methods. That was a stupid mistake – but probably so are most memory leaks.
Of course I fixed this right away, giving XCode a test ride in the process – coming to think that it's just fine for my light-core coding purposes; the search and documentation features are neat. An updated version of Rechnungs Checker will be available soon. While I am very much in favour of programming done right in principle, I wonder to which extent this is really worth the trouble in practice: Rechnungs Checker has a very limited scope and thus user base – people who use MacOS X and get Deutsche Telekom online phone bills. While its scope can probably be extended without too much effort to read electronic phone bills from other companies, this hasn't happened yet as nobody asked for it and provided me with sample files. In addition, the program will most likely be used once a month on moderately sized data. Even on heavy usage the total leak should remain in the range of a few dozen KB. So the fix probably may not even be worth the hassle of the download for many people.
Unfortunately the results for the program still aren't perfect. Sometimes I see the following results:
[kola114:~] ssp% leaks Rechnungs\ Checker
Process 4661: 24541 nodes malloced for 1934 KB
Process 4661: 2 leaks for 240 total leaked bytes.
Leak: 0x00621870 size=160
0x0000000c 0x00000001 0x00000000 0x0000001f
0x90aa9934 0x00621820 0x0000003b 0x93064f30
0x003fecf0 0x00000043 0x93064f30 0x003fe640
0x00000045 0x93064f30 0x003fe640 0x0000002e
0x93064f30 0x003e6410 0x00000031 0x93064f30
0x003f7240 0x00000032 0x93064f30 0x00617490
0x00000033 0x93064f30 0x003758d0 0x00000001
0x0061bc60 0x00000001 0x006215b0 0x00000001
...
Call stack: [thread 7c7f]: | 0x0 | start | _start | main
| NSApplicationMain | -[NSApplication run]
| -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
| _DPSNextEvent | BlockUntilNextEventMatchingListInMode
| ReceiveNextEventCommon | RunCurrentEventLoopInMode
| CFRunLoopRunSpecific | __CFRunLoopRun
| __CFRunLoopDoObservers | _handleWindowNeedsDisplay
| -[NSWindow displayIfNeeded] | -[NSView displayIfNeeded]
| -[NSView _propagateDirtyRectsToOpaqueAncestors]
| -[NSViewHierarchyLock lockForReadingWithExceptionHandler:]
| _NSAddExceptionHandlerForLock | _NSAddAltHandler2
| malloc_zone_malloc
Leak: 0x00621820 size=80
0x00000008 0x00000000 0x003ff340 0x00000000
0x0000357b 0x00000000 0x00000000 0x0000c1d3
0xa1b1c1d3 0x00000000 0x00000000 0x00000000
0x00000000 0xa35d24d4 0x00000000 0x00000000
0x0000357b 0x00000000 0x00000000 0x00000000
Call stack: [thread 7c7f]: | 0x0 | start | _start | main
| NSApplicationMain | -[NSApplication run]
| -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
| _DPSNextEvent | BlockUntilNextEventMatchingListInMode
| ReceiveNextEventCommon | RunCurrentEventLoopInMode
| CFRunLoopRunSpecific | __CFRunLoopRun
| __CFRunLoopDoObservers | _handleWindowNeedsDisplay
| -[NSWindow displayIfNeeded] | -[NSView displayIfNeeded]
| -[NSView _propagateDirtyRectsToOpaqueAncestors]
| -[NSViewHierarchyLock lockForReadingWithExceptionHandler:]
| _NSAddExceptionHandlerForLock
| malloc_zone_malloc
I don't know what that's supposed to tell me. It doesn't tell me the class that causes the problem and the stack traces look like they are inside Cocoa's realm and none of my business. Any takers?