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
(6) |
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: Tom H. <to...@co...> - 2005-08-10 09:00:43
|
In message <21B78378E540EC4795820EFF451D857F199FF2@MCHP7I5A.ww002.siemens.net>
Joachim Bauernberger <joa...@si...> wrote:
> i have however a small problem with the above limitation. has this
> changed within 3.0.0?
>
> the manpage says:
> vvvvvvvvvvv
> 1 May 2002: this is a historical relic which could be easily fixed if
> it gets in your way.
> Mail me and complain if this is a problem for you.
> ^^^^^^^^^^^^
I don't believe it has changed, and I'm not convinced it is easily
fixed - that comment is very old and the whole db-attach scheme has
changed since then I think.
The main problem I suspect is that if you've got multiple programs
running in the terminal there is no way to control which one will get
the input when you try and answer the question about whether to attach
the debugger.
So if you do a straight execve it will probably be fine, but if you
fork and exec so that you have multiple processes it might not be
reliable. Not that is that reliable to start with...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Bauernberger, J. \(EXT\) <joa...@si...> - 2005-08-10 08:53:16
|
Hi, thanks for this great tool.=20 i have however a small problem with the above limitation. has this changed within 3.0.0? the manpage says: vvvvvvvvvvv 1 May 2002: this is a historical relic which could be easily fixed if it gets in your way.=20 Mail me and complain if this is a problem for you. ^^^^^^^^^^^^ thanks & best regards, joachim |
|
From: <ne...@we...> - 2005-08-10 07:49:34
|
hello valgrind-users, I recorded the amount of Stack-Memory of my simple HTTP-Server. Unfortunal= ly I can't send the grafic file as Attachement, so I hope, that everybody = understand my ascii-pic. The 2 peaks are caused by receiving 2 Requests of= a client. Im confused by the fackt, thats till the first Response is arri= ved, the band is grow up so straight. Is that a kind of interpolation=3F Is = the value between the these two peaks a relevant value for the amount of s= tack-memory-usage=3F I know the time range of the record is quite short. But= I also tryed to record for a longer time, but is with the same result of = a constant increasing graph till the first peak and a constant rising grap= h after the last peak. In my Opinion it cant be right. Whats the reason fo= r=3F=20 thanks in advanced andr=E9 100 kb | |=5F=5F| | / \ | / \ | / \ Stack only! |/ \ |=5F=5F=5F=5F=5F=5F=5F\=5F=5F=5F 10 sec. =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/=3Fmc=3D021201 |
|
From: Igmar P. <mai...@jd...> - 2005-08-10 07:15:21
|
> Also ... I remember getting into a pickle with gcc-2.96 and the > order of qualifiers for __attribute__((regparm)) on fn declarations. > That was another motivation for upgrading the compiler rather > than spending time how to write gcc-2.96 compatible regparm > incantations. Not to mention that gcc 2.96 is know to misbehave in a number of cases. Numerous projects refuse to compile if 2.96 is used. Igmar |
|
From: Tom H. <to...@co...> - 2005-08-10 06:25:43
|
In message <loo...@po...>
rak <ra...@ho...> wrote:
> ==20240== Warning: set address range perms: large range 135969264, a 0, v 1
> .
> .
> .
> .
> ==20240== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n
> ==20240== Warning: set address range perms: large range 1064979232, a 0, v 1
> --20240-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting
> --20240-- si_code=1; Faulting address: 0x0; sp: 0x7013BE80
>
> valgrind: the 'impossible' happened:
> Killed by fatal signal
> ==20240== at 0x2A959C0B9F: ???
Please raise a bug for this in the bug tracker.
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-10 06:25:07
|
In message <20050810004040.GC3557@white>
Bob Rossi <bo...@br...> wrote:
> What does the below mean?
> 12882 (398 direct, 12484 indirect) bytes in 38 blocks are definitely
> lost in loss record 33
>
> I do understand what a memory leak is, however, what is a direct vs
> indirect memory leak?
A direct leak is a block which has no pointers to it. An indirect
leak is a block which is only referenced by other leaked blocks.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-10 06:23:55
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> The circularity problem is, however, much worse for the X
> client libraries. Valgrind's default .supp files contain literally
> dozens of suppressions for errors reported in the X libraries.
> I'm not saying Xlib et al are particularly buggy. But it would be
> nice if we didn't have to suppress this much. I'd be happy to
> offer guidance, assistance, etc, to any X.org developers who
> wanted to look Valgrinding X.org; then at least we would know
> whether these are real bugs or false errors.
The main problem with the X libraries is that they send structure
across the network between client and server without initialising
any padding bytes isn't it?
Certainly uninitialised bytes in network writes is the common
complaint from the X libraries.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-10 06:18:15
|
In message <200...@we...>
"prashantha a.s" <pra...@ya...> wrote:
> I am NOT able to use helgrind tool. Which is giving
> me this error.
[ snipped ]
> This means my installation is not proper or this is
> not supported in 2.4.0 version of Valgrind
As has been explained several times this week helgrind is not
supported in the 2.4.0, 2.4.1 or 3.0.0 releases. More details
are available in the NEWS file that came with valgrind.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-10 06:16:31
|
In message <ddbea5$ckp$1...@se...>
Harry Mangalam <hj...@ta...> wrote:
> For some reason, the set of apps I'm currently dealing with (the netcdf
> operators - aka nco) require valgrind & friends to be tweaked more than
> other apps that I've used it on.
What do you mean by 'tweaked' exactly? Have you got patches that you
have to apply to valgrind to make it work with your code?
> V3 is no different, unfortunately: on a PIII coppermine laptop (IBM a22p),
> 512M, Debian unstable, app compiled with gcc 3.4.2. ANy ideas?
It's a bug. Please raise a bug in the bug tracker for it.
Thanks,
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: prashantha a.s <pra...@ya...> - 2005-08-10 04:07:06
|
Hi,
I am NOT able to use helgrind tool. Which is giving
me this error.
#######################################################
Can't open tool "helgrind":
/usr/local/lib/valgrind/vgskin_helgrind.so: cannot
open shared object file: No such file or directory
valgrind: couldn't load tool
Available tools:
memcheck
addrcheck
cachegrind
corecheck
massif
lackey
none
######################################################
This means my installation is not proper or this is
not supported in 2.4.0 version of Valgrind
Thankx & regards
Prashantha.AS
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
|
|
From: rak <ra...@ho...> - 2005-08-10 02:37:20
|
Valgrind crashes when tring to realloc memory . Is there a work around for this. xeon%uname -sa Linux xeon 2.4.21-15.EL #1 SMP Thu Apr 22 00:09:47 EDT 2004 x86_64 x86_64 x86_64 GNU/Linux xeon%valgrind --db-attach=yes ./pro ==20240== Memcheck, a memory error detector. ==20240== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==20240== Using LibVEX rev 1313, a library for dynamic binary translation. ==20240== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==20240== Using valgrind-3.0.0, a dynamic binary instrumentation framework. ==20240== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==20240== For more details, rerun with: -v ==20240== ==20240== Warning: set address range perms: large range 135969264, a 0, v 1 . . . . ==20240== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- n ==20240== Warning: set address range perms: large range 1064979232, a 0, v 1 --20240-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --20240-- si_code=1; Faulting address: 0x0; sp: 0x7013BE80 valgrind: the 'impossible' happened: Killed by fatal signal ==20240== at 0x2A959C0B9F: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==20240== at 0x11B1C563: realloc (vg_replace_malloc.c:306) Thanks, Rak |
|
From: Yeshurun, M. <mei...@in...> - 2005-08-10 01:50:59
|
> I am getting some error while running valgrind on > Montavista Linux. Please find the attachment for error Did you read the replies to your previous message? > PS: One more thing - I am not able to use some of > options like --xml=3Dyes & > --log-file-exactly=3D<fileName>. If i use these options > it is says bad options. You need Valgrind 3.0 to use these options. You're using 2.4. __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around=20 http://mail.yahoo.com=20 |
|
From: Julian S. <js...@ac...> - 2005-08-10 00:47:08
|
On Tuesday 09 August 2005 21:17, Maurice van der Pot wrote: > I have a couple of questions that are probably beginner's questions, > but I never got around to asking them. > > - What is the reason that valgrind has default suppression files for > glibc? > - Are those false positives? > - Are those real problems but are the glibc maintainers not doing > anything about them? > - Do these problems get reported to the glibc maintainers as they are > found? No, these are good questions, and they point at a problem. Maybe you know how to solve it. I was thinking about this the other day. ------ The original motivation for the suppression files was that Memcheck was more or less unusable without them, because it reported a lot of errors in glibc. Many of these are to do with the ultra-optimised strlen etc functions, and so are false positives, but we deal with them better these days. Some are probably real errors. But this leads to a circular problem. Valgrind suppresses glibc errors so you don't get swamped by them, but in doing so more or less means they never come to the attention of the glibc authors and presumably never get fixed. John Reiser has an audited (cleaned-up) version of glibc-2.3.5; the comments at http://bitwagon.com/glibc-audit/glibc-audit.html make interesting reading. I think it's a great shame that the glibc folks don't make glibc Valgrind-clean given the almost unmeasurably small performance overhead John says this would have (and I believe it); this seems to me a poor tradeoff. The circularity problem is, however, much worse for the X client libraries. Valgrind's default .supp files contain literally dozens of suppressions for errors reported in the X libraries. I'm not saying Xlib et al are particularly buggy. But it would be nice if we didn't have to suppress this much. I'd be happy to offer guidance, assistance, etc, to any X.org developers who wanted to look Valgrinding X.org; then at least we would know whether these are real bugs or false errors. ------ So .. why was I thinking about this recently? Because recently I have been trying to make Memcheck work well on (32-bit) PowerPC Linux (the 3.0.0 line has lots of ppc-linux infrastructure in place). But without much success -- I got flooded with uninitialised value errors which I cannot track down. So right now, I don't know if they are false reports caused by endianness bugs in Memcheck, or if they are real bugs in glibc on ppc32-linux. If I knew glibc was valgrind- clean this it would be a lot less confusing. J |
|
From: Bob R. <bo...@br...> - 2005-08-10 00:41:32
|
Hi all, I was looking through the manual and couldn't find the answer to my question. What does the below mean? 12882 (398 direct, 12484 indirect) bytes in 38 blocks are definitely lost in loss record 33 I do understand what a memory leak is, however, what is a direct vs indirect memory leak? If the answer is interesting, maybe it should be added to the manual. Thanks, Bob Rossi |