|
From: Philippe W. <phi...@sk...> - 2019-05-12 15:31:38
|
Currently, when a block is described (e.g. in an error message), valgrind pub_tool_addrinfo.h VG_(pp_addrinfo) and VG_(pp_addrinfo_mc) do not print the block address. At work, I received some suggestions that adding the block address will improve the block descriptions and error messages. It will e.g. help to make the offset given in the error message more clear. Also, giving the block address can be useful to link with application trace of allocated memory. Currently, in an error, valgrind outputs a description such as: ==18039== Address 0x51d8048 is 8 bytes inside a block of size 15 alloc'd ==18039== at 0x4C2BF3D: malloc (vg_replace_malloc.c:309) ==18039== by 0x108751: main (badpoll.c:12) Here follows some possible ways to show the block address in the first line: ==18039== Address 0x51d8048 is 8 bytes inside a block (0x51d8040) of size 15 alloc'd ==18039== Address 0x51d8048 is 8 bytes inside a block at 0x51d8040 of size 15 alloc'd ==18039== Address 0x51d8048 is 8 bytes inside a block address 0x51d8040 of size 15 alloc'd Feedback ? Other suggestions ? Thanks Philippe |
|
From: John R. <jr...@bi...> - 2019-05-12 19:33:01
|
On 5/12/19 8:15 AM, Philippe Waroquiers wrote: > Currently, in an error, valgrind outputs a description such as: > ==18039== Address 0x51d8048 is 8 bytes inside a block of size 15 alloc'd > ==18039== at 0x4C2BF3D: malloc (vg_replace_malloc.c:309) > ==18039== by 0x108751: main (badpoll.c:12) > > > Here follows some possible ways to show the block address in the first line: > ==18039== Address 0x51d8048 is 8 bytes inside a block (0x51d8040) of size 15 alloc'd > > ==18039== Address 0x51d8048 is 8 bytes inside a block at 0x51d8040 of size 15 alloc'd > > ==18039== Address 0x51d8048 is 8 bytes inside a block address 0x51d8040 of size 15 alloc'd > > Feedback ? 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". |
|
From: Ivo R. <iv...@iv...> - 2019-05-12 20:01:24
|
> 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 > > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
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 |
|
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: 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: Philippe W. <phi...@sk...> - 2019-05-14 03:48:31
|
On Mon, 2019-05-13 at 12:22 +0200, 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. > > 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. Another possible layout is: Address 0x51d8048 is 8 bytes inside a block 0x51d8040[15] alloc'd That is short, and should be understandable by most people that have done some c or c++ or syntactically similar languages. Otherwise, yes, I was thinking to change the default output. But seeing how many people are preferring very different layout, maybe we better have an option to indicate what layout the user wants. Philippe |