Reading or writing beyond array bounds or allocation ends
Reading a value from the start or end of the range of an array or other allocation is difficult.
Much of the time, it can go unnoticed, but it can also cause intermittent crashes, where the likelihood of a crash occurring or not depends on the tiniest of changes in runtime environment.
- Reading a value means polluting a calculation, as the resulting value or code path now depends on something unreliable and uncertain.
- Writing to such a location can cause uncertain behavior in other areas of the code that then re-use this now corrupted location.
- Both reading and writing can cause a crash if the address is outside of the program's allocated pages (usually 4096 bytes but some systems use much larger pages).
DDT prevents these kinds of error by working with the operating system to create a page after, or before, each allocation and makes it read and write protected. As soon as the protected memory is touched for a read or write, the Linux O/S notifies the debugger. This is known as Guard Pages, also known as Red Zones.
For codes with a relatively small number of large allocations, such as most scientific codes, and most F90 codes, the number of pages used as guard pages is small.
C++ codes often use significantly many small allocations and can exhaust process limits. For these types of codes DDT, offers an alternative setting known as fence checking or fence painting. This periodically validates a few bytes above and below an allocation to check for unexpected writes.
Note: This mode only checks writes, it cannot detect erroneous reads, and therefore Guard Pages mode is generally preferred where possible for a code.