Memory Leaks in BREW Applications

The memory leaks are one of the worst possible nightmare for any developer, so for an BREW developer. If your application has memory leaks, it will make your application gradually slow and eventually fail at a random point and at a random time which makes it very difficult to debug.

Fortunately, BREW Simulator provides debug messages that will help us find the memory leaks in the code. The BREW Simulator will show "Module failed to free all memory" warning if you exit the application without freeing all the memory that are allocated and also it will print the BPOINT debug messages in the Output log window indicating the place where the memory leak is happening. If you are running the code in the phone, you can connect the BREW Logger to see the debug messages.

The following messages tells you that in testapp.c at line 338 and 339 memory is allocated which is not freed.

*OEMOS.c:581 - BPOINT Type 1, Node 0x027EF708 testapp
*AEEHeap.c:1253 - ------ App Heap Info ------
*AEEHeap.c:1155 - 256 - testapp #1336 d:\source\testapp.c:338 (L)
*OEMOS.c:581 - BPOINT Type 1, Node 0x027EF838 mobistream
*AEEHeap.c:1155 - 64 - testapp #1337 d:\source\testapp.c:339 (L)
*AEEHeap.c:1267 - -------------------------

The problem with the most of the new developers is they are keen to make the functionality work without paying attention to best practices and designing. A little time to design before coding can save you a great deal of debugging time.

Now, The most common reasons for memory leaks are

1. Allocating memory using MALLOC and failing to FREE it.
2. Creating an instance and failing to release it.
3. Loading an Image from the resource file and failing to release it.

Allocating memory using MALLOC and failing to FREE it.

When you allocate memory for a variable make sure you free it somewhere. Sometimes even if you have freed the variable you might get a leak at that point. In such cases, the MALLOC may be called multiple times and the FREE is called just once. Make sure the number of calls to MALLOC matches the number of calls to FREE.

Creating an instance and failing to release it.

Every BREW Instance created must be released before exiting the application. If you have falied to release a instance even the BPOINT messages will not be usefull as it will point to some AEE files. Whatever that have been written for MALLOC/FREE will apply to CreateInstance/Release pair. Make sure the number of calls for CreateInstance for a variable matches the number of calls to Release of that variable. Use the safe release macro mentioned here to avoid dangling pointers.

Loading an Image from the resource file and failing to release it.

When you load an image from a resource file using ISHELL_LoadResImage() or a equivalent API make sure you release the IImage pointer it returns after use. It is one such case of API's returning instances, another API is IADDRBOOK_EnumNextRec() which returns the IAddrRec, which should be released after use. In short, if you are getting a instance pointer from an API you have to release the instance pointer after using it. The only exception to this behaviour is IDISPLAY_SetFont() for which the handling is different (see API ref for details).

Please leave me a comment, if you have any feedback.