possible memory leak

[tsachev]

Hi I am using rsocket 0.10.3, netty 4.1.24.Final and reactor Bismuth-SR8, any idea what may cause this?

I see this in my logs

2018-04-20 19:55:57.725 ERROR 25238 --- [server-epoll-15] i.n.u.ResourceLeakDetector               : LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records: 
Created at:
	io.netty.buffer.AbstractByteBufAllocator.compositeDirectBuffer(AbstractByteBufAllocator.java:221)
	io.netty.buffer.AbstractByteBufAllocator.compositeDirectBuffer(AbstractByteBufAllocator.java:216)
	io.netty.buffer.AbstractByteBufAllocator.compositeBuffer(AbstractByteBufAllocator.java:191)
	io.rsocket.transport.netty.WebsocketDuplexConnection.lambda$receive$0(WebsocketDuplexConnection.java:68)
	reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:100)
	reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:108)
	reactor.ipc.netty.channel.FluxReceive.drainReceiver(FluxReceive.java:211)
	reactor.ipc.netty.channel.FluxReceive.onInboundNext(FluxReceive.java:326)
	reactor.ipc.netty.channel.ChannelOperations.onInboundNext(ChannelOperations.java:309)
	reactor.ipc.netty.http.server.HttpServerOperations.onInboundNext(HttpServerOperations.java:415)
	reactor.ipc.netty.http.server.HttpServerWSOperations.onInboundNext(HttpServerWSOperations.java:107)
	reactor.ipc.netty.channel.ChannelOperationsHandler.channelRead(ChannelOperationsHandler.java:134)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
	io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
	io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1434)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
	io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
	io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:965)
	io.netty.channel.epoll.AbstractEpollStreamChannel$EpollStreamUnsafe.epollInReady(AbstractEpollStreamChannel.java:808)
	io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:404)
	io.netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:304)
	io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:884)
	java.base/java.lang.Thread.run(Thread.java:844)

[robertroeser]

How often? Does it happen at few times at the start then goes away or is it persistent? I've seen this happen during the setup, and there is probably something incorrect there.

[smaldini]

I wonder if the snapshot behaves better, @nebhale worked on some ref counting issues.

[tsachev]

@robertroeser not always but often in my understanding. Here are some examples after enabling -Dio.netty.leakDetectionLevel=advanced

https://gist.githubusercontent.com/tsachev/d2929278840fcd21eacc2a8794e4a04b/raw/e205e387ee7d1e5b524f31f0c4d3c0d7c02dd151/gistfile1.txt
https://gist.githubusercontent.com/tsachev/d2929278840fcd21eacc2a8794e4a04b/raw/e205e387ee7d1e5b524f31f0c4d3c0d7c02dd151/gistfile2.txt

[tsachev]

@robertroeser @smaldini ok I tried with the snapshot and it seems that I still can see this happening.
With the snapshot version I can only reproduce this for the setup frame.
The first line in my server socket acceptor is setup.relese(), but it seems that this is not enough. The setup frame must be released too.

If I change the RSocketFactory#processSetupFrame adding
.doFinally(signalType -> setupFrame.release()) like this it works for me.

return wrappedRSocketClient
            .flatMap(
                sender -> acceptor.get().accept(setupPayload, sender).map(plugins::applyServer))
            .map(
                handler ->
                    new RSocketServer(
                        multiplexer.asClientConnection(), handler, frameDecoder, errorConsumer))
            .doFinally(signalType -> setupFrame.release())
            .then()

Is this the right solution? Or the setup frame should be released somehow when the setup payload is released?

[nebhale]

I haven't gotten to all the places there might be a leak so far (specifically around setup), so there could certainly be some more lurking in there. I'll keep working at it, but even with Netty's diagnostics, it's often quite difficult to find. I don't think I can go in surgically and fix this (it's quite difficult to find these things even with Netty's diagnostics) so it might just have to get taken care of as I gradually make changes and improve code.

[OlegDokuka]

closing since there is no activity and most likely this issue is already fixed