How do you make sure that when an app calls free it isn't freeing a non allocated bit of memory?
Pete
Stacked Memory Management
-
Tim
Re:Stacked Memory Management
By keeping track of the memory which is allocated and putting a check in the function used to free memory.
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Stacked Memory Management
But checking the free'd page is actually used means scanning the stack and making sure it's not in the stack already ... Or am i completely wrong here ? ...Tim Robinson wrote: By keeping track of the memory which is allocated and putting a check in the function used to free memory.
Re:Stacked Memory Management
then how would you know how big it was?Pype.Clicker wrote: But checking the free'd page is actually used means scanning the stack and making sure it's not in the stack already ... Or am i completely wrong here ? ...
It's on a separate list, that is checked. then, the block is moved to the freelist and is declared free (and merged with other blocks).
-
Tim
Re:Stacked Memory Management
Hmm, I can think of three different allocators that Pete might be talking about:
1. Physical (kernel)
2. Virtual (kernel)
3. malloc/free (app)
Applications shouldn't need access to (1) so they can't break it. The kernel code should be perfect so debug-mode-only checks should be enough here.
With (2), the virtual memory manager should already have a list of blocks of virtual memory which have been allocated, so that it can handle page faults. So the virtual_free() function can check this list.
With (3), it's up to the application to handle this. The worst that could happen would be heap corruption, which would eventually crash the application. It's useful to be able to check calls to free() for debugging purposes, but system stability should not be affected by bad calls to free().
1. Physical (kernel)
2. Virtual (kernel)
3. malloc/free (app)
Applications shouldn't need access to (1) so they can't break it. The kernel code should be perfect so debug-mode-only checks should be enough here.
With (2), the virtual memory manager should already have a list of blocks of virtual memory which have been allocated, so that it can handle page faults. So the virtual_free() function can check this list.
With (3), it's up to the application to handle this. The worst that could happen would be heap corruption, which would eventually crash the application. It's useful to be able to check calls to free() for debugging purposes, but system stability should not be affected by bad calls to free().