32 bytes leaked by tr_threadNew()

[tiennou]

leaks reports : Call stack: [thread 0x100e81000]: | thread_start | _pthread_start | libeventThreadFunc | event_base_loop | readFromPipe | tr_sessionInitImpl | tr_dhtInit | tr_threadNew | calloc | malloc_zone_calloc

It is caused by the tr_threadNew call in tr-dht.c:389, since we're not storing the return anywere. I imagine since this is for bootstrapping, as soon the thread exits it will be reclaimed, but I'm filing anyway ;-)

[charles]

possible fix

[charles]

tiennou: could you please test this diff and see if it resolves the issue for you? valgrind isn't reporting this as a leak for some reason...

[tiennou]

I'll test… I got another one from, but your fix will do for both :

Call stack: [thread 0x7fff7040dbe0]: | start | main | NSApplicationMain | +[NSBundle(NSNibLoading) loadNibNamed:owner:] | +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] | loadNib | -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] | -[NSSet makeObjectsPerformSelector:] | -[Controller awakeFromNib] | -[Torrent initWithHistory:lib:forcePause:] | -[Torrent startTransfer] | torrentStart | tr_verifyAdd | tr_threadNew | calloc | malloc_zone_calloc

[charles]

tiennou: what did your tests find?

[tiennou]

I'm no longer seeing the tr_thread leaking after a verification completes with the patch applied (much easier to check than waiting for DHT to bootstrap).

[charles]

IMO this ticket should be done post-1.80. 32 bytes is very little reward compared to the relatively high risk of messing with the threading code...

[charles]

Fixed in trunk for 1.81 by r9987