Re: Apache2::Reload problem (ModPerl::Util bug)

["Philippe M. Chiasson" <go...@ectoplasm.org>]

Mark wrote:
> Mark wrote:
>
>> In 2.0.0, if there are heirarchical packages, and Apache2::Reload is
>> configured to reload the 'parent', it blows away the 'children' package
>> namespaces (and doesn't reload the children.)  For example, if @INC has:
>>
>> Fubar.pm
>> Fubar/Child.pm
>>
>> And Apache2::Reload reloads package Fubar, it blows away
>> Fubar::Child::* and only reloads file Fubar.pm.   Only a server
>> restart can recover from this point.
>>
>> The actual unloading work is done by ModPerl::Util::unload_package(),
>> whose behavior is contrary to the docs, which say:
>>
>>   "unload_package()" takes care to leave sub-stashes intact while
>>   deleting the requested stash. So for example if "CGI" and "CGI::Carp"
>>   are loaded, calling "unload_package('CGI')" won't affect "CGI::Carp".

This is clearly a bug.

>> I only partly understand how unload_package() works, but it seems to
>> just iterate over symbols in the package and blow them away, without
>> regard for the actual file from which the symbol was instantiated.

Yup, it's that simple and there is a slightly smarter version in XS
that does check the source of the symbols from.

>> I tried modifying the code to skip over symbols that correspond
>> to a key in %INC, which seems logical and works correctly in my tests,
>> but may not be a complete or perfect solution for reasons beyond
>> my current testing/thinking.  However, in my tests, it works correctly
>> if either the parent package, child package, or both are modified.
>>
>> Comments/suggestions about the correctness of this patch requested.
>
> Correction. Ignore previous patch.  It only worked one level of
> heirarchy.  Correct patch is:

Much simpler patch to just skip stashes has been checked in in rev 179448.

If you can try latest-svn and confirm your problem goes away, that would be
fantastic.

--------------------------------------------------------------------------------
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/     F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5

Re: Apache2::Reload problem (ModPerl::Util bug)

[Mark <ma...@immermail.com>]

Philippe M. Chiasson wrote:
> Mark wrote:
> 
>>Mark wrote:
>>
>>
>>>In 2.0.0, if there are heirarchical packages, and Apache2::Reload is
>>>configured to reload the 'parent', it blows away the 'children' package
>>>namespaces (and doesn't reload the children.)  For example, if @INC has:
>>>
>>>Fubar.pm
>>>Fubar/Child.pm
>>>
>>>And Apache2::Reload reloads package Fubar, it blows away
>>>Fubar::Child::* and only reloads file Fubar.pm.   Only a server
>>>restart can recover from this point.
>>>
>>>The actual unloading work is done by ModPerl::Util::unload_package(),
>>>whose behavior is contrary to the docs, which say:
>>>
>>>  "unload_package()" takes care to leave sub-stashes intact while
>>>  deleting the requested stash. So for example if "CGI" and "CGI::Carp"
>>>  are loaded, calling "unload_package('CGI')" won't affect "CGI::Carp".
> 
> 
> This is clearly a bug.
> 
> 
>>>I only partly understand how unload_package() works, but it seems to
>>>just iterate over symbols in the package and blow them away, without
>>>regard for the actual file from which the symbol was instantiated.
> 
> 
> Yup, it's that simple and there is a slightly smarter version in XS
> that does check the source of the symbols from.
> 
> 
>>>I tried modifying the code to skip over symbols that correspond
>>>to a key in %INC, which seems logical and works correctly in my tests,
>>>but may not be a complete or perfect solution for reasons beyond
>>>my current testing/thinking.  However, in my tests, it works correctly
>>>if either the parent package, child package, or both are modified.
>>>
>>>Comments/suggestions about the correctness of this patch requested.
>>
>>Correction. Ignore previous patch.  It only worked one level of
>>heirarchy.  Correct patch is:
> 
> 
> Much simpler patch to just skip stashes has been checked in in rev 179448.
> 
> If you can try latest-svn and confirm your problem goes away, that would be
> fantastic.

That works. Thanks.