onvif规范的实现:onvif开发常用调试方法 和常见的segmentation fault错误
在前几篇中,虽然已经实现了rtsp视频流的对接,但是还要做的工作还非常多,onvif本来就是一个覆盖面非常广的一个协议,每一个功能都要填充大量的函数。而且稍不注意就会出现segmentation fault错误。下面把我之前开发调试时的经验写下来,希望能够帮助有这方面需求的人。【来自http://blog.csdn.net/ghostyu】
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定位。
我故意将将成员变量Uri的内存非配注释掉,然后编译运行程序,出现内存错误:
虽然我在函数里,打印了一条信息,表明出错的函数,现在我们完全可以忽略该信息,直接看TEST.log
出现内存错误等致命错误,程序会立刻结束,所以打开TEST.log直接看最后面的信息
- Element begin tag='SOAP-ENV:Body' level='1' id='0' type=''
- Lookup location=0xbfd44a30 type=1548: not found
- Element begin tag='trt:GetSnapshotUriResponse' level='2' id='0' type=''
- Element begin tag='trt:MediaUri' level='3' id='0' type=''
Element begin tag='SOAP-ENV:Body' level='1' id='0' type='' Lookup location=0xbfd44a30 type=1548: not found Element begin tag='trt:GetSnapshotUriResponse' level='2' id='0' type='' Element begin tag='trt:MediaUri' level='3' id='0' type=''
最后一条显示的Element begin tag=' trt:MediaUri',说明程序在开始编码trt:GetSnapshotUriResponse的trt:MediaUri出了问题,这里回过头来看源代码,
结构体的第一条就是Uri,假如我注释的并不是Uri,而是__any等,那么TEST.log中的最后一条就肯定不是上面那样子的,我们可以再一些测试,说明TEST.log对于查找错误的重要性。
修改的程序如下:
重新运行程序,运行到这段代码的时候就会产生一个内存错误,我们再次打开TEST.log
从打印的信息来看,tt:Timeout已经编码结束了,然后才出现的问题,这是再看看源代码中Timeout后面的成员变量是什么
所以就很快的定位到出错的地方了。
但是如果使用gdb调试会是什么样的呢,还是可以做一下测试:
这能看出什么啊?对于调试onvif,gdb就显得那么多余了。。。