有同事反馈说自己的线程不工作，查看堆栈发现其打印如下：

#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  
     
      #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 
      
       , ethIndex=0, threadIndex=0) at rp.c:16316#16 0x000000000043954b in DnsPacketCaptureTask (ptThrPara=0x55cbf60 
       
        ) 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.进程工作与否，不能简单通过查看进程存在来判断。