In the past it’s often been the case that I try using a particular Symbian tool or API only to have it fail on me. The usual strategy is to look on the Nokia and Symbian developer sites for examples or workarounds. Sometimes you just can’t get it working and you end up using some weird or difficult workaround of your own. Over time you build experience and have a kit bag of arounds and techniques. Unfortunately, you never know when the broken API or tool is fixed and you carry on regardless.

A case in point is tracking down memory leaks in Symbian. All you are given is a (sometimes random) address when the application closes. Several years ago I tried using HookLogger but never got it going. (In fact if you look on the forums there’s evidence of lots of frustrated people). Since then I have had a strict regime of fixing memory leaks as soon as I first spot them after adding extra code - as it’s so difficult to track them down later on by systematically adding and removing code, examining raw memory or casting addresses to suspect object types. 

Recently I have had to use lots of code written by someone else. It had some memory leaks and it was impractical to use my existing techniques. I hesitantly tried Hooklogger again and with the help of the latest notes on Nokia Forum Wiki it actually worked! It turns out HookLogger was updated earlier this year (even so you still need to patch the files to cater for paths with spaces).

So if you are also still avoiding HookLogger, give it a go! It will save you hours. Also, it’s a gentle reminder to me not to assume that just because things were broken, it doesn’t mean they are still this way.

This entry was posted on Thursday, November 1st, 2007 at 9:13 pm and is filed under Symbian, Series 60, Mobile. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.