Brew memory debugging-bpoint -- reprinted

Http://hi.baidu.com/gaojinshan/blog/item/456eafd034281087a0ec9c1a.html

When debugging a BREW application on VC, the debug window prompts many information, such as [1] and [2:
* Aeeheap. C: 1167-100-dialereditapp #2042 E:/.../dialereditform. C: 346 (l) [1]
* Oemos. C: 679-bpoint Type 1, node 0x047856c8 dialereditapp [2]

* Aeeheap. C: 1167 -- indicates the output of row 1,167th of the file aeeheap. C.
100 -- indicates the size of memory leaked.
Dialereditapp -- indicates the applet where the memory leak is located
E:/.../dialereditform. C: 346 (l) -- indicates the file and row number of the Memory leakage.
* Oemos. C: 679 -- indicates the output of row 679th of the oemos. c file.
Bpoint type 1 -- indicates Memory leakage
Node 0x047856c8 dialereditapp -- node, address, and Application

Bpoint breakpoint
Brew defines four error types:
Type 1: Memory leakage, that is, the memory allocated with malloc has not been released.
Type 2: brew interface Memory leakage. This error will be prompted when the app exits.
Type 3: Memory uption, which usually means that the write should not be written, or the release should not be released.
Type 4: brew exception.

It is slightly easier to debug for 1 and 2.
Type1: You can add some memory debugging code, record all allocated and released addresses, and find out the error. Many software have reserved memory debugging interfaces during design. If not, write it by yourself.
Type2: if used in the application is very limited. Check it and try it out.
Type3: this type of problem is difficult to debug. Sometimes you can track errors by setting memory breakpoints. Set a memory breakpoint in VC. When the breakpoint is stopped, check whether the operation on this address is correct and whether the address is allocated with memory. However, most of the time, due to the error address (the prompt address), there may be many operations, such as frequent memory allocation, the memory area may be allocated and released repeatedly, making debugging more difficult. At this time, you need to be patient, debug more information, narrow down the scope of the error code, and then carefully check the code.