search

rustwasm / wee_alloc

The Wasm-Enabled, Elfin Allocator
Mozilla Public License 2.0
668 stars 49 forks source link

wee_alloc leaks memory #85

Open CryZe opened 5 years ago

CryZe commented 5 years ago

Describe the Bug

wee_alloc is supposedly useful for embedded devices, but I tried it over the weekend and of the total amount of memory of 256 KiB, wee_alloc is only able to allocate 2.2 KiB in its default configuration. Something seems to be off here.

Steps to Reproduce

  1. Use the static array backend.
  2. Configure 256 KiB of memory.
  3. Do a few allocations in the range 1 - 700 bytes like in the image provided.
  4. wee_alloc should run out of memory very early.

Expected Behavior

It should be able to use at least 200 KiB or so.

Actual Behavior

It can only allocate 2.2 KiB.

https://i.imgur.com/XILjeLr.png

nand-nor commented 5 years ago

I am also experiencing this issue, which is that an OOM error arises in my system when trying to push elements to an alloc::vec::Vec of u32's, right around the 65th element (which is just over 256k bytes of memory). I only have the static_array_backend feature enabled, and the error persists even after adjusting the WEE_ALLOC_STATIC_ARRAY_BACKEND_BYTES env var to twice the default during compilation. For more context wee_alloc is being used as a global allocator in a no_std bare metal OS that is being built. So it is possible there are some confounding variables at play here, but I am fairly certain this is due to wee_alloc.

Are there any fixes or workarounds people have found?

CryZe commented 5 years ago

I switched to dlmalloc, which worked perfectly fine.

fitzgen commented 5 years ago

@CryZe, @nand-nor: are y'all using the size classes feature? I'd recommend against using it in super constrained memory situations (eg only 256k of heap space) since it will prefill each size class's free list with 8k from the main free list. It is essentially trading more fragmentation for faster allocation of small objects.

I think using the size classes in a constrained memory environment, combined with the alignment bug that #87 is fixing, could explain this behavior.

If you were using the size classes feature, I'd be interested in if you could re-test with size classes disabled and the fix in #87 and report if you're seeing the same behavior or not.

nand-nor commented 5 years ago

@fitzgen I have not been using the size classes feature (my target platform has plenty of memory) so the tests I ran separately from tests.sh after enforcing scratch heap alignment did not have this feature enabled.

CryZe commented 5 years ago

I also tried both variants (back then) and both were failing to allocate way too early, though with size classes (as seen in the OP), it was even earlier than without.