Re: Case of the Vanishing Symbol Tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 12, 2001 at 01:17:45AM -0500, Daniel Jacobowitz wrote: I'm willing to bet that this is the Known Nasty having to do with how Apache re-reloads modules. Looks that way to me, but I get lost in exactly when/how mod_perl gets called. Are you using mod_perl as a DSO? If so, have you tried it statically? It's static right now. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBeYNAOGqGs0PadnEQLzgwCbBt/CT8tAjtu/69SE1QWZmLWWGxIAoOX9 mxNMxkAu8lgF80C2IzEjWqoS =2S3T -END PGP SIGNATURE-
Re: Case of the Vanishing Symbol Tables
Are you using PerlFreshRestart? Same behavior, on or off. That's strange. With PerlFreshRestart on, it is supposed to clear things out when restarting, which seems consistent with what you're seeing. Are you sure there is no difference in that trace at all when you turn it on or off? You should be able to replace a PerlModule call with Perluse MyModule;/Perl in the same place in httpd.conf. Does that work for you? The Eagle book says to do that with earlier versions. This doesn't work either. They simply refuse to be loaded anywhere other than the startup.pl. What do you mean by refuse to be loaded? Here's the relevant quote from the Eagle (by way of http://www.modperl.com/): The only trick to this is that you must be careful that the PerlModule directive is called before any PerlPassThru directives appear. Otherwise Apache won't recognize the new directive and will abort with a configuration file syntax error. The other caveat is that PerlModule only works to bootstrap configuration directives in mod_perl versions 1.17 and higher. If you are using an earlier version, use this configuration section instead: Perl use Apache::PassThru (); /Perl
Re: Case of the Vanishing Symbol Tables -- Solved!
Eureka. Took quite a bit of debugging, but I finally tracked it down. First, the setup...our module structure goes something like this: IQGroup \_ Core |_ IQCoordinator |_ IQDeveloper |_ IQNextNeatApplication The IQGroup class is our master mod_perl handler -- it handles 99% of the talking to Apache, as well as providing the handler() routine, error handling, Apache config directives, etc. All of our apps inherit from it. IQGroup::Core has all the classes shared between apps, then each app gets its own namespace to do whatever with. The problem emanates from perl_clear_symtab, which gets called from the remove_module_cleanup function that Apache::ExtUtils sets up. As it traverses the symbol table, it doesn't bother checking for something special like this (trimmed for brevity): SV = PVGV(0x8440a88) at 0x846130c NAME = Core:: GvSTASH = 0x841d1e8 IQGroup GP = 0x842d830 FILE = /home/thebrain/perllib/IQGroup/Core/Utility.pm EGV = 0x846130c Core:: And gleefully blows it away, thus annihilating the symbol tables for IQGroup::Core and everything under it. Presumably perl_clear_symtab isn't supposed to touch symbol tables other than for the module it's currently dealing with, so the attached patch tells it to leave them alone. This has completely fixed the problem on my end. Note I couldn't find any better way of telling if an entry was a symbol table hash, so feel free to change this if you know a trick I don't. -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ Index: src/modules/perl/perl_config.c === RCS file: /home/thebrain/.cvsroot/mod_perl/src/modules/perl/perl_config.c,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 perl_config.c --- src/modules/perl/perl_config.c 2001/11/20 23:55:59 1.1.1.1 +++ src/modules/perl/perl_config.c 2001/12/12 23:54:35 @@ -1685,7 +1685,7 @@ CV *cv; dTHR; - if((SvTYPE(val) != SVt_PVGV) || GvIMPORTED((GV*)val)) + if((SvTYPE(val) != SVt_PVGV) || GvIMPORTED((GV*)val) || ((hv = GvHV((GV*)val)) + strstr(key,::))) continue; if((sv = GvSV((GV*)val))) sv_setsv(GvSV((GV*)val), sv_undef); msg23485/pgp0.pgp Description: PGP signature
Case of the Vanishing Symbol Tables
With the PerlModule/%INC problem recently being rehashed, here's another one
involving PerlModule vs. use that will really bake your noodle.
Attached is a full mod_perl trace, where I hacked into perl_require_module a
dump of one of my vanishing namespaces on each module load. So you can
definitely see it's loading up properly. All is well until you reach the end,
where it starts reloading everything, and the namespace is now completely gone.
Exporter predictably throws an error at this point (since @EXPORT_OK is now
undefined) and the server fails to start. OTOH, one wonders how Exporter got
the call, since @ISA is gone as well.
I posted this once before and got blown off -- a pox on to those who tell me to
check @INC or what not. There is nothing wrong with my code or my setup -- the
only change I have to make to get things working is to `use` all the PerlModule
modules in startup.pl first, before they're called with PerlModule. And don't
tell me to just use `use` either -- they all load up Apache config directives,
so PerlModule has to be called at some point so Apache recognizes the
directives. But if things were working as advertised, PerlModule would be all I
need.
The two obvious questions:
1) Where the fsck did everything go?
2) Why does this only emanate when stuff is loaded up via PerlModule? I mean,
look at perl_require_module -- all it does is `eval require $foo`. Hard to
go wrong there.
--
Stephen Clouse [EMAIL PROTECTED]
Senior Programmer, IQ Coordinator Project Lead
The IQ Group, Inc. http://www.theiqgroup.com/
perl_parse args: '/dev/null' ...allocating perl interpreter...ok
constructing perl interpreter...ok
ok
running perl interpreter...ok
mod_perl: 0 END blocks encountered during server startup
PerlRequire: arg=`/opt/apache/conf/mod_perl.startup.pl'
attempting to require `/opt/apache/conf/mod_perl.startup.pl'
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {};
loading perl module 'Apache::Constants::Exports'...Dump of IQGroup::Core::Utility
namespace:
$VAR1 = {};
ok
ok
PerlModule: arg='IQGroup'
loading perl module 'IQGroup'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {};
fetching PerlChildInitHandler stack
PerlChildInitHandler handlers stack undef, creating
pushing CODE ref into `PerlChildInitHandler' handlers
ok
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {
'import' = *IQGroup::Core::Utility::import,
'EXPORT_FAIL' = *IQGroup::Core::Utility::EXPORT_FAIL,
'iqsprintf' = *IQGroup::Core::Utility::iqsprintf,
'is_spider_or_bot' = *IQGroup::Core::Utility::is_spider_or_bot,
'VERSION' = *IQGroup::Core::Utility::VERSION,
'ISA' = *IQGroup::Core::Utility::ISA,
'EXPORT' = *IQGroup::Core::Utility::EXPORT,
'commify' = *IQGroup::Core::Utility::commify,
'htmlize_nowrap' = *IQGroup::Core::Utility::htmlize_nowrap,
'htmlize' = *IQGroup::Core::Utility::htmlize,
'EXPORT_OK' = *IQGroup::Core::Utility::EXPORT_OK,
'BEGIN' = *IQGroup::Core::Utility::BEGIN,
'EXPORT_TAGS' = *IQGroup::Core::Utility::EXPORT_TAGS
};
ok
PerlModule: arg='IQGroup::IQCoordinator'
loading perl module 'IQGroup::IQCoordinator'...Dump of IQGroup::Core::Utility
namespace:
$VAR1 = {
'import' = *IQGroup::Core::Utility::import,
'EXPORT_FAIL' = *IQGroup::Core::Utility::EXPORT_FAIL,
'iqsprintf' = *IQGroup::Core::Utility::iqsprintf,
'is_spider_or_bot' = *IQGroup::Core::Utility::is_spider_or_bot,
'VERSION' = *IQGroup::Core::Utility::VERSION,
'ISA' = *IQGroup::Core::Utility::ISA,
'EXPORT' = *IQGroup::Core::Utility::EXPORT,
'commify' = *IQGroup::Core::Utility::commify,
'htmlize_nowrap' = *IQGroup::Core::Utility::htmlize_nowrap,
'htmlize' = *IQGroup::Core::Utility::htmlize,
'EXPORT_OK' = *IQGroup::Core::Utility::EXPORT_OK,
'BEGIN' = *IQGroup::Core::Utility::BEGIN,
'EXPORT_TAGS' = *IQGroup::Core::Utility::EXPORT_TAGS
};
ok
loading perl module 'Apache'...Dump of IQGroup::Core::Utility namespace:
$VAR1 = {
'import' = *IQGroup::Core::Utility::import,
'EXPORT_FAIL' = *IQGroup::Core::Utility::EXPORT_FAIL,
'iqsprintf' = *IQGroup::Core::Utility::iqsprintf,
'is_spider_or_bot' = *IQGroup::Core::Utility::is_spider_or_bot,
'VERSION' = *IQGroup::Core::Utility::VERSION,
'ISA' = *IQGroup::Core::Utility::ISA,
'EXPORT' = *IQGroup::Core::Utility::EXPORT,
'commify' = *IQGroup::Core::Utility::commify,
'htmlize_nowrap' = *IQGroup::Core::Utility::htmlize_nowrap,
'htmlize' = *IQGroup::Core::Utility::htmlize,
'EXPORT_OK' = *IQGroup::Core::Utility::EXPORT_OK,
'BEGIN' = *IQGroup::Core::Utility::BEGIN,
'EXPORT_TAGS' = *IQGroup::Core::Utility::EXPORT_TAGS
Re: Case of the Vanishing Symbol Tables
IMHO, this looks similar to (though more catastrophic than) the problem I have been dealing with for some time now. From the archive : http://groups.yahoo.com/group/modperl/message/38622 There is a long thread about it. It is presently unresolved. (We're hoping for Divine intervention. We'd settle for Doug. :-) Good luck, David
Re: Case of the Vanishing Symbol Tables
All is well until you reach the end, where it starts reloading everything, and the namespace is now completely gone. Are you using PerlFreshRestart? I posted this once before and got blown off -- a pox on to those who tell me to check @INC or what not. No need to get testy. If this is causing a problem for your business, and free volunteer help is not working quickly enough for you, you can always contract Covalent to solve the problem. And don't tell me to just use `use` either -- they all load up Apache config directives, so PerlModule has to be called at some point so Apache recognizes the directives. You should be able to replace a PerlModule call with Perluse MyModule;/Perl in the same place in httpd.conf. Does that work for you? The Eagle book says to do that with earlier versions. - Perrin
Re: Case of the Vanishing Symbol Tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 11, 2001 at 11:08:07PM -0500, Perrin Harkins wrote: Are you using PerlFreshRestart? Same behavior, on or off. No need to get testy. That came out wrong, apparently. Sorry. You should be able to replace a PerlModule call with Perluse MyModule;/Perl in the same place in httpd.conf. Does that work for you? The Eagle book says to do that with earlier versions. This doesn't work either. They simply refuse to be loaded anywhere other than the startup.pl. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBbuAwOGqGs0PadnEQK1agCZAS4ksWa1P1ddy5v+5TnTnusq07oAn0jt fjNlzg6pzLmMRCSfpJwp5F2o =1Msz -END PGP SIGNATURE-
Re: Case of the Vanishing Symbol Tables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 11, 2001 at 05:33:12PM -0800, David Pisoni wrote: IMHO, this looks similar to (though more catastrophic than) the problem I have been dealing with for some time now. From the archive : http://groups.yahoo.com/group/modperl/message/38622 There is a long thread about it. It is presently unresolved. (We're hoping for Divine intervention. We'd settle for Doug. :-) This is actually the thread I was referring to :) The first time I encountered this, Apache actually would start successfully, but accessing the application would error with undefined subroutine App::Class::handler. A glance at Apache::Status revealed the exact behavior you're describing. But you're right, it *is* more catastrophic now, in that it's no longer content with nuking just PerlModule modules, it's eating other ones as well. Just wish I could spot *where* they're vanishing at...tried all day today but no luck. I'll give it another try tomorrow. - -- Stephen Clouse [EMAIL PROTECTED] Senior Programmer, IQ Coordinator Project Lead The IQ Group, Inc. http://www.theiqgroup.com/ -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 iQA/AwUBPBbxNQOGqGs0PadnEQI/kgCg5I9fxWtVp5+WuS/ostqbSNVSCKsAniNK C4lgQ9YycR91+N02vi4pS2l7 =Vl6Y -END PGP SIGNATURE-
Re: Case of the Vanishing Symbol Tables
On Tue, Dec 11, 2001 at 04:15:49PM -0600, Stephen Clouse wrote: With the PerlModule/%INC problem recently being rehashed, here's another one involving PerlModule vs. use that will really bake your noodle. Attached is a full mod_perl trace, where I hacked into perl_require_module a dump of one of my vanishing namespaces on each module load. So you can definitely see it's loading up properly. All is well until you reach the end, where it starts reloading everything, and the namespace is now completely gone. Exporter predictably throws an error at this point (since @EXPORT_OK is now undefined) and the server fails to start. OTOH, one wonders how Exporter got the call, since @ISA is gone as well. I posted this once before and got blown off -- a pox on to those who tell me to check @INC or what not. There is nothing wrong with my code or my setup -- the only change I have to make to get things working is to `use` all the PerlModule modules in startup.pl first, before they're called with PerlModule. And don't tell me to just use `use` either -- they all load up Apache config directives, so PerlModule has to be called at some point so Apache recognizes the directives. But if things were working as advertised, PerlModule would be all I need. The two obvious questions: 1) Where the fsck did everything go? 2) Why does this only emanate when stuff is loaded up via PerlModule? I mean, look at perl_require_module -- all it does is `eval require $foo`. Hard to go wrong there. I'm willing to bet that this is the Known Nasty having to do with how Apache re-reloads modules. Are you using mod_perl as a DSO? If so, have you tried it statically? -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
