|
From: Wuweijia <wuw...@hu...> - 2017-07-04 10:49:11
|
Hi:
There are some bug in the sub-tool for valgrind. I want to debug it via printing log, but there is a lot of log and run slowly I can not stand it .
And is there any tools like gdb , I can the debug the sub-tool for vaglrind at some point in my test program.
BR
Owen
|
|
From: Philippe W. <phi...@sk...> - 2017-07-04 18:54:17
|
On Tue, 2017-07-04 at 10:48 +0000, Wuweijia wrote: > Hi: > There are some bug in the sub-tool for valgrind. I want to > debug it via printing log, but there is a lot of log and run slowly I > can not stand it . > And is there any tools like gdb , I can the debug the sub-tool for > vaglrind at some point in my test program. If what you want to do is to debug valgrind itself, then see README_DEVELOPERS. There is a section 'Debugging Valgrind with GDB'. I am using the second way (the 'possibly easier way") as I find it easier :). If the above is not the answer to your question, please rephrase your question. Thanks Philippe |
|
From: John R. <jr...@bi...> - 2017-07-04 20:30:51
|
>
> There are some bug in the sub-tool for valgrind. I want to debug it via printing log, but there is a lot of log and run slowly I can not stand it .
>
> And is there any tools like gdb , I can the debug the sub-tool for vaglrind at some point in my test program.
As Philippe says in another thread, see README_DEVELOPERS.
Beyond that, there are the usual low-level debugging hints:
1. strace -f -o strace.out -e trace=execve -v -s 300 valgrind /bin/date
Then in strace.out:
execve("/usr/lib64/valgrind/memcheck-amd64-linux", ["valgrind", ...],
..., "VALGRIND_LAUNCHER=/usr/bin/valgrind"])
and that last environment variable is important, as well as the pathname
in the first argument to execve(). Everything must correspond; mixing
components will cause confusion and/or errors.
2. When all else fails, then insert a deliberate infinite loop at
(or just before) the point of interest::
write(2, "\n\nHELP!\n\n", 9); /* reminder to developer */
for (;;) ; /* deliberate infinite loop */
Invoke your tool normally (not using any debugger), and watch the CPU utilization
using /usr/bin/top in another window. When the CPU utilization reaches 100%
and/or the HELP! message appears, then attach gdb to the process:
gdb path_to_program_name -p PID ## PID is the process ID
Now you can look around in gdb.
You may have to add symbol tables manually. In a command-line shell, invoke
"cat /proc/PID/maps" to get the layout of the address space, such as:
=====
555be56ae000-555be56ba000 r-xp 00000000 08:03 524616 /usr/bin/cat
555be58b9000-555be58ba000 r--p 0000b000 08:03 524616 /usr/bin/cat
555be58ba000-555be58bb000 rw-p 0000c000 08:03 524616 /usr/bin/cat
555be5baa000-555be5bcb000 rw-p 00000000 00:00 0 [heap]
7efd424dd000-7efd4907c000 r--p 00000000 08:03 544504 /usr/lib/locale/locale-archive
7efd4907c000-7efd49238000 r-xp 00000000 08:03 532794 /usr/lib64/libc-2.24.so
[[snip]
=====
Then for each program or shared library file:
$ objdump --section-headers path_to_file | grep text
12 .text 00007729 0000000000001bc0 0000000000001bc0 00001bc0 2**4
$ gdb # another gdb
(gdb) print 0x555be56ae000 + 0x00001bc0
$1 = 0x555be56afbc0
Go back to the gdb that was invoked with -p, and add the symbols using:
(gdb) add-symbol-file path_to_file 0x555be56afbc0
[Caution: short infinite loops cause the CPU chip to become very hot, quickly.
Avoid executing such a loop for more than a few seconds at a time.]
--
|