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
(11) |
2
|
|
3
(5) |
4
(8) |
5
(33) |
6
(11) |
7
(1) |
8
(3) |
9
(4) |
|
10
(3) |
11
(12) |
12
(17) |
13
(10) |
14
(13) |
15
(7) |
16
|
|
17
(2) |
18
(22) |
19
(9) |
20
(7) |
21
(1) |
22
(4) |
23
(1) |
|
24
|
25
(1) |
26
(3) |
27
(8) |
28
(3) |
29
(16) |
30
(4) |
|
31
|
|
|
|
|
|
|
|
From: Paul A. C. <pa...@us...> - 2003-08-12 22:57:40
|
Does Valgrind support x86-64 executables? I assume x86-32 executables on an x86-64 chip would be supported as normal. (I couldn't find anything specific in the documentation, but I did check first! ;-) Also, has anyone even thought about a port (rewrite?) to the Power/PowerPC architecture? Regards, Paul Clarke |
|
From: Philippe E. <ph...@wa...> - 2003-08-12 20:22:57
|
Nicholas Nethercote wrote: > On Sun, 10 Aug 2003, Philippe Elie wrote: > > >>Very nice works, some minor problem with peculiar application: >>memory use is dominated by obstack in libfd (and stl memory pool >>too) but it already allowed me to learn this libbfd behavior. >>Adding a paragraph about pool allocator, garbage collector and >>obstack which can show different behavior than the naive program >>expect ? > > > Can you give me some more details about this different behaviour? Can you > give me example programs that demonstrate it? nervermind, I was confused about program behavior, the memory profile is ok. regards, Phil |
|
From: Dan K. <da...@ke...> - 2003-08-12 17:57:58
|
Nicholas Nethercote wrote: > I've had feedback saying that Massif isn't as novel/interesting as I > claimed. Parasoft has InUse which I think comes with Insure++ which does > what looks like similar profiling. There's another commercial program > called GlowCode that might be similar. (It can be hard to tell with > commercial products, the descriptions are often so vague.) Mpatrol has an > mprof-like aspect that gives allocation stats; Mozilla has something > called BloatBlame that looks similar. Does anyone else know of other such > tools? It'd be great if you could link to all of 'em from your doc, and explain the differences. Also, your doc doesn't explain the benefit of doing this within valgrind as opposed to just doing it in a native environment; it should mention that. Thanks! - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 17:51:34
|
On Tue, 12 Aug 2003, John Levon wrote: > Is there some reason you dropped this patch ? Sorry, I forgot to actually copy the new version to the webpage [sigh]. Should be fixed now. N |
|
From: Greg H.
|
I sent a bug report about this to the author a few days ago. It's
definitely not right. Here's my patch, based on what strncat() does.
--- mac_replace_strmem.c 2003/08/07 02:52:24 1.1
+++ mac_replace_strmem.c 2003/08/07 02:56:35
@@ -186,13 +186,15 @@
char* strncpy ( char* dst, const char* src, int n )
{
- Char* dst_orig = dst;
+ const Char* src_orig = src;
+ Char* dst_orig = dst;
Int m = 0;
- if (is_overlap(dst, src, n, n))
- complain3("strncpy", dst, src, n);
-
while (m < n && *src) { m++; *dst++ = *src++; }
+ /* Check for overlap after copying; all n bytes of dst are elevant,
+ but only m+1 bytes of src if terminator was found */
+ if (is_overlap(dst_orig, src_orig, n, (m < n) ? m+1 : n))
+ complain3("strncpy", dst, src, n);
while (m++ < n) *dst++ = 0; /* must pad remainder with nulls */
return dst_orig;
|
|
From: Haobing W. <hw...@ep...> - 2003-08-12 17:35:41
|
On Tue, 2003-08-12 at 12:06, Matthew Emmerton wrote: > ----- Original Message ----- > From: "Haobing Wang" <hw...@ep...> > To: <val...@li...> > Sent: Tuesday, August 12, 2003 11:34 AM > Subject: [Valgrind-users] What is the problem? > > > > Hello, > > > > When I used "valgrind --leak-check=yes" to check my C program, it gave > > such information: > > > > ==2363== Invalid read of size 4 > > ==2363== at 0x8049949: main (gating_grinder2J.c:410) > > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > > ==2363== by 0x80487C0: ??? (start.S:81) > > ==2363== Address 0x41209920 is 0 bytes after a block of size 528 > > alloc'd > > ==2363== at 0x4002942A: malloc (vg_replace_malloc.c:153) > > ==2363== by 0x8049025: main (gating_grinder2J.c:247) > > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > > ==2363== by 0x80487C0: ??? (start.S:81) > > Done. > > > > ==2363== > > ==2363== ERROR SUMMARY: 4096 errors from 1 contexts (suppressed: 0 from > > 0) > > ==2363== malloc/free: in use at exit: 19081 bytes in 8 blocks. > > ==2363== malloc/free: 91010 allocs, 91002 frees, 45431125 bytes > > allocated. > > ==2363== For counts of detected errors, rerun with: -v > > ==2363== searching for pointers to 8 not-freed blocks. > > ==2363== checked 3802352 bytes. > > ==2363== > > ==2363== LEAK SUMMARY: > > ==2363== definitely lost: 0 bytes in 0 blocks. > > ==2363== possibly lost: 0 bytes in 0 blocks. > > ==2363== still reachable: 19081 bytes in 8 blocks. > > ==2363== suppressed: 0 bytes in 0 blocks. > > ==2363== Reachable blocks (those to which a pointer was found) are not > > shown. > > ==2363== To see them, rerun with: --show-reachable=yes > > ==2363== > > > > > > Does anybody know what is the problem with the error? I couldn't find > > any error in my program and it seemed that the program could run > > normally. The line 247 in main is: > > vec_rows[k] = (float *)malloc(Timepts*sizeof(float)) > > > > Any help is much appreciated! > > Does your program call free(vec_rows[k]) at some point in time? Yes, I called free(vec_rows[k]) at the end of my program, but I wrote past the end of that memory before freeing it. Thank you anyway! > > -- > Matt Emmerton > |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 17:30:57
|
On Mon, 11 Aug 2003, Steve G wrote: > After a few rounds of comments, I think you can accelerate > the maturity of Massif by distributing it with valgrind so > that people have easier access to it. You basically have to > be a subscriber to this mail list just to know about these > extra skins unless Julian has linked your home page to the > valgrind web site. > > I understand the caution with rolling it out, but to get > thorough testing...people have to have an easy way to find > it. Absolutely, but we haven't reached that stage yet... it's only been released for 3 days :) I've had feedback saying that Massif isn't as novel/interesting as I claimed. Parasoft has InUse which I think comes with Insure++ which does what looks like similar profiling. There's another commercial program called GlowCode that might be similar. (It can be hard to tell with commercial products, the descriptions are often so vague.) Mpatrol has an mprof-like aspect that gives allocation stats; Mozilla has something called BloatBlame that looks similar. Does anyone else know of other such tools? Thanks. N |
|
From: John L. <le...@mo...> - 2003-08-12 17:24:43
|
On Sun, Aug 10, 2003 at 01:29:57PM +0100, John Levon wrote: > > I've written a new skin for Valgrind. It's called Massif, and does > > 2.6.0-test1 works fine. Allow it. Is there some reason you dropped this patch ? regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over. |
|
From: Haobing W. <hw...@ep...> - 2003-08-12 17:08:02
|
On Tue, 2003-08-12 at 12:08, Nicholas Nethercote wrote: > > ==2363== Invalid read of size 4 > > ==2363== at 0x8049949: main (gating_grinder2J.c:410) > > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > > ==2363== by 0x80487C0: ??? (start.S:81) > > ==2363== Address 0x41209920 is 0 bytes after a block of size 528 > > alloc'd > > ==2363== at 0x4002942A: malloc (vg_replace_malloc.c:153) > > ==2363== by 0x8049025: main (gating_grinder2J.c:247) > > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > > ==2363== by 0x80487C0: ??? (start.S:81) > > Done. > > > > Does anybody know what is the problem with the error? I couldn't find > > any error in my program and it seemed that the program could run > > normally. The line 247 in main is: > > vec_rows[k] = (float *)malloc(Timepts*sizeof(float)) > > You allocated some memory on line 247. You wrote past the end of that > memory on line 410. Yes, you are right. I did write past the end of that memory on line 410. That's really a hidden bug! Thank you for your help! Haobing > > N > > |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 16:46:22
|
On Sun, 10 Aug 2003, Philippe Elie wrote: > Very nice works, some minor problem with peculiar application: > memory use is dominated by obstack in libfd (and stl memory pool > too) but it already allowed me to learn this libbfd behavior. > Adding a paragraph about pool allocator, garbage collector and > obstack which can show different behavior than the naive program > expect ? Can you give me some more details about this different behaviour? Can you give me example programs that demonstrate it? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 16:42:59
|
Hi all, Thanks very much for the feedback so far about Massif. I've put a new version (v0.0.2) up at www.cl.cam.ac.uk/~njn25/valgrind.html. I've also put up there source and binary versions of hp2ps, the graph-producing program, so you don't have to download Glasgow Haskell any more. (Nb: These versions I have put up don't have the minor bug involving the marks on the x-axis.) Changes: - Got rid of the "xNN" names, now using code addresses and function names. This makes the graph more user-friendly. - Fixed this bug (hopefully): Massif: ms_main.c:444 (get_XCon): Assertion `0 == xpt->children[i]->n_children' failed. - Now noticing brk() (included in the "data" count) - Now noticing signal handler stacks (in the "stack(s)" count) - Corresponding documentation changes. More feedback welcome. N |
|
From: Randall H. <lis...@ch...> - 2003-08-12 16:38:03
|
If you do this: char dest[64]; char src [16]; strcpy( dest, "more" ); strcpy( src, " stuff" ); strncat( dest, src, sizeof(dest) - strlen(dest) - 1 ); Valgrind says: Source and destination overlap in strncat(0x44b45b98, 0x44b45b88, 59) It's clear what's going on. Memory is layed out like this: [0..15 src][0..63 dst] and valgrind, not knowing whether src is null terminated, is concerned that strncat might read past the end of src into dst. This isn't an error in this case. But I'm on the wall as to whether valgrind should flag it or not. Any thoughts? I guess it boils down to whether valgrind would detect the overwrite through other means if it occured, or could check for null termination before reporting an error. P.S. Yes, this was expanded from a "safe strcat" macro. Just tracing it down. Thanks, Randall |
|
From: Nicholas N. <nj...@ca...> - 2003-08-12 16:17:23
|
> ==2363== Invalid read of size 4 > ==2363== at 0x8049949: main (gating_grinder2J.c:410) > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > ==2363== by 0x80487C0: ??? (start.S:81) > ==2363== Address 0x41209920 is 0 bytes after a block of size 528 > alloc'd > ==2363== at 0x4002942A: malloc (vg_replace_malloc.c:153) > ==2363== by 0x8049025: main (gating_grinder2J.c:247) > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > ==2363== by 0x80487C0: ??? (start.S:81) > Done. > > Does anybody know what is the problem with the error? I couldn't find > any error in my program and it seemed that the program could run > normally. The line 247 in main is: > vec_rows[k] = (float *)malloc(Timepts*sizeof(float)) You allocated some memory on line 247. You wrote past the end of that memory on line 410. N |
|
From: Matthew E. <ma...@co...> - 2003-08-12 16:13:47
|
----- Original Message ----- From: "Haobing Wang" <hw...@ep...> To: <val...@li...> Sent: Tuesday, August 12, 2003 11:34 AM Subject: [Valgrind-users] What is the problem? > Hello, > > When I used "valgrind --leak-check=yes" to check my C program, it gave > such information: > > ==2363== Invalid read of size 4 > ==2363== at 0x8049949: main (gating_grinder2J.c:410) > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > ==2363== by 0x80487C0: ??? (start.S:81) > ==2363== Address 0x41209920 is 0 bytes after a block of size 528 > alloc'd > ==2363== at 0x4002942A: malloc (vg_replace_malloc.c:153) > ==2363== by 0x8049025: main (gating_grinder2J.c:247) > ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) > ==2363== by 0x80487C0: ??? (start.S:81) > Done. > > ==2363== > ==2363== ERROR SUMMARY: 4096 errors from 1 contexts (suppressed: 0 from > 0) > ==2363== malloc/free: in use at exit: 19081 bytes in 8 blocks. > ==2363== malloc/free: 91010 allocs, 91002 frees, 45431125 bytes > allocated. > ==2363== For counts of detected errors, rerun with: -v > ==2363== searching for pointers to 8 not-freed blocks. > ==2363== checked 3802352 bytes. > ==2363== > ==2363== LEAK SUMMARY: > ==2363== definitely lost: 0 bytes in 0 blocks. > ==2363== possibly lost: 0 bytes in 0 blocks. > ==2363== still reachable: 19081 bytes in 8 blocks. > ==2363== suppressed: 0 bytes in 0 blocks. > ==2363== Reachable blocks (those to which a pointer was found) are not > shown. > ==2363== To see them, rerun with: --show-reachable=yes > ==2363== > > > Does anybody know what is the problem with the error? I couldn't find > any error in my program and it seemed that the program could run > normally. The line 247 in main is: > vec_rows[k] = (float *)malloc(Timepts*sizeof(float)) > > Any help is much appreciated! Does your program call free(vec_rows[k]) at some point in time? -- Matt Emmerton |
|
From: Haobing W. <hw...@ep...> - 2003-08-12 15:50:19
|
Hello, When I used "valgrind --leak-check=yes" to check my C program, it gave such information: ==2363== Invalid read of size 4 ==2363== at 0x8049949: main (gating_grinder2J.c:410) ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) ==2363== by 0x80487C0: ??? (start.S:81) ==2363== Address 0x41209920 is 0 bytes after a block of size 528 alloc'd ==2363== at 0x4002942A: malloc (vg_replace_malloc.c:153) ==2363== by 0x8049025: main (gating_grinder2J.c:247) ==2363== by 0x40279A46: __libc_start_main (in /lib/libc-2.3.2.so) ==2363== by 0x80487C0: ??? (start.S:81) Done. ==2363== ==2363== ERROR SUMMARY: 4096 errors from 1 contexts (suppressed: 0 from 0) ==2363== malloc/free: in use at exit: 19081 bytes in 8 blocks. ==2363== malloc/free: 91010 allocs, 91002 frees, 45431125 bytes allocated. ==2363== For counts of detected errors, rerun with: -v ==2363== searching for pointers to 8 not-freed blocks. ==2363== checked 3802352 bytes. ==2363== ==2363== LEAK SUMMARY: ==2363== definitely lost: 0 bytes in 0 blocks. ==2363== possibly lost: 0 bytes in 0 blocks. ==2363== still reachable: 19081 bytes in 8 blocks. ==2363== suppressed: 0 bytes in 0 blocks. ==2363== Reachable blocks (those to which a pointer was found) are not shown. ==2363== To see them, rerun with: --show-reachable=yes ==2363== Does anybody know what is the problem with the error? I couldn't find any error in my program and it seemed that the program could run normally. The line 247 in main is: vec_rows[k] = (float *)malloc(Timepts*sizeof(float)) Any help is much appreciated! Haobing |
|
From: Josef W. <Jos...@gm...> - 2003-08-12 09:15:13
|
Hi, On Tuesday 12 August 2003 02:32, Steve G wrote: > After a few rounds of comments, I think you can accelerate > the maturity of Massif by distributing it with valgrind so > that people have easier access to it. You basically have to Nick, I would appreciate it if you could decide to make separate packages of your skins. This way, I would not be the only one, and issues regarding separate distribution (e.g. skin interface problems etc.) are more easily detected for sure. The installed header files work fine so far. Greetings, Josef |
|
From: Steve G <lin...@ya...> - 2003-08-12 00:34:31
|
>>I tried to put together massif and crocus with this >>version and I got relocations errors. <snip> >However, it wouldn't be hard to work those minor changes >into the next release of Valgrind and then Massif could >be packaged up with it. Although I don't think Massif >deserves the description "stable" yet :) I was starting to wonder what the status of crocus was, too. I think that one is stable enough to be rolled out as is. After a few rounds of comments, I think you can accelerate the maturity of Massif by distributing it with valgrind so that people have easier access to it. You basically have to be a subscriber to this mail list just to know about these extra skins unless Julian has linked your home page to the valgrind web site. I understand the caution with rolling it out, but to get thorough testing...people have to have an easy way to find it. Best Regards, Steve Grubb __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com |