emmalloc_trim broken since #13442?

[sbc100]

It looks like emmalloc_trim has been broken since #13442. Prior to that change the result of sbrk would reduce in test_emmalloc_trim test but after that change the expecations were updated to reflect an sbrk that never goes down, and indeed if I run that test with -sASSERTIONS=2 I see that this assertion fires every time:

emscripten/system/lib/emmalloc.c

Line 1277 in 6b81620

assert((intptr_t)oldSbrk != -1); // Shrinking with sbrk() should never fail.

Basically it looks like sbrk no longer accepts negative values.. which I think was an indended part of #13442. So maybe emmalloc_trim cannot be implement using sbrk along? We would need some kind of new internal function such as sbrk_shrink to make it work?

[kripken]

Where do you see that sbrk does not accept negative values? Looking through the code I failed to find anything obvious.

[sbc100]

You can see from the expected output of the test.. sbrk could be reduced before but not after. I think its because the increment that sbrk was interpreted as signed before and unsigned after. Whatever the reason the side effect can clearly be seen in the test expectations, or by enabling -sASSERTIONS=2.

[sbc100]

-    intptr_t old_brk = *sbrk_ptr;
+    uintptr_t old_brk = *sbrk_ptr;
 #endif
-    intptr_t new_brk = old_brk + increment;
+    uintptr_t new_brk = old_brk + increment;

[sbc100]

Actually real problem is probably uintptr_t increment = (uintptr_t)increment_; which was added

[kripken]

(I commented in #13442 before seeing this, but as I said there, does wrapping mean that the cast to unsigned is ok?)

[sbc100]

@juj I'd be happy to see emmalloc_trim re-enabled if you can figure out a way to make it work again.