bug: panic, nil pointer dereference in Stdio readResponses #358
Description
Description
I need some help with a panic issue when using the stdio MCP client.
I encountered the following panic
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0x5c27bd]
goroutine 27837 [running]:
bufio.(*Reader).ReadSlice(0x0, 0xa)
/usr/local/go/src/bufio/bufio.go:355 +0x3d
bufio.(*Reader).collectFragments(0x0, 0xa)
/usr/local/go/src/bufio/bufio.go:455 +0x70
bufio.(*Reader).ReadString(0x0?, 0x0?)
/usr/local/go/src/bufio/bufio.go:502 +0x1f
github.com/mark3labs/mcp-go/client/transport.(*Stdio).readResponses(0xc000f40240)
/Users/xanarry/go/pkg/mod/github.com/mark3labs/mcp-go@v0.29.0/client/transport/stdio.go:170 +0x53
github.com/mark3labs/mcp-go/client/transport.(*Stdio).Start.func1()
/Users/xanarry/go/pkg/mod/github.com/mark3labs/mcp-go@v0.29.0/client/transport/stdio.go:79 +0x2f
created by github.com/mark3labs/mcp-go/client/transport.(*Stdio).Start in goroutine 27955
/Users/xanarry/go/pkg/mod/github.com/mark3labs/mcp-go@v0.29.0/client/transport/stdio.go:77 +0x8c
my mcp-go version is v0.29.0
I have checked my own code and the MCP client initialization logic, but I couldn't find any obvious reason for c.stdout to be nil at this point. My guess is that this happens when the MCP server subprocess exits unexpectedly, and the client tries to read from a closed or nil pipe.
Should there be a panic recovery or more defensive check in the readResponses goroutine to avoid crashing the whole process?
Or is there any recommended way to handle this scenario gracefully?
Any advice or fix would be appreciated. Thank you!