---

D.2.3如何报告bug¶

将Octave的错误返回提交给Octave错误跟踪器https://bugs.octave.org.

有效报告错误的基本原则是:返回所有事实。如果你不确定是语句afact还是忽略它,请语句！

人们往往忽略事实,因为他们认为自己知道问题的原因,并得出结论认为一些细节无关紧要。因此,您可能会假设您在示例中使用的变量的名称无关紧要。也许没有,但我们不能确定。也许这个错误是错误的内存引用,它恰好从内存中存储该名称的位置获取;也许,如果名称不同,那么该位置的内容会欺骗解释器,使其在出现错误的情况下做正确的事情。谨慎行事,并给出一个具体、完整的例子。

请记住,错误返回的目的是使某人能够在未知的情况下修复错误。总是在假设错误未知的情况下编写错误返回。

有时人们会给出一些粗略的事实,然后问:“这听起来很奇怪吗？”这并不能帮助我们修复错误。最好先发送一个completebug返回。

尝试使您的错误返回独立。如果我们必须向您询问更多信息,最好在您的回复中包括之前的所有信息以及缺失的信息。

为了让某人能够调查该漏洞,您应该包括以下所有内容:

• Octave的版本。您可以通过记录Octave启动时打印的版本号,或使用v参数
• 一个完整的输入文件,将再现错误。

  一个单独的语句可能还不够——错误可能取决于最终发生错误的单个语句中缺少的其他细节。

• 您给Octave的命令参数用于执行该示例并观察错误。为了保证你不会遗漏一些重要的东西,列出所有的参数。

  如果我们试图猜测这些参数,我们可能会猜错,这样我们就不会遇到错误。

• 您正在使用的机器类型,以及操作系统名称和版本号。
• 提供给的命令行参数配置命令。
• 您对interpretersource所做的任何修改的完整列表。

  对这些变化要精确——显示它们的上下文差异。

• 与Octave安装标准程序的任何其他偏差的详细信息。
• 描述你认为正确的行为。例如,“解释器get致命信号”,或者“第208行返回的输出不正确。

  当然,如果错误是解释器get了致命的信号,那么我们就不会错过它。但如果错误是不正确的输出,我们可能不会注意到,除非它是明显错误的。

  即使你遇到的问题是一个致命的信号,你仍然应该明确地说出来。假设发生了一些奇怪的事情,例如,您的解释器副本不同步,或者您在系统的C库中遇到了错误。你的副本可能会崩溃,而这里的副本不会。如果你说预计会崩溃,那么当这里的解释器没有崩溃时,我们就会知道这个bug没有出现。如果你不说预计会发生崩溃,那么我们就不知道这个错误是否正在发生。我们无法从我们的观察中得出任何结论。

  当程序运行时,通常观察到的症状是错误的输出。不幸的是,除非程序简短,否则这些信息还不够。如果您能解释预期输出,以及实际输出不正确的原因,这将非常有帮助。

• 如果您希望建议对Octave源进行更改,请将其作为上下文差异发送。如果你甚至讨论了Octave源中的一些内容,请根据上下文而不是行号来参考,因为开发源中的行号可能与源中的不匹配。

以下是一些不必要的内容:

• 错误包络的描述。

  通常,遇到错误的人会花很多时间研究对输入文件的哪些更改会使错误消失,哪些更改不会影响它。这些信息通常不是我们在Octave中修复错误所必需的,但如果你能找到一个更简单的例子来返回相反原来的一个,那是一个方便。输出中的错误将更容易查找,在调试器下运行将花费更少的时间等。大多数Octave错误只涉及一个函数,因此简化示例的最简单方法是删除除发生错误的函数定义之外的所有函数定义。

  然而,简化并不重要;如果您不想点这个,请报告错误并发送您使用的整个测试用例。

• 漏洞的补丁。补丁可能会有所帮助,但如果你查找了错误,即使你不能发送问题的修复程序,你也应该返回它。