The Builds

All of the SM(...) builds appearing on Treeherder are JS shell-only builds. Currently, they all

• Checkout the source
• Configure using a set of options appropriate to the specific build
• Build (by simply invoking make)
• Run tests, possibly differently depending on the specific build

All of this is done by running the Python script js/src/devtools/automation/autospider.py <variant>, where <variant> is one of the filenames in js/src/devtools/automation/variants/.

Reproducing a build

You should be able to closely replicate a TH build by running autospider.py yourself. For example, to replicate SM(cgc), you could be anywhere within your checkout, and run

 <gecko-root>/js/src/devtools/automation/autospider.py --clobber compacting

The default objdir is <gecko-root>/obj-spider. You can change it by setting the $OBJDIR environment variable.

To narrow the test down, delete some of the lines at the end of autospider.py that run the various tests.

Mapping variants to SM(...) names

There is no good way. They're hardcoded in the Treeherder code. Many of them even show up in multiple repos. Here's a snapshot:

• SM(cgc) - compacting
• SM(p) - plain or plaindebug
• SM(arm) - arm-sim or arm-sim-osx
• SM(arm64) - arm64-sim
• SM(exr) - exactrooting
• SM(r) - rootanalysis
• SM(pkg) - Standalone SpiderMonkey package.
• SM(tsan) - tsan

Specific Build Information

SM(pkg)

The SM(pkg) builds create a tarball of all the sources used to make a standalone SpiderMonkey library and shell, untar it somewhere else, and then runs the autospider command listed above. To reproduce this packaging and unpackaging behavior, you can run this command:

 <gecko-root>/testing/taskcluster/scripts/builder/build-sm-package.sh

SM(tsan)

sm-tsan uses the clang ThreadSanitizer dynamic thread safety checker. Since this is a dynamic analysis, any given run may report only a subset of issues based on the exact timing of that run. One thing that means is that failures in this job may well be intermittent, and thus may not be due to the immediately preceding push. You may consider retriggering a failure a few times to see what to blame it on.

ThreadSanitizer failures are generally not security sensitive, though they can be. The usual rules apply -- eg if it's in GC code, it should be assumed to be sensitive until investigated.