Skip to content
This repository has been archived by the owner on Oct 28, 2021. It is now read-only.

Fix STATICCALL #4200

Merged
merged 7 commits into from
Jun 27, 2017
Merged

Fix STATICCALL #4200

merged 7 commits into from
Jun 27, 2017

Conversation

chfast
Copy link
Member

@chfast chfast commented Jun 23, 2017

Fixes #4199.

Copy link
Member

@pirapira pirapira left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me.

@chfast
Copy link
Member Author

chfast commented Jun 23, 2017

This also requires JSON tests update. I can't do it because I have issues with compiling LLL code.

@chfast chfast added this to the Metropolis milestone Jun 23, 2017
m_runGas += toInt63(m_schedule->callValueTransferGas);

size_t sizesOffset = (m_OP == Instruction::DELEGATECALL || m_OP == Instruction::STATICCALL) ? 2 : 3;
size_t const sizesOffset = haveValueArg ? 3 : 2;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you forget a ! here or was there a bug before?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also swapped the 2 and 3.

}
else
{
callParams->apparentValue = callParams->valueTransfer = m_SP[2];
inOutOffset = 1;
callParams->apparentValue = m_ext->value;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to forward the value in case of staticcall? I would say thiscase should only apply to delegatecall.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are probably right. In case of STATICALL the value should not be forwarded and be 0 all the time.
This might be another bug. @winsvega Can you look for some test cases for this?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of them are quite complex. We need a simple test with a transaction having no-zero value, then staticcall and check of the callvalue inside this staticcall.

Similar one with a CALL instead of transaction.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this test does exactly just that
just add more values to the value list

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure what you mean by "this test". You referenced 2 tests before. If you mean https://github.com/ethereum/tests/blob/develop/src/GeneralStateTestsFiller/stStaticCall/static_callToStaticOpCodeCheckFiller.json#L43, this tests does other weird things like: checking for ORIGIN, multiple levels of different calls, etc. I'm not sure any of them check if the value from transaction is forwarded in STATICCALL.

Also, I don't know what you mean by "just add more values to the value list".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will add tests.

  1. call transaction into A with non-zero value; A performs STATICCALL to B; B stores the call value
  2. call transaction into Q; Q calls into A with non-zero value; A performs STATICCALL to B; B stores the call value

In both cases, the storage slot of B would initially contain some non-zero value, so that we can be sure that the value is overwritten by zero.

@codecov-io
Copy link

codecov-io commented Jun 23, 2017

Codecov Report

Merging #4200 into develop will increase coverage by 0.19%.
The diff coverage is 100%.

@@             Coverage Diff             @@
##           develop    #4200      +/-   ##
===========================================
+ Coverage    67.35%   67.54%   +0.19%     
===========================================
  Files          302      302              
  Lines        23257    23360     +103     
===========================================
+ Hits         15664    15779     +115     
+ Misses        7593     7581      -12
Impacted Files Coverage Δ
libevm/VMCalls.cpp 97.85% <100%> (+0.03%) ⬆️
libethash/internal.c 71.51% <0%> (-1.27%) ⬇️
test/unittests/libdevcrypto/LibSnark.cpp 100% <0%> (ø) ⬆️
test/unittests/libethereum/BlockChainInsert.cpp 98.16% <0%> (+0.91%) ⬆️
libethashseal/EthashCPUMiner.cpp 91.17% <0%> (+2.94%) ⬆️
test/tools/fuzzTesting/fuzzHelper.cpp 58.2% <0%> (+4.68%) ⬆️

@chfast chfast changed the title Fix STATICCALL giving stipend Fix STATICCALL Jun 26, 2017
@pirapira
Copy link
Member

I added the two tests.

@pirapira
Copy link
Member

pirapira commented Jun 26, 2017

Let me have a look at these

  • static_callToDelCallOpCodeCheck Expected another postState hash
    • test case was wrong because staticcall->delegatecall performs sstore still staticcall is expected to return successfully
  • static_callToStaticOpCodeCheck Expected another postState hash
    • similar to above.

@chfast
Copy link
Member Author

chfast commented Jun 27, 2017

Ready to go?

@pirapira
Copy link
Member

@winsvega sounds not happy about the tests I changed.

@pirapira
Copy link
Member

I changed the tests and rendered them useless. I will apply correct fixes.

@winsvega winsvega merged commit 5ad949e into develop Jun 27, 2017
@pirapira pirapira deleted the fix-staticcall branch June 27, 2017 13:18
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants