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
(11) |
2
(13) |
3
(7) |
|
4
(9) |
5
(23) |
6
(19) |
7
(18) |
8
(2) |
9
(7) |
10
(21) |
|
11
(13) |
12
|
13
(8) |
14
(17) |
15
(19) |
16
(25) |
17
(43) |
|
18
(22) |
19
(12) |
20
(19) |
21
(12) |
22
(9) |
23
(12) |
24
(5) |
|
25
(16) |
26
(25) |
27
(24) |
28
(19) |
29
(26) |
30
(25) |
31
(6) |
|
From: Iwona S. <isa...@lb...> - 2004-07-23 19:51:41
|
Hi, I installed Valgrind 2.1.1 on our cluster and I had to rebuild it couple times because a guy I built it for, kept asking me to increase VG_N_RWLOCKS. At some point he suggested that it should be an environmental variable for a user to set. I tried to be a good citizen and following a link from http://valgrind.kde.org/bugs.html I went to the Bugzilla page and got myself an account although it looked like a KDE Bugzilla. So then I tried to file a suggestion, but one of the first questions was "Which version of KDE do you use". I don't. There was nothing about valgrind that I could find.... So I am sending just this e-mail although the page says it's a BAD thing to do. Confused..... Iwona Sakrejda |
|
From: Kingsley G. M. Jr. <ch...@na...> - 2004-07-23 19:37:46
|
On 07/22/04 17:15, Jeremy Fitzhardinge wrote: > On Thu, 2004-07-22 at 16:57 -0700, Kingsley G. > Morse Jr. wrote: > > Thanks for the reply. > > > > It inspired me to research with Google. > > > > On 07/21/04 16:23, Jeremy Fitzhardinge wrote: > > > On Wed, 2004-07-21 at 13:26 -0700, Kingsley > > > G. Morse Jr. wrote: > > > > 3fff7000-40000000 rwxp ffff8000 00:00 > > > > 0 > > > > > > Ah, are you using a 1G:3G user:kernel > > > address space split? > > > > How can I check? > > Well, it's a kernel build option, so look there > first. If not dmesg probably has a clue. Yes, and, if I recall correctly, I found through Google that there was evidently a patch for kernel 2.4.(23?) that added it as a configuration option. However, unless I overlooked it, neither "make xconfig" or "dmesg" revealed such an option for my 2.4.19-aa kernel. <sigh> Cheers, Kingsley -- |
|
From: Nicholas N. <nj...@ca...> - 2004-07-23 11:46:55
|
On Fri, 23 Jul 2004, Tom Hughes wrote: >> .global VG_(helper_CPUID) >> VG_(helper_CPUID): >> push %ebp >> movl %esp,%ebp >> ... >> lea 2*4(%ebp),%eax /* &edx */ > > But EBP is pointing at the stack by then, not the base block, so the > call to VG_(helperc_CPUID) winds up updating the stacked registers > which are then popped again. I am stupid. Thanks, Tom. N |
|
From: Tom H. <th...@cy...> - 2004-07-23 11:32:21
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> Either VG_(helper_CPUID) is broken, or I'm not clever enough to
> understand it... it looks like this:
>
> .global VG_(helper_CPUID)
> VG_(helper_CPUID):
> push %ebp
> movl %esp,%ebp
> pushl %eax
> pushl %ebx
> pushl %ecx
> pushl %edx
> pushl %esi
> pushl %edi
> pushf
Note this bit, and what it does to ebp...
> lea 2*4(%ebp),%eax /* &edx */
> pushl %eax
> addl $4,%eax /* &ecx */
> pushl %eax
> addl $4,%eax /* &ebx */
> pushl %eax
> addl $4,%eax /* &eax */
> pushl %eax
> pushl (%eax) /* eax */
>
> call VG_(helperc_CPUID)
> addl $20,%esp
>
> The relevant part of the baseBlock is initialised like this:
[ snipped ]
> So, AFAICT, VG_(helper_CPUID) starts by pushing &EDX (ie. baseBlock+8 --
> from the "lea 2*4(%ebp)"), then &EBX, then &ESP, then &EBP. Not &EDX,
> &ECX, &EBX, &EAX as it claims.
But EBP is pointing at the stack by then, not the base block, so the
call to VG_(helperc_CPUID) winds up updating the stacked registers
which are then popped again.
> But it seems to be working, eg. in Cachegrind, so I must be
> misunderstanding. Can anyone explain?
The cache detection in cachgrind doesn't go through the helper anyway
as it isn't emulated - that just call VG_(cpuid) directly.
The helper is only used when CPUID is encountered in the target
program.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-23 11:00:09
|
Hi,
Either VG_(helper_CPUID) is broken, or I'm not clever enough to understand
it... it looks like this:
.global VG_(helper_CPUID)
VG_(helper_CPUID):
push %ebp
movl %esp,%ebp
pushl %eax
pushl %ebx
pushl %ecx
pushl %edx
pushl %esi
pushl %edi
pushf
lea 2*4(%ebp),%eax /* &edx */
pushl %eax
addl $4,%eax /* &ecx */
pushl %eax
addl $4,%eax /* &ebx */
pushl %eax
addl $4,%eax /* &eax */
pushl %eax
pushl (%eax) /* eax */
call VG_(helperc_CPUID)
addl $20,%esp
The relevant part of the baseBlock is initialised like this:
static void init_baseBlock ( Addr client_eip, Addr esp_at_startup )
{
/* WORD offsets in this column */
/* 0 */ VGOFF_(m_eax) = alloc_BaB_1_set(0);
/* 1 */ VGOFF_(m_ecx) = alloc_BaB_1_set(0);
/* 2 */ VGOFF_(m_edx) = alloc_BaB_1_set(0);
/* 3 */ VGOFF_(m_ebx) = alloc_BaB_1_set(0);
/* 4 */ VGOFF_(m_esp) = alloc_BaB_1_set(esp_at_startup);
/* 5 */ VGOFF_(m_ebp) = alloc_BaB_1_set(0);
/* 6 */ VGOFF_(m_esi) = alloc_BaB_1_set(0);
/* 7 */ VGOFF_(m_edi) = alloc_BaB_1_set(0);
/* 8 */ VGOFF_(m_eflags) = alloc_BaB_1_set(0)
So, AFAICT, VG_(helper_CPUID) starts by pushing &EDX (ie. baseBlock+8 --
from the "lea 2*4(%ebp)"), then &EBX, then &ESP, then &EBP. Not &EDX,
&ECX, &EBX, &EAX as it claims.
But it seems to be working, eg. in Cachegrind, so I must be
misunderstanding. Can anyone explain?
Thanks.
N
|
|
From: <js...@ac...> - 2004-07-23 03:04:41
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-23 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 168 tests, 4 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-23 02:25:13
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-23 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 7 stderr failures, 1 stdout failure ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-23 02:19:48
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-23 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 8 stderr failures, 0 stdout failures ================= corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_socketpair (stderr) corecheck/tests/pth_cancel2 (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-23 02:13:20
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-23 03:10:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 4 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-23 02:08:12
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-23 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 6 stderr failures, 1 stdout failure ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-23 02:07:31
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-23 03:00:01 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow rcrl: valgrind ./rcrl readline1: valgrind ./readline1 resolv: valgrind ./resolv rlimit_nofile: valgrind ./rlimit_nofile seg_override: valgrind ./seg_override sem: valgrind ./sem semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 173 tests, 0 stderr failures, 0 stdout failures ================= |
|
From: Jeremy F. <je...@go...> - 2004-07-23 00:18:21
|
On Thu, 2004-07-22 at 16:57 -0700, Kingsley G. Morse Jr. wrote: > Thanks for the reply. > > It inspired me to research with Google. > > On 07/21/04 16:23, Jeremy Fitzhardinge wrote: > > On Wed, 2004-07-21 at 13:26 -0700, Kingsley G. Morse Jr. wrote: > > > 3fff7000-40000000 rwxp ffff8000 00:00 0 > > > > Ah, are you using a 1G:3G user:kernel address space split? > > How can I check? Well, it's a kernel build option, so look there first. If not dmesg probably has a clue. But the fact that your process stack top is at 40000000 is a pretty good hint too. J |