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.
[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 swapfile5and 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_mallocI 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?
Received data seems to be invalid. The wanted file does probably not exist or the guys at last.fm changed something.