I don't do any C programming any more, but I certainly remember that tracking down memory allocation problems was a large part of my debugging work. Obviously I'm not the only one who makes such programming errors; a Google search in that area will turn up all kinds of tools and debuggers to help track these things down.
Mac OS X has a few command line tools that can help, too. There are graphical tools as well, of course.
malloc_history lists malloc allocations for a program. You set and export a few environment variables, run the suspect program, and then run malloc_history against its pid. Here we look at part of a "vi session":
$ sudo malloc_history 5146 -all_by_size | head 1 calls for 131072 bytes: thread_a000ef98 |0x0 | 0x209c | 0x21fc | 0x5fe68 | 0xa496c | malloc 1 calls for 4096 bytes: thread_a000ef98 |0x0 | 0x209c | 0x21fc | 0x61638 | 0x2a14 | 0x66628 | 0x69b18 | 0x65538 | 0x65e0c | 0x7b3dc | malloc 1 calls for 4096 bytes: thread_a000ef98 |0x0 | 0x209c | 0x21fc | 0x61638 | 0x2a14 | 0x66688 | 0x69aa4 | 0x65538 | 0x65e0c | 0x7b3dc | malloc 1 calls for 4096 bytes: thread_a000ef98 |0x0 | 0x209c | 0x21fc | 0x61638 | 0x2a14 | 0x66508 | 0x65538 | 0x65e0c | 0x7b3dc | malloc 1 calls for 4096 bytes: thread_a000ef98 |0x0 | 0x209c | 0x21fc | 0x61638 | 0x2afc | 0x4c398 | 0x68bc8 | 0x69aa4 | 0x65538 | 0x65e0c | 0x7b3dc | malloc
leaks searches the memory of a process for unreferenced buffers. Again we look at a vi session:
$ leaks 5573 Process 5573: 2824 nodes malloced Process 5573: 1 leaks Leak: 0x00401380 size=16 0x00000000 0x00000000 0x00000000 0x00000000 Call stack: [thread 21fb]: | 0x0 | 0x209c | 0x21fc | 0x60ed0 | 0xd1078 | 0xd0cf0 | 0x9c530 | 0x7b4c0 | 0x7b3dc | malloc
vmmap displays the virtual memory of a process. Looking at the same "vi":
$ vmmap 5573 | grep MALLOC MALLOC_LARGE 00187000-001a7000 [ 128K] rw-/rwx SM=NUL DefaultMallocZone_0x400000 MALLOC_TINY (freed?) 00200000-00305000 [ 1044K] rw-/rwx SM=COW MALLOC_TINY 00400000-00505000 [ 1044K] rw-/rwx SM=COW DefaultMallocZone_0x400000 MALLOC (freed?) 00800000-01008000 [ 8224K] rw-/rwx SM=COW MALLOC 01800000-02008000 [ 8224K] rw-/rwx SM=COW DefaultMallocZone_0x400000 MALLOC [ 18664K]
Finally, heap gives us another view of the mallocs for that "vi":
$ heap 5573 Process 5573: 1 zones Zone DefaultMallocZone_0x400000: Overall size: 9396KB; 2824 nodes malloced for 576KB (6% of capacity); largest unused: [0x0180de00-8168KB] All zones: 2824 nodes malloced - 576KB Zone DefaultMallocZone_0x400000: 2824 nodes - Sizes: 128KB[1] 8KB[1] 4KB[4] 3584[1] 2560[1] 2048[5] 1536[3] 1024[9] 512[1] 416[1] 352[1] 336[1] 320[1] 288[3] 256[1] 240[1] 224[2] 208[1778] 192[5] 176[1] 160[7] 144[3] 128[4] 112[1] 96[11] 80[20] 64[64] 48[44] 32[227] 16[622] All zones: 2824 nodes malloced - Sizes: 128KB[1] 8KB[1] 4KB[4] 3584[1] 2560[1] 2048[5] 1536[3] 1024[9] 512[1] 416[1] 352[1] 336[1] 320[1] 288[3] 256[1] 240[1] 224[2] 208[1778] 192[5] 176[1] 160[7] 144[3] 128[4] 112[1] 96[11] 80[20] 64[64] 48[44] 32[227] 16[622] Can't get the ObjC classes for 5573 ----------------------------------------------------------------------- <not Objective C object> = 2824 (588816 bytes)
Got something to add? Send me email.
More Articles by Tony Lawrence © 2009-11-07 Tony Lawrence
I am not out to destroy Microsoft, that would be a completely unintended side effect. (Linus Torvalds)
Printer Friendly Version
Memory leaks Copyright © December 2005 Tony Lawrence
Have you tried Searching this site?
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more.
Contact us
Printer Friendly Version