編集：本当にバグを見つけていただきありがとうございます。しかし、見つけたり、再現したりするのが難しいかもしれないので、一般的なデバッグヘルプも非常に高く評価されます！私を助けてください！ =）Pythonメモリフォールトをデバッグするには？
編集2：コードをコメントアウトして編集します。
編集3：lxmlが原因ではないようですね、ありがとう！完全なスクリプトはhereです。私は参照を探してそれを調べる必要があります。彼らはどんな見た目ですか？
編集4：実際にそれのparse_og一部、スクリプトが停止し、この中で（100％を行きます）。だから編集3は偽です - 何とかlxmlでなければなりません。
編集5 MAJOR EDIT：デビッド・ロビンソン、以下TankorSmashによって示唆されるように、私は野生のループでlxml.etree.HTML(data)をお送りしますdataコンテンツの種類を見つけました。 （私はうっかりそれを無視し、私はデバッグの余分な2日間の曲に価格を支払ってきたように私の罪が贖わ見つける;！）A working crashing script is here.(Also opened a new question.)
編集6：判明これはバグですlxmlバージョン2.7.8以下（ 以上）。 Updated to lxml 2.9.0、バグがなくなった。上の上級者にも感謝this follow-up question.
私はこの奇妙な問題をデバッグする方法がわかりません。 以下のコードは、RAMが突然完全にいっぱいになる（約100MBの間に200MBから1700MBに達した後、メモリがいっぱいになると、ブルーの待機状態になる）約5分間正常に実行されます。
以下のコード、具体的には最初の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
私たちもコードをテストできるように、HTMLの 'data'をリンクできますか？ – TankorSmash
'data'はそこのHTML文書の最初の5000バイトです。 – knutole
難しいことではありませんが、さまざまなページで試してみましたが、どのデータを渡しても問題ありません。 – TankorSmash