Re: [Valgrind-users] Vlgrind vgdb doesn't stop after memory error

[Anup <anu...@gm...>]

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