Javascript:Hazard Builds: Difference between revisions

Jump to navigation Jump to search
updated to current reality
(updated to current reality)
Line 9: Line 9:
== Static Rooting Analysis ==
== Static Rooting Analysis ==


Tbpl can run two static analysis builds, one for the full browser (linux64-br-haz) and one for just the JS shell (linux64-sh-haz). The former shows up on tbpl as '''SM(Hf)''', the latter as '''SM(Hs)''':
Tbpl can run two static analysis builds, one for the full browser (linux64-br-haz) and one for just the JS shell (linux64-sh-haz). They show up on treeherder as '''H'''.
* Hf - hazard build for '''f'''irefox browser
* Hs - hazard build for JS '''s'''hell
* Hb - hazard build for '''B'''2G (in progress)
* Hm - hazard build for '''m'''obile firefox browser (in progress)


These builds are performed as follows:
These builds are performed as follows:
Line 32: Line 28:
The far easier way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-br-haz -u none| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-sh-haz -u none| for a much faster result). The expected turnaround time for linux64-br-haz is just under 2 hours.
The far easier way to run an analysis is to push to try with the trychooser line |try: -b do -p linux64-br-haz -u none| (or, if the hazards of interest are contained entirely within js/src, use |try: -b do -p linux64-sh-haz -u none| for a much faster result). The expected turnaround time for linux64-br-haz is just under 2 hours.


The output will be uploaded to a path similar to http://stage.mozilla.org/pub/mozilla.org/firefox/try-builds/sfink@mozilla.com-a5d4f2abfda378eb57e4b6bbc5bb9d5186e0d62d/try-linux64-br-haz/ . At the moment, you'll need to dig that path out of the log file. (I will be adding it to the summary information displayed on tbpl "soon".)
The output will be uploaded and a link will be placed into the build summary info pane on treeherder. If the analysis fails, you will see the number of failures (and the number of expected failures, which should usually be zero.)
 
If the analysis fails, you will see a message like this near the end of the log file:
 
<pre>
10:01:31    INFO - #####
10:01:31    INFO - ##### Running check-expectations step.
10:01:31    INFO - #####
10:01:31    INFO - Running main action method: check_expectations
10:01:31    INFO - Reading from file /builds/slave/l64-sh-haz_try_dep-00000000000/build/source/js/src/devtools/rootAnalysis/expect.shell.json
10:01:31    INFO - Contents:
10:01:31    INFO -  {
10:01:31    INFO -    "expect-hazards": 1
10:01:31    INFO -  }
10:01:31    INFO - Reading from file /builds/slave/l64-sh-haz_try_dep-00000000000/build/analysis/rootingHazards.txt
10:01:31  WARNING - 3 more hazards than expected (expected 1, saw 4)
10:01:31  WARNING - # TBPL WARNING #
</pre>


=== Analysis output ===
=== Analysis output ===
Line 97: Line 76:
The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21
The most common way to fix a hazard is to change the variable to be a Rooted type, as described in http://dxr.mozilla.org/mozilla-central/source/js/public/RootingAPI.h#l21


For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink, terrence, or jonco, and for the really hairy stuff, billm.
For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink, terrence, or jonco.
 
But to do that, you have to identify the hazard. Right now, we still have quite a few known hazards. For now, you'll want to look through hazards.txt for hazards in files that your patch touched. You can also compare with the last good run's hazards.txt file to see which hazards were added.
Confirmed users
329

edits

Navigation menu