Demo Analysis of Linux Debug tool glibc-core dump double free "go"

Transferred from: http://www.cnblogs.com/jiayy/p/3475544.html

By accident, the following two ends of code do not behave the same as void main () {void* P1 = malloc (+);      free (p1); Free (p1);　　A double free error is reported here, and the program exits}void main () {void* P1 = malloc (32);　　void* P2 = malloc (32);　　Free (p1);　　Free (p2); Free (p1); Normal no error free (p2);//Normal, no error ...} I began to wonder, glibc malloc library to doublefree error detection so silly B, only two consecutive free pointers can be detected?　　Then another attempt was made to memset overflow condition, as follows void Main () {void* P1 = malloc (32); memset (p1,1,64); Here overflowed the P1 void* P2 = malloc (32);   printf ("p1=%p,p2=%p\n", P1,P2); Print found, malloc did not detect memset overflow effect} After searching, found that the original GLIBC malloc Library has an environment variable malloc_check_, when its value is 0, for the above two cases (discontinuous free the same period of virtual memory, Memset overflow) is not detected, when I set its value to 1/2/3, the above situation will be normal error. After this test, we recommend that in the development process, it is best to set the Malloc_check_ to 0, wait until the release, the value is set to 0 increase speed. The following is the GLIBC MALLOC debugging related environment variables or tool description, is a good reference     (GO) a) Malloc_check_ gnu standard library (GLIBC) Dynamic memory can be debugged through the built-in debugging features, it is the MALLOC_CHECK_ environment variable, it is not set by default, in the old version of the default value is 0, the new version defaults to 2, but there is a contradiction, if set to NULL, it will print a long trace information, This is set to 2 in more detail.  malloc_check_ has three settings, namely: malloc_check_=0-----Close all checks. Malloc_check_=1-----Print error message on standard error output (STDERR) when an error is detectedmalloc_check_=2-----When an error is detected, the error message is not displayed, and the interrupt is .  . We use the following small program to do the test, the source program is as follows: #include <stdio.h># Include <stdlib.h> int main (int argc,char *argv[]) {        int i;        char* p = (char *) malloc (;  )      char* pt = p;      & nbsp  for (i = 0;i < 10;i++)         {               &N Bsp;p[i] = ' Z ';        }        free (p);       &NBS P;free (PT);        return 0;} GCC Double-free.c-o double-free  Note: This program releases two pointers. Echo $MALLOC _check_  We execute the test program with the Malloc_check_ default setting, Output the following information:  ./test *** glibc detected * * */test:double free or corruption (fasttop): 0x0890f008 ***======= Backtr Ace: =========/lib/libc.so.6[0x175f7d]/lib/libc.so.6 (cfree+0x90) [0x1795d0]./test[0x80483dc]/lib/libc.so.6 (__ Libc_start_MAIN+0XDC) [0x125dec]./test[0x8048301]======= Memory map: ========00110000-00247000 R-xp 00000000 08:01 3704502   & nbsp;/lib/libc-2.5.so00247000-00249000 r-xp 00137000 08:01 3704502    /lib/libc-2.5.so00249000-0024a000 RWXP 00139000 08:01 3704502    /lib/libc-2.5.so0024a000-0024d000 rwxp 0024a000 00:00 0 00b51000-00b6a000 R-xp 00000000 08:01 3704501    /lib/ld-2.5.so00b6a000-00b6b000 r-xp 00018000 08:01 3704501   &NBSP;/LIB/LD -2.5.so00b6b000-00b6c000 rwxp 00019000 08:01 3704501    /lib/ld-2.5.so00bf3000-00bf4000 r-xp 00bf3000 00:00 0 & nbsp        [vdso]00dab000-00db6000 R-xp 00000000 08:01 3704511   &NBSP;/LIB/LIBGCC_ s-4.1.1-20070105.so.100db6000-00db7000 rwxp 0000a000 08:01 3704511   &NBSP;/LIB/LIBGCC_ s-4.1.1-20070105.so.108048000-08049000 R-xp 00000000 08:01 327681    /root/test08049000-0804a000 rw-p 00000000 08:01 327681    /root/test0890f000-08930000 rw-p 0890f000 00:00 0  b7e00000-b7e21000 rw-p b7e00000 00:00 0 b7e21000-b7f00000---p b7e21000 00:00 0 b7f26000-b7f27000 rw-p b7f26000 00:00 0 b7f3b000-b7f3c000 rw-p b7f3b000 00:00 0 bfdcf000-bfde4000 rw-p bfdcf000 00:00 0     & nbsp    [stack]Aborted  Here we adjust malloc_check_ to 0, run the program again, as follows: Export malloc_check_=0./test  Note: We see that the program does not have any output .  we will adjust the Malloc_check_ to 1, run the program again, as follows: Export malloc_check_=1./test malloc:using debugging hooks* * * GLIBC Detected * * * *./test:free (): Invalid pointer:0x0811e008 * * Note: We see the output of malloc:using debugging hooks each time the program is run, and the program checks Test to free () Two release problem .  we will malloc_check_ to 2, run the program again, as follows: Export malloc_check_=2./test aborted Note: We see that the program only outputs the aborted, and interrupts the program's run .    two) using Mtrace to find memory leaks  mtrace is a tool provided by GLIBC, Pack it in the Glibc-utils package in Redhat .  We install this package as follows:rpm-ivh/mnt/server/glibc-utils-2.5-12.i386.rpm  The primary role of Mtrace is to find memory leaks, and in order to apply mtrace programs, the functions Mtrace and muntrace provided by glibc must be used in code. In addition, you must set the name of a file to the environment variable malloc_trace, Because GLIBC uses it to store data for the Mtrace program. When the code is executed, the data will be there for this confirmationFile, each time the program is executed, the contents of this file will be rewritten .  we test it with the following code,:  #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <mcheck.h>  int main (int argc,char *argv[]) {         Setenv ("Malloc_trace", "Output", 1);        mtrace ();        int i;         char* p = (char *) malloc (;        char* pt = P;&NBSP;&NBSP;&N Bsp      for (i = 0;i < 10;i++)         {           &N Bsp    p[i] = ' Z ';        }        return 0;}   Compilation: gcc test.c-o test  Note: The program uses the SETENV function to set the environment variable malloc_trace  run the program:./test   A file named output is generated in the current directory, as follows: Cat output = start@/TEST:[0X80483F2] + 0x82ba438 0xa@/lib/libc.so.6: (clearenv+ 0X7C) [0xb9910c]-0x82ba008@/lib/libc.so.6: (tdestroy+0x47) [0xc39b77]-0x82ba090@/lib/libc.So.6: (tdestroy+0x4f) [0xc39b7f]-0x82ba0b0  uses mtrace to find memory leaks, it tells us that the memories are not freedmtrace output -0x082ba008 Free 3 is never alloc ' d 0xb9910c-0x082ba090 free 4 is never alloc ' d 0xc39b77-0x082ba0b0 free 5 was never alloc ' d 0xc39 B7f memory not freed:-----------------   Address     Size     caller0x082ba438     &NBSP;0XA  at 0x80483f2     three) use Memusage to collect memory statistics   Memusage does not need to make any instructions in the Code. This tool also comes from the glibc-utils package. It uses a column to show how much memory the program consumes. It is output to standard output by default and displays a picture-like column in ASCII text. As follows: Memusage awk ' Begin{print "Hello World"} ' Hello World memory usage summary:heap total:7487, heap peak:6891, Stack peak:8624&nbsp ;        Total calls   Total memory   failed calls malloc|         $           7487             &NBSP;0RE alloc|          0              0     &NBSp        0   (nomove:0, dec:0, free:0)  calloc|          0              0           & nbsp  0   free|         sizes:              797histogram for block  0-              46% ==================================================    16-31              7  12% ============   32-47     &NBS P        2   3% ===   48-63              6  10% = ==========   64-79              1   1% =   80-95              1   1% =   96-111             1   1% =  112-127             4   6% =======  160-175             1   1% =   176-191             2   3% ===  192-207         &NB Sp   1   1% =  208-223             2   3% ===  384-399 &nbsp ;           1   1% =  480-495             1   1% = 4000-4015            1   1% =     IV) use electric fence to detect memory leaks & nbsp Electric Fence uses some clever techniques to detect overflow of the program on the heap memory area, without the need to modify the code with Electric fence, instead, it provides a dynamic library with multiple dynamic allocation functions. A script called EF is used to handle environment variables Ld_ Preload settings, we can use the EF command to invoke the program .  below is the installation electric Fence, as follows: rpm-ivh/mnt/server/electricfence-2.2.2-20.2.2.i386.rpm   Below we use a small program to do the test, the source code is as follows: #include <string.h> intmain (int argc, char *argv[]) {       & Nbsp;int *ptr = new int;     &nbsp  memset (PTR, 0, sizeof (int) + 1);        delete ptr;}   Compile: g++ new-corrupt.cpp-o new-corrupt Note: This applet causes a boundary overflow .  execution Program:./new-corrupt Note: The program does not have any instructions .   We use EF to execute this program, as follows: EF./new-corrupt      electric Fence 2.2.0 Copyright (C) 1987-1999 Bruce Perens <[email protected]>/usr/bin/ef:line:  4148 Segmentation fault       (export ld_ preload=libefence.so.0.0; EXEC $*) Note: There is output information, it tells us that there is a segmentation {sensitive word}t, and indicate in which line the problem occurs .  we can also use electric fence and GDB, as follows: Compile the program and specify the-G option g++-G New-corrupt.cpp-o new-corrupt   Open the program with GDB as follows: GdB./new-corruptgnu gdb Red Hat Linux (6.5-16.EL5RH) Copyright (C ) 2006 free software Foundation, inc.gdb are free software, covered by the GNU general public License, and you arewelcome t o change it and/or distribute copies of it under certain conditions. Type "Show copying" to see the conditions. There is absolutely no warranty for GDB.  type "Show warranty" for details. This GDB is configured as "I386-redhat-linux-gnu" ... Using host libthread_db Library "/lib/libthread_db.so.1" .  (GDB) Set environment Ld_preload libefence.so.0.0              /* setting environment variable ld_preload to libefence.so.0.0*/(GDB) run         &NBSP ;                          ,         &NB Sp        /* running programs */starting program:/root/new-corrupt    electric Fence 2.2.0 Copyright (c) 1987-1999 Bruce Perens <[email protected]>   electric Fence 2.2.0 Copyright (c) 1987-1999 Bruce Perens <[email protected]> program received signal SIGSEGV, segmentation FAULT.0X0804849D in Main () at New-corrupt.cpp:7                    /* Find out when calling the Memset function to cause an out-of-bounds */7               memset (PTR, 0, sizeof (int) + 1);(gdb) QUIT&NBSP; Below we do not specify an environment variable in GDB, we see that GDB does not print out the relevant error message. gdb./new-corruptgnu gdb Red Hat Linux (6.5-16.EL5RH) Copyright (C) 2006 free Software Foundation, Inc.gdb is free software, covered by the GNU general public License, and your arewelcome to change it and/or distribute copies of it under certain conditions. Type "Show copying" to see the conditions. There is absolutely no warranty for GDB.  type "Show warranty" for details. This GDB is configured as "I386-redhat-linux-gnu" ... Using host libthread_db Library "/lib/libthread_db.so.1" .  (GDB) runstarting program:/root/new-corrupt   program exited normally.

Linux Debugging Tools glibc Demo Analysis-core dump double free "go"