|
|
| Line 42: |
Line 42: |
| == SM(tsan) == | | == SM(tsan) == |
|
| |
|
| sm-tsan is a dynamic thread safety checker, which means that any given run will only report a subset of issues. Also, we have a number of errors currently in the codebase that it will allow through without turning the build red. These are listed in | | 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. |
|
| |
|
| <gecko-root>/js/src/devtools/automation/variants/tsan
| | ThreadSanitizer failures are generally not security-critical, though they can be. |
| | |
| under the 'expect-errors' key. These are a list of filename,function pairs. (We cannot use a line number because it would change whenever lines are added/removed.) For a given build, errors are summarized in a tsan_summary.txt artifact, and the detailed stack information produced by tsan will be bundled up in a tsan.tar.gz file containing per-pid outputs.
| |
| | |
| The mrgiggles server is running a script that downloads and categorizes the observed failures, but it isn't done yet (it misses some pushes), and it does not yet expose the information it collects. If you're looking into a specific failure, you can either dig it out of tsan.tar.gz, or ask sfink for the detailed failure information. (mrgiggles watches for job completions, downloads tsan.tar.gz, and records the failure stacks in a file named after the filename, line number, and function name.)
| |