Mailing List Archive

: > What is bothering me, however, is that purify did not notice this memory leak
: > as a memory leak, and instead just reported the memory allocation failure
: > without pointing to the individual actual leak..
: >
: > Why is this? And are there lots more leaks like this? And has
: > anybody used a different memory detection package on perl -- like 'Insight'?

This leak isn't really a leak until you try to do global destruction.
And Perl tries to avoid doing global destruction if possible.

Perl uses its own allocator for SVs, so this can hide some kinds of
leaks. You can compile with -DPURIFY to check for leaks, but then
global destruction doesn't take place and some regression tests fail.

Actually, in my copy I can just setenv PERL_DESTRUCT_LEVEL to force
global destruction...

Larry

On Thu, 26 Oct 1995 12:52:39 PDT, Larry Wall wrote:
>: >
>: > Why is this? And are there lots more leaks like this? And has
>: > anybody used a different memory detection package on perl -- like 'Insight'?
>
>This leak isn't really a leak until you try to do global destruction.
>And Perl tries to avoid doing global destruction if possible.
>
>Perl uses its own allocator for SVs, so this can hide some kinds of
>leaks. You can compile with -DPURIFY to check for leaks, but then
>global destruction doesn't take place and some regression tests fail.

I had occurred to me (when I was chasing an obscure bug) that the SV
allocater code is very fallible if the same SV * gets del_SV()-ed twice. We
should probably maintain a flag in the SV (when compiled with -DDEBUGGING)
that marks it as already deleted, so that we can catch it if it arrives once
again later.

- Sarathy.
gsar@engin.umich.edu