[hello] I am debugging the new sub-tool for valgrind.

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[hello] I am debugging the new sub-tool for valgrind.

Wuweijia

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


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [hello] I am debugging the new sub-tool for valgrind.

Philippe Waroquiers
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




------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [hello] I am debugging the new sub-tool for valgrind.

John Reiser
In reply to this post by Wuweijia
>
>           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.]

--





------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Loading...