Truffle debugger hangs while stepping instruction

[Poytr1]

• I've opened a support ticket before filing this issue.

---

Issue

Truffle debugger hangs while stepping instruction

Steps to Reproduce

truffle debug 0x65d06d2c333b3705554cbb2ee19897e385787a7745939b30dc857161e488671c --fetch-external --url localhost:8545

Then step instruction for 5232 instructions:

;5232

Then step instruction,

The debugger hangs.

Expected Behavior

Step to the next instruction

Actual Results

It never returns

Environment

• Operating System: MacOS
• Ethereum client:
• Truffle version (truffle version): v5.7.0
• node version (node --version):v18.2.0
• npm version (npm --version): 8.9.0

[eggplantzzz]

Hey @Poytr1, thanks for reporting this! Could you let me know how long the debugger hangs? Does it ever return? I just ask as it is possible that it is performing some intense computation. Also, what client/setup are you using?

[Poytr1]

@eggplantzzz Thanks for your quick response!

I waited for several hours, but it never returned. I'm using a local erigon debug node, and here's my truffle config:

module.exports = {
  networks: {
    development: {
      host: "127.0.0.1",
      port: 8545,
      network_id: "*", // match any network
    },
  },
  compilers: {
    solc: {
      version: "0.8.13"
    }
  }
};

[eggplantzzz]

Thanks for the added information! We'll have to take a look into this. @haltman-at

[haltman-at]

@Poytr1 One more question -- it looks like you're debugging a verified external contract on (a forked verison of) some network. What network? Is that mainnet? I was just setting up to reproduce this and realized that was never specified. I'll assume for now that it's mainnet, but please let me know. Thanks!

[haltman-at]

Well, I reproduced the problem so I guess it is mainnet! :) Thanks for bringing this to our attention!

[haltman-at]

OK, on looking into this, I'm pretty confused as to what's going on here.

Let's start with what I can determine. If you attempt to advance from the highlighted step, the debugger will attempt to decode the checkpoints array. (This is because of the debugger's txlog feature, which admittedly isn't very user-visible at the moment. However the same code would be called if you tried to view the contents of checkpoints with v instead at any point.)

The array checkpoints has -- at least according to what the debugger can determine -- a length of 45,040 elements. (Each element is a struct consisting of two uint128s.) Ideally there would be some way to paginate that (see issue #3858), but, that being something we've never implemented, the debugger will attempt to decode all of it. Most of it is storage that the debugger can't currently see, mind you, so it's going to decode to question marks.

After decoding about 900 of these -- the exact number varies -- the debugger stopds decoding and hangs. I don't know why. Not only does the count vary, but the exact point in the code where the hang happens seems to vary as well. Again, I don't know why.

So I'm fairly stumped at the moment. I don't know what's going on here. Those are the pieces of the puzzle I can determine, however.

[Poytr1]

Hi @haltman-at , thanks for your reply, I also tried to debug it before, and once it threw an exception (although I never repro again), it may be related

# Fatal error in ../deps/v8/src/execution.cc, line 64
# Check failed: AllowJavascriptExecution::IsAllowed(isolate).

BTW, I'm curious how you debugged to where the checkpoint is being decoded, are there any instructions I can follow to debug this myself using truffle code?

[Poytr1]

Ok, I repro this issue with another transaction 0xd3cd25657ddc3c580decd1641b3983553445e3c90f4687c05ae12e6031f93119

The function is defined as below (https://github.com/Uniswap/v3-core/blob/05c10bf6d547d6121622ac51c457f93775e1df09/contracts/libraries/Oracle.sol#L78):

function write(
        Observation[65535] storage self,
        uint16 index,
        uint32 blockTimestamp,
        int24 tick,
        uint128 liquidity,
        uint16 cardinality,
        uint16 cardinalityNext
    ) internal returns (uint16 indexUpdated, uint16 cardinalityUpdated)

where there's an array with 65535 elements in storage.