有同事反馈说自己的线程不工作，查看堆栈发现其打印如下：
#0 0x00007f291f72e7be in __lll_lock_wait_private () from /lib64/libc.so.6 #1 0x00007f291f6c2e4e in _L_lock_9925 () from /lib64/libc.so.6 #2 0x00007f291f6c1101 in free () from /lib64/libc.so.6 #3 0x00000000004b5b85 in pcap_close (p=0x561cab0) at ./pcap.c:1888 #4 0x000000000041f811 in ExitClean () at rp.c:5722 #5 0x00007f291f678655 in __run_exit_handlers () from /lib64/libc.so.6 #6 0x00007f291f6786a5 in exit () from /lib64/libc.so.6 #7 0x000000000041f590 in SigHandler (signo=6, info=0x7f291ed49d70, context=0x7f291ed49c40) at rp.c:5654 #8 <signal handler called> #9 0x00007f291f675875 in raise () from /lib64/libc.so.6 #10 0x00007f291f676e51 in abort () from /lib64/libc.so.6 #11 0x00007f291f6b68bf in __libc_message () from /lib64/libc.so.6 #12 0x00007f291f6bc0c8 in malloc_printerr () from /lib64/libc.so.6 #13 0x00007f291f6c110c in free () from /lib64/libc.so.6 #14 0x000000000042b1ef in reqReleasePacketInfo (pPacketInfo=0x5628230) at rp.c:11033 #15 0x0000000000438542 in DnsPacketCaptureEntry (ptConfig=0x741cc0 <atParamConfig>, ethIndex=0, threadIndex=0) at rp.c:16316 #16 0x000000000043954b in DnsPacketCaptureTask (ptThrPara=0x55cbf60 <TaskParaDnsCapConfig>) at rp.c:16715 #17 0x00007f292005e806 in start_thread () from /lib64/libpthread.so.0 #18 0x00007f291f72167d in clone () from /lib64/libc.so.6 #19 0x0000000000000000 in ?? ()
根据代码逻辑，发现其free的时候出现异常，导致了信号的产生，并且被SigHandler 处理，由于注册了退出清理函数，
atexit(ExitClean);
这个 ExitClean 会调用 pcap_close 来清理pcap_open 申请的一些资源，很悲剧的是，这些资源释放的时候，获取的锁看起来被占用了，导致我们exit的时候，被阻塞了。exit的时候，还没有走到
_exit（）函数，就阻塞在锁的等待上面。
这些锁被占用的概率，按照glibc的内存管理方式，不应该这么久，唯一的可能就是，这些锁的状态被异常覆盖了，导致认为被占用了。
反过头来看，一开始的free为什么异常，就能理解这个逻辑了。
查看对应时间点附近的系统日志，发现了很多报文的校验和错误，走查我们的代码，发现三层的错误并没有排查，而是直接采用拷贝的模式，
而拷贝传入的长度，是没有检验的长度，导致了我们malloc的内存越界。这种越界，最终在free的时候被发现。
改进点结论：
1.校验pacp_next返回的pcap_pkthdr中的len成员，大于我们用户的缓存区时，不要越界拷贝，解决malloc的越界，然后free就正常了。
2.进程工作与否，不能简单通过查看进程存在来判断。
