mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

fix memory leak

Browse source 
I'm unsure why this fixed it, but it did. Seems to suggest that the
memory leak is not due to a bug in my code, but that ghc didn't manage
to take full advantage of laziness, or was failing to gc something it
could have.
This commit is contained in:
Joey Hess 2016-12-08 18:26:03 -04:00
parent 095593a9af
commit 0f4ee4f298
No known key found for this signature in database
GPG key ID: C910D9222512E3C7
3 changed files with 20 additions and 38 deletions
Download patch file Download diff file Expand all files Collapse all files

22
doc/todo/tor.mdwn
View file

@ -4,28 +4,6 @@ Mostly working!
Current todo list:
* copy --to peer of a 100 mb file causes the memory of the remotedaemon
to creep up from 40 mb to 136 mb. Once the transfer is done, the
remotedaemon continues using all that memory. Memory leak. Profile it.
(The sending process creeps up some initially, but stops at 45 mb used.
That could just be buffering.)
(copy --from peer does not leak on either end; the remotedaemon uses 34
mb and the receiver 44 mb.)
Profiling results: Leak is in hGetMetered, or perhaps in
the consumer of the data it reads. Graph shows `ARR_WORDS` is
the type; that must be a bytestring.
<pre> individual inherited
COST CENTRE MODULE no. entries %time %alloc %time %alloc
tryNonAsync Utility.Exception 3241 0 0.0 0.1 49.3 65.8
receiveExactly P2P.IO 3429 0 0.0 0.0 49.3 65.7
hGetMetered Utility.Metered 3430 0 49.1 65.6 49.3 65.7
</pre>
Switching to L.hGet, it still leaks, so seems hGetMetered is not at fault
and the bytestring is being buffered excessively somehow.
* When a transfer can't be done because another transfer of the same
object is already in progress, the message about this is output by the
remotedaemon --debug, but not forwarded to the peer, which shows