Resources | developer.brewmp.com Resources | developer.brewmp.com

Developer

resources

Heap Corruption

The Component Heap Tracker can either cause a break when it detects a heap corruption, or print information about the corruption on QXDM. The user controls these features through settings in an .ini file.

The HeapFault parameter in the .ini file controls whether the CHT will break. The Heap1Trace parameter in the .ini file controls whether the CHT prints an entry on QXDM when a corruption is detected.

Using the break option on a device requires JTAG hardware. QXDM is a tool available to manufacturers.

Memory corruptions can be caused by:

  • buffer overrun
  • usage after free
  • double free
  • random corruption

Buffer overrun

Buffer overruns happen when the application writes past the end of the allocated heap node. The detection mechanism relies on the heap node validation, which is called when the node or adjacent nodes are allocated or freed. The validation will catch the memory overrun only if the heap node header or trailer is corrupted. The validation doesn't catch the problem if the application leaves the heap node header and trailer unchanged.

The heap node padding feature of CHT may help debugging a buffer overrun by adding extra bytes to the end of the heap nodes. At the time the heap node is freed CHT will check the pattern to catch the memory overrun.

The user can specify the number of extra bytes by setting the OverRunSize parameter in the .ini file.

Usage after free

In this type of corruption, the owner of a heap node continues to write to the heap node after having freed it. In such a scenario, the heap node may end up allocated to a new owner. If the prior owner continues to write data, this corrupts the new owner's data.

The Brew MP heap supports a feature called delayed free. In this mode, the heap doesn't immediately free the node when an application frees a node. Instead the heap puts the node in a delayed free list. When the free list gets full, the heap frees the oldest heap node on the list.

The delayed free can help avoid this problem, but may not help catch the problem.

The size of the delayed free list is controlled with the DelayedFreeCount .ini parameter.

Double free

A double free happens when an application frees a heap node that has been freed already. There are two scenarios depending on when the second free happens. If the second free happens when the freed node has not yet been allocated, the heap knows this is a double free and will inform the CHT, and CHT will report the error.

If the second free happens after the freed node has been allocated again, the problem is detected after the allocated node is freed. The delayed free feature of the CHT can be useful for debugging this type of corruption. With delayed free, the freed heap nodes are not immediately available for allocation to another client. This makes it more likely that the node will be freed again prior to being allocated to another client, which will be detected and reported by the CHT.

The size of the delayed free list is controlled with the DelayedFreeCount .ini parameter.

Random corruption

Random heap corruption can be very difficult to debug. There is no a single technique for debugging this type of problem. A developer may try:

  1. Debugging the memory corruption using the Component Heap Tracker.
  2. Code review.
  3. Leverage ETM.