在VC上调试BREW应用时,DEBUG窗口提示很多如【1】和【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——表示文件AEEHeap.c的第1167行输出的这个信息
100——表示内存泄漏的内存块的大小
dialereditapp——表示内存泄漏所在Applet
e:\...\dialereditform.c:346 (L)——表示内存泄漏所在文件和行号
*OEMOS.c:679——表示文件OEMOS.c的第679行输出的这个信息
BPOINT Type 1——表示内存泄漏
Node 0x047856C8 dialereditapp——节点,地址,应用
BPOINT 断点
BREW定义了四种错误类型:
TYPE 1: 内存泄露问题,就是用MALLOC分配的内存没有释放了。
TYPE 2: BREW接口内存泄露。这种错误在APP退出的时候会提示。
TYPE 3: 内存corruption,通常就意味着写了不该写的地方,或者释放了不该释放的地方。
TYPE 4: BREW异常。
对于1和2稍微容易调试一些。
TYPE1:可以加一些内存调试代码,记录所有分配和释放的地址,找出错误。很多软件在设计时,都预留了内存调试接口。如果没有,自己写呗。
TYPE2:应用中用的IF是很有限的吧,好好检查下,努力点,就没问题了
TYPE3:这类问题比较难调试,有时候可以通过设置内存断点来跟踪到错误的地方。在VC中设置内存断点,断点停时,查看操作该地址的地方是否有误,该地址是否为义分配内存。但大多时候,由于出错的地址(提示的地址)可能操作的很多,比如内存分配比较频繁,该内存区可能被重复分配释放,调试起来就比较困难了。这时候就需要有耐心了,多打调试信息,缩小出错的代码范围,然后仔细检查代码。
*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——表示文件AEEHeap.c的第1167行输出的这个信息
100——表示内存泄漏的内存块的大小
dialereditapp——表示内存泄漏所在Applet
e:\...\dialereditform.c:346 (L)——表示内存泄漏所在文件和行号
*OEMOS.c:679——表示文件OEMOS.c的第679行输出的这个信息
BPOINT Type 1——表示内存泄漏
Node 0x047856C8 dialereditapp——节点,地址,应用
BPOINT 断点
BREW定义了四种错误类型:
TYPE 1: 内存泄露问题,就是用MALLOC分配的内存没有释放了。
TYPE 2: BREW接口内存泄露。这种错误在APP退出的时候会提示。
TYPE 3: 内存corruption,通常就意味着写了不该写的地方,或者释放了不该释放的地方。
TYPE 4: BREW异常。
对于1和2稍微容易调试一些。
TYPE1:可以加一些内存调试代码,记录所有分配和释放的地址,找出错误。很多软件在设计时,都预留了内存调试接口。如果没有,自己写呗。
TYPE2:应用中用的IF是很有限的吧,好好检查下,努力点,就没问题了
TYPE3:这类问题比较难调试,有时候可以通过设置内存断点来跟踪到错误的地方。在VC中设置内存断点,断点停时,查看操作该地址的地方是否有误,该地址是否为义分配内存。但大多时候,由于出错的地址(提示的地址)可能操作的很多,比如内存分配比较频繁,该内存区可能被重复分配释放,调试起来就比较困难了。这时候就需要有耐心了,多打调试信息,缩小出错的代码范围,然后仔细检查代码。