New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS_ENABLE_HW_BOUND_CHECK can cause resource leak #3320
Comments
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
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:
|
right now i'm inclined towards the first approach because those checks are necessary for OS_ENABLE_HW_BOUND_CHECK=0 anyway. |
OK, and it would be good if we also fix the argv buffer allocation issue in wasm_runtime_invoke_native. |
This is a test code to examine native stack overflow detection logic. The current output on my environment (macOS amd64): ```shell ====== Interpreter stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 14704 | failed | leaked | Exception: native stack overflow 14704 - 17904 | failed | ok | Exception: native stack overflow 17904 - 24576 | ok | ok | ====== AOT stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 18176 | failed | leaked | Exception: native stack overflow 18176 - 24576 | ok | ok | ====== AOT WAMR_DISABLE_HW_BOUND_CHECK=1 stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 1968 | failed | ok | Exception: native stack overflow 1968 - 24576 | ok | ok | ``` This is a preparation to work on relevant issues, including: bytecodealliance#3325 bytecodealliance#3320 bytecodealliance#3314 bytecodealliance#3297
This is a test code to examine native stack overflow detection logic. The current output on my environment (macOS amd64): ```shell ====== Interpreter stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 14704 | failed | leaked | Exception: native stack overflow 14704 - 17904 | failed | ok | Exception: native stack overflow 17904 - 24576 | ok | ok | ====== AOT stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 18176 | failed | leaked | Exception: native stack overflow 18176 - 24576 | ok | ok | ====== AOT WAMR_DISABLE_HW_BOUND_CHECK=1 stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 1968 | failed | ok | Exception: native stack overflow 1968 - 24576 | ok | ok | ``` This is a preparation to work on relevant issues, including: #3325 #3320 #3314 #3297
This is a test code to examine native stack overflow detection logic. The current output on my environment (macOS amd64): ```shell ====== Interpreter stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 14704 | failed | leaked | Exception: native stack overflow 14704 - 17904 | failed | ok | Exception: native stack overflow 17904 - 24576 | ok | ok | ====== AOT stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 18176 | failed | leaked | Exception: native stack overflow 18176 - 24576 | ok | ok | ====== AOT WAMR_DISABLE_HW_BOUND_CHECK=1 stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 1968 | failed | ok | Exception: native stack overflow 1968 - 24576 | ok | ok | ``` This is a preparation to work on relevant issues, including: bytecodealliance#3325 bytecodealliance#3320 bytecodealliance#3314 bytecodealliance#3297
This is a test code to examine native stack overflow detection logic. The current output on my environment (macOS amd64): ```shell ====== Interpreter stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 14704 | failed | leaked | Exception: native stack overflow 14704 - 17904 | failed | ok | Exception: native stack overflow 17904 - 24576 | ok | ok | ====== AOT stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 18176 | failed | leaked | Exception: native stack overflow 18176 - 24576 | ok | ok | ====== AOT WAMR_DISABLE_HW_BOUND_CHECK=1 stack size | fail? | leak? | exception --------------------------------------------------------------------------- 0 - 1968 | failed | ok | Exception: native stack overflow 1968 - 24576 | ok | ok | ``` This is a preparation to work on relevant issues, including: bytecodealliance#3325 bytecodealliance#3320 bytecodealliance#3314 bytecodealliance#3297 Signed-off-by: victoryang00 <victoryang00@ucsc.edu>
another reason why (b) isn't enough is host-provided apis like libc functions. |
on SEGV on the guard pages, the signal handler performs longjmp to recover the control flow.
for aot frames it's fine.
however, when it's caused by native code like host functions, it can end up with resource leaks.
possible solutions:
a. consider native functions hitting guard pages a bug. insert "manual" overflow detection logic to appropriate places instead.
b. insert "resource cleanup callbacks" into the jmpbuf_node stack. execute them after a jump.
The text was updated successfully, but these errors were encountered: