OS_ENABLE_HW_BOUND_CHECK can cause resource leak about wasm-micro-runtime

[wenyongh]

Maybe the second way is better, since the issue not only occurs in the host function, but also may occur in runtime, .e.g. allocating argv buffer in wasm_runtime_invoke_native:

wasm-micro-runtime/core/iwasm/common/wasm_runtime_common.c

Lines 4916 to 4921 in 30426be

	if (argc1 > sizeof(argv_buf) / sizeof(uint64)) {
	size = sizeof(uint64) * (uint64)argc1;
	if (!(argv1 = runtime_malloc((uint32)size, exec_env->module_inst, NULL,
	0))) {
	return false;
	}

It didn't happen since it is allocated only when the default buffer in local variable isn't enough and by default the latter is large enough (allows to call a wasm/host function with 31 arguments).

If we only care about the memory allocated by wasm_runtime_malloc, maybe we can auto handle it wasm_runtime_malloc, wasm_runtime_free and after longjmp:

• in wasm_runtime_malloc, check whether runtime is calling the wasm/host function (e.g. whether the global exec_env_tls is not NULL and its jmp stack isn't NULL), and if yes, allocate an extra node to take the memory allocated, and add the node into current WASMJmpBuf's node list
• in wasm_runtime_free, remove node which has the memory pointer to free in current WASMJmpBuf's node list
• after longjmp, free current WASMJmpBuf's node list and the memory pointers inside them

[yamt]

Maybe the second way is better, since the issue not only occurs in the host function, but also may occur in runtime, .e.g. allocating argv buffer in wasm_runtime_invoke_native:

right now i'm inclined towards the first approach because those checks are necessary for OS_ENABLE_HW_BOUND_CHECK=0 anyway.

[wenyongh]

OK, and it would be good if we also fix the argv buffer allocation issue in wasm_runtime_invoke_native.

[yamt]

another reason why (b) isn't enough is host-provided apis like libc functions.
when we hit the guard pages in the middle of libc, it's impossible to recover gracefully.