|
From: Uday R. <uda...@gm...> - 2012-11-06 04:01:44
|
On Mon, Nov 5, 2012 at 11:35 PM, John Reiser <jr...@bi...> wrote: >> Thanks, but I didn't understand the last part. What exactly do I need >> to run to "print the status of the entire buffer"? I'm running with >> >> --track-origins=yes --db-attach=yes >> >> my 'man valgrind' has no mention of vgdb. > > $ valgrind --help | grep vgdb > > Quoting Philippe Waroquiers of [valgrind-users] "Addresses marked as ??? > in Valgrind stack trace" on 2012-10-09: > ----- > Since Valgrind 3.7.0, Valgrind contains an embedded gdbserver, to > which you connect from gdb using vgdb as a relay application. > > The advantages of gdb/vgdb compared to --db-attach is > that you get all the usual gdb commands > (e.g. breakpoints, continue, jump, inferior function calls, ...) > + interactive calls of Valgrind functionality (e.g. search for > memleaks e.g. when a breakpoint is reached). > vgdb also allows to look at a multi-threaded application, > allows inferior function calls, etc. > You can also start to debug your application under Valgrind from > the beginning (so, before an error has been reported). > > To use it, give argument --vgdb-error=0 to Valgrind, and follow > the instructions to connect your gdb using vgdb. Thanks. With vgdb/gdb, the debugger hangs after a couple of continues. Program received signal SIGTRAP, Trace/breakpoint trap. 0x000000300b4ea3d7 in writev () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install hwloc-1.4.1-2.fc17.x86_64 keyutils-libs-1.5.5-2.fc17.x86_64 krb5-libs-1.10.2-6.fc17.x86_64 libcom_err-1.42.3-3.fc17.x86_64 libesmtp-1.0.6-3.fc17.x86_64 libgcc-4.7.2-2.fc17.x86_64 libibverbs-1.1.6-2.fc17.x86_64 librdmacm-1.0.15-1.fc17.x86_64 libselinux-2.1.10-3.fc17.x86_64 libtool-ltdl-2.4.2-3.1.fc17.x86_64 libxml2-2.7.8-9.fc17.x86_64 numactl-libs-2.0.7-6.fc17.x86_64 openmpi-1.5.4-5.fc17.1.x86_64 openssl-1.0.0j-2.fc17.x86_64 pciutils-libs-3.1.9-1.fc17.x86_64 zlib-1.2.5-7.fc17.x86_64 (gdb) c Continuing. [hung here...] There is no progress after this. The CPU utilization is 0 and it looks like memcheck has hung. On the valgrind side, I see ==29118== Syscall param writev(vector[...]) points to uninitialised byte(s) ==29118== at 0x300B4EA3D7: writev (in /usr/lib64/libc-2.15.so) ==29118== by 0x6256B92: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_oob_tcp.so) ==29118== by 0x62579AC: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_oob_tcp.so) ==29118== by 0x625B1CB: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_oob_tcp.so) ==29118== by 0x604E41E: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_rml_oob.so) ==29118== by 0x604E998: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_rml_oob.so) ==29118== by 0x66656EF: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_grpcomm_bad.so) ==29118== by 0x37CB84D5A2: ??? (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB864C17: PMPI_Init (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x40108A: main (jacobi-1d-imper.distopt.c:72) ==29118== Address 0x51fcc31 is 161 bytes inside a block of size 256 alloc'd ==29118== at 0x4A08A0E: realloc (vg_replace_malloc.c:662) ==29118== by 0x37CB8D1C97: ??? (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB8EAE0D: ??? (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB8B0955: orte_grpcomm_base_pack_modex_entries (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x66655CE: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_grpcomm_bad.so) ==29118== by 0x37CB84D5A2: ??? (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB864C17: PMPI_Init (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x40108A: main (jacobi-1d-imper.distopt.c:72) ==29118== Uninitialised value was created by a heap allocation ==29118== at 0x4A0881C: malloc (vg_replace_malloc.c:270) ==29118== by 0x37CB8E1D7B: ??? (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB8E2440: opal_ifcount (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x6255068: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_oob_tcp.so) ==29118== by 0x37CB8BC45A: mca_oob_base_init (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x604C7EB: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_rml_oob.so) ==29118== by 0x37CB8CAAAC: orte_rml_base_select (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB8AD204: orte_ess_base_app_setup (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x5E4A444: ??? (in /usr/lib64/openmpi/lib/openmpi/mca_ess_env.so) ==29118== by 0x37CB88E9C9: orte_init (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB84CBF8: ??? (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== by 0x37CB864C17: PMPI_Init (in /usr/lib64/openmpi/lib/libmpi.so.1.0.2) ==29118== ==29118== (action on error) vgdb me ... ==29118== Continuing ... I'm using valgrind 3.8.1 on x86-64 with options: --vgdb-error=0 --track-origins=yes code was compiled with gcc 4.7.2. -- Uday > ----- > > -- > |