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
(4) |
|
2
(5) |
3
(3) |
4
(3) |
5
(7) |
6
(7) |
7
(9) |
8
(10) |
|
9
(12) |
10
(26) |
11
(9) |
12
(6) |
13
(7) |
14
(15) |
15
(25) |
|
16
(20) |
17
(32) |
18
(11) |
19
(19) |
20
(22) |
21
(6) |
22
(8) |
|
23
(16) |
24
(25) |
25
(11) |
26
(16) |
27
(12) |
28
(15) |
29
(11) |
|
30
(5) |
31
(8) |
|
|
|
|
|
|
From: Jeremy F. <je...@go...> - 2005-01-29 09:34:16
|
CVS commit by fitzhardinge:
VG_(record_fd_open) still needs to free the pathname, even if we're
not tracking FDs. Otherwise its a leak.
M +5 -4 vg_syscalls.c 1.239
--- valgrind/coregrind/vg_syscalls.c #1.238:1.239
@@ -441,9 +441,10 @@ void VG_(record_fd_open)(Int tid, Int fd
OpenFd *i;
- if (!VG_(clo_track_fds))
+ if (!VG_(clo_track_fds) || /* don't care */
+ fd >= VG_(fd_hard_limit)) { /* Valgrind internal */
+ if (pathname)
+ VG_(arena_free)(VG_AR_CORE, pathname); /* caller expects this */
return;
-
- if (fd >= VG_(fd_hard_limit))
- return; /* Valgrind internal */
+ }
/* Check to see if this fd is already open. */
|
|
From: Jeremy F. <je...@go...> - 2005-01-29 08:57:20
|
On Sat, 2005-01-29 at 03:06 +0000, Julian Seward wrote:
> No, only memory exceptions. I guess with a bit of care, the IR optimiser
> could be told that arbitrary other events (int division, all FP) might
> also cause exceptions and so optionally to be careful to keep them in
> order. However, it would take some thinking about, would reduce performance,
> and I'm unclear what the benefit would be.
Real programs rely on getting precise exceptions of all kinds. We need
to make all exceptions precise. Performance is secondary to
correctness.
There are 3 types of exceptions:
* memory - covered
* FP - tricky
* always (int $XX, illegal instruction) - easy
FP is tricky because the FPU/SSE units are modal, and may or may not
generate exceptions. Writes to the mode register should be pretty easy
to see so we know when the modes change, but dealing with them is
tricky. But we still need to - the Mesa 3D driver, for example,
deliberately provokes SSE SIGFPE exceptions, and won't run unless we get
that right (it currently requires --single-step=yes). (Mesa does the
hardest-to-get-right thing: it provokes an exception, modifies the
machine state from within the signal handler, then returns from the
handler, expecting the instruction to restart with the newly modified
state; a big chunk of the signal handling changes were to get this stuff
right.)
Valgrind also relies on precise exceptions, which becomes noticeable
when it is running itself (again, it needs --single-step=yes now).
I've been thinking about adding a client request, something like
VALGRIND_HINT_PRECISE_EXCEPTIONS(0/1), so that a client can request
precision if it needs it. Bit of a hack, and I'd hope it would be
unnecessary.
> For s-m-c, the issue is how to detect code overwrites. I guess we could
> use the host's memory protection when appropriate, our own bitmaps if
> needed, or some other scheme (self-checking translations?)
I think self-checking is the way to go. Basically, if you see you're
translating code from a writable page, then assume it can be changed,
and generate a check to see the original code is still the same as it
was when the block was translated.
Except for the cases where we know a memory write will hit code, I don't
think there's much point in checking every (or any) writes, since writes
so rarely do touch code.
> It would be
> good to know why this is an issue -- where is there a problem? You mentioned
> something about sighandler returns before, but I don't remember any
> details.
Sigreturns are OK, but nested functions are a bit of a problem, since
the compiler dynamically generates code on the stack and jumps to it for
each call (bug 69511, our oldest) Also, due to the current structure of
the translation cache, the manual invalidate call is very slow, mostly
because of all the tracking down and unlinking of chained blocks.
> Re debugging facility, breakpoints, single-step, again, I'm not sure what
> you want to achieve. Can you outline?
I'm building a gdbstub into Valgrind so that you can attach gdb to the
VCPU and interactively debug a program while it runs under Valgrind.
The GDB remote protocol also supports the notion of multiple address
spaces, and it looks easy and convenient to expose the Tool metadata
through this interface. This means that you can do basic debugging with
an unmodified gdb, and also extend gdb to be Valgrind-aware and get a
much more powerful debugging environment.
Mostly this is fairly easy to integrate, but it does require that the
stub be able to control the VCPU's execution at the instruction level.
With UCode, single stepping is pretty easy with
VG_(clo_single_step)=True and making dispatch_ctr per-thread rather than
global, but it still isn't clear to me what the best way to do
breakpoints is. I'm tending towards just stomping an int3 on the first
byte of the translated instruction, and dealing with the trap
appropriately (since debugger mode is special, there's no problem with
generating a special BB prologue to leave space for it, rather than
overwriting something else).
J
|
|
From: <js...@ac...> - 2005-01-29 03:56:43
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-29 03:50:00 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 ---------------------------------------- == 194 tests, 15 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_fcntl (stderr) helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-01-29 03:25:18
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-29 03:20:03 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 201 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-29 03:21:20
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-29 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (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/tls (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-29 03:15:30
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-29 03:10:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow seg_override: valgrind --num-callers=4 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 12 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Julian S. <js...@ac...> - 2005-01-29 03:07:37
|
> > You can ask for any arbitrary subset of the guest state to be up to date > > at any point where a memory exception might occur. > > Do you mean any kind of exception? No, only memory exceptions. I guess with a bit of care, the IR optimiser could be told that arbitrary other events (int division, all FP) might also cause exceptions and so optionally to be careful to keep them in order. However, it would take some thinking about, would reduce performance, and I'm unclear what the benefit would be. > > > but we > > > also need to do function wrapping, have some way of dealing with > > > self-modifying code, and any debugging facility will need breakpoints > > > and single-step. > > > > In that sense it is neither better nor worse than UCode world since we > > don't have good solutions for those problems in UCode either. > > True; they're problems I'd like to solve. If I can assert that "these > things should be done" and get you to solve them, then I'm happy ;) For s-m-c, the issue is how to detect code overwrites. I guess we could use the host's memory protection when appropriate, our own bitmaps if needed, or some other scheme (self-checking translations?) It would be good to know why this is an issue -- where is there a problem? You mentioned something about sighandler returns before, but I don't remember any details. Re debugging facility, breakpoints, single-step, again, I'm not sure what you want to achieve. Can you outline? J |
|
From: Tom H. <th...@cy...> - 2005-01-29 03:05:20
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-29 03:00: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/x86 ------------------------------------ yield: valgrind --num-callers=4 ./yield -- Finished tests in none/tests ---------------------------------------- == 199 tests, 13 stderr failures, 0 stdout failures ================= helgrind/tests/allok (stderr) helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Jeremy F. <je...@go...> - 2005-01-29 02:45:14
|
On Sat, 2005-01-29 at 02:11 +0000, Julian Seward wrote: > On Saturday 29 January 2005 01:13, Jeremy Fitzhardinge wrote: > > On Fri, 2005-01-28 at 19:16 +0000, Nicholas Nethercote wrote: > > > On Fri, 28 Jan 2005, Julian Seward wrote: > > > > And vex doesn't do translation chaining ... instead it chases across > > > > bb boundaries (possibly even conditional branches, am still > > > > experimenting) > > > > > > Will that make function wrapping more difficult? > > No, I don't think so. Whenever it wants to chase over a bb boundary, and > specifically in the case of chasing a call insn, it first asks (via a > callback) if it is OK to do this. That means V itself can arbitrarily > stop vex chasing across any boundaries it feels like. I already have > to implement this in order that the existing redirection mechanism works. > You can ask for any arbitrary subset of the guest state to be up to date > at any point where a memory exception might occur. Do you mean any kind of exception? > > but we > > also need to do function wrapping, have some way of dealing with > > self-modifying code, and any debugging facility will need breakpoints > > and single-step. > > In that sense it is neither better nor worse than UCode world since we > don't have good solutions for those problems in UCode either. True; they're problems I'd like to solve. If I can assert that "these things should be done" and get you to solve them, then I'm happy ;) With UCode, single stepping is just a matter of using the existing --single-step=yes machinery, and setting the dispatch counter to 1. I expect we could do the same with vex, but it would be nice to have something a bit less brute-force. If vex can be convinced to not intermingle the side-effects of adjacent instructions (ie, commit one instruction's results before starting on committing the next instruciton's, which I guess will be necessary anyway to get the instruction side-effects in-order), then there's be appropriate points in the generated code to delimit the effects of adjacent instructions, and therefore good places to hop between when single-stepping. Those same points would also be where you could put breakpoints too. J |
|
From: Julian S. <js...@ac...> - 2005-01-29 02:12:05
|
On Saturday 29 January 2005 01:13, Jeremy Fitzhardinge wrote: > On Fri, 2005-01-28 at 19:16 +0000, Nicholas Nethercote wrote: > > On Fri, 28 Jan 2005, Julian Seward wrote: > > > And vex doesn't do translation chaining ... instead it chases across > > > bb boundaries (possibly even conditional branches, am still > > > experimenting) > > > > Will that make function wrapping more difficult? No, I don't think so. Whenever it wants to chase over a bb boundary, and specifically in the case of chasing a call insn, it first asks (via a callback) if it is OK to do this. That means V itself can arbitrarily stop vex chasing across any boundaries it feels like. I already have to implement this in order that the existing redirection mechanism works. > Well, I hope the codegen can be reined in a bit when we need to do > special stuff. I'm assuming that it will record enough state to be able > to produce up-to-date VCPU state for any faulting instruction, You can ask for any arbitrary subset of the guest state to be up to date at any point where a memory exception might occur. > but we > also need to do function wrapping, have some way of dealing with > self-modifying code, and any debugging facility will need breakpoints > and single-step. In that sense it is neither better nor worse than UCode world since we don't have good solutions for those problems in UCode either. J |
|
From: Jeremy F. <je...@go...> - 2005-01-29 01:16:33
|
On Fri, 2005-01-28 at 19:16 +0000, Nicholas Nethercote wrote: > On Fri, 28 Jan 2005, Julian Seward wrote: > > > And vex doesn't do translation chaining ... instead it chases across > > bb boundaries (possibly even conditional branches, am still experimenting) > > Will that make function wrapping more difficult? Well, I hope the codegen can be reined in a bit when we need to do special stuff. I'm assuming that it will record enough state to be able to produce up-to-date VCPU state for any faulting instruction, but we also need to do function wrapping, have some way of dealing with self-modifying code, and any debugging facility will need breakpoints and single-step. J |