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
|
|
3
|
4
|
5
|
6
|
7
(1) |
8
|
9
|
|
10
|
11
|
12
(6) |
13
(4) |
14
(3) |
15
(1) |
16
(2) |
|
17
(7) |
18
(1) |
19
(5) |
20
(3) |
21
(1) |
22
(5) |
23
|
|
24
(1) |
25
(3) |
26
(2) |
27
(1) |
28
(2) |
29
(1) |
30
|
|
31
|
|
|
|
|
|
|
|
From: Greg P. <gp...@ap...> - 2016-01-19 21:54:06
|
> On Jan 17, 2016, at 12:32 PM, Florian Krohm <fl...@ei...> wrote: > > But static analysis tools may say that (void)format; is a statement with no effect which are known to be symptoms of bugs (sometimes). Which static analyzer does that? The tools I know of consider an explicit cast to (void) to indicate a deliberately unused value. They would not warn about such an expression. -- Greg Parker gp...@ap... Runtime Wrangler |
|
From: Matthias S. <zz...@ge...> - 2016-01-19 20:51:08
|
Am 17.01.2016 um 21:57 schrieb Matthias Schwarzott: > Am 17.01.2016 um 21:32 schrieb Florian Krohm: >> Hi Matthias, >> >>> >>> Third: The compiler is not allowed to optimize away the read access to >>> format. so we should get rid of the volatile. >>> >>> The simpler solution to cast format to void works for me. >>> I could today only check with gcc-5.3.0 and clang-3.7 but these two were >>> happy about this solution: >>> >>> (void)format; >>> >>> I hope msvc will like it too. >> >> Maybe msvc likes that. But static analysis tools may say that >> (void)format; is a statement with no effect which are known to be >> symptoms of bugs (sometimes). >> I was tempted for a moment to use: if (format) return; >> which would kill your warning as well, but then VALGRIND_PRINTF would be >> a function without effect and I know at least one checker that would >> complain about that. >> So I'm leaving the volatile in there. It'll shut up any compiler for good. >> > My only remaining point is that until now there was the guarantee that > absolutely no code is emitted when NVALGRIND is defined. > This is no longer valid with the commited solution. > > There is the different solution: > > Add the gcc attribute unused to the parameter. I hope this can be > applied for clang also, but I do not understand the current ifdef around > the declaration with __attribute__ (#if defined(__GNUC__) || > defined(__INTEL_COMPILER) && !defined(_MSC_VER)). > > The attribute code could also be cleaned by defining a macro > __attribute__ if the compiler does not support it (or defining a macro > __VALGRIND_ATTRIBUTE to not pollute the namespace). > > And then add some other code like that (without volatile) to silence MSVC: > > #if defined(_MSC_VER) > (void)format; > #endif > The attached patch implements exactly this (with just defining __attribute__ for not-supporting compilers). Matthias |
|
From: Matthias S. <zz...@ge...> - 2016-01-19 20:47:57
|
Am 18.01.2016 um 08:54 schrieb Florian Krohm: > On 18.01.2016 03:52, Bart Van Assche wrote: >> >>> uintptr_t: >>> I do not unerstand why this type is needed and we cannot use unsigned >>> long instead. svn archeology did not reveal anything except that Bart >>> might know. >> >> MSVC uses the LLP64 model. This means that the "long long" type is 64 >> bits and also that the type "long" is only 32 bits wide. See e.g. >> https://blogs.msdn.microsoft.com/oldnewthing/20050131-00/?p=36563. >> > > I'm confused. coregrind/m_execontext.c has this: > > vg_assert(sizeof(void*) == sizeof(UWord)); > To make this assert checked for all platforms either it need to be part of valgrind.h or we need a test-build that compiles this assert for all relevant platforms. > and include/pub/tool_basics.h has this: > > typedef unsigned long UWord; > Does it make sense to have a valgrind.h-specific define for the unsigned type with size matching a pointer? Regards |
|
From: Philippe W. <phi...@sk...> - 2016-01-19 20:28:57
|
On Tue, 2016-01-19 at 11:46 +0100, Julian Seward wrote: > Hi Philippe, > > Well done for spotting this. Question: is this a new bug (regression), > or something that has always been there? I am unclear. This is an old bug. It was already existing at least since 3.9.0 (even if the involved function has changed of name since then). Philippe |
|
From: Julian S. <js...@ac...> - 2016-01-19 10:46:23
|
Hi Philippe, Well done for spotting this. Question: is this a new bug (regression), or something that has always been there? I am unclear. J On 14/01/16 21:23, sv...@va... wrote: > Author: philippe > Date: Thu Jan 14 20:23:11 2016 > New Revision: 15759 > > Log: > fix n-i-bz false positive leaks due to aspacemgr merging non heap segments with heap segments. |