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.

Finding your Location without GPS in J2ME

Off late, the Location Based Services are the talk of town and truly the potential for those services are enormous. But the limiting factor for the wide spread use of LBS is the means of delivering those services. The best means I would say is through their mobile phones, thanks to the ever increasing penetration of the mobiles and nowadays it is hard to find anyone who is not having a mobile phone. The issue here is the finding the location of the mobile phone to deliver the required services. Sure, there are phones with GPS but they are not widespread and the effective alternative would be to use the mobie phone network to find the location of the phone.

A GSM mobile phone keeps track of four parameters that can be used to find the approximate location of the mobile they are MCC (Mobile Country Code), MNC (Mobile Network Code), LAC (Location Area Code) and CellID. Combining these four paramenter you can zero in on mobile phone's location with an accuracy of 1KM (Urban areas) to 3KM (Sub-urban and rural areas), which is quiet sufficient for some Loaction Based Services.

There are some websites that collects the cellid's across the globe like

  1. http://www.cellspotting.com/
  2. http://www.opencellid.com/

or you can sure hop into your vehicle and roam around the city to make your own database.

Now the gotchas, there is no way to extract the cellid information from most of the phones in the J2ME environment. But the sony ericsson has thoughtfully made the cellid information accessible in the J2ME environment, refer Page 72 of SE Developer Guidelines Document. But it will work only on Sony Ericsson phones that has JAVA Platform 7.3 and above.

Now, using the below APIs' you can get the CellID information in your J2ME Application


For Home Network
System.getProperty("com.sonyericsson.net.mcc");
System.getProperty("com.sonyericsson.net.mnc");

For current Network
System.getProperty("com.sonyericsson.net.cmcc");
System.getProperty("com.sonyericsson.net.cmnc");

System.getProperty("com.sonyericsson.net.cellid");
System.getProperty("com.sonyericsson.net.lac");

Now, there is a small but usefull application called Location Alarm written based on the cellID information. Try it out.

Post a comment if you have any queries.