Navigating the stack in a coredump resulting from a stack overflow is slow

[superbobry]

I was debugging a coredump produced by a stack overflow recently, and I noticed that Delve gets increasingly slower as I go up the stack. I suspect that stack navigation commands in Delve (up, down etc) could be linear in stack size. Does that sound right?

I usually need to go to the top of the stack to understand what caused the stack overflow, and that easily takes minutes, because each step along the stack is slow (and is only getting slower).

I assume this should be fairly easy to reproduce, but let me know if you need more details.

---

1. What version of Delve are you using (dlv version)?

   1.23.0

2. What version of Go are you using? (go version)?

   go1.23-20240626-RC01

3. What operating system and processor architecture are you using?

   Linux, x64

[aarzilli]

Yes, making a stack trace takes linear time (and, currently, memory) in the depth you ask for and there is no caching layer.

[aarzilli]

Although I'm surprised that it takes minutes, how deep into the stack are you going?

[superbobry]

[...] how deep into the stack are you going?

Pretty deep, millions of frames.

Yes, making a stack trace takes linear time (and, currently, memory) in the depth you ask for and there is no caching layer.

Does up require making a trace from the top of the stack? Is this solvable in principle?

[aarzilli]

Yes, making a stack trace takes linear time (and, currently, memory) in the depth you ask for and there is no caching layer.

Does up require making a trace from the top of the stack?

Yes, because there is no caching layer.

Is this solvable in principle?

For up yes, for down probably not because it would introduce other problems.

For your problem however, you would be better off doing a huge stack trace of 10 million frames and just look at that, instead of using up. It's still going to be slower than it should be but it's more tempting to optimized huge stack traces (possibly add something for infinite stack traces) than making up fast.

[superbobry]

Making a huge stack trace sadly won't work for my use case, since I need to print local variables/arguments in the bottom frames.