search

trufflesuite / truffle-debugger

Core functionality for debugging Solidity files built with Truffle
67 stars 12 forks source link

Inspect contract public storage variables? #77

Open roschler opened 6 years ago

roschler commented 6 years ago

When debugging in Truffle console using the debug command, I know you can use the "v" command to view the memory variables. However, nothing I've tried works when I want to look at the public storage variables. Currently, I'm trying in vain to inspect the contract owner storage variable that belongs to the Open Zeppelin Ownable contract my smart contract inherits from. I want to look at it because the require() statement for the onlyOwner modifier is failing and reverting the transaction. I can trace through the code, but I can not view either the owner property/storage-variable or the msg object or any of its properties. How can I view these elements?

Also, are there any docs describing what elements can be inspected via the evaluate expression command (i.e. - the colon ':')? The Web3.js interfaces like eth.Contract etc. are not supported and as mentioned above, trying to inspect any of the contract public storage variables doesn't work either. The only thing I've managed to evaluate so far is the this pointer and that just prints a couple of fields; something to do with "safe_eval" or something. It would be really helpful to find a document that explains how to work with the evaluate expressions command.

gnidan commented 6 years ago

@roschler this is due to a limitation in the way debug_traceTransaction works. Since storage addresses are difficult to enumerate (think mapping), the debugger only tracks storage variables once they are referenced via a load or store operation.

This is something that could be implemented, by requiring the debugger to make individual eth_getStorageAt calls for specific variables. I've had in my mind to get to this, but haven't found the time. I'd definitely be open to a pull request. If it's something you'd be interested in looking at, I can write-up some pointers / ideas.

Thanks!

roschler commented 6 years ago

@gnidan Would it be a dumb idea due to make a view only method in the contract that if called, made a "dummy" access to every contract property just to trigger that variable tracking? During a a local (Ganache) debug session, I could add a call to that function to whatever method I discover is throwing a revert error just to get that variable visibility. What do you think?

sfncook commented 6 years ago

@gnidan Seems like an easy first step would be to simply update the command list produced by the debugger to either not include those commands that aren't implemented or add a note that indicates that they aren't implemented yet. False advertising, bud. (I assume from the way that you respond to most of these issues with the debugger that you have some "ownership" of the product. My apologies if that's not the case.)

gnidan commented 6 years ago

@sfncook These commands are implemented, albeit sometimes minimally so. I think they're still useful and saying they're not implemented would mean that people don't use them for what they are useful for.

I apologize for your less than great experience with the debugger. I'm well-aware of the work that's still needed with the product and hope to be able to prioritize the various bug fixes and enhancements over the coming months.

FWIW, there is current active development on pulling out this project's data decoding functionality into a separate library, for the express purpose of providing more-complete listing of contract storage.