You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I don't think this will work. Consider https://os.phil-opp.com/kernel-heap/overview.svg: The size of the unused memory block is completely independent from the size of the used memory block afterwards.
Basically, the size field stores the size of the unused block, and the pointer implicitly stores the size of the unusable memory block that follows.
If you keep track of both used and unused chunks, you can use this approach. However, if you only keep track of unused chunks, there is no way to know where the next unused block begins without storing a pointer.
Well you don't really care about used chunks, since they're not available. And whenever somebody claims to try to free up a chunk, the allocator gets both the address, and the layout of said chunk, and blindly obliges, creating a new chunk (or extends a previous or next one, if the freed up memory are neighbours another free chunk). This would mean that an incorrect call (freeing up nonclaimed space, or double frees) would create corrupt the heap and cause chaos, but that's already the case, isn't it?
This would mean that an incorrect call (freeing up nonclaimed space, or double frees) would create corrupt the heap and cause chaos, but that's already the case, isn't it?
Yes, it is. Even a deallocate call with a valid address can cause undefined behavior due to use-after-free.
Well you don't really care about used chunks, since they're not available.
Yes, that's why this crate only keeps unused blocks in the list. I just don't understand how we can remove the pointer in the list nodes.
Activity
phil-opp commentedon Aug 30, 2019
I don't think this will work. Consider https://os.phil-opp.com/kernel-heap/overview.svg: The size of the unused memory block is completely independent from the size of the used memory block afterwards.
Basically, the
size
field stores the size of the unused block, and the pointer implicitly stores the size of the unusable memory block that follows.axos88 commentedon Aug 30, 2019
This is only in case there is padding due to alignment requirements isn't it? I'll have to look it up how I solved this issue.
phil-opp commentedon Aug 30, 2019
If you keep track of both used and unused chunks, you can use this approach. However, if you only keep track of unused chunks, there is no way to know where the next unused block begins without storing a pointer.
axos88 commentedon Aug 30, 2019
Well you don't really care about used chunks, since they're not available. And whenever somebody claims to try to free up a chunk, the allocator gets both the address, and the layout of said chunk, and blindly obliges, creating a new chunk (or extends a previous or next one, if the freed up memory are neighbours another free chunk). This would mean that an incorrect call (freeing up nonclaimed space, or double frees) would create corrupt the heap and cause chaos, but that's already the case, isn't it?
phil-opp commentedon Aug 31, 2019
Yes, it is. Even a deallocate call with a valid address can cause undefined behavior due to use-after-free.
Yes, that's why this crate only keeps unused blocks in the list. I just don't understand how we can remove the pointer in the list nodes.