C ++和Valgrind调试

Question

I have a memory issue with a SEGFAULT error on a ARM processor running C++.

I run valgrind and it gives me this info:

==7298== Thread 6:
==7298== Mismatched free() / delete / delete []
==7298==    at 0x482C80C: free (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==7298==  Address 0x58186d8 is 0 bytes inside a block of size 29 alloc'd
==7298==    at 0x482CC94: operator new[](unsigned int) (in /usr/lib/valgrind/vgpreload_memcheck-arm-linux.so)
==7298== 

I go into gdb and run "info symbol" on 0x482CC94, 0x58186d8 and 0x482C80C and the debugger says "No symbol matches".

I have so many threads running in the program that I can't figure out where to start. I tired to put printf in the most likely threads to see if that would help but there does not seem to be any correlation between the printf statments and the valgrind output.

How can I debug this problem? Is there some way to name threads in my code so that Valgrind can show something besides "Thread 6". Any guidance would be appreciated.

Answer 1

It might be that the allocation/deallocation is happening during program startup. Try the "--show-below-main" option:

--show-below-main= [default: no]

"By default, stack traces for errors do not show any functions that appear beneath main because most of the time it's uninteresting C library stuff and/or gobbledygook. Alternatively, if main is not present in the stack trace, stack traces will not show any functions below main-like functions such as glibc's __libc_start_main. Furthermore, if main-like functions are present in the trace, they are normalised as (below main), in order to make the output more deterministic.

If this option is enabled, all stack trace entries will be shown and main-like functions will not be normalised."

You may also want to look at "--read-var-info"

--read-var-info= [default: no]

When enabled, Valgrind will read information about variable types and locations from DWARF3 debug info. This slows Valgrind startup significantly and makes it use significantly more memory, but for the tools that can take advantage of it (Memcheck, Helgrind, DRD) it can result in more precise error messages.

There are other valgrind options you can try. The manual is here:

http://valgrind.org/docs/manual/manual.html