HeapLogger
Article Metadata
Heaplogger version 1.
This lib is a heap investigation tool. It is designed to help track down memory leaks, to find out what is going on when you make an OS call, or… well that is about it really. It gives you the ability to log all the memory allocations and dump the heap into a log file. You can also make annotations so that you can tie the allocations back to your code. The functions are described in the header.
/**This function will go at the start of your app. It will give a config line line like
* This is the Heap Logger Dump.
* Old heap contains 000000 bytes in 000000 cells.
* If there are any cells already allocated, the old heap should be switched back
* in with User::SwitchHeap() before these cells are freed.
*
* @param aFileName is the name of the log file created
* @return the old RHeap.
*/
IMPORT_C static RHeap* HeapLogger::UseHeapLogger(const TDesC& aFileName);
/**This sets what will actually be logged. Defaults to ELogNothing
* @param aMode is an ored combination of THeapLoggerMode
*/
IMPORT_C static void HeapLogger::SetMode(TInt aMode);
/**When content is logged (on Free or a heap dump) this is the max
* length of the buffer to be logged.
* @param aMaxLen the max length to log.*/
IMPORT_C static void HeapLogger::SetMaxContentLength(TInt aMaxLen);
/**This dumps the current heap into the log file.*/
IMPORT_C static void HeapLogger::DumpHeap();
/**This allows you to put tags in the log file so that you can tie the
* allocations to sections of code.
* @param aLogStr is a tag for your code to annotate the log.
* @param this is the file, normally given by "__FILE__"
* @param this is the lin number in the source file. Given by "__LINE__"*/
IMPORT_C static void HeapLogger::Log(const TDesC8& aLogStr, const char* aFile,
TInt aLine);
To use the heaplogger, just include the header file and static lib in the mmp file, and then call the functions. You can download a hello world type example at http://homepage.virgin.net/mr.nigel.brown/examples/Lumberjack1.zip. Lumberjack just uses the logging tool to log some random things. The libs and the header file are included. The libs were compiled to Symbian 3rd MR, but should work on other Symbian OS V.9 platforms.
This works on the emulator, but there are better tools to use so this is only really useful on a target device. Also, it makes the application run so incredibly slowly when logging, that it is not useful for long term use. Just one off investigations. The log files get very big.
It all works by replacing the heap in the process with a custom one. I have used it a couple of times for real work, but it is not that well tested. It is here mostly for fun. I did have some issues with using this and target debugging on carbide, but they just went away.
Any comments, post them here.


This tools is promising and seems to work. But I'd have some questions about the log entries.
- what does ELogContentOnFree means?
This means that the content of the cell will be logged when the cell is freed.
- Could you please detail the R: (realloc?) line in the log file? An example that confuses me below. What is that 0 in the realloc?
Yes, R: is a reallocation. Here is the code.
<source>
TAny* RNBHeap::ReAlloc(TAny* aPtr, TInt aSize, TInt aMode)
{
TInt oldLen=0;
if(aPtr)
oldLen=AllocLen(aPtr);
TAny* cell=RHeap::ReAlloc(aPtr, aSize, aMode);
if(iMode & ELogRealloc)
{
TBuf<200> logStr;
_LIT(KFmt, "\nR: 0x%08x %d 0x%08x %09d %09d");
logStr.Format(KFmt, cell, oldLen, aPtr, aSize, aMode);
iLogger.Log(logStr);
}
return cell;
} </source>
A: 0x55903398 000000032
R: 0x55903398 0 0x00000000 000000032 000000000
A: 0x559033c0 000000060
A: 0x55903400 000000032
A: 0x55903428 000000028
A: 0x55903448 000000068
A: 0x559031a8 000000020
A: 0x55903490 000000048
A: 0x559034c8 000000036
A: 0x559034f0 000000068
A: 0x55903538 000000016
A: 0x55903550 000000028
D: 0x55903398 000000036 = 88319055c03390550034905528349055a8319055
R: 0x55903570 36 0x55903398 000000064 000000000
A: 0x55903398 000000024
- What is that 4bytes different on allocated and reallocated buffers. See example above where 0x559036b8 is allocated for 32bytes, and later it's 36 and
This is just the difference between size of the allocated data and the size of the cell, which contains the points to the next cell on the heap.
A: 0x559036b8 000000016
R: 0x559036b8 0 0x00000000 000000016 000000000
D: 0x559036b8 000000020 = 4e38201003030303030303030303030303030303
Thanks!
I am glad it was interesting to someone. It could probably be developed a bit more. It was just something I bashed out over a couple of days out of interest.