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: Nicholas N. <nj...@ca...> - 2004-07-14 21:35:32
|
On Wed, 14 Jul 2004, Jeremy Fitzhardinge wrote: > Looks reasonable to me. It would be really nice to fix the constant > address for info.map_base in stage1. Hm, with this arrangement, info. > mapbase for stage2 is essentially where the brk used to be - after the > main executable. Stage1 can work out where it is just by looking at > stage2's ELF mappings. How do you do that? Do the mappings say how big the executable is? What about stage2's stack? It has one, it's small, but system malloc() is called a few times at startup. >> It's still short of my ultimate goal of a totally flexible barrier between >> client and non-client memory, although it's a step in the right direction. >> One thing preventing me from working on that is that I currently can't work out >> how to move the client's stack away from 0xafffffff -- I change what look like >> the right values in setup_client_stack() but keep getting seg faults. Am I >> missing something important? > > What's segfaulting? Valgrind itself, or the client code? > > The client's stack location is variable anyway, so doesn't it depend on > where everything else goes? Where are you trying to move it to? I tried the attached patch (against HEAD, not my patched version) to move the stack to 0x8000000, below the main executable. Valgrind segfaults very shortly after, within setup_client_stack, during the stack copying -- at the first call to copy_str(). N |
|
From: Jeremy F. <je...@go...> - 2004-07-14 21:18:10
|
On Wed, 2004-07-14 at 21:55 +0100, Nicholas Nethercote wrote:
> On Wed, 14 Jul 2004, Jeremy Fitzhardinge wrote:
>
> > As Tom said, pretty much impossible. But we could set up a piece of
> > client-side code to throw the exception (as generated by the c++
> > compiler), and have Valgrind get the client to jump into it.
>
> But won't that break if the client hasn't been compiled with GCC, due to
> the different compiler implementations of exceptions?
Yes, but so will all the intercepts since the other compiler will
(probably) use a different mangling scheme.
To support multiple compilers, we'd need to:
1. have intercepts for all the new/delete variants for each
compiler
2. compile an exception-throwing stub with each compiler
In principle, if two compilers use the same mangling scheme, they
implement the same ABI and therefore have the exception-throwing
mechanism. In practice, I think it probably comes down to luck.
J
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 20:55:46
|
On Wed, 14 Jul 2004, Jeremy Fitzhardinge wrote: > As Tom said, pretty much impossible. But we could set up a piece of > client-side code to throw the exception (as generated by the c++ > compiler), and have Valgrind get the client to jump into it. But won't that break if the client hasn't been compiled with GCC, due to the different compiler implementations of exceptions? N |
|
From: Jeremy F. <je...@go...> - 2004-07-14 20:32:30
|
On Wed, 2004-07-14 at 18:40 +0100, Nicholas Nethercote wrote: > Hi, > > I've done some more reworking of the memory layout. Log is below, and the > diff is available, as is vg_main.c since the diff for it is not easy to > read (things have been moved a bit), at: > > www.cl.cam.ac.uk/~njn25/diff.mem2 > www.cl.cam.ac.uk/~njn25/vg_main.c > > I'd like to commit this, please let me know if there are any problems with > it. Looks reasonable to me. It would be really nice to fix the constant address for info.map_base in stage1. Hm, with this arrangement, info. mapbase for stage2 is essentially where the brk used to be - after the main executable. Stage1 can work out where it is just by looking at stage2's ELF mappings. This means we could link multiple stage2's for different address space configurations, and have stage1 pick the appropriate one. > It's still short of my ultimate goal of a totally flexible barrier between > client and non-client memory, although it's a step in the right direction. > One thing preventing me from working on that is that I currently can't work out > how to move the client's stack away from 0xafffffff -- I change what look like > the right values in setup_client_stack() but keep getting seg faults. Am I > missing something important? What's segfaulting? Valgrind itself, or the client code? The client's stack location is variable anyway, so doesn't it depend on where everything else goes? Where are you trying to move it to? J |
|
From: Jeremy F. <je...@go...> - 2004-07-14 20:01:42
|
On Wed, 2004-07-14 at 14:04 +0100, Nicholas Nethercote wrote: > Hi, > > I recently changed Valgrind so that the malloc-replacing tools return NULL > if they can't satisfy the request, rather than dying with an assertion > failure. > > This is good for malloc(), but not the right behaviour for C++'s operator > new and operator new[]. (It the right behaviour for the 'nothrow' > versions of new and new[]). > > This is a problem. Does anyone have any suggestions? How hard would it > be to throw an exception from Valgrind's C code? As Tom said, pretty much impossible. But we could set up a piece of client-side code to throw the exception (as generated by the c++ compiler), and have Valgrind get the client to jump into it. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 17:40:32
|
Hi, I've done some more reworking of the memory layout. Log is below, and the diff is available, as is vg_main.c since the diff for it is not easy to read (things have been moved a bit), at: www.cl.cam.ac.uk/~njn25/diff.mem2 www.cl.cam.ac.uk/~njn25/vg_main.c I'd like to commit this, please let me know if there are any problems with it. It's still short of my ultimate goal of a totally flexible barrier between client and non-client memory, although it's a step in the right direction. One thing preventing me from working on that is that I currently can't work out how to move the client's stack away from 0xafffffff -- I change what look like the right values in setup_client_stack() but keep getting seg faults. Am I missing something important? Thanks. N ps: I tried sending the files as attachments, but got the "too big, waiting for moderator approval" message... so another copy of this message, with attachments, will arrive in the next day or two -- please ignore. Merged Valgrind's heap and stack. This has two main advantages: 1. It simplifies various things a bit. 2. Valgrind/tools will run out of memory later than currently in many circumstances. This is good news esp. for Calltree. Some things were going in V's 128MB, and some were going in V's 128MB map segment. Now all these things are going into a single 256MB map segment. stage2 has been moved down to 0xb0000000, the start of the 256MB map segment. The .so files needed by it are placed at 0xb1000000. This required some bootstrapping at startup for memory -- we need to allocate memory to create the segments skip-list which lets us allocate memory... solution was to make the first superblock allocated a special static one. That's pretty simple and enough to get things going. Removed vg_glibc.c which wasn't doing anything anyway. Removed VG_(brk) and associated stuff, made all the things that were calling it call VG_(mmap)() instead. Removed VG_(valgrind_mmap_end) which was no longer needed. Rejigged the startup order a bit as necessary. Moved an important comment from ume.c to vg_main.c where it should be. |
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 15:38:34
|
CVS commit by nethercote:
Intercept 'nothrow' versions of delete and delete[].
M +8 -0 vg_replace_malloc.c.base 1.2
--- valgrind/coregrind/vg_replace_malloc.c.base #1.1:1.2
@@ -133,7 +133,15 @@
FREE( __builtin_delete, __builtin_delete );
FREE( _ZdlPv, __builtin_delete );
+
+// operator delete(void*, std::nothrow_t const&)
+FREE( _ZdlPvRKSt9nothrow_t, __builtin_delete );
+
FREE( __builtin_vec_delete, __builtin_vec_delete );
FREE( _ZdaPv, __builtin_vec_delete );
+// operator delete[](void*, std::nothrow_t const&)
+FREE( _ZdaPvRKSt9nothrow_t, __builtin_vec_delete );
+
+
LIBALIAS(void*, calloc, ( Int nmemb, Int size ))
{
|
|
From: Tom H. <th...@cy...> - 2004-07-14 13:47:22
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Wed, 14 Jul 2004, Tom Hughes wrote:
>
>>> This is good for malloc(), but not the right behaviour for C++'s
>>> operator new and operator new[]. (It the right behaviour for the
>>> 'nothrow' versions of new and new[]).
>>>
>>> This is a problem. Does anyone have any suggestions? How hard would
>>> it be to throw an exception from Valgrind's C code?
>>
>> To do it portably must be virtually impossible as there's no
>> standard way to implement exceptions as far as I know so different
>> compilers may do it completely differently.
>
> That's what I was afraid of. Hmm. Would it be better to abort with a
> warning if new/new[] failed? And maybe have an option that lets them
> return NULL? Silently doing the wrong thing (not throwing an
> exception) is bad.
Aborting is probably better, yes.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 13:35:02
|
On Wed, 14 Jul 2004, Tom Hughes wrote: >> This is good for malloc(), but not the right behaviour for C++'s >> operator new and operator new[]. (It the right behaviour for the >> 'nothrow' versions of new and new[]). >> >> This is a problem. Does anyone have any suggestions? How hard would >> it be to throw an exception from Valgrind's C code? > > To do it portably must be virtually impossible as there's no > standard way to implement exceptions as far as I know so different > compilers may do it completely differently. That's what I was afraid of. Hmm. Would it be better to abort with a warning if new/new[] failed? And maybe have an option that lets them return NULL? Silently doing the wrong thing (not throwing an exception) is bad. N |
|
From: Tom H. <th...@cy...> - 2004-07-14 13:11:15
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> This is good for malloc(), but not the right behaviour for C++'s
> operator new and operator new[]. (It the right behaviour for the
> 'nothrow' versions of new and new[]).
>
> This is a problem. Does anyone have any suggestions? How hard would
> it be to throw an exception from Valgrind's C code?
To do it portably must be virtually impossible as there's no
standard way to implement exceptions as far as I know so different
compilers may do it completely differently.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-14 13:04:07
|
Hi, I recently changed Valgrind so that the malloc-replacing tools return NULL if they can't satisfy the request, rather than dying with an assertion failure. This is good for malloc(), but not the right behaviour for C++'s operator new and operator new[]. (It the right behaviour for the 'nothrow' versions of new and new[]). This is a problem. Does anyone have any suggestions? How hard would it be to throw an exception from Valgrind's C code? N |
|
From: <js...@ac...> - 2004-07-14 02:57:41
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-14 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/overlap (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/pushfpopf (stderr) memcheck/tests/realloc1 (stderr) memcheck/tests/realloc2 (stderr) memcheck/tests/realloc3 (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/signal2 (stderr) memcheck/tests/supp1 (stderr) memcheck/tests/supp2 (stderr) memcheck/tests/suppfree (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/toobig-allocs (stderr) memcheck/tests/trivialleak (stderr) memcheck/tests/tronical (stderr) memcheck/tests/weirdioctl (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-07-14 02:25:02
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-14 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-14 02:19:44
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-14 03:15: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, 7 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) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-14 02:13:17
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-14 03:10:02 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-14 02:08:14
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-14 03:05: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 ================= addrcheck/tests/toobig-allocs (stderr) memcheck/tests/badfree-2trace (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-14 02:06:45
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-14 03:00:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |