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:steve...@planit.com] Sent: 14 February 2012 14:15 To: Torsten Förtsch 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örtsch [mailto:torsten.foert...@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. > > The problem was that the file-level $b variable was created only once > when ModPerl::MM was first loaded, but that happened before > Apache2::BuildConfig.pm was written. The patch simply rewrites $b > (instead of writing a lexical $build which was never used!) later on, > by which time Apache2::BuildConfig.pm 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/MM.pm > =================================================================== > --- lib/ModPerl/MM.pm (revision 1240026) > +++ lib/ModPerl/MM.pm (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! (http://foertsch.name) Like fantasy? http://kabatinte.net --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
