Unix调试总卡壳？5个隐性陷阱90%开发者都踩过

文章配图，仅供参考

　　第一个隐性陷阱是信号掩码的“隐形继承”。我原以为子进程会继承父进程的信号掩码，结果测试时发现子进程的掩码和父进程完全不一样——后来查手册才发现，Unix里`fork()`确实会继承，但`exec()`会重置掩码！可问题是我根本没显式调用`exec()`啊？结果翻代码发现，某个库里偷偷调了`system()`，而`system()`内部会`fork`+`exec`，这一套下来，信号掩码早被改得面目全非。当时机房的空调嗡嗡响，我盯着`strace`的输出，发现`sigprocmask(SIG_SETMASK, ...)`的调用根本不是自己写的，差点没把键盘砸了。

　　第二个坑更隐蔽——共享内存的“伪同步”。有次用`shmget`+`shmat`做进程间通信，明明写端已经`memcpy`了数据，读端却读不到。我原以为是内存对齐问题，结果用`gdb`打印共享内存地址，发现两边的地址居然不一样！后来才明白，`shmat`的返回值是虚拟地址，不同进程的虚拟地址空间不同，直接比较地址当然不一样。更坑的是，`shmat`的`SHM_RDONLY`标志没设对，读端进程居然能修改共享内存，导致数据被意外覆盖。那天中午点的外卖是黄焖鸡，吃的时候还在想“这共享内存怎么和黄焖鸡的汤似的，越搅越乱”。

　　第三个陷阱是文件描述符的“延迟关闭”。有次用`pipe()`做父子进程通信，父进程写，子进程读，结果子进程的`read`一直阻塞。我查了半天，发现父进程的`write`早就返回了，数据也确实写进了管道，但子进程就是读不到。后来用`lsof`一看，父进程的管道写端描述符没关！Unix里，管道的写端不关闭，读端就会一直阻塞，哪怕写端已经没数据了。这事儿最气的是，父进程的代码里明明有`close(fd[1])`，结果调试时发现，这个`close`被某个信号处理函数里的`longjmp`跳过了，导致描述符没真正关闭。当时测试组的阿强接了个电话，说“晚上聚餐”，我头都没抬，回了句“你们先吃，我这管道还没通呢”。

　　第四个坑是线程安全的“假象”。有次用`pthread_mutex`保护共享数据，结果多线程下还是出现数据竞争。我原以为是锁没初始化对，结果用`helgrind`一查，发现是某个线程在持有锁的时候调了`printf`，而`printf`内部又开了锁，导致死锁。更坑的是，这个`printf`是在调试时加的，本来想打印点日志，结果成了罪魁祸首。后来我学乖了，线程相关的代码，连`printf`都不敢随便加，改用`write`直接写日志文件，虽然麻烦，但至少不会死锁。那天晚上，我对着代码里的`pthread_mutex_lock`和`pthread_mutex_unlock`，突然觉得它们像两扇门——你以为关上了，其实可能被风吹开了。

　　第五个陷阱是系统调用的“隐形失败”。有次用`select`监听多个文件描述符，结果`select`返回的值比预期的小。我查了半天，发现是某个文件描述符在`select`之前被关闭了，但`select`没报错，只是默默忽略了它。更气的是，`errno`也没被设置，导致调试时根本找不到问题。后来我改用`epoll`，虽然学习成本高了点，但至少不会出现这种“隐形失败”的情况。这事儿让我想起上次修水管——明明关了总阀，结果水还在流，后来发现是某个分支阀没关紧，和`select`这德行一模一样。

　　这些坑里，最让我后怕的是信号掩码那个——明明代码逻辑没问题，结果问题出在部署脚本上。要是没翻到那句漏掉的`sigprocmask`，我可能还在代码里死磕，越查越怀疑人生。Unix调试这事儿，有时候真不是代码写得好就能解决的，系统层面的细节太多了，一个不留神就掉坑里。现在我调Unix相关的代码，第一件事就是检查信号掩码、文件描述符、线程锁这些“隐形杀手”，宁可多花点时间，也不想再被这些坑折磨了。

　　不过话说回来，这些坑虽然气人，但也算是“优胜劣汰”吧——能避开这些坑的开发者，水平肯定差不了。要是哪天Unix调试变得太简单，那这行也就没挑战性了，你说是不是？

（编辑：站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!