Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: ModPerl: Dev

[RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

  

 
First page Previous page 1 2 Next page Last page  View All ModPerl dev RSS feed   Index | Next | Previous | View Threaded


fred at redhotpenguin

Jan 30, 2012, 10:41 PM

Post #1 of 32 (1114 views)
Permalink
[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).

http://people.apache.org/~phred/mod_perl-2.0.6-rc1.tar.gz

MD5 (mod_perl-2.0.6-rc1.tar.gz) = 1c5a2826fe7f78f91dfcbca2f84064d7

Change summary

=item 2.0.6-rc1

Discover apr-2-config from Apache 2.4 onwards. [Gozer]

Apache 2.4 and onwards doesn't require linking the MPM module directly in
the httpd binary anymore. APXS lost the MPM_NAME query, so we can't assume
a given MPM anymore. Introduce a fake MPM 'dynamic' to represent this.
[Torsten Foertsch, Gozer]

Perl 5.14 brought a few changes in Perl_sv_dup() that made a threaded apache
segfault while cloning interpreters.
[Torsten Foertsch]

PerlIOApache_flush() and mpxs_Apache2__RequestRec_rflush() now no longer throw
exceptions when modperl_wbucket_flush() fails if the failure was just a reset
connection or an aborted connection. The failure is simply logged to the error
log instead. This should fix cases of httpd.exe crashing when users press the
Stop button in their web browsers.
[Steve Hay]

Fixed a few issues that came up with LWP 6.00:
- t/response/TestAPI/request_rec.pm assumes HTTP/1.0 but LWP 6 uses 1.1
- t/api/err_headers_out.t fails due to a bug somewhere in LWP 6
- t/filter/TestFilter/out_str_reverse.pm sends the wrong content-length header
[Torsten Foertsch]

Bugfix: Apache2::ServerUtil::get_server{description,banner,version} cannot
be declared as perl constants or they won't reflect added version components
if Apache2::ServerUtil is loaded before the PostConfig phase. Now, they
are ordinary perl functions. [Torsten Foertsch]

Check for the right ExtUtils::Embed version during build [Torsten Foertsch]

Take a lesson from rt.cpan.org #66085 and pass LD_LIBRARY_PATH if mod_env
is present. Should prevent test failures on some platforms.
[Fred Moyer]

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Jan 31, 2012, 1:41 AM

Post #2 of 32 (1070 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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 [mailto:fred [at] redhotpenguin]
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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Jan 31, 2012, 4:21 AM

Post #3 of 32 (1078 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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 (>=) at ./Makefile.PL line 129" and
"Unparsable version '' for prerequisite Apache::Test at
lib/ModPerl/BuildMM.pm line 153".)


-----Original Message-----
From: Steve Hay [mailto:SteveHay [at] planit]
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 [mailto:fred [at] redhotpenguin]
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-unsubscribe [at] perl For additional
commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Jan 31, 2012, 6:32 AM

Post #4 of 32 (1073 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Monday, 30 January 2012 22:41:15 Fred Moyer wrote:
> http://people.apache.org/~phred/mod_perl-2.0.6-rc1.tar.gz

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Jan 31, 2012, 9:38 AM

Post #5 of 32 (1072 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> I can also confirm that r1145161 is
> the first commit that shows this behavior.

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Jan 31, 2012, 12:00 PM

Post #6 of 32 (1076 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Tuesday, January 31, 2012 at 6:32 AM, Torsten Förtsch wrote:

> On Monday, 30 January 2012 22:41:15 Fred Moyer wrote:
> > http://people.apache.org/~phred/mod_perl-2.0.6-rc1.tar.gz
>
>
>
> 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.


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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Jan 31, 2012, 12:29 PM

Post #7 of 32 (1123 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Tue, Jan 31, 2012 at 4:21 AM, Steve Hay <SteveHay [at] planit> wrote:
> 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 (>=) at ./Makefile.PL line 129" and
> "Unparsable version '' for prerequisite Apache::Test at
> lib/ModPerl/BuildMM.pm line 153".)


Guessing MP_LIBNAME is not getting set correctly.

1747 sub modperl_libs_MSWin32 {
1748 my $self = shift;
1749 "$self->{cwd}/src/modules/perl/$self->{MP_LIBNAME}.lib";
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->VERSION,
+ $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{$]}->{q/ExtUtils::Embed/};
+ 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 => grep
{ -e "$_/Makefile.PL" && -e "$_/lib/mod_perl2.pm" } qw(. ..);

@@ -240,7 +276,8 @@
}

my %threaded_mpms = map { $_ => 1 }
- 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->mpm_name();
@@ -255,8 +292,16 @@
# XXX: hopefully apxs will work on win32 one day
return $self->{mpm_name} = 'winnt' if WIN32;

- my $mpm_name = $self->apxs('-q' => 'MPM_NAME');
+ my $mpm_name;

+ # httpd >= 2.3
+ if ($self->httpd_version_as_int =~ m/^2[3-9]\d+/) {
+ $mpm_name = 'dynamic';
+ }
+ else {
+ $mpm_name = $self->apxs('-q' => 'MPM_NAME');
+ }
+
# building against the httpd source dir
unless (($mpm_name and $self->httpd_is_source_tree)) {
if ($self->dir) {
@@ -1108,7 +1153,18 @@

sub apr_generation {
my ($self) = @_;
- return $self->httpd_version_as_int =~ m/2[1-9]\d+/ ? 1 : 0;
+
+ my $httpd_v = $self->httpd_version_as_int;
+
+ 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->{$key} = $self->{$mp_key};
}

- my $config = $self->apr_generation ? "$what-1-config" : "$what-config";
+ my $apr_generation = $self->apr_generation;
+ my $config = $apr_generation ? "$what-${apr_generation}-config" :
"$what-config";
if (!$self->{$key}) {
my @tries = ();
@@ -1536,9 +1593,12 @@

require ExtUtils::MakeMaker;
my $mm = bless { @mm_init_vars }, 'MM';
- $mm->init_main;
- $mm->init_others;

+ # Fake initialize MakeMaker
+ foreach my $m (qw(init_main init_others init_tools)) {
+ $mm->$m() if $mm->can($m);
+ }
+
for (qw(rm_f mv ld ar cp test_f)) {
my $val = $mm->{"\U$_"};
if ($val) {








>
>
> -----Original Message-----
> From: Steve Hay [mailto:SteveHay [at] planit]
> 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 [mailto:fred [at] redhotpenguin]
> 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-unsubscribe [at] perl For additional
> commands, e-mail: dev-help [at] perl
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 1, 2012, 1:55 AM

Post #8 of 32 (1078 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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:

> perl515.dll!Perl_safesysfree(void * where) Line 263 C
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 [mailto:torsten.foertsch [at] gmx]
Sent: 31 January 2012 17:38
To: dev [at] perl
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> I can also confirm that r1145161 is
> the first commit that shows this behavior.

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-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Feb 1, 2012, 4:50 AM

Post #9 of 32 (1071 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Tuesday, 31 January 2012 12:00:17 Fred Moyer wrote:
> 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.

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 1, 2012, 7:15 AM

Post #10 of 32 (1072 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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->perl being set to the wrong value in modperl_module_config_obj_cleanup_register()? The call to that from modperl_module_config_merge() plays games with MP_PERL_CONTEXT_STORE_OVERRIDE / MP_PERL_CONTEXT_RESTORE, and the orig_perl value that gets saved away is the one that Perl_safesysfree() was expecting...

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 [mailto:SteveHay [at] planit]
Sent: 01 February 2012 09:55
To: Torsten Förtsch; dev [at] perl
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:

> perl515.dll!Perl_safesysfree(void * where) Line 263 C
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 [mailto:torsten.foertsch [at] gmx]
Sent: 31 January 2012 17:38
To: dev [at] perl
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> I can also confirm that r1145161 is
> the first commit that shows this behavior.

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-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


gozer at ectoplasm

Feb 1, 2012, 12:30 PM

Post #11 of 32 (1069 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On 12-01-31 09:32 , Torsten Förtsch wrote:
> On Monday, 30 January 2012 22:41:15 Fred Moyer wrote:
>> http://people.apache.org/~phred/mod_perl-2.0.6-rc1.tar.gz

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/gozer\@(apache|cpan|ectoplasm)\.org/
Attachments: signature.asc (0.25 KB)


SteveHay at planit

Feb 2, 2012, 7:02 AM

Post #12 of 32 (1079 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
The deletion of the ptr_table uses Safefree(), which picks up the context from PERL_GET_CONTEXT, so simply assigning cleanup->perl to aTHX (aka my_perl) before calling modperl_svptr_table_delete() is not sufficient to get Safefree() to use the same interpreter as was used to allocate the memory originally in the modperl_module_config_table_get() call in modperl_module_config_merge().

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->perl);
+#ifdef USE_ITHREADS
+ MP_PERL_CONTEXT_DECLARE;
+ MP_PERL_CONTEXT_STORE_OVERRIDE(cleanup->perl);
+#endif

modperl_svptr_table_delete(aTHX_ cleanup->table, cleanup->ptr);
+
+#ifdef USE_ITHREADS
+ MP_PERL_CONTEXT_RESTORE;
+#endif

MP_TRACE_c(MP_FUNC, "deleting ptr 0x%lx from table 0x%lx",
(unsigned long)cleanup->ptr,
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!Perl_safesysfree(void * where) Line 263 C
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 [mailto:SteveHay [at] planit]
Sent: 01 February 2012 15:16
To: Torsten Förtsch; dev [at] perl
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->perl being set to the wrong value in modperl_module_config_obj_cleanup_register()? The call to that from modperl_module_config_merge() plays games with MP_PERL_CONTEXT_STORE_OVERRIDE / MP_PERL_CONTEXT_RESTORE, and the orig_perl value that gets saved away is the one that Perl_safesysfree() was expecting...

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 [mailto:SteveHay [at] planit]
Sent: 01 February 2012 09:55
To: Torsten Förtsch; dev [at] perl
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:

> perl515.dll!Perl_safesysfree(void * where) Line 263 C
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 [mailto:torsten.foertsch [at] gmx]
Sent: 31 January 2012 17:38
To: dev [at] perl
Cc: Fred Moyer
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> I can also confirm that r1145161 is
> the first commit that shows this behavior.

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-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Feb 7, 2012, 9:01 AM

Post #13 of 32 (1070 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> 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.

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->perl);
#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->process->pconf);
(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>, my_thread_num=0, my_child_num=0, sock=0x7f6588003530, p=<optimized out>) at worker.c:544
#12 worker_thread (thd=0x2daf638, dummy=<optimized out>) at worker.c:894
#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->server is the vhost listening on localhost:8560.

(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->server
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->server to get an interpreter from the right pool.

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 8, 2012, 1:33 AM

Post #14 of 32 (1065 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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 [mailto:torsten.foertsch [at] gmx]
Sent: 07 February 2012 17:02
To: dev [at] perl
Cc: Fred Moyer; Steve Hay
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> 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.

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->perl);
#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->process->pconf);
(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>, my_thread_num=0, my_child_num=0, sock=0x7f6588003530, p=<optimized out>) at worker.c:544
#12 worker_thread (thd=0x2daf638, dummy=<optimized out>) at worker.c:894
#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->server is the vhost listening on localhost:8560.

(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->server
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->server to get an interpreter from the right pool.

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Feb 10, 2012, 10:30 AM

Post #15 of 32 (1054 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Tuesday, 07 February 2012 18:01:50 Torsten Förtsch wrote:
> 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?
On Wednesday, 08 February 2012 09:33:52 Steve Hay wrote:
> I think my patch is good, but clearly isn't the whole story.

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->perl);

MP_ASSERT_CONTEXT(aTHX);

modperl_svptr_table_delete(aTHX_ cleanup->table, cleanup->ptr);

MP_TRACE_c(MP_FUNC, "deleting ptr 0x%lx from table 0x%lx",
(unsigned long)cleanup->ptr,
(unsigned long)cleanup->table);

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 10, 2012, 10:36 AM

Post #16 of 32 (1054 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
> Meanwhile, I have reverted change 1145161 in trunk.>> Fred, could you please roll another rc?
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 <torsten.foertsch [at] gmx>:
> On Tuesday, 07 February 2012 18:01:50 Torsten Förtsch wrote:
>> 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?
> On Wednesday, 08 February 2012 09:33:52 Steve Hay wrote:
>> I think my patch is good, but clearly isn't the whole story.
>
> 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->perl);
>
>    MP_ASSERT_CONTEXT(aTHX);
>
>    modperl_svptr_table_delete(aTHX_ cleanup->table, cleanup->ptr);
>
>    MP_TRACE_c(MP_FUNC, "deleting ptr 0x%lx from table 0x%lx",
>               (unsigned long)cleanup->ptr,
>               (unsigned long)cleanup->table);
>
>    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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Feb 10, 2012, 11:35 AM

Post #17 of 32 (1047 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Friday, 10 February 2012 10:36:57 Fred Moyer wrote:
> Should we add a Changes entry for this?

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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 11, 2012, 9:49 AM

Post #18 of 32 (1049 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Fri, Feb 10, 2012 at 10:51 PM, Niko Tyni <ntyni [at] debian> wrote:
> Hi Fred (and hopefully the list),

Looks like it made it through. Suggest inlining your patches next
time instead of using attachments, sometimes the list code may filter
on those.
>
> as seen in <http://bugs.debian.org/650675>, we're seeing numerous lines of
>  Attempt to free unreferenced scalar: SV 0x7f9c0c347490, Perl interpreter: 0x7f9c0c1a2dd0 during global destruction.
> on Debian unstable with 2.0.5 and Perl 5.14.2. I've been trying to get
> patches through to the mod-perl dev list with no success; there seems
> to be something broken with the list moderation. (I'd be happy to provide
> message-ids and the like if somebody is interested, and they can also
> be found in the bug log.)


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.


> I've verified that those still get emitted with 2.0.6 RC1. The
> test suite passes, but
>  % grep unreferenced t/logs/error_log|wc -l
>  30

Can you post some of that error log which shows the error?


> This seems related to -Dusethreads and started with 5.13.6 or so; please see
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650675#50
> for the full analysis including the perl change that broke this.
>
> Could you please consider these patches for 2.0.6, or let me know if
> I've got it all wrong.

Thanks for the contribution. Anyone else here see those errors
previously, or can reproduce them now?

>
> Thanks for your work,
> --
> Niko Tyni   ntyni [at] debian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 13, 2012, 1:15 AM

Post #19 of 32 (1052 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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 [mailto:fred [at] redhotpenguin]
Sent: 11 February 2012 17:50
To: Niko Tyni
Cc: dev [at] perl; 650675 [at] bugs
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Fri, Feb 10, 2012 at 10:51 PM, Niko Tyni <ntyni [at] debian> wrote:
> Hi Fred (and hopefully the list),

Looks like it made it through. Suggest inlining your patches next time instead of using attachments, sometimes the list code may filter on those.
>
> as seen in <http://bugs.debian.org/650675>, we're seeing numerous
> lines of
>  Attempt to free unreferenced scalar: SV 0x7f9c0c347490, Perl interpreter: 0x7f9c0c1a2dd0 during global destruction.
> on Debian unstable with 2.0.5 and Perl 5.14.2. I've been trying to get
> patches through to the mod-perl dev list with no success; there seems
> to be something broken with the list moderation. (I'd be happy to
> provide message-ids and the like if somebody is interested, and they
> can also be found in the bug log.)


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.


> I've verified that those still get emitted with 2.0.6 RC1. The test
> suite passes, but
>  % grep unreferenced t/logs/error_log|wc -l
>  30

Can you post some of that error log which shows the error?


> This seems related to -Dusethreads and started with 5.13.6 or so;
> please see
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650675#50
> for the full analysis including the perl change that broke this.
>
> Could you please consider these patches for 2.0.6, or let me know if
> I've got it all wrong.

Thanks for the contribution. Anyone else here see those errors previously, or can reproduce them now?

>
> Thanks for your work,
> --
> Niko Tyni   ntyni [at] debian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 13, 2012, 10:52 AM

Post #20 of 32 (1048 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
Niko, are you subscribed to dev [at] perl? 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


On Monday, February 13, 2012 at 10:49 AM, Niko Tyni wrote:

> On Sat, Feb 11, 2012 at 09:49:40AM -0800, Fred Moyer wrote:
> > On Fri, Feb 10, 2012 at 10:51 PM, Niko Tyni <ntyni [at] debian (mailto:ntyni [at] debian)> wrote:
> > > Hi Fred (and hopefully the list),
> >
> >
> >
> > Looks like it made it through.
>
> If you say so, but it doesn't show up in any web accessible archives or
> news.gmane.org (http://news.gmane.org) so I suspect that was just your personal copy. But we'll
> see how it goes this time.
>
> > Suggest inlining your patches next
> > time instead of using attachments, sometimes the list code may filter
> > on those.
>
>
>
> Okay, thanks.
>
> > > I've verified that those still get emitted with 2.0.6 RC1. The
> > > test suite passes, but
> > > % grep unreferenced t/logs/error_log|wc -l
> > > 30
> >
> >
> >
> > Can you post some of that error log which shows the error?
>
> head -20 appended; the whole 200 or so lines can be found at
> http://people.debian.org/~ntyni/650675/error_log
>
> One warning is generated always on startup so it's pretty repetitive.
>
> FWIW, we're configuring the beast with
>
> perl Makefile.PL INSTALLDIRS=vendor \
> MP_USE_GTOP=1 \
> MP_TRACE=0 \
> MP_USE_DSO=1 \
> MP_USE_STATIC=0 \
> MP_CCOPTS="-g -O2 -Wall" \
> MP_INCLUDE_DIR=/usr/include/apache2 \
> MP_APXS=/usr/bin/apxs2 \
> MP_INCLUDE_DIR=/usr/include/apr-1.0
>
> and I've also appended 'perl -V' output after the log part.
>
> Attempt to free unreferenced scalar: SV 0x2af466e1bee0, Perl interpreter: 0x2af466df82a0 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af466a72d48, Perl interpreter: 0x2af466a3d110 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af466984470, Perl interpreter: 0x2af466488140 during global destruction.
> END in modperl_extra.pl (http://modperl_extra.pl), pid=8994
> Attempt to free unreferenced scalar: SV 0x2af45f41e888, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f456218, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f41ee28, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f413b80, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f4612b0, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af4638d1008, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f477050, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f456308, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af4638c6510, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f45a610, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f41e888, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f456218, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> [Mon Feb 13 20:30:26 2012] [notice] Apache/2.2.22 (Debian) world domination series/2.0 mod_perl/2.0.6-rc1 Perl/v5.14.2 configured -- resuming normal operations
> [Mon Feb 13 20:30:26 2012] [info] Server built: Feb 1 2012 21:36:17
> [Mon Feb 13 20:30:26 2012] [debug] prefork.c(1023): AcceptMutex: sysvsem (default: sysvsem)
>
>
> Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
>
> Platform:
> osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux-gnu-thread-multi
> uname='linux barber 2.6.32-5-amd64 #1 smp mon jan 9 20:49:59 utc 2012 x86_64 gnulinux '
> config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
> hint=recommended, useposix=true, d_sigaction=define
> useithreads=define, usemultiplicity=define
> useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
> use64bitint=define, use64bitall=define, uselongdouble=undef
> usemymalloc=n, bincompat5005=undef
> Compiler:
> cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
> optimize='-O2 -g',
> cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
> ccversion='', gccversion='4.6.2', gccosandvers=''
> intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
> d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
> ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
> alignbytes=8, prototype=define
> Linker and Libraries:
> ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
> libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
> libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
> perllibs=-ldl -lm -lpthread -lc -lcrypt
> libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
> gnulibc_version='2.13'
> Dynamic Linking:
> dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
> cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'
>
>
> Characteristics of this binary (from libperl):
> Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
> PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
> PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT
> USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
> USE_REENTRANT_API
> Locally applied patches:
> DEBPKG:debian/arm_thread_stress_timeout - http://bugs.debian.org/501970 Raise the timeout of ext/threads/shared/t/stress.t to accommodate slower build hosts
> DEBPKG:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS default for modules installed from CPAN.
> DEBPKG:debian/db_file_ver - http://bugs.debian.org/340047 Remove overly restrictive DB_File version check.
> DEBPKG:debian/doc_info - Replace generic man(1) instructions with Debian-specific information.
> DEBPKG:debian/enc2xs_inc - http://bugs.debian.org/290336 Tweak enc2xs to follow symlinks and ignore missing @INC directories.
> DEBPKG:debian/errno_ver - http://bugs.debian.org/343351 Remove Errno version check due to upgrade problems with long-running processes.
> DEBPKG:debian/libperl_embed_doc - http://bugs.debian.org/186778 Note that libperl-dev package is required for embedded linking
> DEBPKG:fixes/respect_umask - Respect umask during installation
> DEBPKG:debian/writable_site_dirs - Set umask approproately for site install directories
> DEBPKG:debian/extutils_set_libperl_path - EU:MM: Set location of libperl.a to /usr/lib
> DEBPKG:debian/no_packlist_perllocal - Don't install .packlist or perllocal.pod for perl or vendor
> DEBPKG:debian/prefix_changes - Fiddle with *PREFIX and variables written to the makefile
> DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to the binary targets.
> DEBPKG:debian/instmodsh_doc - Debian policy doesn't install .packlist files for core or vendor.
> DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as per Debian policy.
> DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable.
> DEBPKG:debian/m68k_thread_stress - http://bugs.debian.org/517938 http://bugs.debian.org/495826 Disable some threads tests on m68k for now due to missing TLS.
> DEBPKG:debian/mod_paths - Tweak @INC ordering for Debian
> DEBPKG:debian/module_build_man_extensions - http://bugs.debian.org/479460 Adjust Module::Build manual page extensions for the Debian Perl policy
> DEBPKG:debian/prune_libs - http://bugs.debian.org/128355 Prune the list of libraries wanted to what we actually need.
> DEBPKG:fixes/net_smtp_docs - [rt.cpan.org #36038] http://bugs.debian.org/100195 Document the Net::SMTP 'Port' option
> DEBPKG:debian/perlivp - http://bugs.debian.org/510895 Make perlivp skip include directories in /usr/local
> DEBPKG:debian/disable-zlib-bundling - Disable zlib bundling in Compress::Raw::Zlib
> DEBPKG:debian/cpanplus_definstalldirs - http://bugs.debian.org/533707 Configure CPANPLUS to use the site directories by default.
> DEBPKG:debian/cpanplus_config_path - Save local versions of CPANPLUS::Config::System into /etc/perl.
> DEBPKG:debian/deprecate-with-apt - http://bugs.debian.org/580034 Point users to Debian packages of deprecated core modules
> DEBPKG:fixes/hurd-ccflags - [a190e64] http://bugs.debian.org/587901 [perl #92244] Make hints/gnu.sh (http://gnu.sh) append to $ccflags rather than overriding them
> DEBPKG:debian/squelch-locale-warnings - http://bugs.debian.org/508764 Squelch locale warnings in Debian package maintainer scripts
> DEBPKG:debian/skip-upstream-git-tests - Skip tests specific to the upstream Git repository
> DEBPKG:fixes/extutils-cbuilder-cflags - [011e8fb] http://bugs.debian.org/624460 [perl #89478] Append CFLAGS and LDFLAGS to their Config.pm counterparts in EU::CBuilder
> DEBPKG:fixes/module-build-home-directory - http://bugs.debian.org/624850 [rt.cpan.org (http://rt.cpan.org) #67893] Fix failing tilde test when run under a UID without a passwd entry
> DEBPKG:debian/patchlevel - http://bugs.debian.org/567489 List packaged patches for 5.14.2-7 in patchlevel.h
> DEBPKG:fixes/h2ph-multiarch - [e7ec705] http://bugs.debian.org/625808 [perl #90122] Make h2ph correctly search gcc include directories
> DEBPKG:fixes/index-tainting - [3b36395] http://bugs.debian.org/291450 [perl #64804] RT 64804: tainting with index() of a constant
> DEBPKG:debian/skip-kfreebsd-crash - http://bugs.debian.org/628493 [perl #96272] Skip a crashing test case in t/op/threads.t on GNU/kFreeBSD
> DEBPKG:fixes/document_makemaker_ccflags - http://bugs.debian.org/628522 [rt.cpan.org (http://rt.cpan.org) #68613] Document that CCFLAGS should include $Config{ccflags}
> DEBPKG:fixes/sys-syslog-socket-timeout-kfreebsd.patch - http://bugs.debian.org/627821 [rt.cpan.org (http://rt.cpan.org) #69997] Use a socket timeout on GNU/kFreeBSD to catch ICMP port unreachable messages
> DEBPKG:fixes/hurd-hints - http://bugs.debian.org/636609 Improve general GNU hints, needed for GNU/Hurd.
> DEBPKG:fixes/pod_fixes - [7698aed] http://bugs.debian.org/637816 Fix typos in several pod/perl*.pod files
> DEBPKG:debian/find_html2text - http://bugs.debian.org/640479 Configure CPAN::Distribution with correct name of html2text
> DEBPKG:fixes/digest_eval_hole - http://bugs.debian.org/644108 Close the eval "require $module" security hole in Digest->new($algorithm)
> DEBPKG:fixes/hurd-ndbm - [f0d0a20] [perl #102680] http://bugs.debian.org/645989 Add GNU/Hurd hints for NDBM_File
> DEBPKG:fixes/sysconf.t-posix - [8040185] [perl #102888] http://bugs.debian.org/646016 Fix hang in ext/POSIX/t/sysconf.t on GNU/Hurd
> DEBPKG:fixes/hurd-largefile - [1fda587] [perl #103014] http://bugs.debian.org/645790 enable LFS on GNU/Hurd
> DEBPKG:debian/hurd_test_todo_syslog - http://bugs.debian.org/650093 Disable failing GNU/Hurd tests in cpan/Sys-Syslog/t/syslog.t
> DEBPKG:fixes/hurd_skip_itimer_virtual - [rt.cpan.org #72754] http://bugs.debian.org/650094 Skip interval timer tests in Time::HiRes on GNU/Hurd
> DEBPKG:debian/hurd_test_skip_sigdispatch - http://bugs.debian.org/650188 Disable failing GNU/Hurd tests op/sigdispatch.t
> DEBPKG:debian/hurd_test_skip_stack - http://bugs.debian.org/650175 Disable failing GNU/Hurd tests dist/threads/t/stack.t
> DEBPKG:debian/hurd_test_skip_pipe - http://bugs.debian.org/650187 Disable failing GNU/Hurd tests io/pipe.t
> DEBPKG:debian/hurd_test_skip_io_pipe - http://bugs.debian.org/650096 Disable failing GNU/Hurd tests dist/IO/t/io_pipe.t
> DEBPKG:fixes/manpage_name_CPAN - http://bugs.debian.org/650448 [rt.cpan.org (http://rt.cpan.org) #73396] cpan/CPAN: add NAME headings in modules with POD
> DEBPKG:fixes/manpage_name_CPANPLUS - http://bugs.debian.org/650450 [rt.cpan.org (http://rt.cpan.org) #73398] cpan/CPANPLUS: add NAME headings in modules with POD
> DEBPKG:fixes/manpage_name_Test-Harness - http://bugs.debian.org/650451 [rt.cpan.org (http://rt.cpan.org) #73399] cpan/Test-Harness: add NAME headings in modules with POD
> DEBPKG:fixes/manpage_name_Term-UI - http://bugs.debian.org/650452 [rt.cpan.org (http://rt.cpan.org) #73400] cpan/Term-UI: add NAME headings in modules with POD
> DEBPKG:fixes/podlators_ae_ligature_fallback - http://bugs.debian.org/652851 Fix the ASCII fallback string for AE
> DEBPKG:fixes/fsf_postal_address - [de89470] Update references to the FSF's postal address
> DEBPKG:fixes/cpan_module_pod_fixes - [perl #106870] [rt.cpan.org (http://rt.cpan.org) #73447] [rt.cpan.org (http://rt.cpan.org) #73446] Fix POD formatting in Term-Cap and Pod-Parser
> Built under linux
> Compiled at Jan 29 2012 19:13:20
> @INC:
> /etc/perl
> /usr/local/lib/perl/5.14.2
> /usr/local/share/perl/5.14.2
> /usr/lib/perl5
> /usr/share/perl5
> /usr/lib/perl/5.14
> /usr/share/perl/5.14
> /usr/local/lib/site_perl
> .
>
> --
> Niko Tyni ntyni [at] debian (mailto:ntyni [at] debian)




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


fred at redhotpenguin

Feb 13, 2012, 8:53 PM

Post #21 of 32 (1058 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
On Mon, Feb 13, 2012 at 10:49 AM, Niko Tyni <ntyni [at] debian> wrote:
> FWIW, we're configuring the beast with
>
>  perl Makefile.PL                INSTALLDIRS=vendor \
>                MP_USE_GTOP=1 \

Is gtop desired for any particular reason? I would think production
machines may not want it enabled by default.

>                MP_TRACE=0 \
>                MP_USE_DSO=1 \
>                MP_USE_STATIC=0 \
>                MP_CCOPTS="-g -O2 -Wall" \
>                MP_INCLUDE_DIR=/usr/include/apache2 \
>                MP_APXS=/usr/bin/apxs2 \
>                MP_INCLUDE_DIR=/usr/include/apr-1.0

That's a pretty old APR, considering you're using httpd 2.2.22. Is
there a specific reason?

>
> and I've also appended 'perl -V' output after the log part.
>
> Attempt to free unreferenced scalar: SV 0x2af466e1bee0, Perl interpreter: 0x2af466df82a0 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af466a72d48, Perl interpreter: 0x2af466a3d110 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af466984470, Perl interpreter: 0x2af466488140 during global destruction.
> END in modperl_extra.pl, pid=8994
> Attempt to free unreferenced scalar: SV 0x2af45f41e888, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f456218, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f41ee28, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f413b80, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f4612b0, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af4638d1008, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f477050, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f456308, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af4638c6510, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f45a610, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f41e888, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> Attempt to free unreferenced scalar: SV 0x2af45f456218, Perl interpreter: 0x2af45ddf7d00 during global destruction.
> [Mon Feb 13 20:30:26 2012] [notice] Apache/2.2.22 (Debian) world domination series/2.0 mod_perl/2.0.6-rc1 Perl/v5.14.2 configured -- resuming normal operations
> [Mon Feb 13 20:30:26 2012] [info] Server built: Feb  1 2012 21:36:17
> [Mon Feb 13 20:30:26 2012] [debug] prefork.c(1023): AcceptMutex: sysvsem (default: sysvsem)
>
>
> Summary of my perl5 (revision 5 version 14 subversion 2) configuration:
>
>  Platform:
>    osname=linux, osvers=2.6.32-5-amd64, archname=x86_64-linux-gnu-thread-multi
>    uname='linux barber 2.6.32-5-amd64 #1 smp mon jan 9 20:49:59 utc 2012 x86_64 gnulinux '
>    config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
>    hint=recommended, useposix=true, d_sigaction=define
>    useithreads=define, usemultiplicity=define
>    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
>    use64bitint=define, use64bitall=define, uselongdouble=undef
>    usemymalloc=n, bincompat5005=undef
>  Compiler:
>    cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
>    optimize='-O2 -g',
>    cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
>    ccversion='', gccversion='4.6.2', gccosandvers=''
>    intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
>    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
>    ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
>    alignbytes=8, prototype=define
>  Linker and Libraries:
>    ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
>    libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
>    libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
>    perllibs=-ldl -lm -lpthread -lc -lcrypt
>    libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
>    gnulibc_version='2.13'
>  Dynamic Linking:
>    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
>    cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'
>
>
> Characteristics of this binary (from libperl):
>  Compile-time options: MULTIPLICITY PERL_DONT_CREATE_GVSV
>                        PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP
>                        PERL_PRESERVE_IVUV USE_64_BIT_ALL USE_64_BIT_INT
>                        USE_ITHREADS USE_LARGE_FILES USE_PERLIO USE_PERL_ATOF
>                        USE_REENTRANT_API
>  Locally applied patches:
>        DEBPKG:debian/arm_thread_stress_timeout - http://bugs.debian.org/501970 Raise the timeout of ext/threads/shared/t/stress.t to accommodate slower build hosts
>        DEBPKG:debian/cpan_definstalldirs - Provide a sensible INSTALLDIRS default for modules installed from CPAN.
>        DEBPKG:debian/db_file_ver - http://bugs.debian.org/340047 Remove overly restrictive DB_File version check.
>        DEBPKG:debian/doc_info - Replace generic man(1) instructions with Debian-specific information.
>        DEBPKG:debian/enc2xs_inc - http://bugs.debian.org/290336 Tweak enc2xs to follow symlinks and ignore missing @INC directories.
>        DEBPKG:debian/errno_ver - http://bugs.debian.org/343351 Remove Errno version check due to upgrade problems with long-running processes.
>        DEBPKG:debian/libperl_embed_doc - http://bugs.debian.org/186778 Note that libperl-dev package is required for embedded linking
>        DEBPKG:fixes/respect_umask - Respect umask during installation
>        DEBPKG:debian/writable_site_dirs - Set umask approproately for site install directories
>        DEBPKG:debian/extutils_set_libperl_path - EU:MM: Set location of libperl.a to /usr/lib
>        DEBPKG:debian/no_packlist_perllocal - Don't install .packlist or perllocal.pod for perl or vendor
>        DEBPKG:debian/prefix_changes - Fiddle with *PREFIX and variables written to the makefile
>        DEBPKG:debian/fakeroot - Postpone LD_LIBRARY_PATH evaluation to the binary targets.
>        DEBPKG:debian/instmodsh_doc - Debian policy doesn't install .packlist files for core or vendor.
>        DEBPKG:debian/ld_run_path - Remove standard libs from LD_RUN_PATH as per Debian policy.
>        DEBPKG:debian/libnet_config_path - Set location of libnet.cfg to /etc/perl/Net as /usr may not be writable.
>        DEBPKG:debian/m68k_thread_stress - http://bugs.debian.org/517938 http://bugs.debian.org/495826 Disable some threads tests on m68k for now due to missing TLS.
>        DEBPKG:debian/mod_paths - Tweak @INC ordering for Debian
>        DEBPKG:debian/module_build_man_extensions - http://bugs.debian.org/479460 Adjust Module::Build manual page extensions for the Debian Perl policy
>        DEBPKG:debian/prune_libs - http://bugs.debian.org/128355 Prune the list of libraries wanted to what we actually need.
>        DEBPKG:fixes/net_smtp_docs - [rt.cpan.org #36038] http://bugs.debian.org/100195 Document the Net::SMTP 'Port' option
>        DEBPKG:debian/perlivp - http://bugs.debian.org/510895 Make perlivp skip include directories in /usr/local
>        DEBPKG:debian/disable-zlib-bundling - Disable zlib bundling in Compress::Raw::Zlib
>        DEBPKG:debian/cpanplus_definstalldirs - http://bugs.debian.org/533707 Configure CPANPLUS to use the site directories by default.
>        DEBPKG:debian/cpanplus_config_path - Save local versions of CPANPLUS::Config::System into /etc/perl.
>        DEBPKG:debian/deprecate-with-apt - http://bugs.debian.org/580034 Point users to Debian packages of deprecated core modules
>        DEBPKG:fixes/hurd-ccflags - [a190e64] http://bugs.debian.org/587901 [perl #92244] Make hints/gnu.sh append to $ccflags rather than overriding them
>        DEBPKG:debian/squelch-locale-warnings - http://bugs.debian.org/508764 Squelch locale warnings in Debian package maintainer scripts
>        DEBPKG:debian/skip-upstream-git-tests - Skip tests specific to the upstream Git repository
>        DEBPKG:fixes/extutils-cbuilder-cflags - [011e8fb] http://bugs.debian.org/624460 [perl #89478] Append CFLAGS and LDFLAGS to their Config.pm counterparts in EU::CBuilder
>        DEBPKG:fixes/module-build-home-directory - http://bugs.debian.org/624850 [rt.cpan.org #67893] Fix failing tilde test when run under a UID without a passwd entry
>        DEBPKG:debian/patchlevel - http://bugs.debian.org/567489 List packaged patches for 5.14.2-7 in patchlevel.h
>        DEBPKG:fixes/h2ph-multiarch - [e7ec705] http://bugs.debian.org/625808 [perl #90122] Make h2ph correctly search gcc include directories
>        DEBPKG:fixes/index-tainting - [3b36395] http://bugs.debian.org/291450 [perl #64804] RT 64804: tainting with index() of a constant
>        DEBPKG:debian/skip-kfreebsd-crash - http://bugs.debian.org/628493 [perl #96272] Skip a crashing test case in t/op/threads.t on GNU/kFreeBSD
>        DEBPKG:fixes/document_makemaker_ccflags - http://bugs.debian.org/628522 [rt.cpan.org #68613] Document that CCFLAGS should include $Config{ccflags}
>        DEBPKG:fixes/sys-syslog-socket-timeout-kfreebsd.patch - http://bugs.debian.org/627821 [rt.cpan.org #69997] Use a socket timeout on GNU/kFreeBSD to catch ICMP port unreachable messages
>        DEBPKG:fixes/hurd-hints - http://bugs.debian.org/636609 Improve general GNU hints, needed for GNU/Hurd.
>        DEBPKG:fixes/pod_fixes - [7698aed] http://bugs.debian.org/637816 Fix typos in several pod/perl*.pod files
>        DEBPKG:debian/find_html2text - http://bugs.debian.org/640479 Configure CPAN::Distribution with correct name of html2text
>        DEBPKG:fixes/digest_eval_hole - http://bugs.debian.org/644108 Close the eval "require $module" security hole in Digest->new($algorithm)
>        DEBPKG:fixes/hurd-ndbm - [f0d0a20] [perl #102680] http://bugs.debian.org/645989 Add GNU/Hurd hints for NDBM_File
>        DEBPKG:fixes/sysconf.t-posix - [8040185] [perl #102888] http://bugs.debian.org/646016 Fix hang in ext/POSIX/t/sysconf.t on GNU/Hurd
>        DEBPKG:fixes/hurd-largefile - [1fda587] [perl #103014] http://bugs.debian.org/645790 enable LFS on GNU/Hurd
>        DEBPKG:debian/hurd_test_todo_syslog - http://bugs.debian.org/650093 Disable failing GNU/Hurd tests in cpan/Sys-Syslog/t/syslog.t
>        DEBPKG:fixes/hurd_skip_itimer_virtual - [rt.cpan.org #72754] http://bugs.debian.org/650094 Skip interval timer tests in Time::HiRes on GNU/Hurd
>        DEBPKG:debian/hurd_test_skip_sigdispatch - http://bugs.debian.org/650188 Disable failing GNU/Hurd tests op/sigdispatch.t
>        DEBPKG:debian/hurd_test_skip_stack - http://bugs.debian.org/650175 Disable failing GNU/Hurd tests dist/threads/t/stack.t
>        DEBPKG:debian/hurd_test_skip_pipe - http://bugs.debian.org/650187 Disable failing GNU/Hurd tests io/pipe.t
>        DEBPKG:debian/hurd_test_skip_io_pipe - http://bugs.debian.org/650096 Disable failing GNU/Hurd tests dist/IO/t/io_pipe.t
>        DEBPKG:fixes/manpage_name_CPAN - http://bugs.debian.org/650448 [rt.cpan.org #73396] cpan/CPAN: add NAME headings in modules with POD
>        DEBPKG:fixes/manpage_name_CPANPLUS - http://bugs.debian.org/650450 [rt.cpan.org #73398] cpan/CPANPLUS: add NAME headings in modules with POD
>        DEBPKG:fixes/manpage_name_Test-Harness - http://bugs.debian.org/650451 [rt.cpan.org #73399] cpan/Test-Harness: add NAME headings in modules with POD
>        DEBPKG:fixes/manpage_name_Term-UI - http://bugs.debian.org/650452 [rt.cpan.org #73400] cpan/Term-UI: add NAME headings in modules with POD
>        DEBPKG:fixes/podlators_ae_ligature_fallback - http://bugs.debian.org/652851 Fix the ASCII fallback string for AE
>        DEBPKG:fixes/fsf_postal_address - [de89470] Update references to the FSF's postal address
>        DEBPKG:fixes/cpan_module_pod_fixes - [perl #106870] [rt.cpan.org #73447] [rt.cpan.org #73446] Fix POD formatting in Term-Cap and Pod-Parser
>  Built under linux
>  Compiled at Jan 29 2012 19:13:20
>  @INC:
>    /etc/perl
>    /usr/local/lib/perl/5.14.2
>    /usr/local/share/perl/5.14.2
>    /usr/lib/perl5
>    /usr/share/perl5
>    /usr/lib/perl/5.14
>    /usr/share/perl/5.14
>    /usr/local/lib/site_perl
>    .
>
> --
> Niko Tyni   ntyni [at] debian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 14, 2012, 1:58 AM

Post #22 of 32 (1042 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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 [mailto:SteveHay [at] planit]
Sent: 08 February 2012 09:34
To: Torsten Förtsch; dev [at] perl
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 [mailto:torsten.foertsch [at] gmx]
Sent: 07 February 2012 17:02
To: dev [at] perl
Cc: Fred Moyer; Steve Hay
Subject: Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1

On Tuesday, 31 January 2012 15:32:44 Torsten Förtsch wrote:
> 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.

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->perl);
#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->process->pconf);
(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>, my_thread_num=0, my_child_num=0, sock=0x7f6588003530, p=<optimized out>) at worker.c:544
#12 worker_thread (thd=0x2daf638, dummy=<optimized out>) at worker.c:894
#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->server is the vhost listening on localhost:8560.

(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->server
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->server to get an interpreter from the right pool.

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-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


torsten.foertsch at gmx

Feb 14, 2012, 5:19 AM

Post #23 of 32 (1048 views)
Permalink
Re: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 14, 2012, 6:15 AM

Post #24 of 32 (1039 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
[.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.foertsch [at] gmx]
Sent: 14 February 2012 13:19
To: Steve Hay
Cc: dev [at] perl; 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-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl


SteveHay at planit

Feb 14, 2012, 6:34 AM

Post #25 of 32 (1047 views)
Permalink
RE: [RELEASE CANDIDATE]: mod_perl-2.0.6 RC1 [In reply to]
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 [at] planit]
Sent: 14 February 2012 14:15
To: Torsten Förtsch
Cc: dev [at] perl; 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.foertsch [at] gmx]
Sent: 14 February 2012 13:19
To: Steve Hay
Cc: dev [at] perl; 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-unsubscribe [at] perl For additional commands, e-mail: dev-help [at] perl


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe [at] perl
For additional commands, e-mail: dev-help [at] perl

First page Previous page 1 2 Next page Last page  View All ModPerl dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.