diff options
author | Trumeet <yuuta@yuuta.moe> | 2022-07-26 21:27:24 -0700 |
---|---|---|
committer | Trumeet <yuuta@yuuta.moe> | 2022-07-26 21:27:24 -0700 |
commit | c6948fd983fa1855b2dadba50aa50f576f54bdda (patch) | |
tree | c673a57580e8a87f4ce5dc6acd9763393e667ee0 /mod/src/main/java/moe | |
parent | f635018a3309b1cdddd6546b50f0a18214899218 (diff) | |
download | acron-c6948fd983fa1855b2dadba50aa50f576f54bdda.tar acron-c6948fd983fa1855b2dadba50aa50f576f54bdda.tar.gz acron-c6948fd983fa1855b2dadba50aa50f576f54bdda.tar.bz2 acron-c6948fd983fa1855b2dadba50aa50f576f54bdda.zip |
fix(acronc): input <cmd><EOF> will cause illegal memory access
Cause:
1. stdin got cmd -> request
2. stdin got EOF -> ac_disconnect -> ac_conn becomes NULL
3. socket got response -> ac_receive(ac_conn) -> crash
Conclusion: ordering issue between ac_disconnect and socket read.
Solution:
Best way: pause the input until command returns
Cons:
1. Lost the advantage of background execution of commands (has to wait until done)
2. It is unreliable to determine if a command is done: although the current server implementation will not send anything else after an error or cmd_result, Minecraft server itself or future server implementations may. The spec does not say anything on termination.
Acronc currently assumes that after receiving an error or cmd_result with the same request ID, it is done. Then, it resumes the stdin, reads the EOF, and then disconnect.
Worse way: Directly call uv_read_stop before ac_disconnect
Cons: It is going to lose anything, including command results. This is particularly undesirable for ad-hoc calls (i.e. echo list | acronc).
Therefore, the current approach is to block and read as much as we can (until error or cmd_result), then stop reading the socket before disconnecting as a double safe.
Signed-off-by: Trumeet <yuuta@yuuta.moe>
Diffstat (limited to 'mod/src/main/java/moe')
0 files changed, 0 insertions, 0 deletions