Closed kateinoigakukun closed 3 months ago
@guybedford Yes, I tried the zero-copy approach first, but it revealed the realloc provided by wasi-preview1-component-adapter does not support shrinking and multiple calls at this moment. So I turned it into copying approach in https://github.com/bytecodealliance/jco/pull/444/commits/0968cbafc4e218a4face3da95b2dbc14ac859ce0
Do you think it's worth adding shrinking and multi-call support in realloc of wasi-preview1-component-adapter
for jco?
Okay thanks @kateinoigakukun for clarifying, at least until the adapter can support chained realloc calls then lets land this for now, and then come back to it if and when the adapter gets updated. Updating the adapter certainly to support it seems worthwhile though.
Recent dlmalloc-rs started validating that deallocation size is same as the size that was allocated. https://github.com/alexcrichton/dlmalloc-rs/blob/0.2.6/src/dlmalloc.rs#L1187
Since canonical abi string does not have "capacity" concept separate from "length", we don't have a way to tell how much memory was allocated to the buffer owner. So, canonical abi always assumes that "length" is the same as "capacity" and deallocates the buffer with the "length" size.
This means that if we overallocate the buffer and return the buffer with a length less than the allocated size, dlmalloc-rs validation will fail.
This commit fixes the issue by lopping off the extra allocated space by realloc with smaller size.