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
{{ message }}
This repository was archived by the owner on Jun 24, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Jun 24, 2026. It is now read-only.
Manticore removes only one metadata Swarm hash #909
The Solidity compiler automatically generates a JSON file, the contract metadata. The compiler appends a Swarm hash of the metadata file to the end of the bytecode. Some contracts have more than one metadata hash but Manticore only removes one.
Instead of a fixed length, an iteration should be added to the def _without_metadata method:
@juli hey, I know it has been some time, but can you add some example of Some contracts have more than one metadata hash?
The _without_metadata is used e.g. in calculate_coverage, so I believe it might introduce some bad bugs related to the coverage we report and so I added a high-priority here.
This is probably caused by a contract (X) creating another one (Y): Since Y's creation code is part of X's bytecode, also Y's metadata hash can be found there.
Thanks to @emiliorizzo I have a sample:
End of bytecode metadata:
a165627a7a723058207b86d41905245d0cddab03c40602fcba860db843231d0189039c19578fc091c30029526f6c65733a206163636f756e7420697320746865207a65726f2061646472657373
Look at the end, it is ASCII: \x86\xd4\x19\x05$]\x0c\xdd\xab\x03\xc4\x06\x02\xfc\xba\x86\r\xb8C#\x1d\x01\x89\x03\x9c\x19W\x8f\xc0\x91\xc3\x00)Roles: account is the zero address
@juli since a 5.x version, Solidity changed how string constants are stored in bytecode. If you have a string literal in the constructor, such as a revert reason, those are stored at the very end of the contract bytecode, even after the metadata hash. It seems like this is the case here.
This applies to all constants and goes back a long time (at least pre 0.3.1). It might be that it 0.5.x we changed how the costs are calculated for that optimizer method, so it was used more often.
I was not aware of the string literal in the constructor corner case.
It looks like we are not supporting also newer versions of the metadata. For the long run, I think we should move the metadata responsibility to crytic-compile.
Activity
disconnect3d commentedon Jan 15, 2019
@juli hey, I know it has been some time, but can you add some example of
Some contracts have more than one metadata hash?The
_without_metadatais used e.g. incalculate_coverage, so I believe it might introduce some bad bugs related to the coverage we report and so I added a high-priority here.juli commentedon Jan 23, 2020
I found more instances of broken metadata and now I think it's a solc bug, but I didn't have time to investigate it further.
chriseth commentedon Jan 23, 2020
This is probably caused by a contract (X) creating another one (Y): Since Y's creation code is part of X's bytecode, also Y's metadata hash can be found there.
juli commentedon Jan 23, 2020
Thanks to @emiliorizzo I have a sample:
End of bytecode metadata:
a165627a7a723058207b86d41905245d0cddab03c40602fcba860db843231d0189039c19578fc091c30029526f6c65733a206163636f756e7420697320746865207a65726f2061646472657373Look at the end, it is ASCII:
\x86\xd4\x19\x05$]\x0c\xdd\xab\x03\xc4\x06\x02\xfc\xba\x86\r\xb8C#\x1d\x01\x89\x03\x9c\x19W\x8f\xc0\x91\xc3\x00)Roles: account is the zero addressLooks like an uninitialized memory issue to me.
spalladino commentedon Jan 23, 2020
@juli since a 5.x version, Solidity changed how string constants are stored in bytecode. If you have a string literal in the constructor, such as a revert reason, those are stored at the very end of the contract bytecode, even after the metadata hash. It seems like this is the case here.
chriseth commentedon Jan 23, 2020
This applies to all constants and goes back a long time (at least pre 0.3.1). It might be that it 0.5.x we changed how the costs are calculated for that optimizer method, so it was used more often.
spalladino commentedon Jan 23, 2020
Indeed, I think it was 0.5.2:
montyly commentedon Jan 24, 2020
Thanks, @juli, @chriseth, and @spalladino for pointing this out and providing all these details.
I was not aware of the string literal in the constructor corner case.
It looks like we are not supporting also newer versions of the metadata. For the long run, I think we should move the metadata responsibility to
crytic-compile.