fasthttp: Panics at on context close, v1.33.0

Hello, unfortunately there are no more details except this message I could find.

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x200 pc=0x901667]

goroutine 19473 [running]:
github.com/valyala/fasthttp.(*RequestCtx).Done(0x8c4639)
        /go/src/dsp/vendor/github.com/valyala/fasthttp/server.go:2691 +0x7
context.propagateCancel.func1()
        /usr/local/go/src/context/context.go:280 +0x50
created by context.propagateCancel
        /usr/local/go/src/context/context.go:278 +0x1d0

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 1
Comments: 19 (11 by maintainers)

Commits related to this issue

Don't reset RequestCtx.s RequestCtx's are reused in a server specific pool, so no need to reset it. This fixes a use after reset but when RequestCtx is use as context. Fixes #1205 — committed to valyala/fasthttp by erikdubbelboer 2 years ago
Don't reset RequestCtx.s (#1234) RequestCtx's are reused in a server specific pool, so no need to reset it. This fixes a use after reset but when RequestCtx is use as context. Fixes #1205 — committed to valyala/fasthttp by erikdubbelboer 2 years ago

Most upvoted comments

How about this as a fix?: https://github.com/valyala/fasthttp/pull/1234

erikdubbelboer on Mar 3, 2022

Can confirm with github.com/valyala/fasthttp v1.33.0 // indirect, used by github.com/gofiber/fiber/v2 v2.27.0.

backend_1  | panic: runtime error: invalid memory address or nil pointer dereference
backend_1  | [signal SIGSEGV: segmentation violation code=0x1 addr=0x200 pc=0x881e47]
backend_1  |
backend_1  | goroutine 21135 [running]:
backend_1  | github.com/valyala/fasthttp.(*RequestCtx).Done(0x1097f80)
backend_1  | 	/go/pkg/mod/github.com/valyala/fasthttp@v1.33.0/server.go:2691 +0x7
backend_1  | context.propagateCancel.func1()
backend_1  | 	/usr/local/go/src/context/context.go:280 +0x50
backend_1  | created by context.propagateCancel
backend_1  | 	/usr/local/go/src/context/context.go:278 +0x1d0

GalvinGao on Mar 3, 2022

I can confirm I’m running into the same issue, when reverting back to v1.32.0 it’s all good again.

gzuidhof on Feb 15, 2022

Yes, true, no “context is not released” printed, because the context itself canceled, but context’s WithDeadline internal goroutine which relies on (*requestCtx).Done() chan struct will be instantiated afterwards panicing with nil exception on RequestCtx s *Server field called by Done()…

moredure on Feb 3, 2022

just for your info - no warning is triggered, as you assumed

as I understand it logging “context is not released”, then panics after 500ms

I’m currently downgrating to 1.32, will wait for next release to try. Thanx

Gaudeamus on Feb 3, 2022