|
From: wim d. <wim...@ad...> - 2004-12-08 11:33:06
|
Hi all, I get the above message. Now 0 bytes AFTER how should I interpret it. 0 after is for me the last alloced byte to it should be ok, no ? W |
|
From: Tom H. <th...@cy...> - 2004-12-08 11:42:32
|
In message <200...@ad...>
wim delvaux <wim...@ad...> wrote:
> I get the above message. Now 0 bytes AFTER how should I interpret
> it. 0 after is for me the last alloced byte to it should be ok, no?
No, zero bytes after is the first byte after the block. If you imagine
that you have a pointer to the end of the block and then add that
number of bytes to it then that gives you the pointer through which
your program was trying to read/write.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-12-08 19:40:58
|
On Wed, 8 Dec 2004, Tom Hughes wrote: >> I get the above message. Now 0 bytes AFTER how should I interpret >> it. 0 after is for me the last alloced byte to it should be ok, no? > > No, zero bytes after is the first byte after the block. If you imagine > that you have a pointer to the end of the block and then add that > number of bytes to it then that gives you the pointer through which > your program was trying to read/write. I wonder if that message should be changed to say 1 byte after -- enough people get confused by this that it could be worthwhile. N |
|
From: Dennis L. <pla...@in...> - 2004-12-08 21:37:22
|
At 20:40 08.12.2004, you wrote: >On Wed, 8 Dec 2004, Tom Hughes wrote: > >>>I get the above message. Now 0 bytes AFTER how should I interpret >>>it. 0 after is for me the last alloced byte to it should be ok, no? >> >>No, zero bytes after is the first byte after the block. If you imagine >>that you have a pointer to the end of the block and then add that >>number of bytes to it then that gives you the pointer through which >>your program was trying to read/write. > >I wonder if that message should be changed to say 1 byte after -- enough >people get confused by this that it could be worthwhile. Maybe Im the only one but I have never been confused by it since I always took this as some kind of index... like when doing : 1: int* r = new int[10]; 2: r[10] = 5; 3: delete[] r; 4: r[0] = 5; 5: r[4] = 5; valgrind tells me 2: 0 bytes after a block of 40 ... so I take p = "pointing to right after the block" and p[0] would be where I accessed the memory... so right the first element after it... if I would then acces p[1] (as int) it would write 5 bytes after (with the 1 byte after suggestion) which is just more confusing since int is 4 bytes here. 4: is 0 bytes *inside* a block so I simply know "ah, I accessed r[0]" 5: is 16 bytes *inside* a block so I know "ah, I accessed r[16/sizeof(int)]" so doing it the same way when inside, as after the block just seems natural to me... greets Dennis Carpe quod tibi datum est |
|
From: Steve F. <sf...@re...> - 2004-12-09 18:23:28
|
Nicholas Nethercote wrote: > On Wed, 8 Dec 2004, Tom Hughes wrote: > >>> I get the above message. Now 0 bytes AFTER how should I interpret >>> it. 0 after is for me the last alloced byte to it should be ok, no? >> >> >> No, zero bytes after is the first byte after the block. If you imagine >> that you have a pointer to the end of the block and then add that >> number of bytes to it then that gives you the pointer through which >> your program was trying to read/write. > > > I wonder if that message should be changed to say 1 byte after -- enough > people get confused by this that it could be worthwhile. But then figuring out the address is kind of weird. How about "bad stuff happened at byte offset 0 after an allocation of size..." or "bad stuff happened at byte offset 0 into the range following an allocation of size..." "bad stuff happened at byte offset 0 into the range just after an allocation of size..." "bad stuff happened at byte offset 0 after the end of an allocation of size..." |
|
From: Paul P. <ppl...@gm...> - 2004-12-10 03:37:48
|
On Wed, 08 Dec 2004 12:21:45 -0800, Steve Fink <sf...@re...> wrote:
>
> "bad stuff happened at byte offset 0 after an allocation of size..."
I don't think any of the alternatives are really better.
Perhaps you can take a leaf from competition :-)
Here is how Insure++ does it (best viewed in fixed font):
$ cat junk.c
#include <stdlib.h>
int main()
{
char *p = malloc(1), *q = p+1;
*q = 'a';
return 0;
}
$ insure gcc -g junk.c && ./a.out
[junk.c:5] **WRITE_OVERFLOW**
>> *q = 'a';
Writing overflows memory: q
bbbbb
| 1 | 1 |
wwwww
Writing (w) : 0x0804a4b9 thru 0x0804a4b9 (1 byte)
To block (b) : 0x0804a4b8 thru 0x0804a4b8 (1 byte)
p, allocated at junk.c, 4
malloc() pc: 0x4004cb27 (interface)
main() pc: 0x08048e2e junk.c, 4
Stack trace where the error occurred:
main() pc: 0x08048f5f junk.c, 5
|