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
I was playing around building different middleware chains on the fly. I was using a slice: middleware vestigo.Middleware[]
for that purpose. This sometimes resulted in a crash with nil pointer dereference / invalid memory access. I traced it back to a function in 'router.go' in the vestigo package:
func buildChain(f http.HandlerFunc, m ...Middleware) http.HandlerFunc {
// if our chain is done, use the original handlerfunc
if len(m) == 0 {
return f
}
// otherwise nest the handlerfuncs
return m[0](buildChain(f, m[1:cap(m)]...))
}
I replaced the line return m[0](buildChain(f, m[1:cap(m)]...))
with return m[0](buildChain(f, m[1:len(m)]...))
on my local sources, now everything is fine. I was wondering why you were using cap here at any rate? Wouldn't using 'len' be safer?
The text was updated successfully, but these errors were encountered:
tw1nk
added a commit
to tw1nk/vestigo
that referenced
this issue
Nov 27, 2018
Hi
I was playing around building different middleware chains on the fly. I was using a slice:
middleware vestigo.Middleware[]
for that purpose. This sometimes resulted in a crash with nil pointer dereference / invalid memory access. I traced it back to a function in 'router.go' in the vestigo package:
I replaced the line
return m[0](buildChain(f, m[1:cap(m)]...))
with
return m[0](buildChain(f, m[1:len(m)]...))
on my local sources, now everything is fine. I was wondering why you were using cap here at any rate? Wouldn't using 'len' be safer?
The text was updated successfully, but these errors were encountered: