Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Index out of range in (*routeRegexp).Match #742

Open
1 task done
sdewilde opened this issue Nov 29, 2023 · 1 comment
Open
1 task done

[BUG] Index out of range in (*routeRegexp).Match #742

sdewilde opened this issue Nov 29, 2023 · 1 comment
Labels

Comments

@sdewilde
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

Panic is seen (intermittently) when receiving a POST request, the stack trace is entirely out of my client code and the index shown doesn't seem to relate to anything:

2023/11/29 15:01:30 http: panic serving <IP>:<PORT>: runtime error: index out of range [697533342] with length 28
goroutine 1104 [running]:
net/http.(*conn).serve.func1()
        /usr/local/go/src/net/http/server.go:1868 +0xb9
panic({0xb8b020?, 0xc0003fe2d0?})
        /usr/local/go/src/runtime/panic.go:920 +0x270
regexp.(*Regexp).doOnePass(0xc0003580a0, {0x0?, 0x0}, {0x0, 0x0, 0x0}, {0xc000241945, 0x29}, 0x0, 0x0, ...)
        /usr/local/go/src/regexp/exec.go:445 +0x857
regexp.(*Regexp).doExecute(0xfc31f211f3e25e7a?, {0x0?, 0x0?}, {0x0?, 0xc000492000?, 0xc000492088?}, {0xc000241945?, 0x4190fa?}, 0xacc0c0?, 0x0, ...)
        /usr/local/go/src/regexp/exec.go:532 +0x2a8
regexp.(*Regexp).doMatch(...)
        /usr/local/go/src/regexp/exec.go:514
regexp.(*Regexp).MatchString(...)
        /usr/local/go/src/regexp/regexp.go:533
github.com/gorilla/mux.(*routeRegexp).Match(0xc000354b60, 0x10?, 0xc000019998?)
        /go/pkg/mod/github.com/gorilla/mux@v1.8.1/regexp.go:193 +0x12d
github.com/gorilla/mux.(*Route).Match(0xc000349e00, 0xc000482ae0?, 0xc000482ae0)
        /go/pkg/mod/github.com/gorilla/mux@v1.8.1/route.go:50 +0xb9
github.com/gorilla/mux.(*Router).Match(0xc000000300, 0x420368?, 0xc000482ae0)
        /go/pkg/mod/github.com/gorilla/mux@v1.8.1/mux.go:140 +0x6b
github.com/gorilla/mux.(*Router).ServeHTTP(0xc000000300, {0xcc5e98, 0xc0003fc8c0}, 0xc000459c00)
        /go/pkg/mod/github.com/gorilla/mux@v1.8.1/mux.go:198 +0xd9
net/http.serverHandler.ServeHTTP({0xcc4008?}, {0xcc5e98?, 0xc0003fc8c0?}, 0x6?)
        /usr/local/go/src/net/http/server.go:2938 +0x8e
net/http.(*conn).serve(0xc0002ffb90, {0xcc6f30, 0xc0003e2750})
        /usr/local/go/src/net/http/server.go:2009 +0x5f4
created by net/http.(*Server).Serve in goroutine 6
        /usr/local/go/src/net/http/server.go:3086 +0x5cb

In the couple times this has happened the found index and the range are different (Always very large and then twenty something)

Expected Behavior

No panic, the path is valid and defined. The route is even successfully called in many times but occasionally will hit the above issue.

Steps To Reproduce

Running from golang:bullseye docker image linux_x86_64 go1.21.4, using version 1.8.1 of gorilla/mux
The route it's failing on looks like:

router.HandleFunc("/{id}/GetCustomStats", func(rw http.ResponseWriter, r *http.Request) {
...
}

but as you can see from the stack trace it's not even getting to the handler or calling any middleware.

Anything else?

No response

@sdewilde sdewilde added the bug label Nov 29, 2023
@sdewilde
Copy link
Author

I've been looking into this a lot and think it might be something in the regexp onePassProg that is getting corrupted. Capturing this behaviour in delve I was able to see the InstAlt instance had invalid values for it's Next array:
image
From other successful cases, that array should be [4, 6, 4]. I'm curious if something in copyRouteRegexp of mux.go is causing the array to be over-written but I haven't found a nice way to watch when a variable gets changed.
I have been unable to repro this in a small, self-contained example though so I don't have any helpful source code to share yet.
My next step is to force the route to use a back-tracking regex so we skip that one-pass logic in regexp assuming that's the root cause.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Status: No status
Development

No branches or pull requests

1 participant