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: Julian S. <js...@ac...> - 2005-10-29 12:36:31
|
It's pretty much as you see. The 3-space indent seems to be pretty good for readability. I'm pretty clueless with emacs and have always found its alternative ideas of indentation a pain, so when it's done inserting tabs and generally messing around, I reindent it by hand, getting rid of tabs and inserting spaces instead. J On Saturday 29 October 2005 08:22, Jeroen N. Witmond wrote: > Greetings, > > Are there any standards or guidelines on where to indent, and by how much, > in Valgrind's source code? Can anybody tell me how to instruct emacs to > implement these standards or guidelines? > > Thanks. > > Jeroen. > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by the JBoss Inc. > Get Certified Today * Register for a JBoss Training Course > Free Certification Exam for All Training Attendees Through End of 2005 > Visit http://www.jboss.com/services/certification for more information > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-29 07:37:27
|
Greetings, A minor point: File memcheck/mc_main.c still contains a reference to command line option --cleanup, in mc_print_debug_usage() at line 2280. (IIRC this option was removed because VEX always performs post-instrumentation cleanup.) Jeroen. |
|
From: Jeroen N. W. <jn...@xs...> - 2005-10-29 07:22:58
|
Greetings, Are there any standards or guidelines on where to indent, and by how much, in Valgrind's source code? Can anybody tell me how to instruct emacs to implement these standards or guidelines? Thanks. Jeroen. |
|
From: <js...@ac...> - 2005-10-29 02:52:16
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-10-29 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) |
|
From: <js...@ac...> - 2005-10-29 02:44:36
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-10-29 04:40:01 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-29 02:40:22
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-10-29 03:30:05 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, 12 stderr failures, 4 stdout failures ================= memcheck/tests/exitprog (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (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 == 203 tests, 11 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Oct 29 03:35:14 2005 --- new.short Sat Oct 29 03:40:17 2005 *************** *** 8,10 **** ! == 203 tests, 11 stderr failures, 4 stdout failures ================= memcheck/tests/leak-tree (stderr) --- 8,11 ---- ! == 203 tests, 12 stderr failures, 4 stdout failures ================= ! memcheck/tests/exitprog (stderr) memcheck/tests/leak-tree (stderr) |
|
From: Tom H. <th...@cy...> - 2005-10-29 02:27:50
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-10-29 03:15:03 BST 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 == 202 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) |
|
From: Tom H. <th...@cy...> - 2005-10-29 02:23:12
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-10-29 03:00:03 BST 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 == 177 tests, 8 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/fdleak_fcntl (stderr) none/tests/tls (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-29 02:21:17
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-10-29 03:10:07 BST 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 == 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) |
|
From: Tom H. <th...@cy...> - 2005-10-29 02:17:55
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-10-29 03:05:12 BST 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 == 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) |
|
From: Dirk M. <dm...@gm...> - 2005-10-28 08:20:22
|
On Thursday 27 October 2005 20:46, Robert Walsh wrote: > Not that simple. For example, one of the repos I use is in a secure > national lab. http access is all they allow through. ROTFL... its so secure that they let people *transmit unencrypted credentials* ? You made my day. Dirk |
|
From: Yao Qi <qiy...@cn...> - 2005-10-28 06:18:29
|
Tom Hughes wrote: > 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. I have tried again to export VALGRIND_LIB at .in_place directory and coregrind/valgrind works. Thank you. > > 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 just want to have a try when I read README_DEVELOPERS, and I have tried --prefix option, thanks again. > > Tom > -- Regards, Yao Yao Qi |
|
From: <js...@ac...> - 2005-10-28 02:51:21
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-10-28 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) |
|
From: <js...@ac...> - 2005-10-28 02:44:43
|
Nightly build on g5 ( YDL 4.0, ppc970 ) started at 2005-10-28 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-28 02:40:24
|
Nightly build on dunsmere ( athlon, Fedora Core 4 ) started at 2005-10-28 03:30: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 == 203 tests, 13 stderr failures, 5 stdout failures ================= memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/args (stdout) none/tests/args (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_dup2 (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 == 203 tests, 12 stderr failures, 4 stdout failures ================= memcheck/tests/badfree-2trace (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/mempool (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) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Oct 28 03:35:15 2005 --- new.short Fri Oct 28 03:40:19 2005 *************** *** 8,11 **** ! == 203 tests, 12 stderr failures, 4 stdout failures ================= ! memcheck/tests/badfree-2trace (stderr) memcheck/tests/leak-tree (stderr) --- 8,10 ---- ! == 203 tests, 13 stderr failures, 5 stdout failures ================= memcheck/tests/leak-tree (stderr) *************** *** 16,18 **** --- 15,20 ---- memcheck/tests/xml1 (stderr) + none/tests/args (stdout) + none/tests/args (stderr) none/tests/faultstatus (stderr) + none/tests/fdleak_dup2 (stderr) none/tests/map_unmap (stdout) |
|
From: Tom H. <th...@cy...> - 2005-10-28 02:28:39
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2005-10-28 03:15:03 BST 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 == 202 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) |
|
From: Tom H. <th...@cy...> - 2005-10-28 02:21:27
|
Nightly build on dellow ( x86_64, Fedora Core 4 ) started at 2005-10-28 03:10:09 BST 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 == 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) |
|
From: Tom H. <th...@cy...> - 2005-10-28 02:17:58
|
Nightly build on aston ( x86_64, Fedora Core 3 ) started at 2005-10-28 03:05:05 BST 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 == 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) |
|
From: Tom H. <th...@cy...> - 2005-10-28 02:13:18
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2005-10-28 03:00:03 BST 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 == 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) |
|
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/
|