You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
1
|
|
2
|
3
|
4
|
5
(2) |
6
(1) |
7
|
8
|
|
9
(1) |
10
(1) |
11
|
12
|
13
|
14
(3) |
15
(4) |
|
16
(4) |
17
(2) |
18
(18) |
19
|
20
|
21
(7) |
22
|
|
23
(2) |
24
(3) |
25
(1) |
26
(5) |
27
(12) |
28
(1) |
29
(2) |
|
30
(4) |
31
|
|
|
|
|
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 11:34:04
|
On Tue, 18 Mar 2003, Eyal Lebedinsky wrote: > I hope it complies with the current programming model and style (please > let me know where it fails to do so). From a quick glance, style looks ok. One thing: you use the "long" type for VG_(clo_time_zone)... use the Valgrind synonyms (eg. Long, although I think UInt would be ok here?) We should probably #define the built types "int", etc, to some rubbish so that any use of them is detected... > BTW, where is the CVS tree (is it public?). Publicly readable, on Sourceforge: sourceforge.net/cvs/?group_id=46268 N |
|
From: Eyal L. <ey...@ey...> - 2003-03-18 11:16:23
|
Julian Seward wrote: > > Eyal > > It looks like a good patch, and a useful thing too. I would merge > it in, except there is one critical problem which needs fixing first. As promised, here is a clean patch for the new --time-stamp option. I rewrote the logic so it is much simpler. Two general purpose functions were added VG_(time) as the standard time(), but uses type 'vg_time_t' VG_(localtime) as the standard localtime(), but uses type 'vg_tm'. Also, it always sets tm_isdst to zero and timezone is set through clo. I hope it complies with the current programming model and style (please let me know where it fails to do so). BTW, where is the CVS tree (is it public?). -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-18 09:27:18
|
Hi,
I just discovered a minor bug with --attach-gdb. If an error is caused by
a bad argument to write(), when Valgrind prompts the user whether to drop
into GDB, the first character of the write() is used as the prompt's
input. This program:
int main(void)
{
char buf[5];
buf[0] =3D 'a'; // not one of [yYnNcC]
write(1, buf, 5);
return 0;
}
gives this result:
[njn25@trent head4] vghead4 --gdb-attach=3Dyes a.out
=3D=3D3113=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for x86=
-linux.
=3D=3D3113=3D=3D Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
=3D=3D3113=3D=3D Using valgrind-1.9.4, a program instrumentation system for=
x86-linux.
=3D=3D3113=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
=3D=3D3113=3D=3D Estimated CPU clock rate is 1410 MHz
=3D=3D3113=3D=3D For more details, rerun with: -v
=3D=3D3113=3D=3D
=3D=3D3113=3D=3D Syscall param write(buf) contains uninitialised or unaddre=
ssable byte(s)
=3D=3D3113=3D=3D at 0x402F27B4: __libc_write (in /lib/libc-2.2.4.so)
=3D=3D3113=3D=3D by 0x40235335: __libc_start_main (../sysdeps/generic/li=
bc-start.c:129)
=3D=3D3113=3D=3D by 0x8048330: (within /local/scratch-2/njn25/local/src/=
grind/head4/a.out)
=3D=3D3113=3D=3D Address 0xBFFFF301 is on thread 1's stack
=3D=3D3113=3D=3D
=3D=3D3113=3D=3D ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- a
"@=B0=3D=3D311=
3=3D=3D
=3D=3D3113=3D=3D ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 fro=
m 0)
=3D=3D3113=3D=3D malloc/free: in use at exit: 0 bytes in 0 blocks.
=3D=3D3113=3D=3D malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
=3D=3D3113=3D=3D For a detailed leak analysis, rerun with: --leak-check=3D=
yes
=3D=3D3113=3D=3D For counts of detected errors, rerun with: -v
The `a"@=B0' is the last 4 bytes of the string.
It's a pretty obscure bug, and I don't know how to fix it because it goes
beyond my understanding of how the scheduler works. So maybe it's not
worth fixing. But I thought I'd report it.
N
|
|
From: Eyal L. <ey...@ey...> - 2003-03-17 13:29:27
|
Julian Seward wrote: > > Eyal > > It looks like a good patch, and a useful thing too. I would merge > it in, except there is one critical problem which needs fixing first. > > The patch uses a glibc function, time(), to get the time. We have > a policy that valgrind itself does not use any glibc functions or > headers. Is that so? I see a direct call to gettimeofday() in vg_libpthread.c #include <sys/time.h> /* gettimeofday */ and the include of <pthread.h> also brings in a few time related libc headers. So, I could not define the usual types and had to create new types (vg_time_t, struct vg_tm) and the related functions. Here is a second attempt at these options. The attached patch includes my toying with adjusting the sleep periods and switching to microsec periods (my 17h run finishes in under 7h now), I will send in a clean patch if the time-stamp part is acceptable. The relevant hunks are these (mostly the last one) coregrind/vg_errcontext.c print the timestamp coregrind/vg_include.h clo and my_libc declarations coregrind/vg_main.c clo handling coregrind/vg_mylibc.c VG_(time) and VG_(localtime) I can improve the performance of this implementation (stolen from the linux kernel, the handiest source at the time) and I should stress that this gives UTC, no attempt was done to implement the whole timezone business. I plan to extend the syntax of the option to allow --time-stamp=[+|-]mm:mm to set your local time offset manually, this should be good for most. Please check the code carefully, some of it is monkey see monkey do... -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Josef W. <Jos...@gm...> - 2003-03-17 10:10:41
|
Hi, I just want you to know. When running ./autogen.sh for valgrind CVS, with automake 1.7.2 I get the following warnings. I feel a little bit nervous about this, as usually someone compiling valgrind will think he can override e.g. "CFLAGS=xxx ./configure" as this is a standard configure feature. Josef running: aclocal running: autoheader running: automake -a addrcheck/Makefile.am:8: `CFLAGS' is a user variable, you should not override it; addrcheck/Makefile.am:8: use `AM_CFLAGS' instead. auxprogs/Makefile.am:7: `CFLAGS' is a user variable, you should not override it; auxprogs/Makefile.am:7: use `AM_CFLAGS' instead. cachegrind/Makefile.am:7: `CFLAGS' is a user variable, you should not override it; cachegrind/Makefile.am:7: use `AM_CFLAGS' instead. cachegrind/tests/Makefile.am:13: `CCASFLAGS' is a user variable, you should not override it; cachegrind/tests/Makefile.am:13: use `AM_CCASFLAGS' instead. cachegrind/tests/Makefile.am:11: `CFLAGS' is a user variable, you should not override it; cachegrind/tests/Makefile.am:11: use `AM_CFLAGS' instead. corecheck/Makefile.am:5: `CFLAGS' is a user variable, you should not override it; corecheck/Makefile.am:5: use `AM_CFLAGS' instead. corecheck/Makefile.am:9: `CPPFLAGS' is a user variable, you should not override it; corecheck/Makefile.am:9: use `AM_CPPFLAGS' instead. corecheck/tests/Makefile.am:34: `CFLAGS' is a user variable, you should not override it; corecheck/tests/Makefile.am:34: use `AM_CFLAGS' instead. coregrind/Makefile.am:12: `CCASFLAGS' is a user variable, you should not override it; coregrind/Makefile.am:12: use `AM_CCASFLAGS' instead. coregrind/Makefile.am:6: `CFLAGS' is a user variable, you should not override it; coregrind/Makefile.am:6: use `AM_CFLAGS' instead. coregrind/demangle/Makefile.am:4: `CFLAGS' is a user variable, you should not override it; coregrind/demangle/Makefile.am:4: use `AM_CFLAGS' instead. helgrind/Makefile.am:5: `CFLAGS' is a user variable, you should not override it; helgrind/Makefile.am:5: use `AM_CFLAGS' instead. lackey/Makefile.am:5: `CFLAGS' is a user variable, you should not override it; lackey/Makefile.am:5: use `AM_CFLAGS' instead. memcheck/Makefile.am:10: `CCASFLAGS' is a user variable, you should not override it; memcheck/Makefile.am:10: use `AM_CCASFLAGS' instead. memcheck/Makefile.am:8: `CFLAGS' is a user variable, you should not override it; memcheck/Makefile.am:8: use `AM_CFLAGS' instead. memcheck/tests/Makefile.am:66: `CFLAGS' is a user variable, you should not override it; memcheck/tests/Makefile.am:66: use `AM_CFLAGS' instead. memcheck/tests/Makefile.am:67: `CXXFLAGS' is a user variable, you should not override it; memcheck/tests/Makefile.am:67: use `AM_CXXFLAGS' instead. none/Makefile.am:5: `CFLAGS' is a user variable, you should not override it; none/Makefile.am:5: use `AM_CFLAGS' instead. none/tests/Makefile.am:52: `CFLAGS' is a user variable, you should not override it; none/tests/Makefile.am:52: use `AM_CFLAGS' instead. none/tests/Makefile.am:53: `CXXFLAGS' is a user variable, you should not override it; none/tests/Makefile.am:53: use `AM_CXXFLAGS' instead. tests/Makefile.am:16: `CFLAGS' is a user variable, you should not override it; tests/Makefile.am:16: use `AM_CFLAGS' instead. running: autoconf |
|
From: Julian S. <js...@ac...> - 2003-03-16 23:49:58
|
On Sunday 16 March 2003 11:39 pm, Eyal Lebedinsky wrote: > Julian Seward wrote: > > Eyal > > > > It looks like a good patch, and a useful thing too. I would merge > > it in, except there is one critical problem which needs fixing first. > > > > The patch uses a glibc function, time(), to get the time. We have > > And that goes for localtime() too, right? I will track down a private > implementation then. Get hold of the glibc sources and copy relevant bits from there. > But, it should be OK to issue glibc calls at initialisation time. No ... it's not ok to issue glibc calls at any time. You get bad interactions with the dynamic linker. J |
|
From: Eyal L. <ey...@ey...> - 2003-03-16 23:40:04
|
Julian Seward wrote: > > Eyal > > It looks like a good patch, and a useful thing too. I would merge > it in, except there is one critical problem which needs fixing first. > > The patch uses a glibc function, time(), to get the time. We have And that goes for localtime() too, right? I will track down a private implementation then. But, it should be OK to issue glibc calls at initialisation time. I can then grab timezone offset and use it locally at runtime. -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Julian S. <js...@ac...> - 2003-03-16 11:43:01
|
Eyal
It looks like a good patch, and a useful thing too. I would merge
it in, except there is one critical problem which needs fixing first.
The patch uses a glibc function, time(), to get the time. We have
a policy that valgrind itself does not use any glibc functions or
headers. This is to avoid nightmare bugs where V is executing glibc
code on the real CPU at the same time that the client program is
executing glibc code on the simulated CPU. Such mixing has proved
a problem in the past, and recently Nick spent 2 days chasing another
bug of this kind (not his bug, I point out).
This is why we have vg_mylibc.c to supply replacements for libc services
we actually need.
You may do a system call to get time info (look in vg_mylibc.c
for lots of examples). The best solution would be:
- Remove this
+#include <time.h> /* time, localtime, timezone */
+#include <sys/time.h> /* gettimeofday */
- Remove the call to time()
- Write your own vg_time(), somehow, and put it in vg_mylibc.c.
Note that there is no particular reason why vg_time should have
the same interface as glibc's time(); feel free to change it as
you feel useful. (Perhaps rename it if you change the meaning).
- Use that instead.
I hope this can be made to work because it looks to me like a
useful patch.
J
On Friday 14 March 2003 10:33 am, Eyal Lebedinsky wrote:
> Nicholas Nethercote wrote:
> > On Fri, 14 Mar 2003, Eyal Lebedinsky wrote:
> > > I added a line saying
> > >
> > > ==nnnn== Time: dddddd-hh:mm:ss
> > >
> > > Is there a standard was to request such timestamping? I would
> > > not mind learning how to properly add it to the package, with
> > > a proper --time-stap=yes option.
> >
> > Just choose an existing option and copy the way it's done. For example,
> > search for "--gdb-attach" and "VG_(clo_GDB_attach)" in the source ("clo"
> > is short for "command line option).
>
> OK, here is a humble patch that adds a new option
> --time-stamp=[no|yes]
> which yields the report below. I find that localtime() fails to account
> for timezone when used in valgrind, if anyone can fix it please do so.
>
> $ date ; valgrind --time-stamp=yes ls
> Fri Mar 14 21:31:01 EST 2003
> ==18272== Memcheck, a.k.a. Valgrind, a memory error detector for
> x86-linux.
> ==18272== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
> ==18272== Using valgrind-1.9.4, a program instrumentation system for
> x86-linux.
> ==18272== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
> ==18272== Estimated CPU clock rate is 1204 MHz
> ==18272== For more details, rerun with: -v
> ==18272==
> ==18272== Time: 2003/03/14 10:31:01
> ==18272== pthread_mutex_destroy: mutex is still in use
> ==18272== at 0x40352E70: pthread_error (vg_libpthread.c:288)
> ==18272== by 0x40353D3F: __pthread_mutex_destroy
> (vg_libpthread.c:998)
> ==18272== by 0x402CE1CE: closedir (in /lib/libc-2.2.5.so)
> ==18272== by 0x804A90D: (within /bin/ls)
> 03.ndx ds1.bat odds setit.bat test-all.bat
> build examples okreps ssacssv.err testall
> build.bat ids.db prepids ssacssv.log testall.bat
> chkunpdf ids.dbg prepids.bat ssarun.log testit.bat
> chkunpdf.awk idscosv.err rds stopit.bat tests
> chkunpdf.bat idscosv.log rds.awk stress.bat testx03g.lst
> cleanit.bat idssrsv.err rds.bat stress1.bat testx03p.lst
> data idssrsv.log rule.db systems x
> distro makefile rule.ndx t x.c
> ds1 makefile.tpl setit t.bat xmit
> ==18272==
> ==18272== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
> ==18272== malloc/free: in use at exit: 13833 bytes in 80 blocks.
> ==18272== malloc/free: 90 allocs, 10 frees, 24577 bytes allocated.
> ==18272== For a detailed leak analysis, rerun with: --leak-check=yes
> ==18272== For counts of detected errors, rerun with: -v
|
|
From: Julian S. <js...@ac...> - 2003-03-16 02:02:14
|
Hi. Two things: - I made the -developers list be visible from the outside, so that people can read the list archives. It's still subscriber-only posting, tho. - I have made a new -users list, to be a general discussion list for valgrind users, something I should have done a long time ago. The aims of it are outlined in a short para at the top of http://developer.kde.org/~sewardj/ I've subscribed; perhaps y'all should too. I'll be really interested to see if it does generate some kind of coherent user community. J |
|
From: Julian S. <js...@ac...> - 2003-03-15 17:55:26
|
I just changed the status of the list from private to public, so I think now you should be able to view the archives from the public side of things. (Whatever that really means). J On Saturday 15 March 2003 1:33 pm, Nicholas Nethercote wrote: > On Sat, 15 Mar 2003, Eyal Lebedinsky wrote: > > Any help with accessing the list archive will be > > appreciated - I simply go to > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > and follow the link to the "collection of prior > > postings" just to be greeted with > > > > ERROR > > Forum is restricted to members of this group > > I get that too. View it from > sourceforge.net/mailarchive/forum.php?forum_id=12302, which you get to if > you follow the "lists" link from > sourceforge.net/mailarchive/forum.php?forum_id=12302. > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Nicholas N. <nj...@ca...> - 2003-03-15 13:33:18
|
On Sat, 15 Mar 2003, Eyal Lebedinsky wrote: > Any help with accessing the list archive will be > appreciated - I simply go to > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > and follow the link to the "collection of prior > postings" just to be greeted with > > ERROR > Forum is restricted to members of this group I get that too. View it from sourceforge.net/mailarchive/forum.php?forum_id=12302, which you get to if you follow the "lists" link from sourceforge.net/mailarchive/forum.php?forum_id=12302. N |
|
From: Eyal L. <ey...@ey...> - 2003-03-15 07:10:26
|
I am using valgrind to test a heavily multithreaded client/server system and I suspect that the 98% idle CPU during much of the run is an indication of room for improvement. I started looking at the general logic of the scheduler and could not understand those unusual nanosleeps (various ms durations). I changed them all to 1ms (1 * 1000 * 1000) and my tests now complete in half the time (not bad for what was an 18 hours run last time). Since the machine is fully dedicated to this run, I am happy to have the CPU busy when no thread is ready. Probably a simple yield at that point is all one needs to give other processes a chance. So far I am unable to read the list archive so I will refrain from asking questions that may be FAQs. Any help with accessing the list archive will be appreciated - I simply go to https://lists.sourceforge.net/lists/listinfo/valgrind-developers and follow the link to the "collection of prior postings" just to be greeted with ERROR Forum is restricted to members of this group -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2003-03-15 02:09:01
|
When I try to connect to it at http://sourceforge.net/mailarchive/forum.php?forum=valgrind-developers I get a message saying it is only avaliable to members. How do I proceed to read the archive? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Eyal L. <ey...@ey...> - 2003-03-14 10:34:08
|
Nicholas Nethercote wrote:
>
> On Fri, 14 Mar 2003, Eyal Lebedinsky wrote:
> > I added a line saying
> >
> > ==nnnn== Time: dddddd-hh:mm:ss
>
> > Is there a standard was to request such timestamping? I would
> > not mind learning how to properly add it to the package, with
> > a proper --time-stap=yes option.
>
> Just choose an existing option and copy the way it's done. For example,
> search for "--gdb-attach" and "VG_(clo_GDB_attach)" in the source ("clo"
> is short for "command line option).
OK, here is a humble patch that adds a new option
--time-stamp=[no|yes]
which yields the report below. I find that localtime() fails to account
for timezone when used in valgrind, if anyone can fix it please do so.
$ date ; valgrind --time-stamp=yes ls
Fri Mar 14 21:31:01 EST 2003
==18272== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==18272== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==18272== Using valgrind-1.9.4, a program instrumentation system for
x86-linux.
==18272== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==18272== Estimated CPU clock rate is 1204 MHz
==18272== For more details, rerun with: -v
==18272==
==18272== Time: 2003/03/14 10:31:01
==18272== pthread_mutex_destroy: mutex is still in use
==18272== at 0x40352E70: pthread_error (vg_libpthread.c:288)
==18272== by 0x40353D3F: __pthread_mutex_destroy
(vg_libpthread.c:998)
==18272== by 0x402CE1CE: closedir (in /lib/libc-2.2.5.so)
==18272== by 0x804A90D: (within /bin/ls)
03.ndx ds1.bat odds setit.bat test-all.bat
build examples okreps ssacssv.err testall
build.bat ids.db prepids ssacssv.log testall.bat
chkunpdf ids.dbg prepids.bat ssarun.log testit.bat
chkunpdf.awk idscosv.err rds stopit.bat tests
chkunpdf.bat idscosv.log rds.awk stress.bat testx03g.lst
cleanit.bat idssrsv.err rds.bat stress1.bat testx03p.lst
data idssrsv.log rule.db systems x
distro makefile rule.ndx t x.c
ds1 makefile.tpl setit t.bat xmit
==18272==
==18272== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 1)
==18272== malloc/free: in use at exit: 13833 bytes in 80 blocks.
==18272== malloc/free: 90 allocs, 10 frees, 24577 bytes allocated.
==18272== For a detailed leak analysis, rerun with: --leak-check=yes
==18272== For counts of detected errors, rerun with: -v
--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Nicholas N. <nj...@ca...> - 2003-03-14 08:37:32
|
On Fri, 14 Mar 2003, Eyal Lebedinsky wrote:
> My standard run takes about 15h, and in this period a single server
> deals with a few hundred clients. I need to know which valgrind
> error report belongs to which client, and the way to do it is to
> timestamp the reports.
>
> I added a line saying
>
> ==nnnn== Time: dddddd-hh:mm:ss
> Is there a standard was to request such timestamping? I would
> not mind learning how to properly add it to the package, with
> a proper --time-stap=yes option.
Just choose an existing option and copy the way it's done. For example,
search for "--gdb-attach" and "VG_(clo_GDB_attach)" in the source ("clo"
is short for "command line option).
> Right now I find the most important bit (after correctness) to
> be the speedup of the main scheduler, most of the above 15
> hours pass with the CPU at 98-100% idle. Is anyone working
> on this part currently?
Not really. Valgrind's threads implementation is not very fast, because
most programs don't really need it to be. And as simple as it is, it's
still one of the most complicated and problematic parts of Valgrind. So I
wouldn't hold your breath for improvements any time soon, sorry.
N
|
|
From: Eyal L. <ey...@ey...> - 2003-03-14 08:19:33
|
My standard run takes about 15h, and in this period a single server deals with a few hundred clients. I need to know which valgrind error report belongs to which client, and the way to do it is to timestamp the reports. I added a line saying ==nnnn== Time: dddddd-hh:mm:ss to the start of the report and I find it very usefull. It was a worthy exercies as I found that I cannot simply access the c library (I am still to learn how to do this) but since I did have access to time() I displayed the rest using a simple function. Is there a standard was to request such timestamping? I would not mind learning how to properly add it to the package, with a proper --time-stap=yes option. Right now I find the most important bit (after correctness) to be the speedup of the main scheduler, most of the above 15 hours pass with the CPU at 98-100% idle. Is anyone working on this part currently? -- Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/> |
|
From: Josef W. <Jos...@gm...> - 2003-03-10 13:17:03
|
On Sunday 09 March 2003 17:37, Nicholas Nethercote wrote:
> On Fri, 7 Mar 2003, Josef Weidendorfer wrote:
> > > Thinking about it some more, the only reason I can think of why
> > > valgrind even needs its own malloc() is this:
>
> Thinking more, another important reason is this: for memcheck/addrcheck,
> having the redzones around malloc'd blocks allows them to catch
> over/under-runs.
Yes, but that's not needed for a pure tracing/profiling skin like cachegrind,
too.
> > As I see, a skin is able to implement it's own GLIBC wrapper functions,
> > no matter if they are called malloc() or perhaps open(), simply by
> > defining the function in the skin.
> > This is simply another (but static) way of defining the behaviour of a
> > skin. E.g. in vg_skin.h, do a
> >
> > #define REDIRECT1(fn,rType,pType1) \
> > rType fn(pType1 p1) { return VG_(fn)(p1); }
> >
> > and in the skin, put
> >
> > REDIRECT1(malloc,void*,size_t)
> >
> > Of course it would be good to be able to check at runtime if the skin
> > defined its own wrapper for a function: Use dlsym(RTLD_DEFAULT,"malloc")
> > and check if the address is defined inside of the skin. You can issue a
> > warning if no wrapper was defined when e.g. "new_mem_heap" is requested.
>
> Well, dlsym() is not available for use within Valgrind, unless someone
> implements VG_(dlsym)(). I think.
Ok. Next try:
#define REDIRECT1(fn,rType,pType1) \
rType fn(pType1 p1) { return VG_(fn)(p1); } \
Boolean VG_(fn##_wrapper_defined) = True;
For all symbols where checking for a wrapper is needed, put e.g.
Boolean VG_(malloc_wrapper_defined) = False;
into valgrind core. As the skin lib is ahead of the valgrind lib in
LD_PRELOAD, you will get the "True" value if the wrapper is defined
(Perhaps the boolean in valgrind core must be a weak symbol).
> It's an interesting idea, but feels a bit messy to me... there's one more
> thing for a skin to get wrong (ask for "new_mem_heap" but forget the
> REDIRECT). Doing things statically with macros is a bit hacky too, but
> maybe unavoidable.
Best is to make the "ask for new_mem_heap but forget the REDIRECT" a fatal
error, checked at startup.
> But I do like the idea of the default behavour being "glibc malloc(), no
> wrapper" and that a skin should have to request different behaviour...
> kind of a "principle of least interference" with the original program.
Especially as KDE comes with a malloc implementation of its own. With current
valgrind, cachegrind can't check if the "KDE fast malloc" is really faster
than the glibc provided one.
>
> Here's my ideal scenario:
>
> i. default is no wrapper + glibc malloc()
>
> ii. skin can specify with a need if it wants to use Valgrind's malloc()
> (eg. needs_redzones, or needs_special_malloc, or something)
>
> iii. core decides whether a malloc() wrapper is needed (eg. because
> new_mem_heap is being tracked, or --trace-malloc=yes is set, or
> core errors or shadow chunks are needed
>
> iv. if wrapper is needed, core calls glibc malloc() or Valgrind
> malloc() depending on the needs_redzones/whatever need
>
>
> I don't think all this is attainable. Esp (iii), since the conditions
> there are all dynamic, but the overwriting by Valgrind of glibc's malloc()
> symbol must be done statically.
Valgrind core must be able to check whether the skin provides a wrapper.
This is best done with a second symbol definition, and relying on the runtime
linker for this (see above), as this is the same mechanism.
> I think wrapper + glibc() malloc might be attainable with the --wrap
> linker option, but I'm not certain.
I'm not sure about this. A program to be run under supervison of valgrind is
already linked; you can't change symbol names in it.
But GLIBC is prepared for wrapping its symbols: To get the real malloc, use
"__libc_malloc". As said above, KDE does the same wrapping with its "fast
malloc implementation" as we want to do here. You can have a look at the
code: Use the KDE CVS web frontend and look into "kdelibs/kdecore/malloc".
Josef
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-09 16:37:11
|
On Fri, 7 Mar 2003, Josef Weidendorfer wrote:
> > Thinking about it some more, the only reason I can think of why valgrind
> > even needs its own malloc() is this:
Thinking more, another important reason is this: for memcheck/addrcheck,
having the redzones around malloc'd blocks allows them to catch
over/under-runs.
> As I see, a skin is able to implement it's own GLIBC wrapper functions, no
> matter if they are called malloc() or perhaps open(), simply by defining the
> function in the skin.
> This is simply another (but static) way of defining the behaviour of a skin.
> E.g. in vg_skin.h, do a
>
> #define REDIRECT1(fn,rType,pType1) \
> rType fn(pType1 p1) { return VG_(fn)(p1); }
>
> and in the skin, put
>
> REDIRECT1(malloc,void*,size_t)
>
> Of course it would be good to be able to check at runtime if the skin defined
> its own wrapper for a function: Use dlsym(RTLD_DEFAULT,"malloc") and check if
> the address is defined inside of the skin. You can issue a warning if no
> wrapper was defined when e.g. "new_mem_heap" is requested.
Well, dlsym() is not available for use within Valgrind, unless someone
implements VG_(dlsym)(). I think.
It's an interesting idea, but feels a bit messy to me... there's one more
thing for a skin to get wrong (ask for "new_mem_heap" but forget the
REDIRECT). Doing things statically with macros is a bit hacky too, but
maybe unavoidable.
But I do like the idea of the default behavour being "glibc malloc(), no
wrapper" and that a skin should have to request different behaviour...
kind of a "principle of least interference" with the original program.
It's worth thinking about the different possibilities here in more detail.
----
This is the sequence of events when a client calls malloc(), and
VG_(running_on_simd_CPU) == True.
1. client
- calls malloc()
2. vg_clientfuncs.c:malloc() wrapper is called:
- prints info, if --trace-malloc=yes
- checks arg, if negative:
- if core_checks needed, gives a warning
- returns NULL
- else calls SIMPLE_REQUEST1(VG_USERREQ__MALLOC, n)
3. vg_scheduler.c:do_client_request()
- calls VG_(client_malloc)()
4. vg_clientmalloc.c:VG_(client_malloc)():
- updates malloc stats (number of calls, bytes allocated)
- calls VG_(arena_malloc)()
- add a ShadowChunk (holding extra info about the block), if
needs_shadow_chunks is set
- calls new_mem_heap() event tracker, if there is one
(I don't understand why vg_clientfuncs.c:malloc() needs to use the client
request, rather than just calling VG_(client_malloc)() directly...
although when I tried it I got lots of "invalid read"s within
vg_malloc2.c only some programs... Julian?)
----
When must a skin use Valgrind's malloc?
- when red zones are needed
When must a skin use a malloc() wrapper?
- to print out debug info about malloc() calls
- if 'core_errors' is specified (it prints warning on negative args)
- to use new_mem_heap, etc
- to use ShadowChunks
Valgrind's own malloc() must of course still be used within the core.
What are the possible combinations:
a. no wrapper, glibc malloc()
b. no wrapper, valgrind malloc()
c. wrapper, glibc malloc()
d. wrapper, valgrind malloc
Memcheck would use (d), Helgrind would use (c) I think (doesn't need
redzones), Cachegrind & CallTree would use (a). No skins currently in
existence would use (b).
I think (c) can be achieved using ld's "--wrap symbol" option.
----
Here's my ideal scenario:
i. default is no wrapper + glibc malloc()
ii. skin can specify with a need if it wants to use Valgrind's malloc()
(eg. needs_redzones, or needs_special_malloc, or something)
iii. core decides whether a malloc() wrapper is needed (eg. because
new_mem_heap is being tracked, or --trace-malloc=yes is set, or
core errors or shadow chunks are needed
iv. if wrapper is needed, core calls glibc malloc() or Valgrind
malloc() depending on the needs_redzones/whatever need
I don't think all this is attainable. Esp (iii), since the conditions
there are all dynamic, but the overwriting by Valgrind of glibc's malloc()
symbol must be done statically.
I think wrapper + glibc() malloc might be attainable with the --wrap
linker option, but I'm not certain.
Josef, your REDIRECT idea is heading in the right direction, but not quite
there, I think.
----
So, lots of words from me, but no firm conclusions. Hmm.
N
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-06 08:50:36
|
On Wed, 5 Mar 2003, Josef Weidendorfer wrote: > It's about wrong costs of some GLIBC functions when run under cachegrind, > namely the ones being reimplemented by valgrind, e.g. malloc, __builtin_new > and so on. > If you have C++ code with lots of new/delete, the profiled costs are by far > underestimated. > > Aside from signal/thread handling, is there any need that the > valgrind-supplied variants have to be called on the simulated CPU when using > skins like cachegrind? > I would prefer running the original functions and put all the symbols of > "vg_clientfuncs.c" into the respective skin. I've wondered about this before. I can see four possible combinations a skin might want: a. ordinary malloc() b. ordinary malloc(), but be notified of new_mem_heap etc. events c. valgrind malloc() d. valgrind malloc(), but be notified of new_mem_heap etc. events Thinking about it some more, the only reason I can think of why valgrind even needs its own malloc() is this: for skins using new_mem_heap etc. events, if they used the ordinary malloc(), they could get two events: one from Valgrind saying "new_mem_heap", and then one when normal malloc() does a mmap() or brk() to actually get the memory. This would be bad. So I think only combinations (a), (c) and (d) above will work. And (c) is the one you want to turn into (a). I guess what would be ideal is if the default is for a skin to use normal malloc() (ie. (a)), but if any of the new_mem_heap, die_mem_heap, etc. events are used by a skin, Valgrind switches to using VG_(malloc) (ie. (d)). But this could be difficult, since symbols are static and the event tracking is set up by the skin once things have started. Can anyone think of a nice way of achieving this? N |
|
From: Josef W. <Jos...@gm...> - 2003-03-05 23:38:47
|
Hi, I just got a bug/misbehaviour report for cachegrind which is IMHO justified (from Lars Knoll <la...@tr...>). It's about wrong costs of some GLIBC functions when run under cachegrind, namely the ones being reimplemented by valgrind, e.g. malloc, __builtin_new and so on. If you have C++ code with lots of new/delete, the profiled costs are by far underestimated. Aside from signal/thread handling, is there any need that the valgrind-supplied variants have to be called on the simulated CPU when using skins like cachegrind? I would prefer running the original functions and put all the symbols of "vg_clientfuncs.c" into the respective skin. Or am I totally wrong here? Josef |
|
From: Julian S. <js...@ac...> - 2003-03-05 00:45:45
|
Greetings, all. I released 1.9.4 from the cvs HEAD last Friday, and tagged VALGRIND_1_9_4 at that point. 1.9.4 fixes some of the more pressing bugs in 1.9.3. Overall, 1.9.3/4 seem pretty stable, and I get the impression it is getting quite widely used. My impression is that 1.9.4 is at least as stable as 1.0.4, and so I've branched the tree at this point; the branch tag is VALGRIND_2_0_BRANCH, as expected, and I plan to roll out 2.0.X from that branch some time. That means the head is now open for committing again. Red Hat have very kindly started to supply plausible-looking patches which for (1) MMX/SSE support, and (2) support for NGPT or whatever the next generation posix threads stuff is called. I'll try and work (1) into the head soonish, and perhaps (2) a little later on, once I understand the consequences of it -- it involves quite large changes to the threading stuff. J |