Comment # 11
on bug 11373
from Evan Huus
For those interested, here's a quick breakdown of the bug and fix; the steps
required to trigger this were fascinating and quite precise.
1. Allocate two reasonably-sized chunks of memory in a row, where
"reasonably-sized" just means at least a few multiples of your architecture's
alignment requirements. The allocator puts those two chunks next to each other,
with a header before each. Your memory looks like:
| hdr | chunk1 | hdr | chunk2 |
2. Realloc chunk1 such that it shrinks by exactly sizeof(hdr) (+/- alignment).
The allocator puts this additional chunk in with an effective length of 0, on
the off chance chunk2 is ever freed in which case they could be merged into one
(slightly larger) free chunk. Your memory looks like:
| hdr | chunk1 | hdr | hdr | chunk2 |
3. So we have a new chunk header, but since this new chunk has an effective
length of 0 it is *not* added to the list of free chunks the allocator can pull
from.
4. Realloc chunk1 again *back* to its original size. The allocator sees that it
has free space to its right which is just big enough (it can reclaim the
0-length chunk header) so it does that. During that process it goes "oh, better
remove this chunk from the free list since it's now used". But that chunk
(having no data-length) was never in the free list to begin with! This corrupts
memory in the header for chunk2, which shows up later in a different operation.
The one-line fix is quite trivial: when claiming a free chunk to the right
during a realloc, *don't* try and remove that chunk from the free list if it is
too small to have been added in the first place.
You are receiving this mail because:
- You are watching all bug changes.