John Peacock wrote:
Stas Bekman wrote:
Every time I need to resolve a leaked scalar problem, I spend hours
trying to guess where could it possibly come from. Now add to that
problem the fun of randomness, where sometimes the leaked scalar is
happening every 10th run or so, so it's litterally improssible to debug
this.
I feel your pain. When I was developing the version objects in the core, I
had a persistent leak when I did something particular (the details of which
escape me now). And yes, the bugger of it was that by the time Perl
noticed
that this scalar is going to leak, it has already deallocated pretty much
everything from the scalar except the reference count, so there was nothing
to
examine.
I did have some luck, I recall, when I would notice that the same memory
address was the same. I would manually insert an sv_dump() in the Perl
source
code, hoping to catch whatever it was that was allocating this thing.
Unfortunately in my case, the scalar usually contained an RV, so I would
still
have no idea what was going on. It would be vastly useful to extend the
C-level dumping code to have an sv_rdump which would be a recursive dump
(ala
Devel::Peek) which could reveal what was really contained in that scalar.
This would be incredibly useful to examine hashes and arrays, too, at the
C-level.
It's still not going to be easy to track these little buggers down, because
by
the time Perl can tell that a scalar is going to leak, it has already
leaked
(i.e. the information contained within the scalar is mostly gone). Perhaps
a
new Perl level sub within Devel::Peek could be added which would take a
memory
address and dump the contents. You could add this line to an END block and
see if you can catch the scalar /in situ/ before anything has been actually
deallocated. Of course, the act of adding that code will disturb the
memory
allocation, so there might be a couple of iterations before you figure out
what the correct memory address is to dump the leaker.
<DUMB IDEA>
How about a debugging routine one could call at the end of a program which
would fork, let the child process exit, then look up the bad SV info it
gets from the child's STDERR in its own state?
The parent process is a dupe of the child, of course, but hasn't exited
yet, so the bad SV should still be findable.
This assumes a platform with a "real" fork, of course.
</DUMB IDEA>
Just a thought...
--
Mike Giroux
