編集:バグを見つけるのに本当に感謝します-しかし、見つける/再現するのは難しいかもしれないので、一般的なデバッグの助けも大いに感謝します!私が自分自身を助けるのを手伝ってください!=)
編集2:それを絞り込み、コードをコメントアウトします。
編集3:lxmlが原因ではないようです、ありがとう!完全なスクリプトはここにあります。参考文献を探すためにそれを調べる必要があります。彼らはどんな見た目ですか?
編集4:実際には、スクリプトはこの部分で停止します(100%になります) 。parse_og
したがって、編集3は誤りです-それはどういうわけかlxmlでなければなりません。
編集5主要な編集:以下のDavid RobinsonとTankorSmashが示唆しているように、ワイルドループでdata
送信されるタイプのコンテンツを見つけました。lxml.etree.HTML( data )
(私は不注意にそれを無視しましたが、追加の2日間のデバッグの調整に代償を払ったので、私の罪が償還されました!;) 動作中のクラッシュスクリプトがここにあります。 (また、新しい質問を開きました。)
編集6:これはlxmlバージョン2.7.8以下のバグであることが判明しました(少なくとも)。lxml 2.9.0に更新され、バグはなくなりました。このフォローアップの質問に参加してくれた素晴らしい人々にも感謝します。
私が抱えているこの奇妙な問題をデバッグする方法がわかりません。以下のコードは、RAMが突然完全にいっぱいになると約5分間正常に実行されます(100%の期間中に200MBから1700MBになり、メモリがいっぱいになると、青い待機状態になります)。
これは、以下のコード、具体的には最初の2行によるものです。それは確かだ。しかし、何が起こっているのでしょうか?この振る舞いを説明できるのは何でしょうか?
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