How about store 'structure' and 'buffer' in different heap?

[miaowei]

During my programming on a text parser( write in C), i got an idea that we can put data structure far away from 'text buffer' in linear space.

Code: Select all

char *linebuf = malloc(1024);
struct line *lobj = malloc( sizeof (struct line) );

Then *linebuf and *lobj will probably be neighbors in linear space. And, since the insert/delete/paste operations on a text buffer is quite frequently, if an out-of-bounds write to his neighbor *lobj occurs, the debug will be difficult.
Glibc can discover out-of-bounds write behavior when it detects the heap corruption, but it's after event, and the assertion it throws out is not very useful.

How about put *lobj to another heap which is far away from common heap, it seems C library doesn't provide such API, but we can use mmap() to allocate memory far away from sbrk() area and default mmap() area, like, at 2.5GB address.

Code: Select all

char *linebuf = malloc(1024);
void *another_heap = mmap(0x100000*2560, 0x1000, 
											PROT_WRITE | PROT_READ, 
											MAP_PRIVATE|MAP_ANONYMOUS, -1,0););
struct line *lobj = another_heap;

We put our important data structures there.(just like an island).
Such mechanism can't eliminate or supress out-of-bouds writing, but the debug will be easier. (wired pointer not considered here).

I know the best method to avoid 'out-of-bouds' writing is to keep clear mind when programming, but this seems to be a good mechanism in the initial(buggy) stage of the development, just as assert().

I want to hear from you ~

[iansjack]

If an out of bounds write corrupts a structure or buffer that has no connection to the buffer being accessed, I think that debugging will be even more difficult. At least if the two data areas share a common connection it is likely that corruption will be detected soon after it occurs. But if there is no connection, it may be quite a while until the corruption reveals itself. Trying to backtrack to the source of the corruption will be difficult.

I have found it useful, when a particular area of memory is being corrupted, to put a watch on that area in gdb. Then you can stop the program at the exact moment that the corruption occurs, which makes it much easier to trace the error.

[miaowei]

I have found it useful, when a particular area of memory is being corrupted, to put a watch on that area in gdb.

Yes, watch is useful. In my memory, I met 'out-of-range' writing twice ever and both i found the reason using watch.
The detail is interesting, one time, i was using gdbstub of bochs which doesn't support hardware watchpoint so i had to install ubuntu in VBOX and compiled bochs in it using another option "--enable-debugger' rather than '--enable-gdbstub'. It worked.
The other time, I was still using gdbstub and i was no longer lucky. I was using a low-performance computer and I couldn't install virtual machine in virtual machine any more, so I have to change bochs's source code to let it support hardware watchpoint in gdbstub mode. (Not very difficult, i remeber i added two lines of code only）。　It also worked.

But the problemis that, we usually need a long time to find out where of the memory was altered before we could use watch.

At least if the two data areas share a common connection it is likely that corruption will be detected soon after it occurs. But if there is no connection, it may be quite a while until the corruption reveals itself.

For other programs, i agree with you, I also like cracking once a mistake occurs. But for the program i am writing, separating data structure from string buffer should obtain more benefit. In debug version, i make a double check when walks along a string: the data structure records its length , and the string itself has EOL. If my data structures were not damaged, the program should be able to capture a silent 'out-of-range' writing just happened in string buffer.