The `debug` API gives you access to several non-standard RPC methods, which will allow you
to inspect, debug and set certain debugging flags during runtime.
* TOC
{:toc}
### debug_accountRange
Enumerates all accounts at a given block with paging capability. `maxResults` are returned in the page and the items have keys that come after the `start` key (hashed address).
If `incompletes` is false, then accounts for which the key preimage (i.e: the `address`) doesn't exist in db are skipped. NB: geth by default does not store preimages.
Returns all accounts that have changed between the two blocks specified. A change is defined as a difference in nonce, balance, code hash, or storage hash. With one parameter, returns the list of accounts modified in the specified block.
Turns on mutex profiling for nsec seconds and writes profile data to file. It uses a profile rate of 1 for most accurate information. If a different rate is desired, set the rate and write the profile manually.
When JS-based tracing (see below) was first implemented, the intended usecase was to enable long-running tracers that could stream results back via a subscription channel.
This method works a bit differently. (For full details, see [PR](https://github.com/ethereum/go-ethereum/pull/17914))
- It streams output to disk during the execution, to not blow up the memory usage on the node
- It uses `jsonl` as output format (to allow streaming)
- Uses a cross-client standardized output, so called 'standard json'
* Uses `op` for string-representation of opcode, instead of `op`/`opName` for numeric/string, and other simlar small differences.
* has `refund`
* Represents memory as a contiguous chunk of data, as opposed to a list of `32`-byte segments like `debug_traceTransaction`
This means that this method is only 'useful' for callers who control the node -- at least sufficiently to be able to read the artefacts from the filesystem after the fact.
The method can be used to dump a certain transaction out of a given block:
Files are created in a temp-location, with the naming standard `block_<blockhash:4>-<txindex>-<txhash:4>-<random suffix>`. Each opcode immediately streams to file, with no in-geth buffering aside from whatever buffering the os normally does.
On the server side, it also adds some more info when regenerating historical state, namely, the reexec-number if `required historical state is not avaiable` is encountered, so a user can experiment with increasing that setting. It also prints out the remaining block until it reaches target:
```
INFO [10-15|13:48:25.263] Regenerating historical state block=2385959 target=2386012 remaining=53 elapsed=3m30.990537767s
INFO [10-15|13:48:33.342] Regenerating historical state block=2386012 target=2386012 remaining=0 elapsed=3m39.070073163s
INFO [10-15|13:48:33.343] Historical state regenerated block=2386012 elapsed=3m39.070454362s nodes=10.03mB preimages=652.08kB
INFO [10-15|13:48:33.352] Wrote trace file=/tmp/block_0x14490c57-0-0xfbbd6d91-715824834
INFO [10-15|13:48:33.352] Wrote trace file=/tmp/block_0x14490c57-1-0x71076194-187462969
INFO [10-15|13:48:34.421] Wrote trace file=/tmp/block_0x14490c57-2-0x3f4263fe-056924484
```
The `options` is as follows:
```
type StdTraceConfig struct {
*vm.LogConfig
Reexec *uint64
TxHash *common.Hash
}
```
### debug_standardTraceBadBlockToFile
This method is similar to `debug_standardTraceBlockToFile`, but can be used to obtain info about a block which has been _rejected_ as invalid (for some reason).
### debug_startCPUProfile
Turns on CPU profiling indefinitely, writing to the given file.
Returns the storage at the given block height and transaction index. The result can be paged by providing a `maxResult` to cap the number of storage slots returned as well as specifying the offset via `keyStart` (hash of storage key).
The `debug_traceCall` method lets you run an `eth_call` within the context of the given block execution using the final state of parent block as the base. The first argument (just as in `eth_call`) is a [transaction object](/docs/rpc/objects#transaction-call-object). The block can be specified either by hash or by number as the second argument. A tracer can be specified as a third argument, similar to `debug_traceTransaction`. It returns the same output as `debug_traceTransaction`.
Returns the structured logs created during the execution of EVM between two blocks (excluding start) as a JSON object.
This endpoint must be invoked via `debug_subscribe` as follows:
`const res = provider.send('debug_subscribe', ['traceChain', '0x3f3a2a', '0x3f3a2b'])`
please refer to the [subscription page](https://geth.ethereum.org/docs/rpc/pubsub) for more details.
### debug_traceTransaction
**OBS** In most scenarios, `debug.standardTraceBlockToFile` is better suited for tracing!
The `traceTransaction` debugging method will attempt to run the transaction in the exact same manner
as it was executed on the network. It will replay any transaction that may have been executed prior
to this one before it will finally attempt to execute the transaction that corresponds to the given
hash.
In addition to the hash of the transaction you may give it a secondary *optional* argument, which
specifies the options for this specific call. The possible options are:
*`disableStorage`: `BOOL`. Setting this to true will disable storage capture (default = false).
*`disableStack`: `BOOL`. Setting this to true will disable stack capture (default = false).
*`enableMemory`: `BOOL`. Setting this to true will enable memory capture (default = false).
*`enableReturnData`: `BOOL`. Setting this to true will enable return data capture (default = false).
*`tracer`: `STRING`. Setting this will enable JavaScript-based transaction tracing, described below. If set, the previous four arguments will be ignored.
*`timeout`: `STRING`. Overrides the default timeout of 5 seconds for JavaScript-based tracing calls. Valid values are described [here](https://golang.org/pkg/time/#ParseDuration).
Specifying the `tracer` option in the second argument enables JavaScript-based tracing. In this mode, `tracer` is interpreted as a JavaScript expression that is expected to evaluate to an object which must expose the `result` and `fault` methods. There exist 3 additional methods, namely: `step`, `enter` and `exit`. You must provide either `step`, or `enter` AND `exit` (i.e. these two must be exposed together). You may expose all three if you choose to do so.
##### Step
`step`is a function that takes two arguments, log and db, and is called for each step of the EVM, or when an error occurs, as the specified transaction is traced.
`log` has the following fields:
-`op`: Object, an OpCode object representing the current opcode
-`memory`: Object, a structure representing the contract's memory space
-`contract`: Object, an object representing the account executing the current operation
and the following methods:
-`getPC()` - returns a Number with the current program counter
-`getGas()` - returns a Number with the amount of gas remaining
-`getCost()` - returns the cost of the opcode as a Number
-`getDepth()` - returns the execution depth as a Number
-`getRefund()` - returns the amount to be refunded as a Number
-`getError()` - returns information about the error if one occured, otherwise returns `undefined`
If error is non-empty, all other fields should be ignored.
For efficiency, the same `log` object is reused on each execution step, updated with current values; make sure to copy values you want to preserve beyond the current call. For instance, this step function will not work:
-`isPush()` - returns true iff the opcode is a PUSHn
-`toString()` - returns the string representation of the opcode
-`toNumber()` - returns the opcode's number
`log.memory` has the following methods:
-`slice(start, stop)` - returns the specified segment of memory as a byte slice
-`getUint(offset)` - returns the 32 bytes at the given offset
`log.stack` has the following methods:
-`peek(idx)` - returns the idx-th element from the top of the stack (0 is the topmost element) as a big.Int
-`length()` - returns the number of elements in the stack
`log.contract` has the following methods:
-`getCaller()` - returns the address of the caller
-`getAddress()` - returns the address of the current contract
-`getValue()` - returns the amount of value sent from caller to contract as a big.Int
-`getInput()` - returns the input data passed to the contract
`db` has the following methods:
-`getBalance(address)` - returns a `big.Int` with the specified account's balance
-`getNonce(address)` - returns a Number with the specified account's nonce
-`getCode(address)` - returns a byte slice with the code for the specified account
-`getState(address, hash)` - returns the state value for the specified account and the specified hash
-`exists(address)` - returns true if the specified address exists
If the step function throws an exception or executes an illegal operation at any point, it will not be called on any further VM steps, and the error will be returned to the caller.
##### Result
`result` is a function that takes two arguments `ctx` and `db`, and is expected to return a JSON-serializable value to return to the RPC caller.
`ctx` is the context in which the transaction is executing and has the following fields:
-`type` - String, one of the two values `CALL` and `CREATE`
-`from` - Address, sender of the transaction
-`to` - Address, target of the transaction
-`input` - Buffer, input transaction data
-`gas` - Number, gas budget of the transaction
-`value` - big.Int, amount to be transferred in wei
-`block` - Number, block number
-`output` - Buffer, value returned from EVM
-`gasUsed` - Number, amount of gas used in executing the transaction (excludes txdata costs)
-`time` - String, execution runtime
##### Fault
`fault` is a function that takes two arguments, `log` and `db`, just like `step` and is invoked when an error happens during the execution of an opcode which wasn't reported in `step`. The method `log.getError()` has information about the error.
##### Enter & Exit
`enter` and `exit` are respectively invoked on stepping in and out of an internal call. More specifically they are invoked on the `CALL` variants, `CREATE` variants and also for the transfer implied by a `SELFDESTRUCT`.
`enter` takes a `callFrame` object as argument which has the following methods:
-`getType()` - returns a string which has the type of the call frame
-`getFrom()` - returns the address of the call frame sender
-`getTo()` - returns the address of the call frame target
-`getInput()` - returns the input as a buffer
-`getGas()` - returns a Number which has the amount of gas provided for the frame
-`getValue()` - returns a `big.Int` with the amount to be transferred only if available, otherwise `undefined`
`exit` takes in a `frameResult` object which has the following methods:
-`getGasUsed()` - returns amount of gas used throughout the frame as a Number
-`getOutput()` - returns the output as a buffer
` -getError()` - returns an error if one occured during execution and `undefined` otherwise
##### Usage
Note that several values are Golang big.Int objects, not JavaScript numbers or JS bigints. As such, they have the same interface as described in the godocs. Their default serialization to JSON is as a Javascript number; to serialize large numbers accurately call `.String()` on them. For convenience, `big.NewInt(x)` is provided, and will convert a uint to a Go BigInt.
Usage example, returns the top element of the stack at each CALL opcode only:
