[Proposal] Keep information about the class/method that released the buffer

From time to time you get this notorious IllegalReferenceCountException which basically means that you released the same buffer twice.

It can be a real pain in the neck to track down the method which released this particular buffer. It’s especially painful if you have a quite large pipeline and you’re juggling with ByteBuf instances back and forth.

The exception itself tells only two things:

1. The buffer was already released (i.e. its reference counter is zero)
2. The actual stack trace which shows you which method and in which class called the ByteBuf::release method

It would be great if Netty could keep some information about the caller in the ByteBuf instances. So when you call the ByteBuf::release method and see that the reference counter is zero, you could attach this information to the exception message and a user would know who released this particular buffer earlier.

I think it would simplify the debugging process a little bit. At the moment it can often be impossible to understand who released the buffer without knowing this additional information about the previous caller.

Reflection.getCallerClass() or something similar should do the trick. This feature can also be implemented as a special type of ByteBuf which can only be enabled with some startup option (like a memory leak detector). Because it’ll definitely be very costly to use this feature all the time, I think.

WDYT?

[Scottmitch]

This request sounds different than io.netty.util.ResourceLeakDetector. Instead of detecting things that aren’t released (what io.netty.util.ResourceLeakDetector tries to do) this is requesting tracking call stack information when a buffer is actually released to help debug “double release” scenarios.

As you indicated I think the challenge here is balancing overhead introduced by the additional tracking and potential API impacts. Do we retain a field in each object and increase the memory footprint of each object (even if we are not “tracking” would we still have an additional member variable to track)? Do we sample like we do for ref counting … what if your object wasn’t sampled do we offer a mode to track all deallocations? How common is this in practice and is it worth the additional work/overhead to track this?

[maseev]

On second thought, I think it would be a good idea to share this feature. I’ll create a PR soon.