在前几篇中，虽然已经实现了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就显得那么多余了。。。