If you’re not a fan of CLI tools, Remix is a good debugging alternative for you. In fact, Remix provides a graphical interface with many more options.
Start and connect Remix to Ganache as we did in the previous chapter. Once connected, you will be able to debug the previous transaction we debugged using Truffle. First of all, we need to activate the debugging mode. There are several ways to achieve that, the easiest way being to browse to the debugger tab in the right-hand panel, and then provide either a transaction hash (transaction index) or a block number in the debugging input:
In Remix's right-hand pane, on the debugging form with several controls, press the play button to start debugging. You’ll get a debugging menu with the views depicted here:
The views are listed as follows:
- Instructions: Lists the executed opcodes
- Solidity Locals: Shows the content of local variables in the current scope
- Solidity State: Displays state variables of the current executing contract
- Step detail: Displays the current step's execution details (remaining gas and VM trace step)
- Stack: Displays the local variables values stored in the stack
- Storage: Displays the contract storage entries(key, value) as shown here:
- Memory: Provides a view into the memory space that is used by the contract
- Call Data: Usually contains a 4-byte method signature followed by serialized arguments
The slider bar at the top (transaction section) helps you advance or roll back the execution of the transaction (debugging) easily to visualize the evolution of the available debugging information.
Below the slider, Remix provides a set of buttons at the top of the toolbar for controlling the execution of the transaction you are debugging:
- Step through a transaction's payload execution using the debugging buttons: Single over back
, step back 
, step into 
, and step over 
- You can stop debugging and resume operations at any time using the respective debugging buttons:
and 
Debugging the previous faulty transaction using the transaction’s ID with Remix debugger boils down to dealing with crude information, including the list of executed opcodes. In this first case, the debugger shows us that the execution ends with a REVERT instruction:
If you follow the JUMP instructions and the values being loaded into the stack, you’ll be able to trace the source of the exception. However, I highly suspect you can't (or don't want to) deal with this hard task, which is why I am proposing an easier alternative in the remainder of this section.