Congratulations! You may be the proud new user and/or sheriff of a Mozilla Firefox Tinderbox. Here are some important bits of info you should know.

There's a new sheriff in town

• Sheriffing schedules are posted on the top of the Firefox Tinderbox page
• The Sheriff_Duty page contains a general overview of what sheriff duty entails
• The password for tinderbox/bonsai administration is kept in the sheriffpass bug, if you've been deputized an existing sheriff can CC you to the bug.
• How to back out changes
• How to clobber on Hg

Uh oh, something broke

The Tinderbox tends to be inflammable (what a country!). While code checkins can obviously cause build/test failures, a box may fail in various ways not related to checkins. Some problems fix themselves in the next cycle, others require filing a server ops bug (in mozilla.org / Server Ops: Tinderbox Maintenance).

A unit test failed

If you see a unittest failure, please check the dependencies of bug 438871 to see if it's already filed. If it isn't, then you should file a bug! A failing test *is always a bug*. It's either a bug in the test or in the code, but it needs to be tracked.

Why isn't that box doing anything?

• Some boxes only start doing something when there's a checkin. If a cycle fails for some reason, if will remain red/orange until a checkin triggers a new build.
• Force a build to start by making a trivial checkin:
  • Make a whitespace change
  • Fix a spelling from the spelling bug.

Failed to kill process

• The Windows unit test boxes may fail with errors like:

buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process

• This might indicate a hang while running the test
• It might also mean that a test threw an exception that caused the test harness itself to fail, and the test running script timed out and tried to kill the browser
• This condition may not be caused by a specific checkin, and might fix itself upon the next cycle (when someone checks in).

XUL Popup test failures

• These are due to browser window focus problems on the test box, often because someone logged in to do maintenance and left something else focused.
• File a server ops bug to have the problem corrected
• Sometimes it's unclear why there's a failure, and the box needs rebooted?

libpr0n reftest failures

• Multiple failures on Windows in modules/libpr0n/test/reftest/ can be due to the box reverting back to 16-bit color mode. See bug 414720 for history.
  • Caused by someone connecting to the box with a RDP client in 16-bit color mode.
  • File a server ops bug to have the problem corrected.
• REFTEST UNEXPECTED FAIL (LOADING)
  • Fixed by bug 425987

make[6]: *** INTERNAL: readdir: Bad file number

• Happens occasionally on the Windows unit test box (eg qm-win2k3-01).
• This condition should fix itself upon the next cycle (when someone checks in).

Error: bloat test timed out after 1800 seconds.

• Seen sometimes on qm-win2k3-01 (other platforms too?)
• Should fix itself upon the next cycle (when someone checks in)

bzip2: Data integrity error when decompressing.

• Happens sporadically on Talos boxes
• Should fix itself on next cycle?
• Fixed by bug 427728, 15 May.

Spurious RLk test failure on bm-xserve11

• Error: Leak Test Failed: Number of leaks 1234 is greater than LeakFailureThreshold 0
• Infrequent, often missed due to fast cycle time of this box
• Tracking in bug 412545

(add more common failures here)

See also: http://wiki.mozilla.org/Buildbot/IT_Unittest_Support_Document