bug: yamux Futures leak

[gabrielmer]

When running tests on nwaku and activating dumpPendingFutures from nim-chronos, we noticed that the pending futures grow indefinitely in yamux.

Most of them come from the following line

nim-libp2p/libp2p/muxers/yamux/yamux.nim

Lines 282 to 283 in a60f0c5

	try: # https://github.com/status-im/nim-chronos/issues/516
	discard await race(channel.closedRemotely.wait(), channel.receivedData.wait())

For example

Future[4433822480] with name "AsyncEvent.wait" created at <asyncsync.nim:171> and state = Pending

I see these Futures get created at a really fast pace, and not seeing them getting completed. Even if they do eventually get completed, if we create futures at a faster rate than what it takes to complete them, the pending futures would grow indefinitely.

When using mplex instead, the amount of pending Futures is stable and doesn't grow indefinitely

Version: nim-libp2p 94d93cb

Attaching logs with prints of the pending Futures for both yamux and mplex

logs_yamux.txt
logs_mplex.txt

[lchenut]

I'll summarize here what we discussed in private about this issue:
Both channel.closedRemotely.wait() and channel.receivedData.wait() are Future created just for this specific line.
race await for one Future to be finished. By design all the others unfinished Futures are not cancelled when the first Future is completed. Therefore, each time readOnce is called (and it's frequent) two Futures are created and only one is finished for sure by the end of the procedure.

We can reproduce the problem with the following code (compiling with -d:chronosFutureTracking)

import chronos

when defined(chronosFutureTracking):
  proc dumpChronosInfo() {.async.} =
    while true:
      echo "\n----------- Dumping Chronos Info -----------"
      echo dumpPendingFutures(OnlyPending)
      await sleepAsync(1.seconds)

  asyncSpawn dumpChronosInfo()

proc main() {.async.} =
  while true:
    discard await race(sleepAsync(50.millis()), sleepAsync(10.seconds()))

waitFor(main())

#1171 will fix it. It's probably not a perfect solution. #1175 could help make it better.

[diegomrsantos]

@lchenut thank you for the summary.