vesoft-inc/nebula-go

panic when get data from graph

m20082008m opened this issue · 5 comments

panic: runtime error: slice bounds out of range [:8192] with capacity 4096

goroutine 44 [running]:
bufio.(*Reader).Read(0xc0000323c0, 0xc000032474, 0x4, 0x4, 0x300000002, 0xc000082c00, 0xc000852e00)
        /usr/local/go/src/bufio/bufio.go:238 +0x3ba
io.ReadAtLeast(0x10060a0, 0xc0000323c0, 0xc000032474, 0x4, 0x4, 0x4, 0x74, 0xc000852e60, 0x4dadb2)
        /usr/local/go/src/io/io.go:328 +0x87
io.ReadFull(...)
        /usr/local/go/src/io/io.go:347
github.com/facebook/fbthrift/thrift/lib/go/thrift.(*FramedTransport).readFrameHeader(0xc000032420, 0x0, 0x7, 0x0)
        /go/pkg/mod/github.com/facebook/fbthrift@v0.31.1-0.20210223140454-614a73a42488/thrift/lib/go/thrift/framed_transport.go:154 +0x74
github.com/facebook/fbthrift/thrift/lib/go/thrift.(*FramedTransport).Read(0xc000032420, 0xc00016c0d2, 0x4, 0x40, 0xc00015e080, 0xc000548000, 0x74)
        /go/pkg/mod/github.com/facebook/fbthrift@v0.31.1-0.20210223140454-614a73a42488/thrift/lib/go/thrift/framed_transport.go:80 +0x2ff
io.ReadAtLeast(0x7f62e2dc8150, 0xc000032420, 0xc00016c0d2, 0x4, 0x40, 0x4, 0x74, 0x20000, 0x74)
        /usr/local/go/src/io/io.go:328 +0x87
io.ReadFull(...)
        /usr/local/go/src/io/io.go:347
github.com/facebook/fbthrift/thrift/lib/go/thrift.(*BinaryProtocol).readAll(0xc00016c090, 0xc00016c0d2, 0x4, 0x40, 0xc000548000, 0x74)
        /go/pkg/mod/github.com/facebook/fbthrift@v0.31.1-0.20210223140454-614a73a42488/thrift/lib/go/thrift/binary_protocol.go:494 +0x5f
github.com/facebook/fbthrift/thrift/lib/go/thrift.(*BinaryProtocol).ReadI32(0xc00016c090, 0x0, 0xec9160, 0x7f62e2fec008)
        /go/pkg/mod/github.com/facebook/fbthrift@v0.31.1-0.20210223140454-614a73a42488/thrift/lib/go/thrift/binary_protocol.go:424 +0x48
github.com/facebook/fbthrift/thrift/lib/go/thrift.(*BinaryProtocol).ReadMessageBegin(0xc00016c090, 0x18, 0x18, 0xe1ebc0, 0x0, 0x0)
        /go/pkg/mod/github.com/facebook/fbthrift@v0.31.1-0.20210223140454-614a73a42488/thrift/lib/go/thrift/binary_protocol.go:241 +0x2f
github.com/facebook/fbthrift/thrift/lib/go/thrift.(*ClientConn).RecvMsg(0xc000032490, 0xeec85a, 0x7, 0x1006aa0, 0xc00000c3a8, 0x0, 0x0)
        /go/pkg/mod/github.com/facebook/fbthrift@v0.31.1-0.20210223140454-614a73a42488/thrift/lib/go/thrift/clientconn.go:104 +0x4c
github.com/vesoft-inc/nebula-go/v2/nebula/graph.(*GraphServiceClient).recvExecute(0xc000032480, 0xeec85a, 0x7, 0x1006a40)
        /go/pkg/mod/github.com/vesoft-inc/nebula-go/v2@v2.6.0/nebula/graph/graphservice.go:146 +0x75
github.com/vesoft-inc/nebula-go/v2/nebula/graph.(*GraphServiceClient).Execute(0xc000032480, 0x5d55d3e5f78c2, 0xc0000ae0f0, 0x4a, 0x50, 0x50, 0x5f, 0x0)
        /go/pkg/mod/github.com/vesoft-inc/nebula-go/v2@v2.6.0/nebula/graph/graphservice.go:140 +0x10d
github.com/vesoft-inc/nebula-go/v2.(*connection).execute(0xc000116000, 0x5d55d3e5f78c2, 0xc0000ae050, 0x4a, 0xc06fbea7a74b3b37, 0x4b, 0xc00012f680)
        /go/pkg/mod/github.com/vesoft-inc/nebula-go/v2@v2.6.0/connection.go:111 +0x7f
github.com/vesoft-inc/nebula-go/v2.(*Session).Execute(0xc0000760f0, 0xc0000ae050, 0x4a, 0xc0008533c0, 0x40db9b, 0xc00063a720)
        /go/pkg/mod/github.com/vesoft-inc/nebula-go/v2@v2.6.0/session.go:35 +0x74`

I found the same panic from golang/go#42289, but I don't know it's the same and how to solve

@Aiee any clue on this please?

Aiee commented

What's the version of the nebula service? And what's the query causing this panic?

vesoft/nebula-storaged v2.6.1 91e099fabc72 2 months ago 283MB
vesoft/nebula-graphd v2.6.1 b82a5802a080 2 months ago 277MB
vesoft/nebula-metad v2.6.1 853952de4626 2 months ago 282MB
vesoft/nebula-graph-studio v3.1.0 a7a569d71a6f 2 months ago 373MB
vesoft/nebula-http-gateway v2.1.1 5e35c5b1b664 2 months ago 826MB

image version i used

ther query i used only
FETCH PROP ON * 'xxx' yield id($$)
when i request about 100 concurrently, return that panic

o, i see
i share global session for 100 request, if i new one session for one request, no panic

Aiee commented

The connectionPool is thread-safe while the session is not. If you intend to use multiple threads, you could use multiple threads to request sessions from the connection pool, and always use the same session within the same thread.