wee_alloc leaks memory about wee_alloc HOT 5 OPEN

I switched to dlmalloc, which worked perfectly fine.

from wee_alloc.

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?

from wee_alloc.

@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.

from wee_alloc.

@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.

from wee_alloc.

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.

from wee_alloc.