Confirmed users
328
edits
Javascript:Hazard Builds: Difference between revisions
→Static Analysis for Rooting Hazards: stuff about heap writes
(terrence gone.) |
(→Static Analysis for Rooting Hazards: stuff about heap writes) |
||
| Line 1: | Line 1: | ||
== Static Analysis for Rooting Hazards == | == Static Analysis for Rooting and Heap Write Hazards == | ||
Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''. | Treeherder can run two static analysis builds: the full browser (linux64-haz), just the JS shell (linux64-shell-haz). They show up on treeherder as '''H''' and '''SM(H)'''. | ||
=== Diagnosing a hazard failure === | === Diagnosing a hazard failure === | ||
The first step is to look at what sort of hazard is being reported. There are two types that cause the job to fail: stack rooting hazards for garbage collection, and heap write thread safety hazards for stylo. | |||
The summary output will include either the string "<N> rooting hazards detected" or "<N> heap write hazards detected out of <M> allowed". See the appropriate section below for each. | |||
=== Diagnosing a rooting hazards failure === | |||
Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "public/build/hazards.txt.gz" file. | Click on the '''H''' build link, select the "Job details" pane on the bottom right, follow the "Inspect Task" link, and download the "public/build/hazards.txt.gz" file. | ||
| Line 44: | Line 50: | ||
* during the resulting garbage collection, the object pointed to by ed.obj is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. ed.obj is not, because the GC doesn't know about it. | * during the resulting garbage collection, the object pointed to by ed.obj is moved to a different location. All pointers stored in the JS heap are updated automatically, as are all rooted pointers. ed.obj is not, because the GC doesn't know about it. | ||
* after decompilePC returns, something accesses ed.obj. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say. | * after decompilePC returns, something accesses ed.obj. This is now a stale pointer, and may refer to just about anything -- the wrong object, an invalid object, or whatever. Badness 10000, as TeX would say. | ||
=== Diagnosing a heap write hazard failure === | |||
For the thread unsafe heap write analysis, a hazard means that some Gecko_* function calls, directly or indirectly, code that writes to something on the heap, or calls an unknown function that *might* write to something on the heap. The analysis requires quite a few annotations to describe things that are actually safe. This section will be expanded as we gain more experience with the analysis, but here are some common issues: | |||
* Adding a new Gecko_* function: often, you will need to annotate any outparams or owned (thread-local) parameters in the <code>treatAsSafeArgument</code> function in <code>js/src/devtools/rootAnalysis/analyzeHeapWrites.js</code>. | |||
* Calling some libc function: if you add a call to some random libc function (eg sin() or floor() or ceil(), though the latter two are already annotated), the analysis will report an "External Function". Add it to <code>checkExternalFunction</code>, assuming it *doesn't* have the possibility of writing to shared heap memory. | |||
* If you call some non-returning (crashing) function that the analysis doesn't know about, you'll need to add it to <code>ignoreContents</code>. | |||
On the other hand, you might have a real thread safety issue on your hands. Shared caches are common problems. Fix it. | |||
=== Analysis implementation === | === Analysis implementation === | ||
| Line 81: | Line 97: | ||
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 or jonco. | For more complicated cases, ask on #jsapi. If you don't get a response, ping sfink or jonco for rooting hazards, bholley or sfink for heap write hazards. Or if it's a deeper issue with the analysis logic, try bhackett (the author of both analyses.) | ||