I might be missing something, but with invRound = 28 and clz(size) = 27, isn't (1 << (invRound - clz(size))) - 1 = 1?

  (1 << (invRound - clz(size))) - 1
= (1 << (28 - 27)) - 1
= (1 << 1) - 1
= 2 - 1 = 1

I might be missing something, but with invRound = 28 and clz(size) = 27, isn't (1 << (invRound - clz(size))) - 1 = 1?

1 << -1
1 << (-1 mod 32)
1 << 31

Good catch! 1 << -1 is really equal to 2147483648 (if it's unsigned)

Still not seeing how this becomes -1 given 28 - 27. What am I missing?

Hmm, it should be possible when invRound < clz(size) for example when invRound = 27, clz(size) = 28.
@HerrCai0907 Perhaps you misspelled the initial message?

• size is less than 536870910 (BLOCK_MAXSIZE >> 1) so clz(size) equal from 3 (when size = 536870910) to 31 (when size = 0). Or size has lower bound 15? In this case clz(15) = 28
• invRound is always 27

Hmm, it should be possible when invRound < clz(size) for example when invRound = 27, clz(size) = 28. @HerrCai0907 Perhaps you misspelled the initial message?

Yes, you are right. I have edited the message.

However, I can't reproduce this problem in playground

What am I doing wrong?

Thanks for the clarification. So, from locking at the code, growMemory is only called in one place:

There, the size passed to growMemory has always been prepared to be a valid block size that is not smaller than BLOCK_MINSIZE. Doesn't that prevent the issue from happening?

I think for reproduction of this we should have initialMemory = 0 which is by default always 1. That's why we've never encountered this problem

Doesn't seem to me that the issue depends on the current size of memory. At least the computation in question doesn't use it (neither invRound nor size depend on it), instead is only used after to compute the delta in pages.

It is easy to re-produce it.

These code will trace memory.size is 32770 at last instead of 2.

for (let i=0;i<6000;i++) {
  heap.alloc(1);
  trace("", 1, memory.size());
}

I found some unusual memory consumption behavior from the monitor and find the root cause.
It only can be able to discover when running wasm on some memory-use-sensitive device.

There, the size passed to growMemory has always been prepared to be a valid block size that is not smaller than BLOCK_MINSIZE. Doesn't that prevent the issue from happening?

BLOCK_MINSIZE is 12 instead of 16 @dcodeIO

Is the underlying problem perhaps that searchBlock does not round when size < SB_SIZE where SB_SIZE = 16, but growMemory does?

If so, perhaps instead of reordering the logic, mirroring exactly what searchBlock does would be preferable, that is by not performing the rounding if size < 16?

ping @dcodeIO @MaxGraey