in reply to Mark-and-sweep-like mechanism to verify refcount integrity

I'm not exactly sure that the "correctness" of a refcount can be determined, as one would have to scan all memory available to Perl for references to the SV in question, and even then the memory pointing to it might not be in use anymore.

What I think should be feasible would be a (tree-structured?) dump of all memory references/SVs, together with their reference count. Then you can liberally sprinkle those calls to the dumper around and see where there is change in the tree when there should be none. On the other hand, the signal to noise ratio here is pretty bad I guess, as pretty much every op allocates or deallocates memory...

I guess that the only other recourse would be valgrind or another memory bounds checker, but I'm not sure if they (can) catch and diagnose double frees via refcount mess-ups. Maybe you can trick Perl into not reusing existing SVs, so you then get a real leak or a real access violation?

I have never done any of this, and the only thing possible without any too deep XS magic seems to me the tree dump, courtesy of Scalar::Util and PadWalker, and the output of that won't necessarily be helpfull...

  • Comment on Re: Mark-and-sweep-like mechanism to verify refcount integrity

Replies are listed 'Best First'.
Re^2: Mark-and-sweep-like mechanism to verify refcount integrity
by Anonymous Monk on Oct 04, 2004 at 15:54 UTC
    While valgrind is an excellent tools to check whether perl itself has any memory related problems, it won't help at all for debugging Perl programs. valgrind sits between perl and the OS (roughly speaking) and checks memory access with respect to malloc()ed and free()d memory. valgrind doesn't know the difference between an SV and a hole in the ground.