如何查找导致“ malloc（）：内存损坏：0x00”的行

Question

I have a project that reads data from ethernet port and runs a set of algorithms on it.The program runs fine for a couple of hours and then produces the below shown error.

Could some suggest how to debug, find the line thats causing error ??

   *** Error in `objs/x64Linux3gcc5.4.0/lidarToBoxes': malloc(): memory corruption: 0x00000000051fc640 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f230dc167e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x8213e)[0x7f230dc2113e]
/lib/x86_64-linux-gnu/libc.so.6(__libc_malloc+0x54)[0x7f230dc23184]
/usr/lib/nvidia-384/tls/libnvidia-tls.so.384.111(+0x24c0)[0x7f2304e6e4c0]

======= Memory map: ========
00400000-00dc6000 r-xp 00000000 08:03 38407960                           /home/sai/sai_workspace/avt_17_003/modules/lidarToBoxes/objs/x64Linux3gcc5.4.0/lidarToBoxes
00fc5000-00fcf000 r--p 009c5000 08:03 38407960                           /home/sai/sai_workspace/avt_17_003/modules/lidarToBoxes/objs/x64Linux3gcc5.4.0/lidarToBoxes
00fcf000-00fd5000 rw-p 009cf000 08:03 38407960                           /home/sai/sai_workspace/avt_17_003/modules/lidarToBoxes/objs/x64Linux3gcc5.4.0/lidarToBoxes
00fd5000-00ff0000 rw-p 00000000 00:00 0 
0220b000-0614a000 rw-p 00000000 00:00 0     
[heap]

7f22d0000000-7f22d0022000 rw-p 00000000 00:00 0 
7f22d0022000-7f22d4000000 ---p 00000000 00:00 0 
7f22d4000000-7f22d4021000 rw-p 00000000 00:00 0 
7f22d4021000-7f22d8000000 ---p 00000000 00:00 0 
7f22d8000000-7f22d8021000 rw-p 00000000 00:00 0 
7f22d8021000-7f22dc000000 ---p 00000000 00:00 0 
7f22dc000000-7f22dc07c000 rw-p 00000000 00:00 0 
7f22dc07c000-7f22e0000000 ---p 00000000 00:00 0 
7f22e0000000-7f22e0021000 rw-p 00000000 00:00 0 
7f22e0021000-7f22e4000000 ---p 00000000 00:00 0 
7f22e6ffe000-7f22e6fff000 ---p 00000000 00:00 0 
7f22e6fff000-7f22e77ff000 rwxp 00000000 00:00 0 
7f22e8000000-7f22e8021000 rw-p 00000000 00:00 0 
7f22e8021000-7f22ec000000 ---p 00000000 00:00 0 
7f22eeffe000-7f22eefff000 ---p 00000000 00:00 0 
7f22eefff000-7f22ef7ff000 rwxp 00000000 00:00 0 
7f22ef7ff000-7f22ef800000 ---p 00000000 00:00 0 
7f22ef800000-7f22f0000000 rwxp 00000000 00:00 0 
7f22f0000000-7f22f00a6000 rw-p 00000000 00:00 0 
7f22f00a6000-7f22f4000000 ---p 00000000 00:00 0 
7f22f4000000-7f22f4021000 rw-p 00000000 00:00 0 
7f22f4021000-7f22f8000000 ---p 00000000 00:00 0 
7f22f8000000-7f22f8021000 rw-p 00000000 00:00 0 
7f22f8021000-7f22fc000000 ---p 00000000 00:00 0 
7f22fc093000-7f22fc291000 rw-p 00000000 00:00 0 
7f22fc291000-7f22fc491000 rw-s 00000000 00:09 323133    
socket:[323133]

Thank you!

Answer 1

Based on this first message, the list of unsorted chunks for one particular arena has become corrupted:

* Error in `objs/x64Linux3gcc5.4.0/lidarToBoxes': malloc(): memory corruption: 0x00000000051fc640 *

You can see that by the fact that it says "malloc(): memory corruption" and not, for example "malloc(): memory corruption (fast)". The values at the end of the message vary between releases of glibc but in your particular case what you are seeing is the value of "victim" from code something like this:

while ( (victim = unsorted_chunks(av)->bk) != unsorted_chunks(av)) {
  bck = victim->bk;
  if (__builtin_expect (victim->size <= 2 * SIZE_SZ, 0)
      || __builtin_expect (victim->size > av->system_mem, 0))
    malloc_printerr (check_action, "malloc(): memory corruption",
                     chunk2mem (victim));
  size = chunksize(victim);

In my particular case I grabbed this from glibc-2.18/malloc/malloc.c because, based on the fact that you had one number after the message, your version of glibc seemed near 5.18 but that was just a guess. Your backtrace specifies "/lib/x86_64-linux-gnu/libc.so.6" as the library, which is a bit vague, but if you wanted to find more specific information one way to do so would be to do something like this:

ls -l /lib/x86_64-linux-gnu/libc.so.6

The output would likely show you that your path is a symbolic link, and the target of that link would be more informative. In this case I don't think you really need to know the exact version but having it would allow you to download matching glibc source if you see an error message from libc malloc and want to understand what it means.

So back to what that code shows you is that "victim" is set to point to the last entry of the doubly linked list for the arena recognized by av. It also shows you that the value at the end of the line is from "chunk2mem(victim)". In your case, with a 64 bit process, the macro chunk2mem is adding 16, so you can reconstruct the value of victim as 0x00000000051fc640-16 = 0x00000000051fc630.

You can look at what victim has by doing:

x/4gx 0x00000000051fc630

The second value shown will be the value of victim->size.

If you happen to have a core dump, you can probably use the free open source tool https://github.com/vmware/chap to gather more information because chap often detects such corruption at startup. To start it, use:

chap core-file-path

Given the likelihood that the size field is corrupted, it may also be helpful to understand how the adjacent allocation just prior to the one listed as 0x00000000051fc640 was being used. Possibly the corruption was due to a buffer overrun on that previous allocation. To see the contents of the previous allocation, type show allocation 51fc630 from the chap prompt. If chap tells you that the given address is not part of an allocation, use describe 51fc630 from the chap prompt to get an idea of what that allocation might be.

Answer 2

Before ruining the valgrind compile your program with adding -ggdb3 debug flag

gcc -o executable -std=c11 -Wall -ggdb3 main.c

To run valgrind, pass the executable as an argument

valgrind --leak-check=full \
         --show-leak-kinds=all \
         --track-origins=yes \
         --verbose \
         --log-file=valgrind-out.txt \
         ./executable

Answer 3

我使用valgrind来检测许多内存管理错误。