You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(21) |
2
(16) |
3
(3) |
4
(8) |
5
(9) |
6
(9) |
|
7
(14) |
8
(16) |
9
(21) |
10
(39) |
11
(29) |
12
(23) |
13
(9) |
|
14
(5) |
15
(8) |
16
(17) |
17
(30) |
18
(8) |
19
(35) |
20
(2) |
|
21
|
22
(2) |
23
(8) |
24
(15) |
25
(6) |
26
(20) |
27
(4) |
|
28
(1) |
29
(4) |
30
(8) |
31
(19) |
|
|
|
|
From: Yeshurun, M. <mei...@in...> - 2005-08-17 11:51:41
|
I could be wrong of course. Perhaps you could try to make Valgrind generate an error for printf by passing weird arguments, and then check in the stack trace if printf is in a.out or in a so. If it's in a so, it would definitely rule out what I suggested. Regards, Meir -----Original Message----- From: Rob Holland [mailto:ti...@ge...]=20 Sent: Wednesday, August 17, 2005 2:44 PM To: Yeshurun, Meir Cc: valgrind-users Subject: RE: [Valgrind-users] Replacing printf On Wed, 2005-08-17 at 14:38 +0300, Yeshurun, Meir wrote: > It's possible that printf is a small inline function or a template > function (which then turns around and calls fprintf) that is compiled > into your program, not one of the so's. You need to find a way to leave > the code for printf out of your program, so your program will have to > call the code for printf that is in one of the so's.=20 Hmm. nm a.out reports: U printf@@GLIBC_2.2.5 Doesn't that mean it will trying to find it from a shared library? If I use fprintf, I get U fprintf@@GLIBC_2.2.5 Which implies that they aren't different in how they are resolved. Cheers, Rob --=20 |
|
From: Tom H. <to...@co...> - 2005-08-17 11:50:10
|
In message <1124276546.3197.16.camel@localhost.localdomain>
Rob Holland <ti...@ge...> wrote:
> I've happily managed to replace fprintf and some others, but not
> printf.
That's odd, because I can see printf being replace in your log output
but not fprintf...
> Anyone know what's special about printf and why I can't replace it with
> VG_REPLACE_FUNCTION like I can the others?
You probably just haven't go the right name or something.
> It's not helped that I don't quite understand the syntax of the
> trace-redirs report.
I'll insert some comments to explain it...
> --30136-- Just loaded /usr/local/lib64/valgrind/vg_preload_core.so (soname=vg_preload_core.so),
We've loaded the preload library. Why is it vg_preload_core by the
way? Surely it should be vgpreload_<tool>.so?
> --30136-- resolving any unresolved redirs with it
> --30136-- Finished resolving
We checked if there were redirections pending for any symbols in
that library and (as expected) there weren't.
> --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50
We found a redirection for printf in the vg_preload_core.so library
but as libc has not been loaded yet we can't resolve it.
> --30136-- Just loaded /usr/local/lib64/valgrind/vgpreload_formatcheck.so (soname=(null)),
Now we've loaded your tool preload library but it doesn't seem to
contain any redirections.
> --30136-- Just loaded /lib64/tls/libc-2.3.5.so (soname=libc.so.6),
Now we've loaded libc...
> --30136-- resolving any unresolved redirs with it
...and started resolving any pending redirections in it...
> --30136-- redir resolved (soname:libc.so.6:printf=0x2586FE60 -> 0x2571AF50)
...and found that pending redirection for printf and resolved it so
any call to printf should now get redirected.
> The code is of course available should anyone feel it would be helpful,
> but as it works fine for fprintf I'm assuming the code is ok and that
> printf is "special" in some way I'm unaware of.
Are you sure your test program is actually calling printf and that gcc
and/or the glibc headers haven't turned it into a call to some other
routine?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Rob H. <ti...@ge...> - 2005-08-17 11:44:12
|
On Wed, 2005-08-17 at 14:38 +0300, Yeshurun, Meir wrote: > It's possible that printf is a small inline function or a template > function (which then turns around and calls fprintf) that is compiled > into your program, not one of the so's. You need to find a way to leave > the code for printf out of your program, so your program will have to > call the code for printf that is in one of the so's.=20 Hmm. nm a.out reports: U printf@@GLIBC_2.2.5 Doesn't that mean it will trying to find it from a shared library? If I use fprintf, I get U fprintf@@GLIBC_2.2.5 Which implies that they aren't different in how they are resolved. Cheers, Rob --=20 |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-17 11:38:56
|
It's possible that printf is a small inline function or a template function (which then turns around and calls fprintf) that is compiled into your program, not one of the so's. You need to find a way to leave the code for printf out of your program, so your program will have to call the code for printf that is in one of the so's.=20 Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Rob Holland Sent: Wednesday, August 17, 2005 2:02 PM To: valgrind-users Subject: [Valgrind-users] Replacing printf Hi, As part of the format check code I need to replace printf with our own version which runs some sanity checks. I've happily managed to replace fprintf and some others, but not printf. Anyone know what's special about printf and why I can't replace it with VG_REPLACE_FUNCTION like I can the others? The output of 'valgrind --tool=3Dformatcheck --trace-redirs=3Dyes = /tmp/test' looks the same whether I try to replace fprintf or printf (save the different function name obviously), but when trying to redirect the printf function my replacement isn't actually called :/ It's not helped that I don't quite understand the syntax of the trace-redirs report. It says it's loaded vg_preload_core.so and then lists some REDIRS including the (f)printf one which is in my preload library which it hasn't loaded yet, then it says it's loaded my preload, but there is no mention of the (f)printf redir which is there. If I remove the VG_REPLACE_FUNCTION from my code, it doesn't mention any (f)printf redirections, so I'm assuming there is no printf redirection in the core valgrind. Example: <header snipped> --30136-- Just loaded /tmp/a.out (soname=3D(null)), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- Just loaded /lib64/ld-2.3.5.so = (soname=3Dld-linux-x86-64.so.2), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- REDIRECT addr to addr: 0xFFFFFFFFFF600000 to 0x7002B2DB --30136-- redir resolved ((null):(null)=3D0xFFFFFFFFFF600000 -> 0x7002B2DB) --30136-- Discarding translation due to redirect of already loaded function --30136-- (null):(null)(0xFFFFFFFFFF600000) -> 0x7002B2DB) --30136-- REDIRECT addr to addr: 0xFFFFFFFFFF600400 to 0x7002B2E5 --30136-- redir resolved ((null):(null)=3D0xFFFFFFFFFF600400 -> 0x7002B2E5) --30136-- Discarding translation due to redirect of already loaded function --30136-- (null):(null)(0xFFFFFFFFFF600400) -> 0x7002B2E5) =3D=3D30136=3D=3D For more details, rerun with: -v =3D=3D30136=3D=3D=20 --30136-- Just loaded /usr/local/lib64/valgrind/vg_preload_core.so (soname=3Dvg_preload_core.so), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- REDIR sym to addr: soname:libc.so.6:_Znwm to 0x25719C0F --30136-- REDIR sym to addr: soname:libstdc++*:builtin_new to 0x25719840 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_delete to 0x2571A821 --30136-- REDIR sym to addr: soname:libstdc++*:_ZnamRKSt9nothrow_t to 0x2571A124 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_new to 0x25719E18 --30136-- REDIR sym to addr: soname:libc.so.6:_ZnamRKSt9nothrow_t to 0x2571A1C7 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_new to 0x25719A89 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdlPvRKSt9nothrow_t to 0x2571A717 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdlPv to 0x2571A60D --30136-- REDIR sym to addr: soname:libstdc++*:_ZnwmRKSt9nothrow_t to 0x25719CD2 --30136-- REDIR sym to addr: soname:libc.so.6:memalign to 0x2571AC4E --30136-- REDIR sym to addr: soname:libc.so.6:_ZnwmRKSt9nothrow_t to 0x25719D75 --30136-- REDIR sym to addr: soname:libc.so.6:realloc to 0x2571AB63 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdaPv to 0x2571A92B --30136-- REDIR sym to addr: soname:libc.so.6:malloc_trim to 0x2571AE72 --30136-- REDIR sym to addr: soname:libc.so.6:free to 0x2571A2EF --30136-- REDIR sym to addr: soname:libstdc++*:malloc to 0x257196FA --30136-- REDIR sym to addr: soname:libc.so.6:mallopt to 0x2571AD2C --30136-- REDIR sym to addr: soname:libstdc++*:_Znam to 0x25719F9E --30136-- REDIR sym to addr: soname:libc.so.6:malloc_set_state to 0x2571AE96 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdlPvRKSt9nothrow_t to 0x2571A692 --30136-- REDIR sym to addr: soname:libc.so.6:cfree to 0x2571A3F9 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_delete to 0x2571A503 --30136-- REDIR sym to addr: soname:libstdc++*:free to 0x2571A26A --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_new to 0x25719EDB --30136-- REDIR sym to addr: soname:libc.so.6:valloc to 0x2571AD19 --30136-- REDIR sym to addr: soname:libc.so.6:malloc to 0x2571979D --30136-- REDIR sym to addr: soname:libc.so.6:mallinfo to 0x2571AEA8 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdlPv to 0x2571A588 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_new to 0x257199C6 --30136-- REDIR sym to addr: soname:libc.so.6:pvalloc to 0x2571AE4E --30136-- REDIR sym to addr: soname:libc.so.6:builtin_new to 0x25719903 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_delete to 0x2571A47E --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50 --30136-- REDIR sym to addr: soname:libc.so.6:calloc to 0x2571AABA --30136-- REDIR sym to addr: soname:libstdc++*:_Znwm to 0x25719B4C --30136-- REDIR sym to addr: soname:libc.so.6:malloc_stats to 0x2571AE60 --30136-- REDIR sym to addr: soname:libstdc++*:cfree to 0x2571A374 --30136-- REDIR sym to addr: soname:libc.so.6:malloc_get_state to 0x2571AE84 --30136-- REDIR sym to addr: soname:libc.so.6:posix_memalign to 0x2571AD37 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_delete to 0x2571A79C --30136-- REDIR sym to addr: soname:libc.so.6:malloc_usable_size to 0x2571AD80 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdaPvRKSt9nothrow_t to 0x2571AA35 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdaPvRKSt9nothrow_t to 0x2571A9B0 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdaPv to 0x2571A8A6 --30136-- REDIR sym to addr: soname:libc.so.6:_Znam to 0x2571A061 --30136-- Just loaded /usr/local/lib64/valgrind/vgpreload_formatcheck.so (soname=3D(null)), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- Just loaded /lib64/tls/libc-2.3.5.so (soname=3Dlibc.so.6), --30136-- resolving any unresolved redirs with it --30136-- redir resolved (soname:libc.so.6:malloc_usable_size=3D0x2588FAC0 -> 0x2571AD80) --30136-- redir resolved (soname:libc.so.6:posix_memalign=3D0x25893CA0 -> 0x2571AD37) --30136-- redir resolved = (soname:libc.so.6:malloc_get_state=3D0x258926A0 -> 0x2571AE84) --30136-- redir resolved (soname:libc.so.6:malloc_stats=3D0x25893170 = -> 0x2571AE60) --30136-- redir resolved (soname:libc.so.6:calloc=3D0x25891EE0 -> 0x2571AABA) --30136-- redir resolved (soname:libc.so.6:printf=3D0x2586FE60 -> 0x2571AF50) --30136-- redir resolved (soname:libc.so.6:pvalloc=3D0x25893330 -> 0x2571AE4E) --30136-- redir resolved (soname:libc.so.6:mallinfo=3D0x258930B0 -> 0x2571AEA8) --30136-- redir resolved (soname:libc.so.6:malloc=3D0x25892210 -> 0x2571979D) --30136-- redir resolved (soname:libc.so.6:valloc=3D0x25893430 -> 0x2571AD19) --30136-- redir resolved = (soname:libc.so.6:malloc_set_state=3D0x25893520 -> 0x2571AE96) --30136-- redir resolved (soname:libc.so.6:mallopt=3D0x25893010 -> 0x2571AD2C) --30136-- redir resolved (soname:libc.so.6:free=3D0x25890630 -> 0x2571A2EF) --30136-- redir resolved (soname:libc.so.6:malloc_trim=3D0x2588FE70 -> 0x2571AE72) --30136-- redir resolved (soname:libc.so.6:realloc=3D0x25892860 -> 0x2571AB63) --30136-- redir resolved (soname:libc.so.6:memalign=3D0x258924B0 -> 0x2571AC4E) --30136-- Finished resolving --30136-- Just loaded /lib64/libdl-2.3.5.so (soname=3Dlibdl.so.2), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving foo =3D=3D30136=3D=3D The code is of course available should anyone feel it would be helpful, but as it works fine for fprintf I'm assuming the code is ok and that printf is "special" in some way I'm unaware of. Thanks, Rob --=20 - Rob Holland [ Gentoo Audit Team ] |
|
From: Bob R. <bo...@br...> - 2005-08-17 11:24:39
|
On Sat, Aug 13, 2005 at 06:39:38PM -0700, Robert Walsh wrote: > > > Why do you think these are malloc bugs? These are locations in your > > > code where you called malloc to allocate memory but subsequently never > > > freed it. These are genuine memory leaks. What do you mean "can not > > > reproduce them"? > > > > Yeah, sorry for saying "can not reproduce them". What I mean to say > > is, I can not figure out how to track down the leak. Usually, I can do > > this very easily. For some reason, I can't do it in this case. > > > > Valgrind usually reports when the memory was leaked, right? Because the > > left hand side of the assignment is NULL when the malloc is done and > > assigns the value. How could this be a memory leak? > > Valgrind reports where (not when) the memory that was leaked was > allocated. So that malloc stack backtrace you see was an instance of > some memory that was allocated but never freed. The lvalue would only > factor into this if it already pointed to some allocated memory: > > 1: char *lv; > 2: lv = malloc(10); > 3: lv = malloc(10); > 4: free(lv); > > would show up as a memory leak on line 2. Nothing would show up for > line 3, which is where the leak actually happens. > > You can instrument your code to force Valgrind to do a leak check on the > fly, which might help you track down exactly where the leak is > happening. See the instructions for VALGRIND_DO_LEAK_CHECK in the user > guide. Well, I finally found the memory leak. Most of the time it's much easier, but this time it was difficult. Thanks for the help. Bob Rossi |
|
From: Rob H. <ti...@ge...> - 2005-08-17 11:02:32
|
Hi, As part of the format check code I need to replace printf with our own version which runs some sanity checks. I've happily managed to replace fprintf and some others, but not printf. Anyone know what's special about printf and why I can't replace it with VG_REPLACE_FUNCTION like I can the others? The output of 'valgrind --tool=3Dformatcheck --trace-redirs=3Dyes /tmp/test= ' looks the same whether I try to replace fprintf or printf (save the different function name obviously), but when trying to redirect the printf function my replacement isn't actually called :/ It's not helped that I don't quite understand the syntax of the trace-redirs report. It says it's loaded vg_preload_core.so and then lists some REDIRS including the (f)printf one which is in my preload library which it hasn't loaded yet, then it says it's loaded my preload, but there is no mention of the (f)printf redir which is there. If I remove the VG_REPLACE_FUNCTION from my code, it doesn't mention any (f)printf redirections, so I'm assuming there is no printf redirection in the core valgrind. Example: <header snipped> --30136-- Just loaded /tmp/a.out (soname=3D(null)), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- Just loaded /lib64/ld-2.3.5.so (soname=3Dld-linux-x86-64.so.2), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- REDIRECT addr to addr: 0xFFFFFFFFFF600000 to 0x7002B2DB --30136-- redir resolved ((null):(null)=3D0xFFFFFFFFFF600000 -> 0x7002B2DB) --30136-- Discarding translation due to redirect of already loaded function --30136-- (null):(null)(0xFFFFFFFFFF600000) -> 0x7002B2DB) --30136-- REDIRECT addr to addr: 0xFFFFFFFFFF600400 to 0x7002B2E5 --30136-- redir resolved ((null):(null)=3D0xFFFFFFFFFF600400 -> 0x7002B2E5) --30136-- Discarding translation due to redirect of already loaded function --30136-- (null):(null)(0xFFFFFFFFFF600400) -> 0x7002B2E5) =3D=3D30136=3D=3D For more details, rerun with: -v =3D=3D30136=3D=3D=20 --30136-- Just loaded /usr/local/lib64/valgrind/vg_preload_core.so (soname=3Dvg_preload_core.so), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- REDIR sym to addr: soname:libc.so.6:_Znwm to 0x25719C0F --30136-- REDIR sym to addr: soname:libstdc++*:builtin_new to 0x25719840 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_delete to 0x2571A821 --30136-- REDIR sym to addr: soname:libstdc++*:_ZnamRKSt9nothrow_t to 0x2571A124 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_new to 0x25719E18 --30136-- REDIR sym to addr: soname:libc.so.6:_ZnamRKSt9nothrow_t to 0x2571A1C7 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_new to 0x25719A89 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdlPvRKSt9nothrow_t to 0x2571A717 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdlPv to 0x2571A60D --30136-- REDIR sym to addr: soname:libstdc++*:_ZnwmRKSt9nothrow_t to 0x25719CD2 --30136-- REDIR sym to addr: soname:libc.so.6:memalign to 0x2571AC4E --30136-- REDIR sym to addr: soname:libc.so.6:_ZnwmRKSt9nothrow_t to 0x25719D75 --30136-- REDIR sym to addr: soname:libc.so.6:realloc to 0x2571AB63 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdaPv to 0x2571A92B --30136-- REDIR sym to addr: soname:libc.so.6:malloc_trim to 0x2571AE72 --30136-- REDIR sym to addr: soname:libc.so.6:free to 0x2571A2EF --30136-- REDIR sym to addr: soname:libstdc++*:malloc to 0x257196FA --30136-- REDIR sym to addr: soname:libc.so.6:mallopt to 0x2571AD2C --30136-- REDIR sym to addr: soname:libstdc++*:_Znam to 0x25719F9E --30136-- REDIR sym to addr: soname:libc.so.6:malloc_set_state to 0x2571AE96 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdlPvRKSt9nothrow_t to 0x2571A692 --30136-- REDIR sym to addr: soname:libc.so.6:cfree to 0x2571A3F9 --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_delete to 0x2571A503 --30136-- REDIR sym to addr: soname:libstdc++*:free to 0x2571A26A --30136-- REDIR sym to addr: soname:libc.so.6:__builtin_vec_new to 0x25719EDB --30136-- REDIR sym to addr: soname:libc.so.6:valloc to 0x2571AD19 --30136-- REDIR sym to addr: soname:libc.so.6:malloc to 0x2571979D --30136-- REDIR sym to addr: soname:libc.so.6:mallinfo to 0x2571AEA8 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdlPv to 0x2571A588 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_new to 0x257199C6 --30136-- REDIR sym to addr: soname:libc.so.6:pvalloc to 0x2571AE4E --30136-- REDIR sym to addr: soname:libc.so.6:builtin_new to 0x25719903 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_delete to 0x2571A47E --30136-- REDIR sym to addr: soname:libc.so.6:printf to 0x2571AF50 --30136-- REDIR sym to addr: soname:libc.so.6:calloc to 0x2571AABA --30136-- REDIR sym to addr: soname:libstdc++*:_Znwm to 0x25719B4C --30136-- REDIR sym to addr: soname:libc.so.6:malloc_stats to 0x2571AE60 --30136-- REDIR sym to addr: soname:libstdc++*:cfree to 0x2571A374 --30136-- REDIR sym to addr: soname:libc.so.6:malloc_get_state to 0x2571AE84 --30136-- REDIR sym to addr: soname:libc.so.6:posix_memalign to 0x2571AD37 --30136-- REDIR sym to addr: soname:libstdc++*:__builtin_vec_delete to 0x2571A79C --30136-- REDIR sym to addr: soname:libc.so.6:malloc_usable_size to 0x2571AD80 --30136-- REDIR sym to addr: soname:libc.so.6:_ZdaPvRKSt9nothrow_t to 0x2571AA35 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdaPvRKSt9nothrow_t to 0x2571A9B0 --30136-- REDIR sym to addr: soname:libstdc++*:_ZdaPv to 0x2571A8A6 --30136-- REDIR sym to addr: soname:libc.so.6:_Znam to 0x2571A061 --30136-- Just loaded /usr/local/lib64/valgrind/vgpreload_formatcheck.so (soname=3D(null)), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving --30136-- Just loaded /lib64/tls/libc-2.3.5.so (soname=3Dlibc.so.6), --30136-- resolving any unresolved redirs with it --30136-- redir resolved (soname:libc.so.6:malloc_usable_size=3D0x2588FAC0 -> 0x2571AD80) --30136-- redir resolved (soname:libc.so.6:posix_memalign=3D0x25893CA0 -> 0x2571AD37) --30136-- redir resolved (soname:libc.so.6:malloc_get_state=3D0x258926A0 -> 0x2571AE84) --30136-- redir resolved (soname:libc.so.6:malloc_stats=3D0x25893170 -> 0x2571AE60) --30136-- redir resolved (soname:libc.so.6:calloc=3D0x25891EE0 -> 0x2571AABA) --30136-- redir resolved (soname:libc.so.6:printf=3D0x2586FE60 -> 0x2571AF50) --30136-- redir resolved (soname:libc.so.6:pvalloc=3D0x25893330 -> 0x2571AE4E) --30136-- redir resolved (soname:libc.so.6:mallinfo=3D0x258930B0 -> 0x2571AEA8) --30136-- redir resolved (soname:libc.so.6:malloc=3D0x25892210 -> 0x2571979D) --30136-- redir resolved (soname:libc.so.6:valloc=3D0x25893430 -> 0x2571AD19) --30136-- redir resolved (soname:libc.so.6:malloc_set_state=3D0x25893520 -> 0x2571AE96) --30136-- redir resolved (soname:libc.so.6:mallopt=3D0x25893010 -> 0x2571AD2C) --30136-- redir resolved (soname:libc.so.6:free=3D0x25890630 -> 0x2571A2EF) --30136-- redir resolved (soname:libc.so.6:malloc_trim=3D0x2588FE70 -> 0x2571AE72) --30136-- redir resolved (soname:libc.so.6:realloc=3D0x25892860 -> 0x2571AB63) --30136-- redir resolved (soname:libc.so.6:memalign=3D0x258924B0 -> 0x2571AC4E) --30136-- Finished resolving --30136-- Just loaded /lib64/libdl-2.3.5.so (soname=3Dlibdl.so.2), --30136-- resolving any unresolved redirs with it --30136-- Finished resolving foo =3D=3D30136=3D=3D The code is of course available should anyone feel it would be helpful, but as it works fine for fprintf I'm assuming the code is ok and that printf is "special" in some way I'm unaware of. Thanks, Rob --=20 - Rob Holland [ Gentoo Audit Team ] |
|
From: Tom H. <to...@co...> - 2005-08-17 07:29:31
|
In message <200...@ge...>
Christian Parpart <tr...@ge...> wrote:
> just to be sure i'm not mistaken (and this is because of my borked app):
>
> I ran into the following unhandled instruction bytes:
>
> vex amd64->IR: unhandled instruction bytes: 0xCD 0x5 0x48 0x89
That's "int $5" which seems pretty unlikely. I would guess that your
program has jumped to a bad address.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Christian P. <tr...@ge...> - 2005-08-17 07:19:30
|
Hi, just to be sure i'm not mistaken (and this is because of my borked app): I ran into the following unhandled instruction bytes: vex amd64->IR: unhandled instruction bytes: 0xCD 0x5 0x48 0x89 Regards, Christian Parpart. p.s.: VG 3.0 trunk (2days old) =2D-=20 09:17:25 up 146 days, 22:25, 2 users, load average: 1.58, 2.52, 2.81 |
|
From: prashantha a.s <pra...@ya...> - 2005-08-17 07:02:38
|
Hi, I tried with this, but again i am getting same problem. Please find the atachment. I am giving you entire detalis of memory and also the error that i am getting. Could you please help me regarding this Regards Prahantha.AS --- Tom Hughes <to...@co...> wrote: > In message > <942...@ha...> > "Yeshurun, Meir" <mei...@in...> > wrote: > > > In line 272 of coregrind/stage1.c > > > > info.exe_base = VG_ROUNDDN(info.exe_end - > 0x02000000, 0x10000000); > > > > change the '2' to '4' (i.e., multiply 0x02000000 > by 2) > > > > and then make, make install again > > That will only work if it is a PIE build. He is > using 2.4.0 though > so it may well be as that was the default then. > > If it isn't a PIE build then KICKSTART_BASE will > been to be lowered. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software > Conference & EXPO > September 19-22, 2005 * San Francisco, CA * > Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects > & Teams * Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-17 05:39:37
|
Sorry, this message was delayed for some reason -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Yeshurun, Meir Sent: Wednesday, August 17, 2005 8:17 AM To: Rob Holland Cc: val...@li... Subject: RE: [Valgrind-users] Problem with needs_malloc_replacement Hi, Please run with --trace-redir=3Dyes and show us the output Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Rob Holland Sent: Tuesday, August 16, 2005 8:28 PM To: valgrind-users Subject: [Valgrind-users] Problem with needs_malloc_replacement Hi, I've uploaded a valgrind tool which I created out of bits of various existing tools. The code can be found here: http://dev.gentoo.org/~tigger/fc_main.c It's basically a 300 line no-op at the moment as it doesn't print anything. It's intended to keep track of what's on the heap. However, needs_malloc_replacement isn't having the effect which I expected. Namely, my replacements aren't being run. I can add a VG_(exit)(1); into the malloc routine and nothing changes. I'm a bit lost as to why it's not being used. Anyone have any idea? Thanks, Rob ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-17 05:17:20
|
Hi, Please run with --trace-redir=3Dyes and show us the output Regards, Meir -----Original Message----- From: val...@li... [mailto:val...@li...] On Behalf Of Rob Holland Sent: Tuesday, August 16, 2005 8:28 PM To: valgrind-users Subject: [Valgrind-users] Problem with needs_malloc_replacement Hi, I've uploaded a valgrind tool which I created out of bits of various existing tools. The code can be found here: http://dev.gentoo.org/~tigger/fc_main.c It's basically a 300 line no-op at the moment as it doesn't print anything. It's intended to keep track of what's on the heap. However, needs_malloc_replacement isn't having the effect which I expected. Namely, my replacements aren't being run. I can add a VG_(exit)(1); into the malloc routine and nothing changes. I'm a bit lost as to why it's not being used. Anyone have any idea? Thanks, Rob ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Valgrind-users mailing list Val...@li... https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Nicholas N. <nj...@cs...> - 2005-08-17 02:53:28
|
On Mon, 15 Aug 2005, Neil Youngman wrote: > The problem seems to be that valgrind-3.0.0/VEX/Makefile has CC=gcc, > although it was set to gcc-3.4.4 in the configuration. Changing it in > this Makefile allows valgrind to build. > > This seems to be a deficiency in the configuration script. Yes. Vex has a hand-written Makefile, it does not use the automake/autoconf stuff that the rest of Valgrind does. The two options I can see are: - import CC from the configure script in the way that causes the minimum disturbance (I don't know how to do that, though) - fully automake/autoconf-ify Vex. The latter is made trickier by Vex being an SVN external module. Tom, do you know what would be a good way to fix this problem? N |
|
From: Donald Z. <don...@am...> - 2005-08-16 21:32:52
|
I am trying to use valgrind on Redhat Enterprise Linux 3, Update 5 on x86_64 and am getting the following error. Can anyone tell me what this means and if there is a way to fix it? ==12634== Memcheck, a memory error detector. ==12634== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==12634== Using LibVEX rev 1313, a library for dynamic binary translation. ==12634== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==12634== Using valgrind-3.0.0, a dynamic binary instrumentation framework. ==12634== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. valgrind: symtab.c:377 (vgModuleLocal_addCfiSI): Assertion 'cfisi->len > 0 && cfisi->len < 2000000' failed. ==12634== at 0x7001A7BD: ??? sched status: running_tid=0 Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. Thanks -- Donald Zoch don...@am... |
|
From: Rob H. <ti...@ge...> - 2005-08-16 20:48:33
|
On Tue, 2005-08-16 at 15:33 -0500, Nicholas Nethercote wrote: > Valgrind's replacement versions of malloc et al aren't being called.=20 > What does the Makefile.am in valgrind/formatcheck/ look like? It should=20 > look like this: It didn't. I'd copied it from none/ and just substituted nl->fc :) > If I take out all the vg_preload_formatcheck_so parts, I get the same=20 > behaviour as you. Works now! Many thanks :) Now to switch it to the Massif model :) Rob --=20 - Rob Holland [ Gentoo Audit Team ] |
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 20:33:24
|
On Tue, 16 Aug 2005, Rob Holland wrote:
> tigger@xahn % valgrind --trace-malloc=yes --tool=formatcheck ./a.out
> ==20590== formatcheck, format string check.
> ==20590== Copyright (C) 2005, and GNU GPL'd, by Rob Holland.
> ==20590== Using LibVEX rev 1338, a library for dynamic binary
> translation.
> ==20590== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
> ==20590== Using valgrind-3.1.SVN, a dynamic binary instrumentation
> framework.
> ==20590== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et
> al.
> ==20590== For more details, rerun with: -v
> ==20590==
> ==20590==
> tigger@xahn %
>
> If I run simply: 'valgrind --trace-malloc=yes ls' it does indeed print
> lots of malloc/frees properly.
Valgrind's replacement versions of malloc et al aren't being called.
What does the Makefile.am in valgrind/formatcheck/ look like? It should
look like this:
include $(top_srcdir)/Makefile.tool.am
val_PROGRAMS = vgtool_formatcheck.so vgpreload_formatcheck.so
vgtool_formatcheck_so_SOURCES = fc_main.c
vgtool_formatcheck_so_LDFLAGS = -shared
vgpreload_formatcheck_so_SOURCES =
vgpreload_formatcheck_so_DEPENDENCIES = \
$(LIBREPLACEMALLOC)
vgpreload_formatcheck_so_LDFLAGS = -shared -Wl,-z,interpose,-z,initfirst \
-Wl,--whole-archive \
$(LIBREPLACEMALLOC) \
-Wl,--no-whole-archive
If I take out all the vg_preload_formatcheck_so parts, I get the same
behaviour as you.
Nick
|
|
From: Rob H. <ti...@ge...> - 2005-08-16 20:06:45
|
On Tue, 2005-08-16 at 20:23 +0100, Rob Holland wrote: > On Tue, 2005-08-16 at 13:47 -0500, Nicholas Nethercote wrote: > > > I just tried running your code after inserting a VG_(printf)() statement > > into alloc_and_new_mem() and it was executed as expected. Is your program > > definitely calling malloc()? Try using --trace-malloc=yes to see if it > > is. > > I was running it on "ls". Just to make 100% sure I did: Sorry, misunderstood what you meant. If I run simply: 'valgrind --trace-malloc=yes ls' it does indeed print lots of malloc/frees properly. Still none the wiser as to why my code is broken :( Cheers, Rob |
|
From: Rob H. <ti...@ge...> - 2005-08-16 19:23:11
|
On Tue, 2005-08-16 at 13:47 -0500, Nicholas Nethercote wrote:
> I just tried running your code after inserting a VG_(printf)() statement
> into alloc_and_new_mem() and it was executed as expected. Is your program
> definitely calling malloc()? Try using --trace-malloc=yes to see if it
> is.
I was running it on "ls". Just to make 100% sure I did:
tigger@xahn % cat test.c
#include <stdio.h>
#include <malloc.h>
int main(int argc, char **argv) {
void *data;
data = malloc(2);
}
tigger@xahn % gcc test.c
tigger@xahn % valgrind --trace-malloc=yes --tool=formatcheck ./a.out
==20590== formatcheck, format string check.
==20590== Copyright (C) 2005, and GNU GPL'd, by Rob Holland.
==20590== Using LibVEX rev 1338, a library for dynamic binary
translation.
==20590== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==20590== Using valgrind-3.1.SVN, a dynamic binary instrumentation
framework.
==20590== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et
al.
==20590== For more details, rerun with: -v
==20590==
==20590==
tigger@xahn %
This was having done 'svn up; make'.
I don't get it :/
If it makes any difference, I'm on an amd64.
> Nb: You based the code off Helgrind, it might be worth instead basing it
> off Massif from the current SVN trunk; a few changes have gone in over
> the last few days that make this stuff a bit neater -- the VgHashTable
> type has changed a bit so you don't have to use as many casts, and you can
> use simple lookup() and remove() functions rather than the strange
> VG_(HT_get_node)() function. Your current code will still work, though,
> if you don't feel like changing it.
Cool, thanks for the hint.
> Do you have a clear idea how you'll check format strings? I'd be
> interested to hear what you have planned.
I'm attempting to turn the preload library written by the Gentoo Audit
Team into a valgrind tool so we can do more advanced checks. We'll be
generating a lot of noise (I hope to learn more about suppression
shortly ;) but basically we aim to warn about *printf without any format
specifiers, format strings which aren't string literals, that kind of
thing.
It's pretty noisy, but it's useful for spotting potential problems:
user-fed format strings, double expansion and so on.
Thanks for the help!
Rob
|
|
From: Bob D. <bd...@sr...> - 2005-08-16 19:04:28
|
> Is there a way to tell what address the block is at ? In my program, > the address used will malloc many, many times, with the memory following > different paths - by knowing the address, I can figure out where it > is going using printfs. I found this in the mailing list archives: http://sourceforge.net/mailarchive/message.php?msg_id=9259815 It requires you to modify and recompile the valgrind source. But, it's a starting point to get what you want. Bob |
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 18:56:38
|
On Tue, 16 Aug 2005, Bill May wrote: > I'm using 3.0.0 and would like to know how I can get the > address of the memory that the leak check displays at the > end of execution. > > I'm using: > valgrind --tool=memcheck --leak-check=full --leak-resolution=high > --trace-children=yes --show-reachable=yes <command line> > > It works brillantly, and display lines like: > > 2048 bytes in 1 blocks are definately lost in loss record 6 of 6 > at 0x1B90088D: malloc (vg_replace_malloc.c:149) > by 0x1b9C4e6d: ???? > by ... > > Is there a way to tell what address the block is at ? In my program, > the address used will malloc many, many times, with the memory following > different paths - by knowing the address, I can figure out where it > is going using printfs. I don't think so. Memcheck doesn't record the block addresses, because each message can describe many blocks, as in this case: > 2048 bytes in 32 blocks are definately lost in loss record 6 of 6 It commons up all the info about the 32 blocks into a single lump, losing the individual block addresses as it does. You'd have to hack around memcheck/mac_leakcheck.c a bit. 'lc_shadows' is the array holding all the remaining heap blocks. The call to 'VG_(unique_error)()' is where each loss record is recorded; you could at that point scan through 'lc_shadows' and print out some info about every MAC_Chunk in 'lc_shadows' that matched the loss record. Nick |
|
From: Bill M. <wm...@ci...> - 2005-08-16 18:55:11
|
I'm sorry, but you're not understanding. I'm not looking for the ??? value. My program is already compiled with -g. The stack trace is correct; what I'm after is the address of the memory that was lost. That is not displayed. ie: in the below, I want to know the address of the block that was lost, not any information about the stack. Ignore the ??? - I should have not included it. Buding Chen wrote: > Bill, > > It seemed that the program was not compiled with degug info. > > Please recompile your program with flag -g. > > Thanks > Budingc > >>2048 bytes in 1 blocks are definately lost in loss record 6 of 6 > >> at 0x1B90088D: malloc (vg_replace_malloc.c:149) > >> by 0x1b9C4e6d: ???? > >> by ... > >> > >>Is there a way to tell what address the block is at ? In my program, > >>the address used will malloc many, many times, with the memory following > >>different paths - by knowing the address, I can figure out where it > >>is going using printfs. |
|
From: Nicholas N. <nj...@cs...> - 2005-08-16 18:47:38
|
On Tue, 16 Aug 2005, Rob Holland wrote: > I've uploaded a valgrind tool which I created out of bits of various > existing tools. > > The code can be found here: > > http://dev.gentoo.org/~tigger/fc_main.c > > It's basically a 300 line no-op at the moment as it doesn't print > anything. It's intended to keep track of what's on the heap. > > However, needs_malloc_replacement isn't having the effect which I > expected. Namely, my replacements aren't being run. > > I can add a VG_(exit)(1); into the malloc routine and nothing changes. > > I'm a bit lost as to why it's not being used. > > Anyone have any idea? I just tried running your code after inserting a VG_(printf)() statement into alloc_and_new_mem() and it was executed as expected. Is your program definitely calling malloc()? Try using --trace-malloc=yes to see if it is. Nb: You based the code off Helgrind, it might be worth instead basing it off Massif from the current SVN trunk; a few changes have gone in over the last few days that make this stuff a bit neater -- the VgHashTable type has changed a bit so you don't have to use as many casts, and you can use simple lookup() and remove() functions rather than the strange VG_(HT_get_node)() function. Your current code will still work, though, if you don't feel like changing it. Do you have a clear idea how you'll check format strings? I'd be interested to hear what you have planned. Hope this helps! Ask again if you have more problems. Nick |
|
From: Buding C. <Bu...@hz...> - 2005-08-16 18:38:51
|
QmlsbCwgDQogDQpJdCBzZWVtZWQgdGhhdCB0aGUgcHJvZ3JhbSB3YXMgbm90IGNvbXBpbGVkIHdp dGggZGVndWcgaW5mby4NCiANClBsZWFzZSByZWNvbXBpbGUgeW91ciBwcm9ncmFtIHdpdGggZmxh ZyAtZy4NCiANClRoYW5rcw0KQnVkaW5nYw0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0g DQoJRnJvbTogdmFsZ3JpbmQtdXNlcnMtYWRtaW5AbGlzdHMuc291cmNlZm9yZ2UubmV0IG9uIGJl aGFsZiBvZiBCaWxsIE1heSANCglTZW50OiBXZWQgMjAwNS04LTE3IDE6NTYgDQoJVG86IEJvYiBE dXNlayANCglDYzogdmFsZ3JpbmQtdXNlcnNAbGlzdHMuc291cmNlZm9yZ2UubmV0IA0KCVN1Ympl Y3Q6IFJlOiBbVmFsZ3JpbmQtdXNlcnNdIERpc3BsYXlpbmcgbWVtb3J5IGFkZHJlc3MgaW4gbGVh ayBjaGVjaw0KCQ0KCQ0KDQoJQm9iLA0KCQ0KCVRoYXQgd291bGQgYmUgZ3JlYXQgZm9yIDEgb3Ig MiBtYWxsb2NzLiAgSSdtIHRhbGtpbmcgYWJvdXQgdGhvdXNhbmRzDQoJb2NjdXJyaW5nIGV2ZXJ5 IHNlY29uZC4NCgkNCglCaWxsDQoJDQoJQm9iIER1c2VrIHdyb3RlOg0KCT4gU291bmRzIGxpa2Ug YSBqb2IgZm9yIGdkYi4gIFlvdSBjYW4gc2V0IGEgYnJlYWtwb2ludCBwcmlvciB0byB0aGUNCgk+ IG1hbGxvYywgYW5kIHRoZW4gcHJpbnQgdGhlIGFkZHJlc3Mgb2YgdGhlIHBvaW50ZXIuDQoJPg0K CT4gT24gVHVlLCAyMDA1LTA4LTE2IGF0IDEwOjMwIC0wNzAwLCBCaWxsIE1heSB3cm90ZToNCgk+ DQoJPj5IaSwNCgk+Pg0KCT4+SSdtIHVzaW5nIDMuMC4wIGFuZCB3b3VsZCBsaWtlIHRvIGtub3cg aG93IEkgY2FuIGdldCB0aGUNCgk+PmFkZHJlc3Mgb2YgdGhlIG1lbW9yeSB0aGF0IHRoZSBsZWFr IGNoZWNrIGRpc3BsYXlzIGF0IHRoZQ0KCT4+ZW5kIG9mIGV4ZWN1dGlvbi4NCgk+Pg0KCT4+SSdt IHVzaW5nOg0KCT4+dmFsZ3JpbmQgLS10b29sPW1lbWNoZWNrIC0tbGVhay1jaGVjaz1mdWxsIC0t bGVhay1yZXNvbHV0aW9uPWhpZ2gNCgk+PiAgIC0tdHJhY2UtY2hpbGRyZW49eWVzIC0tc2hvdy1y ZWFjaGFibGU9eWVzIDxjb21tYW5kIGxpbmU+DQoJPj4NCgk+Pkl0IHdvcmtzIGJyaWxsYW50bHks IGFuZCBkaXNwbGF5IGxpbmVzIGxpa2U6DQoJPj4NCgk+PjIwNDggYnl0ZXMgaW4gMSBibG9ja3Mg YXJlIGRlZmluYXRlbHkgbG9zdCBpbiBsb3NzIHJlY29yZCA2IG9mIDYNCgk+PiAgIGF0IDB4MUI5 MDA4OEQ6IG1hbGxvYyAodmdfcmVwbGFjZV9tYWxsb2MuYzoxNDkpDQoJPj4gICBieSAweDFiOUM0 ZTZkOiA/Pz8/DQoJPj4gICBieSAuLi4NCgk+Pg0KCT4+SXMgdGhlcmUgYSB3YXkgdG8gdGVsbCB3 aGF0IGFkZHJlc3MgdGhlIGJsb2NrIGlzIGF0ID8gIEluIG15IHByb2dyYW0sDQoJPj50aGUgYWRk cmVzcyB1c2VkIHdpbGwgbWFsbG9jIG1hbnksIG1hbnkgdGltZXMsIHdpdGggdGhlIG1lbW9yeSBm b2xsb3dpbmcNCgk+PmRpZmZlcmVudCBwYXRocyAtIGJ5IGtub3dpbmcgdGhlIGFkZHJlc3MsIEkg Y2FuIGZpZ3VyZSBvdXQgd2hlcmUgaXQNCgk+PmlzIGdvaW5nIHVzaW5nIHByaW50ZnMuDQoJPj4N Cgk+PkFueSBvdGhlciBpZGVhcyA/DQoJPj4NCgk+PkkgYWxzbyBub3RpY2VkIHRoYXQgaXQgd2ls bCBkaXNwbGF5IGFuIGVycm9yIG1lc3NhZ2UgbGlrZToNCgk+PjAgYnl0ZXMgaW4gMSBibG9jayBh ZnRlciBhIG1hbGxvYyBvZiAwLiAgSSd2ZSByZW1vdmVkIHRoZSBtYWxsb2MNCgk+Pm9mIDAsIGJ1 dCB3b25kZXIgaWYgdGhpcyBpcyBhIHZhbGlkIG1lc3NhZ2UuDQoJPj4NCgk+PlRoYW5rcywNCgk+ PkJpbGwgTWF5DQoJPj4NCgk+Pg0KCT4+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KCT4+U0YuTmV0IGVtYWlsIGlzIFNwb25zb3JlZCBieSB0 aGUgQmV0dGVyIFNvZnR3YXJlIENvbmZlcmVuY2UgJiBFWFBPDQoJPj5TZXB0ZW1iZXIgMTktMjIs IDIwMDUgKiBTYW4gRnJhbmNpc2NvLCBDQSAqIERldmVsb3BtZW50IExpZmVjeWNsZSBQcmFjdGlj ZXMNCgk+PkFnaWxlICYgUGxhbi1Ecml2ZW4gRGV2ZWxvcG1lbnQgKiBNYW5hZ2luZyBQcm9qZWN0 cyAmIFRlYW1zICogVGVzdGluZyAmIFFBDQoJPj5TZWN1cml0eSAqIFByb2Nlc3MgSW1wcm92ZW1l bnQgJiBNZWFzdXJlbWVudCAqIGh0dHA6Ly93d3cuc3FlLmNvbS9ic2NlNXNmDQoJPj5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4+VmFsZ3JpbmQtdXNl cnMgbWFpbGluZyBsaXN0DQoJPj5WYWxncmluZC11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQN Cgk+Pmh0dHBzOi8vbGlzdHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL3ZhbGdyaW5k LXVzZXJzDQoJPg0KCT4NCgkNCgkNCgktLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoJU0YuTmV0IGVtYWlsIGlzIFNwb25zb3JlZCBieSB0aGUg QmV0dGVyIFNvZnR3YXJlIENvbmZlcmVuY2UgJiBFWFBPDQoJU2VwdGVtYmVyIDE5LTIyLCAyMDA1 ICogU2FuIEZyYW5jaXNjbywgQ0EgKiBEZXZlbG9wbWVudCBMaWZlY3ljbGUgUHJhY3RpY2VzDQoJ QWdpbGUgJiBQbGFuLURyaXZlbiBEZXZlbG9wbWVudCAqIE1hbmFnaW5nIFByb2plY3RzICYgVGVh bXMgKiBUZXN0aW5nICYgUUENCglTZWN1cml0eSAqIFByb2Nlc3MgSW1wcm92ZW1lbnQgJiBNZWFz dXJlbWVudCAqIGh0dHA6Ly93d3cuc3FlLmNvbS9ic2NlNXNmDQoJX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglWYWxncmluZC11c2VycyBtYWlsaW5nIGxp c3QNCglWYWxncmluZC11c2Vyc0BsaXN0cy5zb3VyY2Vmb3JnZS5uZXQNCglodHRwczovL2xpc3Rz LnNvdXJjZWZvcmdlLm5ldC9saXN0cy9saXN0aW5mby92YWxncmluZC11c2Vycw0KCQ0KDQo= |
|
From: Bob D. <bd...@sr...> - 2005-08-16 18:21:39
|
Yeah. I'm green. Sorry for the noise. You may find some good stuff in the Variants and Patches portion of the Web site. On Tue, 2005-08-16 at 10:56 -0700, Bill May wrote: > Bob, > > That would be great for 1 or 2 mallocs. I'm talking about thousands > occurring every second. > > Bill > > Bob Dusek wrote: > > Sounds like a job for gdb. You can set a breakpoint prior to the > > malloc, and then print the address of the pointer. > > > > On Tue, 2005-08-16 at 10:30 -0700, Bill May wrote: > > > >>Hi, > >> > >>I'm using 3.0.0 and would like to know how I can get the > >>address of the memory that the leak check displays at the > >>end of execution. > >> > >>I'm using: > >>valgrind --tool=memcheck --leak-check=full --leak-resolution=high > >> --trace-children=yes --show-reachable=yes <command line> > >> > >>It works brillantly, and display lines like: > >> > >>2048 bytes in 1 blocks are definately lost in loss record 6 of 6 > >> at 0x1B90088D: malloc (vg_replace_malloc.c:149) > >> by 0x1b9C4e6d: ???? > >> by ... > >> > >>Is there a way to tell what address the block is at ? In my program, > >>the address used will malloc many, many times, with the memory following > >>different paths - by knowing the address, I can figure out where it > >>is going using printfs. > >> > >>Any other ideas ? > >> > >>I also noticed that it will display an error message like: > >>0 bytes in 1 block after a malloc of 0. I've removed the malloc > >>of 0, but wonder if this is a valid message. > >> > >>Thanks, > >>Bill May > >> > >> > >>------------------------------------------------------- > >>SF.Net email is Sponsored by the Better Software Conference & EXPO > >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > >>_______________________________________________ > >>Valgrind-users mailing list > >>Val...@li... > >>https://lists.sourceforge.net/lists/listinfo/valgrind-users > > > > |
|
From: Tom H. <to...@co...> - 2005-08-16 18:20:22
|
In message <430...@ci...>
Bill May <wm...@ci...> wrote:
> I also noticed that it will display an error message like:
> 0 bytes in 1 block after a malloc of 0. I've removed the malloc
> of 0, but wonder if this is a valid message.
That is entirely valid assuming that you didn't free it.
The C standard allows two possible behaviours for a zero byte
malloc - either it can return null (which can be safely freed as
freeing null is guaranteed to work) or it can return a unique
address of a block with no memory associated.
Hence zero size mallocs need to be freed or you may be leaking
resources on some implementations.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bill M. <wm...@ci...> - 2005-08-16 17:56:35
|
Bob, That would be great for 1 or 2 mallocs. I'm talking about thousands occurring every second. Bill Bob Dusek wrote: > Sounds like a job for gdb. You can set a breakpoint prior to the > malloc, and then print the address of the pointer. > > On Tue, 2005-08-16 at 10:30 -0700, Bill May wrote: > >>Hi, >> >>I'm using 3.0.0 and would like to know how I can get the >>address of the memory that the leak check displays at the >>end of execution. >> >>I'm using: >>valgrind --tool=memcheck --leak-check=full --leak-resolution=high >> --trace-children=yes --show-reachable=yes <command line> >> >>It works brillantly, and display lines like: >> >>2048 bytes in 1 blocks are definately lost in loss record 6 of 6 >> at 0x1B90088D: malloc (vg_replace_malloc.c:149) >> by 0x1b9C4e6d: ???? >> by ... >> >>Is there a way to tell what address the block is at ? In my program, >>the address used will malloc many, many times, with the memory following >>different paths - by knowing the address, I can figure out where it >>is going using printfs. >> >>Any other ideas ? >> >>I also noticed that it will display an error message like: >>0 bytes in 1 block after a malloc of 0. I've removed the malloc >>of 0, but wonder if this is a valid message. >> >>Thanks, >>Bill May >> >> >>------------------------------------------------------- >>SF.Net email is Sponsored by the Better Software Conference & EXPO >>September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices >>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA >>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf >>_______________________________________________ >>Valgrind-users mailing list >>Val...@li... >>https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |