Drangon's blog

一个网络收发的bug的调试所想到的

drangon — Sat, 14 Feb 2009 04:02:21 GMT

软件bug调试最重要的是什么？我认为最重要的是基本功和思路。
基本功包括对程序运行的理解，各种关键信息，以及工具使用的熟悉，能够获取相应的信息。
但即使有好的工具，也能熟练运用，如果没有清晰的思路，也会事倍功半。
调试的思路，主要是根据bug出现和不出现的对比，以及程序本身的流程，推断问题可能存在的地方，提出一些验证方法，经过验证，逐步缩小范围，最终定位。
这个过程中，最复杂的是推断，其次是验证方法，至于验证过程，只是体力活而已。
而且在推断过程，要有适当的怀疑一切的想法，一些你以为绝无问题的地方，可能是个陷阱。

在刚开始写小程序的时候，当发现结果不对时，往往是使用debuger，一步一步的单步执行，进行调试。
但当程序规模较大时，特别是涉及到多线程多进程交互时，长时间运行才出现bug时，往往很难再单步执行调试，此时更需要明确思路，在关键点设断点或者打印日志，进行验证。
从这个意义上来说，是否有IDE，调试器是否强大，重要性已经降低。

前段时间一个网络收发程序出现一个bug。A机器上的程序P不停的向B机器的程序Q发送UDP包，刚开始是正常的，但过了一段时间后，P发包没停，但Q却收不到包了。
P和Q都是有比较复杂的逻辑，在发包和收包的地方加断点可以验证有没有数据包发送和接收到。
但在此之前，先理一下思路，Q没有收到包的原因是什么？
大概是下面几点：P没有发出去，Q没有去接收，数据包中途被丢了。
先在P发包代码加断点，证实是有发送出去的。
在Q接收包代码加断点，证实是有调用recv函数，但却超时了，没有收到数据。
那么数据包是丢掉了，然后在A、B的机器上抓包，都能抓到数据包。

这下好像进入死胡同了，机器收到包，程序却收不到，总不能怀疑操作系统内部的bug吧。
如果基本功比较强大的话，可能可以推测出是什么原因。
但一般情况下，我们应该怎样处理呢？

前面提到，刚开始的时候是正常的，只是过了几十分钟才不正常，调试一次也不容易啊，要等几十分钟才能重现的。
查找线索的一个重要方法，就是对比正常和不正常的情况。
首先，要拿到程序不正常的那个时间点，这个可以通过日志来获取。
然后对比这个时间点附近的各种信息对比，除了程序日志外，还要抓到的包的对比。
（btw，机器最好通过NTP等方式，保证时间同步，这样便于获取统一的时间点。）

这个数据包看上去也没什么问题啊。。。。好像没什么问题啊。。。。好像。。。。
What？数据包的dest MAC地址怎么变了？
前面再看看，怎么有个古怪的ARP包。。。。

BUG的原因，网络环境混合了路由器和HUB，某个路由器发神经，发送了一个错误的ARP包（怀疑是病毒，但没找到），导致A机器将B的MAC地址记成是另外一个，B接在HUB上，所以收到A发送的包，但由于MAC地址不对，结果被操作系统丢弃了。

ffmpeg的windows版本编译方法

drangon — Sun, 25 Jan 2009 10:03:26 GMT

ffmpeg库的强大就不多说了。但ffmpeg用了很多gcc的特性，所以不能用VC来编译，所以需要借助mingw。

直接在windows下编译需要MSYS环境，也可以在linux下交叉编译。我是使用mingw-w64来进行编译的。
配置命令如下：


../ffmpeg/configure --cross-prefix=/compile/mingw/cross/bin/x86_64-pc-mingw32-  \
--enable-memalign-hack \
--disable-devices \
--enable-debug=3 --disable-optimizations --disable-stripping \
--prefix=/home/drangon/work_media/ffmpeg-svn/bm64/out

配置前需要先将configure文件中的“check_cflags -std=c99"一行注释掉，配置完之后，需要修改config.h和config.mak，分别修改”#define HAVE_DOS_PATHS 1“和增加”HAVE_DOS_PATHS=yes“。

mingw-w64环境下的编译工具和库可以在这里下载。

下一步再试试将这些库打包成VC能够使用的库。

vmware的scsi问题

drangon — Tue, 28 Oct 2008 15:06:36 GMT

vmware的scsi硬件模拟似乎问题多多，早期的版本中，kernel检查到的设备数量为0，需要修改kernel代码，直接指定有16个scsi设备，才会检查具体的设备。这个bug在vmware server 2.x和vmware workstation 6.x中修补了。

最新的kernel 2.6.27又出另外一个问题，系统启动时会发现不了scsi硬盘。导致启动失败。

这次修补相对简单一些，只需要在挂载完scsi的模块后，在激活swap和switchroot之前，增加挂载scsi_wait_scan模块就可以。
为了增加这个模块，最简单的方法，就是修改 /etc/sysconfig/mkinitrd 文件，增加下列一行：


MODULES=scsi_wait_scan

然后重新执行mkinitrd就可以了。

小站又开张啦。。。。

drangon — Sun, 19 Oct 2008 08:26:41 GMT

又开张啦，这次要坚持写点东西。。。。

沙漠龙城，Reloading。。。。