I get issue in mimalloc with below stack. Can we say that memory was exhausted

An access out of bounds sounds like a bug in mimalloc or our port of it. Can you provide a testcase?

The bug could be related to memory being exhausted, if there is a code path that doesn't handle OOM properly.

How can new give memory access out of bounds? Shouldn't it be coming when trying to access something out of buffer allocated?

A bug inside new itself could cause strange things like this. Without a testcase it's hard to say. But in general, you are right that the more likely reason for an access out of bounds is a read past a buffer size.

I'm trying to figure out the best test case and reduce the application into this error.Because unfortunately the asan+mimalloc in my application is giving heap_buffer_overflow in starting on main itself, due to which unable to use asan to figure out memory access out of bounds issue. Meanwhile is it safe to assume that if list of heaps per thread is exhausted, then block->next will ideally return garbage value, resulting in memory access out of bounds?

@kleisauke do you know when your change may land? Looks like it improves memory usage efficiency considerably.

AFAIK, there is not yet a non-alpha release of the dev3 branch, so let's wait for that first.

I was thinking the changes of #23037 were included. But that does not seem to be the case.

It looks like the changes in #23037 are no-op on mimalloc v3.0-alpha anyway, it needs probably(?) to be adjusted to:

--DMI_SEGMENT_SLICE_SHIFT=(12 + MI_INTPTR_SHIFT)
+-DMI_ARENA_SLICE_SHIFT=(12 + MI_SIZE_SHIFT)

(in case it's still relevant, it feels a bit dangerous to change these definitions)

the default arena reserve on 32-bit is 128MiB and it doubles every 4 times (so the fifth arena will be 256MiB). Nowadays, if we fail at arena allocation, we will try with a small size again to prevent the issue raised above when reaching the 4GiB limit.

Great! I think that would fix #23090. FWIW, on wasm32, the default arena reserve starts at 32MiB:
https://github.com/microsoft/mimalloc/blob/c820259f3b886062b29ff607dac00226eb3c93e3/src/arena.c#L283-L285

• I hope to release an bug fixed v3 soon
• It is indeed not necessary to change the MI_ARENA_SLICE_SHIFT anymore I think (otherwise, let me know of any issues)
• ha @kleisauke , you know mimalloc better than me :-) I see that indeed for a "non virtual reserve" system like wasm, the arena size indeed starts at 32 MiB so that is quite conservative. When reaching the memory limit (4GiB) it falls back to minimal arena sizes (which I think is 8MiB at a time).

Any updates on this? I can see that mimalloc v3.0.3 was released some time ago: https://github.com/microsoft/mimalloc/releases/tag/v3.0.3

@jarnoharno mimalloc v3.0.3 is still a beta release (according to the readme.md), I prefer to wait for a stable release before updating. That said, there's a work-in-progress changeset available here:
HEAD...kleisauke:mimalloc-update-3.0.3

Which seems to work well in practice (tested using kleisauke/wasm-vips@6b582a0).