Memory Overrun Detection

Man@log is capable of detecting memory overruns and underruns by placing a few guard bytes before and after the allocated memory. This mode consumes more memory and slows the execution, therefore it is off by default. See [How to for developers] how to activate the checks.

Once the corruption is detected, a diagnostics event is recorded in an internal buffer and the memory allocation no longer works. If any application thread attempts to allocate any more memory or if it crashes, it is suspended. Once the application appears frozen or crashed, you run Man@lyzer to gather the events from the application and saves it into the log or dumps in the analysis.

Note: when used to detect memory overruns, Man@lyzer is typically run with arguments -dump -no-stats

Basic checks (-check)

With basic overrun checks each block guard bytes are verified when the block is freed.

Extended checks (-checkEx)

With extended checking a guard bytes for a given block and a few other blocks before and after it is verified when the block is freed. Moreover, several most recent allocations are verified. This slows down the application a bit more, but highly increases the likehood the corruption will be caught soon, while being a lot faster then deep test.

Deep checks (-checkDeep, -checkDeepNNN)

With deep checks all blocks are verified on each memory allocation or free. This is very slow, but should catch any problems very quickly. To reduce the performance impact at the cost of reduced detection accuracy you can provide a number N determining the check is done only each NNN-th memory operation. When NNN is not provided, checking is done on each memory operation.

(Planned optimization, not implemented yet) Deep checks are running as a background job, in parallel with the continued application execution, each check blocks if it is not finished yet when the next allocation takes place.

Smart checks (-checkSmart, -checkSmartNNN)

(not implemented yet)

Combines deep checks (done each NNN, NNN=1000 by default) with extended checks and a few more heuristic checks for last recently allocated blocks.

Regular checks (-checkTimerNNN)

(not implemented yet)

Regular checks run a background job continuously, with a user defined delay of NNN microseconds in between. When a memory allocation happens during the check, it blocks until the check completes. Regular and deep checks can be combined together.