perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <go...@ectoplasm.org>
Subject Re: Apache::PerlRun - Constant subroutine redefined
Date Fri, 22 Oct 2004 20:53:21 GMT
David Radunz wrote:

>Philippe I know your buisy with mod_perl 2 stuff at the moment, but I
>hope you get a chance to look at this when your free - unless the author
>of the code is someone else and you just recommended it?
>  
>
Oh, no, I am the author of this code, and I am indeed busy with mod_perl 
2 stuff, but
that's not a good reason for having waited so long to follow up on this 
issue.

I think that you have just uncovered a small bug in the unload_package() 
implementation
and I'd like to know exactly how you've reproduced this. After looking 
over code, it is
now clear to me that any namespace entry that has a name <= 2 characters 
long (e.g 'qs')
will not be deleted. That's a bug, and I expect to have it fixed both in 
mp2 and in Devel::Unload
soon.

I'll let you know when there is another version of Devel::Unload you can 
try out. In the meantime,
could you please give me more information about how you have tested 
this, since the size of the
string doesn't matter AFAIK.

Thanks!

>Anyway, Let me know.
>
>David
>
>On Mon, 2004-10-11 at 12:25, David Radunz wrote:
>  
>
>>Further to that - I just tested with an even bigger string and this one
>>did get cleared fine, so it musnt be the size :(
>>
>>Not sure what the problem is,
>>
>>DJ
>>
>>On Mon, 2004-10-11 at 12:13, David Radunz wrote:
>>    
>>
>>>Hey,
>>>
>>>  Thanks for your help. I tried using Devel::Unload to see how it works
>>>and encountered something unexpected. Basically I put the
>>>'unload_package_xs' call just above the 'flush_namespace' call. Then I
>>>printed from within the namespace clearing loop (expecting nothing to be
>>>printed), yet something did get printed..
>>>
>>>Flushing
>>>Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::chargespage_2ecgi::qs
>>>Flushing
>>>Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::paymentspage_2ecgi::qs
>>>Flushing
>>>Apache::ROOTsmog_2edev_2enetspace_2enet_2eau::client_2dinfo_2dpr::homeadslclientpage_2ecgi::qs
>>>
>>>Which isnt that bad, because the rest of the namespace had been cleared,
>>>except this lonley scalar - I printed it to see if it contained anything
>>>and got the following:
>>>
>>>  Scalar = SELECT DECODE.... (i wont paste the whole scalar here, its
>>>basically a huge SQL statement, about 2000 characters).
>>>
>>>Perhaps the scalar was too big to be cleared?
>>>
>>>Cheers,
>>>
>>>DJ
>>>
>>>
>>>On Sat, 2004-10-09 at 09:08, Philippe M. Chiasson wrote:
>>>      
>>>
>>>>Stas Bekman wrote:
>>>>
>>>>        
>>>>
>>>>>David Radunz wrote:
>>>>>
>>>>>          
>>>>>
>>>>>>Hi All,
>>>>>>
>>>>>>  I have looked high and low to work out how to avoid the 'Constant
>>>>>>subroutine redefined' warnings in the error log, followed by the
>>>>>>'Prototype missmatch:' error upon subsequent hits to the apache child
>>>>>>process - but, I have not been able to find an easy solution. The
>>>>>>warnings are caused by the 'flush_namespace' routine of Apache::PerlRun
>>>>>>which attempts to reset/nullify everything - including constants.
When a
>>>>>>constant is redefined it causes a warning in the error_log, and when
the
>>>>>>constant gets reset upon the next run of the script the prototype
doesnt
>>>>>>match as its reset incorrectly.
>>>>>>            
>>>>>>
>>>>>David, take a look at the ModPerl::PerlRun which now 
>>>>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/ModPerl-Registry/lib/ModPerl/RegistryCooker.pm?r1=1.50&r2=1.51&diff_format=h
>>>>>
>>>>>uses:
>>>>>http://perl.apache.org/docs/2.0/api/ModPerl/Util.html#C_unload_package_
>>>>>which Philippe has just added recently. (you will need the current mp2

>>>>>cvs to see it at works). It solves all these problems in a much 
>>>>>cleaner way. It's still too new to new to be sure that it doesn't have

>>>>>side-effects, but once it's proved to be good by users, we can just 
>>>>>port it back to mp1.
>>>>>          
>>>>>
>>>>It's also available as a yet to be released on CPAN module 
>>>>(Devel::Unload) here: http://svn.ectoplasm.org/projects/perl/Devel-Unload/
>>>>
>>>>You might just try installing Devel::Unload and plugging it into 
>>>>PerlRun.pm and see if it works
>>>>
>>>>(untested patch)
>>>>
>>>>Index: lib/Apache/PerlRun.pm
>>>>===================================================================
>>>>RCS file: /home/cvs/modperl/lib/Apache/PerlRun.pm,v
>>>>retrieving revision 1.41
>>>>diff -u -I$Id -r1.41 PerlRun.pm
>>>>--- lib/Apache/PerlRun.pm       8 Mar 2003 04:11:09 -0000       1.41
>>>>+++ lib/Apache/PerlRun.pm       8 Oct 2004 23:08:02 -0000
>>>>@@ -118,6 +118,8 @@
>>>>     $_r->clear_rgy_endav;
>>>>     $_r->log_error("Apache::PerlRun->compile") if $Debug &&
$Debug & 4;
>>>>     Apache->untaint($$eval);
>>>>+    use Devel::Unload;
>>>>+    Devel::Unload::unload_package_xs($pr->namespace);
>>>>     {
>>>>        no strict; #so eval'd code doesn't inherit our bits
>>>>        eval $$eval;
>>>>
>>>>        
>>>>
>>>>>If you want to look at the C code that does that, it's 
>>>>>modperl_package_unload in:
>>>>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/modperl_util.c?view=markup
>>>>>
>>>>>
>>>>>          
>>>>>
>>>-- 
>>>David Radunz,
>>>Developer / Programmer
>>>
>>>Netspace Online Systems Pty Ltd
>>>Ground Floor, 293 Camberwell Road
>>>Camberwell, Victoria 3124
>>>Ph:  +613 9811 0087
>>>Fx:  +613 9811 0044
>>>Mo:  +614 0549 9719
>>>Em:  david.radunz@staff.netspace.net.au
>>>
>>>This email and any files transmitted with it are confidential and intended solely
for the 
>>>use of the individual or entity to whom they are addressed. Please notify the
sender 
>>>immediately by email if you have received this email by mistake and delete this
email 
>>>from your system. Please note that any views or opinions presented in this email
are solely
>>> those of the author and do not necessarily represent those of the organisation.

>>>Finally, the recipient should check this email and any attachments for the presence
of 
>>>viruses. The organisation accepts no liability for any damage caused by any virus

>>>transmitted by this email. 
>>>      
>>>
>>-- 
>>David Radunz,
>>Developer / Programmer
>>
>>Netspace Online Systems Pty Ltd
>>Ground Floor, 293 Camberwell Road
>>Camberwell, Victoria 3124
>>Ph:  +613 9811 0087
>>Fx:  +613 9811 0044
>>Mo:  +614 0549 9719
>>Em:  david.radunz@staff.netspace.net.au
>>    
>>


Mime
View raw message