Closed
Bug 512868
Opened 15 years ago
Closed 12 years ago
Static analysis of "fallible" allocation sites
Categories
(Developer Infrastructure :: Source Code Analysis, defect)
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: cjones, Unassigned)
References
Details
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.
Reporter | ||
Updated•15 years ago
|
Blocks: static_analyses
Reporter | ||
Comment 1•12 years ago
|
||
crash-stats does a job of this for us.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Updated•7 years ago
|
Product: Core → Firefox Build System
Updated•2 years ago
|
Product: Firefox Build System → Developer Infrastructure
You need to log in
before you can comment on or make changes to this bug.
Description
•