处理的两个bug

no.1

在使用realtime的sip peer时，在chan_sip.c的check_peer_ok函数中调用find_peer时，未传递peer的name，如果通过ip及port在内存中未找到peer，
则需要通过ipaddr查询peer，由于同一个ipaddr的peer很多，导致加载的数据很大，易出现crash。将find_peer带上name后出现
peer验证不通过的情况（asterisk 服务器间不能互打），新增函数find_peer_verify中新增一个name字段为peer的name值，
这样就可以通过name查询sip。
handle_request_invite(handle_request_subscribe)->check_user_full->check_peer_ok->find_peer(find_peer_verify )->realtime_peer
peer table了。
#0  0x0033b809 in _int_malloc () from /lib/libc.so.6
#1  0x0033c939 in calloc () from /lib/libc.so.6
#2  0x080a2db9 in _ast_calloc (name=0xd4af568 "company_id", value=0x5da9110 "1", filename=0x5a4333 "")
    at /root/dreamstart/asterisk-1.6.0.26/include/asterisk/utils.h:462
#3  ast_variable_new (name=0xd4af568 "company_id", value=0x5da9110 "1", filename=0x5a4333 "") at config.c:214
#4  0x005a0cb1 in __i686.get_pc_thunk.bx () from /usr/lib/asterisk/modules/res_config_mysql.so
#5  0x0d4af568 in ?? ()
#6  0x080a25d4 in ast_load_realtime_multientry (family=0x6a82cb3 "sippeers") at config.c:2129
#7  0x06a56d66 in realtime_peer (newpeername=0x0, sin=0xd4a76d4, devstate_only=0) at chan_sip.c:3976
#8  0x06a5e640 in check_peer_ok (p=0xd4a7400, of=0x5de1a35 "88936", req=0x5de1f14, sipmethod=5, sin=0x5de314c, authpeer=0x0, reliable=XMIT_RELIABLE, 
    rpid_num=0x5de1b62 "", calleridname=0x5de1b30 "", uri2=0x5de19d0 "sip:8712_2_23_714@192.168.1.109") at chan_sip.c:12761
#9  0x06a60030 in check_user_full (p=0xd4a7400, req=0x5de1f14, sipmethod=5, uri=0x5de213f "sip:8712_2_23_714@192.168.1.109", reliable=XMIT_RELIABLE, 
    sin=0x5de314c, authpeer=0x0) at chan_sip.c:12999
#10 0x06a6a685 in check_user (p=0xd4a7400, req=0x5de1f14, debug=0, seqno=20, sin=0x5de314c, recount=0x5de1ebc, 
    e=0x5de213f "sip:8712_2_23_714@192.168.1.109", nounlock=0x5de1eb8) at chan_sip.c:13026
#11 handle_request_invite (p=0xd4a7400, req=0x5de1f14, debug=0, seqno=20, sin=0x5de314c, recount=0x5de1ebc, e=0x5de213f "sip:8712_2_23_714@192.168.1.109", 
    nounlock=0x5de1eb8) at chan_sip.c:18261
#12 0x06a7f385 in handle_incoming (p=0xd4a7400, req=0x5de1f14, sin=0x5de314c, recount=0x5de1ebc, nounlock=0x5de1eb8) at chan_sip.c:19890
#13 0x06a80ef7 in handle_request_do (req=0x5de1f14, sin=0x5de314c) at chan_sip.c:20168
#14 0x06a81f70 in sipsock_read (id=0x9efccf8, fd=16, events=1, ignore=0x0) at chan_sip.c:20074
#15 0x080d45ef in ast_io_wait (ioc=0x9efb4d0, howlong=1000) at io.c:288
#16 0x06a73a05 in do_monitor (data=0x0) at chan_sip.c:20577
#17 0x0813725b in dummy_start (data=0x9efcfc0) at utils.c:861
#18 0x00469a09 in start_thread () from /lib/libpthread.so.0
#19 0x003a743e in clone () from /lib/libc.so.6

no.2

在linphone-3.5.2中嵌入了一个webserver，使之与web端进行tcp通信。这样就可以通过visual studio 编译一个软电话exe的客户端，使之开机启动，这样通过web端及webserver间的tcp通信完成linphone电话呼叫、接听及状态获取过程，同时可进行二次开发。该客户端在非中文的xp的pc上运行，在压力呼叫测试1、2小时后就会出现Windows提示：软件错误，是否发送错误（如果不管它，则软电话可正常工作；如果点击发送或点击不发送，则xp会将exe程序kill掉），但是在中文xp上运行则没有此问题。因此进行的排查过程如下：

1：怀疑程序没问题，是由于xp环境导致；在xp上disable发送错误报告的功能，任何情况下都不发送错误报告，结果压测出现exe程序会无端消失

结果：disable发送错误报告的功能，行不通

2：由于exe程序生成了大量的日志，怀疑是生成日志文件太多，导致xp为安全起见，对用户进行错误提示；程序屏蔽日志后压测，同样提示发送错误报告
结果：日志也不是引起错误报告的原因

3：在客户机器上安装visual studio，同时将源码在客户机器上编译后进行压测。压测10小时工作正常并未出现任何提示，怀疑是xp环境问题导致提示错误报告：visual studio 2008自带的是3.5的.NET，而客户机器上是2.5或2.0的.NET，因此准备将客户机器上的.NET更新至3.5的.NET。但是安装了visual studio机器出现了just-in-time debugger: an unhandled win32 exception happened in xxxx.exe.艾，由于对visual studio开发不是很熟，并未对此提示引起足够重视，并未根据此debug信息定位代码出错的地方（另一个原因是如果不管此提示，exe仍可正常工作，因此认为只是windows的warning而非crash，且认为程序仍在正常运行，则根据just-in-time进行debug不能定位到错误的地方，哎vs菜啊）（其实Windows会自带一个try catch的功能，对于出错的程序，可捕获到从而让程序没有立即挂掉而使它还能正常工作）（所以错误报告和just-in-time提示都是xp已捕获到程序的错误而给出的提示）

结果：对vs开发不熟，未对just-in-time提示进行debug
4：根据just-in-time debugger进行debug，又犯了一个错误，由于exe是多线程，因此调试时有多个线程，此时选择的不是在vs 挂掉的那个线程进行调试，而是去检查底层线程，然后以为底层线程中断运行处出错并调试底层代码进行反复调试并未有任何效果。
结果：对vs开发不熟，未对vs给出的真正错误的程序处（有一个线程）进行调试
5：由于在客户机上，多台pc机上进行反复的压力测试，测试耗用较多时间及精力且效果不明显。

6：自己在程序中添加了一个crash的地方，再次运行，发现vs提示just-in-time debugger: an unhandled win32 exception happened in xxxx.exe.，并且vs显示的正是crash的地方，由此才在vs显示程序中断的地方即错误的地方调试，并最终找到了程序出错的地方并修复之。

分析问题时，一定要从全局出发，要考虑到各种可能的情况且尝试用不同的方法去解决，切忌进入到死胡同。同时也要进行对比总结，不能进行无用的尝试。当然最好的情况是开始就能定位到的问题的根源，这样省力省时效率最高，所以在着手开始处理时，要仔细分析问题发生的情景及条件最好能重现，不能抱着瞎猫碰到死耗子的心理去乱猜。

linphone crash的两个原因：

1：operator执行接听命令后crash,linphone执行时linphone_core_accept_call时出错,mediastream2.dll异常,由于主叫在operator接听时已挂断电话了。
2：operator执行挂断命令后crash,linphone执行时linphone_core_terminate_call时出错,mediastream2.dll异常,由于operator在接听电话后立即挂断，实际上通话还未真正建立。
linphone_core_stop_media_streams()
{

...

audio_stream_stop(lc->audiostream);
...

}