Re: Cannot get mod_perl 2.0.6 to compile with apache 2.2.22 under perl 5.16.0
On Tue, May 29, 2012 at 12:07 PM, Doug Hunt wrote: > Hi mod_perl list! > > I've been using Apache and mod_perl for a long time on our web site, but I'm > having troubles getting it to compile under the most recent Apache, mod_perl > and perl. > > I'm working under CentOS 6.2 on an x86_64 system. > > I'm trying to do a static Apache/mod_perl compile: Try with this patch: https://rt.cpan.org/Public/Bug/Display.html?id=77129
Re: DBI and Apache::DBI issues
On Tue, Feb 8, 2011 at 16:26, Max Pinton wrote: > On Feb 8, 2011, at 7:36 AM, Perrin Harkins wrote: >> That doesn't explain all of your errors though. I'm guessing that >> you're opening a connection during startup and forking with it. You >> need to find that. Look for things that might open a connection >> during startup and move them to ChildInitHandlers instead. > > That's puzzling. I'm not forking anywhere in my scripts. I did once try > using threads for something, but abandoned it because it segfaulted in > mod_perl and it wasn't db-related anyway. My startup.perl (minus my modules) > is: You could always try strace to find if there are any fork/clone calls: strace -e trace=fork,clone httpd -X > [startup.perl] > Does anything there look fishy? Nothing jumps out at me.
Re: [PATCH] END blocks may segfault
>>> On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote:
>>> > I suggest the code shift items off the main array, like perl does,
>>> > but also push those items onto a new temp array.
Find attached a patch that does the above (perhaps naively), passes a
make test and fixes the reported problems for me.
diff --git a/src/modules/perl/modperl_util.c b/src/modules/perl/modperl_util.c
index ce95466..7a74be0 100644
--- a/src/modules/perl/modperl_util.c
+++ b/src/modules/perl/modperl_util.c
@@ -467,19 +467,22 @@ void modperl_perl_do_sprintf(pTHX_ SV *sv, I32 len, SV **sarg)
void modperl_perl_call_list(pTHX_ AV *subs, const char *name)
{
-I32 i, oldscope = PL_scopestack_ix;
-SV **ary = AvARRAY(subs);
+I32 oldscope = PL_scopestack_ix;
+AV *tmpav = newAV();
+
+av_extend(tmpav, AvFILLp(subs));
MP_TRACE_g(MP_FUNC, "pid %lu" MP_TRACEf_TID MP_TRACEf_PERLID
" running %d %s subs",
(unsigned long)getpid(), MP_TRACEv_TID_ MP_TRACEv_PERLID_
AvFILLp(subs)+1, name);
-for (i=0; i<=AvFILLp(subs); i++) {
-CV *cv = (CV*)ary[i];
+while (av_len(subs) >= 0) {
+CV *cv = (CV*)av_shift(subs);
SV *atsv = ERRSV;
PUSHMARK(PL_stack_sp);
+av_push(tmpav, (SV*)cv);
call_sv((SV*)cv, G_EVAL|G_DISCARD);
if (SvCUR(atsv)) {
@@ -491,6 +494,11 @@ void modperl_perl_call_list(pTHX_ AV *subs, const char *name)
Perl_croak(aTHX_ "%s", SvPVX(atsv));
}
}
+
+while (av_len(tmpav) >= 0) {
+av_push(subs, av_shift(tmpav));
+}
+sv_free((SV*)tmpav);
}
void modperl_perl_exit(pTHX_ int status)
Re: [PATCH] END blocks may segfault
On Wed, Jun 30, 2010 at 16:37, Tim Bunce wrote: > On Wed, Jun 30, 2010 at 09:24:42AM -0600, Alex Hunsaker wrote: >> On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote: >> > I suggest the code shift items off the main array, like perl does, >> > but also push those items onto a new temp array. > I presume mod_perl doesn't shift the array because it wants the array to > persist to be used again later. Yeah... Basically when running under ModPerl::Registry it tries to treat your script exactly like it is running under cgi. So when the script finish it runs end blocks. When the next request comes in you still want those end blocks to run. >From the ModPerl::Registry documentation: | END blocks encountered during compilation of a script, are called | after the script has completed its run, including subsequent | invocations when the script is cached in memory. This is | assuming that the script itself doesn't define a package on its | own. If the script defines its own package, the END blocks in the | scope of that package will be executed at the end of the interpretor's life. > Otherwise running 11 the first and 21 the second is the right behavior > for this (very unusual) test case. Yeah... I think you are right, I was completely over thinking things I think.
Re: [PATCH] END blocks may segfault
On Wed, Jun 30, 2010 at 02:49, Tim Bunce wrote:
> On Tue, Jun 29, 2010 at 09:50:00PM -0700, Fred Moyer wrote:
>> I think getting rid of the segfault is a good thing. But if the main
>> problem is issues with NYTProf, then it seems like this change won't
>> solve the core problem of autogenerated null end blocks faulting. I'm
>> don't fully understand the scope of these issues yet, so my answers
>> (and questions) may not be completely helpful.
Well, the point of the test case is it does not use NYTProf. Sure It
was found while playing with NYTProf. :)
> I suggest the code shift items off the main array, like perl does,
> but also push those items onto a new temp array.
> When there are no more items in the main array it would copy
> the items back again (av_make() is handy for that).
Wouldn't the list keep getting longer each time? For example take
your test case:
END { eval "END { }" for 1..10 }
The first time we run them we should shift of 11 items. The next time
21, etc. Am I missing something? Perhaps some cool trick? Thats why
I was thinking local() or equiv would make the most sense.
Hrm?
[PATCH] END blocks may segfault
Hi!
perl: 5.10.1, 5.12.1 (i686-linux, x86_64-linux)
mod_perl: 2.0.4
Basically if you have end blocks that modify/add END blocks things
might go crazy.
A simple test case for this is:
package test:
END { eval "END { }" for 1..10 }
gives:
Not a CODE reference.
END failed--call queue aborted.
if I add another END {}:
package test:
END { eval "END { }" for 1..10 }
END { }
I get:
Undefined subroutine &main:: called.
END failed--call queue aborted.
This was found as I was getting strange segfaults when trying to use
NYTProf. Nicholas Clark was able to pinpoint the problem.
See:
http://groups.google.com/group/develnytprof-dev/msg/4ff26e6b3d95861f
thread:
http://groups.google.com/group/develnytprof-dev/browse_thread/thread/20d2ea800e8936f
Ive included some relevant bits here (again from Nicholas):
> Of course, I looked at the core perl source to see how END blocks were run,
> and the behaviour was safe with perl. perl unshifts each CV from the list
> before it calls it. I should have remembered that inevitably mod_perl is
> "special".
>
> On reflection, I think that this *is* a bug in mod_perl, as they're going
> to get tripped up in similar fashion if any code run as part of an END block
> contains a string eval containing an END block.
Now the simple fix would be to just make modperl shift things off as
well (see attached patch to make it use Perl_call_list). Course if
they use ModPerl::Global::special_list_(call|clear) like
t/modperl/endav.t things break. As when we go to run END blocks or
call special_list_call() they will have been shifted off. This might
be acceptable behavior for END blocks, but I can see not wanting to
break other things that use modperl_perl_call_use. Maybe, maybe not.
Thoughts?
Another option would be to copy/local() the array in
modpler_perl_call_list. Of course that still wont get it "right"
because we wont run any newly defined subs... But at least we wont
segfault/crap out.
Thoughts?
--- modperl_util.c.orig 2010-06-28 10:58:53.535686254 -0600
+++ modperl_util.c 2010-06-28 11:01:25.059112059 -0600
@@ -467,30 +467,12 @@
void modperl_perl_call_list(pTHX_ AV *subs, const char *name)
{
-I32 i, oldscope = PL_scopestack_ix;
-SV **ary = AvARRAY(subs);
-
MP_TRACE_g(MP_FUNC, "pid %lu" MP_TRACEf_TID MP_TRACEf_PERLID
" running %d %s subs",
(unsigned long)getpid(), MP_TRACEv_TID_ MP_TRACEv_PERLID_
AvFILLp(subs)+1, name);
-for (i=0; i<=AvFILLp(subs); i++) {
-CV *cv = (CV*)ary[i];
-SV *atsv = ERRSV;
-
-PUSHMARK(PL_stack_sp);
-call_sv((SV*)cv, G_EVAL|G_DISCARD);
-
-if (SvCUR(atsv)) {
-Perl_sv_catpvf(aTHX_ atsv, "%s failed--call queue aborted",
- name);
-while (PL_scopestack_ix > oldscope) {
-LEAVE;
-}
-Perl_croak(aTHX_ "%s", SvPVX(atsv));
-}
-}
+Perl_call_list(aTHX_ PL_scopestack_ix, subs);
}
void modperl_perl_exit(pTHX_ int status)
[Apache::DBI] [PATCH] use PerlChildExitHandler to properly disconnect
This Patch fixes annoying log messages (notably with postgresql, but
others may apply) because Apache::DBI fails to disconnect properly at
exit time.
(it stops the buggers below from filling my logs...)
LOG: unexpected EOF on client connection
LOG: could not receive data from client: Connection reset by peer
Note the first hunk *might* be a bug fix as under MP2
Apache->can('push_handlers') returns false.
It does not look (unless im missing something) like the
PerlCleanupHandler for AutoCommit rollback ever got registered...
(Patch attached as well in case white space damage occurs)
applies cleanly against 1.05/1.06
diff -x '*~' -ruN Apache-DBI-1.05.orig/lib/Apache/DBI.pm
Apache-DBI-1.05/lib/Apache/DBI.pm
--- Apache-DBI-1.05.orig/lib/Apache/DBI.pm 2006-11-03 23:17:44.0 -0700
+++ Apache-DBI-1.05/lib/Apache/DBI.pm 2008-03-12 17:38:37.455592048 -0600
@@ -137,7 +137,7 @@
# script has finished if AutoCommit is off. however, cleanup can only
# be determined at end of handle life as begin_work may have been called
# to temporarily turn off AutoCommit.
-if (!$Rollback{$Idx} and Apache->can('push_handlers')) {
+if (!$Rollback{$Idx} and (Apache->can('push_handlers') || MP2)) {
debug(2, "$prefix push PerlCleanupHandler");
if (MP2) {
my $s = Apache2::ServerUtil->server;
@@ -151,6 +151,17 @@
$Rollback{$Idx} = 1;
}
+if (Apache->can('push_handlers') || MP2) {
+debug(2, "$prefix push PerlChildExitHandler");
+if (MP2) {
+my $s = Apache2::ServerUtil->server;
+$s->push_handlers("PerlChildExitHandler", sub {
child_disconnect($Idx) });
+}
+else {
+Apache->push_handlers("PerlChildExitHandler", sub {
child_disconnect($Idx) });
+}
+}
+
# do we need to ping the database ?
$PingTimeOut{$dsn} = 0 unless $PingTimeOut{$dsn};
$LastPingTime{$dsn} = 0 unless $LastPingTime{$dsn};
@@ -236,6 +247,26 @@
1;
}
+sub child_disconnect {
+my $Idx = shift;
+
+my $prefix = "$$ Apache::DBI";
+debug(2, "$prefix PerlChildExitHandler");
+
+if ($Connected{$Idx}) {
+cleanup($Idx);
+
+{
+package Apache::DBI::db;
+eval { $Connected{$Idx}->SUPER::disconnect(); };
+delete $Connected{$Idx}
+}
+debug(2, "$prefix PerlChildExitHandler disconnect for '$Idx'");
+}
+
+1;
+}
+
# Store the default start state of each dbh in the handle
# Note: This uses private_Apache_DBI hash ref to store it in the handle itself
my @attrs = qw(
apache_dbi_exithandler.patch
Description: Binary data
