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
(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: Daniel V. <vei...@re...> - 2003-08-14 01:12:20
|
Hi, It doesn't seems to be an FAQ but I would think it's a common problem. What are the "best" processors to run Valgrind ? "best" in how do I compare "usual" valgrind speed w.r.t. CPU architecture and clock speed. I'm usually fine with a relatively slow processor for development but Valgrind is changing this. I don't plan to invest too much money, and I see the choice between Athlon who may have better cache, branch prediction and memory architecture, versus higher speed clock but relatively dumb Celeron. My guts feeling is that for valgrind execution speed is mostly linear with clock speed, though the branch prediction and cache may have a significant effect too. So basically is there something else I forgot, and is there existing Valgrind execution benchmarks for a given "test program" ? I'm mostly interested in performances of the simple run of valgrind, cachegrind kind of use is less common. Just wondering, I'm probably not the first one who had that question, Daniel -- Daniel Veillard | Red Hat Network https://rhn.redhat.com/ vei...@re... | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ |
|
From: Olly B. <ol...@su...> - 2003-08-13 16:51:33
|
> A12. One possible cause is that your program modifies its
> environment variables, possibly including zeroing them
> all. Valgrind relies on the LD_PRELOAD and LD_LIBRARY_PATH
> variables, so zeroing them will break things.
I'm not certain I understand the mechanisms involved completely, but
would it work for valgrind to wrapper getenv, setenv, and putenv and
keep track of what the app thinks LD_PRELOAD and LD_LIBRARY_PATH (and
indeed VG_ARGS) are set to, but when making syscalls, actually use the
values set with the paths valgrind needs prepended?
Or simpler, just wrapper setenv and putenv and force valgrind's paths
in and prevent VG_ARGS from being changed, but I worry slightly that an
app might assume it knows how long a variable is because it just set it
- something like this rather stupid contrived example:
int foo(const char * value) {
char * p = malloc(strlen(value) + 10);
if (!p) return -1;
setenv("LD_PRELOAD", value, 1);
bar();
strcpy(p, getenv("LD_PRELOAD));
strcat(p, ":/usr/lib");
setenv("LD_PRELOAD", p, 1);
baz();
free(p);
return 0;
}
Cheers,
Olly
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 16:07:51
|
On Wed, 13 Aug 2003, Vincent Penquerc'h wrote: > > Yes, that is a problem with such patches, unfortunately. > > Would it be accepted (or considered, at least) with configure > checks to only compile in this code (and include the files) if the > include files are actually found on the target system (eg, if the > files aren't there, then the new ioctls aren't supported, but they > are if the files are found) ? Um... maybe. (I'll let Julian have the final say on this one.) N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-13 15:48:03
|
> Yes, that is a problem with such patches, unfortunately. Would it be accepted (or considered, at least) with configure checks to only compile in this code (and include the files) if the include files are actually found on the target system (eg, if the files aren't there, then the new ioctls aren't supported, but they are if the files are found) ? -- Vincent Penquerc'h |
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 10:21:14
|
On Wed, 13 Aug 2003, Santeri Paavolainen wrote: > So VG_ARGS needs to be added also. Ah, yes. I've updated the FAQ in CVS. Thanks for the help. N |
|
From: Santeri P. <sa...@ss...> - 2003-08-13 09:46:46
|
Nicholas Nethercote wrote:
>Yes: LD_PRELOAD and LD_LIBRARY_PATH, and only with --trace-children=yes.
>
>
Apparently this is not completely true.. I set up the program to pass
LD_PRELOAD and LD_LIBRARY_PATH from the parent process, and this is
visible in debug output too (from the child):
debug[6918]:
LD_PRELOAD=/l/beta/lib/valgrind/vgskin_memcheck.so:/l/beta/lib/valgrind/valgrind.so:
debug[6918]: LD_LIBRARY_PATH=/l/beta/lib/valgrind:
But:
valgrind.so: Startup or configuration error:
Can't read options from env var VG_ARGS.
valgrind.so: Unable to start up properly. Giving up.
So VG_ARGS needs to be added also. I added that to the list of passed
env variables, and so:
debug[7076]: VG_ARGS=
--suppressions=/l/beta/lib/valgrind/default.supp --trace-children=yes
--num-callers=32 --logfile=/l/xxtest/xxtest.log
And now everything works fine.
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 09:36:35
|
On Wed, 13 Aug 2003, Vincent Penquerc'h wrote: > From the traffic on the list, it seems this patch suffers from > the same flaw as another one that stayed unapplied: addition of > include files which may or may not be present on the tgarget > system. Am I right in assuming this is the reason the patch was > not applied ? A quick answer would be nice, time permitting. Yes, that is a problem with such patches, unfortunately. N |
|
From: Vincent Penquerc'h <Vin...@ar...> - 2003-08-13 09:24:03
|
Hi, I posted message:
Message-ID: <B14C9D7F1977D111AD740060970ACBDA0189307D@warhol>
on the 30th of may 2003, and no answer was received. This patch
adds some ioctls and fixes some documentation (I'm unsure of the
actual extent of it, as I am not the patch author).
From the traffic on the list, it seems this patch suffers from
the same flaw as another one that stayed unapplied: addition of
include files which may or may not be present on the tgarget
system. Am I right in assuming this is the reason the patch was
not applied ? A quick answer would be nice, time permitting.
I can post the patches again if requested, if you can't find
the above message. Main text follows.
Thanks.
--
Vincent Penquerc'h
Hi,
This is from my girlfriend, who had been using Valgrind 1.0.4, and
ported some patches to 1.9.6.
--
Vincent Penquerc'h
Hi
I've been playing with valgrind (which is a very useful tool). I needed some
more ioctls, which I added (patch 'ioctls.diff' attached) and I've some
problems with signals.
IOCTLS:
I've added a tty, 2 sound, several frame buffer and VT ioctls.
These ioctls are very lightly tested : I've run programs which I know use
them
under valgrind, they worked and valgrind didn't complain.
I've also updated README_MISSING_SYSCALL_OR_IOCTL to use the new
SYSCAL_TRACK,
etc. instead of must_be_writable, etc.
SIGNALS:
From the manual (2.9 Handling of signals)
As specified by POSIX, a signal is blocked in its own handler.
From a comment at the beginning of coregrind/vg_signal.c
- A signal is not masked in its own handler. Neither are the
signals in the signal's blocking mask.
Which one is true ? (or which one is meant to be true ? ;)
There's a typical output of the program attached ('signals.c')
(run with valgrind -v --trace-signals=yes) :
... Skipping ...
[ 0] --28471-- signal 29 arrived ... queued
[ 1] --28471-- delivering signal 29 to thread 1
[ 2] --28471-- signal 29 arrived ... queued
[ 3] --28471-- signal 29 arrived ... already pending; discarded
[ 4] --28471-- signal 29 arrived ... already pending; discarded
[ 5] --28471-- signal 29 arrived ... already pending; discarded
[ 6] --28471-- signal 29 arrived ... already pending; discarded
[ 7] --28471-- signal 29 arrived ... already pending; discarded
[ 8] --28471-- signal 29 arrived ... already pending; discarded
[ 9] --28471-- signal 29 arrived ... already pending; discarded
[10] --28471-- signal 29 arrived ... already pending; discarded
[11] --28471-- signal 29 arrived ... already pending; discarded
[12] --28471-- signal 29 arrived ... already pending; discarded
[13] --28471-- signal 29 arrived ... already pending; discarded
[14] --28471-- signal 29 arrived ... already pending; discarded
[15] --28471-- signal 29 arrived ... already pending; discarded
[16] --28471-- signal 29 arrived ... already pending; discarded
[17] --28471-- signal 29 arrived ... already pending; discarded
[18] --28471-- signal 29 arrived ... already pending; discarded
[19] Entering: 1
[20] --28471-- delivering signal 29 to thread 1
[21] Entering: 2
[22] --28471-- signal 29 arrived ... queued
[23] --28471-- signal 29 arrived ... already pending; discarded
[24] --28471-- signal 29 arrived ... already pending; discarded
[25] Returning: 2
[26] --28471-- delivering signal 29 to thread 1
[27] Entering: 3
[28] Returning: 3
[29] --28471-- vg_pop_signal_frame (thread 1): valid magic
[30] --28471-- signal 29 arrived ... queued
[31] --28471-- vg_pop_signal_frame (thread 1): valid magic
[32] Returning: 1
[33] --28471-- delivering signal 29 to thread 1
[34] Entering: 2
[35] Returning: 2
[36] --28471-- vg_pop_signal_frame (thread 1): valid magic
[37] --28471-- vg_pop_signal_frame (thread 1): valid magic
... Skipping ...
As far as I understand, signals in lines #2, #22 and #30 should be
discarded.
I use Linux 2.4.13, gcc 2.95.3, libc 2.2.4, valgrind 1.9.6.
Note: signal 29 (SIGIO: I/O now possible) is non-POSIX, it comes from 4.2
BSD.
The example program was compiled with 'gcc -Wall signals.c'. You may want
to
change the MOUSE_DEVICE define at the beginning of the file if your mouse is
not in '/dev/mouse'. To test the program: run it and move the mouse, type
Ctrl-C to quit.
Thank you
--
Annie Testes
|
|
From: Nicholas N. <nj...@ca...> - 2003-08-13 08:48:50
|
On Wed, 13 Aug 2003, Santeri Paavolainen wrote:
> VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
>
> This is clearly caused by the fact that this program clears the
> environmental variables on startup (to known values).
>
> What are the environmental variables that should be preserved (not
> cleared) to allow valgrind to work for the program and the child
> processes (with --trace-children=yes)? (My guess: LD_PRELOAD and
> LD_LIBRARY_PATH.)
Yes: LD_PRELOAD and LD_LIBRARY_PATH, and only with --trace-children=yes.
I updated the FAQ, it now reads:
A12. One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Valgrind relies on the LD_PRELOAD and LD_LIBRARY_PATH
variables, so zeroing them will break things.
As of 1.9.6, Valgrind only uses these variables with
--trace-children=yes, which should reduce the potential for
problems.
N
|
|
From: Santeri P. <sa...@ss...> - 2003-08-13 07:46:07
|
When running valgrind on a program I get the following errors:
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
what = 0
ld_preload_str = `(null)'
ld_library_path_str = `(null)'
vg_prel = `(null)'
sk_prel = `(null)'
coredir2 = `(null)'
VG_LIBDIR = `/l/beta/lib'
This is clearly caused by the fact that this program clears the
environmental variables on startup (to known values).
What are the environmental variables that should be preserved (not
cleared) to allow valgrind to work for the program and the child
processes (with --trace-children=yes)? (My guess: LD_PRELOAD and
LD_LIBRARY_PATH.)
The FAQ entry 12 has some information:
Q12. My program dies like this (often at exit):
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
(loads of text)
A12. We're not entirely sure about this, and would appreciate
someone sending a simple test case for us to look at.
One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Avoid this if you can.
1.9.6 contains a fix which hopefully reduces the chances
of your program bombing out like this.
Perhaps a list of not-to-be-cleared environmental variables should be
added to the FAQ?
--
sa...@ss... I have no opinions, since I cannot express any, after all.
If you think you saw an opinion, contact your optometrist.
|
|
From: Jeremy F. <je...@go...> - 2003-08-13 01:05:51
|
On Tue, 2003-08-12 at 15:42, Paul A. Clarke wrote:
> Does Valgrind support x86-64 executables?
No.
> I assume x86-32 executables on an x86-64 chip would be supported as
> normal.
Yes.
> (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?
Yes.
J
|
|
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 |