New callTracer fails at block 1,431,916

[tanmaster]

System information

Geth version: 1.10.10-unstable, build from master branch
OS & Version: Linux
Commit hash : 633e7ef

I was not sure if this was reported or maybe even fixed already (saw some similar sounding discussions in #23669), so this is just in case. The new callTracer fails at block 1431916 for transaction number 38 (hash: 0x0c10fafe0cdbfff32abfe53d57ec861d09986cc1050c850481f79b1a862bb10a).

Expected behaviour

Traces are returned via RPC socket / websocket.

Actual behaviour

Once that transaction is reached, the following is logged into the geth console (and the tracing continues):

WARN [10-12|20:56:42.851] Tracing failed                           hash=0c10fa..2bb10a block=1,431,916 err="RangeError: json encode recursion limit    in server-side tracer function 'result'"

The error message is quite telling. This transaction spawns a call which recursively calls itself 1024 times (which is the maximum depth for calls in the EVM it think?). After a bit of fiddling, I found that go-duktape sets the default value for the encoding recursion limit to 1000:

https://github.com/olebedev/go-duktape/blob/650f7c85444083d383394f0ac179080ae3b94325/duk_config.h#L3015:

#define DUK_USE_JSON_ENC_RECLIMIT 1000

So my guess is: Since the data structure that holds the results for this transaction is a 1024x nested object, it can't be jsonified. However, trying to set that limit higher (by editing the source file and recompiling) did not work for me, but I am not sure if that is the correct way to do it anyway.

My limited understanding leads me to think that this behaviour could be mitigated by unwrangling the nested object inside the finalize method into an array before returning it. But I also think that doing so would eat up a lot of computation time in the process, making tracing overall slower. So maybe trying to set up the limit is the best approach, especially if the maximum depth is only larger by 24...?

Steps to reproduce the behaviour

Unfortunately, on my machine, it takes almost 1 hour to trace up to said failing block since I have to start at block 0. So reproducing would be easier on a full archive machine I guess.

The command I use for tracing:

{"id": 1, "method": "debug_subscribe", "params": ["traceChain", "0x0", "0x15d96d", {"tracer": "callTracer"}]}

[holiman]

See #21879 and #16426 . We've "handled" it insofar as we don't crash, but can't really fix the root problem.

[holiman]

See #22857 for even more context

[tanmaster]

Bummer, thanks for the swift reply though!