Unclosed reader in github.com/libp2p/go-libp2p-pubsub.(*PubSub).handleNewStream

[prestonvanloon]

trafficstars

This ReaderCloser is never closed. We are seeing high memory usage on the heap from this line and I suspect it is because r.Close() is never called.

https://github.com/libp2p/go-libp2p-pubsub/blob/49274b0e8aecdf6cad59d768e5702ff00aa48488/comm.go#L33

[prestonvanloon]

I think the closer for this reader is just the closer of the underlying stream, but there are branches which the closer is not called.

Why not add defer r.Close() after opening the reader?

[raulk]

@vyzo is looking into this right now!

[vyzo]

The stream is properly clsoed or reset in all branches.

There is a test here: https://github.com/libp2p/go-libp2p-pubsub/blob/49274b0e8aecdf6cad59d768e5702ff00aa48488/comm.go#L38 If it is EOF then we can Close write and be done, in the other two cases the stream is Reset.

Note that defer Close() is not sufficient, as we may need to Reset in abnormal termination cases.

[bruinxs]

I think this part of the logic does have problems. One of my services introduced go-ipfs. It runs for a while (sometimes, sometimes two hours) and throws out of menery to exit abnormally.

I don't know why it is like this now, but I suspect it is because stream is never called.

[Stebalien]

Can you pull a goroutine dump? You should see a tone of handlePeerEOF and/or handleSendingMessages goroutines.