附录B -- 如何报告bug

好的bug报告对任何软件项目的发展都是十分有价值的贡献。但是就象写好的软件一样,好的问题报告也需要一些工作。请明白大多数开发者忙的要死并且会收到 多的变态的电子邮件。所以尽管你的反馈对改进MPlayer至关重要而且非常值得赞赏,希望你理解你必须提供我们需要的所有信息并且严格遵循这个 文件中的指导进行。

B.1 如何修复bug

如果你觉得你有足够的技巧欢迎你尝试自己修正bug。还是你已经这么干了?请阅读这个简短的文件了解怎样让你的代码 包括到MPlayer的代码中。如果你有问题可以从加入mplayer-dev-eng 邮件列表的人那里获得帮助。

B.2 如何报告bug

首先,请先尝试MPlayer最新的CVS版本,因为你的bug在那里可能已经被修正了。发展过程进展的相当快,官方发行版的大部分问题在几天甚至几小时之内 就被报告了,因此请仅仅使用CVS来报告bug。这包括MPlayer的二进制安装包,请不要报告MPlayer的各种RPM变种和Debian安装包的bug。CVS指 令能在这个页面的底部或者README中找到。如果这样做没有改进那么请查阅已知的bug和文件的其他部分。如果你的问题我们没有提到或者按照我们提供的步骤没有解决,那么请报告bug。

请不要私下单独向开发者报告bug。这是一项社区工作所以可能有若干人都对它感兴趣。有时其它用户已经遇到过你的麻烦并且知道如何绕过这个问题 即使它是MPlayer代码中的bug。

请尽可能详细的描述你的问题。做一些小的侦探工作来确定问题发生的情况的范围。这个bug只在一定的情况中出现吗?或是具体针对特定文件或者文件类型吗? 它是针对于唯一的编码格式还是独立于编码格式的?你能用所有的输出驱动重现它吗?你提供的信息越多我们的修复你的问题的机会就越大。别忘了也要包括下面所要求的 有价值的信息,否则我们将无法正确分析你的问题。

有篇文采飞扬的关于如何在公共论坛上提问的极好的指导是Eric S. Raymond写的How To Ask Questions The Smart Way。还有另一篇Simon Tatham写的如何有效的报告Bugs。 按照那些指示做是没有问题的。但是请明白我们大家都在我们的自由时间自愿地回复邮件列表。我们十分忙碌并且 不能保证你的问题一定能得到解决甚至得到回复。

B.3 向哪里报告错误?

订阅mplayer-users邮件列表:
    http://mplayerhq.hu/mailman/listinfo/mplayer-users
同时,把你的bug发送到:
    mplayer-users@mplayerhq.hu

这个列表使用的语言是英语。请遵循标准的网络礼节指导并且不要发送HTML邮件 到任何我们的邮件列表。你将被忽略或者封掉。如果你不知道什么是HTML邮件,以及它为什么邪恶,看看这篇写的不错的文档。它解释了所有细节和关掉HTML的指令。也请注意到我们不会个别地CC(抄送)给人因此 最好通过订阅来保证你会收到答案。

B.4 报告什么?

你可能需要在你的bug报告中包括log,配置或者样本文件。如果它们中间有什么特别大的,最好把它们以压缩格式(最好是gzip或bzip2) 上载到我们的FTP服务器上。我们的邮件列表上一条消息大小限制是80k, 如果你有比这更大的东西请压缩或上载它。

B.4.1 系统信息

B.4.2 硬件和驱动

B.4.3 配置问题

如果你在运行./configure时有问题,或者什么东西的自动检测失败,检查configure.log。你可能会在那里找到 答案,比如你的机器上存在同一个库的多个版本混合存在的问题。或者你忘记安装开发包(那些-dev后缀的)。如果你认为有bug,在你的bug报告 中附上configure.log

B.4.4 编译问题

请附上下列文件: 如果编译失败发生在下面的目录,附上这些文件:

B.4.5 播放的问题

请包括MPlayer的冗长水平为1的输出,但是记住当你把它粘贴到你的邮件中时不要删减输出内容。开发者们需要所有的信息来正确的分析问题。 你可以像这样把输出导入到一个文件中:

    mplayer -v [options] [filename] > mplayer.log 2>&1

如果你的问题是具体对于一个或更多的文件的,那么请上传有问题的文件:

    ftp://mplayerhq.hu/MPlayer/incoming/

再上传一个小的同样文件名的文本文件加上.txt的扩展名。在其中描述对于这个特别的文件你遇到的问题加上你的电子邮件地址还有MPlayer冗长水平为1的输出。 通常文件的前1-5MB足以重现问题,但为了以防万一我们要求你运行:

    dd if=yourfile of=smallfile bs=1024k count=5

它将截取'your-file'的头5兆并把他们写到'small-file'里。然后,测试一下这个小文件,如果bug仍然存在那么你的样本 对我们来说是足够了。请永远不要通过邮件的发送这样文件!把它上传,然后只发送FTP-server上的文件的路径与文件名。如果文件在网上可以获得, 那么发送准确的URL就足够了。

B.4.6 崩溃

你应该在gdb里面运行MPlayer并把完整的输出发送给我们,或者你有一个崩溃产生的core dump,你可以从Core文件中提取 有用的信息,下面教你怎么做:

如果你的崩溃有一个core dump那么继续阅读下一段,否则跳过它。

B.4.6.1 如何保存一个可重复的崩溃的信息

开启调试代码重新编译MPlayer:

    ./configure --enable-debug=3
    make

然后用gdb运行MPlayer:

    gdb mplayer

现在你在gdb内。输入:

    run -v [options-to-mplayer] filename

然后再现你的崩溃。一旦你成功了,gdb将回到命令行,你需要输入

    bt
    disass $pc-32 $pc+32
    info all-registers

B.4.6.2 如何从一个core dump中提取出有意义的信息

请建立下面的命令文件:

bt
disass $pc-32 $pc+32
info all-registers

然后直接在你的命令行下执行下列命令:

    gdb mplayer --core=core -batch --command=command_file > mplayer.bug

B.5 我知道我在干什么...

如果你按照上述步骤建立了一个正确的bug报告而且你充满信心它是MPlayer中的bug,而不是因为编译错误或者文件损坏的问题,你已经阅读了文档并且 找不到解决方案,此外你的声卡驱动正常,那么你可能想要订阅mplayer-advusers列表并把你的bug报告发到那里以便得到更快更好的答案。

请听从我们的劝告,如果你在那里问新手级的问题或者问用户手册中已经回答过的问题,你将被忽略或者被骂而不会得到答案。
因此,不要骂我们并且仅仅当你确实知道你在干什么并且觉得你已经是高级MPlayer用户或者是开发者再订阅 -advusers。如果你符合这些标准找出如何 订阅应该不难...