Comments (9)
@jubeira Your case seems to be resolved too on develop
.
Repro instructions directly with solc
0.8.26:
git clone https://github.com/balancer/balancer-v3-monorepo
cd balancer-v3-monorepo/
yarn install
cd pkg/vault/
solc \
contracts/VaultExplorer.sol \
@balancer-labs/=../../node_modules/@balancer-labs/ \
@openzeppelin/=../../node_modules/@openzeppelin/ \
permit2/=../../node_modules/permit2/ \
--allow-paths ../../ \
--bin \
--via-ir \
--optimize \
--optimize-runs 999 \
--evm-version cancun \
--yul-optimizations 'dhfoDgvulfnTUtnIf [ xa[r]EscLM cCTUtTOntnfDIul Lcul Vcul [j] Tpeul xa[rul] xa[r]cL gvif CTUca[r]LSsTFOtfDnca[r]Iulc ] jmul[jul] VcTOcul jmul : fDnTOcmu'
Internal compiler error:
/solidity/libsolidity/interface/CompilerStack.cpp(1408): Throw in function void solidity::frontend::CompilerStack::assembleYul(const solidity::frontend::ContractDefinition&, std::shared_ptr<solidity::evmasm::Assembly>, std::shared_ptr<solidity::evmasm::Assembly>)
Dynamic exception type: boost::wrapexcept<solidity::langutil::InternalCompilerError>
std::exception::what: Assembly exception for bytecode
[solidity::util::tag_comment*] = Assembly exception for bytecode
Hope this helps as a clue! I'd love to have this fixed.
The will be released as a part of 0.8.27, some time next week.
from solidity.
By the way, @jubeira, looks like you're using the default sequence from 0.8.25, I'm assuming to avoid the "Stack too deep" errors. You should be able to avoid them by making your assembly memory-safe. Have you tried that?
Thanks for the fix and the hint! We'll give it a shot; we've added memory-safe
directives only very recently.
from solidity.
An ICE is not really something that you should be seeing, so it does look like a bug. Looking a bit further into it, the assertion that's triggered is this one.
Was likely introduced here for the 0.8.25 release.
from solidity.
We discussed it on the chat today and it seems to be a regression introduced by the fix for #14863. @ekpyron's diagnosis sounds very plausible:
But yeah, before #14864 we generally overallocated the tag sizes - after that PR, we rely on the code size estimate to be accurate (as in: precise or overestimating) - which is probably broken in a few corner cases (I've seen some in the PUSH0 PR even IIRC) - which would break with that assert in some corner cases - that's my best guess.
Also, regarding the possibility that it's 0.8.24 that is broken and the assertion wasn't being triggered due to incorrect code being generated:
In fact the miscalculation we had in that code before could have lead to something quite similar to that (i.e. allocating too small of space for tags and then just overwriting code when inserting them), but we did already have assertions against that back then
Overall, this is all still speculation since the repro is quite unwieldy (it's a whole repo - a small snippet would be much more helpful) so we'll need to confirm this before fixing, but it's probably correct considering all the info we have so far.
Finally, this bug also highlights a small related issue, i.e. that "assembly exception" for some reason does not include the original message from the assertion that @nikola-matic pointed at. Having it there would have made things clearer from the beginning. We should fix that too.
from solidity.
I have this exact same issue with Balancer V3.
I am using via-ir with the default optimizing steps in 0.8.24 which works fine; 0.8.25 and 0.8.26 do not.
To reproduce, run build instructions (yarn && yarn build) from this commit.
I've narrowed down the problem to the Vault package, and curiously the contract that is causing the problem seems to be VaultExplorer, which is rather simple in comparison to the rest. That branch works if VaultExplorer is deleted from the files or compiled with 0.8.24 as in here.
Hope this helps as a clue! I'd love to have this fixed.
from solidity.
I can confirm that this no longer happens on the current develop
, so it seems that #15354 must have fixed it.
On 0.8.26 it was indeed reproducible with:
git clone https://github.com/lens-protocol/core.git
cd core/
forge install
forge build \
--use 0.8.26 \
--optimize \
--via-ir \
--evm-version cancun \
--no-cache \
--skip test
[⠊] Compiling...
[⠒] Compiling 251 files with Solc 0.8.26
[⠢] Solc 0.8.26 finished in 3.99s
Error:
Compiler run failed:
Error: Internal compiler error (/solidity/libsolidity/interface/CompilerStack.cpp:1408):Assembly exception for bytecode
InternalCompilerError: Assembly exception for bytecode
from solidity.
By the way, @jubeira, looks like you're using the default sequence from 0.8.25, I'm assuming to avoid the "Stack too deep" errors. You should be able to avoid them by making your assembly memory-safe. Have you tried that?
from solidity.
Just for the record: the code does not compile with 0.8.26 with via-IR and the new default optimization steps (stack too deep error). All assembly blocks are memory safe as far as I can tell now, so it might be something else.
The previous optimization sequence from 0.8.24/5 does work.
from solidity.
Does the error also say memoryguard was present
? If it doesn't, there's still something that prevents the compiler from using stack-to-memory mover, which is the mechanism through which the compiler addresses StackTooDeep in the hardest cases for now. There are some things other than unsafe assembly that could prevent it from kicking in, e.g. recursive functions, though the assembly is the most common cause.
But yeah, unfortunately there are still some rare cases in which even with stack-to-memory mover the Yul->EVM transform is unable to generate code and it could just as well be one of those. The change of the sequence did expose some of those in code that was on the verge of running into StackTooDeep due to stack pressure (though it also helped resolve StackTooDeep in other cases so it's a wash). We're working on improving the transform to address these cases, but if you're running into this then I guess using the old sequence is probably the simplest workaround.
from solidity.
Related Issues (20)
- Nested memory arrays not implemented in ABICoder V1
- Switch all MacOS scripts to use GNU utils
- codegen error: Copying of type struct memory[] memory to storage not yet supported. HOT 1
- IR-based Codegen error: too deep inside the stack.
- SMTChecker: Error trying to invoke SMT solver
- SMTChecker: struct variable push() cause false positive HOT 1
- ABICoderv1 and AST import cause storage difference due to function-type variable assignment
- mstore(add(mload(0x80), 0x20), xx) cause IR-based codegen execution revert.
- IR-base codegen, abicoder v1, Ast import lack of memory protection mechanism
- write to uint[2][2] calldata fail in IR-based Codegen HOT 1
- IR-based codegen: Modifying the length of a dynamic array to a large number in assembly, followed by a push() operation, will cause a revert.
- Unnamed return variable is displayed incorrectly in counter example
- When accessing an out-of-bounds index in a fixed-size array, the contract execution reverts
- Unreachable code warning for internal function called by an abstract contract HOT 1
- Compiler error on attempting to use hexadecimal literals of length 39-41 as integers HOT 1
- Unable to check existence of precompiled contract by its address or get its code in VM or Sepolia testnet HOT 1
- Yul interpreter subset for side-effect-free evaluation
- do-while results in redundant branching instructions when compiling via IR HOT 1
- Call external pure function from another pure function of the same contract using "this" causes an error HOT 3
- uint[3] memory a = [1,2,3]; caused "Type uint8[3] memory is not implicitly convertible to expected type uint256[3] memory." HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from solidity.