I think I have run into a similar problem usingwasm-unknown andwasip1 having to do with lifetimes and memory. This PR makes me think about some ways to possibly look into it further for those targets.

In any case, this seems fine to me if it does fix the wasip2 issue as described.

@dgryski any comment here?

I ran into a related issue with the wasmimport functions today and have a reproducer.

Unfortunately the fix in this PR will not fix that issue, and instead result in a memory leak.

Do not merge this.

Because these allocated pointers are not stored anywhere in the TinyGo stack or heap, they are subject to immediate collection. This can happen if the host wants to copy a large string into the guest memory, and performs a sequence ofcabi_realloc calls to grow the target memory.

We have the same issue for libc malloc/realloc. A simple solution would be to calllibc_realloc instead (defined in arch_tinygwasm_malloc.go). That would also avoid duplicating this logic.

(I also see thatlibc_realloc has a bug in the precise GC: it allocates usingmake([]byte, ...) which tells the GC the buffer doesn't contain pointers but that is of course an incorrect assumption with C calloc).

EDIT: See:#4898