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-02 17:24:04
|
On Fri, 2 Jul 2004, Jeremy Fitzhardinge wrote: >> I'm currently looking at rejigging Cachegrind's data structures. I think >> I can solve the missing-info-for-unloaded-code and also significantly >> simplify its code. The key is a tri-level data structure that looks like: >> >> table(filename, table(fn_name, table(line_num, CC))) >> >> where CC is the cost-centre stored for each instruction. Instruction >> addresses are translated immediately to file/fn/line info, so there's no >> staleness. Also, all the relevant filenames and fn_names are stored only >> once, which is nice. (This structure is also necessary due to the way >> Cachegrind dumps its info at the end.) > > The trouble with using file/line info is that, obviously, a lot of code > doesn't have that info, and also that there can be more than one CC per > code line. But think about how the per-instr CCs are actually used -- they just get mapped onto file/func/line info at the end anyway. So nothing changes except there are fewer CCs which saves memory and reduces the size of the output file. N |
|
From: Jeremy F. <je...@go...> - 2004-07-02 17:06:56
|
On Fri, 2004-07-02 at 17:21 +0100, Nicholas Nethercote wrote: > On Fri, 2 Jul 2004, Jeremy Fitzhardinge wrote: > > > On Fri, 2004-07-02 at 13:55 +0100, Nicholas Nethercote wrote: > >> A better way of identifying instructions is with a (obj_file, obj_offset) > >> pair. That will AFAICT uniquely identify any static instruction. > > > > Yeah, that's not a bad idea. There's a few complications though. > > > > Do you actually mean byte offset into the object file? That's a bit > > coarse, since you'd then have to work hard to map that back into a > > segment and get symtab information. It also makes it hard to work out > > the mapped address if you just have a file offset+baseaddr. If you > > recorded (file, segment, offset), you could address these. > > Er, I'm not sure what I mean, I've forgotten the difference between object > files and segments. Well, an ELF file looks (very approximately) like this 0: ELF Header PHeader -> A PHeader -> C PHeader -> B A: Segment B: Segment C: Segment Each Segment is a chunk mmaped out of the file, from a particular file offset. The PHeaders contains the mapping between virtual address and file offset. There's also a lot of other things in the ELF file, so the net result is that the file offset doesn't have much to do with the mapped virtual address. > I'm currently looking at rejigging Cachegrind's data structures. I think > I can solve the missing-info-for-unloaded-code and also significantly > simplify its code. The key is a tri-level data structure that looks like: > > table(filename, table(fn_name, table(line_num, CC))) > > where CC is the cost-centre stored for each instruction. Instruction > addresses are translated immediately to file/fn/line info, so there's no > staleness. Also, all the relevant filenames and fn_names are stored only > once, which is nice. (This structure is also necessary due to the way > Cachegrind dumps its info at the end.) The trouble with using file/line info is that, obviously, a lot of code doesn't have that info, and also that there can be more than one CC per code line. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-02 16:22:21
|
On Fri, 2 Jul 2004, Jeremy Fitzhardinge wrote: > On Fri, 2004-07-02 at 13:55 +0100, Nicholas Nethercote wrote: >> A better way of identifying instructions is with a (obj_file, obj_offset) >> pair. That will AFAICT uniquely identify any static instruction. > > Yeah, that's not a bad idea. There's a few complications though. > > Do you actually mean byte offset into the object file? That's a bit > coarse, since you'd then have to work hard to map that back into a > segment and get symtab information. It also makes it hard to work out > the mapped address if you just have a file offset+baseaddr. If you > recorded (file, segment, offset), you could address these. Er, I'm not sure what I mean, I've forgotten the difference between object files and segments. > And obviously you also need the virtual address of the instruction for > the common case of the .so has not been unloaded. If you store file as > (path, base_address), you know where the object was mapped, and you can > work everything out from that. Ok, then let's pretend that's what I meant. -- Actually, even this still isn't really what we want. The whole point of this is to get back to file/function/line info. If we recorded that straight away in error messages instead of instruction addresses, the debug/symbol info would be nice and fresh and there wouldn't be any problems with unloading, and no need to fiddle around with object/segment offset and maybe reload symbols later. Of course, the reason we currently don't do this is because it would vastly increase the size of each ExeContext. Unless we worked out a clever scheme whereby it didn't. I'm thinking something where every unique code location recorded in an ExeContext is stored in a way that it's never duplicated, and the same for all file/function names. I'm currently looking at rejigging Cachegrind's data structures. I think I can solve the missing-info-for-unloaded-code and also significantly simplify its code. The key is a tri-level data structure that looks like: table(filename, table(fn_name, table(line_num, CC))) where CC is the cost-centre stored for each instruction. Instruction addresses are translated immediately to file/fn/line info, so there's no staleness. Also, all the relevant filenames and fn_names are stored only once, which is nice. (This structure is also necessary due to the way Cachegrind dumps its info at the end.) N |
|
From: Jeremy F. <je...@go...> - 2004-07-02 16:06:47
|
On Fri, 2004-07-02 at 13:55 +0100, Nicholas Nethercote wrote: > A better way of identifying instructions is with a (obj_file, obj_offset) > pair. That will AFAICT uniquely identify any static instruction. Yeah, that's not a bad idea. There's a few complications though. Do you actually mean byte offset into the object file? That's a bit coarse, since you'd then have to work hard to map that back into a segment and get symtab information. It also makes it hard to work out the mapped address if you just have a file offset+baseaddr. If you recorded (file, segment, offset), you could address these. And obviously you also need the virtual address of the instruction for the common case of the .so has not been unloaded. If you store file as (path, base_address), you know where the object was mapped, and you can work everything out from that. J |
|
From: Jeremy F. <je...@go...> - 2004-07-02 16:01:09
|
On Thu, 2004-07-01 at 11:52 +0100, Julian Seward wrote: > I think it's time a new snapshot of the head was made and shipped. > From what I see from the auto-test results, things are pretty stable > at the moment, and various improvements have crept in, which would > be good to get out to users. > > Views? Are there any major known problems which would cause a > problem here? OK with me. J |
|
From: Nicholas N. <nj...@ca...> - 2004-07-02 15:28:41
|
CVS commit by nethercote:
Fix meaningless typo.
M +2 -2 cg_main.c 1.67
--- valgrind/cachegrind/cg_main.c #1.66:1.67
@@ -351,5 +351,5 @@ static Int compute_BBCC_array_size(UCode
static __inline__
-file_node* new_file_node(Char filename[FILENAME_LEN], file_node* next)
+file_node* new_file_node(Char filename[], file_node* next)
{
Int i;
@@ -364,5 +364,5 @@ file_node* new_file_node(Char filename[F
static __inline__
-fn_node* new_fn_node(Char fn_name[FILENAME_LEN], fn_node* next)
+fn_node* new_fn_node(Char fn_name[], fn_node* next)
{
Int i;
|
|
From: Nicholas N. <nj...@ca...> - 2004-07-02 12:55:59
|
Hi, People complain when Memcheck gives them useless error leak messages because the leaks occur in a .so which has been unmapped. Cachegrind has a similar problems -- all stats for an unmapped .so file get dumped into a single "discarded" pile, and cannot be used for annotation. The underlying problem is that we are using an instruction's address as the key for identifying it. This only works while the code is in memory; once it gets unloaded we can't rely on it any more. A better way of identifying instructions is with a (obj_file, obj_offset) pair. That will AFAICT uniquely identify any static instruction. It's not good for dynamically generated instructions -- I don't see how these can be uniquely identified without bringing time into the equation and that would be pretty awful -- but that probably doesn't matter because they don't have any debug info anyway, and so can be lumped together in an "other" category. If ExeContexts were changed to use (obj_file, obj_offset) pairs instead of just instructions, Memcheck (or the core) could, when printing the leaks, reload the debug info of any obj_file that had been unmapped. A similar thing could be done with Cachegrind to avoid the "discarded" pile, and it might actually make Cachegrind simpler overall. Anyway, I'm just thinking aloud. N |
|
From: <js...@ac...> - 2004-07-02 07:29:43
|
Nightly build on nemesis ( SuSE 9.1 ) started at 2004-07-02 08:50:11 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow memcheck/tests/null_socket (stderr) 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/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-02 02:25:19
|
Nightly build on dunsmere ( Fedora Core 2 ) started at 2004-07-02 03:20: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 ---------------------------------------- == 169 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-02 02:19:49
|
Nightly build on audi ( Red Hat 9 ) started at 2004-07-02 03:15: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 ---------------------------------------- == 169 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-02 02:13:26
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-07-02 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 ---------------------------------------- == 169 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-02 02:08:38
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-07-02 03:05:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow 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 ---------------------------------------- == 169 tests, 5 stderr failures, 1 stdout failure ================= 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/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-07-02 02:07:12
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-07-02 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 ---------------------------------------- == 169 tests, 1 stderr failure, 0 stdout failures ================= memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |