Mailing-List: contact dev-help@perl.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of SteveHay@planit.com designates
 213.1.249.253 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Date: Tue, 14 Feb 2012 14:34:39 -0000
Message-ID: <1B32FF956ABF414C9BCE5E487A1497E70C6CF12A@ukmail02.planit.group>
In-Reply-To: <1B32FF956ABF414C9BCE5E487A1497E70C6CF0E7@ukmail02.planit.group>
Thread-Topic: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Thread-Index: AczrG0t+uLF5lBHQSiegSwuO1QmmjgABkFrwAAC7hTA=
References: 
 <CAHrynWC47oKNFP-b514ELo4pLOMS0bUPJ+EOL7jCrS1dvfp60Q@mail.gmail.com>
 <1B32FF956ABF414C9BCE5E487A1497E70C5938EE@ukmail02.planit.group>
 <1B32FF956ABF414C9BCE5E487A1497E70C6CEEFC@ukmail02.planit.group>
 <1734953.78nZS06alG@opi.home>
 <1B32FF956ABF414C9BCE5E487A1497E70C6CF0E7@ukmail02.planit.group>
From: "Steve Hay" <SteveHay@planit.com>
To: =?iso-8859-1?Q?Torsten_F=F6rtsch?= <torsten.foertsch@gmx.net>
Cc: <dev@perl.apache.org>,
	"Fred Moyer" <fred@redhotpenguin.com>

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 [mailto:SteveHay@planit.com]=20
Sent: 14 February 2012 14:15
To: Torsten F=F6rtsch
Cc: dev@perl.apache.org; 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=F6rtsch [mailto:torsten.foertsch@gmx.net]
Sent: 14 February 2012 13:19
To: Steve Hay
Cc: dev@perl.apache.org; 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.
>=20
> The problem was that the file-level $b variable was created only once=20
> when ModPerl::MM was first loaded, but that happened before=20
> Apache2::BuildConfig.pm was written. The patch simply rewrites $b=20
> (instead of writing a lexical $build which was never used!) later on,=20
> by which time Apache2::BuildConfig.pm has been created.
>=20
> If the patch looks ok then shall I apply it before RC2 is rolled?
>=20
> (Needless to say, this doesn't fix the more serious problem of the=20
> test suite still failing when httpd.exe crashes with an out of memory=20
> error part-way through...)
>=20
> Index: lib/ModPerl/MM.pm
> =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> --- lib/ModPerl/MM.pm   (revision 1240026)
> +++ lib/ModPerl/MM.pm   (working copy)
> @@ -128,7 +128,7 @@
>          $eu_mm_mv_all_methods_overriden++;
>      }
>=20
> -    my $build =3D build_config();
> +    $b =3D build_config();
>      my_import(__PACKAGE__);
>=20
>      # 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=F6rtsch

--
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org For additional =
commands, e-mail: dev-help@perl.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org