This page describes techniques for debugging memory allocation problems.  A few examples of a memory allocation problem might be observing code crashing, exceptions on malloc() or free(), or noticing heap corruption or exhaustion issues. One method for debugging this type of problem is to use Green Hill's Run-Time Error Checking (RTEC) feature.

Run-time error checking is enabled via Builder option.  The syntax for this option is:

         -check=type[,type]… -check=type [-check=type]…

 For more informaiton, see the FAQ called "Using Run-Time Error Checking".

 Using ARMv7?

Note:  -check=alloc and -check=memory options are not supported in INTEGRITY on ARMv7, but other -check=options are supported.  Try enabling -check=all.  The -check=all option will not try to enable -check=memory or -check=alloc.  You can also individually enable -check=assignbound, -check=bouncds and -check=nilderef.

Enable CHECKED_BUILD (INTEGRITY applications, only)

Another debugging step for handling memory issues is to enable a checked build.  To do this, please see Enabling Checked Build.   With CHECKED_BUILD enabled and a rebuilt BSP, try reproducing the problem to see if you get any additional output.  

NOTE:  Be sure to Disable -check options, -DCHECKED_BUILD and -kernel=kernel_checked when you are done debugging, as this is not recommended for production builds.

Linker Wrapping

The problem occurs in the same place

If you can force the problem to reproduce in the same place, you may be ablet to set a watchpoint on the memory that is consistently being corrupted.  A watchpoint will provide information showing what code is writing that piece of memory.   Watchpoints depend on hardware breakpoints and are not supported on all targets.  See 3-step Debug Process with TimeMachine which mentions watchpoints.

Related Pages

Reduce Memory Consumption in an INTEGRITY Application

References

Check out the 'Viewing the Memory Allocation Visualization' section of MULTI: Debugging manual. 

Caveats

Note that RTEC does increase the size and reduce the speed of your application. Heap will need to be increased x 10.

Intensive memory checking may be impractical for users with memory contraints.   In this case, use general memory allocation checking (-check=alloc) for the project as a whole, with intensive checking (-check=memory) for specific modules.   See the 'Enabling Intensive Memory Allocation Checking' section of the BUILDING Applications manual.