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
(22) |
2
(19) |
3
(8) |
4
(34) |
5
(14) |
6
(14) |
|
7
(12) |
8
(15) |
9
(15) |
10
(10) |
11
(10) |
12
(28) |
13
(11) |
|
14
(22) |
15
(29) |
16
(20) |
17
(15) |
18
(39) |
19
(11) |
20
(12) |
|
21
(8) |
22
(9) |
23
(8) |
24
(10) |
25
(9) |
26
(7) |
27
(7) |
|
28
(6) |
29
(6) |
30
(11) |
|
|
|
|
|
From: Ashley P. <as...@qu...> - 2004-11-22 16:35:12
|
On Mon, 2004-11-22 at 16:12 +0000, Nicholas Nethercote wrote: > On Sat, 20 Nov 2004, Julian Seward wrote: > > > I never understood why we care about statically linked executables. > > My view is they are a special-case anomaly which it is not worth supporting. > > No developer doing day-to-day hacking is going to continually be building > > statically linked executables (are they?) > > I don't think that's true. I remember at least one person saying "thank > you thank you thank you" when support for this was added. I to write and maintain software that doesn't really like static executables and there are a surprising number of people who use them. Ashley, |
|
From: Nicholas N. <nj...@ca...> - 2004-11-22 16:13:06
|
On Sat, 20 Nov 2004, Julian Seward wrote: > I never understood why we care about statically linked executables. > My view is they are a special-case anomaly which it is not worth supporting. > No developer doing day-to-day hacking is going to continually be building > statically linked executables (are they?) I don't think that's true. I remember at least one person saying "thank you thank you thank you" when support for this was added. |
|
From: Nicholas N. <nj...@ca...> - 2004-11-22 16:06:35
|
On Fri, 19 Nov 2004, Jeremy Fitzhardinge wrote: > Having our own libc is definitely not a good idea, but we haven't gone > to much effort to replace it yet. glibc makes it hard to intercept brk > directly, but it is possible to replace malloc/calloc/realloc/etc and be > reasonably sure of avoiding the use of brk (particularly if you get the > kernel to enforce it). I don't think "reasonably sure" is good enough. > But using system libraries wasn't the only reason to disentangle > ourselves from the dynamic linker. The dynamic linker itself is 1) very > GNU/glibc-specific 2) has changed a lot over the last few years, and > doesn't seem like stopping, and so 3) depending on it in detail is going > to continue to be a maintenance and portability problem. We're stuck > with having to deal with it for the purposes of interception, but it > would be nice to be independent of it for the basic functioning of > Valgrind. How does FV provide that independence? > A bounds-limit test for each memory access isn't that expensive, and in > 64-bit address spaces, you can make the client address space a power of > 2 in size, which simplifies the test. You could also use a v. large > redzone to make hits much more unlikely. The segment test is nice > because it actually is free, but explicit testing probably isn't that > expensive, particularly if the codegen can remove redundant tests, and > schedule the tests it does generate appropriately. I'm not very keen on features that require greatly different mechanisms on different architectures. > Well, hm. If Valgrind is sharing ld.so with the client, then they're > not really separate programs at all. If the client screws up the > dynamic linker, Valgrind could get hit and crash without being able to > report on it at all. Julian made a good point about distinguishing between read-only and read-write memory with Memcheck/Addrcheck. Also, my proposal doesn't preclude Valgrind from keeping it's own copy of ld.so, as is done now. >> - Code size. FV added a lot of code. Especially keeping track of all the >> mapped segments (and there are still several nasty bugs in there). > > You know, I'm really not sure that it did. I'll agree that the skiplist > code has been more subtly broken for longer than it should have been, > but as a generic data structure we should be able to get good use from > it. And really, the mapped segment code is there to replace the old > stuff which kept reading /proc/self/map; that was getting to be a pretty > significant bottleneck and was plain ugly (ie, the mapped segment stuff > would have been needed anyway, regardless of FV). Ok, the segment list could be kept with my proposal. The implementation needs overhauling though. The big problem is that each segment is a range, but the skip-list's interface only allows for it to be (easily) treated as a key-value table, rather than a range-value table. And so various hoops have to be jumped through to account for that -- for example, SkipList_Find's non-intuitive behaviour that it returns the matching node, or the previous one if there's no match, or NULL if the key is below the first on the list; if you want to find the segment that contains an address, you have to call SkipList_Find and then look at the returned node to see if the searched for address is within it. This is crazy. I rewrote the skip-list the other day to provide a much cleaner interface that avoids these strange behaviours. I haven't managed to integrate it yet, however, because several of the places that use the skip-list functions do so in such a difficult-to-understand way that I was unable to determine for a number of them if they were buggy, or doing something extremely subtle. There's also a nasty 7-function cycle in the memory allocation stuff which Julian stumbled across; in obscure circumstances you can get an infinite loop when the program allocates memory, so Valgrind creates a new skip-list node, which can require allocating a new superblock, which requires another skip-list node, etc. (Or something like that, I can't remember the exact details now.) The segment list should not use the same allocator as the rest of Valgrind. > The other large code change is the syscall handing stuff, which is > independent of FV. Sure. > I dunno. Valgrind is a lot more complex now, but it does do a lot more > stuff. I don't think we're going to return to the halcyon days of 1.0 > simplicity and still manage to keep the functionality. Of course not. My proposal doesn't reduce the functionality at all, except for the strict client/Valgrind separation. What I object to is the use of techniques that are clever but fragile. Also, doing work that the kernel could do for us (ie. deciding where to put maps) is not good. >> - Robustness. FV is generally more fragile; there are more things to >> get right, and the consequences are bad if they are not right. IMHO >> we get more random seg fault problems now. A lot have been cleaned up >> (it was really bad at first), but they still happen. > > Yes, but I think that comes with the "doing more stuff". 1.0 would just > fail outright on a lot of programs. 2.x tries to run them, and > generally (but not always) succeeds. And again, I don't think this is > strictly an FV issue. I agree with that statement for the ProxyLWP stuff -- yes, it's more complicated, but handles more programs. As for FV... apart from statically linked binaries, what kinds of programs can we run with it that we could not run without? My argument is that FV reduced the number of programs Valgrind could run, since you need a standard-ish kernel, no virtual memory limit, enough swap space if you have a non-overcommitting kernel. And also it runs out of memory earlier than previously due to the address layout inflexibilities. > Can you explain? What do you mean by "embedded developers"? The Like Julian said, people writing programs that have strict memory limits. A couple of people have recently asked for a --mem-limit option, because they cannot use ulimit to restrict memory sizes. >> V has dropped from #6 to #72 highest-rated project at Freshmeat.net over >> the last year or so; I think the reason for this is that V's "it just >> works" characteristic has been diminished, due to the robustness and >> inflexibility problems. > > Um, do you have anything to support that? I think the ranking is > dropping because V is not new anymore, and people are taking it for > granted. Are we seeing an increase in bug reports disproportionate to > the number of users? Of course I can't prove it. But I do think that Valgrind crashes with random, unexplained seg faults more than it used to. There are a quite a lot of bugs in Bugzilla like that. Some of them have been dealt with since I made FV more strict about checking the results of mmap(), etc, but we still get them. > I'd still like to be able to use C++ internally. It could certainly be useful in places; some places where tools augment core data structures with extra info cry out for inheritance. But I'm happy to not use C++ if it causes too many problems. It's also a slippery slope if you try to restrict yourself to only a subset of the language. > And I really think that the direct mapped shadow memory makes the most > sense for 64-bit systems, even if it doesn't for 32-bit. Well, it's only speculation at the moment. > The increased layout flexibility is the only obvious win to me, and I > think it costs quite a bit. I consider it a big win, and the disadvantages not that big. It's the thin vs. thick model again; with FV we are duplicating the work of the kernel for memory layout. Just take a look at the syscall wrappers for mremap and brk. Yesterday I tried removing the strict partitioning, and the built-in support for shadow memory (tools allocate shadow memory just with VG_(get_memory_from_mmap)(), like they used to). I cut about 300 lines of code with hardly any effort, and that was just a start. > Well, we still need to keep Valgrind and the client stack separate. > Valgrind's stack is fixed size, but the client's has to grow. If we use > the stack the system gave us as the client stack, then we don't need to > worry about it. Yes. >> I think the end result would be simpler, have less code, be more robust, >> and cause fewer problems for users. Discuss. > > I think its more complicated than that. How did I come around to this viewpoint? I've been doing a lot of thinking about memory layout in the last couple of months, mostly trying to work out how to get the flexibility back while preserving FV's strict client/Valgrind separation. The thinking has been prompted by the large number of people who have been having difficulties due to non-3G:1G kernels, the RH8 over-committing problem, people complaining about ulimits not working, running out of memory prematurely, etc. There have been a lot. I've really been trying to come up with plausible ways to address the problems within FV, and I have concluded that it can't be done. If you are willing to abandon the strict client/Valgrind separation, lots of complication and problems fall away immediately. Also, the difficulties above that I encountered when trying to fix the skip-list problems made me quite unhappy; the code has to stay maintainable. FV is a nice idea, but practice has shown us that it ultimately is flawed. There's no shame in that, but it's not a good idea to ignore these flaws. N |
|
From: Tom H. <th...@cy...> - 2004-11-22 04:21:45
|
Nightly build on audi ( Red Hat 9 ) started at 2004-11-22 03:15:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 12 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/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-22 04:15:16
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-11-22 03:05:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-11-22 03:57:09
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2004-11-22 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 186 tests, 5 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) memcheck/tests/scalar (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-11-22 03:52:17
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2004-11-22 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow -- Finished tests in none/tests ---------------------------------------- == 191 tests, 14 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/badjump (stderr) memcheck/tests/badjump2 (stderr) memcheck/tests/badpoll (stderr) memcheck/tests/buflen_check (stderr) memcheck/tests/execve (stderr) memcheck/tests/execve2 (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_exit_group (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/writev (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-22 03:21:41
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-11-22 03:10:07 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_cmov: valgrind ./insn_cmov insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-11-22 03:06:10
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-11-22 03:00:12 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow insn_fpu: valgrind ./insn_fpu insn_mmx: valgrind ./insn_mmx insn_mmxext: valgrind ./insn_mmxext insn_sse: valgrind ./insn_sse insn_sse2: (skipping, prereq failed: ../../../tests/cputest x86-sse2) int: valgrind ./int rm: cannot remove `vgcore.pid*': No such file or directory (cleanup operation failed: rm vgcore.pid*) pushpopseg: valgrind ./pushpopseg rcl_assert: valgrind ./rcl_assert seg_override: valgrind ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 191 tests, 2 stderr failures, 0 stdout failures ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |