11

编辑：非常感谢您在寻找错误方面的帮助 - 但由于它可能很难找到/重现，任何一般的调试帮助也将不胜感激！帮我帮自己！=)

编辑2：缩小范围，注释掉代码。

编辑 3：似乎 lxml 可能不是罪魁祸首，谢谢！完整的脚本在这里。我需要仔细阅读它以寻找参考。他们看起来怎么样？

编辑 4：实际上，脚本在这部分停止（100%） 。parse_og 所以编辑 3 是错误的 - 它一定是 lxml 不知何故。

编辑 5 主要编辑：正如下面大卫罗宾逊和 TankorSmash 所建议的那样，我发现了一种data将lxml.etree.HTML( data )在疯狂循环中发送的内容。（我不小心忽略了它，但发现我的罪已被赎回，因为我已经付出了额外两天调试的代价！;) 一个有效的崩溃脚本在这里。 （还提出了一个新问题。）

编辑 6：原来这是 lxml 2.7.8 及以下版本的错误（至少）。更新到 lxml 2.9.0，并且错误消失了。还要感谢这个后续问题的好人。

我不知道如何调试我遇到的这个奇怪的问题。下面的代码可以正常运行大约五分钟，这时 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

在此处输入图像描述

4

3 回答 3

3

您可以尝试使用 GDB 进行低级 Python 调试。Python解释器或lxml库中可能存在错误，如果没有额外的工具很难找到它。

当 CPU 使用率达到 100% 时，您可以中断在 gdb 下运行的脚本并查看堆栈跟踪。它可能有助于理解脚本内部发生的事情。

于 2013-03-09T17:58:42.930 回答
2

这一定是由于一些参考资料使文件保持活力。必须始终小心 xpath 评估的字符串结果。我看到您已分配None给tree和m但未分配给y,x和i。

你也可以分配None给y,x和i.

于 2013-03-08T23:06:36.847 回答
2

在尝试追踪内存问题时，工具也很有帮助。我发现guppy是一个非常有用的 Python 内存分析和探索工具。

由于缺乏好的教程/文档，它不是最容易上手的，但是一旦你掌握了它，你会发现它非常有用。我使用的功能：

  • 远程内存分析（通过套接字）
  • 用于图表使用的基本 GUI，可选择显示实时数据
  • 用于在 Python shell 中探索数据使用的强大且一致的接口
于 2013-03-09T16:32:20.373 回答