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: Chris J. <ch...@at...> - 2005-01-08 20:19:36
|
> On Sat, 2005-01-08 at 16:56 +0000, Chris January wrote: > > This seemed like > > the 'right' solution at the time because GDB didn't need to have=20 > > special knowledge about Valgrind (or so I thought) and I began=20 > > implementing it but didn't have enough time to finish. >=20 > How far did you get? I don't remember exactly - it was a number of months ago. >=20 > > However now I am revisiting the problem > > and have concluded that this idea is not the best solution because: > > a) it is limited to debuggers implenting the GDB remote debugging=20 > > protocol. >=20 > I'm not terribly worried about that, especially since the set=20 > of debuggers implementing the gdb protocol is vastly larger=20 > than the set using a special Valgrind library. True. >=20 > > b) it still needs a specialised Valgrind target for GDB to launch=20 > > Valgrind and connect to the server port in one operation.=20 > (I suppose=20 > > it would be feasible to have the user manually launch Valgrind and=20 > > then have Valgrind wait for GDB to connect but this is less than=20 > > ideal.) >=20 > Valgrind could do that itself, if that were a major concern. =20 > One of the nice things about having gdb separate is that its=20 > independent of Valgrind's terminal I/O, so I think you'd be=20 > commonly launching them in separate windows anyway. It hadn't actually occurred to me to do this the other way round = (Valgrind launches GDB) but that could work ok. >=20 > > c) poor support for getting data from Valgrind's tools (e.g.=20 > > memcheck). The GDB protocol was never really designed for this. >=20 > Yep, that would be nice to have. Do you have any more=20 > concrete thoughts? It seems like a difficult problem,=20 > because there's nothing generic about a Tool; they can get=20 > very special purpose. How does one represent that on the=20 > wire, and how can a generic debugger deal with it once its there? Tools would publish their own API helper libraries. These would = interpret the data stored in the tool specific area of the shared memory region. A client could ask the API what information the tool provided. A client = would either request this information as a binary structure, which it would = then need to interpret, or could ask for it in string form in which case it = would be displayed unprocessed to the user. >=20 > > The only problem with the original shared memory implementation was=20 > > the exposure of internal data structures. To solve this problem I=20 > > propose adding a debugging API shared library to Valgrind. This=20 > > library would be released as part of the Valgrind package and=20 > > installed at the same time. The library could therefore freely use=20 > > access internal data structures without any problems.=20 > Valgrind's core=20 > > would expose useful debugging information, such as registers, and=20 > > debugging control variables such as single stepping through shared=20 > > memory as before (either SysV or mmap). >=20 > (I don't think shared memory would be a good idea. It would=20 > preclude remote machine access, and adds a complex protocol=20 > overhead for synchronizing between the debugger and the=20 > Valgrind threads.) It's not difficult to synchronise between the debugger and Valgrind = threads. That is to say, I encountered no problems implementing this. As for remote machine access, see below. >=20 > > The debugging API would know > > the structure of this shared memory and access it on behalf of user=20 > > processes (such as a debugger). We could also add an API to=20 > Valgrind=20 > > for skins to publish similar skin-specific information. =20 > The debugging=20 > > API would be lightweight and need not necessarily require=20 > many changes=20 > > to Valgrind. >=20 > And the other end of the equation? Are you proposing that we=20 > modify gdb to use this API, and maintain those modifications=20 > as gdb changes? Do you have any other debuggers in mind=20 > which would use it? >=20 > While its certainly possible to do better, it seems that the=20 > gdb protocol has a number of very strong features: > * it exists > * it's stable > * every gdb in the field can already use it The advantage of the debugging API is you can implement the GDB protocol atop of it (e.g. for remote debugging or to support debuggers without a Valgrind target), but you are not limited to it. It also means the GDB server can be a separate component, whereas without the API it would be = more closely coupled to the Valgrind core. >=20 > I definitely like the idea of having some way to use the=20 > Tool's metadata in a debugging context, but I think the first=20 > step is to get some useful debugging functionality. Once we=20 > have that, we can explore ways of improving it/replacing it=20 > with improvements. Is the protocol really completely inextensible? I already have a set of patches that implement useful debugging functionality. The current question is what is the 'right' way to do it. = > One other thing we could look at is reviving Nick's=20 > interactive mode stuff. I'm guessing it has aged rather a lot. Chris |
|
From: Jeremy F. <je...@go...> - 2005-01-08 19:55:56
|
It turns out the threading changes made this pretty simple to get working: $ valgrind --tool=none --single-step=yes valgrind --tool=none echo 'I simulate, therefore I am.' ==11451== Nulgrind, a binary JIT-compiler for x86-linux. ==11451== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==11451== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==11451== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==11451== For more details, rerun with: -v ==11451== >==11451== Nulgrind, a binary JIT-compiler for x86-linux. >==11451== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. >==11451== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. >==11451== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. >==11451== For more details, rerun with: -v >==11451== I simulate, therefore I am. >==11451== ==11451== |
|
From: Jeremy F. <je...@go...> - 2005-01-08 19:53:31
|
On Sat, 2005-01-08 at 16:56 +0000, Chris January wrote:
> This seemed like
> the 'right' solution at the time because GDB didn't need to have special
> knowledge about Valgrind (or so I thought) and I began implementing it but
> didn't have enough time to finish.
How far did you get?
> However now I am revisiting the problem
> and have concluded that this idea is not the best solution because:
> a) it is limited to debuggers implenting the GDB remote debugging protocol.
I'm not terribly worried about that, especially since the set of
debuggers implementing the gdb protocol is vastly larger than the set
using a special Valgrind library.
> b) it still needs a specialised Valgrind target for GDB to launch Valgrind
> and connect to the server port in one operation. (I suppose it would be
> feasible to have the user manually launch Valgrind and then have Valgrind
> wait for GDB to connect but this is less than ideal.)
Valgrind could do that itself, if that were a major concern. One of the
nice things about having gdb separate is that its independent of
Valgrind's terminal I/O, so I think you'd be commonly launching them in
separate windows anyway.
> c) poor support for getting data from Valgrind's tools (e.g. memcheck). The
> GDB protocol was never really designed for this.
Yep, that would be nice to have. Do you have any more concrete
thoughts? It seems like a difficult problem, because there's nothing
generic about a Tool; they can get very special purpose. How does one
represent that on the wire, and how can a generic debugger deal with it
once its there?
> The only problem with the original shared memory implementation was the
> exposure of internal data structures. To solve this problem I propose adding
> a debugging API shared library to Valgrind. This library would be released
> as part of the Valgrind package and installed at the same time. The library
> could therefore freely use access internal data structures without any
> problems. Valgrind's core would expose useful debugging information, such as
> registers, and debugging control variables such as single stepping through
> shared memory as before (either SysV or mmap).
(I don't think shared memory would be a good idea. It would preclude
remote machine access, and adds a complex protocol overhead for
synchronizing between the debugger and the Valgrind threads.)
> The debugging API would know
> the structure of this shared memory and access it on behalf of user
> processes (such as a debugger). We could also add an API to Valgrind for
> skins to publish similar skin-specific information. The debugging API would
> be lightweight and need not necessarily require many changes to Valgrind.
And the other end of the equation? Are you proposing that we modify gdb
to use this API, and maintain those modifications as gdb changes? Do
you have any other debuggers in mind which would use it?
While its certainly possible to do better, it seems that the gdb
protocol has a number of very strong features:
* it exists
* it's stable
* every gdb in the field can already use it
I definitely like the idea of having some way to use the Tool's metadata
in a debugging context, but I think the first step is to get some useful
debugging functionality. Once we have that, we can explore ways of
improving it/replacing it with improvements. Is the protocol really
completely inextensible?
One other thing we could look at is reviving Nick's interactive mode
stuff. I'm guessing it has aged rather a lot.
J
|
|
From: Chris J. <ch...@at...> - 2005-01-08 16:56:17
|
In which I propose adding a shared library that implements an API for accessing internal Valgrind data structures and tool-specific = information. Some time ago I submitted a patch to implement breakpoints and single stepping in Valgrind. Hopefully that patch can be revisited and = committed at some stage because I have a proposal that builds on that patch to make. As some of you may know I wrote some patches for Valgrind and GDB that allowed GDB to debug processes running under Valgrind. I moved the VG_(threads) structure to a shared memory region so that GDB could read = the register set of the threads from the structure. I also added a control variable to enable single stepping. Now although this method worked fine = it was fragile because GDB needed to have intimate knowledge of the VG_(threads) structure. I later proposed an alternative solution in = which Valgrind provided a GDB server that GDB could connect to. This seemed = like the 'right' solution at the time because GDB didn't need to have special knowledge about Valgrind (or so I thought) and I began implementing it = but didn't have enough time to finish. However now I am revisiting the = problem and have concluded that this idea is not the best solution because: a) it is limited to debuggers implenting the GDB remote debugging = protocol. b) it still needs a specialised Valgrind target for GDB to launch = Valgrind and connect to the server port in one operation. (I suppose it would be feasible to have the user manually launch Valgrind and then have = Valgrind wait for GDB to connect but this is less than ideal.) c) poor support for getting data from Valgrind's tools (e.g. memcheck). = The GDB protocol was never really designed for this. The only problem with the original shared memory implementation was the exposure of internal data structures. To solve this problem I propose = adding a debugging API shared library to Valgrind. This library would be = released as part of the Valgrind package and installed at the same time. The = library could therefore freely use access internal data structures without any problems. Valgrind's core would expose useful debugging information, = such as registers, and debugging control variables such as single stepping = through shared memory as before (either SysV or mmap). The debugging API would = know the structure of this shared memory and access it on behalf of user processes (such as a debugger). We could also add an API to Valgrind for skins to publish similar skin-specific information. The debugging API = would be lightweight and need not necessarily require many changes to = Valgrind. Comments and criticism welcome. Chris -- http://www.atomice.com |
|
From: <js...@ac...> - 2005-01-08 03:56:34
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-01-08 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 ---------------------------------------- == 188 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...> - 2005-01-08 03:24:11
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-01-08 03:20:03 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 sh: line 1: 6106 Illegal instruction VALGRINDLIB=/tmp/valgrind.22439/valgrind/.in_place /tmp/valgrind.22439/valgrind/./coregrind/valgrind --tool=none ./int >int.stdout.out 2>int.stderr.out 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 ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:20:07
|
Nightly build on audi ( Red Hat 9 ) started at 2005-01-08 03:15: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 ./seg_override -- Finished tests in none/tests/x86 ------------------------------------ yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 193 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...> - 2005-01-08 03:13:53
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-01-08 03:10:01 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 ---------------------------------------- == 193 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/scalar (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:08:34
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-01-08 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-01-08 03:04:03
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-01-08 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 193 tests, 3 stderr failures, 1 stdout failure ================= memcheck/tests/scalar (stderr) memcheck/tests/vgtest_ume (stderr) none/tests/susphello (stdout) none/tests/susphello (stderr) make: *** [regtest] Error 1 |