Static analysis of "fallible" allocation sites



Firefox Build System
Source Code Analysis
9 years ago
19 days ago


(Reporter: cjones, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


Even with infallible malloc, some allocation sites will still want to be fallible.  At a minimum, these will be content-controlled allocations (e.g. backing memory for an img heigh= width=).  Informally speaking, we want to ensure that these allocations are indeed being checked and that if the allocation fails, the error is propagated to the event loop.

Fallible allocators are (i) all the moz_ (as opposed to moz_x) allocators in mozalloc.h; (ii) operator new(size_t, fallible_t); (iii) operator new[](size_t, fallible_t).

So a neat static analysis would be to check, for each fallible allocation site a

  * if a fails, it returns either the raw (NULL) pointer or NSERROR_OOM
  * compute all (minimum) paths P in the callgraph from the event loop to a, and
      for each p \in P
        for each node n \in P
          for each out-edge e from n to other node m
            at all call sites in n to node m
              the nsresult or raw pointer returned from m is propagated, or the raw pointer is checked for NULL and NSERROR_OOM is returned

To be usably efficient, this might require some clever graph algorithm optimizations.
crash-stats does a job of this for us.
Last Resolved: 5 years ago
Resolution: --- → WONTFIX


19 days ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.