编辑:非常感谢在发现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