ndnd has a memory leak.

[haowaiwai]

I observed through pprof that two areas are continuously growing in memory usage:

291.04MB  36.24% 36.24%   331.54MB  41.28%  github.com/named-data/ndnd/std/utils/io.ReadTlvStream  
168.89MB  21.03% 57.26%   168.89MB  21.03%  github.com/named-data/ndnd/fw/face.(*linkServiceBase).makeLinkServiceBase (inline)  

I suspect there is a memory leak here:

291.04MB   291.04MB     17:	recvBuf := make([]byte, ndn.MaxNDNPacketSize*8)  
168.39MB   168.39MB     97:	l.sendQueue = make(chan dispatch.OutPkt, CfgFaceQueueSize())  

[zjkmxy]

makeLinkServiceBase

A LinkService is supposed to be created upon face creation. If this becomes a leak, I think the face is not properly closed after use.
Which transport did you use to connect to NDND?

ReadTlvStream

Similarly, this is supposed to be freed after face shut down.

[haowaiwai]

Our application scenario is:
APP → NDND1 → TCP FACE → NDND2 → APP.
We noticed that the memory usage of NDND1 keeps increasing.

[haowaiwai]

Our application scenario involves two NDN faces that are continuously connected, sending and receiving NDN data.

[haowaiwai]

May I ask if this issue will be addressed? If the face is not properly closed, memory usage continues to grow, which seems unreasonable.

[zjkmxy]

May I ask if this issue will be addressed? If the face is not properly closed, memory usage continues to grow, which seems unreasonable.

Sorry the time of both maintainers are very limited now... I will have a look ASAP.

[zjkmxy]

In the mean time, could you please attach the generated pprof file if possible? That may help me debug.

[zjkmxy]

After some investigation, I think the issue is related to CS.

The trace when I set CS = 1024 (default)

The trace when I set CS = 1 (almost disabled)

We can see that the two growing parts are directly related to the capacity of CS.

So the conclusion:

• The issue is that PIT-CS table is supposed to copy the bytes of the packet. However, it keeps the reference of the buffer of the transport face, which leads to a waste of memory.
• This is not a "real" memory-leak, since it will not increase infinitely. Before a fix is published (We will do ASAP), please reduce CS capacity if you have concerns.