Understanding an address sanitizer message for a memory leak caused by global dispatcher (?)

[Isofruit]

Hello everybody, I am still working on threadButler and based on suggestions 
from mratsim and leorize am starting to take a look at it through various tools 
to look for memory leaks etc.

I am currently trying to wrap my head around using [address 
sanitizers](https://github.com/google/sanitizers/wiki/AddressSanitizer#using-addresssanitizer)
 which should help with figuring out some memory things (another is 
valgrind/heaptrack).

I am... unsure how to interpret some of the messages so I would like to ask for 
some interpretation help here, as this seems to go _far_ deeper than I have any 
level of insight to.

#### Setup

I had an [example 
ready](https://github.com/PhilippMDoerner/ThreadButler/blob/add-loonyqueue-support/examples/ex_stdinput.nim)
 and ran it with:

`nim r --cc:clang --mm:arc -d:release --debugger:native -d:useMalloc 
--passc:-fsanitize=address --passl:-fsanitize=address examples/ex_stdinput.nim`

#### Output

The biggest memory leak
    
    
    Indirect leak of 57352 byte(s) in 1 object(s) allocated from:
        #0 0x55c1436e1de1 in __interceptor_calloc 
(/home/philipp/.cache/nim/ex_stdinput_r/ex_stdinput_DD41B6791D32A0B925C6208AC76777EEE30185AD+0x116de1)
 (BuildId: e7b10045252e22912e59f7086d94388eca9eb9eb)
        #1 0x55c143733a35 in newSeqPayload 
/home/philipp/.choosenim/toolchains/nim-2.0.2/lib/system/seqs_v2.nim:44:767
        #2 0x55c14373d8f4 in newSeq__pureZasyncdispatch_u1664 
/home/philipp/.choosenim/toolchains/nim-2.0.2/lib/system/seqs_v2.nim:140:2
        #3 0x55c14373d8f4 in newSeq__pureZasyncdispatch_u1660 
/home/philipp/.choosenim/toolchains/nim-2.0.2/lib/system.nim:631:2
        #4 0x55c143754462 in newSelector__pureZasyncdispatch_u1639 
/home/philipp/.choosenim/toolchains/nim-2.0.2/lib/pure/ioselects/ioselectors_epoll.nim:101:196
        #5 0x55c143759bf1 in newDispatcher__pureZasyncdispatch_u1634 
/home/philipp/.choosenim/toolchains/nim-2.0.2/lib/pure/asyncdispatch.nim:1209:23
        #6 0x55c143758ee8 in getGlobalDispatcher__pureZasyncdispatch_u2349 
/home/philipp/.choosenim/toolchains/nim-2.0.2/lib/pure/asyncdispatch.nim:1237:39
        #7 0x55c143777f97 in serverProc__ex95stdinput_u2576 
/home/philipp/dev/threadbutler/src/threadButler.nim:72:2
    
    
    Run

Now I am mildly confused by this output. It refers to line 72 of my own 
threadButler.nim doing... _something_ that causes a leak.

The code it refers to is this (line 72 can be found at the bottom of the 
codeblock):
    
    
    proc runServerLoop[Msg](data: Server[Msg]) {.gcsafe.} =
      mixin routeMessage
      
      while IS_RUNNING:
        var msg: Option[Msg] = data.hub.readMsg(Msg)
        try:
          while msg.isSome():
            {.gcsafe.}:
              routeMessage(msg.get(), data.hub)
            
            msg = data.hub.readMsg(Msg)
        
        except KillError:
          break
        
        except CatchableError as e:
          error "Message caused exception", msg = msg.get()[], error = e.repr
        
        if hasPendingOperations():
          poll(0)
        else:
          sleep(data.sleepMs)
    
    proc serverProc*[Msg](data: Server[Msg]) {.gcsafe.} =
      mixin runServerLoop
      data.startUp.execEvents()
      
      runServerLoop[Msg](data) ## This is line 72
      
      data.shutDown.execEvents()
    
    
    Run

#### My current understanding

My guess is that the nim-compiler saw the `poll` call in `runServer` and 
implicitly called `getGlobalDispatcher` which implicitly spawned said global 
dispatcher which somehow causes a memory leak.

Based on that my questions:

  * 1 Is this _actually_ a leak or is this an unavoidable false positive where 
one should just tell address sanitizer [somehow to ignore 
it](https://github.com/google/sanitizers/wiki/AddressSanitizer#turning-off-instrumentation)?
  * 2 If it is a leak, what is supposed to be done here?