help with stacktrace

[elij]

A user of one of an http proxy[1] that I wrote reported this stack
trace:

2014/05/26 14:03:20 http: panic serving 141.101.96.59:21920: runtime
error: slice bounds out of range
goroutine 437 [running]:
net/http.func·009()
/usr/lib/go/src/pkg/net/http/server.go:1093 +0xae
runtime.panic(0x657800, 0x95af4a)
/usr/lib/go/src/pkg/runtime/panic.c:248 +0x106
github.com/cactus/go-camo/camo.(*Proxy).ServeHTTP(0xc210051400,
0x7fa83d0c9720, 0xc210623000, 0xc2105e1a90)
/root/go-camo/build/src/github.com/cactus/go-camo/camo/proxy.go:196
+0x1b25
github.com/gorilla/mux.(*Router).ServeHTTP(0xc21000a550, 0x7fa83d0c9720,
0xc210623000, 0xc2105e1a90)
/root/go-camo/build/src/github.com/gorilla/mux/mux.go:98 +0x217
net/http.(*ServeMux).ServeHTTP(0xc2100376c0, 0x7fa83d0c9720,
0xc210623000, 0xc2105e1a90)
/usr/lib/go/src/pkg/net/http/server.go:1496 +0x163
net/http.serverHandler.ServeHTTP(0xc21000a1e0, 0x7fa83d0c9720,
0xc210623000, 0xc2105e1a90)
/usr/lib/go/src/pkg/net/http/server.go:1597 +0x16e
net/http.(*conn).serve(0xc2105f7180)
/usr/lib/go/src/pkg/net/http/server.go:1167 +0x7b7
created by net/http.(*Server).Serve
/usr/lib/go/src/pkg/net/http/server.go:1644 +0x28b

The user is running go1.2.1, gc-amd64 on some flavor of Linux.

The first line of the trace points here:
http://golang.org/src/pkg/net/http/server.go?s=45646:46651#L1093
Is the const on line 1091 not large enough for whatever triggered the
panic in the first place?

[1]: https://github.com/cactus/go-camo

[Dave Cheney]

I think the logic ~ line 196 is wrong. if ok is false, then the type of ct will be []string and its value will be nil, so ct[0] generates a slice out of bounds exception.

                ct, ok := resp.Header[http.CanonicalHeaderKey("content-type")]
                if !ok || ct[0][:6] != "image/" {

[eli.j...@upsight.com]

Ah. The conditional logic is sound (short circuit or), but I think the content of the response header in some cases not be long enough.

example: http://play.golang.org/p/i2mgwvyVDL

If the header response was "nope" for instance, instead of "image/png", the c[0][:6] would not have enough chars in it. Instead of that manual compare I will do a prefix check.

Thanks Dave!

[Dave Cheney]

Sorry. I think I was mistaken, what is more likely is that there is a content-type header, but it either has 0 elements or the value is less than 6 characters. Replacing the line with

if !ok || !strings.HasPrefix(ct[0], "image/") {

Might fix the issue.