Skip to content
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

Debug Socket Read/Write issues with EKF #251

Open
bushidocodes opened this issue Jun 4, 2021 · 0 comments
Open

Debug Socket Read/Write issues with EKF #251

bushidocodes opened this issue Jun 4, 2021 · 0 comments
Assignees

Comments

@bushidocodes
Copy link
Contributor

bushidocodes commented Jun 4, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants