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
(2) |
6
|
7
(1) |
8
(1) |
9
|
10
(1) |
11
|
|
12
(3) |
13
(3) |
14
(3) |
15
(4) |
16
(3) |
17
|
18
(3) |
|
19
(1) |
20
(1) |
21
(3) |
22
|
23
|
24
(1) |
25
(3) |
|
26
|
27
(2) |
28
(10) |
29
|
30
(2) |
31
(2) |
|
|
From: John R. <jr...@bi...> - 2019-05-13 14:15:58
|
Julian Seward wrote:
>
> I would prefer this:
>
> Original:
> Address 0x51d8048 is 8 bytes inside a block of size 15 alloc'd
>
> Extended:
> Address 0x51d8048 is 8 bytes inside a block of size 15 with base address 0x51d8040, alloc'd
>
> In particular I'd prefer to not use the [0x51d8040, +15) notation since I
> think many users won't know what it means, or at best will be uncertain
> what it means.
Having the explicit base address of the block makes it easier to correlate blocks
by sight or by text processing, and also makes it easier to check the alignment
of the block. The base address is computable as the difference (0x51d8048 - 8),
but mental subtraction is less reliable than addition.
From first principles I prefer all information on the same line:
Accessed interval [0x51d8048, +4) begins 8 bytes after the block [0x51d8040, +15)
where each base address, size, and offset is explicit.
The notation for half-open interval has been in use for at least many decades.
>
> Philippe, are you proposing this as a change to the default output, or to be
> available only when specifying a flag? I'm reluctant to change the default
> output here, since this actually adds redundancy to the error messages which
> in general are already long, verbose, and (at least so it seemed in early
> years of the project) which users sometimes don't read entirely.
Short redundancy which increases communication is good!
|
|
From: Julian S. <js...@ac...> - 2019-05-13 10:22:13
|
I would prefer this: Original: Address 0x51d8048 is 8 bytes inside a block of size 15 alloc'd Extended: Address 0x51d8048 is 8 bytes inside a block of size 15 with base address 0x51d8040, alloc'd In particular I'd prefer to not use the [0x51d8040, +15) notation since I think many users won't know what it means, or at best will be uncertain what it means. Philippe, are you proposing this as a change to the default output, or to be available only when specifying a flag? I'm reluctant to change the default output here, since this actually adds redundancy to the error messages which in general are already long, verbose, and (at least so it seemed in early years of the project) which users sometimes don't read entirely. J |
|
From: Mark W. <ma...@kl...> - 2019-05-13 09:59:52
|
On Sun, 2019-05-12 at 22:01 +0200, Ivo Raisr wrote: > > This is a good idea! It allows correlation with vgdb and other > > tools, > > and sometimes even between consecutive runs (requires some > > determinism.) > > > > > Other suggestions ? > > > > I also like > > ==18039== Address 0x51d8048 is 8 bytes inside [0x51d8040, +15) > > alloc'd > > using the notation for "closed (inclusive) on the lower end, > > open (exclusive) on the higher end". > > > > John's idea is really nice. > Mine is only a minor variation: > Address 0x51d8048 is 8 bytes inside a block of 15 bytes allocated > from > [0x51d8040, 0x51d804f]. > > Inclusive on both ends. But that's only my own preference. > Ivosh I don't like the redundancy. All variants proposed reproduce information that is already available. Personally I wouldn't change the current format since people are used to it now. And I don't really understand what new information is provided or how/when it is used. But that might just mean I am using it wrong, so examples how this is more helpful certainly welcome. If we changed the format I would go with a variant of Ivo's suggestion, but with the redundant information removed: "Address 0x51d8048 is inside block [0x51d8040, 0x51d804f] allocated at" Cheers, Mark |