用戶空間工具：

• 內存工具：MEMWATCH 和 YAMD
• strace
• GNU 調試器（gdb）
• 魔術鍵控順序

內核工具：

• 內核源代碼級調試器（kgdb）
• 內建內核調試器（kdb）
• Oops

            #include <stdlib.h>
            #include <stdio.h>
            #include "memwatch.h"
            int main(void)
            {
            char *ptr1;
            char *ptr2;
            ptr1 = malloc(512);
            ptr2 = malloc(512);
            ptr2 = ptr1;
            free(ptr2);
            free(ptr1);
            }
            

            gcc -DMEMWATCH -DMW_STDIO test1.c memwatch
            c -o test1
            

            MEMWATCH 2.67 Copyright (C) 1992-1999 Johan Lindh
            ...
            double-free: <4> test1.c(15), 0x80517b4 was freed from test1.c(14)
            ...
            unfreed: <2> test1.c(11), 512 bytes at 0x80519e4
            {FE FE FE FE FE FE FE FE FE FE FE FE ..............}
            Memory usage statistics (global):
            N)umber of allocations made: 	2
            L)argest memory usage : 	1024
            T)otal of all alloc() calls: 	1024
            U)nfreed bytes totals : 	512
            

            gcc -g test1.c -o test1
            

            YAMD version 0.32
            Executable: /usr/src/test/yamd-0.32/test1
            ...
            INFO: Normal allocation of this block
            Address 0x40025e00, size 512
            ...
            INFO: Normal allocation of this block
            Address 0x40028e00, size 512
            ...
            INFO: Normal deallocation of this block
            Address 0x40025e00, size 512
            ...
            ERROR: Multiple freeing At
            free of pointer already freed
            Address 0x40025e00, size 512
            ...
            WARNING: Memory leak
            Address 0x40028e00, size 512
            WARNING: Total memory leaks:
            1 unfreed allocations totaling 512 bytes
            *** Finished at Tue ... 10:07:15 2002
            Allocated a grand total of 1024 bytes 2 allocations
            Average of 512 bytes per allocation
            Max bytes allocated at one time: 1024
            24 K alloced internally / 12 K mapped now / 8 K max
            Virtual program size is 1416 K
            End.
            

            #include <stdlib.h>
            #include <stdio.h>
            int main(void)
            {
            char *ptr1;
            char *ptr2;
            char *chptr;
            int i = 1;
            ptr1 = malloc(512);
            ptr2 = malloc(512);
            chptr = (char *)malloc(512);
            for (i; i <= 512; i++) {
            chptr[i] = ‘S‘;
            }
            ptr2 = ptr1;
            free(ptr2);
            free(ptr1);
            free(chptr);
            }
            

            Running /usr/src/test/test2/test2
            Temp output to /tmp/yamd-out.1243
            *********
            ./run-yamd: line 101: 1248 Segmentation fault (core dumped)
            YAMD version 0.32
            Starting run: /usr/src/test/test2/test2
            Executable: /usr/src/test/test2/test2
            Virtual program size is 1380 K
            ...
            INFO: Normal allocation of this block
            Address 0x40025e00, size 512
            ...
            INFO: Normal allocation of this block
            Address 0x40028e00, size 512
            ...
            INFO: Normal allocation of this block
            Address 0x4002be00, size 512
            ERROR: Crash
            ...
            Tried to write address 0x4002c000
            Seems to be part of this block:
            Address 0x4002be00, size 512
            ...
            Address in question is at offset 512 (out of bounds)
            Will dump core after checking heap.
            Done.
            

            execve("/sbin/mkfs.jfs", ["mkfs.jfs", "-f", "/dev/test1"], &
            ...
            open("/dev/test1", O_RDWR|O_LARGEFILE) = 4
            stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0
            ioctl(4, 0x40041271, 0xbfffe128) = -1 EINVAL (Invalid argument)
            write(2, "mkfs.jfs: warning - cannot setb" ..., 98mkfs.jfs: warning -
            cannot set blocksize on block device /dev/test1: Invalid argument )
            = 98
            stat64("/dev/test1", {st_mode=&, st_rdev=makedev(63, 255), ...}) = 0
            open("/dev/test1", O_RDONLY|O_LARGEFILE) = 5
            ioctl(5, 0x80041272, 0xbfffe124) = -1 EINVAL (Invalid argument)
            write(2, "mkfs.jfs: can\‘t determine device"..., ..._exit(1)
            = ?
            

            set -x
            rcp best@sfb: /usr/src/linux-2.4.17/arch/i386/boot/bzImage /boot/bzImage-2.4.17
            rcp best@sfb:/usr/src/linux-2.4.17/System.map /boot/System.map-2.4.17
            rm -rf /lib/modules/2.4.17
            rsync -a best@sfb:/lib/modules/2.4.17 /lib/modules
            chown -R root /lib/modules/2.4.17
            lilo
            

            int jfs_mount(struct super_block *sb)
            {
            ...
            int ptr; 			/* line 1 added */
            jFYI(1, ("\nMount JFS\n"));
            / *
            * read/validate superblock
            * (initialize mount inode from the superblock)
            * /
            if ((rc = chkSuper(sb))) {
            goto errout20;
            }
            108 	ptr=0; 			/* line 2 added */
            109 	printk("%d\n",*ptr); 	/* line 3 added */
            

            mount -t jfs /dev/sdb /jfs
            Program received signal SIGSEGV, Segmentation fault.
            jfs_mount (sb=0xf78a3800) at jfs_mount.c:109
            109 		printk("%d\n",*ptr);
            (gdb)where
            #0 jfs_mount (sb=0xf78a3800) at jfs_mount.c:109
            #1 0xc01a0dbb in jfs_read_super ... at super.c:280
            #2 0xc0149ff5 in get_sb_bdev ... at super.c:620
            #3 0xc014a89f in do_kern_mount ... at super.c:849
            #4 0xc0160e66 in do_add_mount ... at namespace.c:569
            #5 0xc01610f4 in do_mount ... at namespace.c:683
            #6 0xc01611ea in sys_mount ... at namespace.c:716
            #7 0xc01074a7 in system_call () at af_packet.c:1891
            #8 0x0 in ?? ()
            (gdb)
            

            ksymoops 2.4.0 on i686 2.4.17. Options used
            ... 15:59:37 sfb1 kernel: Unable to handle kernel NULL pointer dereference at
            virtual address 0000000
            ... 15:59:37 sfb1 kernel: c01588fc
            ... 15:59:37 sfb1 kernel: *pde = 0000000
            ... 15:59:37 sfb1 kernel: Oops: 0000
            ... 15:59:37 sfb1 kernel: CPU:    0
            ... 15:59:37 sfb1 kernel: EIP:    0010:[jfs_mount+60/704]
            ... 15:59:37 sfb1 kernel: Call Trace: [jfs_read_super+287/688]
            [get_sb_bdev+563/736] [do_kern_mount+189/336] [do_add_mount+35/208]
            [do_page_fault+0/1264]
            ... 15:59:37 sfb1 kernel: Call Trace: [<c0155d4f>]...
            ... 15:59:37 sfb1 kernel: [<c0106e04 ...
            ... 15:59:37 sfb1 kernel: Code: 8b 2d 00 00 00 00 55 ...
            >>EIP; c01588fc <jfs_mount+3c/2c0> <=====
            ...
            Trace; c0106cf3 <system_call+33/40>
            Code; c01588fc <jfs_mount+3c/2c0>
            00000000 <_EIP>:
            Code; c01588fc <jfs_mount+3c/2c0>  <=====
            0: 8b 2d 00 00 00 00 	mov 	0x0,%ebp    <=====
            Code; c0158902 <jfs_mount+42/2c0>
            6:  55 			push 	%ebp
            

            109	printk("%d\n",*ptr);
            objdump jfs_mount.o
            jfs_mount.o: 	file format elf32-i386
            Disassembly of section .text:
            00000000 <jfs_mount>:
            0:55 			push %ebp
            ...
            2c:	e8 cf 03 00 00	   call	   400 <chkSuper>
            31:	89 c3 	  	    	mov     %eax,%ebx
            33:	58		    	pop     %eax
            34:	85 db 	  	    	test 	%ebx,%ebx
            36:	0f 85 55 02 00 00 jne 	291 <jfs_mount+0x291>
            3c:	8b 2d 00 00 00 00 mov 	0x0,%ebp << problem line above
            42:	55			push 	%ebp
            

您肯定不想陷入類似在幾千次調用之后發(fā)生分配溢出這樣的情形,。

我們的小組花了許許多多時間來跟蹤稀奇古怪的內存錯誤問題。應用程序在我們的開發(fā)工作站上能運行,，但在新的產品工作站上,，這個應用程序在調用 malloc() 兩百萬次之后就不能運行了。真正的問題是在大約一百萬次調用之后發(fā)生了溢出,。新系統(tǒng)之所有存在這個問題,，是因為被保留的 malloc() 區(qū)域的布局有所不同，從而這些零散內存被放置在了不同的地方,，在發(fā)生溢出時破壞了一些不同的內容,。

我們用多種不同技術來解決這個問題，其中一種是使用調試器,，另一種是在源代碼中添加跟蹤功能,。在我職業(yè)生涯的大概也是這個時候，我便開始關注內存調試工具,，希望能更快更有效地解決這些類型的問題,。在開始一個新項目時，我最先做的事情之一就是運行 MEMWATCH 和 YAMD,，看看它們是不是會指出內存管理方面的問題,。

內存泄漏是應用程序中常見的問題，不過您可以使用本文所講述的工具來解決這些問題,。