|
From: Andreas F. <and...@di...> - 2004-05-25 22:24:49
|
Are you compiling with debug information enabled? It looks as if =
valgrind cannot resolve your symbols.
Try adding -g to the compiler flags.
Regards,
Andreas
-----Original Message-----
From: val...@li... on behalf of =
su...@un...
Sent: Tue 5/25/2004 10:00 PM
To: val...@li...
Subject: [Valgrind-users] a problem
=20
hi,
i am a new valgrind user. i am facing the following proble.
i have a test program here=20
#include <stdio.h>
void Leak(char *inStr)
{
char *str =3D (char *) malloc(strlen(inStr));
memcpy(str, inStr, strlen(inStr));
}
char *AvoidLeak(char *inStr)
{
char *str =3D (char *) malloc(strlen(inStr));
memcpy(str, inStr, strlen(inStr));
return str;
}
int main()
{
char *str;
Leak("This leaks 19 bytes");
str =3D AvoidLeak("This is not a 26 byte leak");
free(str);
str =3D AvoidLeak("12 byte leak");
exit(0);
}
i run=20
=20
1) gcc -o test -g test.c
=20
followed by
2) valgrind --leak-check=3Dyes --show-reachable=3Dyes =
--num-callers=3D20
--error-limit=3Dno ./test
**********************************
I should get the output as =20
**********************************
=3D=3D27145=3D=3D valgrind-1.0.0, a memory error detector for x86 =
GNU/Linux.
=3D=3D27145=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian =
Seward.
=3D=3D27145=3D=3D Estimated CPU clock rate is 993 MHz
=3D=3D27145=3D=3D For more details, rerun with: -v
=3D=3D27145=3D=3D=20
=3D=3D27145=3D=3D=20
=3D=3D27145=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 =
from 0)
=3D=3D27145=3D=3D malloc/free: in use at exit: 31 bytes in 2 blocks.
=3D=3D27145=3D=3D malloc/free: 3 allocs, 1 frees, 57 bytes allocated.
=3D=3D27145=3D=3D For counts of detected errors, rerun with: -v
=3D=3D27145=3D=3D searching for pointers to 2 not-freed blocks.
=3D=3D27145=3D=3D checked 3661276 bytes.
=3D=3D27145=3D=3D=20
=3D=3D27145=3D=3D definitely lost: 19 bytes in 1 blocks.
=3D=3D27145=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D27145=3D=3D still reachable: 12 bytes in 1 blocks.
=3D=3D27145=3D=3D=20
=3D=3D27145=3D=3D 12 bytes in 1 blocks are still reachable in loss =
record 1 of 2
=3D=3D27145=3D=3D at 0x40046824: malloc (vg_clientfuncs.c:100)
=3D=3D27145=3D=3D by 0x8048594: AvoidLeak (test.c:11)
=3D=3D27145=3D=3D by 0x804860E: main (test.c:23)
=3D=3D27145=3D=3D by 0x4026A657: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D27145=3D=3D=20
=3D=3D27145=3D=3D 19 bytes in 1 blocks are definitely lost in loss =
record 2 of 2
=3D=3D27145=3D=3D at 0x40046824: malloc (vg_clientfuncs.c:100)
=3D=3D27145=3D=3D by 0x804854C: Leak (test.c:5)
=3D=3D27145=3D=3D by 0x80485DB: main (test.c:20)
=3D=3D27145=3D=3D by 0x4026A657: __libc_start_main =
(../sysdeps/generic/libc-start.c:129)
=3D=3D27145=3D=3D=20
=3D=3D27145=3D=3D LEAK SUMMARY:
=3D=3D27145=3D=3D definitely lost: 19 bytes in 1 blocks.
=3D=3D27145=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D27145=3D=3D still reachable: 12 bytes in 1 blocks.
=3D=3D27145=3D=3D=20
**************************************************
but i am getting output as
**************************************************
[root@localhost test valgrind programs]# valgrind --leak-check=3Dyes
--show-reachable=3Dyes --num-callers=3D20 -v --single-step=3Dyes =
--error-limit=3Dno
--num-callers=3D20 ./a.out
/usr/local/bin/valgrind: line 120: [: too many arguments
=3D=3D21461=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for =
x86-linux.
=3D=3D21461=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D21461=3D=3D Using valgrind-2.0.0, a program supervision framework =
for x86-linux.
=3D=3D21461=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian =
Seward.
=3D=3D21461=3D=3D Command line:
=3D=3D21461=3D=3D ./a.out
=3D=3D21461=3D=3D Startup, with flags:
=3D=3D21461=3D=3D =
--suppressions=3D/usr/local/lib/valgrind/default.supp
=3D=3D21461=3D=3D --leak-check=3Dyes
=3D=3D21461=3D=3D --show-reachable=3Dyes
=3D=3D21461=3D=3D --num-callers=3D20
=3D=3D21461=3D=3D -v
=3D=3D21461=3D=3D --single-step=3Dyes
=3D=3D21461=3D=3D --error-limit=3Dno
=3D=3D21461=3D=3D --num-callers=3D20
=3D=3D21461=3D=3D Reading syms from /lib/ld-2.3.2.so
=3D=3D21461=3D=3D Reading syms from =
/usr/local/lib/valgrind/vgskin_memcheck.so
=3D=3D21461=3D=3D Reading syms from /usr/local/lib/valgrind/valgrind.so
=3D=3D21461=3D=3D Reading syms from /lib/libc-2.3.2.so
=3D=3D21461=3D=3D Reading suppressions file: =
/usr/local/lib/valgrind/default.supp
=3D=3D21461=3D=3D Estimated CPU clock rate is 1999 MHz
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 =
from 0)
=3D=3D21461=3D=3D malloc/free: in use at exit: 31 bytes in 2 blocks.
=3D=3D21461=3D=3D malloc/free: 3 allocs, 1 frees, 57 bytes allocated.
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D searching for pointers to 2 not-freed blocks.
=3D=3D21461=3D=3D checked 3542472 bytes.
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D 12 bytes in 1 blocks are still reachable in loss =
record 1 of 2
=3D=3D21461=3D=3D at 0x400296B2: malloc (vg_replace_malloc.c:153)
=3D=3D21461=3D=3D by 0x8048453: ???
=3D=3D21461=3D=3D by 0x80484CC: ???
=3D=3D21461=3D=3D by 0x402438C6: __libc_start_main (in =
/lib/libc-2.3.2.so)
=3D=3D21461=3D=3D by 0x8048368: ???
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D 19 bytes in 1 blocks are definitely lost in loss =
record 2 of 2
=3D=3D21461=3D=3D at 0x400296B2: malloc (vg_replace_malloc.c:153)
=3D=3D21461=3D=3D by 0x8048411: ???
=3D=3D21461=3D=3D by 0x804849B: ???
=3D=3D21461=3D=3D by 0x402438C6: __libc_start_main (in =
/lib/libc-2.3.2.so)
=3D=3D21461=3D=3D by 0x8048368: ???
=3D=3D21461=3D=3D
=3D=3D21461=3D=3D LEAK SUMMARY:
=3D=3D21461=3D=3D definitely lost: 19 bytes in 1 blocks.
=3D=3D21461=3D=3D possibly lost: 0 bytes in 0 blocks.
=3D=3D21461=3D=3D still reachable: 12 bytes in 1 blocks.
=3D=3D21461=3D=3D suppressed: 0 bytes in 0 blocks.
=3D=3D21461=3D=3D
--21461-- TT/TC: 0 tc sectors discarded.
--21461-- 1163 chainings, 0 unchainings.
--21461-- translate: new 2506 (7663 -> 169097; ratio 220:10)
--21461-- discard 0 (0 -> 0; ratio 0:10).
--21461-- dispatch: 0 jumps (bb entries), of which 2871 (287100%) were =
unchained.
--21461-- 2/2520 major/minor sched events. 2513 tt_fast =
misses.
--21461-- reg-alloc: 1 t-req-spill, 25423+8 orig+spill uis, 8081 =
total-reg-r.
--21461-- sanity: 3 cheap, 1 expensive checks.
--21461-- ccalls: 2233 C calls, 66% saves+restores avoided (8748 =
bytes)
--21461-- 2868 args, avg 0.92 setup instrs each (416 bytes)
--21461-- 0% clear the stack (6699 bytes)
--21461-- 821 retvals, 4% of reg-reg movs avoided (54 bytes)
[root@localhost test valgrind programs]#
can anyone tell me why i am getting ???? instead of getting the function =
name
and line number here
Thank yuo
-------------------------------------------------------
This SF.Net email is sponsored by: Oracle 10g
Get certified on the hottest thing ever to hit the market... Oracle 10g. =
Take an Oracle 10g class now, and we'll give you the exam FREE.
http://ads.osdn.com/?ad_id=3D3149&alloc_id=3D8166&op=3Dclick
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|
|
From: Nicholas N. <nj...@ca...> - 2004-05-26 09:45:45
|
On Wed, 26 May 2004, Andreas Fredriksson wrote: > Are you compiling with debug information enabled? It looks as if valgrind cannot resolve your symbols. > > Try adding -g to the compiler flags. Sudeep is doing this, viz: > 1) gcc -o test -g test.c > ==21461== 19 bytes in 1 blocks are definitely lost in loss record 2 of 2 > ==21461== at 0x400296B2: malloc (vg_replace_malloc.c:153) > ==21461== by 0x8048411: ??? > ==21461== by 0x804849B: ??? > ==21461== by 0x402438C6: __libc_start_main (in /lib/libc-2.3.2.so) > ==21461== by 0x8048368: ??? Even if you weren't compiling with -g, you'd still get function names. 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... N |
|
From: Igmar P. <mai...@jd...> - 2004-06-19 20:16:54
|
> Sudeep is doing this, viz: > > > 1) gcc -o test -g test.c No he's not : [igmar@ouzo igmar]$ gcc -o x -g x.c [igmar@ouzo igmar]$ file x x: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped [igmar@ouzo igmar]$ gcc -g -o x x.c [igmar@ouzo igmar]$ file x x: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped Basic rule : Don't include things that affect the actual generated stuff after -o. Igmar |
|
From: Nicholas N. <nj...@ca...> - 2004-06-19 20:51:21
|
On Sat, 19 Jun 2004, Igmar Palsenberg wrote: > [igmar@ouzo igmar]$ gcc -o x -g x.c > [igmar@ouzo igmar]$ file x > x: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux > 2.2.5, dynamically linked (uses shared libs), not stripped > > [igmar@ouzo igmar]$ gcc -g -o x x.c > [igmar@ouzo igmar]$ file x > x: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux > 2.2.5, dynamically linked (uses shared libs), not stripped > > Basic rule : Don't include things that affect the actual generated stuff > after -o. I'm confused -- what's the difference between the resulting files? N |
|
From: Igmar P. <mai...@jd...> - 2004-06-19 20:57:21
|
> > Basic rule : Don't include things that affect the actual generated stuff > > after -o. > > I'm confused -- what's the difference between the resulting files? Never mind, I need some sleep. Igmar |