-
Notifications
You must be signed in to change notification settings - Fork 320
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
bug: Finalization Issue with Mismatched return_data_length and Empty return_data #718
Comments
Problem Statement: Proposed Solution:
Finalization Logic: In the finalization phase, compare return_data_len with requested_return_data_len implicitly via using https://github.com/kkrt-labs/kakarot/blob/main/src/utils/utils.cairo#L253
And thus we achieve world peace. |
reproducing here our convo in telegram greg is proposing a little refactor where the execution context has a return_data_info field that points to a ReturnDataInfo struct with the following dimensions
i am fine with doing this, but would like collective buyin before doing so |
Elias:
|
I’m fin with the struct, and it’ll save steps overall |
Time spent on this PR: 0.4 ## Pull request type Please check the type of change your PR introduces: - [x] Bugfix - [ ] Feature - [ ] Code style update (formatting, renaming) - [ ] Refactoring (no functional changes, no api changes) - [ ] Build related changes - [ ] Documentation content changes - [ ] Other (please describe): ## What is the current behavior? Fails to finalize a calling context when `ret_size` is greater than `return_data_len`. Resolves #718 ## What is the new behavior? Use `Helpers.slice` to make sure that the stored `return_data` is big enough. Note: we previously stored the `ret_offset` in the `sub_context.return_data[0]`. I have put both `ret_offset` and `ret_size` in the calling_context return data, as: - this is more logical: they belong to the calling context and not the sub context - it is safe because return_data is only written in RETURN, which stops the context, so no data could have been put before a call - actually I've seen that geth and the execution spec reads RETURNDATASIZE and RETURNDATACOPY directly from the execution context and don't keep a ref to the previous sub_context. Might be an idea for a future refacto
Bug Report
Kakarot version:
Current behavior:
The sha ef tests presented a flow where a called context is finalized without ever executing the
exec_return
opcodeExpected behavior:
Steps to reproduce/related code:
kakarot/tests/integration/solidity_contracts/EFTests/test_sha3.py
Lines 13 to 41 in f00acce
Other information:
The text was updated successfully, but these errors were encountered: