interpreting runtime.Stack()

[Andrew Athan]

goroutine 1299607 [runnable]:
context.(*valueCtx).Err(0xc00a52c3c0?)
<autogenerated>:1 +0x3e
context.(*valueCtx).Err(0x48860a?)
<autogenerated>:1 +0x2a
... repeats many many many times ...
...additional frames elided...
created by
....one_of_my_functions()
somefile.go:2092 +0x4a5

What is going on here? is this likely to be an infinite recursion or similar within the context implementation or is this a normal thing to see?

[Axel Wagner]

What does the panic say? If it says "stack overflow", then yes, that's likely an infinite recursion. If not, then, no. My guess is, that it says "nil-pointer dereference".

The `<autogenerated>` part probably means this is due to embedding. That is, the `Err` method on `valueCtx` is promoted from an embedded Context: https://cs.opensource.google/go/go/+/refs/tags/go1.20.4:src/context/context.go;l=599

If that context was `nil` or otherwise invalid, that would explain why the panic happens. Though I'm not sure how that would happen, unless you use `unsafe` somewhere.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/095c81e9-15c2-4c27-b913-f85a16ee4968n%40googlegroups.com.

[Axel Wagner]

Ouh, I bet I know what's happening: You are using a concrete Context implementation that defines its methods on a value receiver, but pass it in as a nil-pointer: https://go.dev/play/p/JH9MxwvmTw7

That way, the panic happens in autogenerated code (the implicit promoted method from the value-type to the pointer-type) which then panics due to a nil-pointer dereference. The panic message should then actually tell you exactly that, though.

[Andrew Athan]

Alex:

I’ll see how/if this can happen. Among other strangeness in this stack is that Err() doesn’t take a param but I guess it may be displaying the implicit “this”?

btw this is not from a panic, but from a call to runtime.Stack(). The program experiences unbounded growth in cpu  utilization as it runs so either these stacks are a recursion bc there is a context “pointing” to itself as parent or a very deep reference stack.

I’m going to guess there is a captured continuation variable somewhere that is incorrectly updated to a new value ctx with each new connection made or inside some loop instead of using the oroginal basr ctx.

I looked for that originally but didn’t find it, but I’ll look again. I’m concerned that net.Conn’s or tls.Conn’s setRead/WriteDeadline() calls are at fault somehow.

A.

On May 12, 2023, at 12:38 AM, Axel Wagner <axel.wa...@googlemail.com> wrote:



[Andrew Athan]

This stack trace was indeed a contexts with very deep parenthood.