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

SIGSEGV on empty grpc findTraces query #2996

Closed
FauxFaux opened this issue May 15, 2021 · 11 comments · Fixed by #3232
Closed

SIGSEGV on empty grpc findTraces query #2996

FauxFaux opened this issue May 15, 2021 · 11 comments · Fixed by #3232
Assignees
Labels
bug good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement

Comments

@FauxFaux
Copy link

When processing a request for findTraces with no parameters, the server experiences a segmentation fault/segfault.

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

goroutine 29502 [running]:
github.com/jaegertracing/jaeger/cmd/query/app.(*GRPCHandler).FindTraces(0xc006f19060, 0xc006c303c0, 0x1e2bb20, 0xc006c710c0, 0xc006f19060, 0x20)
	github.com/jaegertracing/jaeger/cmd/query/app/grpc_handler.go:88 +0x98
github.com/jaegertracing/jaeger/proto-gen/api_v2._QueryService_FindTraces_Handler(0x14833a0, 0xc006f19060, 0x1e292a0, 0xc006c76000, 0x26d5680, 0xc000274000)
	github.com/jaegertracing/jaeger/proto-gen/api_v2/query.pb.go:994 +0x10b
google.golang.org/grpc.(*Server).processStreamingRPC(0xc00023c340, 0x1e2f7e0, 0xc0004a8300, 0xc000274000, 0xc006f226f0, 0x2687aa0, 0x0, 0x0, 0x0)
	google.golang.org/grpc@v1.29.1/server.go:1329 +0xcd8
google.golang.org/grpc.(*Server).handleStream(0xc00023c340, 0x1e2f7e0, 0xc0004a8300, 0xc000274000, 0x0)
	google.golang.org/grpc@v1.29.1/server.go:1409 +0xc5c
google.golang.org/grpc.(*Server).serveStreams.func1.1(0xc0004c5630, 0xc00023c340, 0x1e2f7e0, 0xc0004a8300, 0xc000274000)
	google.golang.org/grpc@v1.29.1/server.go:746 +0xa5
created by google.golang.org/grpc.(*Server).serveStreams.func1
	google.golang.org/grpc@v1.29.1/server.go:744 +0xa5

To Reproduce

Using the grpc-js generated client from ts-proto, QueryServiceClient: qsc.findTraces({}), i.e. make a request with none of the required parameters populated.

Expected behavior
An error to be returned, and the server to not be down / restart.

Version:

  • OS: Ubuntu
  • Jaeger version: jaegertracing/all-in-one:1.22
  • Deployment: docker-compose
@yurishkuro
Copy link
Member

func (g *GRPCHandler) FindTraces(r *api_v2.FindTracesRequest, stream api_v2.QueryService_FindTracesServer) error

It's very strange that gRPC allows the above handler to be called with r == nil, but I guess it's what we get when everything in the IDL is optional.

@yurishkuro yurishkuro added help wanted Features that maintainers are willing to accept but do not have cycles to implement good first issue Good for beginners labels May 15, 2021
@yurishkuro
Copy link
Member

I think this would also happen with all other API methods since most of them require a request object which could be nil, so the code need to check for that and return an error.

@jeffy-mathew
Copy link
Contributor

Hi, I would like to work on this issue

@yurishkuro
Copy link
Member

It's yours

@jpkrohling
Copy link
Contributor

Wasn't this fixed by #2979 ?

@yurishkuro
Copy link
Member

Wasn't this fixed by #2979 ?

Only FindTraces method was fixed there, we should add this check to all methods.

@akuzni2
Copy link
Contributor

akuzni2 commented Aug 14, 2021

/assign
I'd like to take this up :)

@albertteoh
Copy link
Contributor

Go for it @akuzni2 :)

@akuzni2
Copy link
Contributor

akuzni2 commented Aug 15, 2021

Have a bit of a question on this - should we be checking if the actual client function *Request instances coming into the client are nil or just if any of the exported struct fields might be nil / default struct?

Example:
FindTraces client function requires a r *api_v2.FindTracesRequest argument where FindTracesRequest has a Query *TraceQueryParameters struct field. Should we be verifying that both FindTracesRequest and Query are not nil?

@yurishkuro
Copy link
Member

yes

@akuzni2
Copy link
Contributor

akuzni2 commented Aug 25, 2021

I did create a PR for this issue - had a few questions that I left on the PR submissions. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug good first issue Good for beginners help wanted Features that maintainers are willing to accept but do not have cycles to implement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants