ISHELL_CreateInstance - .........._Release
Thu, 06/12/2008 - 02:21
Forums:
My project has a memory consumption of about 2 KBytes after about 10 runs. I suspect there may be some memory leak. However there are neither "Wasted" report or any leak reported by (L) , nor any BPOINT messages.
I want to check all objects created by ISHELL_CreateInstance are destroyed by (interface_name)_Release.
Are there any easy way to calculate this? I redefined ISHELL_CreateInstance and encapsulated this method, now it counts how many ISHELL_CreateInstances are used. Are there any way to calculate the Releases?
Thu, 06/12/2008 - 17:32
Greg wrote: I assume that you are also intercepting all MALLOC/FREE and new/delete calls as well?
yes I prepared the same code snippet for the MALLOC-FREE pairs. there are no delete-new pairs
Quote:Since you are not getting any reports of a memory leak from BREW, how are you determining that you are leaking those 2 KB? The only thing I would make sure is that you are looking at the total free memory instead of the largest block available.
I use a test application running on actual handset that shows free memory. The value goes down about 1,5 KB for the first run after cold restart, then about 50 ~ 100bytes every run.
Greg wrote: I assume that you are also intercepting all MALLOC/FREE and new/delete calls as well?
yes I prepared the same code snippet for the MALLOC-FREE pairs. there are no delete-new pairs
Quote:Since you are not getting any reports of a memory leak from BREW, how are you determining that you are leaking those 2 KB? The only thing I would make sure is that you are looking at the total free memory instead of the largest block available.
I use a test application running on actual handset that shows free memory. The value goes down about 1,5 KB for the first run after cold restart, then about 50 ~ 100bytes every run.
Thu, 06/12/2008 - 22:53
r u facing some other problem due to this?? it may be due to some other reasons.
try this-
Just do a return SUCCESS from Applet-Initialise method and display a message at APP_START and return TRUE. then recheck the memory status.
r u facing some other problem due to this?? it may be due to some other reasons.
try this-
Just do a return SUCCESS from Applet-Initialise method and display a message at APP_START and return TRUE. then recheck the memory status.
Tue, 06/17/2008 - 00:36
shivendra wrote:
Just do a return SUCCESS from Applet-Initialise method and display a message at APP_START and return TRUE. then recheck the memory status.
do you mean AEEApplet_New ?
shivendra wrote:
r u facing some other problem due to this?? it may be due to some other reasons.
yes , simulator crashes during returning to visual studio (not during applet termination). I know it is difficult to say anything without any code and details, maybe later I will submit new info and new question.
thank you..
shivendra wrote:
Just do a return SUCCESS from Applet-Initialise method and display a message at APP_START and return TRUE. then recheck the memory status.
do you mean AEEApplet_New ?
shivendra wrote:
r u facing some other problem due to this?? it may be due to some other reasons.
yes , simulator crashes during returning to visual studio (not during applet termination). I know it is difficult to say anything without any code and details, maybe later I will submit new info and new question.
thank you..
Tue, 06/17/2008 - 02:56
in simulater, you'll get debug information if there is memory leak
in simulater, you'll get debug information if there is memory leak
Tue, 06/17/2008 - 12:42
As dragonlee cites, the simulator will indicate to you if you have a memory leak. Note, however, that you will need to do a proper exiting of the app. Meaning, if you just hit END CALL, it will not terminate through the proper chain to report any memory leaking.
As dragonlee cites, the simulator will indicate to you if you have a memory leak. Note, however, that you will need to do a proper exiting of the app. Meaning, if you just hit END CALL, it will not terminate through the proper chain to report any memory leaking.
Tue, 06/17/2008 - 17:09
mobileben wrote:As dragonlee cites, the simulator will indicate to you if you have a memory leak. Note, however, that you will need to do a proper exiting of the app. Meaning, if you just hit END CALL, it will not terminate through the proper chain to report any memory leaking.
you say BREW environment is %100 (or so) safe about catching memory leaks then.. thx
mobileben wrote:As dragonlee cites, the simulator will indicate to you if you have a memory leak. Note, however, that you will need to do a proper exiting of the app. Meaning, if you just hit END CALL, it will not terminate through the proper chain to report any memory leaking.
you say BREW environment is %100 (or so) safe about catching memory leaks then.. thx
Thu, 06/12/2008 - 10:52
I believe that IBase_Release is the counterpart to ISHELL_CreateInstance (really IBase_AddRef), but unfortunately because I think the calls to that function are all internal to BREW, I don't think you can do the same things for that function. I assume that you are also intercepting all MALLOC/FREE and new/delete calls as well?
Since you are not getting any reports of a memory leak from BREW, how are you determining that you are leaking those 2 KB? The only thing I would make sure is that you are looking at the total free memory instead of the largest block available.
I believe that IBase_Release is the counterpart to ISHELL_CreateInstance (really IBase_AddRef), but unfortunately because I think the calls to that function are all internal to BREW, I don't think you can do the same things for that function. I assume that you are also intercepting all MALLOC/FREE and new/delete calls as well?
Since you are not getting any reports of a memory leak from BREW, how are you determining that you are leaking those 2 KB? The only thing I would make sure is that you are looking at the total free memory instead of the largest block available.