|
From: Anup <anu...@gm...> - 2012-07-14 00:50:16
|
Hi, I am trying to debug memory corruption in a program by attaching it to valgrind gdbserver and GDB (valgrind version 3.7.0). Command: valgrind --tool=memcheck --vgdb=full --vgdb-error=0 prog I am expecting that execution will stop when valgrind detects memory error which will allow me to debug it using GDB. However, it continues to execute after reporting the error. As it is seen in the following snapshot, action on error is continue. I want execution to stop at this instance giving control to GDB. ==31272== Use of uninitialised value of size 8 ==31272== at 0x783AA6C: __mpn_lshift (lshift.S:57) ==31272== by 0x7851E22: __printf_fp (printf_fp.c:668) ==31272== by 0x784C19F: vfprintf (vfprintf.c:1616) ==31272== by 0x7855659: printf (printf.c:35) ==31272== by 0x4EF2901: gpgpu_sim::cycle() (gpu-sim.cc:1447) ==31272== by 0x4F77D7D: gpgpu_sim_thread_concurrent(void*) (gpgpusim_entrypoint.cc:135) ==31272== by 0x7B8E9C9: start_thread (pthread_create.c:300) ==31272== by 0x78EBCDC: clone (clone.S:112) ==31272== ==31272== (action on error) vgdb me ... ==31272== Continuing ... Is this the expected behavior? How can I get valgrind to stop at such points? I remember using the above command earlier where valgrind stopped on detecting memory error, giving control back to GDB. But I am not able to get it working again. Is such support available in valgrind at this point? Any help is appreciated. Thanks, Anup |
|
From: Philippe W. <phi...@sk...> - 2012-07-16 19:51:10
|
On Sat, 2012-07-14 at 00:44 +0000, Anup wrote: > Hi, > > I am trying to debug memory corruption in a program by attaching it to valgrind > gdbserver and GDB (valgrind version 3.7.0). > > Command: valgrind --tool=memcheck --vgdb=full --vgdb-error=0 prog With --vgdb-error=0, Valgrind should stop before starting prog, to let a GDB attach and e.g. put breaks. It should also stop on all errors. Which OS are you using ? Otherwise, can you add options -v -d and show the trace between vgdb me ... and Continuing Philippe > > I am expecting that execution will stop when valgrind detects memory error which > will allow me to debug it using GDB. However, it continues to execute after > reporting the error. As it is seen in the following snapshot, action on error is > continue. I want execution to stop at this instance giving control to GDB. > > > ==31272== Use of uninitialised value of size 8 > ==31272== at 0x783AA6C: __mpn_lshift (lshift.S:57) > ==31272== by 0x7851E22: __printf_fp (printf_fp.c:668) > ==31272== by 0x784C19F: vfprintf (vfprintf.c:1616) > ==31272== by 0x7855659: printf (printf.c:35) > ==31272== by 0x4EF2901: gpgpu_sim::cycle() (gpu-sim.cc:1447) > ==31272== by 0x4F77D7D: gpgpu_sim_thread_concurrent(void*) > (gpgpusim_entrypoint.cc:135) > ==31272== by 0x7B8E9C9: start_thread (pthread_create.c:300) > ==31272== by 0x78EBCDC: clone (clone.S:112) > ==31272== > ==31272== (action on error) vgdb me ... > ==31272== Continuing ... > > > Is this the expected behavior? How can I get valgrind to stop at such points? > I remember using the above command earlier where valgrind stopped on detecting > memory error, giving control back to GDB. But I am not able to get it working > again. Is such support available in valgrind at this point? > > Any help is appreciated. > Thanks, > Anup > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Anup <anu...@gm...> - 2012-07-16 20:21:44
|
Philippe Waroquiers <philippe.waroquiers <at> skynet.be> writes: > > On Sat, 2012-07-14 at 00:44 +0000, Anup wrote: > > Hi, > > > > I am trying to debug memory corruption in a program by attaching it to valgrind > > gdbserver and GDB (valgrind version 3.7.0). > > > > Command: valgrind --tool=memcheck --vgdb=full --vgdb-error=0 prog > With --vgdb-error=0, Valgrind should stop before starting prog, to let > a GDB attach and e.g. put breaks. It should also stop on all errors. > > Which OS are you using ? > Otherwise, can you add options -v -d and show the trace between > vgdb me ... > and > Continuing > > Philippe > > > > > I am expecting that execution will stop when valgrind detects memory error which > > will allow me to debug it using GDB. However, it continues to execute after > > reporting the error. As it is seen in the following snapshot, action on error is > > continue. I want execution to stop at this instance giving control to GDB. > > > > > > ==31272== Use of uninitialised value of size 8 > > ==31272== at 0x783AA6C: __mpn_lshift (lshift.S:57) > > ==31272== by 0x7851E22: __printf_fp (printf_fp.c:668) > > ==31272== by 0x784C19F: vfprintf (vfprintf.c:1616) > > ==31272== by 0x7855659: printf (printf.c:35) > > ==31272== by 0x4EF2901: gpgpu_sim::cycle() (gpu-sim.cc:1447) > > ==31272== by 0x4F77D7D: gpgpu_sim_thread_concurrent(void*) > > (gpgpusim_entrypoint.cc:135) > > ==31272== by 0x7B8E9C9: start_thread (pthread_create.c:300) > > ==31272== by 0x78EBCDC: clone (clone.S:112) > > ==31272== > > ==31272== (action on error) vgdb me ... > > ==31272== Continuing ... > > > > > > Is this the expected behavior? How can I get valgrind to stop at such points? > > I remember using the above command earlier where valgrind stopped on detecting > > memory error, giving control back to GDB. But I am not able to get it working > > again. Is such support available in valgrind at this point? > > > > Any help is appreciated. > > Thanks, > > Anup > > > > > > ---------------------------------------------------------------------------- -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > will include endpoint security, mobile security and the latest in malware > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > Valgrind-users mailing list > > Valgrind-users <at> lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > Hi, I use Ubuntu 10.04 LTS (64 bit). GDB version is 7.1-ubuntu. As you mentioned, after the valgrind command it stops for GDB to attach the process. I entered the following command there: target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=7394 -d There is no -v option. Then continued using 'c' command on GDB. I don't see any difference from the previous output. Is that the correct way to used option -d? Here is the trace: ==7394== Use of uninitialised value of size 8 ==7394== at 0x7851E1E: __printf_fp (printf_fp.c:668) ==7394== by 0x784C19F: vfprintf (vfprintf.c:1616) ==7394== by 0x7855659: printf (printf.c:35) ==7394== by 0x4EF2901: gpgpu_sim::cycle() (gpu-sim.cc:1447) ==7394== by 0x4F77D7D: gpgpu_sim_thread_concurrent(void*) (gpgpusim_entrypoint.cc:135) ==7394== by 0x7B8E9C9: start_thread (pthread_create.c:300) ==7394== by 0x78EBCDC: clone (clone.S:112) ==7394== ==7394== (action on error) vgdb me ... ==7394== Continuing ... Thanks, Anup |
|
From: Philippe W. <phi...@sk...> - 2012-07-16 20:37:29
|
On Mon, 2012-07-16 at 20:21 +0000, Anup wrote: > I use Ubuntu 10.04 LTS (64 bit). GDB version is 7.1-ubuntu. > As you mentioned, after the valgrind command it stops for GDB to attach the > process. I entered the following command there: > > target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=7394 -d > > There is no -v option. Then continued using 'c' command on GDB. > I don't see any difference from the previous output. Is that the correct way to > used option -d? Effectively, vgdb only has -d option. In this case, you must give the option -v -d to valgrind so as to have more trace from the Valgrind gdbserver. Philippe |
|
From: Anup <anu...@gm...> - 2012-07-18 01:23:21
|
> Effectively, vgdb only has -d option.
> In this case, you must give the option -v -d to valgrind so as to
> have more trace from the Valgrind gdbserver.
Here is the trace with -v -d options given to valgrind.
==4562== Use of uninitialised value of size 8
==4562== at 0x7AAC2CF: __printf_fp (printf_fp.c:802)
==4562== by 0x7AA619F: vfprintf (vfprintf.c:1616)
==4562== by 0x7AAF659: printf (printf.c:35)
--4562:1:mallocfr deferred_reclaimSuperblock at 0x40BBDA000 (pszB 65504)
(prev 0x40BBDA000) owner VALGRIND/demangle
==4562== by 0x50917A9: gpgpu_sim::cycle() (gpu-sim.cc:1447)
--4562:1:mallocfr deferred_reclaimSuperblock at 0x40BBDA000 (pszB 65504)
(prev 0x40BBDA000) owner VALGRIND/demangle
==4562== by 0x5152493: gpgpu_sim_thread_concurrent(void*)
(gpgpusim_entrypoint.cc:135)
==4562== by 0x7DE89C9: start_thread (pthread_create.c:300)
==4562== by 0x7B45CDC: clone (clone.S:112)
==4562==
==4562== (action on error) vgdb me ...
--4562:1:gdbsrv entering call_gdbserver core_reason ... pid 4562 tid 2 status
VgTs_Runnable sched_jmpbuf_valid 1
--4562:1:gdbsrv enter valgrind_wait pid 4562
--4562:1:gdbsrv stop pc is 0x7AAC2CF
--4562:1:gdbsrv exit valgrind_wait returns ptid id 4606 stop_pc 0x7AAC2CF:
__printf_fp (printf_fp.c:802) signal 20
--4562:1:gdbsrv Writing resume reply for 4606
--4562:1:gdbsrv putpkt
("$T1406:50a4820c0*"00;07:60a0820c0*"00;10:cfc2aa070*"00;thread:11fe;#66"); [no
ack]
--4562:1:gdbsrv getpkt ("C14"); [no ack]
--4562:1:gdbsrv set_desired_inferior use_general 0 found 0x402514BE0 tid 1
lwpid 4562
--4562:1:gdbsrv resume_info thread 4562 leave_stopped 0 step 0 sig 17 stepping
0
--4562:1:gdbsrv stop pc is 0x7B0969D
--4562:1:gdbsrv stop_pc 0x7AAC2CF changed to be resume_pc 0x7B0969D: ???
(syscall-template.S:82)
==4562== Continuing ...
|
|
From: Philippe W. <phi...@sk...> - 2012-07-18 06:51:30
|
On Wed, 2012-07-18 at 01:22 +0000, Anup wrote:
> --4562:1:gdbsrv getpkt ("C14"); [no ack]
> --4562:1:gdbsrv set_desired_inferior use_general 0 found 0x402514BE0 tid 1
> lwpid 4562
> --4562:1:gdbsrv resume_info thread 4562 leave_stopped 0 step 0 sig 17 stepping
> 0
> --4562:1:gdbsrv stop pc is 0x7B0969D
> --4562:1:gdbsrv stop_pc 0x7AAC2CF changed to be resume_pc 0x7B0969D: ???
> (syscall-template.S:82)
> ==4562== Continuing ...
This looks similar to bug 297078, which is solved in 3.8.0 SVN.
Can you try with the latest SVN version ?
For how to get it and configure+compile it, see
http://www.valgrind.org/downloads/repository.html
If it does not work with 3.8.0 SVN, then the best is to enter a bug,
redo the -v -d trace and attach the complete trace (from the beginning)
to the bug.
Thanks
Philippe
|
|
From: Anup <anu...@gm...> - 2012-07-18 19:56:13
|
> > This looks similar to bug 297078, which is solved in 3.8.0 SVN. > Can you try with the latest SVN version ? Yes. It works with 3.8.0 SVN version without any glitch. Thanks a lot. Anup |