Cleaning Up on Edit from Perl

Stas Bekman stas at stason.org
Wed Jun 11 21:34:34 CDT 2003


Somebody, please send an XXX-large coffee pack to the IBM Centre.

My apologies to Scott, I have to drink my coffee before starting to answer 
emails. Apparently I have quoted what Scott has quoted :(

Stas Bekman wrote:
> Scott Penrose wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>>
>> On Wednesday, Jun 11, 2003, at 09:39 Australia/Melbourne, Stas Bekman  
>> wrote:
>>
>>> The mod_perl guide comes to help:
>>> http://perl.apache.org/docs/1.0/guide/ 
>>> troubleshooting.html#_warn__child_process_30388_did_not_exit__sending_a 
>>> nother_SIGHUP
>>>
>>> PERL_DESTRUCT_LEVEL=-1 perl my_heavy_destruct_program
>>
>>
>>
>> On exploring this further I have discovered that this only works for  
>> mod_perl....
>>
>>  From perlhack
>>
>>> if you want to run any of the tests yourself manually using the  
>>> pureperl or perl.third executables, please note that by default perl  
>>> does not explicitly cleanup all the memory it has allocated (such as  
>>> global memory arenas) but instead lets the exit() of the whole 
>>> program  "take care" of such allocations, also known as "global 
>>> destruction of  objects".
>>>
>>> There is a way to tell perl to do complete cleanup: set the  
>>> environment variable PERL_DESTRUCT_LEVEL to a non-zero value. The  
>>> t/TEST wrapper does set this to 2, and this is what you need to do  
>>> too, if you don't want to see the "global leaks": For example, for  
>>> "third-degreed" Perl:
>>> (Note: the mod_perl apache module uses also this environment 
>>> variable  for its own purposes and extended its semantics. Refer to 
>>> the mod_perl  documentation for more information.)
>>
>>
>>
>> Note the last part - It seems that mod_perl has extended to support 
>> the  - -1.
>>
>> For now I am going with the following approach.
>>
>>     kill 9, $$;
> 
> 
> Indeed. perlhack.pod says:
> 
> =head2 PERL_DESTRUCT_LEVEL
> 
> If you want to run any of the tests yourself manually using the
> pureperl or perl.third executables, please note that by default
> perl B<does not> explicitly cleanup all the memory it has allocated
> (such as global memory arenas) but instead lets the exit() of
> the whole program "take care" of such allocations, also known
> as "global destruction of objects".
> 
> There is a way to tell perl to do complete cleanup: set the
> environment variable PERL_DESTRUCT_LEVEL to a non-zero value.
> The t/TEST wrapper does set this to 2, and this is what you
> need to do too, if you don't want to see the "global leaks":
> For example, for "third-degreed" Perl:
> 
>     env PERL_DESTRUCT_LEVEL=2 ./perl.third -Ilib t/foo/bar.t
> 
> (Note: the mod_perl apache module uses also this environment variable
> for its own purposes and extended its semantics. Refer to the mod_perl
> documentation for more information. Also, spawned threads do the
> equivalent of setting this variable to the value 1.)
> 
> If, at the end of a run you get the message I<N scalars leaked>, you can
> recompile with C<-DDEBUG_LEAKING_SCALARS>, which will cause
> the addresses of all those leaked SVs to be dumped; it also converts
> C<new_SV()> from a macro into a real function, so you can use your
> favourite debugger to discover where those pesky SVs were allocated.
> 
> 
> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/     mod_perl Guide ---> http://perl.apache.org
> mailto:stas at stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org   http://ticketmaster.com


-- 


__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas at stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com




More information about the Melbourne-pm mailing list