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
|
2
(1) |
3
(1) |
4
(5) |
5
|
6
(1) |
7
|
|
8
(10) |
9
(7) |
10
(2) |
11
(10) |
12
(1) |
13
|
14
(1) |
|
15
(3) |
16
|
17
|
18
|
19
|
20
|
21
(5) |
|
22
(2) |
23
(2) |
24
(4) |
25
(2) |
26
|
27
(7) |
28
(4) |
|
29
(5) |
30
(5) |
31
(1) |
|
|
|
|
|
From: Paul F. <pj...@wa...> - 2023-01-25 20:17:09
|
Hi I'd like some feedback on https://bugs.kde.org/show_bug.cgi?id=464103 This allows the user to specify that a block of memory should be histogrammed. It's intended for blocks larger than the existing 1024 byte limit - recently at work I was profiling and the top data structure was about 1600 bytes so I couldn't see the histogram straight way - I rebuilt dhat with a limit of 2048 to see it. Since this is a user request it shouldn't bee too overwhelming (either for runtime memory or the size of the html generated). I'll do a bit of trial and error and put in some upper limit. About 2500 will fit on my screen, so probably somewhere between 10k and 25k. For such large arrays someone needs to write a nice zoomable GUI. One change I'll probably make straight away is to add an argument for the initial count (normally 0 for malloc or 1 for calloc or std::vector with an initial size and value). Or possibly have 2 macros like DHAT_HISTOGRAM_MEMORY_UNINIT and DHAT_HISTOGRAM_MEMORY_INIT I've also been thinking about an array version of these user requests. For instance say we have 'struct Node' which is 80 bytes. If a user has std::vector<Node> nodeVec(500); or struct Node *nodes = malloc(500*sizeof(struct Node)); Then this would be too big for the DHAT histogram. Just increasing the limiat as with the 1st user request isn't very useful either. So what I'm thinking of is a user request DHAT_HISTOGRAM_ARRAY that takes 3 arguments - pointer to memory - number of elements - size of each element That would look like this std::vector<Node> nodeVec(500); DHAT_HISTOGRAM_ARRAY(nodeVec.data(), nodeVec.size(), sizeof(Node)); In DHAT this would find and throw away the old block. A bit inefficient but I don't see an alternative. Then create number_of_elements subblocks. I did think about automating that. The only alloc function where that would be possible is calloc. malloc new and new[] just have the overall size available. A+ Paul |
|
From: Paul F. <pa...@so...> - 2023-01-25 07:32:28
|
https://sourceware.org/git/gitweb.cgi?p=valgrind.git;h=5830ece5cdfd71cb7a7b537b5b58c9a9858a78a3 commit 5830ece5cdfd71cb7a7b537b5b58c9a9858a78a3 Author: Paul Floyd <pj...@wa...> Date: Wed Jan 25 08:31:09 2023 +0100 FreeBSD: update comment about __sysctlbyname and kern.proc.pathname Diff: --- coregrind/m_syswrap/syswrap-freebsd.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/coregrind/m_syswrap/syswrap-freebsd.c b/coregrind/m_syswrap/syswrap-freebsd.c index 401a7ba8ee..13d3b6bf25 100644 --- a/coregrind/m_syswrap/syswrap-freebsd.c +++ b/coregrind/m_syswrap/syswrap-freebsd.c @@ -6468,8 +6468,9 @@ PRE(sys___sysctlbyname) SET_STATUS_Success(0); } - // @todo PJF kern.proc.pathname - // how is that done? jusr a pid or -1 in the string? + // kern.proc.pathname doesn't seem to be handled + // makes sense as the pid is variable and using + // a MIB is easier than generating a string // read number of ints specified in ARG2 from mem pointed to by ARG1 PRE_MEM_READ("__sysctlbyname(name)", (Addr)ARG1, ARG2 * sizeof(int)); |