OSDev.org

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.
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.
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 ~

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.

iansjack wrote: 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.

iansjack wrote: 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.