深入分析在Python模块顶层运行的代码引起的一个Bug
然后我们在Interactive Python prompt中测试了一下:
>>> import subprocess >>> subprocess.check_call("false")
而在其他机器运行相同的代码时, 却正确的抛出了错误:
>>> subprocess.check_call("false") Traceback (most recent call last): File "", line 1, in File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 542, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'false' returned non-zero exit status 1
看来是subprecess误以为子进程成功的退出了导致的原因.
深入分析
第一眼看上去, 这一问题应该是Python自身或操作系统引起的. 这到底是怎么发生的? 于是我的同事查看了subprocess的wait()方法:
def wait(self): """Wait for child process to terminate. Returns returncode attribute.""" while self.returncode is None: try: pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0) except OSError as e: if e.errno != errno.ECHILD: raise # This happens if SIGCLD is set to be ignored or waiting # for child processes has otherwise been disabled for our # process. This child is dead, we can't get the status. pid = self.pid sts = 0 # Check the pid and loop as waitpid has been known to return # 0 even without WNOHANG in odd situations. issue14396. if pid == self.pid: self._handle_exitstatus(sts) return self.returncode
可见, 如果os.waitpid的ECHILD检测失败, 那么错误就不会被抛出. 通常, 当一个进程结束后, 系统会继续记录其信息, 直到母进程调用wait()方法. 在此期间, 这一进程就叫"zombie". 如果子进程不存在, 那么我们就无法得知其是否成功还是失败了.
以上代码还能解决另外一个问题: Python默认认为子进程成功退出. 大多数情况下, 这一假设是没问题的. 但当一个进程明确表明忽略子进程的SIGCHLD时, waitpid()将永远是成功的.
回到原来的代码中
我们是不是在我们的程序中明确设置忽略SIGCHLD? 不太可能, 因为我们使用了大量的子进程, 但只有极少数情况下才出现同样的问题. 再使用git grep后, 我们发现只有在一段独立代码中, 我们忽略了SIGCHLD. 但这一代吗根本就不是程序的一部分, 只是引用了一下.
一星期后
一星期后, 这一错误又再一次发生. 并且通过简单的调试, 在debugger中重现了该错误.
经过一些测试, 我们确定了正是由于程序忽略了SIGCHLD才引起的这一bug. 但这是怎么发生的呢?
我们查看了那段独立代码, 其中有一段:
signal.signal(signal.SIGCHLD, signal.SIG_IGN)
我们是不是无意间import了这段代码到程序中? 结果显示我们的猜测是正确的. 当import了这段代码后, 由于以上语句是在这一module的顶层, 而不是在一个function中, 导致了它的运行, 忽略了SIGCHLD, 从而导致了子进程错误没有被抛出!
总结
这一bug的发生, 给了我们两个教训. 第一是, 在debug检查时, 应该从新的代码到老的代码, 再到Python Library. 因为新代码发生错误的几率大于老代码, 而python library中发生错误的几率更小.
第二是, 不要将可能会引起副作用的代码写在module顶层, 而应当写到functuon中. 因为如果该module被import, 那么在顶层的代码就会运行, 导致各种不可知的事件发生.
您可能感兴趣的文章:
- 深入分析在Python模块顶层运行的代码引起的一个Bug
- Python 官方代码threading模块的一个死锁的bug
- 一个诡异的BUG: Python导入的模块运行过程中变成了None
- Python 官方代码threading模块的一个死锁的bug
- Python代码分析工具之dis模块
- 一个由于php代码结束符引起的技术bug
- 针对python机器学习与实战代码在python3上运行出现的错误分析和warning的修改代码34—38
- Python collections模块Counter类深入分析
- python标准库logging模块代码分析
- 从BUG工具redmine上获取数据后借助python模块pycha 画出BUG分析类报表
- 【python爬虫】import引起的一个小bug【原创】
- Python代码分析工具之dis模块
- Python字符串操作和string模块代码分析
- 只运行一个应用程序的错误代码的分析
- Python3基础 创建一个模块 导入并调用其中的函数 主代码与模块代码在同一文件夹下
- 交接工作不要只分析流程和看静态的看代码呀,一定要动手,增加一个功能,解决一个 BUG什么的,才能真正理解交接的工作内容呀!
- python安装第三方包之后无法导入相应模块(一个容易忽略的bug)
- python字符串操作和string模块代码分析
- 展讯android LEDS模块分析----一个bug
- Python-一个因浅复制和深复制引起的bug