`INITIAL_HEAP=64KB` and `ALLOW_MEMORY_GROWTH=1` break Envoy build

[phlax]

with these settings we get memory errors, disabling (by patch) fixes

i dont have the error to hand, but can retrigger it if its helpful

[leonm1]

Can you share a repro build command for the envoy failure?

I tried removing the patch building with bazel test --config=clang --override_repository=proxy_wasm_cpp_sdk=$HOME/proxy-wasm-cpp-sdk -- //test/extensions/filters/http/wasm/..., but I did not get a failure.

This option is desirable since the amount of memory that instantiated wasm modules use at startup in each worker thread is defined by this environment variable. The default value is 16MiB, so changing this value results in a very large memory reduction or increase. It should not affect runtime usage, just the initial allocation.

[phlax]

errors are here https://github.com/envoyproxy/envoy/actions/runs/21209817614/job/61015230408

[PiotrSikora]

FWIW, I think the issue is with the tests in Envoy and not the new memory settings in C++ SDK (which match Rust SDK).

Note that historically for every change in C++ Host, C++ SDK and Rust SDK, we've opened a corresponding draft PR in Envoy updating not-yet-merged changes to verify that nothing broke, and to avoid accumulating and pushing required changes on others while contributing to Envoy.

Perhaps it's worth revisiting that practice?

[leonm1]

I think we need to add env.emscripten_notify_memory_growth to the allowed callbacks in the proxy_wasm::WasmBase::allocMemory function:

diff --git a/include/proxy-wasm/wasm.h b/include/proxy-wasm/wasm.h
index 9b85710..e619fe5 100644
--- a/include/proxy-wasm/wasm.h
+++ b/include/proxy-wasm/wasm.h
@@ -393,7 +393,9 @@ inline void *WasmBase::allocMemory(uint64_t size, uint64_t *address) {
     return nullptr;
   }
   wasm_vm_->setRestrictedCallback(
-      true, {// logging (Proxy-Wasm)
+      true, {// Increasing memory size
+             "env.emscripten_notify_memory_growth",
+             // logging (Proxy-Wasm)
              "env.proxy_log",
              // logging (stdout/stderr)
              "wasi_unstable.fd_write", "wasi_snapshot_preview1.fd_write",

This patch should make the tests pass (at least, they do in my repro case locally). This is a symptom of a bug where all attempts by the host to allocate memory beyond the existing linear address space will fail on emscripten-compiled plugins. I'm not aware of an analogous hostcall for wasi-sdk compiled plugins.

[PiotrSikora]

@leonm1 Good catch!

This proves my point that you should do Envoy PRs along each change in Proxy-Wasm, since it would have been caught there. This is especially true, because neither C++ Host, C++ SDK or Rust SDK have a good enough test suite on their own, and historically they relied on tests in Envoy to provide full coverage.

[kyessenov]

Weird it wasn't caught in the CI when the update was merged into Envoy (as the person responsible for merging it) :/

[PiotrSikora]

@kyessenov the setting to use smaller initial heap was removed during the import to Envoy in envoyproxy/envoy#42578, and with larger initial heap size, those tests didn't trigger memory growth.

This resurfaced now, since @phlax tried to remove that patch in envoyproxy/envoy#43096.