 |
|
 |
|
On Tue, 31 Jan 2012 09:41:08 -0000, "Steve Hay" <...@planit.com
The tests are hanging for me - each time it gets as far as
t/modules/include.t and then hangs. If I kill the hung perl.exe then the
next test hangs and so on... The error_log contains nothing unusual.
This was using VC++ 2010 on Win7 x64 with httpd-2.2.21 and bleadperl
(commit 3673acb0ce) built with MYMALLOC and no PERL_IMPLICIT_SYS. I will
try again with an out-of-the-box configuration of perl.
-----Original Message-----
From: Fred Moyer [mai...@redhotpenguin.com]
Sent: 31 January 2012 06:41
To: mod_perl Dev
Subject: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
The mod_perl 2.0.6 first release candidate has arrived! Bundled with
Apache-Test 1.37, Apache-Reload 0.11, and Apache-SizeLimit 0.96.
Please download, test, and report back on this release candiate.
Committers please give a +1 if you are satisfied with the results on
your platform (please report any failing tests you find though still).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
 |
|
 |
|
|
|
|
On Tue, 31 Jan 2012 12:21:41 -0000, "Steve Hay" <...@planit.com
Not entirely successful with a standard build perl either: Initially I
have httpd.exe crash on startup. Reverting the change made in rev.
1145161 for httpd-2.3 fixes that, as I reported once before -
http://marc.info/?l=apache-modperl-dev&m=132206963528352&w=2. (I'm using
httpd-2.2.21, which is the current stable version.)
However, I then find that all tests pass but the entire test sequence
gets re-run again every time it reaches the end, so "nmake test" is
never-ending! Could that be an Apache-Test problem?
(I did see some warnings produced from the Makefile.PL: both
Apache-Reload and Apache-SizeLimit complained "Use of uninitialized
value in concatenation (.) or string at lib/Apache2/Build.pm line 1749"
and "Note (probably harmless): No library found for
/src/modules/perl/.lib", and Apache-Test complained "Argument "3.39_01"
isn't numeric in numeric ge ("Unparsable version '' for prerequisite Apache::Test at
lib/ModPerl/BuildMM.pm line 153".)
-----Original Message-----
From: Steve Hay [mai...@planit.com]
Sent: 31 January 2012 09:41
To: Fred Moyer; mod_perl Dev
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
The tests are hanging for me - each time it gets as far as
t/modules/include.t and then hangs. If I kill the hung perl.exe then the
next test hangs and so on... The error_log contains nothing unusual.
This was using VC++ 2010 on Win7 x64 with httpd-2.2.21 and bleadperl
(commit 3673acb0ce) built with MYMALLOC and no PERL_IMPLICIT_SYS. I will
try again with an out-of-the-box configuration of perl.
-----Original Message-----
From: Fred Moyer [mai...@redhotpenguin.com]
Sent: 31 January 2012 06:41
To: mod_perl Dev
Subject: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
The mod_perl 2.0.6 first release candidate has arrived! Bundled with
Apache-Test 1.37, Apache-Reload 0.11, and Apache-SizeLimit 0.96.
Please download, test, and report back on this release candiate.
Committers please give a +1 if you are satisfied with the results on
your platform (please report any failing tests you find though still).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional
commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 31 Jan 2012 12:29:25 -0800, Fred Moyer <...@redhotpenguin.com
On Tue, Jan 31, 2012 at 4:21 AM, Steve Hay <...@planit.com
Guessing MP_LIBNAME is not getting set correctly.
1747 sub modperl_libs_MSWin32 {
1748 my $self = shift;
1749 "$self-1750 }
Here are the relevant changes from 2.0.5:
svn diff -r1023553 lib/Apache2/Build.pm
Index: lib/Apache2/Build.pm
===================================================================
--- lib/Apache2/Build.pm (revision 1023553)
+++ lib/Apache2/Build.pm (working copy)
@@ -27,6 +27,42 @@
use ExtUtils::Embed ();
use File::Copy ();
+BEGIN { # check for a sane ExtUtils::Embed
+ unless ($ENV{MP_USE_MY_EXTUTILS_EMBED}) {
+ my ($version, $path)=(ExtUtils::Embed-+ $INC{q{ExtUtils/Embed.pm}});
+ my $msg=<<"EOF";
+I have found ExtUtils::Embed $version at
+
+ $path
+
+This is probably not the right one for this perl version. Please make sure
+there is only one version of this module installed and that it is the one
+that comes with this perl version.
+
+If you insist on using the ExtUtils::Embed as is set the environment
+variable MP_USE_MY_EXTUTILS_EMBED=1 and try again.
+
+EOF
+ if (eval {require Module::CoreList}) {
+ my $req=$Module::CoreList::version{$]}-+ die "Please repair your Module::CoreList" unless $req;
+ unless ($version eq $req) {
+ $msg.=("Details: expecting ExtUtils::Embed $req ".
+ "(according to Module::CoreList)\n\n");
+ die $msg;
+ }
+ }
+ else {
+ my $req=$Config{privlib}.'/ExtUtils/Embed.pm';
+ unless ($path eq $req) {
+ $msg.="Details: expecting ExtUtils::Embed at $req\n\n";
+ die $msg;
+ }
+ }
+ }
+}
+
use constant IS_MOD_PERL_BUILD = { -e "$_/Makefile.PL" && -e "$_/lib/mod_perl2.pm" } qw(. ..);
@@ -240,7 +276,8 @@
}
my %threaded_mpms = map { $_ =- qw(worker winnt beos mpmt_os2 netware leader perchild threadpool);
+ qw(worker winnt beos mpmt_os2 netware leader perchild threadpool
+ dynamic);
sub mpm_is_threaded {
my $self = shift;
my $mpm_name = $self-@@ -255,8 +292,16 @@
# XXX: hopefully apxs will work on win32 one day
return $self-
- my $mpm_name = $self-+ my $mpm_name;
+ # httpd + if ($self-+ $mpm_name = 'dynamic';
+ }
+ else {
+ $mpm_name = $self-+ }
+
# building against the httpd source dir
unless (($mpm_name and $self- if ($self-@@ -1108,7 +1153,18 @@
sub apr_generation {
my ($self) = @_;
- return $self-+
+ my $httpd_v = $self-+
+ if ($httpd_v =~ m/2[4-9]\d+/) {
+ return 2;
+ }
+ elsif ($httpd_v =~ m/2[1-3]\d+/) {
+ return 1;
+ }
+ else {
+ return;
+ }
}
# returns an array of apr/apu linking flags (--link-ld --libs) if found
@@ -1168,7 +1224,8 @@
$self- }
- my $config = $self-+ my $apr_generation = $self-+ my $config = $apr_generation ? "$what-${apr_generation}-config" :
"$what-config";
if (!$self- my @tries = ();
@@ -1536,9 +1593,12 @@
require ExtUtils::MakeMaker;
my $mm = bless { @mm_init_vars }, 'MM';
- $mm-- $mm-
+ # Fake initialize MakeMaker
+ foreach my $m (qw(init_main init_others init_tools)) {
+ $mm-+ }
+
for (qw(rm_f mv ld ar cp test_f)) {
my $val = $mm- if ($val) {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 17:53:05 +0100, Torsten Förtsch <...@gmx.net
Thanks. It passes all tests here with linux, perl 5.12.3, worker and prefork.
I think we should simply rename the threading branch to trunk (or the SVN
equivalent of "rename") after 2.0.6. Apart from ~2 changes everything that has
been committed to trunk is also present in threading. And one of those blocked
commits is the reverting of the cmdparams.pm.
Fred, now that the OOM issue has been resolved is there anything left for
2.0.6 other than the Niko Tyni issue? It seems that I have missed a few
messages in that regard. Are the following 2 patches all there is to it?
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=50;filename=0001-Fix-a-
reference-counting-bug-uncovered-by-Perl-5.13..patch;att=2;bug=650675
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=50;filename=0002-Fix-another-
reference-counting-bug-uncovered-by-Perl.patch;att=3;bug=650675
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 09:15:25 -0800, Fred Moyer <...@redhotpenguin.com
That's right those are the two patches. Feedback welcome, cc'ing Niko. Take a look if you can, I'm ready to roll RC2.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 20:31:11 +0100, Torsten Förtsch <...@gmx.net
Committed revision 1244184.
Thanks, Niko, for sorting this out.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 14:50:08 -0800, Fred Moyer <...@redhotpenguin.com
I've pushed RC2 which contains Steve and Niko's fixes. +1 on
2.2.21/5.14.1 and Lion 10.6.
http://people.apache.org/~phred/mod_perl-2.0.6-rc2.tar.gz
MD5 (mod_perl-2.0.6-rc2.tar.gz) = 3bc64d1ab66c29361e8a6a0ee044e667
2012/2/14 Torsten Förtsch <...@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 15 Feb 2012 10:04:27 +0100, Torsten Förtsch <...@gmx.net
+1 opensuse 12.1, self-compiled perls and httpds
| perl 5.12.3 | perl 5.14.2
httpd 2.2.21 | w/ ithreads | w/o ithreads | w/ ithreads
--------------+-------------+--------------+------------
prefork | OK | OK | OK
worker | OK | n/a | OK
$ echo 3bc64d1ab66c29361e8a6a0ee044e667 mod_perl-2.0.6-rc2.tar.gz | md5sum -c
mod_perl-2.0.6-rc2.tar.gz: OK
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 15 Feb 2012 10:17:26 -0000, "Steve Hay" <...@planit.com
All good for me on Win7 x64 with VC++ 2010, httpd 2.2.21 and three different perls: blead in default build, blead with perl's malloc() and no PERL_IMPLICIT_SYS, and 5.12.4 in default build...
... *EXCEPT* for the continuing problem of the test suite re-running at the end.
That problem is caused by r957309, which added "$(MAKE) -k run_subtests" and "$(MAKE) -C ModPerl-Registry test" (and others) directly to Makefile.PL. I guess your make program has different arguments to my nmake program. My nmake's -k means "Build unrelated targets on error", while -C means "Suppress output messages" -- surely not what is needed!
The appended patch restores the original way of running the ModPerl-Registry tests, and appends Apache-Reload and Apache-SizeLimit in similar fashion. This successfully runs the ModPerl-Registry tests (as before), and successfully kicks off "nmake test" in Apache-Reload too, but unfortunately the Apache-Reload tests don't work for me. It crashes out with the same error as if I manually cd into Apache-Reload and run "nmake test", namely:
sorry, cannot run tests without a properly
configured Apache-Test environment, mininum
Apache::Test version needed is 1.3
Looks like Apache-Reload's Makefile.PL went wrong in check_for_apache_test().
The top-level build command that I run is: "perl Makefile.PL MP_AP_PREFIX=/full/path/to/httpd/dir". Debugging inside the Apache-Reload Makefile.PL script I find that MOD_PERL_2_BUILD is set in the environment, but none of MP_APXS, APACHE_TEST_HTTPD or APACHE_TEST_APXS are. So the script pushes "-apxs" onto an initially empty @ARGV, but Apache::TestMM::filter_args() sets @Apache::TestMM::Argv to an empty list (did it want a "value" for the "-apxs" argument?) and hence check_for_apache_test() returns 0.
I notice that the INSTALL file does say to use MP_APXS=... rather than MP_AP_PREFIX=..., but doing so makes no difference to any of the above. Even setting the environment variable MP_APXS to the full path of apxs and then just running "perl Makefile.PL" doesn't work nicely (it asks what the path to apxs is!).
I can make it work by setting APACHE_TEST_HTTPD appropriately and building as usual (with the patch below, this passes all tests at the top-level, in ModPerl-Registry and in Apache-Reload), but it doesn't seem ideal that such a thing is necessary, and INSTALL makes no mention of needing to do it.
One other thing I noticed: the README file says "mod_perl is currently considered beta". Surely it could be changed to say stable by now?
Index: Makefile.PL
===================================================================
--- Makefile.PL (revision 1244410)
+++ Makefile.PL (working copy)
@@ -789,23 +789,16 @@
$(PASSENV) \
$(FULLPERL) -I$(INST_ARCHLIB) -I$(INST_LIB) \
t/TEST -bugreport -verbose=$(TEST_VERBOSE) $(TEST_FILES)
- $(MAKE) -k run_subtests
-
-run_subtests ::
- $(MAKE) -C ModPerl-Registry test
-
-run_subtests ::
- $(MAKE) -C Apache-Reload test
-
+ cd ModPerl-Registry && $(MAKE) test
+ cd Apache-Reload && $(MAKE) test
EOF
$preamble .= <<'EOF' unless $build--run_subtests ::
- $(MAKE) -C Apache-SizeLimit test
-
+ cd Apache-SizeLimit && $(MAKE) test
EOF
$preamble .= <<'EOF';
+
test :: pure_all run_tests test_clean
EOF
End of Patch.
-----Original Message-----
From: Fred Moyer [mai...@redhotpenguin.com]
Sent: 14 February 2012 22:50
To: Torsten Förtsch
Cc: de...@perl.apache.org; Steve Hay; Niko Tyni
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
I've pushed RC2 which contains Steve and Niko's fixes. +1 on
2.2.21/5.14.1 and Lion 10.6.
http://people.apache.org/~phred/mod_perl-2.0.6-rc2.tar.gz
MD5 (mod_perl-2.0.6-rc2.tar.gz) = 3bc64d1ab66c29361e8a6a0ee044e667
2012/2/14 Torsten Förtsch <...@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 8 Feb 2012 09:33:52 -0000, "Steve Hay" <...@planit.com
I was using bleadperl (commit 3673acb0ce). Trying again with perl 5.12.4 I find that by default httpd.exe crashes on startup with the "panic: free from wrong pool" error in modperl_svptr_table_delete() as before -- the my_perl which Safefree() picks up is the wrong one. With my previously posted patch it crashes with that same error a little later on in modperl_env_table_populate(), exactly as for my bleadperl.
I think my patch is good, but clearly isn't the whole story. Either another similar bug is lurking somewhere, or perhaps it's due to problems with the interp pool select code that you've found, because reverting the troublesome LimitExcept change (rev. 1145161) I find that httpd.exe starts up normally and runs ok as far as compat/request_body.t but then httpd.exe crashes with the message "Out of memory!" in the error_log. My patch makes no difference to that. I didn't see that happen with bleadperl, although it had the other problem that I reported before of the entire test suite getting re-run endlessly instead.
I also still have the warnings from Makefile.PL that I reported before too, which Fred guessed are due to MP_LIBNAME not getting set correctly. I haven't had a chance to look further into that yet, sorry :-(
As before, this is all with httpd 2.2.21, with everything built from source in default configurations using VC++ 2010.
-----Original Message-----
From: Torsten Förtsch [mai...@gmx.net]
Sent: 07 February 2012 17:02
To: de...@perl.apache.org
Cc: Fred Moyer; Steve Hay
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
I think perhaps I have found the culprit. modperl has 2 ways of assigning a perl interpreter to the request. One is modperl_interp_select() that can be used if we have either a request_rec* or a conn_rec* or a server_rec*. The other is modperl_interp_pool_select() which is in my opinion basically a hack to work around the situation when one of the above is hidden on the stack somewhere but currently not accessible. To do this modperl_interp_select() ties the interpreter to a pool by storing it in the pool userdata hash. This pool might be a conn_req or request_rec pool depending on PerlInterpScope.
Now, when modperl_interp_pool_select() is called it hopes that the pool it is passed already contains an interpreter. If so, all is fine. Otherwise,
modperl_interp_pool_select() hopes that the server_rec it is also passed (or rather the mip stored there) matches the current request. Unfortunately, this assumption is false for dir config merger functions. That's what the XXX comment below is about.
modperl_module.c has this piece of code:
/*
* XXX: vhosts may have different parent interpreters.
*/
static void *modperl_module_config_merge(apr_pool_t *p,
void *basev, void *addv,
int type) { ...
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
MP_PERL_CONTEXT_STORE_OVERRIDE(interp-#endif
The first request in t/directive/perlrequire.t is a good test to show the problem. With change 1145161 it fails reliably, without it succeeds.
Now, if I set a breakpoint on modperl_interp_pool_select() it is hit only with change 1145161. Without it modperl_interp_pool_select() is not reached.
So, without 1145161 the interpreter is assigned by modperl_interp_select() while with it modperl_interp_pool_select() tries to do it (and picks the wrong interpreter pool).
Breakpoint 1, modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
341 int is_startup = (p == s-(gdb) bt
#0 modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
#1 0x00007f6596ab2241 in modperl_module_config_merge (p=0x7f65840028f8, basev=0x2d2a9d0, addv=0x2d2c210, type=1) at modperl_module.c:186
#2 0x00007f6596ab2b83 in modperl_module_config_dir_merge (p=0x7f65840028f8, basev=0x2d2a9d0, addv=0x2d2c210) at modperl_module.c:260
#3 0x000000000043d598 in ap_merge_per_dir_configs (p=0x7f65840028f8, base=0x2de09a0, new_conf=0x7f6584009470) at config.c:248
#4 0x00000000004387d2 in ap_directory_walk (r=0x7f6584002970) at request.c:1195
#5 0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
#6 0x0000000000437978 in ap_run_map_to_storage (r=0x7f6584002970) at request.c:69
#7 0x0000000000439b38 in ap_process_request_internal (r=0x7f6584002970) at request.c:150
#8 0x000000000044a490 in ap_process_request (r=0x7f6584002970) at http_request.c:280
#9 0x0000000000447478 in ap_process_http_connection (c=0x7f6588003748) at http_core.c:190
#10 0x0000000000443898 in ap_run_process_connection (c=0x7f6588003748) at connection.c:43
#11 0x00000000004505b1 in process_socket (bucket_alloc=<optimized out#12 worker_thread (thd=0x2daf638, dummy=<optimized out#13 0x00007f65a0c64f05 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f65a07a363d in ?? () from /lib64/libc.so.6
#15 0x0000000000000000 in ?? ()
Now, if we look at the server_rec passed to modperl_interp_pool_select() it turns out to be the default server listening on localhost:8529.
(gdb) dump_server_rec s
name=localhost:8529
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
While r-
(gdb) up 5
#5 0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
3621 if ((access_status = ap_directory_walk(r))) {
(gdb) dump_server_rec r-name=localhost:8560
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
(gdb)
What to do now? I'd suggest to revert change 1145161 and get 2.0.6 out (perhaps with Steve's latest patch). Steve, do you use perl 5.14? If yes, can you try if you see the "panic: free from wrong pool" also with 5.12?
After that, we should merge the threading branch. There at the very beginning of a request the request_rec is stored as pool userdata in the request pool. Thus, modperl_interp_pool_select() can fetch it from there and then use r-
The other way would be to make sure there is an interpreter in the request pool before core_map_to_storage(). I think this would make the current mess even worse.
Thoughts?
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 09:58:51 -0000, "Steve Hay" <...@planit.com
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
-----Original Message-----
From: Steve Hay [mai...@planit.com]
Sent: 08 February 2012 09:34
To: Torsten Förtsch; de...@perl.apache.org
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
[...]
I also still have the warnings from Makefile.PL that I reported before too, which Fred guessed are due to MP_LIBNAME not getting set correctly. I haven't had a chance to look further into that yet, sorry :-(
As before, this is all with httpd 2.2.21, with everything built from source in default configurations using VC++ 2010.
-----Original Message-----
From: Torsten Förtsch [mai...@gmx.net]
Sent: 07 February 2012 17:02
To: de...@perl.apache.org
Cc: Fred Moyer; Steve Hay
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
I think perhaps I have found the culprit. modperl has 2 ways of assigning a perl interpreter to the request. One is modperl_interp_select() that can be used if we have either a request_rec* or a conn_rec* or a server_rec*. The other is modperl_interp_pool_select() which is in my opinion basically a hack to work around the situation when one of the above is hidden on the stack somewhere but currently not accessible. To do this modperl_interp_select() ties the interpreter to a pool by storing it in the pool userdata hash. This pool might be a conn_req or request_rec pool depending on PerlInterpScope.
Now, when modperl_interp_pool_select() is called it hopes that the pool it is passed already contains an interpreter. If so, all is fine. Otherwise,
modperl_interp_pool_select() hopes that the server_rec it is also passed (or rather the mip stored there) matches the current request. Unfortunately, this assumption is false for dir config merger functions. That's what the XXX comment below is about.
modperl_module.c has this piece of code:
/*
* XXX: vhosts may have different parent interpreters.
*/
static void *modperl_module_config_merge(apr_pool_t *p,
void *basev, void *addv,
int type) { ...
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
MP_PERL_CONTEXT_STORE_OVERRIDE(interp-#endif
The first request in t/directive/perlrequire.t is a good test to show the problem. With change 1145161 it fails reliably, without it succeeds.
Now, if I set a breakpoint on modperl_interp_pool_select() it is hit only with change 1145161. Without it modperl_interp_pool_select() is not reached.
So, without 1145161 the interpreter is assigned by modperl_interp_select() while with it modperl_interp_pool_select() tries to do it (and picks the wrong interpreter pool).
Breakpoint 1, modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
341 int is_startup = (p == s-(gdb) bt
#0 modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
#1 0x00007f6596ab2241 in modperl_module_config_merge (p=0x7f65840028f8, basev=0x2d2a9d0, addv=0x2d2c210, type=1) at modperl_module.c:186
#2 0x00007f6596ab2b83 in modperl_module_config_dir_merge (p=0x7f65840028f8, basev=0x2d2a9d0, addv=0x2d2c210) at modperl_module.c:260
#3 0x000000000043d598 in ap_merge_per_dir_configs (p=0x7f65840028f8, base=0x2de09a0, new_conf=0x7f6584009470) at config.c:248
#4 0x00000000004387d2 in ap_directory_walk (r=0x7f6584002970) at request.c:1195
#5 0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
#6 0x0000000000437978 in ap_run_map_to_storage (r=0x7f6584002970) at request.c:69
#7 0x0000000000439b38 in ap_process_request_internal (r=0x7f6584002970) at request.c:150
#8 0x000000000044a490 in ap_process_request (r=0x7f6584002970) at http_request.c:280
#9 0x0000000000447478 in ap_process_http_connection (c=0x7f6588003748) at http_core.c:190
#10 0x0000000000443898 in ap_run_process_connection (c=0x7f6588003748) at connection.c:43
#11 0x00000000004505b1 in process_socket (bucket_alloc=<optimized out#12 worker_thread (thd=0x2daf638, dummy=<optimized out#13 0x00007f65a0c64f05 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f65a07a363d in ?? () from /lib64/libc.so.6
#15 0x0000000000000000 in ?? ()
Now, if we look at the server_rec passed to modperl_interp_pool_select() it turns out to be the default server listening on localhost:8529.
(gdb) dump_server_rec s
name=localhost:8529
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
While r-
(gdb) up 5
#5 0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
3621 if ((access_status = ap_directory_walk(r))) {
(gdb) dump_server_rec r-name=localhost:8560
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
(gdb)
What to do now? I'd suggest to revert change 1145161 and get 2.0.6 out (perhaps with Steve's latest patch). Steve, do you use perl 5.14? If yes, can you try if you see the "panic: free from wrong pool" also with 5.12?
After that, we should merge the threading branch. There at the very beginning of a request the request_rec is stored as pool userdata in the request pool. Thus, modperl_interp_pool_select() can fetch it from there and then use r-
The other way would be to make sure there is an interpreter in the request pool before core_map_to_storage(). I think this would make the current mess even worse.
Thoughts?
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 14:19:20 +0100, Torsten Förtsch <...@gmx.net
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-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 14:15:25 -0000, "Steve Hay" <...@planit.com
[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 [mai...@gmx.net]
Sent: 14 February 2012 13:19
To: Steve Hay
Cc: de...@perl.apache.org; Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
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-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 14 Feb 2012 14:34:39 -0000, "Steve Hay" <...@planit.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 [mai...@planit.com]
Sent: 14 February 2012 14:15
To: Torsten Förtsch
Cc: de...@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 [mai...@gmx.net]
Sent: 14 February 2012 13:19
To: Steve Hay
Cc: de...@perl.apache.org; Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
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-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Sat, 11 Feb 2012 09:49:40 -0800, Fred Moyer <...@redhotpenguin.com
On Fri, Feb 10, 2012 at 10:51 PM, Niko Tyni <...@debian.org
Looks like it made it through. Suggest inlining your patches next
time instead of using attachments, sometimes the list code may filter
on those.
I looked through the patches and grok the syntax, but the finer
details aren't clear to me yet. Maybe some of the other devs
(gozer,steve,torsten) can comment on them. I'll hold rc2 for a few
days to give them a chance to respond.
Can you post some of that error log which shows the error?
Thanks for the contribution. Anyone else here see those errors
previously, or can reproduce them now?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Mon, 13 Feb 2012 20:53:33 -0800, Fred Moyer <...@redhotpenguin.com
On Mon, Feb 13, 2012 at 10:49 AM, Niko Tyni <...@debian.org
Is gtop desired for any particular reason? I would think production
machines may not want it enabled by default.
That's a pretty old APR, considering you're using httpd 2.2.22. Is
there a specific reason?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Fri, 17 Feb 2012 10:43:08 +0200, Niko Tyni <...@debian.org
No idea, it looks like it's been that way forever. Thanks for the
note, I've filed http://bugs.debian.org/660184 to get it removed.
It's really APR 1.4.5. I don't know why there's 1.0 in the name,
but that's where the headers are here.
As for the 'unreferenced scalar' issue, I can confirm that RC2
fixes the issue for me. Thanks, Torsten!
--
Niko Tyni ntyn...@debian.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Mon, 13 Feb 2012 10:52:39 -0800, Fred Moyer <...@redhotpenguin.com
Niko, are you subscribed to de...@perl.apache.org? Can you please check your subscription status?
Looks like your post didn't make it through to the gossamer archive - http://www.gossamer-threads.com/lists/modperl/dev/103847
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Mon, 13 Feb 2012 09:15:34 -0000, "Steve Hay" <...@planit.com
I'm afraid the details are not clear to me either, but I have tried the two patches out (after correcting an instance of code-before-declaration which VC++ doesn't accept in C files) and I find that (with the LimitExcept change reverted as per current svn Trunk) they make no visible difference to my setup: I don't see the "free unreferenced scalar" errors in the log file after running the tests with or without the patches, but I do still get an "Out of memory!" crash mid-way through the test suite either way :-(
-----Original Message-----
From: Fred Moyer [mai...@redhotpenguin.com]
Sent: 11 February 2012 17:50
To: Niko Tyni
Cc: de...@perl.apache.org; 6506...@bugs.debian.org
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
On Fri, Feb 10, 2012 at 10:51 PM, Niko Tyni <...@debian.org
Looks like it made it through. Suggest inlining your patches next time instead of using attachments, sometimes the list code may filter on those.
I looked through the patches and grok the syntax, but the finer details aren't clear to me yet. Maybe some of the other devs
(gozer,steve,torsten) can comment on them. I'll hold rc2 for a few days to give them a chance to respond.
Can you post some of that error log which shows the error?
Thanks for the contribution. Anyone else here see those errors previously, or can reproduce them now?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 31 Jan 2012 15:32:44 +0100, Torsten Förtsch <...@gmx.net
opensuse 12.1 self-compiled apache 2.2.21, perl 5.12.3
prefork: all tests pass successfully
worker: I see the same behavior as Steve. I can also confirm that r1145161 is
the first commit that shows this behavior. Blame on me!
$ svn diff -c1145161
Index: t/response/TestDirective/cmdparms.pm
===================================================================
--- t/response/TestDirective/cmdparms.pm (revision 1145160)
+++ t/response/TestDirective/cmdparms.pm (revision 1145161)
@@ -134,6 +134,8 @@
TestCmdParms "Location"
-<LimitExcept GET- TestCmdParms "Limit"
-</LimitExcept+<Directory /+ <LimitExcept GET+ TestCmdParms "Limit"
+ </LimitExcept+</Directory
looks quite innocent.
Except without the change the limit is part of the server's base config. With
it it will be merged at request time.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 01 Feb 2012 15:30:10 -0500, "Philippe M. Chiasson" <...@ectoplasm.org
Fedora 16 x86_64 with system perl and httpd.
All tests pass OK except for a known bug in Fedora httpd's server string.
--
Philippe M. Chiasson GPG: F9BFE0C2480E7680 1AE53631CB32A107 88C3A5A5
http://gozer.ectoplasm.org/ m/go...@(apache|cpan|ectoplasm)\.org/
|
|
|
|
|
|
|
|
|
On Tue, 31 Jan 2012 12:00:17 -0800, Fred Moyer <...@redhotpenguin.com
So this happens with worker only - something to do with threading and the command directive code? I don't understand the guts there yet, trying to get a high level view to know where to look.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 01 Feb 2012 13:50:17 +0100, Torsten Förtsch <...@gmx.net
Worker + threading - yes. Command directive code - not so sure. It can be
basically everywhere in the code. The change in cmdparms.pm just modifies the
memory layout a bit and now the stray pointer access changes a vital bit. That
is what I suspect happens.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 07 Feb 2012 18:01:50 +0100, Torsten Förtsch <...@gmx.net
I think perhaps I have found the culprit. modperl has 2 ways of assigning
a perl interpreter to the request. One is modperl_interp_select() that can
be used if we have either a request_rec* or a conn_rec* or a server_rec*. The
other is modperl_interp_pool_select() which is in my opinion basically a hack
to work around the situation when one of the above is hidden on the stack
somewhere but currently not accessible. To do this modperl_interp_select()
ties the interpreter to a pool by storing it in the pool userdata hash. This
pool might be a conn_req or request_rec pool depending on PerlInterpScope.
Now, when modperl_interp_pool_select() is called it hopes that the pool it
is passed already contains an interpreter. If so, all is fine. Otherwise,
modperl_interp_pool_select() hopes that the server_rec it is also passed
(or rather the mip stored there) matches the current request. Unfortunately,
this assumption is false for dir config merger functions. That's what the
XXX comment below is about.
modperl_module.c has this piece of code:
/*
* XXX: vhosts may have different parent interpreters.
*/
static void *modperl_module_config_merge(apr_pool_t *p,
void *basev, void *addv,
int type)
{
...
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
MP_PERL_CONTEXT_STORE_OVERRIDE(interp-#endif
The first request in t/directive/perlrequire.t is a good test to show the
problem. With change 1145161 it fails reliably, without it succeeds.
Now, if I set a breakpoint on modperl_interp_pool_select() it is hit only
with change 1145161. Without it modperl_interp_pool_select() is not reached.
So, without 1145161 the interpreter is assigned by modperl_interp_select()
while with it modperl_interp_pool_select() tries to do it (and picks the
wrong interpreter pool).
Breakpoint 1, modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
341 int is_startup = (p == s-(gdb) bt
#0 modperl_interp_pool_select (p=0x7f65840028f8, s=0x686848) at modperl_interp.c:341
#1 0x00007f6596ab2241 in modperl_module_config_merge (p=0x7f65840028f8, basev=0x2d2a9d0, addv=0x2d2c210, type=1) at modperl_module.c:186
#2 0x00007f6596ab2b83 in modperl_module_config_dir_merge (p=0x7f65840028f8, basev=0x2d2a9d0, addv=0x2d2c210) at modperl_module.c:260
#3 0x000000000043d598 in ap_merge_per_dir_configs (p=0x7f65840028f8, base=0x2de09a0, new_conf=0x7f6584009470) at config.c:248
#4 0x00000000004387d2 in ap_directory_walk (r=0x7f6584002970) at request.c:1195
#5 0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
#6 0x0000000000437978 in ap_run_map_to_storage (r=0x7f6584002970) at request.c:69
#7 0x0000000000439b38 in ap_process_request_internal (r=0x7f6584002970) at request.c:150
#8 0x000000000044a490 in ap_process_request (r=0x7f6584002970) at http_request.c:280
#9 0x0000000000447478 in ap_process_http_connection (c=0x7f6588003748) at http_core.c:190
#10 0x0000000000443898 in ap_run_process_connection (c=0x7f6588003748) at connection.c:43
#11 0x00000000004505b1 in process_socket (bucket_alloc=<optimized out#12 worker_thread (thd=0x2daf638, dummy=<optimized out#13 0x00007f65a0c64f05 in start_thread () from /lib64/libpthread.so.0
#14 0x00007f65a07a363d in ?? () from /lib64/libc.so.6
#15 0x0000000000000000 in ?? ()
Now, if we look at the server_rec passed to modperl_interp_pool_select() it
turns out to be the default server listening on localhost:8529.
(gdb) dump_server_rec s
name=localhost:8529
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
While r-
(gdb) up 5
#5 0x0000000000433c59 in core_map_to_storage (r=0x7f6584002970) at core.c:3621
3621 if ((access_status = ap_directory_walk(r))) {
(gdb) dump_server_rec r-name=localhost:8560
process_rec=0x67d218:
pool=0x67d128, pconf=0x67f138
(gdb)
What to do now? I'd suggest to revert change 1145161 and get 2.0.6 out
(perhaps with Steve's latest patch). Steve, do you use perl 5.14? If
yes, can you try if you see the "panic: free from wrong pool" also with
5.12?
After that, we should merge the threading branch. There at the very
beginning of a request the request_rec is stored as pool userdata in
the request pool. Thus, modperl_interp_pool_select() can fetch it from
there and then use r-
The other way would be to make sure there is an interpreter in the
request pool before core_map_to_storage(). I think this would make
the current mess even worse.
Thoughts?
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Fri, 10 Feb 2012 19:30:42 +0100, Torsten Förtsch <...@gmx.net
By now I think Steve's patch should not be necessary. I believe the wrong
context is a result of using the wrong interpreter pool in the directory
merge.
I think it is a bug if at that point aTHX differs from PERL_GET_CONTEXT. So, I
added the following macros to the threading branch.
#ifdef MP_DEBUG
# define MP_ASSERT(exp) ap_assert(exp)
#else
# define MP_ASSERT(exp) ((void)0)
#endif
#ifdef USE_ITHREADS
# define MP_ASSERT_CONTEXT(perl) MP_ASSERT((perl) == PERL_GET_CONTEXT)
#else
# define MP_ASSERT_CONTEXT(perl) ((void)0)
#endif
The latter macro is then used in modperl_module_config_obj_cleanup() to check
the context:
static apr_status_t modperl_module_config_obj_cleanup(void *data)
{
config_obj_cleanup_t *cleanup =
(config_obj_cleanup_t *)data;
dTHXa(cleanup-
MP_ASSERT_CONTEXT(aTHX);
modperl_svptr_table_delete(aTHX_ cleanup-
MP_TRACE_c(MP_FUNC, "deleting ptr 0x%lx from table 0x%lx",
(unsigned long)cleanup- (unsigned long)cleanup-
return APR_SUCCESS;
}
Meanwhile, I have reverted change 1145161 in trunk.
Fred, could you please roll another rc?
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Fri, 10 Feb 2012 10:36:57 -0800, Fred Moyer <...@redhotpenguin.com
I didn't see the commit message, but verified 'svn update' resulted in a change.
Should we add a Changes entry for this? I'll roll another rc tonight
or tomorrow. Thanks for the work on this guys.
2012/2/10 Torsten Förtsch <...@gmx.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Fri, 10 Feb 2012 20:35:35 +0100, Torsten Förtsch <...@gmx.net
Don't think so. What do we have svn commit messages for? I think an entry in
the Changes file should be a bit more substantial.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Tue, 31 Jan 2012 18:38:24 +0100, Torsten Förtsch <...@gmx.net
Working with r1145161, the minimal set of tests to trigger the bug is this (so
far):
t/TEST t/apache/add_config.t \
t/apache/conftree.t \
t/apache/constants.t \
t/apache/content_length_header.t \
t/apache/daemon.t \
t/apache/post.t \
t/apache/read.t \
t/apache/read2.t \
t/apache/read3.t \
t/apache/scanhdrs.t \
t/apache/scanhdrs2.t \
t/apache/send_cgi_header.t \
t/apache/subprocess.t
Now, it chokes in subprocess.t instead of command.t.
It does not fail on every run. If it does I get in the error_log this line:
Usage: DynaLoader::dl_load_file(filename, flags=0).
I suspect that some piece of code writes to a random location. But I really
don't know how to start to debug that best given the sheer number of tests
(409) in this set.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 1 Feb 2012 09:55:08 -0000, "Steve Hay" <...@planit.com
Starting up the server as per "make test", attaching to it in a debugger with a breakpoint in modperl_response_handler_cgi() and then using lwp-request to GET /apache/add_config I find that it crashes every time with a "panic: free from wrong pool" error. Stack trace is:
mod_perl.so!modperl_svptr_table_delete(interpreter * my_perl, ptr_tbl * tbl, void * key) Line 152 + 0xa bytes C
mod_perl.so!modperl_module_config_obj_cleanup(void * data) Line 121 + 0x17 bytes C
libapr-1.dll!run_cleanups(cleanup_t * * cref) Line 2346 + 0xf bytes C
libapr-1.dll!apr_pool_destroy(apr_pool_t * pool) Line 809 + 0xc bytes C
libhttpd.dll!ap_destroy_sub_req(request_rec * r) Line 1944 C
libhttpd.dll!ap_add_cgi_vars(request_rec * r) Line 392 C
mod_perl.so!modperl_env_request_populate(interpreter * my_perl, request_rec * r) Line 381 C
mod_perl.so!modperl_response_handler_cgi(request_rec * r) Line 1083 + 0xd bytes C
libhttpd.dll!ap_run_handler(request_rec * r) Line 158 + 0x50 bytes C
libhttpd.dll!ap_invoke_handler(request_rec * r) Line 376 + 0x9 bytes C
libhttpd.dll!ap_process_request(request_rec * r) Line 282 + 0x9 bytes C
libhttpd.dll!ap_process_http_connection(conn_rec * c) Line 190 + 0x9 bytes C
libhttpd.dll!ap_run_process_connection(conn_rec * c) Line 43 + 0x50 bytes C
libhttpd.dll!ap_process_connection(conn_rec * c, void * csd) Line 192 C
libhttpd.dll!worker_main(void * thread_num_val) Line 784 C
msvcr100d.dll!_callthreadstartex() Line 314 + 0xf bytes C
msvcr100d.dll!_threadstartex(void * ptd) Line 297 C
kernel32.dll!760b339a()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77c09ef2()
ntdll.dll!77c09ec5()
-----Original Message-----
From: Torsten Förtsch [mai...@gmx.net]
Sent: 31 January 2012 17:38
To: de...@perl.apache.org
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Working with r1145161, the minimal set of tests to trigger the bug is this (so
far):
t/TEST t/apache/add_config.t \
t/apache/conftree.t \
t/apache/constants.t \
t/apache/content_length_header.t \
t/apache/daemon.t \
t/apache/post.t \
t/apache/read.t \
t/apache/read2.t \
t/apache/read3.t \
t/apache/scanhdrs.t \
t/apache/scanhdrs2.t \
t/apache/send_cgi_header.t \
t/apache/subprocess.t
Now, it chokes in subprocess.t instead of command.t.
It does not fail on every run. If it does I get in the error_log this line:
Usage: DynaLoader::dl_load_file(filename, flags=0).
I suspect that some piece of code writes to a random location. But I really don't know how to start to debug that best given the sheer number of tests
(409) in this set.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Wed, 1 Feb 2012 15:15:43 -0000, "Steve Hay" <...@planit.com
The crash happens deleting the ptr_table, complaining that the wrong PerlInterpreter is being used (the "free from wrong pool" error).
There are two PerlInterperters in modperl_svptr_table_clone() -- aTHX (my_perl) and proto_perl. Looking at the memory addresses, I see that my_perl is the same as used throughout the calls in the stack trace below, but the value of aTHX in the crashing Perl_safesysfree() is the other value -- the proto_perl value from our clone call.
Is cleanup-
Is it relevant that we don't set the proto_perl or new_perl members of the CLONE_PARAMS? And/or is it related to the fairly recent addition of the new_perl member in http://perl5.git.perl.org/perl.git/commit/1db366cc74 ?
-----Original Message-----
From: Steve Hay [mai...@planit.com]
Sent: 01 February 2012 09:55
To: Torsten Förtsch; de...@perl.apache.org
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Starting up the server as per "make test", attaching to it in a debugger with a breakpoint in modperl_response_handler_cgi() and then using lwp-request to GET /apache/add_config I find that it crashes every time with a "panic: free from wrong pool" error. Stack trace is:
mod_perl.so!modperl_svptr_table_delete(interpreter * my_perl, ptr_tbl * tbl, void * key) Line 152 + 0xa bytes C
mod_perl.so!modperl_module_config_obj_cleanup(void * data) Line 121 + 0x17 bytes C
libapr-1.dll!run_cleanups(cleanup_t * * cref) Line 2346 + 0xf bytes C
libapr-1.dll!apr_pool_destroy(apr_pool_t * pool) Line 809 + 0xc bytes C
libhttpd.dll!ap_destroy_sub_req(request_rec * r) Line 1944 C
libhttpd.dll!ap_add_cgi_vars(request_rec * r) Line 392 C
mod_perl.so!modperl_env_request_populate(interpreter * my_perl, request_rec * r) Line 381 C
mod_perl.so!modperl_response_handler_cgi(request_rec * r) Line 1083 + 0xd bytes C
libhttpd.dll!ap_run_handler(request_rec * r) Line 158 + 0x50 bytes C
libhttpd.dll!ap_invoke_handler(request_rec * r) Line 376 + 0x9 bytes C
libhttpd.dll!ap_process_request(request_rec * r) Line 282 + 0x9 bytes C
libhttpd.dll!ap_process_http_connection(conn_rec * c) Line 190 + 0x9 bytes C
libhttpd.dll!ap_run_process_connection(conn_rec * c) Line 43 + 0x50 bytes C
libhttpd.dll!ap_process_connection(conn_rec * c, void * csd) Line 192 C
libhttpd.dll!worker_main(void * thread_num_val) Line 784 C
msvcr100d.dll!_callthreadstartex() Line 314 + 0xf bytes C
msvcr100d.dll!_threadstartex(void * ptd) Line 297 C
kernel32.dll!760b339a()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77c09ef2()
ntdll.dll!77c09ec5()
-----Original Message-----
From: Torsten Förtsch [mai...@gmx.net]
Sent: 31 January 2012 17:38
To: de...@perl.apache.org
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Working with r1145161, the minimal set of tests to trigger the bug is this (so
far):
t/TEST t/apache/add_config.t \
t/apache/conftree.t \
t/apache/constants.t \
t/apache/content_length_header.t \
t/apache/daemon.t \
t/apache/post.t \
t/apache/read.t \
t/apache/read2.t \
t/apache/read3.t \
t/apache/scanhdrs.t \
t/apache/scanhdrs2.t \
t/apache/send_cgi_header.t \
t/apache/subprocess.t
Now, it chokes in subprocess.t instead of command.t.
It does not fail on every run. If it does I get in the error_log this line:
Usage: DynaLoader::dl_load_file(filename, flags=0).
I suspect that some piece of code writes to a random location. But I really don't know how to start to debug that best given the sheer number of tests
(409) in this set.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|
|
|
On Thu, 2 Feb 2012 15:02:48 -0000, "Steve Hay" <...@planit.com
The deletion of the ptr_table uses Safefree(), which picks up the context from PERL_GET_CONTEXT, so simply assigning cleanup-
The following patch fixes this by utilizing MP_PERL_CONTEXT_STORE_OVERRIDE / MP_PERL_CONTEXT_RESTORE as is done by modperl_module_config_merge():
--- modperl_module.c.orig Fri May 13 07:18:04 2011
+++ modperl_module.c Thu Feb 02 14:09:46 2012
@@ -116,9 +116,16 @@
{
config_obj_cleanup_t *cleanup =
(config_obj_cleanup_t *)data;
- dTHXa(cleanup-+#ifdef USE_ITHREADS
+ MP_PERL_CONTEXT_DECLARE;
+ MP_PERL_CONTEXT_STORE_OVERRIDE(cleanup-+#endif
modperl_svptr_table_delete(aTHX_ cleanup-+
+#ifdef USE_ITHREADS
+ MP_PERL_CONTEXT_RESTORE;
+#endif
MP_TRACE_c(MP_FUNC, "deleting ptr 0x%lx from table 0x%lx",
(unsigned long)cleanup-End of Patch.
That allows the server to get a little further through handling the response, but it still crashes with another free from wrong pool error a few lines later :-( The stack trace is now:
perl515.dll!S_hsplit(interpreter * my_perl, hv * hv) Line 1157 + 0xc bytes C
perl515.dll!Perl_hv_common(interpreter * my_perl, hv * hv, sv * keysv, const char * key, unsigned int klen, int flags, int action, sv * val, unsigned long hash) Line 813 + 0xd bytes C
perl515.dll!Perl_hv_common_key_len(interpreter * my_perl, hv * hv, const char * key, long klen_i32, const int action, sv * val, const unsigned long hash) Line 332 + 0x27 bytes C
mod_perl.so!modperl_env_table_populate(interpreter * my_perl, apr_table_t * table) Line 132 + 0xb3 bytes C
mod_perl.so!modperl_env_request_populate(interpreter * my_perl, request_rec * r) Line 381 + 0x13 bytes C
mod_perl.so!modperl_response_handler_cgi(request_rec * r) Line 1083 + 0xd bytes C
libhttpd.dll!ap_run_handler(request_rec * r) Line 158 + 0x50 bytes C
libhttpd.dll!ap_invoke_handler(request_rec * r) Line 376 + 0x9 bytes C
libhttpd.dll!ap_process_request(request_rec * r) Line 282 + 0x9 bytes C
libhttpd.dll!ap_process_http_connection(conn_rec * c) Line 190 + 0x9 bytes C
libhttpd.dll!ap_run_process_connection(conn_rec * c) Line 43 + 0x50 bytes C
libhttpd.dll!ap_process_connection(conn_rec * c, void * csd) Line 192 C
libhttpd.dll!worker_main(void * thread_num_val) Line 784 C
msvcr100d.dll!_callthreadstartex() Line 314 + 0xf bytes C
msvcr100d.dll!_threadstartex(void * ptd) Line 297 C
kernel32.dll!760b339a()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77c09ef2()
ntdll.dll!77c09ec5()
-----Original Message-----
From: Steve Hay [mai...@planit.com]
Sent: 01 February 2012 15:16
To: Torsten Förtsch; de...@perl.apache.org
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
The crash happens deleting the ptr_table, complaining that the wrong PerlInterpreter is being used (the "free from wrong pool" error).
There are two PerlInterperters in modperl_svptr_table_clone() -- aTHX (my_perl) and proto_perl. Looking at the memory addresses, I see that my_perl is the same as used throughout the calls in the stack trace below, but the value of aTHX in the crashing Perl_safesysfree() is the other value -- the proto_perl value from our clone call.
Is cleanup-
Is it relevant that we don't set the proto_perl or new_perl members of the CLONE_PARAMS? And/or is it related to the fairly recent addition of the new_perl member in http://perl5.git.perl.org/perl.git/commit/1db366cc74 ?
-----Original Message-----
From: Steve Hay [mai...@planit.com]
Sent: 01 February 2012 09:55
To: Torsten Förtsch; de...@perl.apache.org
Cc: Fred Moyer
Subject: RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Starting up the server as per "make test", attaching to it in a debugger with a breakpoint in modperl_response_handler_cgi() and then using lwp-request to GET /apache/add_config I find that it crashes every time with a "panic: free from wrong pool" error. Stack trace is:
mod_perl.so!modperl_svptr_table_delete(interpreter * my_perl, ptr_tbl * tbl, void * key) Line 152 + 0xa bytes C
mod_perl.so!modperl_module_config_obj_cleanup(void * data) Line 121 + 0x17 bytes C
libapr-1.dll!run_cleanups(cleanup_t * * cref) Line 2346 + 0xf bytes C
libapr-1.dll!apr_pool_destroy(apr_pool_t * pool) Line 809 + 0xc bytes C
libhttpd.dll!ap_destroy_sub_req(request_rec * r) Line 1944 C
libhttpd.dll!ap_add_cgi_vars(request_rec * r) Line 392 C
mod_perl.so!modperl_env_request_populate(interpreter * my_perl, request_rec * r) Line 381 C
mod_perl.so!modperl_response_handler_cgi(request_rec * r) Line 1083 + 0xd bytes C
libhttpd.dll!ap_run_handler(request_rec * r) Line 158 + 0x50 bytes C
libhttpd.dll!ap_invoke_handler(request_rec * r) Line 376 + 0x9 bytes C
libhttpd.dll!ap_process_request(request_rec * r) Line 282 + 0x9 bytes C
libhttpd.dll!ap_process_http_connection(conn_rec * c) Line 190 + 0x9 bytes C
libhttpd.dll!ap_run_process_connection(conn_rec * c) Line 43 + 0x50 bytes C
libhttpd.dll!ap_process_connection(conn_rec * c, void * csd) Line 192 C
libhttpd.dll!worker_main(void * thread_num_val) Line 784 C
msvcr100d.dll!_callthreadstartex() Line 314 + 0xf bytes C
msvcr100d.dll!_threadstartex(void * ptd) Line 297 C
kernel32.dll!760b339a()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!77c09ef2()
ntdll.dll!77c09ec5()
-----Original Message-----
From: Torsten Förtsch [mai...@gmx.net]
Sent: 31 January 2012 17:38
To: de...@perl.apache.org
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1
Working with r1145161, the minimal set of tests to trigger the bug is this (so
far):
t/TEST t/apache/add_config.t \
t/apache/conftree.t \
t/apache/constants.t \
t/apache/content_length_header.t \
t/apache/daemon.t \
t/apache/post.t \
t/apache/read.t \
t/apache/read2.t \
t/apache/read3.t \
t/apache/scanhdrs.t \
t/apache/scanhdrs2.t \
t/apache/send_cgi_header.t \
t/apache/subprocess.t
Now, it chokes in subprocess.t instead of command.t.
It does not fail on every run. If it does I get in the error_log this line:
Usage: DynaLoader::dl_load_file(filename, flags=0).
I suspect that some piece of code writes to a random location. But I really don't know how to start to debug that best given the sheer number of tests
(409) in this set.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org For additional commands, e-mail: dev-...@perl.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-...@perl.apache.org
For additional commands, e-mail: dev-...@perl.apache.org
|
|
|
|
|
|
|