can't find ANONSUB's 'anon1' entry.
gorus
I've been using Rose::DB 0.747 for a while with no issues. When I try
to update to 0.748 or above and restart apache (mod_perl 2), my
error_log continuously fills up with the following error messages:
can't find ANONSUB's 'anon1' entry.
They come up once every half a second or so. If I try to make any
Apache requests that use Rose::DB, they hang forever. If I downgrade
to 0.747, all is well again.
I have no clue where to start looking--if someone would chime in with
some suggestions, I'd greatly appreciate it. This is running on
CentOS 5.2 with Perl 5.8.8, Apache 2.2.3, and MySql 5.0.45.
Thanks,
Anton
John Siracusa
> I've been using Rose::DB 0.747 for a while with no issues. When I try
> to update to 0.748 or above and restart apache (mod_perl 2), my
> error_log continuously fills up with the following error messages:
>
> can't find ANONSUB's 'anon1' entry.
>
> They come up once every half a second or so. If I try to make any
> Apache requests that use Rose::DB, they hang forever. If I downgrade
> to 0.747, all is well again.
I'm assuming you found this already:
http://mail-archives.apache.org/mod_mbox/perl-dev/200504.mbox/%3C4256B5F...@stason.org%3E
But I confess I've never seen that error. Maybe this documentation will help?
http://search.cpan.org/dist/Rose-DB/lib/Rose/DB/Cache.pm
If you can provide a minimal reproduction of the problem (e.g., a
small sample httpd.conf plus startup.pl) I can try to debug it. Any
other mod_perl 2 users have this problem?
-John
gorus
> I'm assuming you found this already:
>
You guessed it :) I am using the mentioned "PerlOptions +Parent"
option in my virtual hosts... I also found the mod_perl source file
that gives the error:
http://cpansearch.perl.org/src/GOZER/mod_perl-2.0.4/src/modules/perl/modperl_handler.c
Unfortunately, my level of expertise is not good enough to debug
mod_perl on that level (without direction), so I thought I'd see if
someone else has experienced the issue first.
> But I confess I've never seen that error. Maybe this documentation will help?
>
> http://search.cpan.org/dist/Rose-DB/lib/Rose/DB/Cache.pm
mean to point out something specific there that applies to Rose::DB as
well?
> If you can provide a minimal reproduction of the problem (e.g., a
> small sample httpd.conf plus startup.pl) I can try to debug it. Any
> other mod_perl 2 users have this problem?
complex and large, so I'm stripping it down to the bare minimum such
that the issue is still reproducible. Meanwhile, can you think of
anything specific that changed in the code between 0.747 and 0.748
that is somehow related to mod_perl's use of anon subs?
-Anton
John Siracusa
>> http://search.cpan.org/dist/Rose-DB/lib/Rose/DB/Cache.pm
>
> I read through this, although I'm not using Rose::DB::Cache. Did you
> mean to point out something specific there that applies to Rose::DB as
> well?
If you're not calling new_or_cached(), I suspect the point is moot.
>> If you can provide a minimal reproduction of the problem (e.g., a
>> small sample httpd.conf plus startup.pl) I can try to debug it. Any
>> other mod_perl 2 users have this problem?
>
> I'm trying to put this together now. The code base I inherited is
> complex and large, so I'm stripping it down to the bare minimum such
> that the issue is still reproducible. Meanwhile, can you think of
> anything specific that changed in the code between 0.747 and 0.748
> that is somehow related to mod_perl's use of anon subs?
That release was all about changes to mod_perl 2 support, but I think
it should not affect you if you're not using caching:
http://search.cpan.org/diff?from=Rose-DB-0.747&to=Rose-DB-0.748&w=1
Maybe you're using caching and don't know it?
-John
gorus
> it should not affect you if you're not using caching:
>
> http://search.cpan.org/diff?from=Rose-DB-0.747&to=Rose-DB-0.748&w=1
>
> Maybe you're using caching and don't know it?
Rose::DB::Cache anyway, which is enough to cause the problem (even
though I'm not calling any cache methods). I dug deeper and actually
found the code that causes the error, lines 166-170:
Apache2::ServerUtil->server->push_handlers(PerlChildInitHandler => sub
{
$Debug && warn "$$ is MP2 child\n";
$MP2_Is_Child = 1;
});
Commenting out these lines makes the problem go away! Perhaps you can
consider having Rose::DB::Cache not load that little snippet by
default? Seems reasonable if one is not using Rose::DB::Cache.
-Anton
John Siracusa
> I'm definitely not using caching. However, Rose/DB.pm line 13 loads
> Rose::DB::Cache anyway, which is enough to cause the problem (even
> though I'm not calling any cache methods). I dug deeper and actually
> found the code that causes the error, lines 166-170:
>
> Apache2::ServerUtil->server->push_handlers(PerlChildInitHandler => sub
> {
> $Debug && warn "$$ is MP2 child\n";
> $MP2_Is_Child = 1;
> });
Ah, that makes sense.
> Commenting out these lines makes the problem go away! Perhaps you can
> consider having Rose::DB::Cache not load that little snippet by
> default? Seems reasonable if one is not using Rose::DB::Cache.
The trouble is, it's not known at the time the decision is being made
whether you will call new_or_cached() anywhere in your code in the
future. A better fix would be to figure out a way to check for
whatever setting it is that will cause this handler to fail later. Is
that the "PerlOptions +Parent" thing? If so, how can we check for
that programatically?
-John
gorus
> whether you will call new_or_cached() anywhere in your code in the
> future. A better fix would be to figure out a way to check for
> whatever setting it is that will cause this handler to fail later. Is
> that the "PerlOptions +Parent" thing? If so, how can we check for
> that programatically?
questions.
For the first, unfortunately, I cannot verify "PerlOptions +Parent" is
the cause. The whole code base is dependent on this directive and I
cannot disable it. Perhaps Stas Bekman may be able to help you,
judging by the info at that first link you found? I have a feeling it
is the cause and it may be simple for him to look at those 5 lines in
your Cache.pm and offer a suggestion.
For the second, I believe this is what you're looking for:
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlOptions_
-Anton
John Siracusa
>> The trouble is, it's not known at the time the decision is being made
>> whether you will call new_or_cached() anywhere in your code in the
>> future. A better fix would be to figure out a way to check for
>> whatever setting it is that will cause this handler to fail later. Is
>> that the "PerlOptions +Parent" thing? If so, how can we check for
>> that programatically?
>
> I dug around to see if I can find concrete answers to your two
> questions.
>
> For the first, unfortunately, I cannot verify "PerlOptions +Parent" is
> the cause. The whole code base is dependent on this directive and I
> cannot disable it.
Well, as a work-around, I can always check for some environment
variable (e.g., ROSE_DB_NO_MOD_PERL) and then not run the offending
code if it's set. That might suffice until/unless a minimal
reproduction can be created to pinpoint the cause. What do you think?
-John
gorus
> variable (e.g., ROSE_DB_NO_MOD_PERL) and then not run the offending
> code if it's set. That might suffice until/unless a minimal
> reproduction can be created to pinpoint the cause. What do you think?
obviously make the mod in my local copy--do what you think is right
for your project :) I think longer term, a mod_perl expert like Stas
could be a good person to consult.
Thanks,
Anton
John Siracusa
Okay, I think I worked around it without requiring any environment
variable hacks. Try out the SVN version and let me know if it works
for you.
-John
gorus
> variable hacks. Try out the SVN version and let me know if it works
> for you.
get 48 of these error_log entries:
[Mon Mar 16 12:27:56 2009] [error] lookup of
'Rose::DB::Cache::__mod_perl_2_rose_db_child_init_handler' failed
Apache restarts successfully though, and Rose::DB functionality works
as expected.
I have not done excessive testing yet, but the error messages appear
to be harmless thus far.
-Anton
gorus
stable and the error message does not appear at any other time besides
Apache starting. That said, keep in mind that I'm not using any
caching methods, so I don't know if they would fail.
-Anton
John Siracusa
> John, after a few more days of extensive testing, things seem to be
> stable and the error message does not appear at any other time besides
> Apache starting. That said, keep in mind that I'm not using any
> caching methods, so I don't know if they would fail.
In SVN, I added an (undocumented) environment variable on top of my
previous fix:
Set ROSE_DB_NO_CHILD_INIT_HANDLER to a true (as far as Perl is
concerned) value and let me know if that silences all of your
warnings.
-John
gorus
> previous fix:
>
> Set ROSE_DB_NO_CHILD_INIT_HANDLER to a true (as far as Perl is
> concerned) value and let me know if that silences all of your
> warnings.
doesn't. If I type 'env' or 'declare' or 'export' in my bash shell, I
do show:
ROSE_DB_NO_CHILD_INIT_HANDLER=1
among my other environment vars. However, the elsif(!$ENV
{'ROSE_DB_NO_CHILD_INIT_HANDLER'}) clause is not being executed when I
restart Apache. Anyway, perhaps my $ENV doesn't work correctly, so it
looks like a different problem on my end now; I'll figure it out.
Thanks for your help.
-Anton
John Siracusa
>> In SVN, I added an (undocumented) environment variable on top of my
>> previous fix:
>>
>> http://code.google.com/p/rose/source/diff?spec=svn1907&r=1907&format=...
>>
>> Set ROSE_DB_NO_CHILD_INIT_HANDLER to a true (as far as Perl is
>> concerned) value and let me know if that silences all of your
>> warnings.
>
> Thanks, I can see how that should work, but for some reason it
> doesn't. If I type 'env' or 'declare' or 'export' in my bash shell, I
> do show:
>
> ROSE_DB_NO_CHILD_INIT_HANDLER=1
>
> among my other environment vars. However, the elsif(!$ENV
> {'ROSE_DB_NO_CHILD_INIT_HANDLER'}) clause is not being executed
Look into PerlPassEnv
http://modperlbook.org/html/4-2-10-PerlSetEnv-and-PerlPassEnv.html
-John