cryptic debug messages | developer.brewmp.com cryptic debug messages | developer.brewmp.com

Developer

cryptic debug messages

Forums:

Hi,

Can someone help me to understand the following messages?

*OEMOS.c:556 - BPOINT Type 3, Address: 0x01D98590
*OEMOS.c:539 - BPOINT Type 1, Node 0x01D94554 brew_barbie
- What is a BPOINT? Breakpoint?
- What does the type mean?
- What does this address point to?
- What does "Node" mean?

*AEEShell.c:8855 - #*gCL=16974621
- meaning?

*AEEHeap.c:1243 - ------ App Heap Info ------
*AEEHeap.c:1145 - 80 - brew_barbie #404 \code313\brewery\libdev\src\Aee\AEEShell.c:2677 (L)
- How can I debug such BREW-internal memleaks?
- Is #404 a cell id? How can I get the base pointer of the memory it refers?

*AEEShell.c:6615 - #*g*C=101402c:3
- meaning?

It would be a great help is anyone could help me to figure it out. Compared to other embedded platforms I know, I find debugging really painful in Brew :'(

Thanks,
Julien.

The OEM debug messages are OEM specific, so I can't help you with those. For a description of the BREW messages, see here:
http://brewforums.qualcomm.com/showpost.php?p=33168&postcount=4

The OEM debug messages are OEM specific, so I can't help you with those. For a description of the BREW messages, see here:
http://brewforums.qualcomm.com/showpost.php?p=33168&postcount=4

Well, the OEMOS.c parts do not depends on OEM since I'm talking about the Brew Simulator. So that's Qualcomm's code in there...
Julien.

Well, the OEMOS.c parts do not depends on OEM since I'm talking about the Brew Simulator. So that's Qualcomm's code in there...
Julien.

Well, tell me the version of the Simulator you're using and I'll take a look.

Well, tell me the version of the Simulator you're using and I'll take a look.

I'm getting a similar memory leak in the 3.1.2.13 Simulator:
*AEEHeap.c:1073 - 80 - myapp #18732 \code312\brewery\libdev\src\Aee\AEEShell.c:2316 (L)
Any idea what I'm leaking?
-Erik

I'm getting a similar memory leak in the 3.1.2.13 Simulator:
*AEEHeap.c:1073 - 80 - myapp #18732 \code312\brewery\libdev\src\Aee\AEEShell.c:2316 (L)
Any idea what I'm leaking?
-Erik

I'm using 2.1.1 (japanese), 3.1.2 (english) and 3.1.3 (english) SDKs.
The aforementioned messages were from the simulator of the 3.1.3 sdk.
Julien.

I'm using 2.1.1 (japanese), 3.1.2 (english) and 3.1.3 (english) SDKs.
The aforementioned messages were from the simulator of the 3.1.3 sdk.
Julien.

Heap debug messages demystified:
*AEEHeap.c:1073 - 80 - myapp #18732 \code312\brewery\libdev\src\Aee\AEEShell.c:2316 (L)
AEEHeap.c:1073 - The file and line number where this dbg message originated
80 - The size of the heap node (the size of the memory leak is 80 bytes)
myapp - The name of the memory group that caused the leak (most cases this is just the name of the app structure)
#18732 - The malloc ID of the object. BREW internal tracker.
AEEShell.c:2316 - where it was malloced
L: whether the memory node was locked or unlocked(U)
The above line (AEEShell.c:2316) basically malloced memory for your applet (which includes the applets data and virtual tables)
What does all this mean? Your program has allocated memory somewhere and is not freeing it when exiting. More than likely this variable resides in your applet's structure.
How should I fix this? Use a debugger to track all the variables that malloc for memory. Set a breakpoint in your FreeAppData() fxn and if the variables are not being set back to NULL, you are not freeing those objects.

Heap debug messages demystified:
*AEEHeap.c:1073 - 80 - myapp #18732 \code312\brewery\libdev\src\Aee\AEEShell.c:2316 (L)
AEEHeap.c:1073 - The file and line number where this dbg message originated
80 - The size of the heap node (the size of the memory leak is 80 bytes)
myapp - The name of the memory group that caused the leak (most cases this is just the name of the app structure)
#18732 - The malloc ID of the object. BREW internal tracker.
AEEShell.c:2316 - where it was malloced
L: whether the memory node was locked or unlocked(U)
The above line (AEEShell.c:2316) basically malloced memory for your applet (which includes the applets data and virtual tables)
What does all this mean? Your program has allocated memory somewhere and is not freeing it when exiting. More than likely this variable resides in your applet's structure.
How should I fix this? Use a debugger to track all the variables that malloc for memory. Set a breakpoint in your FreeAppData() fxn and if the variables are not being set back to NULL, you are not freeing those objects.

Thanks a lot for the description of this message's fields.
However, the method you mention for debugging leaks works well on small projects which put everything in the applet structure without using aggregation and without transfering ownership to other objects. If you code a C++ program with hundreds of classes (which is my case), things get a little bit more complex. And since the BREW Simulator allocs a memory pool for all those MALLOC()s, tools like Purify will detect no memory leak at all...
I think the simulator lacks some real stats about memory... At least it should give the address of the leaking cell (so that you can try to cast that adress in Visual, just like you do on symbian, and determine the type of the pointer).
Anyway, thanks, again...
Julien

Thanks a lot for the description of this message's fields.
However, the method you mention for debugging leaks works well on small projects which put everything in the applet structure without using aggregation and without transfering ownership to other objects. If you code a C++ program with hundreds of classes (which is my case), things get a little bit more complex. And since the BREW Simulator allocs a memory pool for all those MALLOC()s, tools like Purify will detect no memory leak at all...
I think the simulator lacks some real stats about memory... At least it should give the address of the leaking cell (so that you can try to cast that adress in Visual, just like you do on symbian, and determine the type of the pointer).
Anyway, thanks, again...
Julien

Well, the thread above only discuss about enabling heap debug information and dealing with trivial memory leaks such as for memory allocated by the application using MALLOC(). It's hardly of any help for real memory leaks, which on BREW basically mean:
1) Code allocated by the framework, but not freed by the application (the API reference being what it is, it's often not clear if the returned pointer is owned by the framework or by the caller -a recent example I have in mind: pointer returned by IDBRECORD_GetField(), which is owned by the framework and overwritten upon multiple calls, leading to surprising results since you can FREE() it anytime without any crash)
2) Object not released, or at least not as released as many times it wasaddref'ed.
3) Callback still active
AFAIK, the development kit for BREW offers no way to debug such leaks, which is just too bad since it would require only very little additions in simulator's source code.
Julien.

Well, the thread above only discuss about enabling heap debug information and dealing with trivial memory leaks such as for memory allocated by the application using MALLOC(). It's hardly of any help for real memory leaks, which on BREW basically mean:
1) Code allocated by the framework, but not freed by the application (the API reference being what it is, it's often not clear if the returned pointer is owned by the framework or by the caller -a recent example I have in mind: pointer returned by IDBRECORD_GetField(), which is owned by the framework and overwritten upon multiple calls, leading to surprising results since you can FREE() it anytime without any crash)
2) Object not released, or at least not as released as many times it wasaddref'ed.
3) Callback still active
AFAIK, the development kit for BREW offers no way to debug such leaks, which is just too bad since it would require only very little additions in simulator's source code.
Julien.

I finally managed to get some useful info from this cryptic message:
*OEMOS.c:556 - BPOINT Type 3, Address: 0x01D94A0C
If you're using VC++:
* Break into the program
* In a Watch window, enter:
o (char*)((unsigned*)0x01D94A0C)[1], this will (sometimes) give you the name of a source file
o ((unsigned*)0x01D94A0C)[2], this will (sometimes) give you a line number
I don't know what "Type 3" means. I will post the results of my investigations here when I find other things...
Julien.

I finally managed to get some useful info from this cryptic message:
*OEMOS.c:556 - BPOINT Type 3, Address: 0x01D94A0C
If you're using VC++:
* Break into the program
* In a Watch window, enter:
o (char*)((unsigned*)0x01D94A0C)[1], this will (sometimes) give you the name of a source file
o ((unsigned*)0x01D94A0C)[2], this will (sometimes) give you a line number
I don't know what "Type 3" means. I will post the results of my investigations here when I find other things...
Julien.

*OEMOS.c:556 - BPOINT Type 3, Address: 0x01D98590
*OEMOS.c:539 - BPOINT Type 1, Node 0x01D94554 brew_barbie
- What is a BPOINT? Breakpoint?
[t] Yes. It means BREAKPOINT
- What does the type mean?
[t] 1 -> Memory leak in the app due to user allocated memory using MALLOC
"Node" is just a naming convention
2 -> Memory leak in the app due to BREW Interface memory leaks
In this case, "IFace" would have been printed out instead of "Node"
3 -> Memory being double freed. Exception!
4 -> Corrupt Node
- What does this address point to?
[t] Address / starting address of the memory

*OEMOS.c:556 - BPOINT Type 3, Address: 0x01D98590
*OEMOS.c:539 - BPOINT Type 1, Node 0x01D94554 brew_barbie
- What is a BPOINT? Breakpoint?
[t] Yes. It means BREAKPOINT
- What does the type mean?
[t] 1 -> Memory leak in the app due to user allocated memory using MALLOC
"Node" is just a naming convention
2 -> Memory leak in the app due to BREW Interface memory leaks
In this case, "IFace" would have been printed out instead of "Node"
3 -> Memory being double freed. Exception!
4 -> Corrupt Node
- What does this address point to?
[t] Address / starting address of the memory

Hi,
I am getting the error "oemos.c:565 - BPOINT type 3, Address" when i run my application develop in brew 2.1 and run in simulator 3.1.But when i debug the simulator i found that the error is due to the used of FREE macro. Whereever the FREE as been used the error of BPOINT were occuring. But when i remove the line of
FREE(pstr) the error stop occuring.
So, may the FREE has been defined slightly different in 2.1 onwards,
So, please have a look at your application by removing the every use of FREE macro.

Hi,
I am getting the error "oemos.c:565 - BPOINT type 3, Address" when i run my application develop in brew 2.1 and run in simulator 3.1.But when i debug the simulator i found that the error is due to the used of FREE macro. Whereever the FREE as been used the error of BPOINT were occuring. But when i remove the line of
FREE(pstr) the error stop occuring.
So, may the FREE has been defined slightly different in 2.1 onwards,
So, please have a look at your application by removing the every use of FREE macro.

uhh removing the FREE would remove the error checking too, so of course you won't get messages,

uhh removing the FREE would remove the error checking too, so of course you won't get messages,

So if BPOINT really does mean breakpoint, any thoughts on how to get the debugger to actually break at that point? I know the simulator does have at least one real breakpoint hard-coded (int 3 in x86 assembly), because I've triggered it once in a while when exiting our application. But BPOINT doesn't break.

So if BPOINT really does mean breakpoint, any thoughts on how to get the debugger to actually break at that point? I know the simulator does have at least one real breakpoint hard-coded (int 3 in x86 assembly), because I've triggered it once in a while when exiting our application. But BPOINT doesn't break.

put a breakpoint in the simulator at the point it triggers the message

put a breakpoint in the simulator at the point it triggers the message

charliex wrote:put a breakpoint in the simulator at the point it triggers the message
You mean at, for example, OEMOS.c:556 to break on any double free? Absent simulator source code or at least a symbol file, I'm not quite sure how I'd go about that. Could you elaborate a bit?

charliex wrote:put a breakpoint in the simulator at the point it triggers the message
You mean at, for example, OEMOS.c:556 to break on any double free? Absent simulator source code or at least a symbol file, I'm not quite sure how I'd go about that. Could you elaborate a bit?

yes there are two functions one for the address and one for the exception.
unfortunately going into any further details that that would be against qualcomms rules, one of the moderators may choose to add more details, but its not that hard to do if you know your way around x86
i'm also not fully convinced that the exception reports are accurate either, i was playing around with this morning debugging someone elses code and i noticed some anomalies, but since its not my code i'm not sure yet.
edit: don't edit before coffee!

yes there are two functions one for the address and one for the exception.
unfortunately going into any further details that that would be against qualcomms rules, one of the moderators may choose to add more details, but its not that hard to do if you know your way around x86
i'm also not fully convinced that the exception reports are accurate either, i was playing around with this morning debugging someone elses code and i noticed some anomalies, but since its not my code i'm not sure yet.
edit: don't edit before coffee!

Im getting a message,
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C1DA60 sample
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C17DB0 sample..
Wat does this mean.. Im freeing the heap also.. but still the application exits with the message "Module failed to free all memory"..
Anybody can help me..

Im getting a message,
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C1DA60 sample
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C17DB0 sample..
Wat does this mean.. Im freeing the heap also.. but still the application exits with the message "Module failed to free all memory"..
Anybody can help me..

vicky wrote:Im getting a message,
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C1DA60 sample
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C17DB0 sample..
Wat does this mean.. Im freeing the heap also.. but still the application exits with the message "Module failed to free all memory"..
Anybody can help me..
Off the top of my head, you've probably not released an IFILE. If you search the forums for BPOINT 581 you'll find my post about it.

vicky wrote:Im getting a message,
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C1DA60 sample
*OEMOS.c:581 - BPOINT Type 1, Node 0x02C17DB0 sample..
Wat does this mean.. Im freeing the heap also.. but still the application exits with the message "Module failed to free all memory"..
Anybody can help me..
Off the top of my head, you've probably not released an IFILE. If you search the forums for BPOINT 581 you'll find my post about it.

Type 3 stands for AEEBRK_CORRUPTNODE;This triggers a breakpoint call when a node is corrupt. This may not be the exact corrupt node, but in most cases should be close.

Type 3 stands for AEEBRK_CORRUPTNODE;This triggers a breakpoint call when a node is corrupt. This may not be the exact corrupt node, but in most cases should be close.

Type 1: AEEBRK_MEMLEAK
Description:
This triggers a breakpoint call for a memory leak fault. It will be called for each node that is leaked by the application when the module is unloaded.Do not free this buffer, it will be freed after AEEOS_Breakpoint() returns.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_MEMLEAK
pData: Pointer to a AEEAppLeak structure
nSize: Size of AEEAppLeak structure
Name:
Type2: AEEBRK_IFACELEAK
Description:
This triggers a breakpoint call for an interface leak fault, when the interface has registered and linked system object attached to the application whose module is unloading. The extension registers with AEE_LinkSysObject(). Do not release this object, it will be released after AEEOS_Breakpoint() returns.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_IFACELEAK
pData: Pointer to a AEEAppLeak structure
nSize: Size of AEEAppLeak structure
Name:
Type3: AEEBRK_CORRUPTNODE
Description:
This triggers a breakpoint call when a node is corrupt. This may not be the exact corrupt node, but in most cases should be close. You can then use the AEEkHeap_Walk to walk the heap for more information if necessary.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_CORRUPTNODE
pData: Address of a corrupt node
nSize: 0
Name:
Type 4: AEEBRK_EXCEPTION
Description:
This triggers a breakpoint call for an exception that will happen synchronously before an exception is thrown or device reset is issued.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_EXCEPTION
pData: Pointer to a AEEExceptionType type
nSize: Size of AEEExceptionType type

Type 1: AEEBRK_MEMLEAK
Description:
This triggers a breakpoint call for a memory leak fault. It will be called for each node that is leaked by the application when the module is unloaded.Do not free this buffer, it will be freed after AEEOS_Breakpoint() returns.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_MEMLEAK
pData: Pointer to a AEEAppLeak structure
nSize: Size of AEEAppLeak structure
Name:
Type2: AEEBRK_IFACELEAK
Description:
This triggers a breakpoint call for an interface leak fault, when the interface has registered and linked system object attached to the application whose module is unloading. The extension registers with AEE_LinkSysObject(). Do not release this object, it will be released after AEEOS_Breakpoint() returns.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_IFACELEAK
pData: Pointer to a AEEAppLeak structure
nSize: Size of AEEAppLeak structure
Name:
Type3: AEEBRK_CORRUPTNODE
Description:
This triggers a breakpoint call when a node is corrupt. This may not be the exact corrupt node, but in most cases should be close. You can then use the AEEkHeap_Walk to walk the heap for more information if necessary.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_CORRUPTNODE
pData: Address of a corrupt node
nSize: 0
Name:
Type 4: AEEBRK_EXCEPTION
Description:
This triggers a breakpoint call for an exception that will happen synchronously before an exception is thrown or device reset is issued.
void AEEOS_Breakpoint(uint32 dwType, void * pData, uint32 nSize);
Parameters:
dwType: Specifies AEEBRK_EXCEPTION
pData: Pointer to a AEEExceptionType type
nSize: Size of AEEExceptionType type