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
When the chain is processing several DR tallies while new ones are being posted/committed the processes sometimes crashes during tally VM execution. When systemd restarts the SEDAD process it just resumes with the block that failed and completes it without issues, including the DR during which the crash happened. This makes it look like the block took a long time to produce, but that doesn't seem to be the case.
We looked into it briefly but the only notable thing is that when executing several tallies per block for a few blocks suddenly the CPU spikes and the process crashes with the last log being the ‘executing tally VM’ one, basically the same error we see on the ARM machine.
Steps to Reproduce
We were able to most reliable reproduce it by submitting 10-20 data requests without an executor running. Then we'd start the executor with a fast ticker time so it executes and commits/reveals multiple DRs per block.
All submitted DRs were identical apart from the memo field.
🐛 Bug Report
When the chain is processing several DR tallies while new ones are being posted/committed the processes sometimes crashes during tally VM execution. When
systemd
restarts the SEDAD process it just resumes with the block that failed and completes it without issues, including the DR during which the crash happened. This makes it look like the block took a long time to produce, but that doesn't seem to be the case.We looked into it briefly but the only notable thing is that when executing several tallies per block for a few blocks suddenly the CPU spikes and the process crashes with the last log being the ‘executing tally VM’ one, basically the same error we see on the ARM machine.
Steps to Reproduce
We were able to most reliable reproduce it by submitting 10-20 data requests without an executor running. Then we'd start the executor with a fast ticker time so it executes and commits/reveals multiple DRs per block.
All submitted DRs were identical apart from the memo field.
Stack trace & error message
Logs taken from journalctl:
When the node is restarted it processes that block without issues:
Expected Behavior
The node should not suddenly crash when executing tally WASM binaries.
Your Environment
./sedad version
: 0.2.0-dev.2, taken from Github release (statically compiled)Architecture: x86_64
The text was updated successfully, but these errors were encountered: