Heap block corrupted

[scrognoid]

I and a colleague (evankw21) have been beating our head on the wall for over a week over a "heap block corrupted" error. Normal Debug checks are not finding the problem. In searching Help, I find a few tools that might help, such as "full page heap" and the NTSD debugger and a routine called _heapchk from C. Before I pursue any of these I'd like to know: Can I use these tools in Fortran?

[jimdempseyatthecove]

Is the error reproducible?
By reproducable I mean is the same node (address) corrupted?

When running with the debug heap (which reports this error), allocations include preamble and post-amblesignature guard bytes:







A typical error in writing out of bounds is typically one cell before or after the "allocated" memory (the ).
This will "trash" the affected signature guard bytes.

The debug heap assert will tell you what heap node was trashed, but I cannot recall if it tells you the address of the affected guard bytes. If you get the node address, you can use the memory window of the debugger to examine the memory block including the guard bytes. The guard bytes in intptr_t sized units (4 or 8 bytes) will be a repeating pattern (e.g. 0xCCCCCCCC or 0xCECECECE or something else that stands out). This repeating pattern will be several machine words long (same number on each side). Your task then is to identify which guard bytes were corrupted. This will generally be the preamble or post-amble with the fewer of the repeating guard byte sequence.

When the error is reproducable (to the same heap node address), then with a little work you can identify the allocation the problem.

First, start the program and run to a break point (first statement will do).
Set break point on data change entering in the hex address of the guard bytes you suspect were trashed. (use C addressing format and 4 bytes for size).
Then continue.
Expect a break when the memory is allocated (and the guard bytes initialized).
Continue from this break.
Next break may be from either a) your bug, or b) deallocation of node.
If a) then you found your bug
If b) then continue, run till break at next allocation of same node, and continue
Repeat until bug found.

The above will catch indexing out of range.

The above will NOT catch referencing a deallocate object. To catch referencing a deallocated object...

Perform a find in files for deallocatewithin your entire solution.
Every place you have a deallocate:

a) if the object is a pointer NULLIFY the pointer (after deallocation). What this will do is cause a subsequent errant reference to trap on writing to memory in the low 4KB address space.

b) if the object is an allocatable, see if the allocatable has TARGET attribute (use second search results window such that you do not trash your list of deallocations). If not TARGET then no pointers are permitted so continue to next deallocation. If TARGET .AND. if locatedmodule "static"data thendescriptor is persistent so continue to next deallocation.When allocatable w/TARGET appears as stack variable (transient descriptor) thensearch (using second search results window) for => containing the allocatable. This may be harder to do when the pointer assignment is made in function/subroutine call by way of dummy argument. In this case it only matters when the pointer is a persistent pointer (declared in module or inside user defined type).

The above may get you started.

Jim Dempsey