-
Notifications
You must be signed in to change notification settings - Fork 54
Memory leak #66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
We have found a same/similar problem which also results in breaking of heap. Despite still having half of the heap free, there are no big-enough free holes
Full log:
|
There are three different concerns I can think of, only one of which relates to the actual allocator. (Disclaimer: I have never worked on an embedded system; this is my understanding of the various stuff I have read about.)
|
Some of the libraries we use require Rust's liballoc and heap, notably
I am thinking of using another allocator (probably |
It would probably be a good idea, for reliability. |
This bug is not a matter of fragmentation, it is a logic bug in the heap implementation which causes memory to be lost. The back padding of a chunk should be stored as part of some chunk header and taken into account when the chunk is deallocated. |
Thanks a lot for reporting this issue and especially for the example to reproduce it! I agree that this is something we should fix.
I think the easiest solution would be to consider regions that would result in such a small back padding as unsuitable. This way, we should never get any padding that is too small to be stored. It might lead to an earlier heap exhaustion in some edge cases, but that's better than fragmenting the heap further and further by leaking lots of padding bytes. |
That sounds like a valid solution. But if you wish to provide more flexibility with the chunks, you can store a single |
I created an alternative memory allocator which solves this problem and provides many more benefits, such as improved performance and memory utilization. |
I just implemented a fix for this in #71 and created a new |
Nice crate! It's great to have more alternatives in this space and the benchmarks look impressive. Do you have docs about your design somewhere? If you like, feel free submit a PR with your crate to our Rust OSDev newsletter in rust-osdev/homepage#119, I'm sure many people will find it interesting. |
Pull in the fix for rust-osdev/linked-list-allocator#66. Change-Id: I0c92b186244639d8e6f37fc14e29a09907f14565 GitOrigin-RevId: 69bbd3c9ea5e2223247e4fb5798e5228a4504b30
Pull in the fix for rust-osdev/linked-list-allocator#66. Change-Id: I0c92b186244639d8e6f37fc14e29a09907f14565
Problem
The heap implementation has a memory leak, so that even using only code that is considered safe, the heap memory can be exhausted so that next allocation requests will fail.
Cause
This happens because, when the back padding of a chunk is not enough to store a hole, it is considered to be part of the allocated chunk, but when that chunk is deallocated, this back padding is not taken into account, and the size of the hole is just set to the size of the aligned layout of the allocation.
Example
The following example provides a function which breaks the heap and wastes all of it's memory. Heap allocations that are performed after a call to
break_heap
and are of a size that is larger than 16 bytes will fail with an out of memory condition, even though this function properly deallocates every single allocation that it performs before returning.Note that although this example contains
unsafe
blocks, it is considered safe, and if another allocator would have been used here, this function would not break the heap, since all allocations are properly deallocated, which is guaranteed by using theAllocation
struct, and by wrapping allocations in aBox
in theBarrier
struct.If this function is executed for example on the chunk allocator from the
simple-chunk-allocator
crate, the function loops infinitely because it keeps trying to waste the largest chunk but it doesn't get wasted since that heap implementation doesn't have this memory leak bug.This function can break the heap even if some parts of it are used, and it will waste all of the currently unused chunks that are larger than 16 bytes.
The text was updated successfully, but these errors were encountered: