onvif 段错调试办法

 希望对大家有帮助 来自于 http://blog.csdn.net/olei_oleitao/article/details/9332531

1、打开onvif调试开关,以便让onvif打印一些可用的调试信息。

在Makefile中添加调试宏定义如: CC = gcc -DDEBUG

2、打开调试宏后,默认在程序运行的目录产生三个文件:

RECV.log

SENT.log

TEST.log

RECV.log是onvif接收到的SOAP数据,没接收一条,都会在RECV.log中记录

SENT.log是onvif发送出去的SOAP数据,没发送一套,也会在SENT.log中生成记录

最后是TEST.log,如果说RECV和SENT可以用wireshark工具抓包代替,那么TEST.log是谁也替代不了的,TEST.log记录了onvif的实时的工作状态。

尤其当出现segmentation fault错误,TEST.log就成了唯一一个能够定位到具体内存出错的地方了。

3、最常见的错误:segmentation fault错误的解决方法

segmentation fault错误是onvif开发过程最常见的错误,至少我是这样的,主要是由于访问了没有分配地址的内存导致的,在填充功能函数时,很容易漏掉为必须的结构体分配内存,导致gSoap产生的代码会在不知情的状况下访问该结构体,然后报segmentation fault错误。那如何快速的定位到内存出错的地方呢?

有人说使用GDB、在这里GDB调试工具起不到什么作用的,因为GDB定位到的内存访问错误,是真的定位到访问时的那一条代码,而onvif中访问结构体内存的代码是有gSOAP自动产生的,代码本身并没有错,是最高一层的填充错误,这时候gdb就显得无能为力了。只能通过TEST.log定位。

onvif 段错调试办法_第1张图片

我故意将将成员变量Uri的内存非配注释掉,然后编译运行程序,出现内存错误:

onvif 段错调试办法_第2张图片

虽然我在函数里,打印了一条信息,表明出错的函数,现在我们完全可以忽略该信息,直接看TEST.log

onvif 段错调试办法_第3张图片

出现内存错误等致命错误,程序会立刻结束,所以打开TEST.log直接看最后面的信息

[plain] view plain copy print ?
  1. Element begin tag='SOAP-ENV:Body' level='1' id='0' type='' 
  2. Lookup location=0xbfd44a30 type=1548: not found 
  3. Element begin tag='trt:GetSnapshotUriResponse' level='2' id='0' type='' 
  4. Element begin tag='trt:MediaUri' level='3' id='0' type='' 
最后一条显示的Element begin tag=' trt:MediaUri',说明程序在开始编码trt:GetSnapshotUriResponse的trt:MediaUri出了问题,这里回过头来看源代码,

onvif 段错调试办法_第4张图片
结构体的第一条就是Uri,假如我注释的并不是Uri,而是__any等,那么TEST.log中的最后一条就肯定不是上面那样子的,我们可以再一些测试,说明TEST.log对于查找错误的重要性。

修改的程序如下:

onvif 段错调试办法_第5张图片

重新运行程序,运行到这段代码的时候就会产生一个内存错误,我们再次打开TEST.log

onvif 段错调试办法_第6张图片

从打印的信息来看,tt:Timeout已经编码结束了,然后才出现的问题,这是再看看源代码中Timeout后面的成员变量是什么onvif 段错调试办法_第7张图片

所以就很快的定位到出错的地方了。


但是如果使用gdb调试会是什么样的呢,还是可以做一下测试:

onvif 段错调试办法_第8张图片

这能看出什么啊?对于调试onvif,gdb就显得那么多余了。。。

 

你可能感兴趣的:(onvif 段错调试办法)