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
(5) |
2
(15) |
3
(20) |
|
4
(4) |
5
(11) |
6
(8) |
7
(36) |
8
(23) |
9
(6) |
10
(4) |
|
11
(4) |
12
(19) |
13
(17) |
14
(33) |
15
(16) |
16
(17) |
17
(4) |
|
18
(4) |
19
(30) |
20
(22) |
21
(23) |
22
(29) |
23
(20) |
24
(12) |
|
25
(7) |
26
(33) |
27
(10) |
28
(12) |
29
(19) |
30
(15) |
31
(8) |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-28 22:09:00
|
On Thu, Jan 29, 2009 at 3:28 AM, John Reiser <jr...@bi...> wrote: >> I want to redirect calls to e.g. socket function calls like "bind" or "recv" >> to ones that are used in a network simulator. > > In most cases this can be done by using LD_PRELOAD. The socket interface > is sufficiently grotesque (all functions are multiplexed into just one system > call number) that nearly all apps use the extern C linkage to C library (glibc). > In most remaining cases, direct binary patching (over-write instructions with > JUMP to intercept code) works well. Yes, that would be the easiest way. Or you could use Valgrind's function wrapping support -- see section 3.2 of the manual, but be warned that it's a bit tricky to get working well. Nick |
|
From: Josef W. <Jos...@gm...> - 2009-01-28 18:19:15
|
On Wednesday 28 January 2009, Tom Hughes wrote: > > Josef, you committed a non-power-of-two cache size change for Callgrind. > > I would like to ship that in 3.4.1 if it is stable enough and will not > > cause any problems. (Rationale: CPUs with non-power-of-2 cache sizes > > are already common, and 3.4.x is likely to stay alive approximately > > a year). What do you think? Yes, that was my intention with the patch. From the stability point of view, for Cachegrind it is minimalistic, and it is sane from a technical point of view. For Callgrind, it is more or less the same, with a few "|" changed to "+" in addition. I am sufficiently sure that it is correct. All simulator variants are tested with non-power-of-two cache sizes. Also, the nightly tests just showed the addition of the 5 added tests. What do you think of the manual changes in Cachegrind? (the Callgrind manual just refers to Cachegrind). As given in the commit message, the patch needs r8912, which gets rid of some code duplication for getting the cache parameters via CPUID (obviously correct). > I think we should put it in. I've just tested it on both a Core 2 with a > 6Mb L2 and an Atom with a 24Kb D1 with no obvious ill effects other than > the warning going away. Good to know. Anyway, this was expected, as all the added tests for non-power-of-two overwrite the cache parameters to check for exactly these cases on every system. Josef > > Tom > |
|
From: John R.
|
> I want to redirect calls to e.g. socket function calls like "bind" or "recv" > to ones that are used in a network simulator. In most cases this can be done by using LD_PRELOAD. The socket interface is sufficiently grotesque (all functions are multiplexed into just one system call number) that nearly all apps use the extern C linkage to C library (glibc). In most remaining cases, direct binary patching (over-write instructions with JUMP to intercept code) works well. -- |
|
From: Christoph M. <ma...@tm...> - 2009-01-28 14:31:27
|
Hi, as I am new to valgrind development, sorry if this is a stupid question. I want to write a new valgrind tool to redirect linux system calls to my own implementation. Specifically, I want to redirect calls to e.g. socket function calls like "bind" or "recv" to ones that are used in a network simulator. The goal is to take a normal network application like a Webserver, redirect all network calls through binary transformation with a valgrind tool and then, have a new executable that runs in the simulation environment. Is it possible to use valgrind to "exchange" function calls? Or would it be easier to use some kind of relinking mechanisms? Thanks, Chris |
|
From: Tom H. <to...@co...> - 2009-01-28 12:40:42
|
Julian Seward wrote: > Josef, you committed a non-power-of-two cache size change for Callgrind. > I would like to ship that in 3.4.1 if it is stable enough and will not > cause any problems. (Rationale: CPUs with non-power-of-2 cache sizes > are already common, and 3.4.x is likely to stay alive approximately > a year). What do you think? I think we should put it in. I've just tested it on both a Core 2 with a 6Mb L2 and an Atom with a 24Kb D1 with no obvious ill effects other than the warning going away. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Julian S. <js...@ac...> - 2009-01-28 11:15:01
|
Hi, I'd like to release Valgrind 3.4.1 on Sunday 15 Feb. This is much sooner than usual between x.y.z releases, but it's clear now that 3.4.0 had some serious regressions in stack unwinding, and so it's important to push out a new stable version soon. In the past few days I merged in a bunch of stack unwinding fixes from Tom, plus misc other debuginfo reading fixes, and I think 3_4_BRANCH is now in a pretty good state. If there are any other high priority bug fixes that should go in 3.4.1, please let me know, preferably with trunk rev numbers. But please no build system changes. Josef, you committed a non-power-of-two cache size change for Callgrind. I would like to ship that in 3.4.1 if it is stable enough and will not cause any problems. (Rationale: CPUs with non-power-of-2 cache sizes are already common, and 3.4.x is likely to stay alive approximately a year). What do you think? J |
|
From: Nicholas N. <n.n...@gm...> - 2009-01-28 05:25:13
|
On Tue, Jan 27, 2009 at 10:59 PM, Konstantin Serebryany > The page mentioned by Nick looks partially outdated. > At least few items (--track-origins=yes, C++ demangler) are already > implemented. I've deleted those two, thanks. Nick |
|
From: <sv...@va...> - 2009-01-28 05:24:10
|
Author: njn Date: 2009-01-28 05:23:59 +0000 (Wed, 28 Jan 2009) New Revision: 375 Log: Remove two projects that have been done. Modified: trunk/help/projects.html Modified: trunk/help/projects.html =================================================================== --- trunk/help/projects.html 2009-01-10 05:44:32 UTC (rev 374) +++ trunk/help/projects.html 2009-01-28 05:23:59 UTC (rev 375) @@ -201,17 +201,6 @@ numbers. (Added August 27, 2005)</p> -<h3>Updating the C++ demangler</h3> -<p>Valgrind's C++ demangler was copied almost verbatim from GNU binutils -about 4 years ago. We have heard of one or two cases where it is -failing to demangle some symbols; it's possible that new demangling -cases have been introduced since then. It would be useful if someone -checked that the demangler is up-to-date, and fixed it if not. The -relevant Valgrind files are coregrind/m_demangle/*.c. This would be a -relatively easy project, at the same time being of benefit to a large -proportion of the Valgrind user base. (Added August 27, 2005)</p> - - <h3>Supporting custom allocators</h3> <p>Valgrind has two client requests, VALGRIND_MALLOCLIKE_BLOCK and VALGRIND_FREELIKE_BLOCK that are intended to support custom allocators. @@ -311,29 +300,6 @@ learn about OS kernels and Valgrind's internals. (Added August 27, 2005.)</p> -<h3>Identifying root causes of undefined value errors</h3> -<p>Memcheck's undefined value errors report the use of undefined values -at the point at which they could affect the program's behaviour. This -is often far from the root cause of the error, which often makes fixing -these errors challenging. The Memcheck USENIX paper has lots more -information about this.</p> - -<p>Typically the root cause is forgetting to initialise a piece of -memory such as a field in a struct. Some errors have more than one root -cause. If you could associate extra metadata with each undefined value -that identifies one of its root causes, better undefined error messages -would be possible. The hard part is maintaining that extra metadata for -all undefined value errors without taking a large performance hit. -We're not convinced it's even possible, but we'd love to be proven -wrong. A solution to this problem would be publishable. (Added August 27, -2005)</p> - -<p>The "Tracking Bad Apples" paper on our -<a href="docs/pubs.html">publications page</a> describes an attempt at this -that was promising but ultimately didn't work that well in practice. -(August 29, 2007) - - <h3>Cryptographic snooping</h3> <p>Since a Valgrind tool can see every operation performed by a program, it is conceivable that a tool might be able to analyse some kind of |
|
From: Tom H. <th...@cy...> - 2009-01-28 03:47:29
|
Nightly build on vauxhall ( x86_64, Fedora 10 ) started at 2009-01-28 03:20:04 GMT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 486 tests, 2 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/hg05_race2 (stderr) memcheck/tests/x86-linux/scalar (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 486 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Jan 28 03:33:44 2009 --- new.short Wed Jan 28 03:47:22 2009 *************** *** 8,10 **** ! == 486 tests, 1 stderr failure, 0 stdout failures, 0 post failures == memcheck/tests/x86-linux/scalar (stderr) --- 8,11 ---- ! == 486 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/hg05_race2 (stderr) memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-28 03:44:19
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-01-28 03:05:07 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 477 tests, 6 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/tc20_verifywrap (stderr) memcheck/tests/x86-linux/scalar (stderr) |
|
From: Tom H. <th...@cy...> - 2009-01-28 03:32:07
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-01-28 03:10:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 483 tests, 6 stderr failures, 2 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/linux/timerfd-syscall (stdout) memcheck/tests/x86-linux/scalar (stderr) none/tests/mremap2 (stdout) |
|
From: Julian S. <js...@ac...> - 2009-01-28 00:53:04
|
> Note to valgrind experts: this is _not_ about the Conditional thing in
> zlib, but about an uninitialized byte _in the middle_ of the zlib output
> buffer.
I understand. But -- whilst we're on the subject of the Conditional thing:
I thought I'd suppressed all those zlib FAQ#36 complaints, but apparently
not. Could you try the following and see if it helps?
Index: xfree-4.supp
===================================================================
--- xfree-4.supp (revision 9082)
+++ xfree-4.supp (working copy)
@@ -315,6 +315,7 @@
zlib-1.2.x trickyness (1a): See http://www.zlib.net/zlib_faq.html#faq36
Memcheck:Cond
obj:/*lib*/libz.so.1.2.*
+ ...
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
@@ -329,6 +330,7 @@
zlib-1.2.x trickyness (2a): See http://www.zlib.net/zlib_faq.html#faq36
Memcheck:Value8
obj:/*lib*/libz.so.1.2.*
+ ...
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
@@ -343,6 +345,7 @@
zlib-1.2.x trickyness (3a): See http://www.zlib.net/zlib_faq.html#faq36
Memcheck:Value4
obj:/*lib*/libz.so.1.2.*
+ ...
obj:/*lib*/libz.so.1.2.*
fun:deflate
}
Now to your real question. I believe this is either a bug in Valgrind
or some strangeness with libc. I don't think it has anything to do
with zlib.
One way to make sense of it is to force Memcheck to check the definedness
of the output buffer as soon as you're done with zlib. This is easier to
make sense of than trying to infer what's going on by interpreting complaints
about badness deep in the innards of libc. Thusly:
--- zlib_bad.c-ORIG 2009-01-28 01:25:46.000000000 +0100
+++ zlib_bad.c 2009-01-28 01:41:13.000000000 +0100
@@ -2,6 +2,7 @@
#include <stdlib.h>
#include <string.h>
#include <zlib.h>
+#include <memcheck.h>
int main(int argc, char **argv)
{
@@ -64,12 +65,17 @@
if (deflateEnd(&stream) != Z_OK)
return 1;
+ int nAvail = size - stream.avail_out;
+ printf("nAvail = %d\n", nAvail);
+ VALGRIND_CHECK_MEM_IS_DEFINED(compressed, nAvail);
+#if 0
out = fopen("/dev/null", "w");
fwrite(compressed + 51, 51, 1, out);
fwrite(compressed + 51, 1, 1, stderr);
fflush(out);
fclose(out);
+#endif
free(compressed);
return 0;
}
Program as modified w/ patch runs Memcheck-clean for me. Whereas if
you change the check to
VALGRIND_CHECK_MEM_IS_DEFINED(compressed, nAvail+1);
then I get
nAvail = 58
==3891== Uninitialised byte(s) found during client check request
==3891== at 0x40092D: main (zlib_bad.c:70)
==3891== Address 0x53da882 is 58 bytes inside a block of size 193 alloc'd
==3891== at 0x4C2594E: malloc (vg_replace_malloc.c:207)
==3891== by 0x400859: main (zlib_bad.c:46)
as expected.
That said, I don't have any concrete offerings as to what the problem
really is, or even whether there is a problem. I do know that zlib's
handwritten assembly inner loops tend to cause Memcheck's definedness
tracking to have problems. If you want to chase this further, I suggest you
build zlib from source, with -g -O0, and make sure you use the generic
C versions of deflate et al. Then you might be in with a fighting chance
of getting to the bottom of this.
Please lmk what the outcome is, so I know if it's a bug in Memcheck.
A final comment - you should make friends with --track-origins=yes.
It doesn't help much here, but in general it makes finding the sources
of uninitialised values a whole lot easier.
J
|