Heap Corruption 2

[jamez05]

Hi,

Need help trying to debug my program. I'm using visual stuidio.net C++ on Windows. I'm getting a debug error:
HEAP CORRUPTION DETECTED:before Normal block (#46769) at 0x07D636C0. CRT detected that the application wrote to memory before start of heap buffer.

I've tried looking at it in debug mode, but it makes no sense. When I search the internet, everything seems to refer to writing to memory after the start of heap buffer instead of before. How do I go about learning to interpret this and figure it out?

Thanks

James

 

[Salem]

> before Normal block ([red]#46769[/red]) at [blue]0x07D636C0[/blue].
Are either of those numbers constant, or at least reasonably predictable?

The red number is the block number of the allocation. There is a memory debug variable [tt]_crtBreakAlloc[/tt] which allows you to stop when that block is allocated.

At the start of your program (put a break on the first line), assign that variable with the # number which appears, then run the code. The debugger will resume when that block is allocated.

With the .net debugger, you can then insert a data breakpoint to break when the contents of a memory location is changed. Set one of these up for the address which is reported.

With any luck, this data access breakpoint will occur, and show you the exact line of code which is the problem.


--
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.

 

[cpjust]

Also, to know exactly where and how much you are overflowing a buffer, break just before the operation that causes the problem, then copy the address of the pointer that's overflowing and look at that location in the Memory window.
You should see four 'FD' hex bytes before and after the block of memory that's allocated to that pointer.
Now step over the line that causes the problem. The Red text in the Memory window shows which bytes were changed. If the four 'FD' bytes before or after your memory were changed, then you definitely overflowed the buffer.
Either fix the pointer location you're writing to, write less data, or allocate more memory.

For example, functions like strcpy() are dangerous since there is no limit on how many bytes they can write to the destination. Using strncpy() helps to prevent writing too much data to the destination...

 

[jamez05]

Thanks,

I will be trying both of your suggestions shortly. Those numbers are easily predictable, tracked down of the situations that caused the error already, however getting it agian