Closed jzawodn closed 14 years ago
A co-worker who has looked at this suspects a circular reference error with $reader in anyevent_read_type in the block that starts:
It's not a circular reference "error" - it was intentionally made to reference itself, as a common technique used in AnyEvent. The problem here is that there's no cleanup (undef'ing it) for this $reader handler.
Ahh, ok. That makes sense.
Thanks for the info. I'm still working to wrap my head around AnyEvent-style programming.
Your co-worker is right that this circular ref is the thing that's causing the leak. We could fix it by either a) rewrite it without the circular ref (using the normal method) or b) properly cleanup the reader when 'return' from it.
Pull request submitted with an undef that fixes the case I tickled.
I've just pushed some changes that fix another leak and also added tests for these.
Excellent. Thanks!
0.22 shipped with the changes by dgl
I've been using the latest redis and the latest AnyEvent::Redis to try some simple examples on which I can build a larger daemon process. And I've discovered a memory leak.
I can show a trivial script that runs many GETs with no leak:
http://gist.github.com/653910
and then an almost identical script that uses BLPOP instead:
http://gist.github.com/653912
The second script will leak memory (even though it runs slower because of the timeout in BLPOP).
A co-worker who has looked at this suspects a circular reference error with $reader in anyevent_read_type in the block that starts:
} elsif($hd->{rbuf} =~ /^*/) {
That means lots of other methods are likely affected too. I'm pretty sure I hit this when messing with pubsub as well.