深入分析在Python模塊頂層運行的代碼引起的一個Bug

更新時間：2014年07月04日 09:52:16 作者：Desmond Chen

幾個星期前, 我的同事跑過來, 說發(fā)現(xiàn)一個奇怪的Bug: 在使用Python的subprocess運行子進(jìn)程時, 當(dāng)子進(jìn)程運行失敗時居然沒有拋出錯誤!

然后我們在Interactive Python prompt中測試了一下:

>>> import subprocess
  >>> subprocess.check_call("false")
  0

而在其他機(jī)器運行相同的代碼時, 卻正確的拋出了錯誤:

>>> 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誤以為子進(jìn)程成功的退出了導(dǎo)致的原因.

深入分析

第一眼看上去, 這一問題應(yīng)該是Python自身或操作系統(tǒng)引起的. 這到底是怎么發(fā)生的? 于是我的同事查看了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檢測失敗, 那么錯誤就不會被拋出. 通常, 當(dāng)一個進(jìn)程結(jié)束后, 系統(tǒng)會繼續(xù)記錄其信息, 直到母進(jìn)程調(diào)用wait()方法. 在此期間, 這一進(jìn)程就叫"zombie". 如果子進(jìn)程不存在, 那么我們就無法得知其是否成功還是失敗了.

以上代碼還能解決另外一個問題: Python默認(rèn)認(rèn)為子進(jìn)程成功退出. 大多數(shù)情況下, 這一假設(shè)是沒問題的. 但當(dāng)一個進(jìn)程明確表明忽略子進(jìn)程的SIGCHLD時, waitpid()將永遠(yuǎn)是成功的.

回到原來的代碼中

我們是不是在我們的程序中明確設(shè)置忽略SIGCHLD? 不太可能, 因為我們使用了大量的子進(jìn)程, 但只有極少數(shù)情況下才出現(xiàn)同樣的問題. 再使用git grep后, 我們發(fā)現(xiàn)只有在一段獨立代碼中, 我們忽略了SIGCHLD. 但這一代嗎根本就不是程序的一部分, 只是引用了一下.

一星期后

一星期后, 這一錯誤又再一次發(fā)生. 并且通過簡單的調(diào)試, 在debugger中重現(xiàn)了該錯誤.

經(jīng)過一些測試, 我們確定了正是由于程序忽略了SIGCHLD才引起的這一bug. 但這是怎么發(fā)生的呢?

我們查看了那段獨立代碼, 其中有一段:

signal.signal(signal.SIGCHLD, signal.SIG_IGN)
我們是不是無意間import了這段代碼到程序中? 結(jié)果顯示我們的猜測是正確的. 當(dāng)import了這段代碼后, 由于以上語句是在這一module的頂層, 而不是在一個function中, 導(dǎo)致了它的運行, 忽略了SIGCHLD, 從而導(dǎo)致了子進(jìn)程錯誤沒有被拋出!

總結(jié)

這一bug的發(fā)生, 給了我們兩個教訓(xùn). 第一是, 在debug檢查時, 應(yīng)該從新的代碼到老的代碼, 再到Python Library. 因為新代碼發(fā)生錯誤的幾率大于老代碼, 而python library中發(fā)生錯誤的幾率更小.

第二是, 不要將可能會引起副作用的代碼寫在module頂層, 而應(yīng)當(dāng)寫到functuon中. 因為如果該module被import, 那么在頂層的代碼就會運行, 導(dǎo)致各種不可知的事件發(fā)生.

您可能感興趣的文章: