On Thu, Apr 21, 2016 at 2:23 PM, Nicolas B. Pierron < [email protected]> wrote:
> On 04/21/2016 05:16 PM, Jan de Mooij wrote: > >> Is our only option doubling down on these fuzz bugs and adding more >> assertions, or can we do better with static analysis, the type system, >> annotations, something? >> > > From the type system point of view, I think we could add a type to > distinguish the Allocation failures from boolean types. In many cases, I > found that we were mixing the true/false expectation of an analysis, with > the true/false of an allocations. > I agree. One of the annoyances with my static analysis was that the analysis had to guess the meaning of every bool return type. > Using the type system would involve making a lot of modifications to the > code base, either to wrap/unwrap error code, or to add new enumerated > types. I think this could be a good long term solution, but hardly a way > to make incremental progress. > I bet we can do a mass-change. > This means that an analysis should probably: (1) Go through the body of > functions, and look for values returned in case of allocation failures. (2) > Annotate the function declaration with the value used on allocation > failures. (3) Revisit by going to 1. any of the functions which are using > any of the annotated function declarations. (4) Ensure that virtual > functions have consistent error values. > The biggest problem I had with my analysis was that some templates abstracted over error-handling strategies. Ugh. Here's the README I wrote. In particular, note the precise rules the analysis tries to enforce. https://gist.github.com/jorendorff/0763b926f08d468c028453969a47abef There is nothing OOM-specific in the readme. My actual analysis code did distinguish OOM, but maybe it's not so different that we really have to. At the time I wrote it, OOM did not set a pending exception, so it was quite different. (It is still possible to have an uncatchable error condition, though, so who knows.) (All APIs where a non-OOM error is possible would still require careful error checking even if we decided to crash on OOM.) -j _______________________________________________ dev-tech-js-engine-internals mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
