3 ms·

How do you detect a "pointer that has already been freed"?

by coldpie 10y ago

aseipp 10y ago
You overwrite the page you just freed (e.g. point it entirely to a fixed page of junk bytes) or mark it as PROT_NONE immediately upon free().
mikeash 10y ago
You could keep a separate list of all live allocations. If free() is called with a pointer that's not on the list, it's an error. This won't immediately detect the case where you free, something else mallocs in that exact spot, and then you free again. It will eventually catch it when the something else tries to call free. It will catch cases where the second free call happens before the memory is reused, or when the memory is reused but the new chunk starts earlier. I assume this isn't done because maintaining and checking the list would cost too much.
- xenadu02 10y ago
  If the bookkeeping weren't so massive you could cycle through the entire 64-bit address space before re-issuing the same memory address. That would be similar to a bump allocator; once all the allocations on a page were freed you could unmap it so except for pathological cases you couldn't explode the number of page table entries too horribly. At 1 TB/sec of allocations it would take 500 years to reach the end of the 64-bit address space in the kernel. (It's actually 544 years ignoring leap years and leap seconds, but subtract 44 years for reserved address ranges). The benefit would be making it impossible to use-after-free because the same address would never be re-used.
  - majewsky 10y ago
    The problem isn't the bookkeeping. It's the massive implicit memory leak that you get when there's only one 4-byte allocation left on your 4-KB page.
    - mikeash 10y ago
      One might reasonably describe the 4kB granularity of virtual memory as bookkeeping overhead, although it's probably not what people would usually think of if they heard that.
    - xenadu02 10y ago
      That's what I meant by "except for pathological cases". Existing memory allocators have the same problems with fragmentation.
twoodfin 10y ago
The answer to every problem in computer science is another level of indirection. Pointers point to descriptors that point to allocations. Of course, you can't dynamically manage descriptors without reintroducing the same problem, but the answer to every problem in computer science...

How do you detect a "pointer that has already been freed"?

by coldpie 10y ago

How do you detect a "pointer that has already been freed"?

You overwrite the page you just freed (e.g. point it entirely to a fixed page of junk bytes) or mark it as PROT_NONE immediately upon free().

mikeash 10y ago

You could keep a separate list of all live allocations. If free() is called with a pointer that's not on the list, it's an error. This won't immediately detect the case where you free, something else mallocs in that exact spot, and then you free again. It will eventually catch it when the something else tries to call free. It will catch cases where the second free call happens before the memory is reused, or when the memory is reused but the new chunk starts earlier. I assume this isn't done because maintaining and checking the list would cost too much.

xenadu02 10y ago
If the bookkeeping weren't so massive you could cycle through the entire 64-bit address space before re-issuing the same memory address. That would be similar to a bump allocator; once all the allocations on a page were freed you could unmap it so except for pathological cases you couldn't explode the number of page table entries too horribly. At 1 TB/sec of allocations it would take 500 years to reach the end of the 64-bit address space in the kernel. (It's actually 544 years ignoring leap years and leap seconds, but subtract 44 years for reserved address ranges). The benefit would be making it impossible to use-after-free because the same address would never be re-used.
- majewsky 10y ago
  The problem isn't the bookkeeping. It's the massive implicit memory leak that you get when there's only one 4-byte allocation left on your 4-KB page.
  - mikeash 10y ago
    One might reasonably describe the 4kB granularity of virtual memory as bookkeeping overhead, although it's probably not what people would usually think of if they heard that.
  - xenadu02 10y ago
    That's what I meant by "except for pathological cases". Existing memory allocators have the same problems with fragmentation.

twoodfin 10y ago

The answer to every problem in computer science is another level of indirection. Pointers point to descriptors that point to allocations. Of course, you can't dynamically manage descriptors without reintroducing the same problem, but the answer to every problem in computer science...