Memory leak prevention methodogies | developer.brewmp.com Memory leak prevention methodogies | developer.brewmp.com

Developer

Memory leak prevention methodogies

Hi all,
I’m studying a problem releated to memory leakage especially in embedded programming.
Now, there are many tools to check memory leakake at run-time (dynamic analysis), and some tools can check memory leakage at compile-time (static analysis). But I have some questions:
How do you think to prevent memory leakage from coding phase (without using tool)? (or In coding phase, what do you have to do to prevent memory leakage?)
For ex: Using coding guide line, Use template libraries, ...
I want to investigate from many programmers in many countries.
Can you help me?

coding phase
- basically coding guidelines and usage of code templates.
- review based in guidelines
development stage on simulator
BREW simulator provides memory leak messages in logs..
examples of such a log message is given here..
http://brewforums.qualcomm.com/showthread.php?p=60901#post60901
Target testing stage
-Similar messages (like in simulator) are also produced on target phones, we need to use logger tools like BREW logger or QXDM to capture such messages..
-Heap tracking using various tools.

coding phase
- basically coding guidelines and usage of code templates.
- review based in guidelines
development stage on simulator
BREW simulator provides memory leak messages in logs..
examples of such a log message is given here..
http://brewforums.qualcomm.com/showthread.php?p=60901#post60901
Target testing stage
-Similar messages (like in simulator) are also produced on target phones, we need to use logger tools like BREW logger or QXDM to capture such messages..
-Heap tracking using various tools.

Document on debugging BREW application. Also mentions about various debug messages and BREW debug codes.
PROG-805- BREW Application Debugging for Developers and OEMs
http://brew.qualcomm.com/bnry_brew/pdf/brew_2007/Prog-805_Fryckman_v01.pdf

Document on debugging BREW application. Also mentions about various debug messages and BREW debug codes.
PROG-805- BREW Application Debugging for Developers and OEMs
http://brew.qualcomm.com/bnry_brew/pdf/brew_2007/Prog-805_Fryckman_v01.pdf

The device I was testing (Sanyo KATANA) doesn't seem to recollect leaked memory if my app is restarted. The leaked memory is still counted against my module.
What's the word from Qualcomm, is the garbage collection logic responsibility of Qualcomm of OEM?

The device I was testing (Sanyo KATANA) doesn't seem to recollect leaked memory if my app is restarted. The leaked memory is still counted against my module.
What's the word from Qualcomm, is the garbage collection logic responsibility of Qualcomm of OEM?

Memory leak prevention is important during development and QA, I agree.
However for a complex module, my experience is that no matter how hard you try (and sometimes under release schedule pressure or whatever), you just cannot capture all the leaks. For a service module that runs all the time, it'll eventually be a problem to the module itself as well as the device.

Memory leak prevention is important during development and QA, I agree.
However for a complex module, my experience is that no matter how hard you try (and sometimes under release schedule pressure or whatever), you just cannot capture all the leaks. For a service module that runs all the time, it'll eventually be a problem to the module itself as well as the device.

You are responsible to free the memory you allocate -- there is no excuse. If the emulator or development tools used do not assist with this, build your own memory tools that track every piece of memory and report on those unfreed (for development only, not in production).
Building your own simple memory tracking system is a worthwhile task; one will learn a lot and current and future projects will benefit greatly.

You are responsible to free the memory you allocate -- there is no excuse. If the emulator or development tools used do not assist with this, build your own memory tools that track every piece of memory and report on those unfreed (for development only, not in production).
Building your own simple memory tracking system is a worthwhile task; one will learn a lot and current and future projects will benefit greatly.