Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

hi guys,
am new to this forum..and to BREW SDK. I've been reading a lot of topics here but there are some things I need to ask

1. Is the "App Heap Info" a standard debug info in Brew? Been seeing
a lot in the discussions..but I can't make it come out in BREW Logger
(filter options are limited). Is this for the Simulator only?

2. How does one use the "###n" code? Where is this applied? In Simulator
or in Brew Logger?

3. Lastly...I'm trying to debug somebody else's applets which are intergrated
with several other modules and there are sometimes increases in HEAP that
are unaccounted for (I've been using IHEAP_GetMemStats).
Assuming I've already ruled out the following
a. failure to deallocate pointers
b. failure to release BREW Interface Objects
c. failure to free allocations inside BREW helper functions (e.g. STRDUP)
and still get these one-time increases, is it safe to assume that
it is BREW's internal caching that's causing this?
Is there a way to know how much of the HEAP is used by the applet
itself and how much by BREW's cache?

Whew..

Quote:
1. Is the "App Heap Info" a standard debug info in Brew? Been seeing
a lot in the discussions..but I can't make it come out in BREW Logger
(filter options are limited). Is this for the Simulator only?
You can use the DBGPRINTF() macro in the application and the output will come on the "Output" screen of the Emulator.
Quote:
2. How does one use the "###n" code? Where is this applied? In Simulator
or in Brew Logger?
This code sequence is to turn ON/OFF the debug on the device itself while your app is running. e.g. if you press "###2" you will see some single character output on the top right corner of the phone. To turn OFF press "###0". Search the Forum for details on the sequence.
Quote:
3. Lastly...I'm trying to debug somebody else's applets which are intergrated
with several other modules and there are sometimes increases in HEAP that
are unaccounted for (I've been using IHEAP_GetMemStats).
Assuming I've already ruled out the following
a. failure to deallocate pointers
b. failure to release BREW Interface Objects
c. failure to free allocations inside BREW helper functions (e.g. STRDUP)
and still get these one-time increases, is it safe to assume that
it is BREW's internal caching that's causing this?
Is there a way to know how much of the HEAP is used by the applet
itself and how much by BREW's cache?
If all the cases you mentioned, are taken care of then BREW is doing the memory management when your app is doing MALLOC/FREE. As long as you don't see "Failed to Release Memory" in the emulator output, when you close the application, you are ok.

Quote:
1. Is the "App Heap Info" a standard debug info in Brew? Been seeing
a lot in the discussions..but I can't make it come out in BREW Logger
(filter options are limited). Is this for the Simulator only?
You can use the DBGPRINTF() macro in the application and the output will come on the "Output" screen of the Emulator.
Quote:
2. How does one use the "###n" code? Where is this applied? In Simulator
or in Brew Logger?
This code sequence is to turn ON/OFF the debug on the device itself while your app is running. e.g. if you press "###2" you will see some single character output on the top right corner of the phone. To turn OFF press "###0". Search the Forum for details on the sequence.
Quote:
3. Lastly...I'm trying to debug somebody else's applets which are intergrated
with several other modules and there are sometimes increases in HEAP that
are unaccounted for (I've been using IHEAP_GetMemStats).
Assuming I've already ruled out the following
a. failure to deallocate pointers
b. failure to release BREW Interface Objects
c. failure to free allocations inside BREW helper functions (e.g. STRDUP)
and still get these one-time increases, is it safe to assume that
it is BREW's internal caching that's causing this?
Is there a way to know how much of the HEAP is used by the applet
itself and how much by BREW's cache?
If all the cases you mentioned, are taken care of then BREW is doing the memory management when your app is doing MALLOC/FREE. As long as you don't see "Failed to Release Memory" in the emulator output, when you close the application, you are ok.

arvind321 wrote:As long as you don't see "Failed to Release Memory" in the emulator output, when you close the application, you are ok.
hello. As for the project I am working on, there is no "Failed to Release Memory" screen but there are some amount of "wasted" memory.
*AEEHeap.c:1171 - ------ App Heap Info ------
*AEEHeap.c:1073 - 964 - myProject #368 h:\projects\myProject\myProject\source\myProject.cpp:253 (L)
*AEEHeap.c:1185 - -------------------------
*AEEHeap.c:1186 - 237567 Alloc - Total
*AEEHeap.c:1187 - 0 OEM
*AEEHeap.c:1188 - 65010 BREW
*AEEHeap.c:1189 - 172557 Apps
*AEEHeap.c:1190 - 2361 Wasted
*AEEHeap.c:1191 - 31217340 Free - Total
*AEEHeap.c:1192 - 31172408 Largest
*AEEHeap.c:1193 - 17984 Largest Non Seq.
*AEEHeap.c:1194 - 44932 Total Non Seq.
*AEEHeap.c:1195 - -------------------------
More Details:
Above is the only heap output after the first screen of app is seen and the app has been terminated just after that.
As the application is used with its all functionality, it allocates 12KB of data but does not release it. In subsequent launchs of applet, about 10KB of data is freed somehow. After 5 or 6 consecutive launchs, it allocates another 12 KB of data.
The application uses sockets, database and file managers I guess the BREW caching system may be reserving the memory, but after about 20 launchs, the memory allocation gets worse and the unfreed memory reaches about total of 22KB or more. I can send the exact memory leak test results, if needed.

arvind321 wrote:As long as you don't see "Failed to Release Memory" in the emulator output, when you close the application, you are ok.
hello. As for the project I am working on, there is no "Failed to Release Memory" screen but there are some amount of "wasted" memory.
*AEEHeap.c:1171 - ------ App Heap Info ------
*AEEHeap.c:1073 - 964 - myProject #368 h:\projects\myProject\myProject\source\myProject.cpp:253 (L)
*AEEHeap.c:1185 - -------------------------
*AEEHeap.c:1186 - 237567 Alloc - Total
*AEEHeap.c:1187 - 0 OEM
*AEEHeap.c:1188 - 65010 BREW
*AEEHeap.c:1189 - 172557 Apps
*AEEHeap.c:1190 - 2361 Wasted
*AEEHeap.c:1191 - 31217340 Free - Total
*AEEHeap.c:1192 - 31172408 Largest
*AEEHeap.c:1193 - 17984 Largest Non Seq.
*AEEHeap.c:1194 - 44932 Total Non Seq.
*AEEHeap.c:1195 - -------------------------
More Details:
Above is the only heap output after the first screen of app is seen and the app has been terminated just after that.
As the application is used with its all functionality, it allocates 12KB of data but does not release it. In subsequent launchs of applet, about 10KB of data is freed somehow. After 5 or 6 consecutive launchs, it allocates another 12 KB of data.
The application uses sockets, database and file managers I guess the BREW caching system may be reserving the memory, but after about 20 launchs, the memory allocation gets worse and the unfreed memory reaches about total of 22KB or more. I can send the exact memory leak test results, if needed.

Quote:964 - myProject #368 h:\projects\myProject\myProject\source\myProject.c pp:253 (L)
Check what is being done in this line of that particular file...
Mostly it would be a MALLOC or ISHELL_CreateInstance(). The memory location thus created might not be freed or released..

Quote:964 - myProject #368 h:\projects\myProject\myProject\source\myProject.c pp:253 (L)
Check what is being done in this line of that particular file...
Mostly it would be a MALLOC or ISHELL_CreateInstance(). The memory location thus created might not be freed or released..

Wow nice thread. will mind copying it to my blog? hope you don't man :) صور فنانات‫

Wow nice thread. will mind copying it to my blog? hope you don't man :) صور فنانات‫