|
From: Kevin O. <ol...@bo...> - 2003-09-10 17:49:29
|
Hello, Is there any information on using VALGRIND with MPI programs ? Kevin Olson |
|
From: Szabo P. <pt...@in...> - 2003-09-25 11:12:56
|
Dear Valgrind Developers, Please implement the ENTER and LEAVE assembly instructions. ==24198== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==24198== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==24198== Using valgrind-20030725, a program supervision framework for x86-linux. ==24198== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==24198== Estimated CPU clock rate is 800 MHz ==24198== For more details, rerun with: -v ==24198== disInstr: unhandled instruction bytes: 0xC8 0xC 0x0 0x0 Illegal instruction (core dumped) Thank you: pts --- (vvv use GNU); pt...@in...; http://www.inf.bme.hu/~pts [/dlflg/=u]dZ[lalbdlp*lqlg*+lpla*lqlf*+lflgsbsasfsglex]dscZ[r%O*]sdzzKsa [nlbdlaldxlglfldxsfdsalex]dsuZ[.]zsqsssgsbnsfspselsn[lcxsslqdlp+spz+sqdx]dx |
|
From: Dirk M. <dm...@gm...> - 2003-09-25 17:58:02
|
On Thursday 25 September 2003 13:12, Szabo Peter wrote: > Please implement the ENTER and LEAVE assembly instructions. LEAVE is already implemented, however ENTER is indeed missing. Any test application we could validate against? Dirk |
|
From: Nicholas N. <nj...@ca...> - 2003-10-12 17:16:55
|
On Thu, 25 Sep 2003, Dirk Mueller wrote: > On Thursday 25 September 2003 13:12, Szabo Peter wrote: > > > Please implement the ENTER and LEAVE assembly instructions. > > LEAVE is already implemented, however ENTER is indeed missing. I'm not sure if this was announced: ENTER was implemented in the CVS HEAD a couple of weeks ago. Thanks to Dirk Mueller for doing it. N |
|
From: Attila <sa...@fr...> - 2004-04-06 10:46:37
|
Hi,
I had a strange message with getaddrinfo (before that I used
gethostbyname, but it was no good in a multithreaded
program, so moved to getaddrinfo per man page instructions
(gethostbyname -> getipnodebyname -> getaddrinfo).
Is it a bug of mine or of glibc? Is it a serious thing?
I include a small test program here, and the verbose vg output.
I use SuSE 9 and vg 2.1.1.
br,
Attila
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
int main()
{
int ret;
struct addrinfo* ainfo;
ret = getaddrinfo(/* node = */ "127.0.0.1", /* service =
*/ NULL,
/* hints = */ NULL, &ainfo);
freeaddrinfo(ainfo);
return ret;
}
==16380== Memcheck, a memory error detector for x86-linux.
==16380== Copyright (C) 2002-2004, and GNU GPL'd, by Julian
Seward.
==16380== Using valgrind-2.1.1, a program supervision
framework for x86-linux.
==16380== Copyright (C) 2000-2004, and GNU GPL'd, by Julian
Seward.
==16380== Valgrind library directory: /usr/local/lib/valgrind
==16380== Command line
==16380== ./a.out
==16380== Startup, with flags:
==16380== --tool=memcheck
==16380== --leak-check=yes
==16380== --num-callers=9
==16380== -v
==16380== Reading syms from
/home/avangel/test/vg_getaddrinfo/a.out (0x8048000)
==16380== Reading syms from /lib/ld-2.3.2.so (0x3C000000)
==16380== object doesn't have any debug info
==16380== Reading syms from /lib/ld-2.3.2.so (0xB0000000)
==16380== object doesn't have any debug info
==16380== Reading syms from /lib/libdl.so.2 (0xB002A000)
==16380== object doesn't have any debug info
==16380== Reading syms from /lib/i686/libc.so.6 (0xB002D000)
==16380== object doesn't have any debug info
==16380== Reading syms from
/usr/local/lib/valgrind/vgskin_memcheck.so (0xB0260000)
==16380== Reading syms from /usr/local/lib/valgrind/stage2
(0xB8000000)
==16380== Reading suppressions file:
/usr/local/lib/valgrind/default.supp
==16380== REDIRECT soname:libc.so.6(__GI___errno_location)
to soname:libpthread.so.0(__errno_location)
==16380== REDIRECT soname:libc.so.6(__errno_location) to
soname:libpthread.so.0(__errno_location)
==16380== REDIRECT soname:libc.so.6(__GI___h_errno_location)
to soname:libpthread.so.0(__h_errno_location)
==16380== REDIRECT soname:libc.so.6(__h_errno_location) to
soname:libpthread.so.0(__h_errno_location)
==16380== REDIRECT soname:libc.so.6(__GI___res_state) to
soname:libpthread.so.0(__res_state)
==16380== REDIRECT soname:libc.so.6(__res_state) to
soname:libpthread.so.0(__res_state)
==16380== REDIRECT soname:libc.so.6(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==16380== REDIRECT soname:libc.so.6(strnlen) to
*vgpreload_memcheck.so*(strnlen)
==16380== REDIRECT soname:ld-linux.so.2(stpcpy) to
*vgpreload_memcheck.so*(stpcpy)
==16380== REDIRECT soname:ld-linux.so.2(strchr) to
*vgpreload_memcheck.so*(strchr)
==16380==
==16380== Reading syms from
/usr/local/lib/valgrind/vg_inject.so (0x3C01C000)
==16380== Reading syms from
/usr/local/lib/valgrind/vgpreload_memcheck.so (0x3C01F000)
==16380== TRANSLATE: 0x3C0133D0 redirected to 0x3C020A30
==16380== Reading syms from /lib/i686/libc.so.6 (0x3C036000)
==16380== object doesn't have any debug info
==16380== Syscall param socketcall.sendto(msg) contains
uninitialised or unaddressable byte(s)
==16380== at 0x3C1130A6: sendto (in /lib/i686/libc.so.6)
==16380== by 0x3C12F081: __check_pf (in /lib/i686/libc.so.6)
==16380== by 0x3C0FEB10: getaddrinfo (in /lib/i686/libc.so.6)
==16380== by 0x804839D: main (main.c:9)
==16380== Address 0x4FFFDF41 is on thread 1's stack
==16380==
==16380== ERROR SUMMARY: 1 errors from 1 contexts
(suppressed: 11 from 1)
==16380==
==16380== 1 errors in context 1 of 1:
==16380== Syscall param socketcall.sendto(msg) contains
uninitialised or unaddressable byte(s)
==16380== at 0x3C1130A6: sendto (in /lib/i686/libc.so.6)
==16380== by 0x3C12F081: __check_pf (in /lib/i686/libc.so.6)
==16380== by 0x3C0FEB10: getaddrinfo (in /lib/i686/libc.so.6)
==16380== by 0x804839D: main (main.c:9)
==16380== Address 0x4FFFDF41 is on thread 1's stack
--16380--
--16380-- supp: 11 Ugly strchr error in /lib/ld-2.3.2.so
==16380==
==16380== IN SUMMARY: 1 errors from 1 contexts (suppressed:
11 from 1)
==16380==
==16380== malloc/free: in use at exit: 0 bytes in 0 blocks.
==16380== malloc/free: 3 allocs, 3 frees, 144 bytes allocated.
==16380==
==16380== No malloc'd blocks -- no leaks are possible.
--16380-- TT/TC: 0 tc sectors discarded.
--16380-- 1106 chainings, 2 unchainings.
--16380-- translate: new 1856 (33714 -> 438005; ratio
129:10)
--16380-- discard 1 (23 -> 320; ratio 139:10).
--16380-- dispatch: 0 jumps (bb entries), of which 4650
(465000%) were unchained.
--16380-- 25/2210 major/minor sched events. 1979
tt_fast misses.
--16380-- reg-alloc: 418 t-req-spill, 82057+3327 orig+spill
uis, 10145 total-reg-r.
--16380-- sanity: 26 cheap, 2 expensive checks.
--16380-- ccalls: 6989 C calls, 54% saves+restores
avoided (22284 bytes)
--16380-- 9271 args, avg 0.86 setup instrs each
(2446 bytes)
--16380-- 0% clear the stack (20967 bytes)
--16380-- 3137 retvals, 27% of reg-reg movs
avoided (1688 bytes)
|
|
From: Steve G <lin...@ya...> - 2004-04-06 12:33:49
|
>Is it a bug of mine or of glibc? This is in glibc. I've mentioned it to Red Hat developers a couple of times. What is happening is they are using a dummy structure to fill in a lower level call for something that was otherwise passed to getaddrinfo as a NULL pointer. Usually, this is the service parameter. As best as I can tell, it is harmless...but I wished they would correct it. Hope this helps... -Steve Grubb __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ |
|
From: Henrik N. <hn...@ma...> - 2004-04-06 12:45:56
|
On Tue, 6 Apr 2004, Attila wrote: > Is it a bug of mine or of glibc? Is it a serious thing? > ==16380== at 0x3C1130A6: sendto (in /lib/i686/libc.so.6) > ==16380== by 0x3C12F081: __check_pf (in /lib/i686/libc.so.6) > ==16380== by 0x3C0FEB10: getaddrinfo (in /lib/i686/libc.so.6) > ==16380== by 0x804839D: main (main.c:9) Looks to me like a harmless glibc or nsswitch misfeature/overoptimization. Regards Henrik |
|
From: Nicholas N. <nj...@ca...> - 2004-05-27 09:21:37
|
[Nb: please reply to the list; sorry if this is sent twice] On Wed, 26 May 2004 su...@un... wrote: > > It looks like the file has been stripped of symbol table info, which is > > strange if you are compiling and running exactly as stated. Sudeep, does > > the output of 'nm test' include lines like these: > > > > 0804843a T AvoidLeak > > 080483f8 T Leak > > > > ? If so, then its not a symbol table problem, but rather looks like > > Valgrind is getting confused when walking the stack... > > nm test shows me > > 0804843a T AvoidLeak > 080483f8 T Leak > > so my valgrind is getting confused. Is there any way I can correct it. Hard to say. Maybe your gcc is doing something weird with stack layout, can you try with a different gcc version? N |
|
From: Neil Y. <nei...@wi...> - 2004-09-03 08:56:08
|
I'm seeing massif (2.2.0) crash on startup with an assertion failure on RedHat 7.3 valgrind --tool=massif --depth=8 --alloc-fn=sqlcxt --num-callers=16 ./program ==23804== Massif, a space profiler for x86-linux. ==23804== Copyright (C) 2003, Nicholas Nethercote ==23804== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==23804== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" ==23804== For more details, rerun with: -v ==23804== @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" ==23804== valgrind: vg_libpthread.c:2313 (write): Assertion `write_ptr != ((void *)0) && write_ptr != write' failed. ==23804== Please report this bug at: valgrind.kde.org ==23804== ==23804== Total spacetime: 294,134,770 ms.B ==23804== heap: 2.5% ==23804== heap admin: 0.1% ==23804== stack(s): 97.2% Neil Youngman Wirefast Limited |
|
From: Sinan Y. <asm...@ya...> - 2004-11-06 11:34:07
|
confirm 190754 ===== __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com |
|
From: Kevin W. <Kw...@po...> - 2004-11-11 17:12:37
|
confirm 139105 |
|
From: Laurent-Varin J. <jul...@in...> - 2004-11-16 15:33:15
|
I've install Mandrake 10.1 community, and valgrind become blind ? Does any one
know what happen ?
Thank you.
Here is an example !
test_val.c :
/*******************************************************************/
#include <stdio.h>
#include <stdlib.h>
int main( int argc, char *argv[] ) {
int *toto;
toto=(int *)malloc(sizeof(int)*2);
toto[4]=1; /* here is the memory error for testing valgrind */
free(toto);
return 0;
}
/*******************************************************************/
compilation :
gcc -c -g -Wall test_val.c
gcc -g -Wall test_val.o -o test_val
/*******************************************************************/
>uname -a
Linux localhost 2.6.3-7mdk #1 Wed Mar 17 15:56:42 CET 2004 i686 unknown unknown
GNU/Linux
>nm test_val.o
U free
00000000 T main
U malloc
>nm test_val
080495d0 A __bss_start
080482f4 t call_gmon_start
080495d0 b completed.1
080495a4 d __CTOR_END__
080495a0 d __CTOR_LIST__
080494cc D __data_start
080494cc W data_start
08048480 t __do_global_ctors_aux
08048320 t __do_global_dtors_aux
080494d0 D __dso_handle
080495ac d __DTOR_END__
080495a8 d __DTOR_LIST__
080494d8 D _DYNAMIC
080495d0 A _edata
080495d4 A _end
080484a4 T _fini
080494cc A __fini_array_end
080494cc A __fini_array_start
080484c0 R _fp_hw
08048360 t frame_dummy
080484c8 r __FRAME_END__
U free@@GLIBC_2.0
080495b4 D _GLOBAL_OFFSET_TABLE_
w __gmon_start__
08048274 T _init
080494cc A __init_array_end
080494cc A __init_array_start
080484c4 R _IO_stdin_used
080495b0 d __JCR_END__
080495b0 d __JCR_LIST__
w _Jv_RegisterClasses
08048420 T __libc_csu_fini
080483d0 T __libc_csu_init
U __libc_start_main@@GLIBC_2.0
0804838c T main
U malloc@@GLIBC_2.0
080494d4 d p.0
080482d0 T _start
/*******************************************************************/
>valgrind --tool=memcheck test_val
==11988== Memcheck, a memory error detector for x86-linux.
==11988== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==11988== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==11988== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==11988== For more details, rerun with: -v
==11988==
==11988== Invalid write of size 4
==11988== at 0x80483B2: ???
==11988== by 0x1B93295C: __libc_start_main (in /lib/tls/libc-2.3.3.so)
==11988== by 0x80482F0: ???
==11988== Address 0x1BA68038 is 8 bytes after a block of size 8 alloc'd
==11988== at 0x1B906E50: malloc (vg_replace_malloc.c:131)
==11988== by 0x80483A5: ???
==11988== by 0x1B93295C: __libc_start_main (in /lib/tls/libc-2.3.3.so)
==11988== by 0x80482F0: ???
==11988==
==11988== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 15 from 1)
==11988== malloc/free: in use at exit: 0 bytes in 0 blocks.
==11988== malloc/free: 1 allocs, 1 frees, 8 bytes allocated.
==11988== For a detailed leak analysis, rerun with: --leak-check=yes
==11988== For counts of detected errors, rerun with: -v
/*******************************************************************/
Why ??? appear ?
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
|
|
From: Nicholas N. <nj...@ca...> - 2004-11-16 15:54:10
|
On Tue, 16 Nov 2004, Laurent-Varin Julien wrote: > ==11988== Invalid write of size 4 > ==11988== at 0x80483B2: ??? > ==11988== by 0x1B93295C: __libc_start_main (in /lib/tls/libc-2.3.3.so) > ==11988== by 0x80482F0: ??? > ==11988== Address 0x1BA68038 is 8 bytes after a block of size 8 alloc'd > ==11988== at 0x1B906E50: malloc (vg_replace_malloc.c:131) > ==11988== by 0x80483A5: ??? > ==11988== by 0x1B93295C: __libc_start_main (in /lib/tls/libc-2.3.3.so) > ==11988== by 0x80482F0: ??? > > Why ??? appear ? See FAQ 4.4. N |
|
From: Laurent-Varin J. <jul...@in...> - 2004-11-16 18:38:05
|
I add -fno-omit-frame-pointer -fno-stack-check for compilation, and the same result appear Selon Nicholas Nethercote <nj...@ca...>: > On Tue, 16 Nov 2004, Laurent-Varin Julien wrote: > > > ==11988== Invalid write of size 4 > > ==11988== at 0x80483B2: ??? > > ==11988== by 0x1B93295C: __libc_start_main (in /lib/tls/libc-2.3.3.so) > > ==11988== by 0x80482F0: ??? > > ==11988== Address 0x1BA68038 is 8 bytes after a block of size 8 alloc'd > > ==11988== at 0x1B906E50: malloc (vg_replace_malloc.c:131) > > ==11988== by 0x80483A5: ??? > > ==11988== by 0x1B93295C: __libc_start_main (in /lib/tls/libc-2.3.3.so) > > ==11988== by 0x80482F0: ??? > > > > Why ??? appear ? > > See FAQ 4.4. > > N > > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
|
From: Nicholas N. <nj...@ca...> - 2004-11-17 17:55:25
|
On Tue, 16 Nov 2004, Laurent-Varin Julien wrote: > I add -fno-omit-frame-pointer -fno-stack-check for compilation, and the same > result appear As the FAQ explains, many libraries come with their symbol tables stripped. Valgrind cannot do any better than "???" if this is the case, as it seems to be on your system. N |
|
From: Nicholas N. <nj...@ca...> - 2004-11-18 10:44:39
|
On Thu, 18 Nov 2004, Laurent-Varin julien wrote: > I'm sorry to insist, but I don't understand; even if I use a stripped > library, I don't strip my own object program, > then why don't I obtain something like that : > > ==10694== Invalid write of size 4 > ==10694== at 0x80483DE: main (test_val.c:8) > ==10694== by 0x1B92DE9F: __libc_start_main (libc-start.c:209) > ==10694== by 0x8048320: ??? > ==10694== Address 0x1BA39038 is 8 bytes after a block of size 8 alloc'd > ==10694== at 0x1B904E28: malloc (vg_replace_malloc.c:131) > ==10694== by 0x80483D1: main (test_val.c:7) > ==10694== by 0x1B92DE9F: __libc_start_main (libc-start.c:209) > ==10694== by 0x8048320: ??? > > rather than : > > ==10694== Invalid write of size 4 > ==10694== at 0x80483DE: ??? > ==10694== by 0x1B92DE9F: __libc_start_main (libc-start.c:209) > ==10694== by 0x8048320: ??? > ==10694== Address 0x1BA39038 is 8 bytes after a block of size 8 alloc'd > ==10694== at 0x1B904E28: malloc (vg_replace_malloc.c:131) > ==10694== by 0x80483D1: ??? > ==10694== by 0x1B92DE9F: __libc_start_main (libc-start.c:209) > ==10694== by 0x8048320: ??? I think it just happens that way sometimes, unfortunately; it's not really Valgrind's fault, the program is optimising its stack usage in such a way that Valgrind can't get a proper trace. I'm not sure how to improve the situation, if you've done everything suggested in the FAQ... N |
|
From: AlexClark <ale...@12...> - 2004-12-20 03:53:45
|
DQoNCgkNCg0KDQpBbGV4Q2xhcmsNCjIwMDQtMTItMjAgIDExOjUxOjE5oaGhoaGhoaGhoaGhoaGh oaGhoaEgIKGhICAgDQoNCg== |
|
From: Yardumian, H. (H. (hrant) <hr...@ch...> - 2005-01-12 18:49:42
|
I am trying to use Valgrind on an executable that's built with the -g option, yet Valgrind complains that it cannot load the debug info and symbols. (see sample output below.) As a result, Valgrind output will not give me exact locations of problems. Are there any settings other than -g that I need when building my executable? Thanks - =3D=3D30298=3D=3D Reading syms from /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ simulator_test/simulator_test_simulator_test_main.exe (0x8048000) =3D=3D30298=3D=3D warning: mmap failed on /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ simulator_test/simulator_test_simulator_test_main.exe =3D=3D30298=3D=3D no symbols or debug info loaded =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0x1B8E4000) =3D=3D30298=3D=3D object doesn't have any debug info =3D=3D30298=3D=3D Reading syms from /.automount/izu/vol/vol0/rpo_rpp_q1/intersect/users/liko/valgrind-2.2.0/ lib/valgrind/stage2 (0xB0000000) =3D=3D30298=3D=3D Reading syms from /lib/ld-2.2.5.so (0xB1000000) =3D=3D30298=3D=3D object doesn't have any debug info =3D=3D30298=3D=3D Reading syms from /lib/libdl-2.2.5.so (0xB1031000) =3D=3D30298=3D=3D object doesn't have any debug info =3D=3D30298=3D=3D Reading syms from /lib/i686/libc-2.2.5.so (0xB1035000) =3D=3D30298=3D=3D object doesn't have any debug info Hrant Yardumian ChevronTexaco - ETC Reservoir Simulation Research - INTERSECT Team 4800 Fournace Pl., Rm E-561 Bellaire, TX 77401-2324 Tel : (713) 432-2816 =20 Mobile : (281) 782-8669 Fax : (713) 432-6620 |
|
From: Chris S. <c.s...@co...> - 2005-01-12 20:23:40
|
On Wed, Jan 12, 2005 at 12:49:23PM -0600, Yardumian, Hrant (HEYA) (hrant) wrote: > > I am trying to use Valgrind on an executable that's built with the -g > option, yet Valgrind complains that it cannot load the debug info and > symbols. (see sample output below.) > > As a result, Valgrind output will not give me exact locations of > problems. > > Are there any settings other than -g that I need when building my > executable? > > Thanks - > You should show the command line used to execute valgrind. What version are you using? > > > ==30298== Reading syms from > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ > simulator_test/simulator_test_simulator_test_main.exe (0x8048000) > ==30298== warning: mmap failed on Why is the mmap failing? > /.automount/zion/d/a/data/intersect/build/build_with_debug/ix/unit_test/ > simulator_test/simulator_test_simulator_test_main.exe > ==30298== no symbols or debug info loaded > ==30298== Reading syms from /lib/ld-2.2.5.so (0x1B8E4000) > ==30298== object doesn't have any debug info > ==30298== Reading syms from > /.automount/izu/vol/vol0/rpo_rpp_q1/intersect/users/liko/valgrind-2.2.0/ > lib/valgrind/stage2 (0xB0000000) > ==30298== Reading syms from /lib/ld-2.2.5.so (0xB1000000) > ==30298== object doesn't have any debug info > ==30298== Reading syms from /lib/libdl-2.2.5.so (0xB1031000) > ==30298== object doesn't have any debug info > ==30298== Reading syms from /lib/i686/libc-2.2.5.so (0xB1035000) > ==30298== object doesn't have any debug info > > Hrant Yardumian > ChevronTexaco - ETC > Reservoir Simulation Research - INTERSECT Team > 4800 Fournace Pl., Rm E-561 > Bellaire, TX 77401-2324 > > Tel : (713) 432-2816 > Mobile : (281) 782-8669 > Fax : (713) 432-6620 > |
|
From: Farid A. <far...@ho...> - 2005-06-13 15:37:46
|
<html><div style='background-color:'><DIV class=RTE>Hi, <BR>I recently switched from valgrind 2.0.0 to valgrind 2.4.0.</DIV> <DIV class=RTE>when I start valgrind with the following options:<BR> valgrind --skin=none --trace-syscalls=yes -v MyProgram</DIV> <DIV class=RTE>valgrind works fine in version 2.0.0 but loading the dynamic libraries at startup takes a long long time to load in verion 2.4.0 (some dynamic libraries took around 4 minutes each to load. Also system calls which did not show in 2.0.0 are now showing in 2.4.0.</DIV> <DIV class=RTE>For example in Valgrind 2.0.0 I will get </DIV> <DIV class=RTE>==8927== Reading syms from /sanbox/foo.so</DIV> <DIV class=RTE>but in Valgrind 2.4.0 I will get something like the following and then a long pause for most dynamic libraries</DIV> <DIV class=RTE> --> 985698304 (0x3AC09000)<BR>SYSCALL[8287,1](125):sys_mprotect ( 0x3AC20000, 13224, 0 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x3AC20000, 16384, 3, 18, 3, 90112 ) --> 985792512 (0x3AC20000)<BR>SYSCALL[8287,1]( 6):sys_close ( 3 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 5) mayBlock:sys_open ( 0xAFEFD4BC(/sandbox/foo.so), 0 ) --> ...<BR>SYSCALL[8287,1]( 5) --> 3 (0x3)<BR>SYSCALL[8287,1]( 3) mayBlock:sys_read ( 3, 0xAFEFD694, 1024 ) --> ...<BR>SYSCALL[8287,1]( 3) --> 1024 (0x400)<BR>SYSCALL[8287,1](197):sys_fstat64 ( 3, 0xAFEFD5C4 ) --> 0 (0x0)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 4096, 3, 34, -1, 0 ) --> 985812992 (0x3AC25000)<BR>SYSCALL[8287,1]( 90) special:old_mmap ( 0x0, 77212, 5, 2, 3, 0 )==8287== Reading syms from /sandbox/foo.so (0x3AC27000)<BR> --> 985821184 (0x3AC27000)</DIV> <DIV class=RTE><BR>What could be wrong?<BR>Thanks<BR>Farid</DIV></div></html> |
|
From: Suihong L. <sui...@re...> - 2005-08-09 18:11:59
|
Hi, =20 I used the valgrind 3.0.0 to check my program (which is basically multithreading + ipq), and got the following output: =20 --9021-- Linux version 2.4.22 (root@XXX) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #4 SMP Fri Sep 26 09:13:25 EDT 2003 --9021-- Reading syms from /home/adm/multithreadipq (0x8048000) --9021-- Reading syms from /lib/ld-2.2.93.so (0x1D487000) --9021-- Reading syms from /usr/local/lib/valgrind/stage2 (0xB0000000) --9021-- Reading suppressions file: /usr/local/lib/valgrind/default.supp =3D=3D9021=3D=3D --9021-- Helgrind is not yet ready to handle Vex IR =20 The program is compiled using gcc -g -o multithreadipq ipq.c -lipq -lpthread. =20 My program is simple, using a pthread_mutex_t to insure concurrence of the ipq_handle. I think valgrind should support it (pthread_create, pthread_join, pthread_mutex_lock/unlock). Does anyone know what I am missing? =20 Any information is appreciated. suihong |
|
From: Tom H. <to...@co...> - 2005-08-09 18:20:25
|
In message <C0F4ACAC25B8DB409D76AB4598AF6176D47D92@MAIL3.toronto.redknee.com>
"Suihong Liang" <sui...@re...> wrote:
> --9021-- Helgrind is not yet ready to handle Vex IR
So you were trying to use helgrind I assume?
> My program is simple, using a pthread_mutex_t to insure concurrence of
> the ipq_handle. I think valgrind should support it (pthread_create,
> pthread_join, pthread_mutex_lock/unlock). Does anyone know what I am
> missing?
What you're missing in this sentence in the NEWS file:
- Addrcheck is currently not working. We hope to get it working again
soon. Helgrind is still not working, as was the case for the 2.4.0
release.
There is no helgrind support in the 2.4.0, 2.4.1 or 3.0.0 releases
of valgrind - if you want to use it you will have to use 2.2.0 I'm
afraid.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-08-09 18:22:28
|
Hi, > I used the valgrind 3.0.0 to check my program (which is basically > multithreading + ipq), and got the following output: The file NEWS in the valgrind top source directory states: Helgrind is still not working, as was the case for the 2.4.0 release. This news seems to have escaped getting included in file README. ;-) Jeroen. |
|
From: Eduardo M. <ea...@us...> - 2006-02-08 19:22:15
|
I greed with you but this is a test from your test suite=20 none/tests/x86/init.c and the int.stderr.exp file has the following: Expected results from valgrind:=20 Process terminating with default action of signal 11 (SIGSEGV) GPF (Pointer out of bounds?) at 0x........: main (int.c:5) I gues you just need to change you test cases or modify the expected=20 results file. Regards, Eduardo A. Mu=F1oz |
|
From: ganapathy s. <rgs...@re...> - 2006-05-09 01:00:20
|
=0A=0Adear gromacs users,=0A i tried to profile the execution of =
grompp using =0Athe callgrind profiling tool.=0A=0Athe command is as belo=
w.=0A>callgrind -v -dump-every-bb =3D 10000000 grompp -f run4.mdp -c run3.g=
ro -p CAVITY2.top -o run4.tpr =0A =0Athe program aborted with the foll=
owing output.=0A=0A=3D7186=3D=3D Callgrind-0.10.1, a call-graph generating =
cache profiler.=0A=3D=3D7186=3D=3D Copyright (C) 2002-2005, and GNU GPL'd, =
by J.Weidendorfer et al.=0A=3D=3D7186=3D=3D Using LibVEX rev 1575, a librar=
y for dynamic binary translation.=0A=3D=3D7186=3D=3D Copyright (C) 2004-200=
5, and GNU GPL'd, by OpenWorks LLP.=0A=3D=3D7186=3D=3D Using valgrind-3.1.1=
, a dynamic binary instrumentation framework.=0A=3D=3D7186=3D=3D Copyright =
(C) 2000-2005, and GNU GPL'd, by Julian Seward et al.=0A=3D=3D7186=3D=3D Fo=
r more details, rerun with: -v=0A=3D=3D7186=3D=3D=0A=3D=3D7186=3D=3D=0A=3D=
=3D7186=3D=3D For interactive control, run 'callgrind_control -h'.=0A =
:-) G R O M A C S (-:=0A=0A Grave=
l Rubs Often Many Awfully Cauterized Sores=0A=0A =
:-) VERSION 3.3.1 (-:=0A=0A=0A Written by David van der Spoel, Erik=
Lindahl, Berk Hess, and others.=0A Copyright (c) 1991-2000, Universi=
ty of Groningen, The Netherlands.=0A Copyright (c) 2001-2006, T=
he GROMACS development team,=0A check out http://www.gromacs.org=
for more information.=0A=0A This program is free software; you can=
redistribute it and/or=0A modify it under the terms of the GNU Ge=
neral Public License=0A as published by the Free Software Foundatio=
n; either version 2=0A of the License, or (at your option) any =
later version.=0A=0A :-) grompp (-:=0A=0AO=
ption Filename Type Description=0A----------------------------=
--------------------------------=0A -f run4.mdp Input, Opt! grompp=
input file with MD parameters=0A -po mdout.mdp Output grompp i=
nput file with MD parameters=0A -c run3.gro Input Generic st=
ructure: gro g96 pdb tpr tpb tpa=0A xml=
=0A -r conf.gro Input, Opt. Generic structure: gro g96 pdb tpr tpb=
tpa=0A xml=0A -rb conf.gro Input,=
Opt. Generic structure: gro g96 pdb tpr tpb tpa=0A =
xml=0A -n index.ndx Input, Opt. Index file=0A-deshuf d=
eshuf.ndx Output, Opt. Index file=0A -p CAVITY2.top Input Topo=
logy file=0A -pp processed.top Output, Opt. Topology file=0A -o ru=
n4.tpr Output Generic run input: tpr tpb tpa xml=0A -t traj.t=
rr Input, Opt. Full precision trajectory: trr trj=0A -e ener.edr =
Input, Opt. Generic energy: edr ene=0A=0A Option Type Value Descr=
iption=0A------------------------------------------------------=0A -[n=
o]h bool no Print help info and quit=0A -[no]X bool no U=
se dialog box GUI to edit command line options=0A -nice int 0=
Set the nicelevel=0A -[no]v bool yes Be loud and noisy=0A =
-time real -1 Take frame at or first after this time.=0A -=
np int 1 Generate statusfile for # nodes=0A-[no]shuffle bool =
no Shuffle molecules over nodes=0A -[no]sort bool no Sort molecu=
les according to X coordinate=0A-[no]rmvsbds bool yes Remove constant=
bonded interactions with virtual=0A sites=0A =
-load string Releative load capacity of each node on a=0A =
parallel machine. Be sure to use quotes around=0A =
the string, which should contain a number for=0A =
each node=0A -maxwarn int 10 Number of =
warnings after which input processing=0A stops=
=0A-[no]check14 bool no Remove 1-4 interactions without Van der Waal=
s=0A -[no]renum bool yes Renumber atomtypes and minimize number of=
=0A atomtypes=0A=0Acreating statusfile for 1 nod=
e...=0Achecking input for internal consistency...=0AWARNING 1 [file run4.md=
p, line unknown]:=0A For energy conservation with switch/shift potentials,=
rlist should be 0.1=0A to 0.3 nm larger than rcoulomb/rvdw.=0Acalling /li=
b/cpp...=0Aprocessing topology...=0AGenerated 141 of the 1176 non-bonded pa=
rameter combinations=0AExcluding 3 bonded neighbours for POP 32=0Aturning H=
bonds into constraints...=0AExcluding 2 bonded neighbours for SOL 1051=0At=
urning H bonds into constraints...=0AExcluding 3 bonded neighbours for POP =
32=0AExcluding 2 bonded neighbours for SOL 1051=0AExcluding 3 bonded neighb=
ours for POP 32=0AExcluding 2 bonded neighbours for SOL 1051=0AExcluding 3 =
bonded neighbours for POP 32=0AExcluding 2 bonded neighbours for SOL 1051=
=0A*** glibc detected *** grompp: realloc(): invalid pointer: 0x04120008 **=
*=0A=3D=3D=3D=3D=3D=3D=3D Backtrace: =3D=3D=3D=3D=3D=3D=3D=3D=3D=0A/lib/lib=
c.so.6(__libc_realloc+0x2e6)[0x1cff15]=0Agrompp[0x80a926d]=0A=3D=3D=3D=3D=
=3D=3D=3D Memory map: =3D=3D=3D=3D=3D=3D=3D=3D=0A0011f000-00120000 r-xp 001=
1f000 00:00 0=0A00148000-00162000 r-xp 00000000 fd:00 945102 /lib/ld-2.=
3.5.so=0A00162000-00163000 r-xp 00019000 fd:00 945102 /lib/ld-2.3.5.so=
=0A00163000-00164000 rwxp 0001a000 fd:00 945102 /lib/ld-2.3.5.so=0A0016=
a000-0028e000 r-xp 00000000 fd:00 945103 /lib/libc-2.3.5.so=0A0028e000-=
00290000 r-xp 00124000 fd:00 945103 /lib/libc-2.3.5.so=0A00290000-00292=
000 rwxp 00126000 fd:00 945103 /lib/libc-2.3.5.so=0A00292000-00294000 r=
wxp 00292000 00:00 0=0A00296000-002b8000 r-xp 00000000 fd:00 945104 /li=
b/libm-2.3.5.so=0A002b8000-002b9000 r-xp 00021000 fd:00 945104 /lib/lib=
m-2.3.5.so=0A002b9000-002ba000 rwxp 00022000 fd:00 945104 /lib/libm-2.3=
.5.so=0A002bc000-002be000 r-xp 00000000 fd:00 945105 /lib/libdl-2.3.5.s=
o=0A002be000-002bf000 r-xp 00001000 fd:00 945105 /lib/libdl-2.3.5.so=0A=
002bf000-002c0000 rwxp 00002000 fd:00 945105 /lib/libdl-2.3.5.so=0A002d=
7000-003a7000 r-xp 00000000 fd:00 1482512 /usr/X11R6/lib/libX11.so.6.2=
=0A003a7000-003ab000 rwxp 000cf000 fd:00 1482512 /usr/X11R6/lib/libX11.s=
o.6.2=0A003ad000-003bb000 r-xp 00000000 fd:00 1482513 /usr/X11R6/lib/lib=
Xext.so.6.4=0A003bb000-003bc000 rwxp 0000e000 fd:00 1482513 /usr/X11R6/l=
ib/libXext.so.6.4=0A003be000-003c5000 r-xp 00000000 fd:00 1476469 /usr/X=
11R6/lib/libXp.so.6.2=0A003c5000-003c6000 rwxp 00006000 fd:00 1476469 /u=
sr/X11R6/lib/libXp.so.6.2=0A004d4000-004dd000 r-xp 00000000 fd:00 945107 =
/lib/libgcc_s-4.0.0-20050520.so.1=0A004dd000-004de000 rwxp 00009000 fd:00=
945107 /lib/libgcc_s-4.0.0-20050520.so.1=0A005cb000-005d3000 r-xp 0000=
0000 fd:00 1482523 /usr/X11R6/lib/libSM.so.6.0=0A005d3000-005d4000 rwxp =
00007000 fd:00 1482523 /usr/X11R6/lib/libSM.so.6.0=0A005d6000-005ed000 r=
-xp 00000000 fd:00 1482522 /usr/X11R6/lib/libICE.so.6.3=0A005ed000-005ee=
000 rwxp 00016000 fd:00 1482522 /usr/X11R6/lib/libICE.so.6.3=0A005ee000-=
005f0000 rwxp 005ee000 00:00 0=0A005f2000-00847000 r-xp 00000000 fd:00 1475=
394 /usr/X11R6/lib/libXm.so.3.0.2=0A00847000-00860000 rwxp 00255000 fd:0=
0 1475394 /usr/X11R6/lib/libXm.so.3.0.2=0A00860000-00861000 rwxp 0086000=
0 00:00 0=0A04000000-04001000 r-xp 00000000 fd:00 260368 /usr/local/lib=
/valgrind/x86-linux/vgpreload_core.so=0A04001000-04002000 rwxp 00000000 fd:=
00 260368 /usr/local/lib/valgrind/x86-linux/vgpreload_core.so=0A0400200=
0-04003000 rwxp 04002000 00:00 0=0A04004000-0400d000 r-xp 00000000 fd:00 94=
3829 /lib/libnss_files-2.3.5.so=0A0400d000-0400e000 r-xp 00008000 fd:00=
943829 /lib/libnss_files-2.3.5.so=0A0400e000-0400f000 rwxp 00009000 fd=
:00 943829 /lib/libnss_files-2.3.5.so=0A04019000-0401a000 rwxp 04019000=
00:00 0=0A0401a000-0406c000 r-xp 00000000 fd:00 1481939 /usr/X11R6/lib/=
libXt.so.6.0=0A0406c000-04070000 rwxp 00052000 fd:00 1481939 /usr/X11R6/=
lib/libXt.so.6.0=0A04070000-04071000 rwxp 04070000 00:00 0=0A04071000-04087=
000 r-xp 00000000 fd:00 1482558 /usr/X11R6/lib/libXmu.so.6.2=0A04087000-=
04088000 rwxp 00015000 fd:00 1482558 /usr/X11R6/lib/libXmu.so.6.2=0A0408=
8000-04229000 rwxp 04088000 00:00 0=0A07f7d000-07f8f000 r-xp 00000000 fd:00=
945114 /lib/libnsl-2.3.5.so=0A07f8f000-07f90000 r-xp 00011000 fd:00 94=
5114 /lib/libnsl-2.3.5.so=0A07f90000-07f91000 rwxp 00012000 fd:00 94511=
4 /lib/libnsl-2.3.5.so=0A07f91000-07f93000 rwxp 07f91000 00:00 0=0A0804=
8000-081c9000 r-xp 00000000 fd:00 2024902 /usr/local/gromacs/bin/grompp=
=0A081c9000-081d0000 rwxp 00181000 fd:00 2024902 /usr/local/gromacs/bin/=
grompp=0A081d0000-08202000 rwxp 081d0000 00:00 0=0A08202000-082bf000 rwxp 0=
8202000 00:00 0=0A61d4a000-6224a000 rwxp 61d4a000 00:00 0=0A6224a000-6224c0=
00 --xp 6224a000 00:00 0=0A6224c000-6225c000 rwxp 6224c000 00:00 0=0A6225c0=
00-6225e000 --xp 6225c000 00:00 0=0A6225e000-633a4000 rwxp 6225e000 00:00 0=
=0Ab0000000-b0125000 r-xp 00000000 fd:00 650893 /usr/local/lib/valgrind=
/x86-linux/callgrind=0Ab0125000-b012e000 rwxp 00125000 fd:00 650893 /us=
r/local/lib/valgrind/x86-linux/callgrind=0Ab012e000-b074c000 rwxp b012e000 =
00:00 0=0Abea85000-bea93000 rwxp bea85000 00:00 0=0Abfa7f000-bfa95000 rw-p =
bfa7f000 00:00 0 [stack]=0A=3D=3D7186=3D=3D=0A=3D=3D7186=3D=3D Eve=
nts : Ir=0A=3D=3D7186=3D=3D Collected : 110292439=0A=3D=3D7186=3D=3D=0A=
=3D=3D7186=3D=3D I refs: 110,292,439=0AAborted=0A =0Athe program ra=
n perfectly without the profiling tool and generated the =0Aoutput files.=
=0A=0Acan anybody help me with a solution or a workaround plzzzz.=0A=0Adoes=
anyone know of other profiling tools that work well with gromacs?=0A=0Atha=
nk you in advance =0A=0Aregards =0Aganapathy senthilkumar =0A |