in reply to Memory leak detection

Howdy and welcome to the Monastery, runnerup! Can you show us your server's code? It's a bit difficult to diagnose memory leaks without being able to see the leaking program, as I'm sure you'll agree.

Replies are listed 'Best First'.
Re^2: Memory leak detection
by runnerup (Novice) on Sep 07, 2014 at 15:55 UTC
    The code itself is over 2000 lines, so I think it would be difficult to post or analyze.
    However, my question is actually how can ARENA COUNTS show
    69084 REF-Tie::RefHash::Weak

    when all the adding all the scalar(keys %HASHS) of all the hashes using Tie::RefHash::Weak, scalar(keys %EACHHASH) added together is much much less than 69084.
    Is there any common case that can happen?
    I am deleting the keys like delete($hash($key)).
    All the keys are to Danga::Socket::GCallback, so there should be no circular references possible.
[reply]
      However, my question is actually how can ARENA COUNTS show 69084 REF-Tie::RefHash::Weak when all the adding all the scalar(keys %HASHS) of all the hashes using Tie::RefHash::Weak, scalar(keys %EACHHASH) added together is much much less than 69084.

      That is why they call it "memory leak" :) The "arena" goes through internal perl structures to see which structures are allocated. As long as variable is accessible from the user code, it is "good" structure. The problem comes, when the structure is not accessible from user code. This structure is then "leaked". So, if you have a leak, then you won't be able to see leaked structures from your perl code. Of course in this case your count won't match the count of "arena".

[reply]
        Other than cyclic references (which I don't think could exist in my code), do you know what could cause this to happen?
        I would think that if the reference count is 0, that the objects would be deleted.
        What approach should I use to find the problem?
[reply]

In Section Seekers of Perl Wisdom