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

Do not crash on invalid index access #5096

Closed
wants to merge 7 commits into from
Closed

Conversation

axic
Copy link
Member

@axic axic commented Sep 26, 2018

Fixes #5057.
Depends on #5195.

Another instance of this https://github.com/ethereum/solidity/blob/develop/libsolidity/analysis/TypeChecker.cpp#L2253 uses hasErrors().

I think that is unreliable and we may just use fatalError in expectType.

@axic
Copy link
Member Author

axic commented Sep 26, 2018

Need to add tests.

@axic axic changed the title Do not crash on invalid indexed access [WIP] Do not crash on invalid indexed access Sep 26, 2018
bytes[32] memory a;
a[8**90][8**90][1 - 8**90];
}
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This is failing with an assertion, to be fixed by this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done.

@@ -0,0 +1,3 @@
contract C {
function f(bytes32[1263941234127518272][500] memory) public pure {}
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This is failing with an assertion, to be fixed by this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done.

bytes[32] memory a;
a[8**90][8**90][8**90*0.1];
}
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This is failing with an assertion, to be fixed by this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done.

bytes32 b;
b[888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888888];
}
}
Copy link
Member Author

Choose a reason for hiding this comment

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

This is failing with an assertion, to be fixed by this PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Done.

resultType = make_shared<TypeType>(make_shared<ArrayType>(
DataLocation::Memory,
typeType.actualType(),
length->literalValue(nullptr)
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 think we are missing another test case here for too large rational numbers.

Copy link
Collaborator

Choose a reason for hiding this comment

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

This should be already covered by e.g. array_multidim_rational.sol. Is that correct or do you have another test in mind?

@axic
Copy link
Member Author

axic commented Sep 26, 2018

@chriseth please review this, the last failure is due to the need of checking calldatasize in the type checker for a multi dimensional array and rejecting if it is too large.

length->literalValue(nullptr)
));
else
if (!expectType(*index, IntegerType(256)) || type(*index)->category() != Type::Category::RationalNumber)
Copy link
Contributor

Choose a reason for hiding this comment

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

expectType already creates an error message

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok, yeah, it was like that before, but then if we make expectType return a bool, should not the condition be negated?

chriseth
chriseth previously approved these changes Sep 26, 2018
@codecov
Copy link

codecov bot commented Oct 4, 2018

Codecov Report

Merging #5096 into develop will increase coverage by <.01%.
The diff coverage is 77.77%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #5096      +/-   ##
===========================================
+ Coverage    88.02%   88.02%   +<.01%     
===========================================
  Files          314      314              
  Lines        31782    31784       +2     
  Branches      3748     3749       +1     
===========================================
+ Hits         27976    27978       +2     
  Misses        2537     2537              
  Partials      1269     1269
Flag Coverage Δ
#all 88.02% <77.77%> (ø) ⬆️
#syntax 28.78% <77.77%> (ø) ⬆️

@erak erak changed the title [WIP] Do not crash on invalid indexed access Do not crash on invalid indexed access Oct 4, 2018
@erak erak changed the title Do not crash on invalid indexed access Do not crash on invalid index access Oct 4, 2018
{
auto baseType = dynamic_cast<ArrayType const*>(arrayType->baseType().get());
if (arrayType->location() == DataLocation::Memory || arrayType->location() == DataLocation::CallData)
if ((baseType && !baseType->validForCalldata()) || !arrayType->validForCalldata())
Copy link
Contributor

Choose a reason for hiding this comment

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

If the base type is not valid for calldata, why should the type itself be? This rather sounds like the change should be inside validForCalldata

Copy link
Contributor

@chriseth chriseth left a comment

Choose a reason for hiding this comment

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

This PR needs to be split into multiple PRs.

@erak
Copy link
Collaborator

erak commented Oct 10, 2018

I split out #5188 and #5195. Since these PRs are very related to each other, I based my decision on where to split them on the parts of the compiler they change and not on the test cases they cover.

This PR now depends on #5195, because the new signature of expectType() will only be introduced by that one.

@erak erak mentioned this pull request Oct 10, 2018
@erak
Copy link
Collaborator

erak commented Oct 12, 2018

After checking again, it became clear that #5195 already fixed the remaining bug that this PR is trying to fix. I will close it now as this change does not seem to be needed anymore.

@erak erak closed this Oct 12, 2018
@axic axic deleted the invalid-index-literals branch March 22, 2019 11:16
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

Successfully merging this pull request may close these issues.

3 participants