You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When you have defer func() { /* code */ () and there is a nil pointer dereference in the body of func, then the stack trace (correctly) shows the line inside the func() where the nil pointer dereference happened. (Example: https://go.dev/play/p/qjGg11jBLwD)
func main() {
s := struct{ f func() }{}
defer func() {
s.f()
}()
}
This can make debugging quite confusing, as the final line in the stack trace might actually not have any code at all, or it might have some code which can never have a nil pointer exception.
What did you see happen?
Missing entry in the stack trace. See the section above.
What did you expect to see?
There should be an extra entry in the stack trace pointing to the appropriate line in the defer statement where the nil pointer dereference actually happened.
Aside
This issue is based on a confusing stack trace that my colleague @antonsviridov-src debugged earlier today.
The text was updated successfully, but these errors were encountered:
Go version
go version go1.23.0 darwin/arm64
Output of
go env
in your module/workspace:What did you do?
When you have
defer func() { /* code */ ()
and there is a nil pointer dereference in the body of func, then the stack trace (correctly) shows the line inside thefunc()
where the nil pointer dereference happened. (Example: https://go.dev/play/p/qjGg11jBLwD)However, if you don't have a
func()
then the defer line is not shown in the panic (Example: https://go.dev/play/p/1tvIBFvpdss)This can make debugging quite confusing, as the final line in the stack trace might actually not have any code at all, or it might have some code which can never have a nil pointer exception.
What did you see happen?
Missing entry in the stack trace. See the section above.
What did you expect to see?
There should be an extra entry in the stack trace pointing to the appropriate line in the defer statement where the nil pointer dereference actually happened.
Aside
This issue is based on a confusing stack trace that my colleague @antonsviridov-src debugged earlier today.
The text was updated successfully, but these errors were encountered: