You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EKF is a program that requires persistent state for multiple iterations. Phani made this work in the serverless model by accepting and returning a binary blob. The assumption is that the response body of iteration one would be the request body of iteration two. It appears that you can generate the initial state by defining DUMP_STATE. This is presumably run as a native binary to generate ekf_raw.dat and then DUMP_STATE is undefined to build for serverless execution.
Currently, calls to read and write in main() assume that they will be successful in one call, as enforced by assert(). Normally, these sorts of calls are part of a loop that exits when the sum of the total amount read or written equals the expected size.
At some point in the past, I've witnessed that these asserts were not succeeding, which suggests that the program is not loading all of the binary payload and silently failing or returning a partial result. The call to assert() calls musl (our libc implementation that is written to our *.so modules), and the musl function for assert calls various wasm_* syscalls that we haven't implemented, causing the runtime to crash. I believe that this occurs when the module is built with debugging symbols, but I'm not totally sure.
My suggestion is to deep dive on the behavior of the function running native first.
Once that is working, it is worth trying to figure out how to get the assert to crash the runtime. If you run the runtime in GDB, this should set you up to debug the issue.
The solution might be as simple as just having to wrap the calls to read / write in a loop. However, it is worth making sure that there isn't a socket-related bug in the runtime first.
The text was updated successfully, but these errors were encountered:
EKF is a program that requires persistent state for multiple iterations. Phani made this work in the serverless model by accepting and returning a binary blob. The assumption is that the response body of iteration one would be the request body of iteration two. It appears that you can generate the initial state by defining
DUMP_STATE
. This is presumably run as a native binary to generateekf_raw.dat
and thenDUMP_STATE
is undefined to build for serverless execution.Currently, calls to read and write in
main()
assume that they will be successful in one call, as enforced byassert()
. Normally, these sorts of calls are part of a loop that exits when the sum of the total amount read or written equals the expected size.At some point in the past, I've witnessed that these asserts were not succeeding, which suggests that the program is not loading all of the binary payload and silently failing or returning a partial result. The call to
assert()
callsmusl
(our libc implementation that is written to our *.so modules), and the musl function forassert
calls variouswasm_*
syscalls that we haven't implemented, causing the runtime to crash. I believe that this occurs when the module is built with debugging symbols, but I'm not totally sure.My suggestion is to deep dive on the behavior of the function running native first.
Once that is working, it is worth trying to figure out how to get the assert to crash the runtime. If you run the runtime in GDB, this should set you up to debug the issue.
The solution might be as simple as just having to wrap the calls to read / write in a loop. However, it is worth making sure that there isn't a socket-related bug in the runtime first.
The text was updated successfully, but these errors were encountered: