roschler
commented
6 years ago @cgewecke and @gnidan
Hello Christopher and Nicholas,
TL;DR
I believe this problem occurs when there is a mismatch between a contract address and the ABI the Truffle console tries to apply during a method call against a deployed contract. My feeling is that it's going to boil down to providing a better error message when this occurs, assuming you can detect such a condition like the mismatch between a deployment image vs ABI problems. When I say mismatch I mean either because the wrong contract address is supplied by the user or there is a mismatch between the ABI and the deployed contract image (user forgot to re-compile, etc.)
Long version
NOTE: My current belief, perhaps due to my own lack of skill as a novice dApp/Solidity coder, is that it is not possible to debug ZeppelinOS proxy contracts using the Truffle console debug command.
The ZeppelinOS proxy contract tools sets up an environment where a "forward facing" contract passes on calls to the current logic contract (i.e. - implementation contract) using delegatecall. It also does some tricks using Assembly() to pass on the state variables using Soliditys raw memory slots. (E.g. - mload, calldatacopy, returndatacopy, etc.). You can see those contracts here:
https://github.com/zeppelinos/zos-lib/tree/development/contracts/upgradeability
To faciliate this discussion. Please look at the zos.network.json file below. This file is the record-keeping file that the ZOS client commands use to track the proxy-to-proxied-contract relationships active in an app and the changes that take place between them over time. Note the contracts.Basil.address, proxies.Basil.address, proxies.Basil.implementation, and app addresses:
{
"contracts": {
"Basil": {
"address": "0x6ed79aa1c71fd7bdbc515efda3bd4e26394435cc",
"bytecodeHash": "93e5232cedc10f89615de9b638a9a025dbd87a0e76127ee16695255bea4caf85"
}
},
"proxies": {
"Basil": [
{
"address": "0x4849038be95fe6e42da67c9edbe411709e9c6780",
"version": "0.0.2",
"implementation": "0x6ed79aa1c71fd7bdbc515efda3bd4e26394435cc"
}
],
"MintableERC721Token": [
{
"address": "0x5c4f7148f0bbc0328cb487f72b2ba71a30895a36",
"version": "0.0.2",
"implementation": "0xad888d0ade988ebee74b8d4f39bf29a8d0fe8a8d"
}
]
},
"app": {
"address": "0x67b5656d60a809915323bf2c40a8bef15a152e3e"
},
"version": "0.0.2",
"package": {
"address": "0x59d3631c86bbe35ef041872d502f218a39fba150"
},
"provider": {
"address": "0x0e696947a06550def604e82c26fd9e493e576337"
},
"stdlib": {
"address": "0x21a59654176f2689d12e828b77a783072cd26680",
"customDeploy": true,
"name": "openzeppelin-zos",
"version": "1.9.1"
}For a while I was not getting the "context null" error and I recently figured out why. It's because I was passing the debug command the actual address of my proxied contract, not the address of the proxy entry point. This is actually a mistake of course because by doing this I was going around the proxy and going straight to the proxied contract, thus circumventing the proxy. However, this made the Truffle debug command happy since the ABI of the contract matched up with the contract executing the code the debug command was tracing through, given the Tx hash passed to the debug command.
The instant I switch to the proxy address and by that I mean either the app address or the proxies.Basil.address address I immediately get the "context null" error. This makes sense because the ABI of BasilERC721, the proxied contract, does not match those other addresses because they belong to different contract types. Therefore when I tried to debug the transaction using the following command, which uses the proxy "front end" address aka the app address the error occurs:
BasilERC721.at("0x67b5656d60a809915323bf2c40a8bef15a152e3e").emitOwnerDetails.sendTransaction({from: web3.eth.accounts[0], gas: 4200000});I've attached the exact steps I follow to make this happen. When I say exact I mean exactly that since I've executed the steps a few hundred times now. The document attached is my revision of the ZeppelinOS Basil tutorial found here in its original form:
https://docs.zeppelinos.org/docs/basil.html
My next test will be to try and issue the debug command using the Zeppelin OS Proxy contract as the contract wrapper for the setToken command. Hopefully that contract is getting deployed during the Truffle migrate that takes place when you execute a debug command. Perhaps I'll be able to trace from by going in the front door.
@gnidan I believe trying to use my repo as opposed to the attached instructions will do more harm than good since you have to setup several environment variables as you go through the tutorial. If those values are wrong you'll end up debugging the wrong thing (aka "wild goose chase").
gitcoinbot
froller
vongohren
gnidan
svechinsky
chris-gilbert
spm32
kuhnchris
We are trying to debug a contract and receive this error every time we try to debug a transaction involving that contract, using both
truffle debugand running a script that imports the debugger. The contracts were migrated withtruffle migrate --reset --compile-all