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
(14) |
|
2
|
3
(6) |
4
(9) |
5
(23) |
6
(6) |
7
(10) |
8
(2) |
|
9
(1) |
10
(5) |
11
(2) |
12
(5) |
13
(2) |
14
(2) |
15
(4) |
|
16
(3) |
17
(22) |
18
(21) |
19
(15) |
20
(24) |
21
(5) |
22
(5) |
|
23
(14) |
24
(2) |
25
(2) |
26
(1) |
27
|
28
|
29
(1) |
|
30
|
31
|
|
|
|
|
|
|
From: Petar J. <mip...@gm...> - 2016-10-14 17:20:26
|
On Sat, Oct 8, 2016 at 8:08 PM, Ivo Raisr <iv...@iv...> wrote: > Dear developers, > > Johan van Selst recently announced on fosdem alias that we have a dev room > at FOSDEM 2017. > He also said this will be announced shortly on FOSDEM website. Here is the devroom link: https://fosdem.org/2017/schedule/track/valgrind/ Regards, Petar |
|
From: Ruurd B. <Ruu...@in...> - 2016-10-14 07:45:36
|
Hi, Sorry about the delay… 1. The MEMPOOL_DELETE was, indeed, a bad comment. Has to be VALGRIND_MEMPOOL_FREE. The documentation (memcheck/docs/mc-manual.xml) did use the correct name. 2. I see where the confusion comes from. Apologies. In my first attempts to get valgrind to understand our custom allocator, I saw a need to have a special attributes for a memory pool. - A flag to indicate that items in a pool-block are to be freed when VALGRIND_MEMPOOL_FREE is used on such a block. - A flag to indicate that a pool block is allocated (with VALGRIND_MALLOCLIKE_BLOCK) which is then used as a pool to allocate smaller VALGRIND_MALLOCLIKE_BLOCKs from. Without the first attribute, I got thousands of leaks reported that were not really leaks. Without the 2nd attribute, valgrind would crash with an assert, complaining about overlapping blocks. So: Without these fixes, valgrind is not usable in our environment. My first implementation of this broke compatibility in valgrind.h by altering the signature of VALGRIND_CREATE_MEMPOOL. I managed to get it to work in our environment that way and we found and fixed several issues in our large code base. Yippee! Then I tried to get the fixes in valgrind reworked so they could become part of the standard distribution, because our code is multi-platform, and we continuously support new hardware and OS-releases. I do not want to have to re-fix every future version of valgrind. The naming of the reworked version is, I must admit, badly chosen. The attribute names reflect the implementation, not the functionality. There is no point in having an AUTO_FREE pool which is not a METAPOOL. The name of the macro already tells you that, and AUTO_FREE only makes sense when chunks are contained in other chunks (i.e. META). A METAPOOL that is not AUTO_FREE is more logical, I can envision a custom allocator that. So a VALGRIND_CREATE_META_MEMPOOL that only accepts an AUTO_FREE flag is better. Or a name like VALGRIND_CREATE_MEMPOOL_EXT or some other convention that allows future expansion. So I agree with the renaming: The VALGRIND_MEMPOOL_METAPOOL flag can go and is implied in the call. The documentation of that flag (which only confuses things) can be removed. There is a test which tests the double-level stuff. The memcheck/tests/leak-autofreepool.c test creates a pool with blocks, the allocates (with VALGRIND_MALLOCLIKE_BLOCK, like our custom allocator does. In test case 5, it demonstrates that valgrind asserts and aborts if the METAPOOL flags is not passed. Again, the documentation is confusing: the blocks overlap, but one is of type MEMPOOL_ALLOC and the second of MALLOCLIKE_BLOCK type. Apologies for that: my focus was more on “getting it working here and for us now” than on a clean, complete & spotless valgrind patch. I’m glad the vetting process is so thorough, though ☺ Who is going to polish up this stuff? I can do it, but if one of the valgrind veterans does it I’ll be happy, too (and if I do it, it might again take a few tries before it is deemed satisfactory). The change to our custom allocator will be tiny (use the new macro and names) and as long as it works, I’m happy. Regards, Ruurd Beerstra From: Ivo Raisr [mailto:iv...@iv...] Sent: Thursday, October 06, 2016 22:02 To: Ruurd Beerstra <Ruu...@in...> Subject: Fwd: [Valgrind-developers] Confusion in recent meta mempool doc and/or usage FYI if you are not on valgrind-developers ---------- Forwarded message ---------- From: Philippe Waroquiers <phi...@sk...<mailto:phi...@sk...>> Date: 2016-10-06 21:59 GMT+02:00 Subject: [Valgrind-developers] Confusion in recent meta mempool doc and/or usage To: valgrind-developers <val...@li...<mailto:val...@li...>> I am a little bit lost in the documentation and/or semantic of the recently added meta mempool feature. First, valgrind.h tells: ... When the VALGRIND_MEMPOOL_AUTO_FREE is passed, a MEMPOOL_DELETE will auto-free all chunks (so not reported as leaks) for allocators that assume that destroying a pool destroys all objects in the pool. ... But this operation MEMPOOL_DELETE does not exist. This looks to be rather VALGRIND_MEMPOOL_FREE. In the manual, the description is somewhat different. Second thing confusing me: The user manual tells for META mempool first describe the auto free flag: ... This indicates that items allocated from this memory pool are automatically freed when VALGRIND_MEMPOOL_FREE is used on a block. ... But of course, when calling VALGRIND_MEMPOOL_FREE, by definition, the addr given as argument is supposed to be a chunk of the pool, and is released. So, this flag is by itself useless, unless it is combined with VALGRIND_MEMPOOL_METAPOOL. Do I miss something ? Assuming I did not miss something, then we now have a new macro VALGRIND_CREATE_META_MEMPOOL(pool, rzB, is_zeroed, flags) which in its names indicates it is a meta pool. So, it is unclear why we ask the user to specify VALGRIND_MEMPOOL_METAPOOL and/or allows the user to specify VALGRIND_MEMPOOL_AUTO_FREE, as this will be useless unless the pool is a real meta pool. (checking the code, effectively, the only thing an AUTO_FREE pool does is to release automatically the '2nd level smaller blocks' when a 'first level pool bigger block' is released with VALGRIND_MEMPOOL_FREE The second flag documented is also somewhat confusingly described: ... This indicates that memory that has been marked as being allocated with VALGRIND_MALLOCLIKE_BLOCK is used by a custom allocator to pass out memory to an application (again marked with VALGRIND_MALLOCLIKE_BLOCK). ... I do not see anything in tests and/or code that would implement something like a double level of VALGRIND_MALLOCLIKE_BLOCK. As I understand, we have a first level of blocks which are described with VALGRIND_MEMPOOL_ALLOC Then, such first level blocks can be split and allocated using VALGRIND_MALLOCLIKE_BLOCK. I think it would be better to clarify the documentation and maybe remove this (useless for the user) VALGRIND_MEMPOOL_METAPOOL : The underlying (internal) client request might effectively be the same (and so have an 'internal' flag VALGRIND_MEMPOOL_METAPOOL but it looks to me that describing this flag to the user is just confusing. Philippe ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Valgrind-developers mailing list Val...@li...<mailto:Val...@li...> https://lists.sourceforge.net/lists/listinfo/valgrind-developers |