The server crashes whenever I set server concurrency bigger than 1

[nicolaenicora]

The server crashes whenever I set server concurrency bigger than 1

srv := &svc{ logger: logger, } frpcServer, err := echo.NewServer(srv, nil, &logger) if err != nil { logger.Fatal().Err(err) } frpcServer.SetConcurrency(2)

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

goroutine 50 [running]:
github.com/loopholelabs/frisbee-go.(*Server).createHandler.func1(0x0)
/Users/GoLib/src/github.com/nnicora/fgrpc/vendor/github.com/loopholelabs/frisbee-go/server.go:245 +0x82
github.com/loopholelabs/frisbee-go.(*Server).handleLimitedPacket.func1(0x0)
/Users/GoLib/src/github.com/nnicora/fgrpc/vendor/github.com/loopholelabs/frisbee-go/server.go:388 +0x34
created by github.com/loopholelabs/frisbee-go.(*Server).handleLimitedPacket in goroutine 35
/Users/GoLib/src/github.com/nnicora/fgrpc/vendor/github.com/loopholelabs/frisbee-go/server.go:395 +0x498
Exiting.
`

Additional context
Debugging the server saw that the packet was nil and the err variable was 'connection closed'.
https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L395

[ShivanshVij]

Okay so the bug seems to be that the p *packet.Packet on line https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L395C14-L395C15 happens to be nil.

p could only have been created here: https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L396 or here: https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L375, and in both places we're checking if err != nil

BUT, if err != nil here: https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L375, we don't return the function and let it continue: https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L378

So, the fix should just be as simple as properly checking if the connection should be closed, and then returning:

	p, err := frisbeeConn.ReadPacket()
	if err != nil {
		_ = frisbeeConn.Close()
		s.onClosed(frisbeeConn, err)
                 return
	}

[ShivanshVij]

This also answers the question of why it only happens when concurrency > 1: https://github.com/loopholelabs/frisbee-go/blob/staging/server.go#L349, when concurrency < 2, we run handleUnlimitedPacket instead, and as you can see that one does call return on an error.

[ShivanshVij]

Closed as part of v0.7.2