Open Bug 427111 Opened 16 years ago Updated 2 years ago

Identify/replace allocation locations which we might want to use the new malloc_allowfail API

Categories

(Core :: General, defect)

defect

Tracking

()

People

(Reporter: benjamin, Unassigned)

References

Details

We need (somehow) to identify current allocation points in our tree which can allocate large blocks of memory, especially memory which comes from the network or user images. These allocations should use the new malloc_allowfail API from bug 427109; we should also check to make sure that they actually do handle failure relatively gracefully.

Right now I'm thinking we should just do this through dynamic analysis: use a printf in jemalloc, or dtrace, to collect allocation stacks for any allocation over 4k; browse the web somewhat extensively, then sort by callee.

dmandelin, I can't think of a static approach to detect these kinds of allocations... can you? It sounds like a really hard dataflow problem, especially because it's hard to know what counts as an allocation request from the "user".
Blocks: 427109
Blocks: 427115
Summary: Identify allocation locations which we might want to use the new malloc_allowfail API → Identify/replace allocation locations which we might want to use the new malloc_allowfail API
I agree, dynamic analysis is the way to go on this one.
One particular area is in the imgContainer for the mRestoreData which keeps a cache/copy of the undecoded image data to allow for discarding of the display version of the image. This is a nice example where one could just to skip this copy (and disable this discardig optimization) when this large allocation fails.

Also the allocation of the image frame space itself is of course a candidate for this. 
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.