编辑:非常感谢在发现bug方面的帮助,但由于可能很难找到/复制,任何一般的调试帮助也将不胜感激!帮帮我自己
   
  
  
   
    编辑2:缩小它的范围,注释掉代码。
   
  
  
   
    编辑3:看起来lxml可能不是罪魁祸首,谢谢!完整的脚本是
    
     here
    
    。我需要翻一翻,寻找参考资料。它们长什么样?
   
  
  
   
    编辑4:事实上,脚本在这里停止(100%)
   
   
    parse_og
   
   
    部分原因。所以edit3是错误的——它一定是lxml。
   
  
  
   
    
     编辑5主要编辑:正如下面David Robinson和TankorSmash所建议的,我发现了一种
     
      data
     
     将发送的内容
     
      lxml.etree.HTML( data )
     
     在一个疯狂的循环中。(我漫不经心地忽略了它,但发现我的罪过得到了弥补,因为我付出了额外两天调试的代价!)
     
      A working crashing script is here.
     
     
      (Also opened a new question.)
     
    
   
  
  
   
    编辑6:这是lxml 2.7.8及以下版本的一个错误(位于
最少)。
    
     Updated to lxml 2.9.0
    
    ,bug消失了。也要感谢在
    
     this follow-up question.
    
   
  
  
   我不知道如何调试我遇到的这个奇怪的问题。
当RAM突然完全充满时(在100%期间从200MB到1700MB,然后当内存充满时,它进入蓝色等待状态),下面的代码运行约五分钟。
  
  
   这是由于下面的代码,特别是前两行代码。这是肯定的。但到底发生了什么?什么可能解释这种行为?
  
  def parse_og(self, data):
    """ lxml parsing to the bone! """
    try:
        tree = etree.HTML( data ) # << break occurs on this line >>
        m = tree.xpath("//meta[@property]")
        #for i in m:
        #   y = i.attrib['property']
        #   x = i.attrib['content']
        #   # self.rj[y] = x  # commented out in this example because code fails anyway
        tree = ''
        m = ''
        x = ''
        y = ''
        i = ''
        del tree
        del m
        del x
        del y
        del i
    except Exception:
        print 'lxml error: ', sys.exc_info()[1:3]
        print len(data)
        pass