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
(1) |
|
2
(28) |
3
(21) |
4
(27) |
5
(22) |
6
(24) |
7
(25) |
8
(21) |
|
9
(18) |
10
(20) |
11
(10) |
12
(36) |
13
(18) |
14
(18) |
15
(29) |
|
16
(17) |
17
(7) |
18
(11) |
19
(17) |
20
(18) |
21
(12) |
22
(13) |
|
23
(9) |
24
(8) |
25
(7) |
26
(22) |
27
(18) |
28
(9) |
29
(15) |
|
30
(13) |
31
(7) |
|
|
|
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-10-27 20:27:28
|
On Thu, 27 Oct 2005, Jeroen N. Witmond wrote:
> Recent changes in VEX's instrumentation interface seem to allow the
> reinstatement of the full functionality of lackey. The attached patch
> attempts to do this, with the following questions:
>
> - To count the number of guest instructions, I count the number of
> Ist_IMark statements executed. Is this the correct approach?
Yes.
> - One additional guest instruction is still counted for each building
> block (in add_one_BB). Is this (and the comment explaining it) still
> relevant?
I don't think so. Adding instrumentation at each IMark to count the
instruction should be enough.
> - lackey still uses the word 'UInstr'. Should this be replaced by
> something like 'VEX statement'?
Yes.
Similarly, the notion of basic block counting is no longer accurate
either, since Vex uses superblocks (single-entry, multiple-exit sequences
of code).
> - In the 'switch (st->tag)' statement, the 'case Ist_Exit:' adds a deep
> copy of the statement to bb; whereas the 'default:' adds the statement
> itself. Is there a rationale behind this difference?
I don't know. Cachegrind doesn't do deep copies like this. If you remove
the deep copy does it still work?
Another thing... as this comment explains...
/* We need to know the entry point for this bb to do this. In any
case it's pretty meaningless in the presence of bb chasing since
we may enter this function part way through an IRBB. */
... calling get_fnname_if_entry() only at the start of a block might cause
the entry to the function to be missed. You could call
get_fnname_if_entry() for every instruction (ie. on every IMark) instead.
Nick
|
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-27 20:12:08
|
Greetings, Recent changes in VEX's instrumentation interface seem to allow the reinstatement of the full functionality of lackey. The attached patch attempts to do this, with the following questions: - To count the number of guest instructions, I count the number of Ist_IMark statements executed. Is this the correct approach? - One additional guest instruction is still counted for each building block (in add_one_BB). Is this (and the comment explaining it) still relevant? - lackey still uses the word 'UInstr'. Should this be replaced by something like 'VEX statement'? - In the 'switch (st->tag)' statement, the 'case Ist_Exit:' adds a deep copy of the statement to bb; whereas the 'default:' adds the statement itself. Is there a rationale behind this difference? Jeroen. |
|
From: Robert W. <rj...@du...> - 2005-10-27 18:46:18
|
> > * There's the BerkeleyDB flakiness thing. Plus having to
> > _manually_ upgrade the DB whenever the BerkeleyDB version
> > changes.
>=20
> That's why they introduced fsfs.
Granted. Valgrind needs to switch over to this.
> star mergin technique is on the way.
It's not there already, which makes it next to useless for existing
repositories. I already have repos where I have to hand-track merges.
Will the new merge stuff automatically figure out these existing merges?
I don't think it can, unless it comes with a natural-language processor,
because none of the meta-data (from rev blah, directory blah) is left
around.
> > * Centralized repositories are so mid-90s.
>=20
> this is FUD
I don't know what you mean by this, unless you have a different
definition of the word FUD to me. I'm expressing an opinion here. FUD
doesn't enter into it.
> SVN is adopting some basic ideas from CVS, so, that users will=20
> have it easy to switch over. This counts in for centralization as well as=
for=20
> the client side commandline use.
Users, I've noticed, are not stupid: they can mostly deal with new
ideas. Distributed can be made to look centralized if that's a problem.
Switching over to just about any new SCM from CVS is made trivial by the
wealth of importers that exist. I don't buy the "easy migration from
CVS" argument one bit.
> as said above, when you don't like it. don't use it. but don't blame othe=
rs=20
> about that you feel so bad in using it.
> I (in my case) don't like CVS, but I (usually) don't blame it publically =
in a=20
> way you do (that is: somewhat "mediocre").
Wow. I'm not about to bottle up my thoughts on something just because I
might make someone cry. I'm expressing an opinion based on observations
I've had working on projects where I have no policy access to the
repositories. I'm only blaming people in so much as anyone who files a
bug report blames someone. Do you think any argument against SVN is by
default mediocre?
> > * Configuring an already-fun-to-configure Apache setup to plonk a=
n
> > SVN server in on top.
>=20
> you don't need Apache to provide access to SVN repositories.
> Think about svn:// and svn+ssh://. Simply RTFM.
Not that simple. For example, one of the repos I use is in a secure
national lab. http access is all they allow through. ssh certainly
isn't going to be allowed, and their admins will balk at the thought of
opening up yet another port.
> This "performance issue" is well known by the svn devs and got *partly* f=
ixed=20
> at the time KDE were about to switch over from CVS to SVN.
> I'd recomment you to join #svn and/or #svn-devel at OPN if you have some =
good=20
> (meaning: not "lame") ideas and proposals on how to improve it.
> Doing so could also change your future experience when using svn after ha=
ving=20
> these improvements being implemented :-P
But, why bother? Right now, I can get a really fast SCM (actually,
there's a choice of several) that solves all my problems without having
to wait for future performance and functionality fixes, mess around with
alternative clients to make functionality magically appear, etc. I know
these existing SCMs were designed from the ground up as distributed SCMs
with changesets treated as first-class objects and not an afterthought,
which makes them fast and convenient right out of the box.
My capsule summary of your counter-argument is:
* Don't use BerkeleyDB.
* The new functionality is on the way.
* Yes, performance is a problem. Try fix it yourself.
* If you don't like it, use something else. Good idea!
* Don't express an opinion that might offend someone.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: Christian P. <tr...@ge...> - 2005-10-27 17:43:03
|
On Wednesday 26 October 2005 22:58, Robert Walsh wrote:
> > Subversion's BerkeleyDB back-end sometimes sucks... the rest of it is
> > pretty good. GCC's about to switch to it from CVS..
>
> Having used SVN for a while now (on this project and on others), I can
> say that I find it quite mediocre:
saying mediocre gives me the feeling of a very very bad word.
when you really feel that way, then you'd better stay away=20
from svn in any way.
> * There's the BerkeleyDB flakiness thing. Plus having to
> _manually_ upgrade the DB whenever the BerkeleyDB version
> changes.
That's why they introduced fsfs.
> * Branching and merging is as bad as CVS: you actually have to
> remember what revisions you've merged in yourself. For busy
> repositories like some I'm involved in, that can be painful.
> This is probably my biggest gripe. With a changeset concept
> added to Subversion, I at least expected this to be fixed, so
> imagine my surprise.
star mergin technique is on the way. it's "well known" by the=20
subversion devs, that svn's merging is as trivial as in CVS,=20
however, branching is far off the same as in CVS. I guess you=20
never did it, when you say it actually *is* the same.
When you need "star merging"-alike features, use SVK as SVN client which=20
already supports it.
> * Centralized repositories are so mid-90s.
this is FUD. SVN is adopting some basic ideas from CVS, so, that users will=
=20
have it easy to switch over. This counts in for centralization as well as f=
or=20
the client side commandline use.
If you still want a decentralized approach, you'd be better with SVK (which=
is=20
based on SVN API).
> * Subversion is 120,000+ lines of code PLUS all the APR and neon
> stuff clocking in at another 350,000 lines of code, versus
> 10,000 lines of python for Mercurial. Python runs everywhere,
> even on Windows: portability was essentially free.
as said above, when you don't like it. don't use it. but don't blame others=
=20
about that you feel so bad in using it.
I (in my case) don't like CVS, but I (usually) don't blame it publically in=
a=20
way you do (that is: somewhat "mediocre").
> * Configuring an already-fun-to-configure Apache setup to plonk an
> SVN server in on top.
you don't need Apache to provide access to SVN repositories.
Think about svn:// and svn+ssh://. Simply RTFM.
> * Slow slow slow slow updates, especially for large repos or
> continent-spanning net connections: looks like SVN still checks
> every file in your repo against the server's version every time
> you do an update. So, I've changed my mind: this is probably my
> biggest gripe. I have to wait about 3 minutes to get a repo
> based in New Mexico updated, even if there's no changes (I'm in
> California.) Again: what did they add changesets in for?
> Changesets that aren't really changesets are kind of lame.
This "performance issue" is well known by the svn devs and got *partly* fix=
ed=20
at the time KDE were about to switch over from CVS to SVN.
I'd recomment you to join #svn and/or #svn-devel at OPN if you have some go=
od=20
(meaning: not "lame") ideas and proposals on how to improve it.
Doing so could also change your future experience when using svn after havi=
ng=20
these improvements being implemented :-P
> * Plus, I hate that 'svn update' updates the current directory and
> it's subdirectories, and not the whole repository, but that's a
> personal thing.
This is just like CVS did, and I personally don't find this behavior that=20
"hate"-full, in fact, it even shouldn't affect upper-level directories. But=
=20
this is just a matter of policy. If you like to change that, write your=20
little script that finds the local root of your working copy and does the s=
vn=20
update from there.
Obviousely, you like the other policy, then add e.g. the following=20
into your ~/.bashrc:
function svnup() {
pushd . &> /dev/null
while [ -d "../.svn" ]; do
cd ..
done
svn update
popd &> /dev/null
}
Best regards,
Christian Parpart.
|
|
From: Nicholas N. <nj...@cs...> - 2005-10-27 14:52:05
|
On Thu, 27 Oct 2005, Tom Hughes wrote: > That said I still say it's easier just to install it - it's what I do > all the time, configure with --prefix pointing at a temporary area and > do a make install and run the installed version. I like the in-place builds because it's quicker to "make" than "make install". N |
|
From: Tom H. <to...@co...> - 2005-10-27 10:57:46
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> I just start to use valgrind from scratch and I met a problem when I set
> VALGRIND_LIB per README_DEVELOPERS as follows. Maybe someone of you could
> clarify for me. Thanks in advance.
>
> At the fifth line of README_DEVELOPERS, it is said that "run
> coregrind/valgrind with the VALGRIND_LIB environment variable set, where <dir>
> is the root of the source tree".
>
> I set VALGRIND_LIB like this,
> [qiyao@localhost valgrind]$ export VALGRIND_LIB=/home/qiyao/valgrind
> and run valgrind like this,
> [qiyao@localhost valgrind]$ coregrind/valgrind
> valgrind: failed to start tool 'memcheck': Permission denied
I just read README_DEVELOPERS again and you haven't actually done what
it said - you are supposed to point VALGRIND_LIB at the .in_place
directory. I've just tried that and it seems to work for me.
That said I still say it's easier just to install it - it's what I do
all the time, configure with --prefix pointing at a temporary area and
do a make install and run the installed version.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-10-27 10:52:37
|
In message <436...@cn...>
Yao Qi <qiy...@cn...> wrote:
> I just start to use valgrind from scratch and I met a problem when I set
> VALGRIND_LIB per README_DEVELOPERS as follows. Maybe someone of you could
> clarify for me. Thanks in advance.
>
> At the fifth line of README_DEVELOPERS, it is said that "run
> coregrind/valgrind with the VALGRIND_LIB environment variable set, where <dir>
> is the root of the source tree".
Why not just install it properly? Then you won't have to muck around
with such internal details...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Yao Qi <qiy...@cn...> - 2005-10-27 10:15:58
|
Hi, valgrind-developers,
I just start to use valgrind from scratch and I met a problem when I set
VALGRIND_LIB per README_DEVELOPERS as follows. Maybe someone of you could
clarify for me. Thanks in advance.
At the fifth line of README_DEVELOPERS, it is said that "run
coregrind/valgrind with the VALGRIND_LIB environment variable set, where <dir>
is the root of the source tree".
I set VALGRIND_LIB like this,
[qiyao@localhost valgrind]$ export VALGRIND_LIB=/home/qiyao/valgrind
and run valgrind like this,
[qiyao@localhost valgrind]$ coregrind/valgrind
valgrind: failed to start tool 'memcheck': Permission denied
I strace its execution and found that I evaluate the wrong value to VALGRIND_LIB,
[qiyao@localhost valgrind]$ strace coregrind/valgrind
......
execve("/home/qiyao/valgrind/memcheck", ["coregrind/valgrind"], [/* 24 vars */]) = -1
EACCES (Permission denied)
execve failed since /home/qiyao/valgrind/memcheck is just a *directory* instead of
an executable, so I reset VALGRIND_LIB like this,
[qiyao@localhost valgrind]$ export VALGRIND_LIB=/home/qiyao/valgrind/memcheck
and ./coregrind/valgrind works.
My rough idea to it is that either README_DEVELOPERS of this part is ambiguous or
there is a 'bug' in coregrind/launcher.c not to interpret VALGRIND_LIB very well.
140 toolfile = malloc(strlen(valgrind_lib) + strlen(toolname) + 2);
141 if (toolfile == NULL)
142 barf("malloc of toolfile failed.");
143 sprintf(toolfile, "%s/%s", valgrind_lib, toolname);
I am thinking of whether there is any solution for this in source code side? Would
anyone like to take a look? Any suggestions and comments are highly appreciated!
--
Regards, Yao
Yao Qi
|
|
From: Dirk M. <dm...@gm...> - 2005-10-27 07:06:57
|
On Wednesday 26 October 2005 22:58, Robert Walsh wrote: > * There's the BerkeleyDB flakiness thing. Plus having to > _manually_ upgrade the DB whenever the BerkeleyDB version > changes. it has a FSFS backend which doesn't have all those problems (plus is much faster) > * Configuring an already-fun-to-configure Apache setup to plonk an > SVN server in on top. then don't use subversion over apache - its slower than anything else anyway. > * Slow slow slow slow updates, especially for large repos or > continent-spanning net connections: looks like SVN still checks > every file in your repo against the server's version every time > you do an update. actually it doesn't. but it verifies integrity of your local files first. so if you have a slow disk / bad filesystem, it can take very long time before actually connecting to the remote server. Dirk |
|
From: Bryan O'S. <bo...@se...> - 2005-10-27 03:57:32
|
On Wed, 2005-10-26 at 16:21 -0500, Nicholas Nethercote wrote: > Have you heard of Bazaar-NG? I haven't used it > but it looks interesting. http://www.bazaar-ng.org/ It's quite similar to Mercurial, but slower. <b |
|
From: <js...@ac...> - 2005-10-27 02:57:45
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-10-27 03:30:00 BST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 201 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 200 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 27 03:41:48 2005 --- new.short Thu Oct 27 03:57:37 2005 *************** *** 10,12 **** ! == 200 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) --- 10,12 ---- ! == 201 tests, 2 stderr failures, 0 stdout failures ================= none/tests/faultstatus (stderr) |
|
From: <js...@ac...> - 2005-10-27 02:44:42
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-10-27 04:40:00 CEST Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 170 tests, 20 stderr failures, 2 stdout failures ================= memcheck/tests/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) cachegrind/tests/chdir (stderr) cachegrind/tests/dlclose (stderr) massif/tests/toobig-allocs (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/fdleak_ipv4 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2005-10-27 02:40:24
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-10-27 03:30:03 BST 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 == 203 tests, 11 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/nanoleak_supp (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/x86/int (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 == 202 tests, 13 stderr failures, 6 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stdout) memcheck/tests/stack_changes (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/map_unmap (stdout) none/tests/map_unmap (stderr) none/tests/mremap2 (stdout) none/tests/sigstackgrowth (stdout) none/tests/sigstackgrowth (stderr) none/tests/stackgrowth (stdout) none/tests/stackgrowth (stderr) none/tests/x86/cpuid (stdout) none/tests/x86/cpuid (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 27 03:35:07 2005 --- new.short Thu Oct 27 03:40:20 2005 *************** *** 8,15 **** ! == 202 tests, 13 stderr failures, 6 stdout failures ================= memcheck/tests/leak-tree (stderr) ! memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) - memcheck/tests/stack_changes (stdout) - memcheck/tests/stack_changes (stderr) memcheck/tests/weirdioctl (stderr) --- 8,13 ---- ! == 203 tests, 11 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) ! memcheck/tests/nanoleak_supp (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/weirdioctl (stderr) *************** *** 25,28 **** none/tests/stackgrowth (stderr) - none/tests/x86/cpuid (stdout) - none/tests/x86/cpuid (stderr) none/tests/x86/int (stderr) --- 23,24 ---- |
|
From: Tom H. <th...@cy...> - 2005-10-27 02:27:52
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-10-27 03:15:03 BST 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 == 202 tests, 16 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) none/tests/x86/yield (stdout) ================================================= == 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 == 201 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/mempool (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) none/tests/faultstatus (stderr) none/tests/x86/int (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 27 03:21:19 2005 --- new.short Thu Oct 27 03:27:37 2005 *************** *** 8,10 **** ! == 201 tests, 16 stderr failures, 0 stdout failures ================= memcheck/tests/addressable (stderr) --- 8,10 ---- ! == 202 tests, 16 stderr failures, 1 stdout failure ================= memcheck/tests/addressable (stderr) *************** *** 25,26 **** --- 25,27 ---- none/tests/x86/int (stderr) + none/tests/x86/yield (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-27 02:21:05
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-10-27 03:10:06 BST 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 == 177 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 176 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 27 03:16:57 2005 --- new.short Thu Oct 27 03:20:58 2005 *************** *** 8,10 **** ! == 176 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 177 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-27 02:17:47
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-10-27 03:05:04 BST 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 == 177 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == 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 == 176 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/mremap2 (stdout) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 27 03:12:16 2005 --- new.short Thu Oct 27 03:17:41 2005 *************** *** 8,10 **** ! == 176 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 177 tests, 7 stderr failures, 2 stdout failures ================= memcheck/tests/sigprocmask (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-27 02:13:22
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-10-27 03:00:03 BST 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 == 177 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (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 == 176 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/sigprocmask (stderr) memcheck/tests/strchr (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/xml1 (stderr) none/tests/as_mmap (stderr) none/tests/as_shm (stdout) none/tests/as_shm (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_fcntl (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Oct 27 03:04:36 2005 --- new.short Thu Oct 27 03:13:14 2005 *************** *** 8,10 **** ! == 176 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/sigprocmask (stderr) --- 8,10 ---- ! == 177 tests, 8 stderr failures, 1 stdout failure ================= memcheck/tests/sigprocmask (stderr) |
|
From: Julian S. <js...@ac...> - 2005-10-27 01:36:25
|
Fixed. J On Wednesday 26 October 2005 21:15, Robert Walsh wrote: > I'm seeing this: > > $ svn update > svn: Berkeley DB error while opening environment for filesystem > /home/svn/repos/valgrind/db: DB_RUNRECOVERY: Fatal error, run database > recovery > svn: bdb: PANIC: fatal region error detected; run recovery > > Subversion sucks. Mercurial rules, OK. > > Regards, > Robert. |