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: 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. |
|
From: Nicholas N. <nj...@cs...> - 2005-10-26 21:21:16
|
On Wed, 26 Oct 2005, Robert Walsh wrote: > Having used SVN for a while now (on this project and on others), I can > say that I find it quite mediocre: Have you heard of Bazaar-NG? I haven't used it but it looks interesting. http://www.bazaar-ng.org/ |
|
From: Robert W. <rj...@du...> - 2005-10-26 20:58:57
|
> Git is nice, too. There is a SVN import now. > Should be quite easy to switch ;-) I should point out that Mercurial has importers for just about everything under the sun. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Robert W. <rj...@du...> - 2005-10-26 20:58:24
|
> Subversion's BerkeleyDB back-end sometimes sucks... the rest of it is=20
> 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:
* There's the BerkeleyDB flakiness thing. Plus having to
_manually_ upgrade the DB whenever the BerkeleyDB version
changes.
* 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.
* Centralized repositories are so mid-90s.
* 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.
* Configuring an already-fun-to-configure Apache setup to plonk an
SVN server in on top.
* 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.
* 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.
Regards,
Robert.
--=20
Robert Walsh
Amalgamated Durables, Inc. - "We don't make the things you buy."
Email: rj...@du...
|
|
From: Josef W. <Jos...@gm...> - 2005-10-26 20:29:27
|
On Wednesday 26 October 2005 22: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. Git is nice, too. There is a SVN import now. Should be quite easy to switch ;-) Inclusive Web-Frontend and automatic mails to this list on a "push" to a "central" repository... Josef > > Regards, > Robert. > |
|
From: Nicholas N. <nj...@cs...> - 2005-10-26 20:28:04
|
On Wed, 26 Oct 2005, 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 Same here. > Subversion sucks. Mercurial rules, OK. Subversion's BerkeleyDB back-end sometimes sucks... the rest of it is pretty good. GCC's about to switch to it from CVS.. Nick |
|
From: Robert W. <rj...@du...> - 2005-10-26 20:15:27
|
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. --=20 Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Josef W. <Jos...@gm...> - 2005-10-26 19:18:42
|
Hi,
I somehow succeeded in linking callgrind as static binary.
The first question was which information for linking
to pass via valgrind.pc? I decided to pass the load address
as separate variable (valt_load_address), and the libraries to
link. And these libraries must be installed by VG. Thus this
needs the following patch to VG SVN:
===================================================================
--- valgrind.pc.in (Revision 4967)
+++ valgrind.pc.in (Arbeitskopie)
@@ -5,11 +5,12 @@
arch=@VG_ARCH@
os=@VG_OS@
platform=@VG_PLATFORM@
+valt_load_address=@VALT_LOAD_ADDRESS@
Name: Valgrind
Description: A dynamic binary instrumentation framework
Version: @VERSION@
Requires:
-Libs:
+Libs: -L${libdir} -lcoregrind -lvex -lgcc
Cflags: -I${includedir} @ARCH_TOOL_AM_CFLAGS@
--- coregrind/Makefile.am (Revision 4968)
+++ coregrind/Makefile.am (Arbeitskopie)
@@ -6,7 +6,7 @@
default.supp: $(SUPP_FILES)
-noinst_LIBRARIES = \
+lib_LIBRARIES = \
libcoregrind.a \
libreplacemalloc_toolpreload.a
===================================================================
Problem: How and where to install libvex.a? Adding it to
coregrind/Makefile.am as "lib_LIBRARIES = ... @VEXDIR@/libvex.a"
does not work, as automake wants to build this library from
a "../VEX/libvex.c" file ?!
I decided to pass the libraries in valgrind.pc so that the
tools configure.in can check if all libraries are available at
configure time without hardcoding.
I think that libreplacemalloc_toolpreload.a should be installed,
too: an external tool may choose to overwrite malloc().
Now, when trying to run the tool, I get a panic inside of my
instrument() function:
Callgrind: the 'impossible' happened:
host/guest word size mismatch
Code:
IRBB* CLG_(instrument)( IRBB* bbIn, VexGuestLayout* layout,
IRType gWordTy, IRType hWordTy )
{
...
if (gWordTy != hWordTy) {
/* We don't currently support this case. */
VG_(tool_panic)("host/guest word size mismatch");
}
...
I probably miss something here.
The CFLAGS used to compile callgrind for x86 are
gcc ... -DVGA_x86 -DVGO_linux -I/usr/include/valgrind \
-m32 -mpreferred-stack-boundary=2 -g -O2 ...
and I of course compiled VEX on the same machine.
Help!
Josef
|
|
From: Nicholas N. <nj...@cs...> - 2005-10-26 16:18:48
|
On Wed, 26 Oct 2005, Josef Weidendorfer wrote: > Can you change "valgrind --version" to dump the version string > to stdout again, please? Patch attached. Done, thanks for the patch. I added a regression test so this problem should not return. Nick |
|
From: <sv...@va...> - 2005-10-26 16:17:51
|
Author: njn
Date: 2005-10-26 17:17:46 +0100 (Wed, 26 Oct 2005)
New Revision: 4969
Log:
The version string from --version was being printed to stderr. This
commit fixes it to print to stdout. I added a regression test for this.
Added:
trunk/none/tests/cmdline0.stderr.exp
trunk/none/tests/cmdline0.stdout.exp
trunk/none/tests/cmdline0.vgtest
trunk/none/tests/filter_cmdline0
Modified:
trunk/coregrind/m_main.c
trunk/none/tests/Makefile.am
Modified: trunk/coregrind/m_main.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/coregrind/m_main.c 2005-10-26 12:21:16 UTC (rev 4968)
+++ trunk/coregrind/m_main.c 2005-10-26 16:17:46 UTC (rev 4969)
@@ -998,6 +998,8 @@
vg_assert(str);
=20
if (VG_STREQ(str, "--version")) {
+ // Ensure the version string goes to stdout
+ VG_(clo_log_fd) =3D 1;
VG_(printf)("valgrind-" VERSION "\n");
VG_(exit)(0);
=20
Modified: trunk/none/tests/Makefile.am
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/Makefile.am 2005-10-26 12:21:16 UTC (rev 4968)
+++ trunk/none/tests/Makefile.am 2005-10-26 16:17:46 UTC (rev 4969)
@@ -2,7 +2,8 @@
DIST_SUBDIRS =3D ${VG_ARCH_ALL} .
=20
noinst_SCRIPTS =3D \
- filter_as_mmap filter_fdleak filter_none_discards filter_stderr
+ filter_as_mmap filter_cmdline0 \
+ filter_fdleak filter_none_discards filter_stderr
=20
EXTRA_DIST =3D $(noinst_SCRIPTS) \
ansi.stderr.exp ansi.vgtest \
@@ -13,6 +14,7 @@
bitfield1.stderr.exp bitfield1.vgtest \
blockfault.vgtest blockfault.stderr.exp blockfault.stdout.exp \
closeall.stderr.exp closeall.vgtest \
+ cmdline0.stderr.exp cmdline0.stdout.exp cmdline0.vgtest \
cmdline1.stderr.exp cmdline1.stdout.exp cmdline1.vgtest \
cmdline2.stderr.exp cmdline2.stdout.exp cmdline2.vgtest \
cmdline3.stderr.exp cmdline3.vgtest \
Added: trunk/none/tests/cmdline0.stderr.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Added: trunk/none/tests/cmdline0.stdout.exp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/cmdline0.stdout.exp 2005-10-26 12:21:16 UTC (rev 496=
8)
+++ trunk/none/tests/cmdline0.stdout.exp 2005-10-26 16:17:46 UTC (rev 496=
9)
@@ -0,0 +1 @@
+valgrind-XXX
Added: trunk/none/tests/cmdline0.vgtest
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/cmdline0.vgtest 2005-10-26 12:21:16 UTC (rev 4968)
+++ trunk/none/tests/cmdline0.vgtest 2005-10-26 16:17:46 UTC (rev 4969)
@@ -0,0 +1,2 @@
+vgopts: --version
+stdout_filter: filter_cmdline0
Added: trunk/none/tests/filter_cmdline0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/none/tests/filter_cmdline0 2005-10-26 12:21:16 UTC (rev 4968)
+++ trunk/none/tests/filter_cmdline0 2005-10-26 16:17:46 UTC (rev 4969)
@@ -0,0 +1,3 @@
+#! /bin/sh
+
+sed "s/^valgrind-.*/valgrind-XXX/g"
Property changes on: trunk/none/tests/filter_cmdline0
___________________________________________________________________
Name: svn:executable
+ *
|
|
From: Dirk M. <dm...@gm...> - 2005-10-26 15:09:05
|
On Wednesday 26 October 2005 16:46, Tom Hughes wrote: > Obviously we could do one without but I don't see the point of a beta > if it is going to be radically different from the final product. Well, this way we could test the Aspacemgr changes independently :) Dirk |
|
From: Josef W. <Jos...@gm...> - 2005-10-26 15:01:00
|
Hi,
I invested quite some time in looking why my configure script does
not detect the version of Valgrind SVN correctly. I use
vg_version=`$prefix/bin/valgrind --version`
case "${vg_version}" in
valgrind-3.1.*)
...
This worked since ever. But VG 3.1.SVN now dumps the
version to stderr, thus vg_version stays empty.
Can you change "valgrind --version" to dump the version string
to stdout again, please? Patch attached.
Josef
--- coregrind/m_main.c (Revision 4968)
+++ coregrind/m_main.c (Arbeitskopie)
@@ -998,6 +998,8 @@
vg_assert(str);
if (VG_STREQ(str, "--version")) {
+ // Ensure the version string goes to stdout
+ VG_(clo_log_fd) = 1;
VG_(printf)("valgrind-" VERSION "\n");
VG_(exit)(0);
|
|
From: Tom H. <to...@co...> - 2005-10-26 14:46:34
|
In message <200...@gm...>
Dirk Mueller <dm...@gm...> wrote:
> On Wednesday 26 October 2005 13:58, Tom Hughes wrote:
>
>> For 3.1.0 we wanted to have the proper biarch support in, and that is
>> currently blocked on a couple of things.
>
> Does that mean that we're not even able to do a beta release?
Not with biarch support, no.
Obviously we could do one without but I don't see the point of a beta
if it is going to be radically different from the final product.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Dirk M. <dm...@gm...> - 2005-10-26 14:40:31
|
On Wednesday 26 October 2005 13:58, Tom Hughes wrote: > For 3.1.0 we wanted to have the proper biarch support in, and that is > currently blocked on a couple of things. Does that mean that we're not even able to do a beta release? Dirk |