perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Hay" <>
Subject RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Date Tue, 14 Feb 2012 14:34:39 GMT
Argh! Just found the cause of the out of memory error: When I had httpd.exe crashing previously
(due to thread context problems revealed by the LimitExcept change) I enabled the page heap
for httpd.exe to trap any writes past allocated memory at the point of occurrence, and I'd
completely forgotten that I'd left it enabled. It seems that it has a significant memory overhead,
and was causing the OOM error itself!

So now that I've disabled the page heap again the complete top-level test suite runs without
error, but now I'm back to the problem that I encountered before after I'd experimentally
tried reverting the LimitExcept change, namely that the entire top-level test suite keeps
getting re-run every time it finishes.

I wonder if it's the bit at the end where it normally cds into the ModPerl-Registry folder
and runs tests in there that is the problem? Perhaps the cd has failed for some reason...

-----Original Message-----
From: Steve Hay [] 
Sent: 14 February 2012 14:15
To: Torsten Förtsch
Cc:; Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

[Apologies for all the top-posting replies, btw. Blame Outlook! I have a macro somewhere to
fix it, but haven't installed it yet on my new machine...]

I've committed the ModPerl::MM fix, renaming $b to $build, and generally borrowing the style
of ModPerl::BuildMM (although it's all rather ugly anyway).

I will try to bisect to find where the OOM crash has crept in.

And I definitely agree that any code commented "should not happen" ought to assert when it
does happen so that we (developers) can catch it in debug builds. To that end, the MP_ASSERT
macro that you've added to the threading branch would be useful to have in trunk ASAP.

-----Original Message-----
From: Torsten Förtsch []
Sent: 14 February 2012 13:19
To: Steve Hay
Cc:; Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 14 February 2012 09:58:51 Steve Hay wrote:
> The patch below fixes the problems with MP_LIBNAME (and cwd) not being 
> set correctly when building Apache::Reload and Apache::SizeLimit.
> The problem was that the file-level $b variable was created only once 
> when ModPerl::MM was first loaded, but that happened before 
> was written. The patch simply rewrites $b 
> (instead of writing a lexical $build which was never used!) later on, 
> by which time has been created.
> If the patch looks ok then shall I apply it before RC2 is rolled?
> (Needless to say, this doesn't fix the more serious problem of the 
> test suite still failing when httpd.exe crashes with an out of memory 
> error part-way through...)
> Index: lib/ModPerl/
> ===================================================================
> --- lib/ModPerl/   (revision 1240026)
> +++ lib/ModPerl/   (working copy)
> @@ -128,7 +128,7 @@
>          $eu_mm_mv_all_methods_overriden++;
>      }
> -    my $build = build_config();
> +    $b = build_config();
>      my_import(__PACKAGE__);
>      # set top-level WriteMakefile's values if weren't set already

Apart from the fact that $b is a really nasty name for a global variable I don't mind. But
that's not your fault. Be it $x or $y or even $B I wouldn't complain either. But $a and $b
look like out of a sort {} block to me.

Why don't you commit the patch and see what happens. The good thing with SVN is that we can
always go back.

On the OOM, is there a special commit where it starts?

While working on the threading branch I discovered at least one occurrence
(modperl_filter_f_cleanup) where an interpreter was used *after* it has been put back to the
pool. That means at this point it might have already been assigned to another thread. Thanks,
Steve, for reminding that Perl sometimes picks the interpreter by PERL_GET_CONTEXT. That was
the key. See "svn log -c1243509" for more information. I don't know if the bug is also present
in trunk but I strongly believe so. In principle this may cause arbitrary effects. The other
occurrence mentioned in the commit message can happen only with "PerlInterpScope handler",
I think.

Another note, I have seen quite a few pieces of code reading:

  if (...) {
    /* should not happen */
    return NULL;

This is really bad because it hides bugs. It does not fix anything. Wouldn't it be better
to abort() here? Or ap_assert()?

Torsten Förtsch

Need professional modperl support? Hire me! (

Like fantasy?

To unsubscribe, e-mail: For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message