Remote debugging

When a bug is reproducible by a community member, but not on a developer's computer, a last-resort strategy is to debug it on the community member's computer. The crash victim should at least know how to run a debugger, if not how to use it, and should have a debug build of Firefox handy.

This requires quite a bit of trust, in both directions. The developer trusts that his time is not being wasted: the crash is a real bug in Firefox. (That is, there's a legitimate reason it happens only on some computers, but that reason just hasn't been discovered.) The crash victim, in turn, trusts the developer with full access to his computer.

A good place to start is a detailed stack (in gdb, use bt followed by bt full).  There give more information about the stack than a Breakpad crash report: not only the names of the functions on the stack, but also the values they were passed.





Mac上でコアダンプを生成するため、「ulimit -c unlimited」をタイプして、コマンドラインからFirefoxを起動し、Firefoxをクラッシュする。Firefoxがクラッシュしたとき、コアは /Cores に位置する。そしてあなたはgdb(gdb firefox-bin corefile)にコアファイルをロードすることができる。そしてそれはgdb下でFirefoxを起動している間、あたかもクラッシュをキャッチしたかのようになるでしょう!




Debugging over Bugzilla

Explain in the bug that you have a core file or can reproduce the crash as many times as needed. The developer can give you appropriate commands to type into the debugger.

Examples: 367650, 374356, 393325, 418139

Debugging over IRC

IRCで開発者を見つけ、デバッガでバグを捕らえたことを説明してください。 デバッグは通常多くのオブジェクトの表示を必要とするので、これはBugzillaでデバッグするよりはるかに早い。IRCにペーストするには長すぎるためpastebin.mozilla.orgを使いなさい。

Examples: 391851


VNCFog Creek Copilotのようなリモートデスクトップソフトウェアを使用することであなたのコンピュータを制御することを開発者に提案してください。



Examples: 496391, 476241