Analysis of Memcheck Report of debug artifact Valgrind

Memcheck how to run

Valgrind--log-file=valgrind.log--tool=memcheck--leak-check=full--show-reachable=no--workaround-gcc296-bugs=yes ./mcsample arg1 Arg2

–log-file represents the output report file, which can be a relative path or a full path
–tool=memcheck do memory detection is Memcheck, you know Valgrind is a tool set
–leak-check=full Full Test
–show-reachable=no whether the display reachable see the memory leaks section, usually no, can also be changed to Yes
–workaround-gcc296-bugs=yes If your gcc has a corresponding bug, set it to Yes, or it will be reported
Finally, the detected program and its parameters. What do you think of Memcheck report? first, an unexpected mistake.

int main (int argc, char *argv[])
{
    char* bigbuff = (char*) malloc[1024];
    Free (bigbuff);
}

==3498== Invalid Free ()/delete/delete[]/realloc ()
==3498== at    0x402b06c:free (In/usr/lib/valgrind/vgpreloa d_memcheck-x86-linux.so)
==3498== by    0x8048444:main (main.cpp:19)
==3498== address  0x40c0500 The Text segment of/lib/i386-linux-gnu/libc-2.15.so

The code incorrectly writes malloc () as malloc[], which is equivalent to getting the address behind the malloc function pointer, which tells us that this address is located in the. Text segment.

You can see that the basic format of the report is:

{Problem description}   
At {address, function name, module or line of code} by 
{address, function name, line of code} by
... {The call stack is displayed on a per-layer basis}
Address 0x???????? {describes the relative relationship of addresses}

The overall format of the report's output document can be summed up as:

1. Copyright Notice
2. Exception read-write report
2.1 Main thread exception read-write
2.2 Thread A exception read-write report
2.3 thread B Exception read-write report
2. Other Threads
3. Heap Memory leak report
3.1 Heap Memory usage overview (HEAP SUMMARY)
3.2 assured memory leak report (definitely lost)
3.3 Suspicious Memory Operation report (Show-reachable=no shutdown)
3.4 Disclosure Overview (leak SUMMARY)

What are the common exception reports Memory Leaks

int main (int argc, char *argv[])
{
    char* bigbuff = (char*) malloc (1024);
}

1,024 bytes in 1 blocks are definitely lost in loss record 1 of 1 at
 0x402be68:malloc (in/usr/lib/valgrind/vgpreload _memcheck-x86-linux.so) by
 0x8048414:main (main.cpp:17)

Definitely lost: Memory is not released and no pointers are pointing here. Must have leaked out. The stack that is reported is the call stack when memory is allocated, and it can basically specify what business logic the memory is created from.
Still reachable: It is said that memory is not released, although there is still a pointer pointing, memory is still in use, this can not be a leak. (asynchronous system calls that are still working when the program exits?)
Possibly lost: is to say that there may be leaks, generally have a level two pointer (pointer) and other complex situations are not easy to trace when the appearance.
Suppressed: Some of the parameters that use Valgrind to cancel some of the errors in a particular library will be attributed to the abnormal release here

int main (int argc, char *argv[])
{
    char* bigbuff = (char*) malloc (1024);
    char* Offsetbuff = bigbuff + 888;
    Free (offsetbuff);
}

Invalid free ()/delete/delete[]/realloc () at
  0x402b06c:free (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux. So) by
  0x8048461:main (main.cpp:24) address 0x41f23a0 are 888 bytes inside a block of the
 size 1,024 alloc ' d at
  0x 402be68:malloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) by
  0x8048444:main (main.cpp:17)

Free ()/delete/delete[]/realloc () any of the four species, here is the illegal release of freed. When describing the relative relationship of the address, a sentence is used in the format of the sentence, which is the???????? of the addressing0x is {x} bytes {Inside/before/after} A block of size {y} {alloc ' D/free ' d}

It represents the relative position of the released address and a Y-length block. If the address is in front of the block, then use before, in the block is used inside, after the block is after. And the last Alloc ' d represents this block of y length in a valid state, and the stack at the time it is allocated is as follows, and free ' d represents the Y-length block has been deleted and the stack is as follows.

So the above report can be interpreted as: Address 0x41f23a0 is located in a valid block of length 1024 + 888, its allocation of the call stack as follows. illegal reading and writing

int main (int argc, char *argv[])
{
    char* bigbuff = (char*) malloc (1024);
    uint64_t* bignum = (uint64_t*) (bigbuff+1020);
    *bignum = 0X12345678AABBCCDD;
    printf ("Bignum is%llu\n", *bignum);
    Free (bigbuff);
}

Invalid write of size 4 at
 0x8048490:main (main.cpp:19) address
0x41f2428 are 0 bytes after a block of size 1,024 Alloc ' d at
 0x402be68:malloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) by
 0x8048474:main ( MAIN.CPP:17)

Invalid read of size 4 at
 0x804849b:main (main.cpp:20) address
0x41f2428 are 0 bytes after a b Lock of size 1,024 alloc ' d at
 0x402be68:malloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
 by 0x8048474:main (MAIN.CPP:17)

When the use of a memory area exceeds the allocated size, the invalid write/read can be triggered and the length is told. In this case, the uint64_t is 8 bytes long and the access exceeds 4 bytes. If you change the bigbuff+1020 to bigBuff-20, the report will tell you exactly what address xxx bytes before a.

Another interesting phenomenon is that I find that illegal access to uint64_t produces 2 reports of 4-byte-length illegal access, which shows what. Mismatched release

int main (int argc, char *argv[])
{
    int unused;
    char* Bigbuff = (char*) malloc (1024);
    Delete[] Bigbuff;
    printf ("unused=%d", unused);
}

Mismatched free ()/Delete/delete [] at
 0x402a8dc:operator delete[] (void*) (IN/USR/LIB/VALGRIND/VGPRELOAD_MEMCHEC k-x86-linux.so) by
 0x80484fb:main (main.cpp:19) address
0x4323028 are 0 bytes inside a block of size 1,024 alloc ' D at
 0x402be68:malloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) by
 0x80484e4:main (main.cpp (£) Use of

uninitialised value of size 4 at
 0x416e0db: _itoa_word (_itoa.c:195) by
 0x417221a:vfprintf (VF printf.c:1629 by
 0x4178b2e:printf (printf.c:35) by
 0X41454D2: (below Main) (libc-start.c:226)

Regardless of malloc allocation after the delete or delete[], or new[] careless with delete release, will get mismatched free ()/Delete/delete [] report, and the main content of the report is consistent. use an uninitialized value

In the example above, the int unused is used without assigning a value, and a report with the use of uninitialised value of size 4 is not usually fatal, but it needs to be ruled out.

You can observe an interesting case where the last layer of the stack appears (below main), which means that the code is executed outside of the main function and not from the thread, and I can't explain it clearly, but I did the following test: ... static construction and release

Class Globalclass
{public
:
    globalclass ()
    {
        char* buf = (char*) malloc (
        a); * (int*) (buf+8) = m;
        Free (BUF);
    }
    ~globalclass ()
    {
        char* buf = (char*) malloc (a);
        * (int*) (buf+8) = m;
        Free (BUF);
    }
    void Fake () {}
} G_globalclass;

int main (int argc, char *argv[])
{
    g_globalclass.fake ();
}

Invalid write of size 4 at 0x804857b:globalclass::globalclass () (main.cpp:21) by 0x804850f: __static_initialization_and _DESTRUCTION_0 (int, int) (MAIN.CPP:31) by 0x8048551: _global__sub_i_g_globalclass (main.cpp:55) by 0x8048631: __libc_cs U_init (In/home/jinzeyu/codelocal/build-mcsample-desktop_qt_5_3_gcc_32bit-debug/mcsample) by 0x4060469: (Below main (libc-start.c:185) Address 0x41f2030-8 bytes inside a block of size alloc ' d at 0x402be68:malloc (in/usr/lib/val grind/vgpreload_memcheck-x86-linux.so) by 0x8048571:globalclass::globalclass () (main.cpp:20) by 0x804850F: __static_ INITIALIZATION_AND_DESTRUCTION_0 (int, int) (MAIN.CPP:31) by 0x8048551: _global__sub_i_g_globalclass (main.cpp:55) by 0x8048631: __libc_csu_init (In/home/jinzeyu/codelocal/build-mcsample-desktop_qt_5_3_gcc_32bit-debug/mcsample) by 0x4060469: (below Main) (libc-start.c:185) Invalid write of size 4 at 0x80485b9:globalclass::~globalclass () (Main.cpp:2 7) by 0x4079b80: __run_exit_handlers (exit. c:78) by 0x4079c0c:exit (exit.c:100) by 0x40604da: (below Main) (libc-start.c:258) address 0x41f2070 is 8 bytes inside A block of size ten alloc ' d at 0x402be68:malloc (in/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) by 0X80485AF:GL Obalclass::~globalclass () (main.cpp:26) by 0x4079b80: __run_exit_handlers (exit.c:78) by 0x4079c0c:exit (exit.c:100) b
 Y 0x40604da: (below Main) (libc-start.c:258)

The construction and release of static classes are all outside of main, so the words (below main) appear, and the function name of the stack confirms the two processes well. here I think of another problem, that is, the order of static constructs does not necessarily follow expectations, and strongly recommends that there be no dependencies between static objects. crashes

If you encounter crashes during Memcheck running your program, it can still provide some useful information

--16198--Valgrind INTERNAL Error:valgrind received a signal (SIGSEGV)-exiting--16198--
;  Faulting address:0x74207972;  sp:0x6564ca5c
valgrind:the ' Impossible ' happened: killed by fatal signal ==16198== at    0x380c0ad4:??? (In/usr/lib/valgrind/memcheck-x86-linux)
==16198== by    0x380c12c5:??? (In/usr/lib/valgrind/memcheck-x86-linux)
==16198== by    0x38040a63:??? (In/usr/lib/valgrind/memcheck-x86-linux)
==16198== by    0x38040b36:??? (In/usr/lib/valgrind/memcheck-x86-linux)
==16198== by    0x3803ea4b:??? (In/usr/lib/valgrind/memcheck-x86-linux)
==16198== by    0x20202e78:???

Sched Status:
  running_tid=3

The report then lists the stack and the running state of the threads at the time of the crash

Thread 1:status = Vgts_waitsys ...

Thread 2:status = Vgts_waitsys ... Thread 3:status = vgts_runnable ==16198== at 0x402c9b4:operator new (unsigned int) (IN/USR/LIB/VALGRIND/VGPRELOAD_MEM check-x86-linux.so) ==16198== by 0x437d7d3:std::string::_rep::_s_create (unsigned int, unsigned int, std::allocator&lt ;char> const&) (in/usr/lib/i386-linux-gnu/libstdc++.so.6.0.16) ==16198== by 0x437fbb5:std::basic_string< Char, Std::char_traits<char>, std::allocator<char> >::basic_string (char const*, std::allocator< Char> const&) (in/usr/lib/i386-linux-gnu/libstdc++.so.6.0.16) ==16198== by 0x82a76a3:datachecker::handle_ Data_check_resp_msg (void*) (data_checker.c:55) ==16198== by 0x8144411:main_thread (void*) (main_thread.c:198) ==16198 = by 0x82839cf:thread_manager_start_routine (void*) (thread_manager.c:72) ==16198== by 0x42d3d4b:start_thread (PTH read_create.c:308) ==16198== by 0x450bfdd:clone (clone. s:130) Thread 4:status = Vgts_wAitsys ...
 

Then, the running thread is naturally the most suspect, and we can extract its stack information for further analysis.