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)
Core
General
Tracking
()
NEW
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".
Reporter | ||
Updated•16 years ago
|
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
Comment 1•16 years ago
|
||
I agree, dynamic analysis is the way to go on this one.
Comment 2•16 years ago
|
||
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.
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•