Re: [ANNOUNCE] mod_perl 2.0.9

2015-06-21 Thread Jan Kaluža 

On 06/21/2015 01:44 AM, Steve Hay wrote:

We are delighted to announce the long-awaited release of mod_perl
2.0.9, which you will soon be able to download from a mirror site near
you via:


Great! Thanks for RMing. I've just updated mod_perl in Fedora :).

Regards,
Jan Kaluza


http://perl.apache.org/download/index.html

or in the meantime directly from:

http://apache.org/dist/perl/
http://search.cpan.org/dist/mod_perl/
https://metacpan.org/release/mod_perl/

MD5: fdab9a145bf35f54fce997c96c76f8e2 *mod_perl-2.0.9.tar.gz
SHA1: 5de3018214da21de186d758a429d5c78f827caa5 *mod_perl-2.0.9.tar.gz

This is the first official release of mod_perl with support for httpd
2.4.x. Your humble release engineer would like to give a big thank you
to all those who helped to make it happen.

Please note that perl 5.22.0 is not supported by this release. We hope
to have this fixed soon in mod_perl 2.0.10.

See below for the full list of changes in this release.

Enjoy!

Steve Hay


Add note to README about MP_INLINE problem when building with GCC 5.
[Niko Tyni ]

Fix t/api/aplog.t for apr-1.5.2. [Steve Hay]

Note that Perl 5.22.x is currently not supported. This is logged as
CPAN RT#101962 and will hopefully be addressed in 2.0.10. [Steve Hay]

Fix unthreaded build, which was broken in 2.0.9-rc2. [Steve Hay]

Remove PerlInterpScope. This has not been working properly with
threaded MPMs with httpd-2.4.x and the use-case of this directive was
questionable. [Jan Kaluza]

Allow running the test suite with httpd-2.4.x when mod_access_compat
is not loaded. [Steve Hay]

Add support for Apache httpd-2.4.x. [Torsten Foertsch, Jan Kaluza,
Steve Hay, Gozer]

Don't call modperl_threaded_mpm() et al. from XS code. Fixes Debian
Bug #765174. [Niko Tyni ]

Make sure modperl_interp_select uses r->server rather than the passed
s parameter to find the interpreter pool to pull an interpreter from.
This fixes an issue with vhosts with a separate interpreter pool and
runtime dir-config merges that used to pull the interpreter from the
wrong pool. [Torsten Foertsch]

PerlInterpScope is now more advisory. Using $(c|r)->pnotes will bind
the current interpreter to that object for it's lifetime.
$(c|r)->pnotes_kill() can be used to prematurely drop pnotes and
remove this binding. [Torsten Foertsch]

Now correctly invokes PerlCleanupHandlers, even if they are the only
handler type configured for that request [Torsten Foertsch]

For threaded MPMs, change interpreter managment to a new,
reference-counted allocation model. [Torsten Foertsch]

Expose modperl_interp_pool_t via ModPerl::InterpPool, modperl_tipool_t
via ModPerl::TiPool and modperl_tipool_config_t via
ModPerl::TiPoolConfig [Torsten Foertsch]

Expose modperl_interp_t via ModPerl::Interpreter [Torsten Foertsch]

Fix t/compat/apache_file.t on Windows. Apache::File->tmpfile() wants
TMPDIR or TEMP from the environment, or else defaults to /tmp. The
latter is no good on Windows, so make sure the environment variables
are passed through. (TEMP should be set to something suitable on
Windows.) [Steve Hay]

Fix t/api/err_headers_out.t with HTTP::Headers > 6.00. [Rolando
]

Fix the build with VC++ and dmake (rather than nmake) on Windows. The
Makefile generated by Apache2::Build uses shell commands for the
manifest file, but neglected to tell dmake to use the shell. [Steve
Hay]

Don't write an 'rpm' target into the Makefile on Windows. It isn't
relevant on Windows, and the (hard-coded, not MakeMaker-generated)
recipe group has syntax which dmake doesn't understand. [Steve Hay]

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




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

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC3

2015-06-11 Thread Jan Kaluža 

On 06/10/2015 07:13 PM, Steve Hay wrote:

Please download, test, and report back on this release candidate of
the long-awaited mod_perl 2.0.9.

http://people.apache.org/~stevehay/mod_perl-2.0.9-rc3.tar.gz


All tests pass for me with both apr-1.5.1 and apr-1.5.2, httpd-2.4.12, 
Perl 5.18.4, apr-util 1.5.4. Running Fedora 21.


Regards,
Jan Kaluza


MD5 = 61d07fe00919d9da2b49dbf7b821b1a7
SHA1 = 09e1d5f19312742db9da38c8e7f8955a77d29dfd

Changes since RC2:

Fix t/api/aplog.t for apr-1.5.2. [Steve Hay]

Note that Perl 5.22.x is currently not supported. This is logged as
CPAN RT#101962 and will hopefully be addressed in 2.0.10. [Steve Hay]

Fix unthreaded build, which was broken in 2.0.9-rc2. [Steve Hay]

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




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

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC2

2015-06-10 Thread Jan Kaluža 

On 06/09/2015 10:23 AM, Steve Hay wrote:

On 8 June 2015 at 08:14, Jan Kaluža  wrote:

On 05/31/2015 03:12 AM, Kevin A. McGrail wrote:


On 5/30/2015 2:20 PM, Steve Hay wrote:


Please download, test, and report back on this release candidate of
the long-awaited mod_perl 2.0.9.

http://people.apache.org/~stevehay/mod_perl-2.0.9-rc2.tar.gz

MD5 = 6dbf61e0724a245f1c015687fb3e4213
SHA1 = faf63c98b338ef0373ccbbe775c52506270ff3b9

Changes since RC1:

Remove PerlInterpScope. This has not been working properly with
threaded MPMs with httpd-2.4.x and the use-case of this directive was
questionable. [Jan Kaluza]

Allow running the test suite with httpd-2.4.x when mod_access_compat
is not loaded. [Steve Hay]


The test suite finished with one failure against 2.4.12 on my test rig:

Test Summary Report
---
t/api/aplog.t (Wstat: 0 Tests: 36 Failed: 1)
Failed test:  24
Files=245, Tests=4646, 304 wallclock secs ( 3.34 usr  0.49 sys + 227.74
cusr 50.53 csys = 282.10 CPU)
Result: FAIL
Failed 1/245 test programs. 1/4646 subtests failed.
[warning] server localhost.localdomain:8529 shutdown
[warning] port 8529 still in use...
...done
[  error] error running tests (please examine t/logs/error_log)
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++
Makefile:1112: recipe for target 'run_tests' failed
make: *** [run_tests] Error 1



Repeating with TEST_VERBOSE=1 added...  Here's the relevant output:

ok 23
# testing : $s->log_serror(LOG_MARK, LOG_DEBUG, APR::Const::EGENERAL...)
# expected: qr/(?^:Internal error: log_serror test 2)/
# received: '
# *** The following warn entry is expected and harmless ***
# [Sat May 30 21:04:59.085379 2015] [perl:debug] [pid 9642:tid 3076]
aplog.pm(90): (20014)Internal error (specific information not
available): log_serror test 2
# '
not ok 24
# testing : $r->log_rerror(LOG_MARK, LOG_CRIT, APR::Const::ENOTIME...)
# expected: qr/(?^:\[\w*:crit\] \[pid[^]]+\] .*?: \[[^]]+\] log_rerror
test)/
# received: '# Failed test 24 in
/usr/src/mod_perl-2.0.9-rc2/t/response/TestAPI/aplog.pm at line 92



Something is bad here I think, because test on line 92 is not the one which
is failing according to the TEST_VERBOSE output. Could you check what's in
aplog.pm at line 92?

Jan Kaluza


# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.086325 2015] [perl:crit] [pid 9642:tid 3076]
(20007)No time was provided and one was required.: [client
127.0.0.1:56778] log_rerror test
# '
ok 25


Ah... I think the "testing/expected/received" text is appearing
*before* the "ok/not ok" text.

Test 25 has succeeded because the quoted text from "# Failed test 24"
through "log_rerror test #" does indeed match the pattern
qr/\[\w*:crit\] \[pid[^]]+\] .*?: \[[^]]+\] log_rerror test/

But it is test 24 on lin 92 that has failed because the received text

# *** The following warn entry is expected and harmless ***
# [Sat May 30 21:04:59.085379 2015] [perl:debug] [pid 9642:tid 3076]
aplog.pm(90): (20014)Internal error (specific information not
available): log_serror test 2
#

doesn't match the pattern qr/$egeneral: log_serror test 2/, where

 my $egeneral = have_min_apache_version('2.1.0')
? "Internal error"
: "Error string not specified yet";

It fails to match because of the " (specific information not available)" part.

Does the following/attached patch fix it?


Great! I've been able to reproduce it. That error string changed in 
apr-1.5.2 and I've been testing with apr-1.5.1 earlier. I've verified 
that the patch you've attached fixes the issue for me.


I've tested with the patch with both apr-1.5.2 and apr-1.5.1 and it 
worked in both cases for me, so +1 from my point of view.


Regards,
Jan Kaluza


Index: t/response/TestAPI/aplog.pm
===
--- t/response/TestAPI/aplog.pm (revision 1684346)
+++ t/response/TestAPI/aplog.pm (working copy)
@@ -83,7 +83,7 @@

  # the APR_EGENERAL error string changed for APR 1.0
  my $egeneral = have_min_apache_version('2.1.0')
-   ? "Internal error"
+   ? qr/Internal error(?: \(specific information not available\))?/
 : "Error string not specified yet";

  t_server_log_warn_is_expected();




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




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

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC2

2015-06-08 Thread Jan Kaluža 

On 05/31/2015 03:12 AM, Kevin A. McGrail wrote:

On 5/30/2015 2:20 PM, Steve Hay wrote:

Please download, test, and report back on this release candidate of
the long-awaited mod_perl 2.0.9.

http://people.apache.org/~stevehay/mod_perl-2.0.9-rc2.tar.gz

MD5 = 6dbf61e0724a245f1c015687fb3e4213
SHA1 = faf63c98b338ef0373ccbbe775c52506270ff3b9

Changes since RC1:

Remove PerlInterpScope. This has not been working properly with
threaded MPMs with httpd-2.4.x and the use-case of this directive was
questionable. [Jan Kaluza]

Allow running the test suite with httpd-2.4.x when mod_access_compat
is not loaded. [Steve Hay]

The test suite finished with one failure against 2.4.12 on my test rig:

Test Summary Report
---
t/api/aplog.t (Wstat: 0 Tests: 36 Failed: 1)
   Failed test:  24
Files=245, Tests=4646, 304 wallclock secs ( 3.34 usr  0.49 sys + 227.74
cusr 50.53 csys = 282.10 CPU)
Result: FAIL
Failed 1/245 test programs. 1/4646 subtests failed.
[warning] server localhost.localdomain:8529 shutdown
[warning] port 8529 still in use...
...done
[  error] error running tests (please examine t/logs/error_log)
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++
Makefile:1112: recipe for target 'run_tests' failed
make: *** [run_tests] Error 1



Repeating with TEST_VERBOSE=1 added...  Here's the relevant output:

ok 23
# testing : $s->log_serror(LOG_MARK, LOG_DEBUG, APR::Const::EGENERAL...)
# expected: qr/(?^:Internal error: log_serror test 2)/
# received: '
# *** The following warn entry is expected and harmless ***
# [Sat May 30 21:04:59.085379 2015] [perl:debug] [pid 9642:tid 3076]
aplog.pm(90): (20014)Internal error (specific information not
available): log_serror test 2
# '
not ok 24
# testing : $r->log_rerror(LOG_MARK, LOG_CRIT, APR::Const::ENOTIME...)
# expected: qr/(?^:\[\w*:crit\] \[pid[^]]+\] .*?: \[[^]]+\] log_rerror
test)/
# received: '# Failed test 24 in
/usr/src/mod_perl-2.0.9-rc2/t/response/TestAPI/aplog.pm at line 92


Something is bad here I think, because test on line 92 is not the one 
which is failing according to the TEST_VERBOSE output. Could you check 
what's in aplog.pm at line 92?


Jan Kaluza


# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.086325 2015] [perl:crit] [pid 9642:tid 3076]
(20007)No time was provided and one was required.: [client
127.0.0.1:56778] log_rerror test
# '
ok 25
# testing : $r->log_error(...)
# expected: qr/(?^:\[\w*:error\] \[pid[^]]+\] \$r->log_error test)/
# received: '
# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.087329 2015] [:error] [pid 9642:tid 3076]
$r->log_error test
# '


Anything else I can do/provide to help fix?

regards,
KAM

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




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

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC2

2015-06-05 Thread Jan Kaluža 

On 05/31/2015 03:12 AM, Kevin A. McGrail wrote:

On 5/30/2015 2:20 PM, Steve Hay wrote:

Please download, test, and report back on this release candidate of
the long-awaited mod_perl 2.0.9.

http://people.apache.org/~stevehay/mod_perl-2.0.9-rc2.tar.gz

MD5 = 6dbf61e0724a245f1c015687fb3e4213
SHA1 = faf63c98b338ef0373ccbbe775c52506270ff3b9

Changes since RC1:

Remove PerlInterpScope. This has not been working properly with
threaded MPMs with httpd-2.4.x and the use-case of this directive was
questionable. [Jan Kaluza]

Allow running the test suite with httpd-2.4.x when mod_access_compat
is not loaded. [Steve Hay]

The test suite finished with one failure against 2.4.12 on my test rig:


Hi,

what perl version did you use, please? It seems that Perl version is the 
only common thing between people for who that test fails and for who it 
works.


Regards,
Jan Kaluza


Test Summary Report
---
t/api/aplog.t (Wstat: 0 Tests: 36 Failed: 1)
   Failed test:  24
Files=245, Tests=4646, 304 wallclock secs ( 3.34 usr  0.49 sys + 227.74
cusr 50.53 csys = 282.10 CPU)
Result: FAIL
Failed 1/245 test programs. 1/4646 subtests failed.
[warning] server localhost.localdomain:8529 shutdown
[warning] port 8529 still in use...
...done
[  error] error running tests (please examine t/logs/error_log)
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++
Makefile:1112: recipe for target 'run_tests' failed
make: *** [run_tests] Error 1



Repeating with TEST_VERBOSE=1 added...  Here's the relevant output:

ok 23
# testing : $s->log_serror(LOG_MARK, LOG_DEBUG, APR::Const::EGENERAL...)
# expected: qr/(?^:Internal error: log_serror test 2)/
# received: '
# *** The following warn entry is expected and harmless ***
# [Sat May 30 21:04:59.085379 2015] [perl:debug] [pid 9642:tid 3076]
aplog.pm(90): (20014)Internal error (specific information not
available): log_serror test 2
# '
not ok 24
# testing : $r->log_rerror(LOG_MARK, LOG_CRIT, APR::Const::ENOTIME...)
# expected: qr/(?^:\[\w*:crit\] \[pid[^]]+\] .*?: \[[^]]+\] log_rerror
test)/
# received: '# Failed test 24 in
/usr/src/mod_perl-2.0.9-rc2/t/response/TestAPI/aplog.pm at line 92
#
# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.086325 2015] [perl:crit] [pid 9642:tid 3076]
(20007)No time was provided and one was required.: [client
127.0.0.1:56778] log_rerror test
# '
ok 25
# testing : $r->log_error(...)
# expected: qr/(?^:\[\w*:error\] \[pid[^]]+\] \$r->log_error test)/
# received: '
# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.087329 2015] [:error] [pid 9642:tid 3076]
$r->log_error test
# '


Anything else I can do/provide to help fix?

regards,
KAM

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




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

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC2

2015-06-05 Thread Jan Kaluža 

On 06/04/2015 06:47 AM, Gregg Smith wrote:

On 6/3/2015 1:03 AM, Steve Hay wrote:

On 2 June 2015 at 23:30, Gregg Smith  wrote:

On 6/2/2015 10:35 AM, Steve Hay wrote:

On 2 June 2015 at 17:52, Gregg Smith   wrote:

On 6/2/2015 12:49 AM, Steve Hay wrote:

On 1 June 2015 at 18:59, Gregg Smithwrote:

On 5/30/2015 11:20 AM, Steve Hay wrote:

Is there anything more in t/logs/error_log?


Sorry for the delay, had two very busy days.

The 403 in both_str_req_proxy.t is no real surprise to me and
mod_access_compat being the culprit is what I had guessed.
mod_access_compat should not be relied upon on 2.4. It certainly does
not work as I had expected it to when I switched over from 2.2 and I see
support questions because of it in forums all the time.


Could you please try to fix it, since you are able to reproduce this 
issue? Or is there anyone else with Windows who can reproduce it and fix it?


It would be really great to spend some time fixing these bugs which 
cannot be reproduced globally, so we can finally release 2.4.x support :).



The proxy.t error might just be Vista when I think about it since you do
not get the same on Win7. Vista has a very limited number of connections
that can be open. I should upgrade to 8.1 but it's so much work to get
all my other needed software installed.



t\filter\both_str_req_proxy.t ...
1..1
# Running under perl version 5.016003 for MSWin32
# Win32::BuildNumber 1604
# Current time local: Wed Jun  3 20:48:44 2015
# Current time GMT:   Thu Jun  4 03:48:44 2015
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.39
# testing : lc input and reverse output filters
# Failed test 1 in t\filter\both_str_req_proxy.t at line 18
# expected: 'abcdefghijklmnopqrstuvwxyz0123456789'
# received: '
# 
# 403 Forbidden
# 
# Forbidden
# You don\'t have permission to access
/TestFilter__both_str_req_proxy/foo
# on this server.
# 
# 
# Apache/2.4.12 (Win32) world domination series/2.0
OpenSSL/1.0.1m mod_perl/2.0.9-rc2 Perl/
v5.16.3 Server at gls3 Port 8529
# 
# '
not ok 1
Failed 1/1 subtests

[Wed Jun 03 20:48:43.885200 2015] [charset_lite:debug] [pid 3124:tid
2344] mod_charset_lite.c(216): [client 10.0.0.33:59366] AH01448:
incomplete configuration: src unspecified, dst unspecified
[Wed Jun 03 20:48:43.885200 2015] [deflate:debug] [pid 3124:tid 2344]
mod_deflate.c(853): [client 10.0.0.33:59366] AH01384: Zlib: Compressed
21 to 26 : URL /TestFilter__both_str_req_mix
[Wed Jun 03 20:48:50.842800 2015] [access_compat:error] [pid 3124:tid
2344] [client 10.0.0.33:59367] AH01797: client denied by server
configuration:
proxy:http://GLS3:8529/TestFilter__both_str_req_proxy_content/foo
[Wed Jun 03 20:48:57.909600 2015] [authz_core:debug] [pid 3124:tid 2344]
mod_authz_core.c(834): [client 10.0.0.33:59368] AH01628: authorization
result: granted (no directives)
[Wed Jun 03 20:48:57.909600 2015] [charset_lite:debug] [pid 3124:tid
2344] mod_charset_lite.c(216): [client 10.0.0.33:59368] AH01448:
incomplete configuration: src unspecified, dst unspecified



# connecting to http://GLS3:8538/TestModules__proxy
1..1
# Running under perl version 5.016003 for MSWin32
# Win32::BuildNumber 1604
# Current time local: Wed Jun  3 21:04:05 2015
# Current time GMT:   Thu Jun  4 04:04:05 2015
# Using Test.pm version 1.26
# Using Apache/Test.pm version 1.39
request has failed (the response code was: 503)
see t/logs/error_log for more details
Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 1/1 subtests

[Wed Jun 03 21:04:13.855200 2015] [proxy:debug] [pid 3124:tid 2340]
mod_proxy.c(1161): [client 10.0.0.33:59664] AH01143: Running scheme http
handler (attempt 0)
[Wed Jun 03 21:04:13.855200 2015] [proxy_fcgi:debug] [pid 3124:tid 2340]
mod_proxy_fcgi.c(859): [client 10.0.0.33:59664] AH01076: url:
http://gls3:8538/TestModules__proxy_real proxyname: (null) proxyport: 0
[Wed Jun 03 21:04:13.855200 2015] [proxy_fcgi:debug] [pid 3124:tid 2340]
mod_proxy_fcgi.c(864): [client 10.0.0.33:59664] AH01077: declining URL
http://gls3:8538/TestModules__proxy_real
[Wed Jun 03 21:04:13.855200 2015] [proxy_scgi:debug] [pid 3124:tid 2340]
mod_proxy_scgi.c(516): [client 10.0.0.33:59664] AH00865: declining URL
http://gls3:8538/TestModules__proxy_real
[Wed Jun 03 21:04:13.855200 2015] [proxy:debug] [pid 3124:tid 2340]
proxy_util.c(2138): AH00942: HTTP: has acquired connection for (*)
[Wed Jun 03 21:04:13.855200 2015] [proxy:debug] [pid 3124:tid 2340]
proxy_util.c(2192): [client 10.0.0.33:59664] AH00944: connecting
http://gls3:8538/TestModules__proxy_real to gls3:8538
[Wed Jun 03 21:04:13.855200 2015] [proxy:debug] [pid 3124:tid 2340]
proxy_util.c(2393): [client 10.0.0.33:59664] AH00947: connected
/TestModules__proxy_real to gls3:8538
[Wed Jun 03 21:04:34.884000 2015] [proxy:error] [pid 3124:tid 2340] (OS
10060)A connection attempt failed because the connected party did not
properly respond after a period of time, or established connection
failed because connected host has failed to respond.  : AH00957: HTTP:
attempt t

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC2

2015-06-01 Thread Jan Kaluža 

On 05/31/2015 03:12 AM, Kevin A. McGrail wrote:

On 5/30/2015 2:20 PM, Steve Hay wrote:

Please download, test, and report back on this release candidate of
the long-awaited mod_perl 2.0.9.

http://people.apache.org/~stevehay/mod_perl-2.0.9-rc2.tar.gz

MD5 = 6dbf61e0724a245f1c015687fb3e4213
SHA1 = faf63c98b338ef0373ccbbe775c52506270ff3b9

Changes since RC1:

Remove PerlInterpScope. This has not been working properly with
threaded MPMs with httpd-2.4.x and the use-case of this directive was
questionable. [Jan Kaluza]

Allow running the test suite with httpd-2.4.x when mod_access_compat
is not loaded. [Steve Hay]

The test suite finished with one failure against 2.4.12 on my test rig:

Test Summary Report
---
t/api/aplog.t (Wstat: 0 Tests: 36 Failed: 1)
   Failed test:  24
Files=245, Tests=4646, 304 wallclock secs ( 3.34 usr  0.49 sys + 227.74
cusr 50.53 csys = 282.10 CPU)
Result: FAIL
Failed 1/245 test programs. 1/4646 subtests failed.
[warning] server localhost.localdomain:8529 shutdown
[warning] port 8529 still in use...
...done
[  error] error running tests (please examine t/logs/error_log)
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++
Makefile:1112: recipe for target 'run_tests' failed
make: *** [run_tests] Error 1



Repeating with TEST_VERBOSE=1 added...  Here's the relevant output:

ok 23
# testing : $s->log_serror(LOG_MARK, LOG_DEBUG, APR::Const::EGENERAL...)
# expected: qr/(?^:Internal error: log_serror test 2)/
# received: '
# *** The following warn entry is expected and harmless ***
# [Sat May 30 21:04:59.085379 2015] [perl:debug] [pid 9642:tid 3076]
aplog.pm(90): (20014)Internal error (specific information not
available): log_serror test 2
# '
not ok 24
# testing : $r->log_rerror(LOG_MARK, LOG_CRIT, APR::Const::ENOTIME...)
# expected: qr/(?^:\[\w*:crit\] \[pid[^]]+\] .*?: \[[^]]+\] log_rerror
test)/
# received: '# Failed test 24 in
/usr/src/mod_perl-2.0.9-rc2/t/response/TestAPI/aplog.pm at line 92
#
# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.086325 2015] [perl:crit] [pid 9642:tid 3076]
(20007)No time was provided and one was required.: [client
127.0.0.1:56778] log_rerror test
# '
ok 25
# testing : $r->log_error(...)
# expected: qr/(?^:\[\w*:error\] \[pid[^]]+\] \$r->log_error test)/
# received: '
# *** The following error entry is expected and harmless ***
# [Sat May 30 21:04:59.087329 2015] [:error] [pid 9642:tid 3076]
$r->log_error test
# '



Hm, I don't see this fail on my machines. It's strange, because the log 
line looks quite similar to yours:


*** The following error entry is expected and harmless ***
[Mon Jun 01 09:40:54.402616 2015] [perl:crit] [pid 26515:tid 
140439323637504] (20007)No time was provided and one was required.: 
[client 127.0.0.1:46822] log_rerror test


Anyway, there has to be something wrong with the regexp matching this 
log line:


if (APACHE24) {
ok t_cmp $logdiff->diff,
qr/\[\w*:crit\] \[pid[^]]+\] .*?: \[[^]]+\] log_rerror test/,
'$r->log_rerror(LOG_MARK, LOG_CRIT, APR::Const::ENOTIME...)';
}
else {
ok t_cmp $logdiff->diff,
qr/\[crit\] .*?: log_rerror test/,
'$r->log_rerror(LOG_MARK, LOG_CRIT, APR::Const::ENOTIME...)';
}

Any ideas someone?

Regards,
Jan Kaluza


Anything else I can do/provide to help fix?

regards,
KAM

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




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

PerlInterpScope removed, the compatibility with threaded MPMs fixed

2015-05-28 Thread Jan Kaluža 

Hi,

as discussed in the thread about commit r1676417, I've removed 
PerlInterpScope directive. The reasoning is described in the 
http://svn.apache.org/r1682369 commit message, but I will paste it here too:


~~~
Remove PerlInterpScope directive as discussed on mailing list.
PerlInterpScope did not work correctly with httpd-2.4.x threaded MPMs.
For example when using 'PerlInterpScope connection' and multiple
requests are handled using the single connection, every request tries
to fetch new interpreter. This leads to deadlock soon, because we can 
always have more requests than interpreters.


There are more situations like the one described above and the fix is 
quite hard with the way how the usage of PerlInterpeters is designed 
currently.

~~~

This and other changes I've done in trunk today should fix the 
modperl-2.0.9-RC1 freeze seen with threaded MPMs on httpd-2.4.x. Could 
you please test it?


If things will look OK, maybe we could release RC2 to let more people to 
test it.


Regards,
Jan Kaluza

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

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-28 Thread Jan Kaluža 

On 05/28/2015 12:44 AM, Steve Hay wrote:


On 25 May 2015 10:11, "Jan Kaluža" mailto:jkal...@redhat.com>> wrote:
 >
 > On 05/24/2015 04:50 PM, Steve Hay wrote:
 >>
 >> On 20 May 2015 at 14:51, Jan Kaluža mailto:jkal...@redhat.com>> wrote:
 >>>
 >>> On 05/20/2015 11:49 AM, Jan Kaluža wrote:
 >>>>
 >>>>
 >>>> On 05/15/2015 12:26 PM, Jan Kaluža wrote:
 >>>>>
 >>>>>
 >>>>> On 05/15/2015 11:57 AM, Jan Kaluža wrote:
 >>>>>>
 >>>>>>
 >>>>>> On 05/15/2015 10:01 AM, Steve Hay wrote:
 >>>>>>>
 >>>>>>>
 >>>>>>> On 15 May 2015 at 08:56, Steve Hay mailto:steve.m@googlemail.com>> wrote:
 >>>>>>>>
 >>>>>>>>
 >>>>>>>> On 15 May 2015 at 07:14, Jan Kaluža mailto:jkal...@redhat.com>> wrote:
 >>>>>>>>>
 >>>>>>>>>
 >>>>>>>>> On 05/14/2015 07:42 PM, Steve Hay wrote:
 >>>>>>>>>>
 >>>>>>>>>>
 >>>>>>>>>>
 >>>>>>>>>> On 14 May 2015 at 12:48, Jan Kaluža mailto:jkal...@redhat.com>> wrote:
 >>>>>>>>>>>
 >>>>>>>>>>>
 >>>>>>>>>>>
 >>>>>>>>>>> On 05/14/2015 11:24 AM, Niko Tyni wrote:
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>> On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:
 >>>>>>>>>>>>>
 >>>>>>>>>>>>>
 >>>>>>>>>>>>>
 >>>>>>>>>>>>>
 >>>>>>>>>>>>> On 28 April 2015 at 07:51,  mailto:jkal...@apache.org>> wrote:
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>> Author: jkaluza
 >>>>>>>>>>>>>> Date: Tue Apr 28 06:51:12 2015
 >>>>>>>>>>>>>> New Revision: 1676417
 >>>>>>>>>>>>>>
 >>>>>>>>>>>>>> URL: http://svn.apache.org/r1676417
 >>>>>>>>>>>>>> Log:
 >>>>>>>>>>>>>> Initialize interp->refcnt to 1 in modperl_interp_select.
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>
 >>>>>>>>>>>>> I cannot understand why, but since this patch was applied
I find
 >>>>>>>>>>>>> that
 >>>>>>>>>>>>> t\modules\proxy.t fails every time when I run the full "nmake
 >>>>>>>>>>>>> test",
 >>>>>>>>>>>>> but it always succeeds when I run it in isolation so I'm at a
 >>>>>>>>>>>>> loss to
 >>>>>>>>>>>>> find out what is going wrong. All other tests (apart from
those
 >>>>>>>>>>>>> known
 >>>>>>>>>>>>> Win32-specific failures documented in README) still pass.
 >>>>>>>>>>>>> Reverting
 >>>>>>>>>>>>> the patch "fixes" the proxy.t problem, but probably isn't the
 >>>>>>>>>>>>> right
 >>>>>>>>>>>>> solution.
 >>>>>>>>>>>
 >>>>>>>>>>>
 >>>>>>>>>>>
 >>>>>>>>>>>
 >>>>>>>>>>>
 >>>>>>>>>>> It's caused by Perl_croak/modperl_croak.
 >>>>>>>>>>>
 >>>>>>>>>>> Lets take modperl_run_filter as an example. When followin

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-25 Thread Jan Kaluža 

On 05/24/2015 04:50 PM, Steve Hay wrote:

On 20 May 2015 at 14:51, Jan Kaluža  wrote:

On 05/20/2015 11:49 AM, Jan Kaluža wrote:


On 05/15/2015 12:26 PM, Jan Kaluža wrote:


On 05/15/2015 11:57 AM, Jan Kaluža wrote:


On 05/15/2015 10:01 AM, Steve Hay wrote:


On 15 May 2015 at 08:56, Steve Hay  wrote:


On 15 May 2015 at 07:14, Jan Kaluža  wrote:


On 05/14/2015 07:42 PM, Steve Hay wrote:



On 14 May 2015 at 12:48, Jan Kaluža  wrote:



On 05/14/2015 11:24 AM, Niko Tyni wrote:




On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:




On 28 April 2015 at 07:51,   wrote:




Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.






I cannot understand why, but since this patch was applied I find
that
t\modules\proxy.t fails every time when I run the full "nmake
test",
but it always succeeds when I run it in isolation so I'm at a
loss to
find out what is going wrong. All other tests (apart from those
known
Win32-specific failures documented in README) still pass.
Reverting
the patch "fixes" the proxy.t problem, but probably isn't the
right
solution.





It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following
code-path is
executed ...

   modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
 "a filter calling $f->read "
 "must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I
presume it's
because of Perl_croak, but I don't understand why it stops the
execution
of
the rest of modperl_run_filter method).

Because of that, the interp->refcnt is not decreased, and the
interp is
not
freed.

I has been able to "fix" it by attached patch, but I would like to
discuss
more generic way how to fix that problem...

Any ideas?



modperl_croak() calls Perl_croak(), which is an XS interface to
Perl's
die() function, so surely you wouldn't expect anything immediately
after it to be run?

I'm not sure exactly where it does end up, though. It must be
getting
caught by some eval somewhere since we aren't exiting the process,
but
presumably it wouldn't be possible to do appropriate clean-up
wherever
it lands up unless there is some mechanism for registering required
clean-up behaviour? Otherwise maybe we need to pass interp into
modperl_croak(), or into a new version of that if not all cases
require it, so that it can do the MP_INTERP_PUTBACK(interp, aTHX)
call?



What worries me here a bit is that we would have to
MP_INTEPR_PUTBACK the
PerlInterp which is later used for PerlCroak, if I understand it
right.

I have found out that usually when modperl_croak is called, the
refcnt of
the interp is above 1, so it wouldn't get freed prematurely, but
still.

I think for now we should putback the interp only when
interp->refcnt > 1,
it wouldn't fully fix all bugs, but lot of them would be fixed by
that.

If someone knows how Perl_croak works and if it's possible to
cleanup the
interp after that, it would be great to share that info .



My understanding of Perl_croak() is that it either exits the process
(if not inside an eval()) or else calls the system's longjmp(), which
resumes execution from immediately after where the corresponding
setjmp() was called, having restored the process environment to the
original state at that point too.

In the perl source, the setjmp()/longjmp() of eval()/die() are done by
the JMPENV_PUSH in Perl_eval_sv() (maybe called from Perl_eval_pv())
and the JMPENV_JUMP in Perl_die_unwind(), called from Perl_vcroak().
The JMPENV* macros are in cop.h, and call
PerlProc_setjmp()/PerlProc_longjmp(), which are typically
setjmp()/longjmp(), or maybe sigsetjmp()/siglongjmp() if you have
them.

I think you're right that we should probably check that interp->refcnt


1 if we go ahead and pass interp into modperl_croak(). There aren't


too many calls, so this may be workable; we also have a few call
MP_RUN_CROAK()/MP_RUN_CROAK_RESET() calls to look at too. What worries
me is the (much larger number of!) calls to Perl_croak(). They will
also not return, so we presumably need to do cleanup before each one
of those too? Maybe we need a little wrapper function/macro to do
clean up and then call Perl_croak() and use that everywhere instead of
Perl_croak() (including the call inside modperl_croak(), of course)?



The other approach I mentioned earlier was to try to do the cleanup in
the eval() where the die() has landed. If that's possible then it
might be a cleaner approach.

In this case, I think we're inside the eval_pv done in
modperl_filter_resolve_init_handler(). I only see three other eval*()s
(one more eval_pv() and two eval_sv()s) around the mod_perl C source
code so this could

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-20 Thread Jan Kaluža 

On 05/20/2015 11:49 AM, Jan Kaluža wrote:

On 05/15/2015 12:26 PM, Jan Kaluža wrote:

On 05/15/2015 11:57 AM, Jan Kaluža wrote:

On 05/15/2015 10:01 AM, Steve Hay wrote:

On 15 May 2015 at 08:56, Steve Hay  wrote:

On 15 May 2015 at 07:14, Jan Kaluža  wrote:

On 05/14/2015 07:42 PM, Steve Hay wrote:


On 14 May 2015 at 12:48, Jan Kaluža  wrote:


On 05/14/2015 11:24 AM, Niko Tyni wrote:



On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:



On 28 April 2015 at 07:51,   wrote:



Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.





I cannot understand why, but since this patch was applied I find
that
t\modules\proxy.t fails every time when I run the full "nmake
test",
but it always succeeds when I run it in isolation so I'm at a
loss to
find out what is going wrong. All other tests (apart from those
known
Win32-specific failures documented in README) still pass.
Reverting
the patch "fixes" the proxy.t problem, but probably isn't the
right
solution.




It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following
code-path is
executed ...

  modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
"a filter calling $f->read "
"must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I
presume it's
because of Perl_croak, but I don't understand why it stops the
execution
of
the rest of modperl_run_filter method).

Because of that, the interp->refcnt is not decreased, and the
interp is
not
freed.

I has been able to "fix" it by attached patch, but I would like to
discuss
more generic way how to fix that problem...

Any ideas?



modperl_croak() calls Perl_croak(), which is an XS interface to
Perl's
die() function, so surely you wouldn't expect anything immediately
after it to be run?

I'm not sure exactly where it does end up, though. It must be
getting
caught by some eval somewhere since we aren't exiting the process,
but
presumably it wouldn't be possible to do appropriate clean-up
wherever
it lands up unless there is some mechanism for registering required
clean-up behaviour? Otherwise maybe we need to pass interp into
modperl_croak(), or into a new version of that if not all cases
require it, so that it can do the MP_INTERP_PUTBACK(interp, aTHX)
call?



What worries me here a bit is that we would have to
MP_INTEPR_PUTBACK the
PerlInterp which is later used for PerlCroak, if I understand it
right.

I have found out that usually when modperl_croak is called, the
refcnt of
the interp is above 1, so it wouldn't get freed prematurely, but
still.

I think for now we should putback the interp only when
interp->refcnt > 1,
it wouldn't fully fix all bugs, but lot of them would be fixed by
that.

If someone knows how Perl_croak works and if it's possible to
cleanup the
interp after that, it would be great to share that info .



My understanding of Perl_croak() is that it either exits the process
(if not inside an eval()) or else calls the system's longjmp(), which
resumes execution from immediately after where the corresponding
setjmp() was called, having restored the process environment to the
original state at that point too.

In the perl source, the setjmp()/longjmp() of eval()/die() are done by
the JMPENV_PUSH in Perl_eval_sv() (maybe called from Perl_eval_pv())
and the JMPENV_JUMP in Perl_die_unwind(), called from Perl_vcroak().
The JMPENV* macros are in cop.h, and call
PerlProc_setjmp()/PerlProc_longjmp(), which are typically
setjmp()/longjmp(), or maybe sigsetjmp()/siglongjmp() if you have
them.

I think you're right that we should probably check that interp->refcnt

1 if we go ahead and pass interp into modperl_croak(). There aren't

too many calls, so this may be workable; we also have a few call
MP_RUN_CROAK()/MP_RUN_CROAK_RESET() calls to look at too. What worries
me is the (much larger number of!) calls to Perl_croak(). They will
also not return, so we presumably need to do cleanup before each one
of those too? Maybe we need a little wrapper function/macro to do
clean up and then call Perl_croak() and use that everywhere instead of
Perl_croak() (including the call inside modperl_croak(), of course)?


The other approach I mentioned earlier was to try to do the cleanup in
the eval() where the die() has landed. If that's possible then it
might be a cleaner approach.

In this case, I think we're inside the eval_pv done in
modperl_filter_resolve_init_handler(). I only see three other eval*()s
(one more eval_pv() and two eval_sv()s) around the mod_perl C source
code so this could be worth pursuing.


Hm, maybe stupid idea, but could we store the refcnt before the eval and
reset it af

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-20 Thread Jan Kaluža 

On 05/15/2015 12:26 PM, Jan Kaluža wrote:

On 05/15/2015 11:57 AM, Jan Kaluža wrote:

On 05/15/2015 10:01 AM, Steve Hay wrote:

On 15 May 2015 at 08:56, Steve Hay  wrote:

On 15 May 2015 at 07:14, Jan Kaluža  wrote:

On 05/14/2015 07:42 PM, Steve Hay wrote:


On 14 May 2015 at 12:48, Jan Kaluža  wrote:


On 05/14/2015 11:24 AM, Niko Tyni wrote:



On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:



On 28 April 2015 at 07:51,   wrote:



Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.





I cannot understand why, but since this patch was applied I find
that
t\modules\proxy.t fails every time when I run the full "nmake
test",
but it always succeeds when I run it in isolation so I'm at a
loss to
find out what is going wrong. All other tests (apart from those
known
Win32-specific failures documented in README) still pass.
Reverting
the patch "fixes" the proxy.t problem, but probably isn't the
right
solution.




It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following
code-path is
executed ...

  modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
"a filter calling $f->read "
"must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I
presume it's
because of Perl_croak, but I don't understand why it stops the
execution
of
the rest of modperl_run_filter method).

Because of that, the interp->refcnt is not decreased, and the
interp is
not
freed.

I has been able to "fix" it by attached patch, but I would like to
discuss
more generic way how to fix that problem...

Any ideas?



modperl_croak() calls Perl_croak(), which is an XS interface to
Perl's
die() function, so surely you wouldn't expect anything immediately
after it to be run?

I'm not sure exactly where it does end up, though. It must be getting
caught by some eval somewhere since we aren't exiting the process,
but
presumably it wouldn't be possible to do appropriate clean-up
wherever
it lands up unless there is some mechanism for registering required
clean-up behaviour? Otherwise maybe we need to pass interp into
modperl_croak(), or into a new version of that if not all cases
require it, so that it can do the MP_INTERP_PUTBACK(interp, aTHX)
call?



What worries me here a bit is that we would have to
MP_INTEPR_PUTBACK the
PerlInterp which is later used for PerlCroak, if I understand it
right.

I have found out that usually when modperl_croak is called, the
refcnt of
the interp is above 1, so it wouldn't get freed prematurely, but
still.

I think for now we should putback the interp only when
interp->refcnt > 1,
it wouldn't fully fix all bugs, but lot of them would be fixed by
that.

If someone knows how Perl_croak works and if it's possible to
cleanup the
interp after that, it would be great to share that info .



My understanding of Perl_croak() is that it either exits the process
(if not inside an eval()) or else calls the system's longjmp(), which
resumes execution from immediately after where the corresponding
setjmp() was called, having restored the process environment to the
original state at that point too.

In the perl source, the setjmp()/longjmp() of eval()/die() are done by
the JMPENV_PUSH in Perl_eval_sv() (maybe called from Perl_eval_pv())
and the JMPENV_JUMP in Perl_die_unwind(), called from Perl_vcroak().
The JMPENV* macros are in cop.h, and call
PerlProc_setjmp()/PerlProc_longjmp(), which are typically
setjmp()/longjmp(), or maybe sigsetjmp()/siglongjmp() if you have
them.

I think you're right that we should probably check that interp->refcnt

1 if we go ahead and pass interp into modperl_croak(). There aren't

too many calls, so this may be workable; we also have a few call
MP_RUN_CROAK()/MP_RUN_CROAK_RESET() calls to look at too. What worries
me is the (much larger number of!) calls to Perl_croak(). They will
also not return, so we presumably need to do cleanup before each one
of those too? Maybe we need a little wrapper function/macro to do
clean up and then call Perl_croak() and use that everywhere instead of
Perl_croak() (including the call inside modperl_croak(), of course)?


The other approach I mentioned earlier was to try to do the cleanup in
the eval() where the die() has landed. If that's possible then it
might be a cleaner approach.

In this case, I think we're inside the eval_pv done in
modperl_filter_resolve_init_handler(). I only see three other eval*()s
(one more eval_pv() and two eval_sv()s) around the mod_perl C source
code so this could be worth pursuing.


Hm, maybe stupid idea, but could we store the refcnt before the eval and
reset it after the eval? I presume that perlinterp

Re: [RELEASE CANDIDATE]: mod_perl-2.0.9 RC1

2015-05-17 Thread Jan Kaluža 

On 05/15/2015 06:15 PM, Kevin A. McGrail wrote:

On 5/13/2015 4:40 PM, Steve Hay wrote:

On 13 May 2015 at 20:55, Steve Hay  wrote:

>Please download, test, and report back on this release candidate of
>the long-awaited mod_perl 2.0.9.
>
>http://people.apache.org/~stevehay/mod_perl-2.0.9-rc1.tar.gz
>

If I can vote for my own RC then it's a +1 from me:-)

I almost always consider the release managers call for a vote as an
implicit +1

With that said, I've compiled and done make test on CentOS 6.6 with a
custom installation of both 2.2 and 2.4.  I'm currently running 2.2 on
the box because of the lack of mod_perl with installs in
/usr/local/apache2.2 and /usr/local/apache2.4

2.2 passed

With 2.4 I get this error (keep reading)

gcc -I/usr/src/mod_perl-2.0.9-rc1/src/modules/perl
-I/usr/src/mod_perl-2.0.9-rc1/xs -I/usr/local/apache2.4/include
-I/usr/local/apache2.4/include  -I/usr/local/apache2.4/include
-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -pipe -fstack-protector
-I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
-I/usr/lib64/perl5/CORE -DMOD_PERL -DMP_COMPAT_1X -DLINUX=2 -O2 -g -pipe
-Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -fPIC \
 -c modperl_constants.c && mv modperl_constants.o
modperl_constants.lo
modperl_constants.c: In function 'modperl_constants_lookup_apache2_const':
modperl_constants.c:1378: error: 'HTTP_ALREADY_REPORTED' undeclared
(first use in this function)
modperl_constants.c:1378: error: (Each undeclared identifier is reported
only once
modperl_constants.c:1378: error: for each function it appears in.)
modperl_constants.c:1433: error: 'HTTP_IM_USED' undeclared (first use in
this function)
modperl_constants.c:1458: error: 'HTTP_LOOP_DETECTED' undeclared (first
use in this function)
modperl_constants.c:1488: error: 'HTTP_NETWORK_AUTHENTICATION_REQUIRED'
undeclared (first use in this function)
modperl_constants.c:1543: error: 'HTTP_PERMANENT_REDIRECT' undeclared
(first use in this function)
modperl_constants.c:1553: error: 'HTTP_PRECONDITION_REQUIRED' undeclared
(first use in this function)
modperl_constants.c:1578: error: 'HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE'
undeclared (first use in this function)
modperl_constants.c:1618: error: 'HTTP_TOO_MANY_REQUESTS' undeclared
(first use in this function)
make[1]: *** [modperl_constants.lo] Error 1
make[1]: Leaving directory `/usr/src/mod_perl-2.0.9-rc1/src/modules/perl'
make: *** [modperl_lib] Error 2

This was with httpd 2.4.2.  So just to rule that out I used 2.4.12 and
latest apr & apr-util.
(Is there a minimum 2.4.x version for mp 2.0.9? )

After switching to 2.4.12, make test is just hanging for a LONG time at
this point:

t/filter/in_str_sandwich.t .. 1/1 # Failed test 1 in
t/filter/in_str_sandwich.t at line 16
t/filter/in_str_sandwich.t .. Failed 1/1 subtests
t/filter/out_apache.t ... skipped: cannot find module
'include'
t/filter/out_bbs_basic.t  ok
t/filter/out_bbs_ctx.t .. ok
t/filter/out_bbs_filebucket.t ... 1/10 # Failed test 1 in
t/filter/out_bbs_filebucket.t at line 26
# Failed test 2 in t/filter/out_bbs_filebucket.t at line 27


That's known issue we are discussing in another thread on this list.

Jan Kaluza


[Waited about 30 minutes until a ctrl-c]

^C[warning]
halting tests
[warning] server localhost:8529 shutdown
[warning] port 8529 still in use...

done
++
| Please file a bug report: http://perl.apache.org/bugs/ |
++
make: *** [run_tests] Error 1


repeating make test and it got farther but then seemed to hang on

t/protocol/echo_nonblock.t .. 1/3

A third test appears hung at t/filter/in_str_msg.t ...

Fourth test caught on fire and sank into the swamp.


Anyway, getting pretty inconclusive test results here with 2.4.12

Regards,
KAM



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




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

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-15 Thread Jan Kaluža 

On 05/15/2015 11:57 AM, Jan Kaluža wrote:

On 05/15/2015 10:01 AM, Steve Hay wrote:

On 15 May 2015 at 08:56, Steve Hay  wrote:

On 15 May 2015 at 07:14, Jan Kaluža  wrote:

On 05/14/2015 07:42 PM, Steve Hay wrote:


On 14 May 2015 at 12:48, Jan Kaluža  wrote:


On 05/14/2015 11:24 AM, Niko Tyni wrote:



On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:



On 28 April 2015 at 07:51,   wrote:



Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.





I cannot understand why, but since this patch was applied I find
that
t\modules\proxy.t fails every time when I run the full "nmake
test",
but it always succeeds when I run it in isolation so I'm at a
loss to
find out what is going wrong. All other tests (apart from those
known
Win32-specific failures documented in README) still pass. Reverting
the patch "fixes" the proxy.t problem, but probably isn't the right
solution.




It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following
code-path is
executed ...

  modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
"a filter calling $f->read "
"must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I
presume it's
because of Perl_croak, but I don't understand why it stops the
execution
of
the rest of modperl_run_filter method).

Because of that, the interp->refcnt is not decreased, and the
interp is
not
freed.

I has been able to "fix" it by attached patch, but I would like to
discuss
more generic way how to fix that problem...

Any ideas?



modperl_croak() calls Perl_croak(), which is an XS interface to Perl's
die() function, so surely you wouldn't expect anything immediately
after it to be run?

I'm not sure exactly where it does end up, though. It must be getting
caught by some eval somewhere since we aren't exiting the process, but
presumably it wouldn't be possible to do appropriate clean-up wherever
it lands up unless there is some mechanism for registering required
clean-up behaviour? Otherwise maybe we need to pass interp into
modperl_croak(), or into a new version of that if not all cases
require it, so that it can do the MP_INTERP_PUTBACK(interp, aTHX)
call?



What worries me here a bit is that we would have to
MP_INTEPR_PUTBACK the
PerlInterp which is later used for PerlCroak, if I understand it right.

I have found out that usually when modperl_croak is called, the
refcnt of
the interp is above 1, so it wouldn't get freed prematurely, but still.

I think for now we should putback the interp only when
interp->refcnt > 1,
it wouldn't fully fix all bugs, but lot of them would be fixed by that.

If someone knows how Perl_croak works and if it's possible to
cleanup the
interp after that, it would be great to share that info .



My understanding of Perl_croak() is that it either exits the process
(if not inside an eval()) or else calls the system's longjmp(), which
resumes execution from immediately after where the corresponding
setjmp() was called, having restored the process environment to the
original state at that point too.

In the perl source, the setjmp()/longjmp() of eval()/die() are done by
the JMPENV_PUSH in Perl_eval_sv() (maybe called from Perl_eval_pv())
and the JMPENV_JUMP in Perl_die_unwind(), called from Perl_vcroak().
The JMPENV* macros are in cop.h, and call
PerlProc_setjmp()/PerlProc_longjmp(), which are typically
setjmp()/longjmp(), or maybe sigsetjmp()/siglongjmp() if you have
them.

I think you're right that we should probably check that interp->refcnt

1 if we go ahead and pass interp into modperl_croak(). There aren't

too many calls, so this may be workable; we also have a few call
MP_RUN_CROAK()/MP_RUN_CROAK_RESET() calls to look at too. What worries
me is the (much larger number of!) calls to Perl_croak(). They will
also not return, so we presumably need to do cleanup before each one
of those too? Maybe we need a little wrapper function/macro to do
clean up and then call Perl_croak() and use that everywhere instead of
Perl_croak() (including the call inside modperl_croak(), of course)?


The other approach I mentioned earlier was to try to do the cleanup in
the eval() where the die() has landed. If that's possible then it
might be a cleaner approach.

In this case, I think we're inside the eval_pv done in
modperl_filter_resolve_init_handler(). I only see three other eval*()s
(one more eval_pv() and two eval_sv()s) around the mod_perl C source
code so this could be worth pursuing.


Hm, maybe stupid idea, but could we store the refcnt before the eval and
reset it after the eval? I presume that perlinterp is valid for the
evaluated code only when we a

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-15 Thread Jan Kaluža 

On 05/15/2015 10:01 AM, Steve Hay wrote:

On 15 May 2015 at 08:56, Steve Hay  wrote:

On 15 May 2015 at 07:14, Jan Kaluža  wrote:

On 05/14/2015 07:42 PM, Steve Hay wrote:


On 14 May 2015 at 12:48, Jan Kaluža  wrote:


On 05/14/2015 11:24 AM, Niko Tyni wrote:



On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:



On 28 April 2015 at 07:51,   wrote:



Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.





I cannot understand why, but since this patch was applied I find that
t\modules\proxy.t fails every time when I run the full "nmake test",
but it always succeeds when I run it in isolation so I'm at a loss to
find out what is going wrong. All other tests (apart from those known
Win32-specific failures documented in README) still pass. Reverting
the patch "fixes" the proxy.t problem, but probably isn't the right
solution.




It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following code-path is
executed ...

  modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
"a filter calling $f->read "
"must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I presume it's
because of Perl_croak, but I don't understand why it stops the execution
of
the rest of modperl_run_filter method).

Because of that, the interp->refcnt is not decreased, and the interp is
not
freed.

I has been able to "fix" it by attached patch, but I would like to
discuss
more generic way how to fix that problem...

Any ideas?



modperl_croak() calls Perl_croak(), which is an XS interface to Perl's
die() function, so surely you wouldn't expect anything immediately
after it to be run?

I'm not sure exactly where it does end up, though. It must be getting
caught by some eval somewhere since we aren't exiting the process, but
presumably it wouldn't be possible to do appropriate clean-up wherever
it lands up unless there is some mechanism for registering required
clean-up behaviour? Otherwise maybe we need to pass interp into
modperl_croak(), or into a new version of that if not all cases
require it, so that it can do the MP_INTERP_PUTBACK(interp, aTHX)
call?



What worries me here a bit is that we would have to MP_INTEPR_PUTBACK the
PerlInterp which is later used for PerlCroak, if I understand it right.

I have found out that usually when modperl_croak is called, the refcnt of
the interp is above 1, so it wouldn't get freed prematurely, but still.

I think for now we should putback the interp only when interp->refcnt > 1,
it wouldn't fully fix all bugs, but lot of them would be fixed by that.

If someone knows how Perl_croak works and if it's possible to cleanup the
interp after that, it would be great to share that info .



My understanding of Perl_croak() is that it either exits the process
(if not inside an eval()) or else calls the system's longjmp(), which
resumes execution from immediately after where the corresponding
setjmp() was called, having restored the process environment to the
original state at that point too.

In the perl source, the setjmp()/longjmp() of eval()/die() are done by
the JMPENV_PUSH in Perl_eval_sv() (maybe called from Perl_eval_pv())
and the JMPENV_JUMP in Perl_die_unwind(), called from Perl_vcroak().
The JMPENV* macros are in cop.h, and call
PerlProc_setjmp()/PerlProc_longjmp(), which are typically
setjmp()/longjmp(), or maybe sigsetjmp()/siglongjmp() if you have
them.

I think you're right that we should probably check that interp->refcnt

1 if we go ahead and pass interp into modperl_croak(). There aren't

too many calls, so this may be workable; we also have a few call
MP_RUN_CROAK()/MP_RUN_CROAK_RESET() calls to look at too. What worries
me is the (much larger number of!) calls to Perl_croak(). They will
also not return, so we presumably need to do cleanup before each one
of those too? Maybe we need a little wrapper function/macro to do
clean up and then call Perl_croak() and use that everywhere instead of
Perl_croak() (including the call inside modperl_croak(), of course)?


The other approach I mentioned earlier was to try to do the cleanup in
the eval() where the die() has landed. If that's possible then it
might be a cleaner approach.

In this case, I think we're inside the eval_pv done in
modperl_filter_resolve_init_handler(). I only see three other eval*()s
(one more eval_pv() and two eval_sv()s) around the mod_perl C source
code so this could be worth pursuing.


Hm, maybe stupid idea, but could we store the refcnt before the eval and 
reset it after the eval? I presume that perlinterp is valid for the 
evaluated code only when we are in the eval(), so if something incr

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-14 Thread Jan Kaluža 

On 05/14/2015 07:42 PM, Steve Hay wrote:

On 14 May 2015 at 12:48, Jan Kaluža  wrote:

On 05/14/2015 11:24 AM, Niko Tyni wrote:


On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:


On 28 April 2015 at 07:51,   wrote:


Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.




I cannot understand why, but since this patch was applied I find that
t\modules\proxy.t fails every time when I run the full "nmake test",
but it always succeeds when I run it in isolation so I'm at a loss to
find out what is going wrong. All other tests (apart from those known
Win32-specific failures documented in README) still pass. Reverting
the patch "fixes" the proxy.t problem, but probably isn't the right
solution.



It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following code-path is
executed ...

 modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
   "a filter calling $f->read "
   "must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I presume it's
because of Perl_croak, but I don't understand why it stops the execution of
the rest of modperl_run_filter method).

Because of that, the interp->refcnt is not decreased, and the interp is not
freed.

I has been able to "fix" it by attached patch, but I would like to discuss
more generic way how to fix that problem...

Any ideas?



modperl_croak() calls Perl_croak(), which is an XS interface to Perl's
die() function, so surely you wouldn't expect anything immediately
after it to be run?

I'm not sure exactly where it does end up, though. It must be getting
caught by some eval somewhere since we aren't exiting the process, but
presumably it wouldn't be possible to do appropriate clean-up wherever
it lands up unless there is some mechanism for registering required
clean-up behaviour? Otherwise maybe we need to pass interp into
modperl_croak(), or into a new version of that if not all cases
require it, so that it can do the MP_INTERP_PUTBACK(interp, aTHX)
call?



What worries me here a bit is that we would have to MP_INTEPR_PUTBACK 
the PerlInterp which is later used for PerlCroak, if I understand it right.


I have found out that usually when modperl_croak is called, the refcnt 
of the interp is above 1, so it wouldn't get freed prematurely, but still.


I think for now we should putback the interp only when interp->refcnt > 
1, it wouldn't fully fix all bugs, but lot of them would be fixed by that.


If someone knows how Perl_croak works and if it's possible to cleanup 
the interp after that, it would be great to share that info .


Regards,
Jan Kaluza


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

Re: svn commit: r1676417 - /perl/modperl/trunk/src/modules/perl/modperl_interp.c

2015-05-14 Thread Jan Kaluža 

On 05/14/2015 11:24 AM, Niko Tyni wrote:

On Sun, May 10, 2015 at 01:47:19PM +0100, Steve Hay wrote:

On 28 April 2015 at 07:51,   wrote:

Author: jkaluza
Date: Tue Apr 28 06:51:12 2015
New Revision: 1676417

URL: http://svn.apache.org/r1676417
Log:
Initialize interp->refcnt to 1 in modperl_interp_select.



I cannot understand why, but since this patch was applied I find that
t\modules\proxy.t fails every time when I run the full "nmake test",
but it always succeeds when I run it in isolation so I'm at a loss to
find out what is going wrong. All other tests (apart from those known
Win32-specific failures documented in README) still pass. Reverting
the patch "fixes" the proxy.t problem, but probably isn't the right
solution.


It's caused by Perl_croak/modperl_croak.

Lets take modperl_run_filter as an example. When following code-path is 
executed ...


modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
  "a filter calling $f->read "
  "must return OK and not DECLINED");

... the MP_INTERP_PUTBACK is not reached for some reason (I presume it's 
because of Perl_croak, but I don't understand why it stops the execution 
of the rest of modperl_run_filter method).


Because of that, the interp->refcnt is not decreased, and the interp is 
not freed.


I has been able to "fix" it by attached patch, but I would like to 
discuss more generic way how to fix that problem...


Any ideas?

Regards,
Jan Kaluza


As a data point, this also seems to happen with 2.0.9-RC1 on Debian
kfreebsd-amd64.

   
https://buildd.debian.org/status/fetch.php?pkg=libapache2-mod-perl2&arch=kfreebsd-amd64&ver=2.0.9~rc1-1&stamp=1431587841

   request has failed (the response code was: 502)
   see t/logs/error_log for more details
   t/modules/proxy.t ...
   # connecting to http://localhost:8538/TestModules__proxy
   1..1
   # Running under perl version 5.020002 for gnukfreebsd
   # Current time local: Thu May 14 07:15:21 2015
   # Current time GMT:   Thu May 14 07:15:21 2015
   # Using Test.pm version 1.26
   # Using Apache/Test.pm version 1.39
   Dubious, test returned 2 (wstat 512, 0x200)
   Failed 1/1 subtests

I haven't been able to test yet whether it's reproducible there.



Index: src/modules/perl/modperl_filter.c
===
--- src/modules/perl/modperl_filter.c	(revision 1679170)
+++ src/modules/perl/modperl_filter.c	(working copy)
@@ -535,6 +535,7 @@
  * pass the bucket brigade through after it called
  * $f->read(), since it causes a pre-fetch of the
  * bb */
+interp->refcnt--;
 modperl_croak(aTHX_ MODPERL_FILTER_ERROR,
   "a filter calling $f->read "
   "must return OK and not DECLINED");


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

Re: [RELEASE CANDIDATE] Apache-Test-1.39 RC1

2015-04-17 Thread Jan Kaluža 

On 04/16/2015 10:36 PM, Adam Prime wrote:

+1

server localhost:8529 started
[   info] adding source lib /tmp/Apache-Test-1.39-rc1/lib to @INC
t/alltest/allskipped
 all skipped: testing all.t
t/alltest2/all...skipped
 all skipped: testing more than one all.t
t/bad_coding.ok
t/cookiesok
t/import.ok
t/log_watch..ok
t/more/all...skipped
 all skipped: cannot find module 'mod_perl.c'
t/next_available_portok
t/ping...ok
t/redirect...ok
t/requestok
t/sokok
All tests successful, 3 tests skipped.
Files=12, Tests=88, 15 wallclock secs (13.79 cusr +  1.08 csys = 14.87 CPU)
[warning] server localhost:8529 shutdown



I see the same on Fedora 21, perl-5.18.4-306.fc21.x86_64, 
httpd-2.4.12-1.fc23.x86_64 (testing version, not in Fedora 21 normally).


Jan Kaluza




On 15-04-08 09:24 AM, Steve Hay wrote:

Please download, test, and report back on this Apache-Test 1.39
release candidate.

http://people.apache.org/~stevehay/Apache-Test-1.39-rc1.tar.gz

MD5  = ee927033dd36bb6befb34443b7353f4f
SHA1 = ab048a92d70b55a44668db240e9c9e3a969ef4a2

=item 1.39-rc1

Test scripts can now test if perl has a fork() implementation
available by using the Apache::Test::need_fork() function. [Steve Hay]

CPAN RT#87620: Add -D APACHE2_4 to identify httpd-2.4. [Michael Schout]

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




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




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

Re: Back at testing 2.0.9-dev with httpd 2.4.12

2015-03-25 Thread Jan Kaluža 

On 03/25/2015 09:44 AM, Jan Kaluža wrote:

On 03/25/2015 06:52 AM, Fred Moyer wrote:

Here's my latest results from testing 2.0.9-dev with httpd 2.4.12 on
OS X 10.10.2

Configured httpd with:

./configure --prefix=$HOME/dev/httpd_24 --with-included_apr
--with-mpm=prefork

By default httpd 2.4 builds with the event MPM I found.

I built mod_perl with:

perl Makefile.PL MP_NO_THREADS=1

The build is successful, but for some reason the
_mod_perl_handler_name symbol can't be found during make test. Will
dig into it, any pointers appreciated.

/Users/phred/dev/httpd_24/bin/httpd  -d
/Users/phred/dev/modperl/mod_perl-2.0/t -f
/Users/phred/dev/modperl/mod_perl-2.0/t/conf/httpd.conf -D APACHE2
using Apache/2.4.12 (prefork MPM)
waiting 300 seconds for server to start: 00:00httpd: Syntax error on
line 82 of /Users/phred/dev/modperl/mod_perl-2.0/t/conf/httpd.conf:
Cannot load
/Users/phred/dev/modperl/mod_perl-2.0/src/modules/perl/mod_perl.so
into server:
dlopen(/Users/phred/dev/modperl/mod_perl-2.0/src/modules/perl/mod_perl.so,

10): Symbol not found: _modperl_handler_name\n  Referenced from:
/Users/phred/dev/modperl/mod_perl-2.0/src/modules/perl/mod_perl.so\n
Expected in: dynamic lookup\n
waiting 300 seconds for server to start: 00:45^C


This looks like:

http://mail-archives.apache.org/mod_mbox/perl-modperl/201211.mbox/%3C1B32FF956ABF414C9BCE5E487A1497E70EC7DB38@ukmail02.planit.group%3E


The key thing from that thread is probably:

The problem appears to have been that APR was built with gcc, but 
because Perl's Configure
had picked up cc (which was clang, not gcc), then mod_perl was being 
compiled with cc, but

getting the wrong definition for MP_INLINE as a result.



Regards,
Jan Kaluza


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




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




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

Re: Back at testing 2.0.9-dev with httpd 2.4.12

2015-03-25 Thread Jan Kaluža 

On 03/25/2015 06:52 AM, Fred Moyer wrote:

Here's my latest results from testing 2.0.9-dev with httpd 2.4.12 on
OS X 10.10.2

Configured httpd with:

./configure --prefix=$HOME/dev/httpd_24 --with-included_apr --with-mpm=prefork

By default httpd 2.4 builds with the event MPM I found.

I built mod_perl with:

perl Makefile.PL MP_NO_THREADS=1

The build is successful, but for some reason the
_mod_perl_handler_name symbol can't be found during make test. Will
dig into it, any pointers appreciated.

/Users/phred/dev/httpd_24/bin/httpd  -d
/Users/phred/dev/modperl/mod_perl-2.0/t -f
/Users/phred/dev/modperl/mod_perl-2.0/t/conf/httpd.conf -D APACHE2
using Apache/2.4.12 (prefork MPM)
waiting 300 seconds for server to start: 00:00httpd: Syntax error on
line 82 of /Users/phred/dev/modperl/mod_perl-2.0/t/conf/httpd.conf:
Cannot load /Users/phred/dev/modperl/mod_perl-2.0/src/modules/perl/mod_perl.so
into server: 
dlopen(/Users/phred/dev/modperl/mod_perl-2.0/src/modules/perl/mod_perl.so,
10): Symbol not found: _modperl_handler_name\n  Referenced from:
/Users/phred/dev/modperl/mod_perl-2.0/src/modules/perl/mod_perl.so\n
Expected in: dynamic lookup\n
waiting 300 seconds for server to start: 00:45^C


This looks like:

http://mail-archives.apache.org/mod_mbox/perl-modperl/201211.mbox/%3C1B32FF956ABF414C9BCE5E487A1497E70EC7DB38@ukmail02.planit.group%3E

Regards,
Jan Kaluza


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




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

Re: test failure in svn head

2015-03-11 Thread Jan Kaluža 

On 02/03/2015 09:19 AM, Steve Hay wrote:

On 28 January 2015 at 01:33, Steve Hay  wrote:

On 26 January 2015 at 09:21, Steve Hay  wrote:

On 25 January 2015 at 19:41, Steve Hay  wrote:

On 24 January 2015 at 04:32, Fred Moyer  wrote:

Ran across a test failure while trying to roll RC1 today. Any thoughts?

perl 5.14.2, httpd 2.4.6

fred@dev ~/dev/mod_perl-2.0 $ uname -r
2.6.32-220.23.1.el6.x86_64

Built via:

perl Makefile.PL MP_APXS=/home/fred/dev/httpd24/bin/apxs MP_NO_THREADS=1

Build succeeded, but got a test failure on test startup.

fred@dev ~/dev/mod_perl-2.0 $ tail -f t/logs/error_log
[Fri Jan 23 14:26:30.719260 2015] [perl:error] [pid 93630] Can't
locate object method "loglevel" via package "Apache2::ServerRec" at
/home/fred/dev/mod_perl-2.0/t/conf/post_config_startup.pl line
82.\nCompilation failed in require at (eval 197) line 1.\n
[Fri Jan 23 14:26:30.719295 2015] [perl:error] [pid 93630] Can't load
Perl file: /home/fred/dev/mod_perl-2.0/t/conf/post_config_startup.pl
for server localhost:8529, exiting...



I haven't tried building for a while, and just assumed that things
were good to go since I didn't think there had been any changes
lately, but I was wrong.

My build fails with httpd-2.4.9:

ConnectionUtil.obj : error LNK2001: unresolved external symbol
_modperl_pnotes_kill
..\..\..\blib\arch\auto\Apache2\ConnectionUtil\ConnectionUtil.dll : fatal error

Reverting this commit:

http://svn.apache.org/viewvc?view=revision&revision=1638351

fixes that.



The linker error is now fixed by commit r1654746. I will look at the
startup crash later today if nobody else has by then.


The startup crash that I was getting only happened on 5.21.7 or
higher, and is now fixed by commit r1655200.

I don't see the loglevel problem. I'll try 5.14.2 and 2.4.6 to see if
I can reproduce it.


I still can't reproduce this. Everything builds fine, with only the
"expected" set of four test failures (Win32-specific, I think) using
5.14.2 and 2.4.6.

Are you able to investigate this any more Fred?




However, we have a problem looming on the horizon: Startup fails with
5.21.8 due to this change in core perl:
http://perl5.git.perl.org/perl.git/commit/c910fead78 which causes an
access violation in modperl_env_init() when trying to replace the now
*const* PL_vtbls with our own versions. I fear this may be an
unreasonable thing for anyone to be doing in the first place? I've
asked on rt.perl.org:
https://rt.perl.org/Ticket/Display.html?id=123687


We do indeed have a problem here and need to make some changes to fix
things for 5.22 (due in May) -- see Leon's reply at
https://rt.perl.org/Public/Bug/Display.html?id=123687#txn-1328613

This shouldn't hold up our release of 2.0.9, though, which I believe
is good for all supported stable Perls up to 5.18.4.


I've just updated mod_perl to latest trunk in Fedora and all the tests 
are passing here with httpd-2.4.10 and httpd-2.4.12 and perl-5.18.4.


Regards,
Jan Kaluza


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




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

Re: Releasing Apache 2.4 supported Mod-Perl

2015-01-23 Thread Jan Kaluža 

On 01/22/2015 06:54 PM, Steve Hay wrote:

On 22 January 2015 at 16:52, The Aquatic Research Center
 wrote:

Dear appreciated mod-perl developers,



I have a mod-perl site that I want to continue using, but my distro doesn't
distribute the mod-perl package anymore because there is none available that
works with Apache 2.4.



I read the archives and saw that nobody raised any objections against
releasing.



Does somebody know who is the brave Perl-monk that takes precious care of
the mod-perl-pumpkin and is willing to release the Apache 2.4 supported
mod-perl?





Thank you for your interest in mod_perl. I have been trying to
organize a new release for a little while now, and hope that it will
happen soon.


+1, looking forward :).

Jan Kaluza


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




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

Re: release blockers?

2014-12-03 Thread Jan Kaluža 

On 09/12/2014 07:06 PM, Steve Hay wrote:

On 12 September 2014 18:01, Fred Moyer  wrote:

On Wed, Aug 27, 2014 at 2:55 AM, Jan Kaluža  wrote:

since we have mod_perl which compiles and works with httpd-2.4, what are the
current blockers before we do some release with initial httpd-2.4 support?


What branch should I pull for testing? Or has that code been merged into trunk?




Everything's in trunk now.

I think we're good to go. I have a couple of failure on Windows still,
but wouldn't want to hold people up on other OSes for them if it's
looking good elsewhere.



Time for Christmas release? :)

Regards,
Jan Kaluza


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

Re: release blockers?

2014-10-16 Thread Jan Kaluža 

On 10/16/2014 10:02 AM, Steve Hay wrote:

On 16 September 2014 08:08, Jan Kaluža mailto:jkal...@redhat.com>> wrote:

On 09/12/2014 07:05 PM, Steve Hay wrote:

On 12 September 2014 16:15, Niko Tyni mailto:nt...@debian.org>> wrote:

On Fri, Sep 12, 2014 at 05:01:36PM +0200, Jan Kaluža wrote:

On 08/27/2014 11:55 AM, Jan Kaluža wrote:


since we have mod_perl which compiles and works with
httpd-2.4, what are
the current blockers before we do some release with
initial httpd-2.4
support?


Does the silence mean that we have no blockers? :)


Is t/perl/ithreads3.t working for everybody else?


http://mail-archives.apache.__org/mod_mbox/perl-dev/201408.__mbox/%3C20140807141231.__GA24545@estella.local.invalid%__3E

<http://mail-archives.apache.org/mod_mbox/perl-dev/201408.mbox/%3C20140807141231.GA24545@estella.local.invalid%3E>


Works for me last time I tried, but t/perl/ithreads* are not in the
release tarballs anyway, I think (because of persistent trouble with
them historically).


It doesn't actually "work for me", of course: It just doesn't fail for
me since the test requires the worker MPM, so is skipped on Windows!



I've tried it with worker MPM and it fails for me, but I think the
test is somehow broken. The comment in ithreads3.pm
<http://ithreads3.pm> says:

 # now add an extra PerlCleanupHandler. It is run each time the
 # interp is released. So it is run after Trans, MapToStorage and
 # Fixup. In the response phase $counter should be 5. After Response
 # it is run again but that is after.

But when checking the code for PerlCleanupHandler, it seems to be
run once the request request_rec.pool is destroyed, which is in
contradiction with the comment.

It then continues with:

 # This used to eat up all interpreters because
 # modperl_interp_unselect
 # calls modperl_config_request_cleanup that allocates a new interp
 # to handle the cleanup.

This is also not a true in current code. modperl_interp_unselect
does not call modperl_config_request_cleanup if I understand the
current code.

I would say the test is outdated and I have no clue what was its
goal. It clearly tries to count how many times are the handlers
executed, but in its current state, it is not useful, because it
tests the code paths we no longer have.


Now omitted from the distribution as per Niko's suggestion: Revision
1632231.


Great, thanks. Do you know anything else we have to do/fix before 
release? :) I would like to so see some release with 2.4.x support soon :).


Regards,
Jan Kaluza


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

Re: release blockers?

2014-09-16 Thread Jan Kaluža 

On 09/12/2014 07:05 PM, Steve Hay wrote:

On 12 September 2014 16:15, Niko Tyni  wrote:

On Fri, Sep 12, 2014 at 05:01:36PM +0200, Jan Kaluža wrote:

On 08/27/2014 11:55 AM, Jan Kaluža wrote:


since we have mod_perl which compiles and works with httpd-2.4, what are
the current blockers before we do some release with initial httpd-2.4
support?


Does the silence mean that we have no blockers? :)


Is t/perl/ithreads3.t working for everybody else?

  
http://mail-archives.apache.org/mod_mbox/perl-dev/201408.mbox/%3C20140807141231.GA24545@estella.local.invalid%3E



Works for me last time I tried, but t/perl/ithreads* are not in the
release tarballs anyway, I think (because of persistent trouble with
them historically).


I've tried it with worker MPM and it fails for me, but I think the test 
is somehow broken. The comment in ithreads3.pm says:


# now add an extra PerlCleanupHandler. It is run each time the
# interp is released. So it is run after Trans, MapToStorage and
# Fixup. In the response phase $counter should be 5. After Response
# it is run again but that is after.

But when checking the code for PerlCleanupHandler, it seems to be run 
once the request request_rec.pool is destroyed, which is in 
contradiction with the comment.


It then continues with:

# This used to eat up all interpreters because
# modperl_interp_unselect
# calls modperl_config_request_cleanup that allocates a new interp
# to handle the cleanup.

This is also not a true in current code. modperl_interp_unselect does 
not call modperl_config_request_cleanup if I understand the current code.


I would say the test is outdated and I have no clue what was its goal. 
It clearly tries to count how many times are the handlers executed, but 
in its current state, it is not useful, because it tests the code paths 
we no longer have.


Jan Kaluza


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




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

Re: release blockers?

2014-09-12 Thread Jan Kaluža 

On 08/27/2014 11:55 AM, Jan Kaluža wrote:

Hi,

since we have mod_perl which compiles and works with httpd-2.4, what are
the current blockers before we do some release with initial httpd-2.4
support?


Does the silence mean that we have no blockers? :)

Jan Kaluza


Distributions tend to use our trunk anyway, so maybe it's time to think
about some beta release with httpd-2.4 support :).

Jan Kaluza

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




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

Re: mod_perl-2.0.8 make errors with ld: Unrecognized argument: +DD64

2014-09-01 Thread Jan Kaluža 

Hi,

can you please try it with attached patch?

Jan Kaluza

On 08/30/2014 06:49 PM, Braly, Larissa (NE) wrote:

Good Morning,

I accidentally submitted my ticket before my confirmation message came
back for joining this mailing list so please forgive me if you have seen
this once already.

I’m trying to compile mod_perl-2.0.8 with perl 5.20.0.  OS is HPUX 11.31
64 bit.

I’m running configure with the following for Mod_Perl with no issues:

perl Makefile.PL MP_APXS=/opt/hpws22/apache/bin/apxs
MP_APR_CONFIG=/opt/hpws22/apache/bin/apr-1-config

I then run the make and get the following:

ld: Unrecognized argument: +DD64

Fatal error.

*** Error exit code 1

Stop.

*** Error exit code 1

I saw another ticket from way back regarding the same issue with
DBD::Oracle (ticket 30971 -
https://rt.perl.org/Public/Bug/Display.html?id=30971). I have installd
DBD::Oracle and DBI with no issues. With that said, this is the same
exact issue that I’m having with Mod_Perl.  Is there possibly a
workaround or a known patch that I can apply for my Mod_Perl Issue?  I
did not see anything I could modify in Makefile.PL so I tried modifying
the generated Makefile and removing instances of +DD64, but that did not
work.

LDFLAGS =  +DD64 -L/usr/local/lib -L/usr/lib/hpux64was
modified to LDFLAGS =  -L/usr/local/lib -L/usr/lib/hpux64

That didn't work so I also tried to remove it from the cc flags
parameter as well which did not work either.

CCFLAGS =-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE
-Wl,+vnocompatwarnings +DD64 +Z -I/usr/local/include   -DMOD_PERL
-DMP_COMPAT_1X -DHPUX11 -D_REENTRANT -D_HPUX_SOURCE

Changed to

CCFLAGS =-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE
-Wl,+vnocompatwarnings +Z -I/usr/local/include   -DMOD_PERL
-DMP_COMPAT_1X -DHPUX11 -D_REENTRANT -D_HPUX_SOURCE

Information for Perl is as follows:

perl -V

Summary of my perl5 (revision 5 version 20 subversion 0) configuration:

   Platform:

 osname=hpux, osvers=11.31, archname=IA64.ARCHREV_0-thread-multi-LP64

 uname='hp-ux cmos14 b.11.31 u ia64 1940667773 unlimited-user license '

 config_args='-Dprefix=/opt/perl5 -Duselargefiles -Duse64bitall
-Duseithreads -Accflags=+Z -A prepend:libswanted=cl pthread
-Ubincompat5005 -d'

 hint=recommended, useposix=true, d_sigaction=define

 useithreads=define, usemultiplicity=define

 use64bitint=define, use64bitall=define, uselongdouble=undef

 usemymalloc=n, bincompat5005=undef

   Compiler:

 cc='cc', ccflags =' -D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae
-D_HPUX_SOURCE -Wl,+vnocompatwarnings +DD64 +Z -I/usr/local/include
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ',

 optimize='+O2 +Onolimit',

 cppflags='-Aa -D__STDC_EXT__ -D_HPUX_SOURCE
-D_POSIX_C_SOURCE=199506L -D_REENTRANT -Ae -D_HPUX_SOURCE
-Wl,+vnocompatwarnings +DD64 +Z -I/usr/local/include'

 ccversion='B3910B A.06.28', gccversion='', gccosandvers=''

 intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321

 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='/usr/bin/ld', ldflags =' +DD64 -L/usr/local/lib -L/usr/lib/hpux64'

 libpth=/usr/local/lib /usr/lib/hpux64 /lib /usr/lib /usr/ccs/lib

 libs=-lcl -lpthread -lnsl -lnm -ldl -lm -lsec -lc

 perllibs=-lcl -lpthread -lnsl -lnm -ldl -lm -lsec -lc

 libc=/usr/lib/hpux64/libc.so, so=so, useshrplib=false,
libperl=libperl.a

 gnulibc_version=''

   Dynamic Linking:

 dlsrc=dl_hpux.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-B,deferred '

 cccdlflags='+Z', lddlflags='-b +vnocompatwarnings -L/usr/local/lib
-L/usr/lib/hpux64'

Characteristics of this binary (from libperl):

   Compile-time options: HAS_TIMES MULTIPLICITY PERLIO_LAYERS

 PERL_DONT_CREATE_GVSV

 PERL_HASH_FUNC_ONE_AT_A_TIME_HARD

 PERL_IMPLICIT_CONTEXT PERL_MALLOC_WRAP

 PERL_NEW_COPY_ON_WRITE PERL_PRESERVE_IVUV

 USE_64_BIT_ALL USE_64_BIT_INT USE_ITHREADS

 USE_LARGE_FILES USE_LOCALE USE_LOCALE_COLLATE

 USE_LOCALE_CTYPE USE_LOCALE_NUMERIC USE_PERLIO

 USE_PERL_ATOF USE_REENTRANT_API

   Built under hpux

   Compiled at Aug 29 2014 16:17:49

   %ENV:

 PERL5LIB="/usr/cmos/script"

   @INC:

 /usr/cmos/script

 /opt/perl5/lib/site_perl/5.20.0/IA64.ARCHREV_0-thread-multi-LP64

 /opt/perl5/lib/site_perl/5.20.0

 /opt/perl5/lib/5.20.0/IA64.ARCHREV_0-thread-multi-LP64

 /opt/perl5/lib/5.20.0

 .

This is an excerpt of the output from the make command:

   -c modperl_directives.c && mv modperl_directives.o modperl_directives.lo

 cc -I/rdbms2/hpux_webserver/mod_perl-2.0.8/src/modules/perl
-I/rdbms2/hpux_

release blockers?

2014-08-27 Thread Jan Kaluža 

Hi,

since we have mod_perl which compiles and works with httpd-2.4, what are 
the current blockers before we do some release with initial httpd-2.4 
support?


Distributions tend to use our trunk anyway, so maybe it's time to think 
about some beta release with httpd-2.4 support :).


Jan Kaluza

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

Re: t/compat/conn_rec.t failure in trunk with Apache 2.4

2014-08-15 Thread Jan Kaluža 

On 08/14/2014 09:31 AM, Jie Gao wrote:

These now passes "make test" on rhel6.5:

t/api/conn_rec.t  ok
t/api/conn_util.t ... ok

The only failures are the following:

t/perl/ithreads3.t .. 1/6 # Failed test 3 in 
t/perl/ithreads3.t at line 32
# Failed test 4 in t/perl/ithreads3.t at line 33
# Failed test 5 in t/perl/ithreads3.t at line 35
t/perl/ithreads3.t .. Failed 3/6 subtests


Is that with httpd from RHEL-6.5, or is there some special configuration 
you have there? Is it with prefork MPM?


Regards,
Jan Kaluza



Regards,

Jie

* Jan Kaluža  wrote:


Date: Thu, 14 Aug 2014 08:57:22 +0200
From: Jan Kaluža 
To: dev@perl.apache.org
Subject: Re: t/compat/conn_rec.t failure in trunk with Apache 2.4
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
  Thunderbird/24.7.0

On 08/08/2014 08:43 AM, Jan Kaluža wrote:

On 08/07/2014 01:32 PM, Niko Tyni wrote:

Hi,

I'm trying to get the current mod_perl trunk to build on Debian unstable
(with Apache 2.4.10 and Perl 5.18.2), and I'm seeing a failure in
t/compat/conn_rec.t. It's getting an internal server error at test 3,
with this in t/logs/error_log:

  [Thu Aug 07 14:15:39.916269 2014] [perl:error] [pid 19060:tid
140108267251456] [client 127.0.0.1:36626] overriding
Apache2::Connection::remote_addr didn't return a CODE ref at
/home/niko/tmp/libapache2-mod-perl2/blib/lib/Apache2/compat.pm line
252.\n

So it's the remote_addr vs. client_addr thing again.

The test used to work with the httpd24 branch at r1449661, and it
looks like it broke with r1497279, which restored 2.2 compatibility
in lib/Apache2/compat.pm

  http://svn.apache.org/viewvc?view=revision&revision=1497279

If I understand this correctly, Apache2::compat is supposed to provide
mod_perl 1.0 backward compatibility, so we want to offer remote_addr()
there even with Apache 2.4. Does the attached patch make sense? It works
for me on 2.4 and I'd expect it to work with 2.2 too (but I haven't
verified that.)


Hi,

yes it does. I didn't do that because of my poor Perl knowledge, so I
had no idea how to detect httpd-2.4 in that particular part of code. I
will commit the patch next week (right now I'm on conference and I would
not like to commit the patch blindly).


Sorry for a delay and thanks Steve for additional testing. I've
committed it in r1617891.

Jan Kaluza


Rea
Jan Kaluza





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




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




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




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

Re: t/compat/conn_rec.t failure in trunk with Apache 2.4

2014-08-13 Thread Jan Kaluža 

On 08/08/2014 08:43 AM, Jan Kaluža wrote:

On 08/07/2014 01:32 PM, Niko Tyni wrote:

Hi,

I'm trying to get the current mod_perl trunk to build on Debian unstable
(with Apache 2.4.10 and Perl 5.18.2), and I'm seeing a failure in
t/compat/conn_rec.t. It's getting an internal server error at test 3,
with this in t/logs/error_log:

  [Thu Aug 07 14:15:39.916269 2014] [perl:error] [pid 19060:tid
140108267251456] [client 127.0.0.1:36626] overriding
Apache2::Connection::remote_addr didn't return a CODE ref at
/home/niko/tmp/libapache2-mod-perl2/blib/lib/Apache2/compat.pm line
252.\n

So it's the remote_addr vs. client_addr thing again.

The test used to work with the httpd24 branch at r1449661, and it
looks like it broke with r1497279, which restored 2.2 compatibility
in lib/Apache2/compat.pm

  http://svn.apache.org/viewvc?view=revision&revision=1497279

If I understand this correctly, Apache2::compat is supposed to provide
mod_perl 1.0 backward compatibility, so we want to offer remote_addr()
there even with Apache 2.4. Does the attached patch make sense? It works
for me on 2.4 and I'd expect it to work with 2.2 too (but I haven't
verified that.)


Hi,

yes it does. I didn't do that because of my poor Perl knowledge, so I
had no idea how to detect httpd-2.4 in that particular part of code. I
will commit the patch next week (right now I'm on conference and I would
not like to commit the patch blindly).


Sorry for a delay and thanks Steve for additional testing. I've 
committed it in r1617891.


Jan Kaluza


Rea
Jan Kaluza





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




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




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

Re: t/compat/conn_rec.t failure in trunk with Apache 2.4

2014-08-07 Thread Jan Kaluža 

On 08/07/2014 01:32 PM, Niko Tyni wrote:

Hi,

I'm trying to get the current mod_perl trunk to build on Debian unstable
(with Apache 2.4.10 and Perl 5.18.2), and I'm seeing a failure in
t/compat/conn_rec.t. It's getting an internal server error at test 3,
with this in t/logs/error_log:

  [Thu Aug 07 14:15:39.916269 2014] [perl:error] [pid 19060:tid 
140108267251456] [client 127.0.0.1:36626] overriding 
Apache2::Connection::remote_addr didn't return a CODE ref at 
/home/niko/tmp/libapache2-mod-perl2/blib/lib/Apache2/compat.pm line 252.\n

So it's the remote_addr vs. client_addr thing again.

The test used to work with the httpd24 branch at r1449661, and it
looks like it broke with r1497279, which restored 2.2 compatibility
in lib/Apache2/compat.pm

  http://svn.apache.org/viewvc?view=revision&revision=1497279

If I understand this correctly, Apache2::compat is supposed to provide
mod_perl 1.0 backward compatibility, so we want to offer remote_addr()
there even with Apache 2.4. Does the attached patch make sense? It works
for me on 2.4 and I'd expect it to work with 2.2 too (but I haven't
verified that.)


Hi,

yes it does. I didn't do that because of my poor Perl knowledge, so I 
had no idea how to detect httpd-2.4 in that particular part of code. I 
will commit the patch next week (right now I'm on conference and I would 
not like to commit the patch blindly).


Rea
Jan Kaluza





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




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

Re: httpd-2.4 support is now in trunk! :-)

2014-06-23 Thread Jan Kaluža 

Hi,

sorry for late response, I was on vacation :). Thank you really for the 
merge. I'm going to update to latest trunk revision in Fedora Rawhide.


Maybe we could try to release some alpha/beta version with httpd-2.4.x 
support later this year? :)


Regards,
Jan Kaluza

On 06/12/2014 02:36 PM, Steve Hay wrote:

Thanks to the magic of auto-merge I have now merged the httpd24 branch
and the httpd24threading branch that was copied from it (and which
includes everything from the threading branch) back into trunk.

Massive thanks to all those who worked on the three branches
concerned; I've not done much more than have the happy job of pressing
the buttons to merge it all into trunk ;-)

Please can you test trunk with httpd-2.4, and, not forgetting the
obvious need for backwards-compatibility, httpd-2.2 as well.

This has all been too long coming (apologies for holding things up
longer in a bid to get the tests passing on Windows), and it would be
great to finally get a 2.0.9 out soon with this stuff in it.

On Windows, the current state of play is:

httpd-2.4, perl-5.20.0, VC++ 2010:

Fails t\compat\conn_rec.t due to a problem getting this to work with
both 2.2 and 2.4. We should be able to sort this out somehow.

Fails t\protocol\echo_block.t, t\protocol\echo_nonblock.t,
t\protocol\echo_timeout.t and t\protocol\pseudo_http.t due to
Windows-specific problems that I have not yet been able to fix.

httpd-2.2, perl-5.20.0, VC++ 2010:

Fails t\api\access2.t, which wasn't happening on the httpd24threading
branch when I last tried (see
http://marc.info/?l=apache-modperl-dev&m=140009489519031&w=2) so I
need to find out what's gone wrong. (Note that trunk is actually now
identical to httpd24threading, so I don't think the merge has gone
wrong. Maybe it's the newer perl I'm using now???)

I believe that the state of play on Linux is similar, except that it
doesn't have the failures cited as Windows-specific above, and does
fail a couple of other tests with httpd-2.2, but they were apparently
failing anyway before this merge was done (see
http://marc.info/?l=apache-modperl-dev&m=139876807817952&w=2).

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




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

Re: buildbot failure in ASF Buildbot on mod_perl_2_trunk

2014-06-12 Thread Jan Kaluža 

On 06/12/2014 09:51 AM, Steve Hay wrote:

On 12 June 2014 08:47,   wrote:

The Buildbot has detected a failed build on builder mod_perl_2_trunk while 
building ASF Buildbot.
Full details are available at:
  http://ci.apache.org/builders/mod_perl_2_trunk/builds/0

Buildbot URL: http://ci.apache.org/

Buildslave for this Build: ceres_ubuntu

Build Reason: scheduler
Build Source Stamp: [branch perl/modperl/trunk] 1602082
Blamelist: stevehay

BUILD FAILED: failed compile_2



I've begun the process of merging httpd24threading back into trunk, so
please ignore buildbot failures until the process is complete. I'll
email this list when I believe I've merged it all across...


Great news :). I hope it will work correctly after the merge :).

Jan Kaluza


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




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

Re: Current httpd24threading branch problems?

2014-06-10 Thread Jan Kaluža 

On 05/14/2014 07:01 PM, Steve Hay wrote:

On 14 May 2014 13:10, Jan Kaluža  wrote:

On 05/14/2014 02:07 PM, Steve Hay wrote:


On 14 May 2014 09:27, Jan Kaluža  wrote:


On 05/13/2014 07:29 PM, Steve Hay wrote:



On 29 April 2014 11:40, Jan Kaluža  wrote:



On 04/17/2014 09:15 AM, Steve Hay wrote:




On 17 April 2014 07:46, Jan Kaluža  wrote:




Hi Fred,

could you please sum up what's the current state of httpd24threading
branch?
I think you're the only one currently who knows what has to be done
before
we can release it somehow.

I've tried to read the mailing list to refresh my memory, but I'm not
sure
what has been fixed/done already during these 3 months.



I think it's mostly been me and you working on it, actually!

I've said before that I need to fix some Windows test failures and
then (assuming *nix doesn't have any outstanding of its own) I'll be
happy to merge this branch into trunk and we can get a release going.

My current list of failures is:

Test Summary Report
---
t\compat\conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
[new failure for 2.4.x]
  Parse errors: Bad plan.  You planned 4 tests but ran 2.
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  3, 6, 9
t\modperl\merge2.t(Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  3, 6, 9
t\modperl\merge3.t(Wstat: 0 Tests: 10 Failed: 3)
  Failed tests:  3, 6, 9
t\modules\cgi.t   (Wstat: 0 Tests: 5 Failed: 5)
  Failed tests:  1-5
t\modules\cgi2.t  (Wstat: 0 Tests: 5 Failed: 5)
  Failed tests:  1-5
t\modules\cgipost.t   (Wstat: 0 Tests: 6 Failed: 5)
  Failed tests:  2-6
t\modules\cgipost2.t  (Wstat: 0 Tests: 6 Failed: 5)
  Failed tests:  2-6
t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
  Failed tests:  1-2
t\modules\cgiupload2.t(Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
  Failed tests:  1-2
t\protocol\echo_block.t   (Wstat: 0 Tests: 3 Failed: 2)
[new failure for 2.4.x]
  Failed tests:  2-3
t\protocol\echo_nonblock.t(Wstat: 0 Tests: 3 Failed: 1)
[new failure for 2.4.x]
  Failed test:  2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
[new failure for 2.4.x]
  Failed tests:  2-5
t\protocol\pseudo_http.t  (Wstat: 0 Tests: 13 Failed: 9)
 [new failure for 2.4.x]
  Failed tests:  3-8, 11-13
Files=252, Tests=2938, 848 wallclock secs ( 2.26 usr +  0.36 sys =
2.62
CPU)

The ones marked 'new failure for 2.4.x' fail with 2.4.x but not with
2.2.x so they are particularly worrying for 2.4.x support, but note
also that *none* of the above tests fail with 2.2.x when using trunk
(or mod_perl-2.08), which is also quite worrying.

What is the current state of play on *nix? Which tests, if any, fail
using:





Hi,

I've had finally some time to do the tests. It's run on Fedora 20,
httpd-2.4.9 and httpd-2.2.23. See below.


(1) httpd24threading + httpd-2.4.x





t/compat/conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)

 Parse errors: Bad plan.  You planned 4 tests but ran 2.

^ This is expected problem for now. It's caused by renamed "remote_ip"
and
"remote_addr" in httpd-2.4. I was not able to put proper version check
in
this test (probably my lack of Perl knowledge).

t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
 Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
 Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
 Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
 Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
 Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
 Failed test:  2

^ All these are caused by r1491887 -
/perl/modperl/trunk/t/modperl/local_env.t. Should we revert this
commit?


(2) httpd24threading + httpd-2.2.x





t/api/server_const.t  (Wstat: 0 Tests: 6 Failed: 2)
 Failed tests:  5-6
t/modperl/setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
 Failed tests:  17-23
t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
 Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
 Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
 Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
 Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
 Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Fa

Re: Current httpd24threading branch problems?

2014-05-15 Thread Jan Kaluža 

On 05/14/2014 02:07 PM, Steve Hay wrote:

On 14 May 2014 09:27, Jan Kaluža  wrote:

On 05/13/2014 07:29 PM, Steve Hay wrote:


On 29 April 2014 11:40, Jan Kaluža  wrote:


On 04/17/2014 09:15 AM, Steve Hay wrote:



On 17 April 2014 07:46, Jan Kaluža  wrote:



Hi Fred,

could you please sum up what's the current state of httpd24threading
branch?
I think you're the only one currently who knows what has to be done
before
we can release it somehow.

I've tried to read the mailing list to refresh my memory, but I'm not
sure
what has been fixed/done already during these 3 months.



I think it's mostly been me and you working on it, actually!

I've said before that I need to fix some Windows test failures and
then (assuming *nix doesn't have any outstanding of its own) I'll be
happy to merge this branch into trunk and we can get a release going.

My current list of failures is:

Test Summary Report
---
t\compat\conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
[new failure for 2.4.x]
 Parse errors: Bad plan.  You planned 4 tests but ran 2.
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
 Failed test:  6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
 Failed tests:  3, 6, 9
t\modperl\merge2.t(Wstat: 0 Tests: 10 Failed: 3)
 Failed tests:  3, 6, 9
t\modperl\merge3.t(Wstat: 0 Tests: 10 Failed: 3)
 Failed tests:  3, 6, 9
t\modules\cgi.t   (Wstat: 0 Tests: 5 Failed: 5)
 Failed tests:  1-5
t\modules\cgi2.t  (Wstat: 0 Tests: 5 Failed: 5)
 Failed tests:  1-5
t\modules\cgipost.t   (Wstat: 0 Tests: 6 Failed: 5)
 Failed tests:  2-6
t\modules\cgipost2.t  (Wstat: 0 Tests: 6 Failed: 5)
 Failed tests:  2-6
t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
 Failed tests:  1-2
t\modules\cgiupload2.t(Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
 Failed tests:  1-2
t\protocol\echo_block.t   (Wstat: 0 Tests: 3 Failed: 2)
[new failure for 2.4.x]
 Failed tests:  2-3
t\protocol\echo_nonblock.t(Wstat: 0 Tests: 3 Failed: 1)
[new failure for 2.4.x]
 Failed test:  2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
[new failure for 2.4.x]
 Failed tests:  2-5
t\protocol\pseudo_http.t  (Wstat: 0 Tests: 13 Failed: 9)
[new failure for 2.4.x]
 Failed tests:  3-8, 11-13
Files=252, Tests=2938, 848 wallclock secs ( 2.26 usr +  0.36 sys =  2.62
CPU)

The ones marked 'new failure for 2.4.x' fail with 2.4.x but not with
2.2.x so they are particularly worrying for 2.4.x support, but note
also that *none* of the above tests fail with 2.2.x when using trunk
(or mod_perl-2.08), which is also quite worrying.

What is the current state of play on *nix? Which tests, if any, fail
using:




Hi,

I've had finally some time to do the tests. It's run on Fedora 20,
httpd-2.4.9 and httpd-2.2.23. See below.


(1) httpd24threading + httpd-2.4.x




t/compat/conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)

Parse errors: Bad plan.  You planned 4 tests but ran 2.

^ This is expected problem for now. It's caused by renamed "remote_ip"
and
"remote_addr" in httpd-2.4. I was not able to put proper version check in
this test (probably my lack of Perl knowledge).

t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
Failed test:  2

^ All these are caused by r1491887 -
/perl/modperl/trunk/t/modperl/local_env.t. Should we revert this commit?


(2) httpd24threading + httpd-2.2.x




t/api/server_const.t  (Wstat: 0 Tests: 6 Failed: 2)
Failed tests:  5-6
t/modperl/setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
Failed tests:  17-23
t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
Failed test:  2

CGI tests fails for the same reason as in the previous case. Other tests
fail *also* for tru

Re: Current httpd24threading branch problems?

2014-05-14 Thread Jan Kaluža 

On 05/13/2014 07:29 PM, Steve Hay wrote:

On 29 April 2014 11:40, Jan Kaluža  wrote:

On 04/17/2014 09:15 AM, Steve Hay wrote:


On 17 April 2014 07:46, Jan Kaluža  wrote:


Hi Fred,

could you please sum up what's the current state of httpd24threading
branch?
I think you're the only one currently who knows what has to be done
before
we can release it somehow.

I've tried to read the mailing list to refresh my memory, but I'm not
sure
what has been fixed/done already during these 3 months.



I think it's mostly been me and you working on it, actually!

I've said before that I need to fix some Windows test failures and
then (assuming *nix doesn't have any outstanding of its own) I'll be
happy to merge this branch into trunk and we can get a release going.

My current list of failures is:

Test Summary Report
---
t\compat\conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
[new failure for 2.4.x]
Parse errors: Bad plan.  You planned 4 tests but ran 2.
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
Failed test:  6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
Failed tests:  3, 6, 9
t\modperl\merge2.t(Wstat: 0 Tests: 10 Failed: 3)
Failed tests:  3, 6, 9
t\modperl\merge3.t(Wstat: 0 Tests: 10 Failed: 3)
Failed tests:  3, 6, 9
t\modules\cgi.t   (Wstat: 0 Tests: 5 Failed: 5)
Failed tests:  1-5
t\modules\cgi2.t  (Wstat: 0 Tests: 5 Failed: 5)
Failed tests:  1-5
t\modules\cgipost.t   (Wstat: 0 Tests: 6 Failed: 5)
Failed tests:  2-6
t\modules\cgipost2.t  (Wstat: 0 Tests: 6 Failed: 5)
Failed tests:  2-6
t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
Failed tests:  1-2
t\modules\cgiupload2.t(Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
Failed tests:  1-2
t\protocol\echo_block.t   (Wstat: 0 Tests: 3 Failed: 2)
[new failure for 2.4.x]
Failed tests:  2-3
t\protocol\echo_nonblock.t(Wstat: 0 Tests: 3 Failed: 1)
[new failure for 2.4.x]
Failed test:  2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
[new failure for 2.4.x]
Failed tests:  2-5
t\protocol\pseudo_http.t  (Wstat: 0 Tests: 13 Failed: 9)
   [new failure for 2.4.x]
Failed tests:  3-8, 11-13
Files=252, Tests=2938, 848 wallclock secs ( 2.26 usr +  0.36 sys =  2.62
CPU)

The ones marked 'new failure for 2.4.x' fail with 2.4.x but not with
2.2.x so they are particularly worrying for 2.4.x support, but note
also that *none* of the above tests fail with 2.2.x when using trunk
(or mod_perl-2.08), which is also quite worrying.

What is the current state of play on *nix? Which tests, if any, fail
using:



Hi,

I've had finally some time to do the tests. It's run on Fedora 20,
httpd-2.4.9 and httpd-2.2.23. See below.


(1) httpd24threading + httpd-2.4.x



t/compat/conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)

   Parse errors: Bad plan.  You planned 4 tests but ran 2.

^ This is expected problem for now. It's caused by renamed "remote_ip" and
"remote_addr" in httpd-2.4. I was not able to put proper version check in
this test (probably my lack of Perl knowledge).

t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
   Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
   Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
   Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
   Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
   Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
   Failed test:  2

^ All these are caused by r1491887 -
/perl/modperl/trunk/t/modperl/local_env.t. Should we revert this commit?


(2) httpd24threading + httpd-2.2.x



t/api/server_const.t  (Wstat: 0 Tests: 6 Failed: 2)
   Failed tests:  5-6
t/modperl/setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
   Failed tests:  17-23
t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
   Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
   Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
   Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
   Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
   Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
   Failed test:  2

CGI tests fails for the same reason as in the previous case. Other tests
fail *also* for trunk + httpd-2.2.x (see below).



(3) trunk (or mod_perl-2.08) + httpd 2.2.x



trunk + httpd-2.2.23:

t/api/server_c

Re: httpd24threading branch build failure

2014-05-13 Thread Jan Kaluža 

On 05/13/2014 09:30 AM, Alexander Pyhalov wrote:

On 05/12/2014 17:06, Jan Kaluža wrote:


thanks for testing. I think I've just fixed this problem at
<http://svn.apache.org/r1593957>. Please try it again with this latest
commit, maybe there are more places like that.


Hello.
Thanks for fixing this, the latest version works for me.



Great,
thanks for letting us know :).

Jan Kaluza


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

Re: httpd24threading branch build failure

2014-05-12 Thread Jan Kaluža 

On 05/12/2014 10:41 AM, Alexander Pyhalov wrote:

Hello.
I've tried to build httpd24threading branch of mod_perl on OpenIndiana
with the following config:

$ /usr/perl5/5.16/bin/perl Makefile.PL INSTALLDIRS=perl
INSTALLSITELIB=/usr/apache2/2.4/lib/perl
INSTALLARCHLIB=/usr/apache2/2.4/lib/perl
INSTALLSITEARCH=/usr/apache2/2.4/lib/perl
INSTALLPRIVLIB=/usr/apache2/2.4/lib/perl
SITEARCHEXP=/usr/apache2/2.4/lib/perl
SITELIBEXP=/usr/apache2/2.4/lib/perl
INSTALLMAN1DIR=/usr/apache2/2.4/man/man1
INSTALLMAN3DIR=/usr/apache2/2.4/man/man3
INSTALLSCRIPT=/usr/apache2/2.4/bin MP_NO_THREADS=1
MP_APXS=/usr/apache2/2.4/bin/apxs MP_APR_CONFIG=/usr/apr/bin/apr-1-config
$ /usr/gnu/bin/make

Note MP_NO_THREADS=1 option.

The build fails with


Hi,

thanks for testing. I think I've just fixed this problem at 
. Please try it again with this latest 
commit, maybe there are more places like that.


Regards,
Jan Kaluza



/usr/gcc/4.7/bin/gcc -m32
-I/export/home/alp/srcs/oi-userland/components/apache2-modules/mod_perl-24/build/i86/src/modules/perl
-I/export/home/alp/srcs/oi-userland/components/apache2-modules/mod_perl-24/build/i86/xs
-I/usr/apr/include -I/usr/apr-util/include -I/usr/include/openldap
-I/usr/apache2/2.4/include -DPTR_IS_LONG -fno-strict-aliasing -pipe
-fstack-protector -DPERL_USE_SAFE_PUTENV
-I/usr/perl5/5.16/lib/i86pc-solaris-64int/CORE -DMOD_PERL -DMP_COMPAT_1X
-DSOLARIS2=11 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O -fPIC -DPIC \
-c modperl_util.c && mv modperl_util.o modperl_util.lo
modperl_util.c: In function ‘perl_parse_require_line’:
modperl_util.c:1013:14: error: ‘interp’ undeclared (first use in this
function)
modperl_util.c:1013:14: note: each undeclared identifier is reported
only once for each function it appears in
make[2]: *** [modperl_util.lo] Error 1
make[2]: Leaving directory
`/export/home/alp/srcs/oi-userland/components/apache2-modules/mod_perl-24/build/i86/src/modules/perl'

make[1]: *** [modperl_lib] Error 2



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

Re: Current httpd24threading branch problems?

2014-04-29 Thread Jan Kaluža 

On 04/17/2014 09:15 AM, Steve Hay wrote:

On 17 April 2014 07:46, Jan Kaluža  wrote:

Hi Fred,

could you please sum up what's the current state of httpd24threading branch?
I think you're the only one currently who knows what has to be done before
we can release it somehow.

I've tried to read the mailing list to refresh my memory, but I'm not sure
what has been fixed/done already during these 3 months.



I think it's mostly been me and you working on it, actually!

I've said before that I need to fix some Windows test failures and
then (assuming *nix doesn't have any outstanding of its own) I'll be
happy to merge this branch into trunk and we can get a release going.

My current list of failures is:

Test Summary Report
---
t\compat\conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
[new failure for 2.4.x]
   Parse errors: Bad plan.  You planned 4 tests but ran 2.
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
   Failed test:  6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
   Failed tests:  3, 6, 9
t\modperl\merge2.t(Wstat: 0 Tests: 10 Failed: 3)
   Failed tests:  3, 6, 9
t\modperl\merge3.t(Wstat: 0 Tests: 10 Failed: 3)
   Failed tests:  3, 6, 9
t\modules\cgi.t   (Wstat: 0 Tests: 5 Failed: 5)
   Failed tests:  1-5
t\modules\cgi2.t  (Wstat: 0 Tests: 5 Failed: 5)
   Failed tests:  1-5
t\modules\cgipost.t   (Wstat: 0 Tests: 6 Failed: 5)
   Failed tests:  2-6
t\modules\cgipost2.t  (Wstat: 0 Tests: 6 Failed: 5)
   Failed tests:  2-6
t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
   Failed tests:  1-2
t\modules\cgiupload2.t(Wstat: 0 Tests: 2 Failed: 2)
[with LWP only]
   Failed tests:  1-2
t\protocol\echo_block.t   (Wstat: 0 Tests: 3 Failed: 2)
[new failure for 2.4.x]
   Failed tests:  2-3
t\protocol\echo_nonblock.t(Wstat: 0 Tests: 3 Failed: 1)
[new failure for 2.4.x]
   Failed test:  2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
[new failure for 2.4.x]
   Failed tests:  2-5
t\protocol\pseudo_http.t  (Wstat: 0 Tests: 13 Failed: 9)
  [new failure for 2.4.x]
   Failed tests:  3-8, 11-13
Files=252, Tests=2938, 848 wallclock secs ( 2.26 usr +  0.36 sys =  2.62 CPU)

The ones marked 'new failure for 2.4.x' fail with 2.4.x but not with
2.2.x so they are particularly worrying for 2.4.x support, but note
also that *none* of the above tests fail with 2.2.x when using trunk
(or mod_perl-2.08), which is also quite worrying.

What is the current state of play on *nix? Which tests, if any, fail using:


Hi,

I've had finally some time to do the tests. It's run on Fedora 20, 
httpd-2.4.9 and httpd-2.2.23. See below.



(1) httpd24threading + httpd-2.4.x


t/compat/conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
  Parse errors: Bad plan.  You planned 4 tests but ran 2.

^ This is expected problem for now. It's caused by renamed "remote_ip" 
and "remote_addr" in httpd-2.4. I was not able to put proper version 
check in this test (probably my lack of Perl knowledge).


t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
  Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
  Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  2

^ All these are caused by r1491887 - 
/perl/modperl/trunk/t/modperl/local_env.t. Should we revert this commit?



(2) httpd24threading + httpd-2.2.x


t/api/server_const.t  (Wstat: 0 Tests: 6 Failed: 2)
  Failed tests:  5-6
t/modperl/setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
  Failed tests:  17-23
t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
  Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
  Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  2

CGI tests fails for the same reason as in the previous case. Other tests 
fail *also* for trunk + httpd-2.2.x (see below).



(3) trunk (or mod_perl-2.08) + httpd 2.2.x


trunk + httpd-2.2.23:

t/api/server_const.t  (Wstat: 0 Tests: 6 Failed: 2)
  Failed tests:  5-6
t/modperl/setupenv2.t

Re: 2.4 threading branch and apxs missing MPM_NAME

2014-04-28 Thread Jan Kaluža 

On 04/28/2014 03:08 PM, Torsten Förtsch wrote:

On 28/04/14 15:03, Jan Kaluža wrote:

I think we can remove that option


Please do it so.


Done in r1590627. Although r1151822 seems to do similar thing, I think 
my way provides cleaner error message and has working MP_NO_THREADS=1 
option.



Torsten



Jan Kaluza


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

Re: 2.4 threading branch and apxs missing MPM_NAME

2014-04-28 Thread Jan Kaluža 

On 04/28/2014 03:03 PM, Jan Kaluža wrote:

On 04/28/2014 02:57 PM, Torsten Förtsch wrote:

Hi Jan,

On 28/04/14 13:22, Jan Kaluža wrote:

On 04/23/2014 03:04 PM, Torsten Förtsch wrote:

On 23/04/14 13:21, Jan Kaluža wrote:

Thanks for that summary Torsten. As I understand it right now, we
should
build mod_perl with httpd-2.4 with "-Duseithreads
-Dusemultiplicity" and
allow building with other combination if user explicitly wants it (set
some command line parameter during build), right?


We should by default require a Perl built with "-Duseithreads
-Dusemultiplicity". If the user explicitly wants it, we should also
accept a Perl built with "-Uuseithreads -Uusemultiplicity".

All other combinations should be refused.


Can you please check attached patch? If I understand you correctly, it
should do what you propose.


Can you please check what the difference between NONTHREADED_OK and
NO_THREADS is. They seem to serve the same purpose.


I've checked that before sending the patch and it looks like this option
is not used by anything:


Although I'm not sure right now...

http://svn.apache.org/viewvc?view=revision&revision=r1151822

Btw, you are the author of that :-P.


$ grep "NONTHREADED_OK" -R .
./lib/ModPerl/BuildOptions.pm:NONTHREADED_OK 0Using a non-threaded
perl is okay with httpd >=2.3
./blib/lib/ModPerl/BuildOptions.pm:NONTHREADED_OK 0Using a
non-threaded perl is okay with httpd >=2.3

I think we can remove that option, or if you like this name better, I
can use it in my patch.


Torsten



Jan Kaluza


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



Jan Kaluza


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

Re: 2.4 threading branch and apxs missing MPM_NAME

2014-04-28 Thread Jan Kaluža 

On 04/28/2014 02:57 PM, Torsten Förtsch wrote:

Hi Jan,

On 28/04/14 13:22, Jan Kaluža wrote:

On 04/23/2014 03:04 PM, Torsten Förtsch wrote:

On 23/04/14 13:21, Jan Kaluža wrote:

Thanks for that summary Torsten. As I understand it right now, we should
build mod_perl with httpd-2.4 with "-Duseithreads -Dusemultiplicity" and
allow building with other combination if user explicitly wants it (set
some command line parameter during build), right?


We should by default require a Perl built with "-Duseithreads
-Dusemultiplicity". If the user explicitly wants it, we should also
accept a Perl built with "-Uuseithreads -Uusemultiplicity".

All other combinations should be refused.


Can you please check attached patch? If I understand you correctly, it
should do what you propose.


Can you please check what the difference between NONTHREADED_OK and
NO_THREADS is. They seem to serve the same purpose.


I've checked that before sending the patch and it looks like this option 
is not used by anything:


$ grep "NONTHREADED_OK" -R .
./lib/ModPerl/BuildOptions.pm:NONTHREADED_OK 0Using a non-threaded 
perl is okay with httpd >=2.3
./blib/lib/ModPerl/BuildOptions.pm:NONTHREADED_OK 0Using a 
non-threaded perl is okay with httpd >=2.3


I think we can remove that option, or if you like this name better, I 
can use it in my patch.



Torsten



Jan Kaluza


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

Re: 2.4 threading branch and apxs missing MPM_NAME

2014-04-28 Thread Jan Kaluža 

On 04/23/2014 03:04 PM, Torsten Förtsch wrote:

On 23/04/14 13:21, Jan Kaluža wrote:

Thanks for that summary Torsten. As I understand it right now, we should
build mod_perl with httpd-2.4 with "-Duseithreads -Dusemultiplicity" and
allow building with other combination if user explicitly wants it (set
some command line parameter during build), right?


We should by default require a Perl built with "-Duseithreads
-Dusemultiplicity". If the user explicitly wants it, we should also
accept a Perl built with "-Uuseithreads -Uusemultiplicity".

All other combinations should be refused.


Can you please check attached patch? If I understand you correctly, it 
should do what you propose.


Jan Kaluza


Torsten

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



Index: Makefile.PL
===
--- Makefile.PL	(revision 1589126)
+++ Makefile.PL	(working copy)
@@ -509,10 +509,28 @@
 $perl_version =~ s/5.00(\d)(?:00(\d))?/"5.$1." . ($2||0)/e;
 my $perl_threads = Apache2::Build::PERL_HAS_ITHREADS ? "w/" : "w/o";
 my $perl_string = "Using Perl $perl_version $perl_threads ithreads";
-my $mpm = $build->mpm_name();
+my $httpd_version = $build->httpd_version;
+my $mpm = "";
+my $build_threaded = 0;
 
+# For httpd-2.4, we can't use mpm_is_threaded(), because MPMs are loadable
+# modules. We therefore treat httpd as a whole project as threaded. It is
+# still possible to disable threading by using MP_NO_THREADS=1
+if ($httpd_version lt MIN_HTTPD_24_VERSION) {
+$build_threaded = $build->mpm_is_threaded();
+$mpm = $build->mpm_name();
+}
+else {
+if ($build->{MP_NO_THREADS}) {
+$build_threaded = 0;
+}
+else {
+$build_threaded = 1;
+}
+}
+
 # certain mpms require perl 5.8.0+ w/ithreads
-if ($build->mpm_is_threaded()) {
+if ($build_threaded) {
 my @fail;
 push @fail, "Perl 5.8 or higher"
 unless $] >= 5.008;
@@ -519,9 +537,16 @@
 push @fail, "Perl built with ithreads (build perl with -Duseithreads)"
 unless Apache2::Build::PERL_HAS_ITHREADS();
 if (@fail) {
-error "$perl_string and '$mpm' mpm httpd.",
-"Failed requirements:",
-join "", map {"  - $_\n"} @fail;
+if ($httpd_version lt MIN_HTTPD_24_VERSION) {
+error "$perl_string and '$mpm' mpm httpd.",
+"Failed requirements:",
+join "", map {"  - $_\n"} @fail;
+}
+else {
+error "$perl_string and httpd-2.4.",
+"Failed requirements:",
+join "", map {"  - $_\n"} @fail;
+}
 exit 1;
 }
 }
@@ -531,8 +556,14 @@
 if ($build->should_build_apache && !Apache2::Build::PERL_HAS_ITHREADS) {
 # before 5.8.2, perl_shutdown is incomplete
 if ($] < 5.008_002) {
-error "static $mpm mpm requires a threaded ".
-  "perl 5.6.1-5.8.1 or any perl 5.8.2+";
+if ($httpd_version lt MIN_HTTPD_24_VERSION) {
+error "static $mpm mpm requires a threaded ".
+"perl 5.6.1-5.8.1 or any perl 5.8.2+";
+}
+else {
+error "httpd-2.4 requires a threaded ".
+"perl 5.6.1-5.8.1 or any perl 5.8.2+";
+}
 exit 1;
 }
 }
@@ -553,7 +584,7 @@
 if ($Config{usemultiplicity} xor $Config{useithreads}) {
 error "mod_perl does not currently support multiplicity without ".
 	  "ithreads.";
-if ($build->mpm_is_threaded()) {
+if ($build_threaded) {
 	error "Please recompile Perl with -Duseithreads and ".
 	  "-Dusemultiplicity";
 } else {
Index: lib/ModPerl/BuildOptions.pm
===
--- lib/ModPerl/BuildOptions.pm	(revision 1589126)
+++ lib/ModPerl/BuildOptions.pm	(working copy)
@@ -266,3 +266,4 @@
 COMPAT_1X  0Compile-time mod_perl 1.0 backcompat (default is  on)
 APR_LIB0Lib used to build APR::* on Win32 (default is aprext)
 NONTHREADED_OK 0Using a non-threaded perl is okay with httpd >=2.3
+NO_THREADS 0Build mod_perl without thread support with httpd >= 2.4


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

Re: 2.4 threading branch and apxs missing MPM_NAME

2014-04-23 Thread Jan Kaluža 

On 04/18/2014 12:20 PM, Torsten Förtsch wrote:

On 18/04/14 11:50, Jan Kaluza wrote:

Hm, do you know why mod_perl needs to know that during compilation? If
it's really used for something, we will have to remove those
MPM-specific #ifdefs and use normal conditionals instead for httpd-2.4.


Perl can be built in 3 different ways:

1) with global data structures. That way it supports only one
interpreter per process and only one thread per process. But the
resulting Perl is the fastest of the 3.

   -Uuseithreads -Uusemultiplicity

2) with support for multiple interpreters but leaving out thread
synchronization. This is good for environments where conflicting data
access can be eliminated by other means. Postgres' perl integration is
an example. You can declare 2 backend languages, plperl and plperlu.
They need 2 different interpreters. But only one of them can be active
at a time.

   -Uuseithreads -Dusemultiplicity

3) support thread concurrency.

   -Duseithreads -Dusemultiplicity

Historically, modperl supports either 1) or 3). I measured the
performance difference between them years ago for perl 5.12. I got
15-20% which is quite a lot.

I believe the majority of modperl-backed web servers uses prefork. The
best Perl in this context is 1). Up to httpd 2.2 modperl could check if
the user tried to use such a Perl with a threaded MPM. It refused to
compile in that case. For httpd 2.4, this check does not make sense
anymore. Though, I think it would be good to allow the user to build
modperl with a Perl built as per 1). I think this should be allowed only
upon request such as a command line parameter. In all other cases
modperl should refuse to compile with all Perls except for 3).


Thanks for that summary Torsten. As I understand it right now, we should 
build mod_perl with httpd-2.4 with "-Duseithreads -Dusemultiplicity" and 
allow building with other combination if user explicitly wants it (set 
some command line parameter during build), right?


If others agree with that, I will do that in httpd24threading branch.


Just my 2¢,
Torsten



Regards,
Jan Kaluza


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

Current httpd24threading branch problems?

2014-04-16 Thread Jan Kaluža 

Hi Fred,

could you please sum up what's the current state of httpd24threading 
branch? I think you're the only one currently who knows what has to be 
done before we can release it somehow.


I've tried to read the mailing list to refresh my memory, but I'm not 
sure what has been fixed/done already during these 3 months.


Thanks,
Jan Kaluza

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

Re: Struggling with failing echo_* tests on Windows

2014-02-11 Thread Jan Kaluža 

On 02/10/2014 10:19 AM, Steve Hay wrote:

Perl 5.19.5, httpd 2.4.6, mod_perl SVN:

echo_block.t fails tests 2 and 3, receiving nothing, and writing
"APR::Socket::recv: (730060) A connection attempt failed because the
connected party did not properly respond after a period of time, or
established connection failed because connected host has failed to
respond." in the error_log.

echo_nonblock.t fails test 2 with an ECONNRESET after timing out on
the first attempt.

echo_timeout.t fails tests 2, 3, 4 and 5, receiving "good", "bye",
"cruel" and "world" (when it expected to receive nothing) and writing
the same 730060 error in the error_log.

These all work with httpd 2.2.25 (and same perl/mod_perl) but I'm at a
loss to see what's gone wrong with 2.4.6. Any help / suggestions would
be greatly appreciated.


I have no idea here :( It works correctly for me here on Linux (Fedora).

Jan Kaluza


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




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

Re: Apache2::compat in httpd24threading

2014-02-11 Thread Jan Kaluža 

On 02/06/2014 07:13 PM, Steve Hay wrote:

Looking at a(nother) Windows test failure with httpd-2.4.6
(t/compat/conn_rec.t fails tests 3 and 4), I notice that
Apache2::compat was changed to use client_ip/client_addr instead of
remote_ip/remote_addr in r1448202, but then changed back (for the sake
of httpd-2.2.x) in r1497279.

Is this test now passing on Linux? I can't understand why it would
only fail on Windows.



It is not passing. I have no idea how to change Apache2::compat to 
support both. I was able to support only httpd24 or httpd22, not both. 
If you know how to do that, feel free. Otherwise I think it's better to 
declare Apache2::compat to be httpd22 only.


Jan Kaluza


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

Re: mod_perl head build with httpd 2.4.6 on Linux results

2014-01-30 Thread Jan Kaluža 

On 01/30/2014 10:45 AM, Steve Hay wrote:

Surely the old code is saying that refcount != 0 means the interpreter is still 
in use?:

-if (interp->refcnt != 0) {
+if (interp->refcnt > 1) {
  --interp->refcnt;
  MP_TRACE_i(MP_FUNC, "interp=0x%lx, refcnt=%d -- interp still in use",
 (unsigned long)interp, interp->refcnt);

In both versions, refcount == 0 means the interpreter is not used any more.
What you've changed is the refcount == 1 case: the old code would say an 
interpreter is still in use; the new code says not.

That doesn't sound right. It makes no difference to the tests on Windows, 
though.


Does refcnt == 1 mean that there is exactly one place where the 
interpreter is used? If it does and you call unselect for last time with 
refcnt == 1, the refcnt is decremented to 0, but the interpreter is 
consider as in-use.


Without that patch, it ends up in "deadlock" caused by all interpreters 
marked as in-use. Maybe there is situation where recnt is increased and 
not decreased or there's race condition in refcnt manipulation from more 
threads?


[pid=7575, tid=7f58f57fa700, perl=0] modperl_hook_post_read_request: GET 
0.0.0.0:8529/TestApache__scanhdrs
[Thu Jan 30 11:09:05.184662 2014] [authz_core:debug] [pid 7575:tid 
140020052633344] mod_authz_core.c(828): [client 127.0.0.1:49365] 
AH01628: authorization result: granted (no directives)
[pid=7575, tid=7f58f57fa700, perl=0] modperl_response_handler_cgi: 
selecting interp: r=7f58cc002970, c=7f58f8023820, s=7f591aa41368
[pid=7575, tid=7f58f57fa700, perl=0] modperl_interp_select: fetching 
interp for localhost:8529
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: about to lock 
tipool in thread 0x7f58f57fa700
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: acquired tipool 
lock
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: waiting for 
available tipool item in thread 0x7f58f57fa700
[pid=7575, tid=7f58f57fa700, perl=0] modperl_tipool_pop: (2 items in 
use, 2 alive)
[pid=7575, tid=7f58f5ffb700, perl=7f58c8002910] modperl_interp_unselect: 
unselect(interp=7f58c80028d0): refcnt=1
[pid=7575, tid=7f58f5ffb700, perl=7f58c8002910] modperl_interp_unselect: 
interp=0x7f58c80028d0, refcnt=0 -- interp still in use


Jan Kaluza




-Original Message-
From: Jan Kaluža [mailto:jkal...@redhat.com]
Sent: 30 January 2014 09:04
To: dev@perl.apache.org
Subject: Re: mod_perl head build with httpd 2.4.6 on Linux results

Hi again,

I've been able to fix the problem with freezing tests with event MPM
using attached patch. The problem is that currently I'm somehow
confused by the patched code.

Does somebody have an idea why the previous code thought that refcount
== 0 means that perl interpreter is still in use? I would say that
refcount == 0 would mean that perl interpreter is *not* used anymore.

The attached patch changes exactly this mentioned refcount behaviour
and the tests are passing with all three MPMs in Linux.

Can you please verify the fix?

Regards,
Jan Kaluza

On 01/23/2014 01:18 PM, Jan Kaluža wrote:

On 11/15/2013 04:01 PM, Jeff Trawick wrote:

Is it fair to say that mod_perl shouldn't be used with the event

MPM?


With the httpd24threading branch on Linux (older, RHEL 5-ish stuff)
and httpd 2.4.6 with event MPM, I'm getting hangs in some testcases
(e.g., echo_bbs2, echo_nonblock, in_str_sandwich, etc., but not
consistent) and even a crash:


I'm able to reproduce handing echo_nonblock with event mpm even with
my
httpd24 branch (so without threading fixes). I will try to fix this
one or at least debug it more.


#2  
#3  0x2ad0c2a3 in ?? () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-

multi/auto/DBI

/DBI.so

#4  0x2ad0ee8e in XS_DBI_dispatch () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-

multi/auto/DBI

/DBI.so

#5  0x003060290a96 in Perl_pp_entersub () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#6  0x0030602338a7 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#7  0x0030602376f0 in Perl_call_sv () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#8  0x003060295416 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#9  0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#10 0x003060295727 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#11 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#12 0x003060284cbc in Perl_hv_free_ent () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#13 0x003060284e26 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#14 0x003060286750 in Perl_hv_undef () from
/usr/lib64/p

Re: mod_perl head build with httpd 2.4.6 on Linux results

2014-01-30 Thread Jan Kaluža 

Hi again,

I've been able to fix the problem with freezing tests with event MPM 
using attached patch. The problem is that currently I'm somehow confused 
by the patched code.


Does somebody have an idea why the previous code thought that refcount 
== 0 means that perl interpreter is still in use? I would say that 
refcount == 0 would mean that perl interpreter is *not* used anymore.


The attached patch changes exactly this mentioned refcount behaviour and 
the tests are passing with all three MPMs in Linux.


Can you please verify the fix?

Regards,
Jan Kaluza

On 01/23/2014 01:18 PM, Jan Kaluža wrote:

On 11/15/2013 04:01 PM, Jeff Trawick wrote:

Is it fair to say that mod_perl shouldn't be used with the event MPM?

With the httpd24threading branch on Linux (older, RHEL 5-ish stuff) and
httpd 2.4.6 with event MPM, I'm getting hangs in some testcases (e.g.,
echo_bbs2, echo_nonblock, in_str_sandwich, etc., but not consistent) and
even a crash:


I'm able to reproduce handing echo_nonblock with event mpm even with my
httpd24 branch (so without threading fixes). I will try to fix this one
or at least debug it more.


#2  
#3  0x2ad0c2a3 in ?? () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/DBI.so

#4  0x2ad0ee8e in XS_DBI_dispatch () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/DBI.so

#5  0x003060290a96 in Perl_pp_entersub () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#6  0x0030602338a7 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#7  0x0030602376f0 in Perl_call_sv () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#8  0x003060295416 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#9  0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#10 0x003060295727 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#11 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#12 0x003060284cbc in Perl_hv_free_ent () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#13 0x003060284e26 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#14 0x003060286750 in Perl_hv_undef () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#15 0x00306029581a in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#16 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#17 0x2ae2c8fd6914 in modperl_cleanup_pnotes (data=0x1568c788) at
modperl_util.c:839
#18 0x2ae2bd992919 in run_cleanups (cref=0x1568bda8) at
memory/unix/apr_pools.c:2352
#19 0x2ae2bd991732 in apr_pool_clear (pool=0x1568bd88) at
memory/unix/apr_pools.c:772
#20 0x2ae2c715d4a0 in process_lingering_close (cs=0x1568c018,
pfd=0x11880aa0) at event.c:1317
#21 0x2ae2c715e06c in listener_thread (thd=0x11881358,
dummy=0x15638760) at event.c:1551
#22 0x2ae2bd9a04a9 in dummy_worker (opaque=0x11881358) at
threadproc/unix/thread.c:142
#23 0x00305a20673d in start_thread () from /lib64/libpthread.so.0
#24 0x0030596d40cd in clone () from /lib64/libc.so.6

The listener thread is running these cleanups, but that's not the thread
that handled the connection.



Jan Kaluza


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



Index: src/modules/perl/modperl_interp.c
===
--- src/modules/perl/modperl_interp.c	(revision 1562728)
+++ src/modules/perl/modperl_interp.c	(working copy)
@@ -277,7 +277,7 @@
 MP_TRACE_i(MP_FUNC, "unselect(interp=%pp): refcnt=%d",
interp, interp->refcnt);
 
-if (interp->refcnt != 0) {
+if (interp->refcnt > 1) {
 --interp->refcnt;
 MP_TRACE_i(MP_FUNC, "interp=0x%lx, refcnt=%d -- interp still in use",
(unsigned long)interp, interp->refcnt);


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

Re: mod_perl head build with httpd 2.4.6 on Linux results

2014-01-23 Thread Jan Kaluža 

On 11/15/2013 04:01 PM, Jeff Trawick wrote:

Is it fair to say that mod_perl shouldn't be used with the event MPM?

With the httpd24threading branch on Linux (older, RHEL 5-ish stuff) and
httpd 2.4.6 with event MPM, I'm getting hangs in some testcases (e.g.,
echo_bbs2, echo_nonblock, in_str_sandwich, etc., but not consistent) and
even a crash:


I'm able to reproduce handing echo_nonblock with event mpm even with my 
httpd24 branch (so without threading fixes). I will try to fix this one 
or at least debug it more.



#2  
#3  0x2ad0c2a3 in ?? () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/DBI.so
#4  0x2ad0ee8e in XS_DBI_dispatch () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/DBI.so
#5  0x003060290a96 in Perl_pp_entersub () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#6  0x0030602338a7 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#7  0x0030602376f0 in Perl_call_sv () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#8  0x003060295416 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#9  0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#10 0x003060295727 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#11 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#12 0x003060284cbc in Perl_hv_free_ent () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#13 0x003060284e26 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#14 0x003060286750 in Perl_hv_undef () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#15 0x00306029581a in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#16 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#17 0x2ae2c8fd6914 in modperl_cleanup_pnotes (data=0x1568c788) at
modperl_util.c:839
#18 0x2ae2bd992919 in run_cleanups (cref=0x1568bda8) at
memory/unix/apr_pools.c:2352
#19 0x2ae2bd991732 in apr_pool_clear (pool=0x1568bd88) at
memory/unix/apr_pools.c:772
#20 0x2ae2c715d4a0 in process_lingering_close (cs=0x1568c018,
pfd=0x11880aa0) at event.c:1317
#21 0x2ae2c715e06c in listener_thread (thd=0x11881358,
dummy=0x15638760) at event.c:1551
#22 0x2ae2bd9a04a9 in dummy_worker (opaque=0x11881358) at
threadproc/unix/thread.c:142
#23 0x00305a20673d in start_thread () from /lib64/libpthread.so.0
#24 0x0030596d40cd in clone () from /lib64/libc.so.6

The listener thread is running these cleanups, but that's not the thread
that handled the connection.



Jan Kaluza


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

Re: mod_perl head build with httpd 2.4.6 on Linux results

2014-01-13 Thread Jan Kaluža 

On 11/15/2013 04:01 PM, Jeff Trawick wrote:

Is it fair to say that mod_perl shouldn't be used with the event MPM?


I will try to check that and reproduce the crash you are seeing.

Jan Kaluza


With the httpd24threading branch on Linux (older, RHEL 5-ish stuff) and
httpd 2.4.6 with event MPM, I'm getting hangs in some testcases (e.g.,
echo_bbs2, echo_nonblock, in_str_sandwich, etc., but not consistent) and
even a crash:

#2  
#3  0x2ad0c2a3 in ?? () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/DBI.so
#4  0x2ad0ee8e in XS_DBI_dispatch () from
/usr/lib64/perl5/vendor_perl/5.8.8/x86_64-linux-thread-multi/auto/DBI/DBI.so
#5  0x003060290a96 in Perl_pp_entersub () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#6  0x0030602338a7 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#7  0x0030602376f0 in Perl_call_sv () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#8  0x003060295416 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#9  0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#10 0x003060295727 in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#11 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#12 0x003060284cbc in Perl_hv_free_ent () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#13 0x003060284e26 in ?? () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#14 0x003060286750 in Perl_hv_undef () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#15 0x00306029581a in Perl_sv_clear () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#16 0x003060295bc0 in Perl_sv_free () from
/usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so
#17 0x2ae2c8fd6914 in modperl_cleanup_pnotes (data=0x1568c788) at
modperl_util.c:839
#18 0x2ae2bd992919 in run_cleanups (cref=0x1568bda8) at
memory/unix/apr_pools.c:2352
#19 0x2ae2bd991732 in apr_pool_clear (pool=0x1568bd88) at
memory/unix/apr_pools.c:772
#20 0x2ae2c715d4a0 in process_lingering_close (cs=0x1568c018,
pfd=0x11880aa0) at event.c:1317
#21 0x2ae2c715e06c in listener_thread (thd=0x11881358,
dummy=0x15638760) at event.c:1551
#22 0x2ae2bd9a04a9 in dummy_worker (opaque=0x11881358) at
threadproc/unix/thread.c:142
#23 0x00305a20673d in start_thread () from /lib64/libpthread.so.0
#24 0x0030596d40cd in clone () from /lib64/libc.so.6

The listener thread is running these cleanups, but that's not the thread
that handled the connection.




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

Re: need sanity check on my mod_perl + 2.4.6 on Windows attempt

2013-11-07 Thread Jan Kaluža 

On 11/07/2013 09:53 AM, Steve Hay wrote:

On 7 November 2013 06:48, Jan Kaluža  wrote:

On 11/06/2013 11:53 PM, Steve Hay wrote:


On 6 November 2013 19:06, Jeff Trawick  wrote:


On Wed, Nov 6, 2013 at 1:20 PM, Steve Hay 
wrote:



On 6 November 2013 14:27, Jeff Trawick  wrote:


On Wed, Nov 6, 2013 at 8:50 AM, Steve Hay 
wrote:



On 6 November 2013 13:50, Steve Hay 
wrote:


On 6 November 2013 12:27, Jeff Trawick  wrote:


On Wed, Nov 6, 2013 at 4:02 AM, Steve Hay

wrote:



On 6 November 2013 00:48, Jeff Trawick  wrote:


Back to the httpd24threading branch:

* modperl_interp_pool_select() has this notion of phase, which
must
either
be startup or request context.
* It thinks it is startup only if the pool passed in is
s->process->pconf.
* Sometimes it is passed s->process->pool (parent of pconf), such
as
from
perl_parse_require_line().
* perl_parse_require_line() can sometimes be called from request
context.
* When perl_parse_require_line() calls
modperl_interp_pool_select(),
request
context can never be identified because perl_parse_require_line()
never
passes in r->pool (which I guess would be cmd->pool).
* etc.

This would seem to be the way to get the right pool to
modperl_interp_pool_select().

Index: src/modules/perl/modperl_util.c


===
--- src/modules/perl/modperl_util.c (revision 1539040)
+++ src/modules/perl/modperl_util.c (working copy)
@@ -989,7 +989,7 @@
   int count;
   void *key;
   auth_callback *ab;
-MP_dINTERP_POOLa(cmd->server->process->pool, cmd->server);
+MP_dINTERP_POOLa(cmd->pool, cmd->server);

   if (global_authz_providers == NULL) {
   MP_INTERP_PUTBACK(interp, aTHX);

That still doesn't bring happiness (no interpreter returned,
resulting
in a
crash trying to dereference interp).



I'm getting the same crash-on-startup behaviour now myself after a
fresh rebuild of everything (now using httpd-2.4.6 and
perl-5.19.5). I
will look back over the changes made on the threading branch and/or
my
merges of them into the httpd24 branch. Hopefully the answer lies
there somewhere. I'll be very grateful for any help I can get with
this though -- I didn't do the original work on either of those
branches...




With the "fix" above in place, modperl_init_vhost() seems to be the
next
crucial code.  We go down this path:

  if (base_server == s) {
  MP_TRACE_i(MP_FUNC, "base server is not vhost, skipping
%s",
 vhost);
  return OK;
  }

and fall through this FIXME in modperl_interp_pool_select():

  if (!scfg->mip) {
  /* FIXME: We get here if global "server_rec" ==
s,
scfg->mip
   * is not created then. I'm not sure if that's
bug
or
   * bad/good design decicision. For now just
return
NULL.
   */
  return NULL;
  }

(Note: disabling the base_server == s check in modperl_init_vhost()
brings
no happiness either, though perhaps it is a step in the right
direction.)

This path is new with httpd 2.4; 2.2 didn't have authz_providers.

This seems to be a whack-a-mole issue.  I'd expect that there is
some
easy
way to grab the interpreter for any arbitrary startup path, but I
don't
see
it.  Maybe it is worthwhile seeing if we already went through some
paths
where we were able to grab an interpreter.



The last change on the httpd24 branch (r1503193) is what added the
FIXME above, but it also made a change in perl_parse_require_line()
which I've lost in the course of merging the threading branch in: it
made that function tolerant of modperl_interp_pool_select() returning
NULL (which is exactly what happens in the FIXME case).

If modperl_interp_pool_select() returns NULL then
perl_parse_require_line() just returns NULL itself in r1503193, but
in
httpd24threading I've hidden the use of modperl_interp_pool_select()
within the MP_dINTERP_POOLa() macro (as per the general style of
changes in the threading branch), but that macro crashes if
modperl_interp_pool_select() has returned NULL.

The diff below makes that macro tolerant of
modperl_interp_pool_select() returning NULL, and makes
perl_parse_require_line() tolerant of interp ending up NULL, like it
used to be in r1503193.

With this diff in place (which includes your earlier change), the
server now starts up for me and tests appear to be running as normal.



Oops! In my excitement I forgot the diff!:

Index: src/modules/perl/modperl_interp.h
===
--- src/modules/perl/modperl_interp.h   (revision 1539262)
+++ src/modules/perl/modperl_interp.h   (working copy)
@@ -68,9 +68,12 @@
   #define MP_INTERP_POOLa(p, s)
\
   MP_TRACE_i(MP_FUNC, "selecting interp: p=%pp,

Re: mod_perl head build with httpd 2.4.6 on Linux results

2013-11-06 Thread Jan Kaluža 

On 11/06/2013 10:38 PM, Steve Hay wrote:

On 6 November 2013 18:42, Fred Moyer  wrote:

On Wed, Nov 6, 2013 at 10:26 AM, Steve Hay  wrote:


On 6 November 2013 17:55, Fred Moyer  wrote:

Greetings,

I've been tracking the httpd 2.4 dev work that Steve has been merging to
trunk,


I haven't merged anything into trunk. I created a new branch called
httpd24threading, copied from httpd24, and then merged the threading
branch into that. I was hoping that it would fix an
interpreter/threads-related problem that I was having on Windows with
the httpd24 branch, and it does indeed seem to have done.


Clearly I need to pay better attention here... I'll check out the
httpd24 branch and give that a whirl instead.


Nooo! Check out the httpd24threading branch and give *that* a whirl!!!
*That*'s the one that I think we should merge into trunk when we're
happy with it, and if I read Jeff's latest post correctly then things
are better than I thought -- it looks like the Require line parsing
problem isn't actually a problem at all right now, and won't be until
such time as PerlAddAuthzProvider is updated to allow an optional 2nd
handler. So I think we can at least punt that issue into the future
for now, and worry about it if/when PerlAddAuthzProvider is enhanced.


Latest httpd24threading looks OK on Fedora for me. It passes/fails the 
same tests as in older "httpd24" branch.


cgi,t related failures are caused by r1491887 (Pointed that already in 
some older mail to this mailing list). compat/conn_rec.t is caused by 
client_addr vs. remote_addr I was not able to fix in httpd24 branch.


Jan Kaluza








There are still numerous test failures to sort out (not just on
Windows), plus a problem with the order of creating an interpreter vs.
handling Require directive parsing that has just come to light (also
presumably not just on Windows), which is mentioned in the commit
message for revision 1539414. Assistance with resolving that would be
greatly appreciated.

After that, I think we could then be looking at merging it all into trunk :-)


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




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

Re: need sanity check on my mod_perl + 2.4.6 on Windows attempt

2013-11-06 Thread Jan Kaluža 

On 11/06/2013 11:53 PM, Steve Hay wrote:

On 6 November 2013 19:06, Jeff Trawick  wrote:

On Wed, Nov 6, 2013 at 1:20 PM, Steve Hay 
wrote:


On 6 November 2013 14:27, Jeff Trawick  wrote:

On Wed, Nov 6, 2013 at 8:50 AM, Steve Hay 
wrote:


On 6 November 2013 13:50, Steve Hay  wrote:

On 6 November 2013 12:27, Jeff Trawick  wrote:

On Wed, Nov 6, 2013 at 4:02 AM, Steve Hay

wrote:


On 6 November 2013 00:48, Jeff Trawick  wrote:

Back to the httpd24threading branch:

* modperl_interp_pool_select() has this notion of phase, which
must
either
be startup or request context.
* It thinks it is startup only if the pool passed in is
s->process->pconf.
* Sometimes it is passed s->process->pool (parent of pconf), such
as
from
perl_parse_require_line().
* perl_parse_require_line() can sometimes be called from request
context.
* When perl_parse_require_line() calls
modperl_interp_pool_select(),
request
context can never be identified because perl_parse_require_line()
never
passes in r->pool (which I guess would be cmd->pool).
* etc.

This would seem to be the way to get the right pool to
modperl_interp_pool_select().

Index: src/modules/perl/modperl_util.c

===
--- src/modules/perl/modperl_util.c (revision 1539040)
+++ src/modules/perl/modperl_util.c (working copy)
@@ -989,7 +989,7 @@
  int count;
  void *key;
  auth_callback *ab;
-MP_dINTERP_POOLa(cmd->server->process->pool, cmd->server);
+MP_dINTERP_POOLa(cmd->pool, cmd->server);

  if (global_authz_providers == NULL) {
  MP_INTERP_PUTBACK(interp, aTHX);

That still doesn't bring happiness (no interpreter returned,
resulting
in a
crash trying to dereference interp).



I'm getting the same crash-on-startup behaviour now myself after a
fresh rebuild of everything (now using httpd-2.4.6 and
perl-5.19.5). I
will look back over the changes made on the threading branch and/or
my
merges of them into the httpd24 branch. Hopefully the answer lies
there somewhere. I'll be very grateful for any help I can get with
this though -- I didn't do the original work on either of those
branches...



With the "fix" above in place, modperl_init_vhost() seems to be the
next
crucial code.  We go down this path:

 if (base_server == s) {
 MP_TRACE_i(MP_FUNC, "base server is not vhost, skipping %s",
vhost);
 return OK;
 }

and fall through this FIXME in modperl_interp_pool_select():

 if (!scfg->mip) {
 /* FIXME: We get here if global "server_rec" ==
s,
scfg->mip
  * is not created then. I'm not sure if that's
bug
or
  * bad/good design decicision. For now just
return
NULL.
  */
 return NULL;
 }

(Note: disabling the base_server == s check in modperl_init_vhost()
brings
no happiness either, though perhaps it is a step in the right
direction.)

This path is new with httpd 2.4; 2.2 didn't have authz_providers.

This seems to be a whack-a-mole issue.  I'd expect that there is
some
easy
way to grab the interpreter for any arbitrary startup path, but I
don't
see
it.  Maybe it is worthwhile seeing if we already went through some
paths
where we were able to grab an interpreter.



The last change on the httpd24 branch (r1503193) is what added the
FIXME above, but it also made a change in perl_parse_require_line()
which I've lost in the course of merging the threading branch in: it
made that function tolerant of modperl_interp_pool_select() returning
NULL (which is exactly what happens in the FIXME case).

If modperl_interp_pool_select() returns NULL then
perl_parse_require_line() just returns NULL itself in r1503193, but
in
httpd24threading I've hidden the use of modperl_interp_pool_select()
within the MP_dINTERP_POOLa() macro (as per the general style of
changes in the threading branch), but that macro crashes if
modperl_interp_pool_select() has returned NULL.

The diff below makes that macro tolerant of
modperl_interp_pool_select() returning NULL, and makes
perl_parse_require_line() tolerant of interp ending up NULL, like it
used to be in r1503193.

With this diff in place (which includes your earlier change), the
server now starts up for me and tests appear to be running as normal.


Oops! In my excitement I forgot the diff!:

Index: src/modules/perl/modperl_interp.h
===
--- src/modules/perl/modperl_interp.h   (revision 1539262)
+++ src/modules/perl/modperl_interp.h   (working copy)
@@ -68,9 +68,12 @@
  #define MP_INTERP_POOLa(p, s)
\
  MP_TRACE_i(MP_FUNC, "selecting interp: p=%pp, s=%pp", (p), (s));
\
  interp = modperl_interp_pool_select((p), (s));
\
-MP_TRACE_i(MP_FUNC, "  --> got (0x%pp)->refcnt=%d",
\
-   interp, interp->refcnt);
\
-aTHX = interp->perl
+if (interp) {
\
+MP_TRACE_i(MP_FUNC, "  --> got (0x%pp)-

Re: httpd24 on Windows?

2013-11-05 Thread Jan Kaluža 


Please could somebody in non-Windows-land give the httpd24threading
branch a try and report back what it's looking like there?


Hm, It crashes for me when starting httpd on "make test". It's OK in 
httpd24 branch. I haven't checked your commits yet to find out what's 
the problem, but I think I could try to bisect it tomorrow (don't have 
time today...)


#0  0x7f383a05bf13 in modperl_interp_select (r=0x0, c=c@entry=0x0, 
s=s@entry=0x0) at modperl_interp.c:403


#1  0x7f383a05bfb6 in modperl_interp_pool_select (p=, 
s=0x7f3847563ee0) at modperl_interp.c:396


#2  0x7f383a0631a5 in perl_parse_require_line (cmd=0x7fffbb1845a0, 
require_line=0x7f38475ce980 "goo bar", parsed_require_line=out>) at modperl_util.c:992


#3  0x7f38435a6ab1 in add_authz_provider (cmd=0x7fffbb1845a0, 
config=0x7f3847635cd8, args=0x7f38475ce980 "goo bar") at 
mod_authz_core.c:421


#4  0x7f3846f9ed76 in invoke_cmd (cmd=0x7f38437a8b48 
, parms=parms@entry=0x7fffbb1845a0, 
mconfig=0x7f3847635cd8, args=0x7f38475ce978 "my-user goo bar") at 
config.c:878


#5  0x7f3846fa135f in ap_walk_config_sub 
(section_vector=0x7f3847634f58, parms=0x7fffbb1845a0, 
current=0x7f38475ce930) at config.c:1308


#6  ap_walk_config (current=0x7f38475ce930, 
parms=parms@entry=0x7fffbb1845a0, 
section_vector=section_vector@entry=0x7f3847634f58) at config.c:1341


#7  0x7f3846f9452b in urlsection (cmd=0x7fffbb1845a0, mconfig=
, arg=0x7f384762f2c1 "") at core.c:2234

#8  0x7f3846f9ed76 in invoke_cmd (cmd=0x7f38471d7428 , 
parms=parms@entry=0x7fffbb1845a0, mconfig=0x7f384756b118, 
args=0x7f38475ce5f8 "/TestAPI__access2>") at config.c:878


#9  0x7f3846fa135f in ap_walk_config_sub 
(section_vector=0x7f384756a8f8, parms=0x7fffbb1845a0, 
current=0x7f38475ce5b0) at config.c:1308


#10 ap_walk_config (current=0x7f38475ce5b0, 
parms=parms@entry=0x7fffbb1845a0, section_vector=0x7f384756a8f8) at 
config.c:1341


#11 0x7f3846fa264c in ap_process_config_tree (s=, 
conftree=, p=0x7f3847538158, ptemp=) at 
config.c:2062


#12 0x7f3846f7f9e6 in main (argc=9, argv=0x7fffbb184808) at main.c:639


I think we could be getting close to merging this all into trunk! :-)



Jan Kaluza


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

Re: httpd24 on Windows?

2013-10-30 Thread Jan Kaluža 

On 10/29/2013 12:52 PM, Jan Kaluža wrote:

On 10/28/2013 10:05 AM, Steve Hay wrote:

On 4 October 2013 18:04, Steve Hay  wrote:

On 18 September 2013 12:31, Jan Kaluža  wrote:

On 09/18/2013 12:46 PM, Steve Hay wrote:


On 18 September 2013 11:32, Jan Kaluža  wrote:


Hi,

what's the state of mod_perl httpd24 branch on Windows currently? I
somehow
got lost in the updates and I'm not sure what's the current state.

Does it compile and work properly if you build against httpd-2.2?
If it
does, maybe we could do the merge and think about release even
when it
does
not work currently on Windows with httpd-2.4.

Lot of people are probably interested in mod_perl for Linux and not
releasing working code just because of Windows build seems to be
bad idea
to
me. Maybe we could get more people to try fixing mod_perl on Windows
using
this strategy too.



This sounds like a good plan, but can I get back to you on this in a
few days time? I'm currently waylaid with the release of perl-5.19.4
and I've forgotten myself where I got to with this on Windows!



Great :). I've just wanted to resurrect this discussion after a while.



I've tried the current httpd24 branch with Apache Lounge's 2.4.6 and
my own build of Perl 5.19.4. The build works fine but the test suite
crashes httpd.exe in t/api/add_config.t ("free from wrong pool"),
which I'm sure was not happening for me previously.


I've been looking more at this but haven't figured it out yet.

Debugging the test server processing the URL
http://localhost:8562/TestAPI__add_config/, I find that it crashes in
modperl_cleanup_pnotes() - in Safefree() on the first call to
Perl_hv_undef_flags():

 if (header->interpreter != aTHX) {
 Perl_croak_nocontext("panic: free from wrong pool, %p!=%p",
  header->interpreter, aTHX);
 }

The header->interpreter is the value saved away in cleanup_data->perl
by modperl_pnotes_cleanup_data(), which is registered as the cleanup
routine when the pnotes is made in modperl_pnotes(), so that's been
correctly restored to aTHX in modperl_cleanup_pnotes(), but the aTHX
in Safefree() is different and I don't know why, or how this was
working before :-/



Hm, I have no idea what's going on here, but it does not happen for me
with older Perl. The good thing is that Fedora 20 just updated to
Perl-5.18, so I will try to install F20 and Perl-5.18 and give it a try.
Will write you soon how it worked.


The tests works on Linux even with Perl-5.18, so I presume it's caused 
by the Perl build options on Windows or it's Windows-only related bug...


Jan Kaluza


Regards,
Jan Kaluza


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




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

Re: What is the status of the threading branch?

2013-10-30 Thread Jan Kaluža 

On 10/29/2013 07:18 PM, Steve Hay wrote:

The threading branch has a lot of useful looking commits, but no
activity for a while now. What is the status of this branch?

I'm currently having threading-related problems on the httpd-2.4
branch and can't help wondering if some of the problems are already
fixed...

Is the threading branch in a suitable state for merging into trunk? If
so then I could update httpd-2.4 from trunk and hopefully some of my
woes will be gone!


You can always merge threading branch with httpd-2.4 (which is equal to 
trunk more or less) and try how it works :).



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



Jan Kaluza


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

Re: httpd24 on Windows?

2013-10-29 Thread Jan Kaluža 

On 10/28/2013 10:05 AM, Steve Hay wrote:

On 4 October 2013 18:04, Steve Hay  wrote:

On 18 September 2013 12:31, Jan Kaluža  wrote:

On 09/18/2013 12:46 PM, Steve Hay wrote:


On 18 September 2013 11:32, Jan Kaluža  wrote:


Hi,

what's the state of mod_perl httpd24 branch on Windows currently? I
somehow
got lost in the updates and I'm not sure what's the current state.

Does it compile and work properly if you build against httpd-2.2? If it
does, maybe we could do the merge and think about release even when it
does
not work currently on Windows with httpd-2.4.

Lot of people are probably interested in mod_perl for Linux and not
releasing working code just because of Windows build seems to be bad idea
to
me. Maybe we could get more people to try fixing mod_perl on Windows
using
this strategy too.



This sounds like a good plan, but can I get back to you on this in a
few days time? I'm currently waylaid with the release of perl-5.19.4
and I've forgotten myself where I got to with this on Windows!



Great :). I've just wanted to resurrect this discussion after a while.



I've tried the current httpd24 branch with Apache Lounge's 2.4.6 and
my own build of Perl 5.19.4. The build works fine but the test suite
crashes httpd.exe in t/api/add_config.t ("free from wrong pool"),
which I'm sure was not happening for me previously.


I've been looking more at this but haven't figured it out yet.

Debugging the test server processing the URL
http://localhost:8562/TestAPI__add_config/, I find that it crashes in
modperl_cleanup_pnotes() - in Safefree() on the first call to
Perl_hv_undef_flags():

 if (header->interpreter != aTHX) {
 Perl_croak_nocontext("panic: free from wrong pool, %p!=%p",
  header->interpreter, aTHX);
 }

The header->interpreter is the value saved away in cleanup_data->perl
by modperl_pnotes_cleanup_data(), which is registered as the cleanup
routine when the pnotes is made in modperl_pnotes(), so that's been
correctly restored to aTHX in modperl_cleanup_pnotes(), but the aTHX
in Safefree() is different and I don't know why, or how this was
working before :-/



Hm, I have no idea what's going on here, but it does not happen for me 
with older Perl. The good thing is that Fedora 20 just updated to 
Perl-5.18, so I will try to install F20 and Perl-5.18 and give it a try. 
Will write you soon how it worked.


Regards,
Jan Kaluza


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

Re: httpd24 on Windows?

2013-09-18 Thread Jan Kaluža 

On 09/18/2013 12:46 PM, Steve Hay wrote:

On 18 September 2013 11:32, Jan Kaluža  wrote:

Hi,

what's the state of mod_perl httpd24 branch on Windows currently? I somehow
got lost in the updates and I'm not sure what's the current state.

Does it compile and work properly if you build against httpd-2.2? If it
does, maybe we could do the merge and think about release even when it does
not work currently on Windows with httpd-2.4.

Lot of people are probably interested in mod_perl for Linux and not
releasing working code just because of Windows build seems to be bad idea to
me. Maybe we could get more people to try fixing mod_perl on Windows using
this strategy too.



This sounds like a good plan, but can I get back to you on this in a
few days time? I'm currently waylaid with the release of perl-5.19.4
and I've forgotten myself where I got to with this on Windows!



Great :). I've just wanted to resurrect this discussion after a while.

JK


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

httpd24 on Windows?

2013-09-18 Thread Jan Kaluža 

Hi,

what's the state of mod_perl httpd24 branch on Windows currently? I 
somehow got lost in the updates and I'm not sure what's the current state.


Does it compile and work properly if you build against httpd-2.2? If it 
does, maybe we could do the merge and think about release even when it 
does not work currently on Windows with httpd-2.4.


Lot of people are probably interested in mod_perl for Linux and not 
releasing working code just because of Windows build seems to be bad 
idea to me. Maybe we could get more people to try fixing mod_perl on 
Windows using this strategy too.


Regards,
Jan Kaluza

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

Re: [httpd24 branch] apr-ext crashes

2013-08-07 Thread Jan Kaluža 

On 08/02/2013 07:10 PM, Steve Hay wrote:

Steve Hay wrote on 2013-07-30:

It's actually only the path to mod_perl.so that I need to add to the
PATH, which I'd determined previously was due to the new dependency (now
in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol.

I'll look at that again, or else just work around it for now by adding
to the PATH in the top-level Makefile.PL's MY::test().



For the record, I have now committed that "workaround" in rev. 1509781 after 
deciding that it's fine, not just a nasty hack. The commit message hopefully describes my 
reasoning adequately:

"Add the path to mod_perl.so to the PATH when running the test suite on Windows

Httpd.exe is able to find mod_perl.so because the test httpd.conf contains a 
LoadModule line with the fully qualified path to mod_perl.so in it. However, 
before httpd.exe is started the test framework must create that httpd.conf 
file. In the case of mod_perl it uses perl.exe and goes into 
Apache/TestConfigPerl.pm's run_apache_test_configure(), which runs 
APACHE_TEST_CONFIGURE() in various modules in t/response/TestApache (e.g. 
subprocess.pm). Those modules all use Apache2::Const, but 
Apache2/Const/Const.dll and ModPerl/Const/Const.dll now depend on mod_perl.so 
for the 'perl_module' symbol. Therefore, perl.exe must be able to find 
mod_perl.so when running the tests, and this is the easiest way to achieve that.

There is no problem with Apache2::Const and ModPerl::Const depending on mod_perl.so 
because they are normally only used within a mod_perl application, which will 
(obviously) have mod_perl.so loaded already. (It is only the APR::* modules which we 
are at pains (elsewhere) to avoid having a dependency on mod_perl.so because they 
are of use outside of mod_perl applications.)"



That makes sense. I have also tested httpd24 branch again and it's still 
working as expected for me.


Jan Kaluza


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

Re: [httpd24 branch] apr-ext crashes

2013-07-29 Thread Jan Kaluža 

On 07/29/2013 04:59 PM, Steve Hay wrote:

Jan Kaluža wrote on 2013-07-29:

On 07/29/2013 10:54 AM, Steve Hay wrote:

Ok, I've found the problem: Apache2::Build::apr_generation() is now

returning 2 instead of 1, but the apxs scripts on Windows are still
called ap[ru]-1-config.bat.


I could easily tweak apr_generation() to account for that, but I

guess the correct fix is to change apxs on Windows?

Hm, I build it with following options on Linux, so I presume it skips
this check:
   MP_APXS=/usr/bin/apxs \
   MP_APR_CONFIG=%{_bindir}/apr-1-config
After discussion with Joe Orton I think it would be better to use APR
generation 1 even for httpd-2.4, so the proper fix would be to change
apr_generation() method to return 1. Httpd-2.4 is still intended to be
compiled with APR-1.x. Maybe in the past it was not like that and
therefore we have that code there, but current state is like I said.



Ok, with revs 1222775 (apr_generation() change), 1448043 and 1503135 (aprutil-1 
changes) all reverted the build now works for me and the apr-ext tests no 
longer crash. The attached patch effects these three reverts.

Does this work for you? It reverts the "FIXME" for finding aprutil-1 which you 
added in rev 1448043, but I wonder if that was unnecessary?:- Maybe if you don't pass 
MP_APR_CONFIG then it will work fine for you, given that apr_generation() now does the 
right thing? Or failing that, passing MP_APU_CONFIG as well should locate aprutil-1?


With this patch everything works for me as expected, so you can commit 
it :).



If these changes are ok then I will commit them and continue looking at what 
else is wrong here on Windows...

I still have the problem of needing to put the httpd bin and mod_perl.so paths 
in my PATH, plus I need to pull in the latest Apache-Test changes 
(specifically, rev 1504090) for the httpd.conf generation to work correctly. 
How do I pull that into modperl?


I have done that in r1508317. If you would like to change it again in 
the future, it can be changed by "svn propedit svn:externals ."



Otherwise, my test failure list is now down to:

Test Summary Report
---
t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
   Parse errors: Bad plan.  You planned 5 tests but ran 1.
t\api\access2_24.t(Wstat: 0 Tests: 6 Failed: 3)
   Failed tests:  2, 5-6
t\api\err_headers_out.t   (Wstat: 0 Tests: 6 Failed: 3)
   Failed tests:  2-3, 5
t\compat\conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
   Parse errors: Bad plan.  You planned 4 tests but ran 2.
t\hooks\authen_digest.t   (Wstat: 0 Tests: 7 Failed: 4)
   Failed tests:  4-7
t\modperl\local_env.t (Wstat: 0 Tests: 6 Failed: 1)
   Failed test:  6
t\modperl\merge.t (Wstat: 0 Tests: 10 Failed: 3)
   Failed tests:  3, 6, 9
t\modperl\merge2.t(Wstat: 0 Tests: 10 Failed: 3)
   Failed tests:  3, 6, 9
t\modperl\merge3.t(Wstat: 0 Tests: 10 Failed: 3)
   Failed tests:  3, 6, 9
t\modperl\setupenv2.t (Wstat: 0 Tests: 23 Failed: 7)
   Failed tests:  17-23
t\modules\cgi.t   (Wstat: 0 Tests: 5 Failed: 5)
   Failed tests:  1-5
t\modules\cgi2.t  (Wstat: 0 Tests: 5 Failed: 5)
   Failed tests:  1-5
t\modules\cgipost.t   (Wstat: 0 Tests: 6 Failed: 5)
   Failed tests:  2-6
t\modules\cgipost2.t  (Wstat: 0 Tests: 6 Failed: 5)
   Failed tests:  2-6
t\modules\cgiupload.t (Wstat: 0 Tests: 2 Failed: 2)
   Failed tests:  1-2
t\modules\cgiupload2.t(Wstat: 0 Tests: 2 Failed: 2)
   Failed tests:  1-2
t\protocol\echo_block.t   (Wstat: 0 Tests: 3 Failed: 2)
   Failed tests:  2-3
t\protocol\echo_nonblock.t(Wstat: 0 Tests: 3 Failed: 1)
   Failed test:  2
t\protocol\echo_timeout.t (Wstat: 0 Tests: 5 Failed: 4)
   Failed tests:  2-5
t\protocol\pseudo_http.t  (Wstat: 0 Tests: 13 Failed: 9)
   Failed tests:  3-8, 11-13
Files=249, Tests=2468, 801 wallclock secs ( 2.15 usr +  0.28 sys =  2.43 CPU)
Result: FAIL
Failed 20/249 test programs. 67/2468 subtests failed.



I still have only the expected subset with your apr.patch:

t/compat/conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)
  Parse errors: Bad plan.  You planned 4 tests but ran 2.
t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
  Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
  Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  2


--

Re: [httpd24 branch] apr-ext crashes

2013-07-29 Thread Jan Kaluža 

On 07/29/2013 10:54 AM, Steve Hay wrote:

Ok, I've found the problem: Apache2::Build::apr_generation() is now returning 2 
instead of 1, but the apxs scripts on Windows are still called 
ap[ru]-1-config.bat.

I could easily tweak apr_generation() to account for that, but I guess the 
correct fix is to change apxs on Windows?


Hm, I build it with following options on Linux, so I presume it skips 
this check:

 MP_APXS=/usr/bin/apxs \
 MP_APR_CONFIG=%{_bindir}/apr-1-config

After discussion with Joe Orton I think it would be better to use APR 
generation 1 even for httpd-2.4, so the proper fix would be to change 
apr_generation() method to return 1. Httpd-2.4 is still intended to be 
compiled with APR-1.x. Maybe in the past it was not like that and 
therefore we have that code there, but current state is like I said.



Where does apxs come from on *nix? On Windows I've long used the one at
http://perl.apache.org/dist/win32-bin/apxs_win32-0.6.tar.gz
with a minor (local) change to line 107 of apxs_win32. Really I'd like to put 
out a 0.7, but I've no idea how to create
http://perl.apache.org/dist/win32-bin/apxs_win32-0.7.tar.gz


It's normally built together with httpd (since 'apxs' is part of httpd 
source code) and then include in Linux (Fedora/Debian/...) binary package.



Shall I make a 0.7 and put it in, say, http://people.apache.org/~stevehay/, for 
now, and then look at updating the perl.apache.org location later if someone 
knows how to?




I don't know what changed in apxs between 2.2 and 2.4. I would just try 
if it compiles with apr_generation() returning 1 and if it does, then 
you probably don't have to do anything.


Regards,
Jan Kaluza



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

Re: [httpd24 branch] merge with trunk?

2013-07-16 Thread Jan Kaluža 

t/api/server_const.t  (Wstat: 512 Tests: 0 Failed: 0)
   Non-zero exit status: 2
   Parse errors: No plan found in TAP output
t/modules/apache_resource.t   (Wstat: 512 Tests: 0 Failed: 0)
   Non-zero exit status: 2
   Parse errors: Bad plan.  You planned 1 tests but ran 0.
t/modules/apache_status.t (Wstat: 65280 Tests: 0 Failed: 0)
   Non-zero exit status: 255
   Parse errors: Bad plan.  You planned 15 tests but ran 0.


Those are related to missing &Apache2::ServerUtil::get_server_version.

You have removed that method in r1503137, because it's not provided by 
httpd-2.4, but there's compat method defined in modperl_apache_compat.h, 
which was used instead.


I can fix the tests to use proper httpd-2.4 version and remove that 
compat version if it's problem on Windows. Or if you are going to link 
modules against modperl.lib on Windows, I think we could try reverting 
that commit, since I linking against modperl.lib would probably fix also 
this previous linking problem.


Regards,
Jan Kaluza


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

Re: [httpd24 branch] merge with trunk?

2013-07-16 Thread Jan Kaluža 

On 07/16/2013 03:04 PM, Steve Hay wrote:

Jan Kaluža wrote on 2013-07-15:

On 07/15/2013 02:58 PM, Steve Hay wrote:

[...] right now I still have it crashing

on startup (with or without revision r1303215), so we obviously didn't
have the same crashing problem after all :-/ I will try to fix that
next.




I'm afraid I can't help you further here...



When running "nmake test" I'm getting:

Can't load 
'D:\temp\mp2d\modperl-httpd24\blib\arch/auto/Apache2/Const/Const.dll' for 
module Apache2::Const: load_file:The specified module could not be found at 
D:/temp/mp2d/perl/lib/DynaLoader.pm line 190.
  at D:\temp\mp2d\modperl-httpd24\t\response\TestApache\subprocess.pm line 13.

Trying a simple one-liner:

D:\temp\mp2d\perl\bin\perl.exe -Iblib\arch -Iblib\lib -MApache2::Const -e1

does much the same. That works with trunk, built against httpd-2.2. The 
difference is that Apache2/Const/Const.dll now depends on mod_perl.so (it 
didn't use to), and that isn't in a location in the PATH when running the test 
suite.

Using dumpbin /imports to see why we have this new dependency shows that it's 
due to the 'perl_module' symbol... We've been here before recently with the 
APR::Brigade build failure. I wondered if Apache2::Const (and maybe others) 
needed to link against libaprext.lib (with its fake 'perl_module' symbol) to 
avoid this problem, but lib/ModPerl/BuildMM says:

 # in order to decouple APR/APR::* from mod_perl.so,
 # link these modules against the static MP_APR_LIB lib,
 # rather than the mod_perl lib (which would demand mod_perl.so
 # be available). For other modules, use mod_perl.lib as
 # usual.

which suggests that Apache2::* modules are expected to depend on mod_perl.so 
(even though this one happened not to until now), so using libaprext.lib 
instead of mod_perl.lib here is probably the wrong thing to do here and would 
likely break things that require a proper definitions of 'perl_module'.

So I think the answer is to add src/modules/perl (where mod_perl.so has been 
built) to the PATH when running the test suite.

If I do that manually in my Command Prompt window then "nmake test" runs 
normally (albeit with a *lot* of test failures [1] which I'll look at later), but I'm not 
sure where is the best place to make that happen automatically within Apache-Test?

Is this an issue on other OSes, or only on Windows? (Not sure if you normally 
build mod_perl dynamically or statically linked elsewhere?)


If I understand it right, we don't link modules to anything explicitly 
on Linux, but when they are loaded later, all their dependencies have to 
be loaded on runtime too. Since apr/apr-util and mod_perl are loaded by 
httpd, there's no problem.


At least I see "LIBS => q[ ]" in MakeMaker parametrs for Apache2::* modules.



[1] The complete list of failures on this first run through (using a perl 
without LWP installed, so lots more tests were skipped too) is:

Test Summary Report
---
t\apache\subprocess.t (Wstat: 0 Tests: 1 Failed: 0)
   Parse errors: Bad plan.  You planned 5 tests but ran 1.
t\api\access2.t   (Wstat: 0 Tests: 0 Failed: 0)
   Parse errors: No plan found in TAP output
t\api\server_const.t  (Wstat: 2304 Tests: 0 Failed: 0)
   Non-zero exit status: 9
   Parse errors: No plan found in TAP output
t\apr-ext\brigade.t   (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 14 tests but ran 0.
t\apr-ext\bucket.t(Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 21 tests but ran 0.
t\apr-ext\finfo.t (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 27 tests but ran 0.
t\apr-ext\perlio.t(Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: No plan found in TAP output
t\apr-ext\pool.t  (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 77 tests but ran 0.
t\apr-ext\table.t (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 58 tests but ran 0.
t\apr-ext\threadmutex.t   (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 5 tests but ran 0.
t\apr-ext\threadrwlock.t  (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 5 tests but ran 0.
t\apr-ext\uri.t   (Wstat: 1280 Tests: 0 Failed: 0)
   Non-zero exit status: 5
   Parse errors: Bad plan.  You planned 36 tests but ran 0.
t\compat\conn_rec.t   (Wstat: 0 Tests: 2 Failed: 0)

Re: [httpd24 branch] merge with trunk?

2013-07-15 Thread Jan Kaluža 

On 07/15/2013 02:58 PM, Steve Hay wrote:

Jan Kaluža wrote on 2013-07-15:

On 07/15/2013 12:52 PM, Steve Hay wrote:> Jan Kaluža wrote on 2013-07-
15:

On 07/15/2013 12:30 PM, Steve Hay wrote:

Jan Kaluža wrote on 2013-07-15:

On 07/15/2013 10:48 AM, Steve Hay wrote:

So I now have a build of mod_perl against httpd-2.4. Yay!
However, it doesn't run yet... it's crashing when starting up

the  >>>> server. I will look into that very soon...


It crashed for me too here. It used to work before the changes

you've  >>>> done in last week. I will review them and try to find out
what's wrong.




That's good, actually, because it simultaneously means it isn't a
Windows-only failure and greatly narrows down where the problem

must  >>> be :-)  >>>  >>> I will look soon too if you haven't beaten
me to it ;-)  >>>  >>  >> I think I have fixed that (together with
some compiler warnings) in  >> r1503171. Hopefully it will still
compile properly on Windows. Please  >> inform me if this revision
works for you. All expected tests are  >> passing on Fedora in this
revision again.




At a quick glance I think it won't compile again because dTHXa and

dSP are declarations, which are now mixed up with code again.

You are right. Maybe something like r1503193 could workaround that?
Although whole situation around that code is strange (see my FIXME
comment in the mentioned revision).



It now builds on Windows again.

I've just rearranged it very slightly again in r1303215 to put back the early 
return if the key is not found, like you had done in r1503171. I've also 
protected the modperl_interp_pool_select() call and dTHXa() declaration with 
#ifdef USE_ITHREADS like other callers do.


It still works after these changes for me, so +1.


Not sure what to say about the FIXME comment, but if 
modperl_interp_pool_select() can now return NULL then the other callers should 
test for that too, rather than always blindly dereferencing the return value.

>

I will look at that shortly, but right now I still have it crashing on startup 
(with or without revision r1303215), so we obviously didn't have the same 
crashing problem after all :-/ I will try to fix that next.



I'm afraid I can't help you further here...

Regards,
Jan Kaluza


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

Re: [httpd24 branch] merge with trunk?

2013-07-15 Thread Jan Kaluža 

On 07/15/2013 12:52 PM, Steve Hay wrote:> Jan Kaluža wrote on 2013-07-15:
>> On 07/15/2013 12:30 PM, Steve Hay wrote:
>>> Jan Kaluža wrote on 2013-07-15:
>>>> On 07/15/2013 10:48 AM, Steve Hay wrote:
>>>>> So I now have a build of mod_perl against httpd-2.4. Yay!
>>>>> However, it doesn't run yet... it's crashing when starting up the
>>>> server. I will look into that very soon...
>>>>
>>>> It crashed for me too here. It used to work before the changes you've
>>>> done in last week. I will review them and try to find out what's 
wrong.

>>>>
>>>
>>> That's good, actually, because it simultaneously means it isn't a
>>> Windows-only failure and greatly narrows down where the problem must
>>> be :-)
>>>
>>> I will look soon too if you haven't beaten me to it ;-)
>>>
>>
>> I think I have fixed that (together with some compiler warnings) in
>> r1503171. Hopefully it will still compile properly on Windows. Please
>> inform me if this revision works for you. All expected tests are
>> passing on Fedora in this revision again.
>>
>
> At a quick glance I think it won't compile again because dTHXa and 
dSP are declarations, which are now mixed up with code again.


You are right. Maybe something like r1503193 could workaround that? 
Although whole situation around that code is strange (see my FIXME 
comment in the mentioned revision).


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


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

Re: [httpd24 branch] merge with trunk?

2013-07-15 Thread Jan Kaluža 

On 07/15/2013 12:30 PM, Steve Hay wrote:

Jan Kaluža wrote on 2013-07-15:

On 07/15/2013 10:48 AM, Steve Hay wrote:

So I now have a build of mod_perl against httpd-2.4. Yay!
However, it doesn't run yet... it's crashing when starting up the

server. I will look into that very soon...

It crashed for me too here. It used to work before the changes you've
done in last week. I will review them and try to find out what's wrong.



That's good, actually, because it simultaneously means it isn't a Windows-only 
failure and greatly narrows down where the problem must be :-)

I will look soon too if you haven't beaten me to it ;-)



I think I have fixed that (together with some compiler warnings) in 
r1503171. Hopefully it will still compile properly on Windows. Please 
inform me if this revision works for you. All expected tests are passing 
on Fedora in this revision again.


Jan Kaluza


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

Re: [httpd24 branch] merge with trunk?

2013-07-15 Thread Jan Kaluža 

On 07/15/2013 10:48 AM, Steve Hay wrote:

Steve Hay wrote on 2013-07-12:

Steve Hay wrote on 2013-07-12:

The problem of how to specify the path of aprutil-1 in
xs/APR/APR/Makefile.PL remains, but with the fix above the build now
proceeds to the next problem: Apache2/Provider.dll fails to link,
with an unresolved external symbol, ap_register_provider.

That symbol is exported from libhttpd.dll so I'm not sure right now
why the link fails because we *do* already link against libhttpd.lib
(and it has found it, along with libapr-1.lib and libaprutil-1.lib,
this time).


I've temporarily dodged the two problems above by (a) commenting out
the addition of -laprutil-1 to $libs in xs/APR/APR/Makefile.PL until I
figure out how to get its path, and (b) disabling the XS-wrapping of
ap_register_provider (by adding a leading '!' character) in
xs/maps/apache2-functions.map (it was only being wrapped for httpd >
2.3.0, but I can't figure out what causes it not to link at the moment).



I've now fixed those two problems properly in r1503135 and r1503136 
respectively.

The first fix might be the key to how to resolve that "FIXME" in 
xs/APR/APR/Makefile.PL?




So that got things going a little further. I've fixed some more code
before declaration errors in Apache2__RequestUtil.h (r1502464) but now
I've got another linker error, this time in Apache2/ServerUtil.dll: it
complains that ap_get_server_version is unresolved, and this time the
error is genuine. The symbol was exported from libhttpd.dll in httpd-
2.2, but ap_mmn.h notes that it was replaced with ap_get_server_banner
and ap_get_server_description in httpd-2.3 so I think I need to add
some more #_if_ ... #_end_ magic to apache2_functions.map to account
for that.

The attached patch does this, and with that in place the build now
runs through to completion (so perhaps the -laprutil-1 commented out
as mentioned above isn't even needed on Windows anyway? -- unless some
problem with omitting it comes to light in due course then I will just
make it conditional on !WIN32...).

What puzzles me is how can the build be working on other OSes? This
one is definitely not a Windows-specific problem. Before I go ahead
and commit this patch, is there some part of the puzzle that I'm missing?
How does it build for others without the patch?



I've committed that too in r1503137. It's easily reverted if it causes trouble 
for anyone, and we're only working on a branch here anyway.

So I now have a build of mod_perl against httpd-2.4. Yay!
However, it doesn't run yet... it's crashing when starting up the server. I 
will look into that very soon...


It crashed for me too here. It used to work before the changes you've 
done in last week. I will review them and try to find out what's wrong.



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



Regards,
Jan Kaluza


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

Re: [httpd24 branch] merge with trunk?

2013-07-15 Thread Jan Kaluža 

On 07/15/2013 10:48 AM, Steve Hay wrote:

Steve Hay wrote on 2013-07-12:

Steve Hay wrote on 2013-07-12:

The problem of how to specify the path of aprutil-1 in
xs/APR/APR/Makefile.PL remains, but with the fix above the build now
proceeds to the next problem: Apache2/Provider.dll fails to link,
with an unresolved external symbol, ap_register_provider.

That symbol is exported from libhttpd.dll so I'm not sure right now
why the link fails because we *do* already link against libhttpd.lib
(and it has found it, along with libapr-1.lib and libaprutil-1.lib,
this time).


I've temporarily dodged the two problems above by (a) commenting out
the addition of -laprutil-1 to $libs in xs/APR/APR/Makefile.PL until I
figure out how to get its path, and (b) disabling the XS-wrapping of
ap_register_provider (by adding a leading '!' character) in
xs/maps/apache2-functions.map (it was only being wrapped for httpd >
2.3.0, but I can't figure out what causes it not to link at the moment).



I've now fixed those two problems properly in r1503135 and r1503136 
respectively.


This looks great, but shouldn't ap_provider.h be guarded by #ifdef? I 
think this header does not exist before 2.4.



The first fix might be the key to how to resolve that "FIXME" in 
xs/APR/APR/Makefile.PL?


I will try to build latest httpd24 branch HEAD in Fedora and see if it 
fixes it too.






So that got things going a little further. I've fixed some more code
before declaration errors in Apache2__RequestUtil.h (r1502464) but now
I've got another linker error, this time in Apache2/ServerUtil.dll: it
complains that ap_get_server_version is unresolved, and this time the
error is genuine. The symbol was exported from libhttpd.dll in httpd-
2.2, but ap_mmn.h notes that it was replaced with ap_get_server_banner
and ap_get_server_description in httpd-2.3 so I think I need to add
some more #_if_ ... #_end_ magic to apache2_functions.map to account
for that.

The attached patch does this, and with that in place the build now
runs through to completion (so perhaps the -laprutil-1 commented out
as mentioned above isn't even needed on Windows anyway? -- unless some
problem with omitting it comes to light in due course then I will just
make it conditional on !WIN32...).

What puzzles me is how can the build be working on other OSes? This
one is definitely not a Windows-specific problem. Before I go ahead
and commit this patch, is there some part of the puzzle that I'm missing?
How does it build for others without the patch?



I've committed that too in r1503137. It's easily reverted if it causes trouble 
for anyone, and we're only working on a branch here anyway.

So I now have a build of mod_perl against httpd-2.4. Yay!
However, it doesn't run yet... it's crashing when starting up the server. I 
will look into that very soon...

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




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

Re: [httpd24 branch] merge with trunk?

2013-07-11 Thread Jan Kaluža 

On 07/11/2013 11:06 AM, Jan Kaluža wrote:

The error is:

libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external
symbol _perl_module
..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120:
1 unresolved externals

On Windows we build a static library called libaprext.lib containing
various symbols otherwise found in mod_perl.lib/dll for APR DLLs to
link against so that they don't have a dependency on mod_per.dll --
see the comments in the top-level Makefile.PL around line 187.

The list of source files whose objects are put in this library (given
by ModPerl::Code::src_apr_ext()) is:

modperl_error.c
modperl_bucket.c
modperl_common_util.c
modperl_common_log.c

So the problem here is that modperl_error.c is included in
libaprext.lib, but it references the symbol "perl_module", which is
defined in mod_perl.c, but that isn't included in libaprext.lib, so
the symbol is unresolved when linking APR/Brigade.dll (and presumably
any other APR/*.dll which links against libaprext.lib).

Simply throwing mod_perl.c into libaprext.lib too doesn't work because
it references many, many other symbols which are also not included.



So I think we need to move the definition of "perl_module" to some
other file which either already is or else can be included in
libaprext.lib, but I'm not sure where would be best right now.



I think moving it to different file is not possible. perl_module struct
contains pointers to methods which later call another methods which
really need all those symbols. So to define perl_module, you basically
need all that stuff included in mod_perl.h.

I think what you could do is to create dummy .c file and just add dummy
perl_module definition there. No source code mentioned above (in
libaprext.lib) actually needs perl_module, so it should be OK to do
that. You wouldn't be able to use perl_module properly from external
library anyway if I'm right.

It's not ideal way, but I'm not sure I see better solution. I've done
that in ModPerl::Const:

http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in-Const.xs.patch


When thinking about it, it's really strange we have problems with 
perl_module in httpd24 branch, because that part of code didn't change 
at all in httpd24 branch.


In trunk, the perl_module in mod_perl.h is declared as extern too and 
the files used to link libaprext.lib are also the same. Maybe there are 
different compler/linker flags in use when building with 2.4 causing 
this behaviour?


I think that could be worth checking too.



Regards,
Jan Kaluza


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



Regards,
Jan Kaluza


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

Re: [httpd24 branch] merge with trunk?

2013-07-11 Thread Jan Kaluža 

On 07/11/2013 10:41 AM, Steve Hay wrote:

Jan Kaluža wrote on 2013-07-11:

On 07/11/2013 01:17 AM, Steve Hay wrote:

The first problem was "Warning (mostly harmless): No library found for
-laprutil-1" appearing from Makefile.PL between ModPerl::WrapXS and APR
(presumably it applies to the latter), which I've ignored for now but
will probably come back to bite me later. No other such issues are
reported, and all the libraries (apr-1.lib, aprutil-1.lib,
libapr-1.lib, libapriconv-1.lib, libaprutil-1.lib, libhttpd.lib,
mod_dav.lib and xml.lib) are together in C:\Apache24\lib, so I'm not
sure what the problem is there yet.


After thinking about that for a bit and checking all my patches I've
found out there's the same problem on Linux. I have overcame that with
quite hardcoded way last year when trying to get it work:

http://jkaluza.fedorapeople.org/mod_perl/0020-Link-APR.so-against-
libaprutil-1.patch

Something like that is probably needed on Windows too. Proper way
would be to fix Apache2::Build to include this library, but I was not
able to achieve that last year if I remember well.



I see that patch is in the httpd24 branch so it is already being done on 
Windows just like any other OS, but the problem is that the path to the library 
in question isn't known.

In my build $libs is

-LD:\temp\mp2\MODPER~1\blib\arch\auto\LIBAPR~1 -laprext -laprutil-1

and libaprutil-l.lib is in D:\temp\mp2\apache\lib. If I manually add 
-LD:\temp\mp2\apache\lib into $libs then it builds fine but I'm struggling to 
automate that at the moment.


Right, I had the same problem with automation and I decided to hardcode 
it for Linux :(.



The httpd lib path that I need is seemingly available from Apache2::BuildConfig:

'MODPERL_AP_LIBDIR' => 'D:\\temp\\mp2\\apache\\lib'

but none of the MODPERL_* keys exist in the $build in xs/APR/APR/Makefile.PL; 
they are presumably generated later.



The build now progress to APR::Brigade, but falls over complaining
that modperl_error.c references the symbol "perl_module", but that
isn't defined anywhere.


Can you send full compiler error? perl_module should be declared in
mod_perl.h and defined in mod_perl.c.

I've had similar issue when building xs/ModPerl/Const. That was caused
by ModPerl::Const using mod_perl.h, but did not compiling mod_perl.c,
so extern perl_module variable was not defined. Maybe there's similar
situation in Windows for some file too.

I would check full trace which leads you to undefined perl_module and
check if files have #include mod_perl.h and links with compiler's
mod_perl.c output.



The error is:

libaprext.lib(modperl_error.obj) : error LNK2001: unresolved external symbol 
_perl_module
..\..\..\blib\arch\auto\APR\Brigade\Brigade.dll : fatal error LNK1120: 1 
unresolved externals

On Windows we build a static library called libaprext.lib containing various 
symbols otherwise found in mod_perl.lib/dll for APR DLLs to link against so 
that they don't have a dependency on mod_per.dll -- see the comments in the 
top-level Makefile.PL around line 187.

The list of source files whose objects are put in this library (given by 
ModPerl::Code::src_apr_ext()) is:

modperl_error.c
modperl_bucket.c
modperl_common_util.c
modperl_common_log.c

So the problem here is that modperl_error.c is included in libaprext.lib, but it 
references the symbol "perl_module", which is defined in mod_perl.c, but that 
isn't included in libaprext.lib, so the symbol is unresolved when linking APR/Brigade.dll 
(and presumably any other APR/*.dll which links against libaprext.lib).

Simply throwing mod_perl.c into libaprext.lib too doesn't work because it 
references many, many other symbols which are also not included.



So I think we need to move the definition of "perl_module" to some other file 
which either already is or else can be included in libaprext.lib, but I'm not sure where 
would be best right now.



I think moving it to different file is not possible. perl_module struct 
contains pointers to methods which later call another methods which 
really need all those symbols. So to define perl_module, you basically 
need all that stuff included in mod_perl.h.


I think what you could do is to create dummy .c file and just add dummy 
perl_module definition there. No source code mentioned above (in 
libaprext.lib) actually needs perl_module, so it should be OK to do 
that. You wouldn't be able to use perl_module properly from external 
library anyway if I'm right.


It's not ideal way, but I'm not sure I see better solution. I've done 
that in ModPerl::Const:


http://jkaluza.fedorapeople.org/mod_perl/0023-Define-perl_module-in-Const.xs.patch

Regards,
Jan Kaluza


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

Re: [httpd24 branch] merge with trunk?

2013-07-10 Thread Jan Kaluža 

On 07/11/2013 01:17 AM, Steve Hay wrote:

Hi Jan,

Thank you so much for all your work on this!

>

I've finally got round to having a look at it (sorry it's been so
long!), and have run into some teething problems here on Windows...


Thank you for trying that branch. I haven't actually tried to compile it 
on Windows.



The first problem was "Warning (mostly harmless): No library found for
-laprutil-1" appearing from Makefile.PL between ModPerl::WrapXS and APR
(presumably it applies to the latter), which I've ignored for now but
will probably come back to bite me later. No other such issues are
reported, and all the libraries (apr-1.lib, aprutil-1.lib, libapr-1.lib,
libapriconv-1.lib, libaprutil-1.lib, libhttpd.lib, mod_dav.lib and
xml.lib) are together in C:\Apache24\lib, so I'm not sure what the
problem is there yet.


After thinking about that for a bit and checking all my patches I've 
found out there's the same problem on Linux. I have overcame that with 
quite hardcoded way last year when trying to get it work:


http://jkaluza.fedorapeople.org/mod_perl/0020-Link-APR.so-against-libaprutil-1.patch

Something like that is probably needed on Windows too. Proper way would 
be to fix Apache2::Build to include this library, but I was not able to 
achieve that last year if I remember well.



Next up, modperl_util.c contained various declarations scatted amongst
code which VC++ doesn't support when compiling C (rather than C++). I've
fixed that in r1502045.


Right, that was really bug. Thanks for fixing that.


Next, modperl_apache_compat.c complains that we're *defining* the
missing httpd function "ap_get_server_version", but we've declared it
the same way as httpd would do -- that is, marked "dllexport" when
compiled in httpd and otherwise marked "dllimport" to say that we're
third-party code importing it from httpd. We're third-party code, of
course, but *defining* a function marked "dllimport" isn't allowed.
Removing dllexport/dllimport from the declaration (see attached patch)
fixes this for me, but I don't know if that's the right thing on other OSes?


It works for me. It does not change XS generation, it builds and tests 
are working. Feel free to commit that patch to httpd24.



The build now progress to APR::Brigade, but falls over complaining that
modperl_error.c references the symbol "perl_module", but that isn't
defined anywhere.


Can you send full compiler error? perl_module should be declared in 
mod_perl.h and defined in mod_perl.c.


I've had similar issue when building xs/ModPerl/Const. That was caused 
by ModPerl::Const using mod_perl.h, but did not compiling mod_perl.c, so 
extern perl_module variable was not defined. Maybe there's similar 
situation in Windows for some file too.


I would check full trace which leads you to undefined perl_module and 
check if files have #include mod_perl.h and links with compiler's 
mod_perl.c output.



I've run out of time tonight but will come back to this very soon. If
you can shed any light on the remaining problems so far that might
assist me when I look again then please let me know.

Steve


Regards,
Jan Kaluza




On 9 July 2013 11:16, Jan Kaluža mailto:jkal...@redhat.com>> wrote:

Hi,

I just want to say that from my point of view, it should be possible
to merge httpd24 branch with trunk now. Maybe it's time to actually
do the merge and give that code some more testing.

Before future release, we have to coordinate with Apache-Test to
release also new Apache-Test which contains fixes needed to run
mod_perl with httpd24.

I'm going to update mod_perl to the HEAD of httpd24 branch in Fedora
soon too to give it more testing.

Regards,
Jan Kaluza

--__--__-
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.__org
<mailto:dev-unsubscr...@perl.apache.org>
For additional commands, e-mail: dev-h...@perl.apache.org
<mailto:dev-h...@perl.apache.org>





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

[httpd24 branch] merge with trunk?

2013-07-09 Thread Jan Kaluža 

Hi,

I just want to say that from my point of view, it should be possible to 
merge httpd24 branch with trunk now. Maybe it's time to actually do the 
merge and give that code some more testing.


Before future release, we have to coordinate with Apache-Test to release 
also new Apache-Test which contains fixes needed to run mod_perl with 
httpd24.


I'm going to update mod_perl to the HEAD of httpd24 branch in Fedora 
soon too to give it more testing.


Regards,
Jan Kaluza

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

Re: use Apache-Test/trunk@1496006 in httpd24 branch

2013-07-01 Thread Jan Kaluža 

Done in httpd24 branch.

On 06/24/2013 03:12 PM, Jan Kaluža wrote:

On 06/24/2013 02:54 PM, Jan Kaluža wrote:

Hi,

since we need Apache-Test from trunk to run modperl-httpd24 tests
without additional manual tweaks (like quick and dirty chmod 777
/run/httpd I was using on my system... *shame*), I'm playing with idea
of changing svn:externals in httpd24 branch to
"https://svn.apache.org/repos/asf/perl/Apache-Test/trunk@1496006";.


Oops... I meant revision 1496018 (current HEAD) of course.


I have not verified if this change actually works, but I'm going to do
that soon. I presume to use Apache-Test from trunk in httpd24 branch a)
until the new Apache-Test version containing the fixes gets released or
b) until there will be some decision how to continue with httpd24
development which will allow me to not use this.

It will make development easier and it will be possible for
distributions willing to use mod_perl from httpd24 branch to properly
package it with the tests included.

If you are against this change or you think it will break something,
please stop me by sending an email :).

Regards,
Jan Kaluza

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



Regards,
Jan Kaluza


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



Jan Kaluza


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

Re: httpd24 branch now works with both httpd-2.2 and httpd-2.4

2013-07-01 Thread Jan Kaluža 

On 06/27/2013 12:55 PM, Jan Kaluža wrote:

Hi,

I have done some work on httpd24 branch today.

Already done:
- xs/tables are now divided into two separate directories:
xs/tables/current and xs/tables/current24 (2.2 vs. 2.4)
- xs_generate generates output to the proper directory according to
httpd version.
- everything should compile fine with both httpd versions
- tests should work properly with both versions. there are currently
some failing tests, but they fail even in trunk for me.

What's missing (TODO):
- xs/maps are still httpd-2.4 only, so if you try to run "make
xs_generate" with httpd-2.2, it will break.


This should work now (at least it works for me).



We have to use #ifdefs in the xs/maps and merge xs/maps from trunk with
xs/maps from httpd24 branch. I will do that, but probably not this week.

I think it could be ready for merge after some more testing and when the
things on TODO list above gets fixed.

Regards,
Jan Kaluza

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



Jan Kaluza


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

Re: [httpd24] t/directive/perlloadmodule3.t failure

2013-07-01 Thread Jan Kaluža 

On 06/30/2013 10:19 PM, Niko Tyni wrote:

On Tue, Jun 25, 2013 at 11:18:52AM +0200, Jan Kaluža wrote:

On 06/24/2013 11:14 PM, Niko Tyni wrote:

On Mon, Jun 24, 2013 at 01:13:58PM +0200, Jan Kaluža wrote:

On 06/23/2013 10:21 PM, Niko Tyni wrote:



# Failed test 1 in t/directive/perlloadmodule3.t at line 38



  
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?r1=959392&r2=959464

Clearly mod_perl2 needs to somehow map the char to a Perl number. The
test failure happens because the zero byte "\0" is true in Perl and
so the is_virtual method always returns true.



Try it with attached patch. I haven't tried to run the tests with
the patch applied, but from the generated code it looks like it
should return int now.


Thanks, but that doesn't quite work here:



Hm, I have just tried it and it works for me here (fails without
this patch and works with it). Have you regenerated xs using "make
source_scan" and "make xs_generate"?


I thought I had, but obviously something went wrong.

I can confirm it's working for me now. Thanks, and sorry
for being hasty.



No problem. I have just committed the fix to httpd24 branch.

Thanks for testing.
Jan Kaluza


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

svn commit: r1491887 - /perl/modperl/trunk/t/modperl/local_env.t

2013-06-27 Thread Jan Kaluža 

Hi,

just for info, this commit breaks following tests for me. I haven't 
tried to get more info yet.


t/modules/cgi.t   (Wstat: 0 Tests: 5 Failed: 2)
  Failed tests:  2, 5
t/modules/cgi2.t  (Wstat: 0 Tests: 5 Failed: 1)
  Failed test:  3
t/modules/cgipost.t   (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgipost2.t  (Wstat: 0 Tests: 6 Failed: 1)
  Failed test:  4
t/modules/cgiupload.t (Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  1
t/modules/cgiupload2.t(Wstat: 0 Tests: 2 Failed: 1)
  Failed test:  2

Regards,
Jan Kaluza

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

httpd24 branch now works with both httpd-2.2 and httpd-2.4

2013-06-27 Thread Jan Kaluža 

Hi,

I have done some work on httpd24 branch today.

Already done:
- xs/tables are now divided into two separate directories: 
xs/tables/current and xs/tables/current24 (2.2 vs. 2.4)
- xs_generate generates output to the proper directory according to 
httpd version.

- everything should compile fine with both httpd versions
- tests should work properly with both versions. there are currently 
some failing tests, but they fail even in trunk for me.


What's missing (TODO):
- xs/maps are still httpd-2.4 only, so if you try to run "make 
xs_generate" with httpd-2.2, it will break.


We have to use #ifdefs in the xs/maps and merge xs/maps from trunk with 
xs/maps from httpd24 branch. I will do that, but probably not this week.


I think it could be ready for merge after some more testing and when the 
things on TODO list above gets fixed.


Regards,
Jan Kaluza

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

Re: [httpd24] t/directive/perlloadmodule3.t failure

2013-06-25 Thread Jan Kaluža 

On 06/24/2013 11:14 PM, Niko Tyni wrote:

On Mon, Jun 24, 2013 at 01:13:58PM +0200, Jan Kaluža wrote:

On 06/23/2013 10:21 PM, Niko Tyni wrote:



# Failed test 1 in t/directive/perlloadmodule3.t at line 38



  
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?r1=959392&r2=959464

Clearly mod_perl2 needs to somehow map the char to a Perl number. The
test failure happens because the zero byte "\0" is true in Perl and
so the is_virtual method always returns true.



Try it with attached patch. I haven't tried to run the tests with
the patch applied, but from the generated code it looks like it
should return int now.


Thanks, but that doesn't quite work here:
  t/directive/perlloadmodule3.t .. 1/3 # Failed test 1 in 
t/directive/perlloadmodule3.t at line 38
  # Failed test 2 in t/directive/perlloadmodule3.t at line 69
  # Failed test 3 in t/directive/perlloadmodule3.t at line 97
  t/directive/perlloadmodule3.t .. Failed 3/3 subtests
  t/directive/perlloadmodule4.t .. Failed 3/3 subtests
  t/directive/perlloadmodule5.t .. Failed 3/3 subtests
  t/directive/perlloadmodule6.t .. Failed 3/3 subtests

Will look into it properly later.


Hm, I have just tried it and it works for me here (fails without this 
patch and works with it). Have you regenerated xs using "make 
source_scan" and "make xs_generate"?


Regards,
Jan Kaluza



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

Re: use Apache-Test/trunk@1496006 in httpd24 branch

2013-06-24 Thread Jan Kaluža 

On 06/24/2013 02:54 PM, Jan Kaluža wrote:

Hi,

since we need Apache-Test from trunk to run modperl-httpd24 tests
without additional manual tweaks (like quick and dirty chmod 777
/run/httpd I was using on my system... *shame*), I'm playing with idea
of changing svn:externals in httpd24 branch to
"https://svn.apache.org/repos/asf/perl/Apache-Test/trunk@1496006";.


Oops... I meant revision 1496018 (current HEAD) of course.


I have not verified if this change actually works, but I'm going to do
that soon. I presume to use Apache-Test from trunk in httpd24 branch a)
until the new Apache-Test version containing the fixes gets released or
b) until there will be some decision how to continue with httpd24
development which will allow me to not use this.

It will make development easier and it will be possible for
distributions willing to use mod_perl from httpd24 branch to properly
package it with the tests included.

If you are against this change or you think it will break something,
please stop me by sending an email :).

Regards,
Jan Kaluza

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



Regards,
Jan Kaluza


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

use Apache-Test/trunk@1496006 in httpd24 branch

2013-06-24 Thread Jan Kaluža 

Hi,

since we need Apache-Test from trunk to run modperl-httpd24 tests 
without additional manual tweaks (like quick and dirty chmod 777 
/run/httpd I was using on my system... *shame*), I'm playing with idea 
of changing svn:externals in httpd24 branch to 
"https://svn.apache.org/repos/asf/perl/Apache-Test/trunk@1496006";.


I have not verified if this change actually works, but I'm going to do 
that soon. I presume to use Apache-Test from trunk in httpd24 branch a) 
until the new Apache-Test version containing the fixes gets released or 
b) until there will be some decision how to continue with httpd24 
development which will allow me to not use this.


It will make development easier and it will be possible for 
distributions willing to use mod_perl from httpd24 branch to properly 
package it with the tests included.


If you are against this change or you think it will break something, 
please stop me by sending an email :).


Regards,
Jan Kaluza

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

Re: [Apache-Test + httpd24] [PATCH] Set DefaultRuntimeDir on Apache 2.4

2013-06-24 Thread Jan Kaluža 

On 06/23/2013 10:10 PM, Niko Tyni wrote:

Quoting :

   Create run-time files such as shared memory files, pid files, etc.
 Use ap_runtime_dir_relative() so that the global configuration for the
 location of such files, either by the DEFAULT_REL_RUNTIMEDIR compile
 setting or the DefaultRuntimeDir directive, will be respected. Apache
 httpd 2.4.2 and above.

The attached patch makes Apache-Test set DefaultRunTimeDir to the
log directory so that mod_auth_digest (and possibly others) will write
there. The setting is guarded with IfVersion directives, so the change
shouldn't break anything with older Apache versions.

With this, the mod_perl httpd24 branch doesn't need an explicit
DefaultRuntimeDir setting in t/conf/extra.conf.in anymore; remove that
as well.



mod_perl part committed in http://svn.apache.org/r1496006.

Thanks,
Jan Kaluza


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

Re: httpd24 (was Re: 2.0.9-dev)

2013-06-24 Thread Jan Kaluža 

On 06/23/2013 10:52 PM, Niko Tyni wrote:

At the moment httpd24 is lagging behind trunk. There seems to be a need
for making sure they stay synchronised.


This is temporary state and it was supposed to be like that only before
someone from core mod_perl developers decides how to continue with the
development... As I said before in this email, I will re-merge httpd24
branch and if we decide to choose this way, I think I would be able to
merge it regularly.


Thanks again!



Merged in http://svn.apache.org/r1496004 . I will try to merge with 
trunk more frequently now.


Regards,
Jan Kaluza


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

Re: [httpd24] t/directive/perlloadmodule3.t failure

2013-06-24 Thread Jan Kaluža 

On 06/23/2013 10:21 PM, Niko Tyni wrote:

We're seeing just one test failure with the httpd24 branch
and Apache 2.4.4:


# Failed test 1 in t/directive/perlloadmodule3.t at line 38


This is an API change in Apache 2.4: the server_rec struct member types
have changed. In this case, is_virtual used to be an 'int' but is now a
'char'.

  
http://svn.apache.org/viewvc/httpd/httpd/trunk/include/httpd.h?r1=959392&r2=959464

Clearly mod_perl2 needs to somehow map the char to a Perl number. The
test failure happens because the zero byte "\0" is true in Perl and
so the is_virtual method always returns true.

I couldn't find existing infrastructure to do this mapping but maybe
I'm just missing it?


Try it with attached patch. I haven't tried to run the tests with the 
patch applied, but from the generated code it looks like it should 
return int now.


Regards,
Jan Kaluza

Index: xs/Apache2/ServerRec/Apache2__ServerRec.h
===
--- xs/Apache2/ServerRec/Apache2__ServerRec.h	(revision 1495981)
+++ xs/Apache2/ServerRec/Apache2__ServerRec.h	(working copy)
@@ -16,4 +16,17 @@
 
 #if AP_SERVER_MAJORVERSION_NUMBER>2 || AP_SERVER_MINORVERSION_NUMBER>=3
 #define loglevel log.level
+
+static MP_INLINE
+int mpxs_Apache2__ServerRec_is_virtual(pTHX_ server_rec *s, SV *val)
+{
+int retval = s->is_virtual;
+
+if (val) {
+s->is_virtual = SvIV(val);
+}
+
+return retval;
+}
+
 #endif
Index: xs/maps/apache2_structures.map
===
--- xs/maps/apache2_structures.map	(revision 1495981)
+++ xs/maps/apache2_structures.map	(working copy)
@@ -99,7 +99,7 @@
 %  error_fname
 $  error_log
 $  loglevel
-<  is_virtual
+~  is_virtual
 <  module_config
 <  lookup_defaults
 <  addrs
Index: xs/maps/modperl_functions.map
===
--- xs/maps/modperl_functions.map	(revision 1495981)
+++ xs/maps/modperl_functions.map	(working copy)
@@ -21,6 +21,9 @@
  mpxs_Apache2__RequestRec_finfo | | r, finfo=NULL
  mpxs_Apache2__RequestRec_handler | | ...
  mpxs_Apache2__RequestRec_content_languages | | r, languages=(SV *)NULL
+,
+MODULE=Apache2::ServerRec   PACKAGE=Apache2::ServerRec
+ mpxs_Apache2__ServerRec_is_virtual   | | server_rec *:s, val=(SV *)NULL
 
 MODULE=Apache2::RequestUtil   PACKAGE=guess
  mpxs_Apache2__RequestRec_push_handlers


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

Re: [httpd24] [PATCH] Make sure authn and authz providers are cleaned up in time

2013-06-24 Thread Jan Kaluža 

On 06/23/2013 09:55 PM, Niko Tyni wrote:

As discussed in , we encountered somewhat
non-deterministic SIGSEGVs at the end of the mod_perl test suite when
building our packages based on the httpd24 branch (merged with the
2.0.8 release.)

It turns out the 'pre_cleanup' function cleanup_perl_global_providers()
was getting called after mod_perl had been unloaded, because the cleanup
was registered against the server process pool. This pool has a longer
lifetime than that of the mod_perl shared object.

As suggested by Stefan Fritsch, registering the cleanup against the
configuration pool seems to work better. This fixes the problem completely
according to my tests.  Proposed patch attached.



Applied in 1495982.

Thanks,
Jan Kaluza




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




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

Re: mod_perl and $0

2013-04-14 Thread Jan Kaluža 

On 04/12/2013 09:15 AM, Michiel Beijen wrote:

Hi,

According to perldoc perlvar the special variable $0 "Contains the
name of the program being executed".

My application uses $0 and FindBin to add some relative subdirectories
to @INC. This works fine in CGI context, and when scripts are run from
the command line, but under mod_perl $0 actually contains the Apache
configuration file, so this does not work correctly. We fix this by
performing 'use lib' with the actual directory names in the apache
perl startup file.

Now Fedora (Jan Kaluza) added a patch to their mod_perl package to set
$0 to 'httpd' which is done I think in order to have a nice process
list:

http://pkgs.fedoraproject.org/cgit/mod_perl.git/commit/mod_perl-short-name.patch?id=e18c20f9e3cdc3e062f75e8d54fdd4520d2f719f


This was done mainly to fix 
https://bugzilla.redhat.com/show_bug.cgi?id=782369 , but as you stated 
below, during my work on porting mod_perl to httpd24, I have found out 
the same thing as you and currently in F18+ this patch is not applied:


http://pkgs.fedoraproject.org/cgit/mod_perl.git/tree/mod_perl.spec#n81


The problem with that is that it is no longer a valid path, so if we
use FindBin it dies.

I now worked around it by determining if $0 is a valid path and if not
by assigning to it in a BEGIN block. Now mod_perl can at least start
again on Fedora.

Two questions:

A: is it conceivable that we fix mod_perl so that it actually returns
the correct value for $0?
B: is the downstream patch Fedora uses for setting $0 to 'httpd' dersirable?

--
Mike



Jan Kaluza


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

Re: Time for 2.0.8?

2013-03-19 Thread Jan Kaluža 

On 03/18/2013 03:15 PM, Fred Moyer wrote:

+1. There was one issue I wanted to resolve with the YAML file using
version_from insteas if version, but I will start the release wheels.
This won't have httpd 2.4 compat yet correct?


Actually, I think Joe Orton committed some of my httpd-2.4 related 
patches to trunk, but they are guarded by #ifdefs and do not affect the 
code anyhow until you try to compile mod_perl against httpd-2.4. In this 
case, you have to do the "make source_scan" and "make xs_generate" 
exercise. So, current trunk contains some httppd-2.4 related changes, 
but they are not used yet and you are not able to actually compile and 
use mod_perl-trunk with httpd-2.4 yet. You have to use httpd-2.4 branch.


So, you are right. I just wanted to make it more accurate.


On Mar 18, 2013 5:41 AM, "Adam Prime" mailto:adam.pr...@utoronto.ca>> wrote:

+1

On 03/18/2013 05:32 AM, Steve Hay wrote:
 > The mod_perl trunk now contains a bunch of fixes for recent
versions of
 > perl, especially with respect to changes to rehashing. These changes
 > will be necessary for mod_perl to build with the forthcoming perl
 > 5.18.0. That is due to be released on 18th May, and the perl repo
is in
 > full code freeze from Wednesday (20th March) so in theory no further
 > changes will be forthcoming which will require fixes to mod_perl.
 >
 > Therefore, it would be good to roll a new release of mod_perl
very soon
 > so that we have a release which works with 5.18.0 when that gets
 > released.
 >
 > -
 > To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org

 > For additional commands, e-mail: dev-h...@perl.apache.org

 >


-
To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org

For additional commands, e-mail: dev-h...@perl.apache.org




Jan Kaluza


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

Re: httpd24 branch

2013-02-26 Thread Jan Kaluža 

On 02/26/2013 03:52 AM, Andy Colson wrote:

On 02/25/2013 05:20 AM, Jan Kaluža wrote:

On 02/22/2013 09:02 PM, Andy Colson wrote:

After applying mod_perl-2.0.5-nolfs.patch, then re-making, I got this on
make test:

t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.16.2
/home/andy/apps/mod_perl24/t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT=
APACHE_TEST_USER= APACHE_TEST_APXS= \
/usr/bin/perl5.16.2 -Iblib/arch -Iblib/lib \
t/TEST -bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.16.2
/home/andy/apps/mod_perl24/t/TEST -bugreport -verbose=0
/usr/sbin/httpd  -d /home/andy/apps/mod_perl24/t -f
/home/andy/apps/mod_perl24/t/conf/httpd.conf -D APACHE2 -D
PERL_USEITHREADS
using Apache/2.4.3 (event MPM)

waiting 300 seconds for server to start: .[Fri Feb 22 13:55:18.809928
2013] [env:warn] [pid 7261:tid 3070203648] AH01506: PassEnv variable
LD_LIBRARY_PATH was undefined
AH00526: Syntax error on line 296 of
/home/andy/apps/mod_perl24/t/conf/httpd.conf:
Unknown Authz provider: valid-user
[  error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
sh: line 1:  7165 Terminated  /usr/bin/perl5.16.2
/home/andy/apps/mod_perl24/t/TEST -bugreport -verbose=0
make: *** [run_tests] Error 143


I've played with my systems /etc/httpd/httpd.conf file, is that a
problem?


I'm not sure how exactly Apache-Test works, but there are some
comments about "system-wide httpd.conf", so I presume it gets the list
of modules from the system-wide httpd.conf.

Please check you have "LoadModule authz_user_module
modules/mod_authz_user.so" included in your system-wide httpd.conf and
check if it's included in /home/andy/apps/mod_perl24/t/conf/httpd.conf.

"valid-user" should be provided by that httpd module.


-Andy


Yep, that works.  I had to enable these (in my system httpd.conf) to get
everything to run thru:

authz_user_module
authn_core_module
access_compat_module


Hum... I got to this test and it just froze:

t/protocol/echo_filter.t  1/3


You could try running just this single test using: "t/TEST 
t/protocol/echo_filter.t" and check the httpd log in t/logs




I'll play around and see if I can figure out why.

-Andy


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



Jan Kaluza


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

Re: httpd24 branch

2013-02-26 Thread Jan Kaluža 

On 02/25/2013 07:39 PM, Torsten Förtsch wrote:

On 02/25/2013 12:20 PM, Jan Kaluža wrote:

I've played with my systems /etc/httpd/httpd.conf file, is that a
problem?


I'm not sure how exactly Apache-Test works, but there are some comments
about "system-wide httpd.conf", so I presume it gets the list of modules
from the system-wide httpd.conf.


Before starting the httpd Apache::Test calls

   apxs -q SYSCONFDIR

to get the location of the system httpd.conf. Based on that file it
creates t/conf/httpd.conf. In particular, it inherits LoadModule and
LoadFile directives.

This kind of DWIMing has pluses and minuses. If you look from the
perspective of a certain system with a complex custom configuration and
you run the tests for an additional module to be integrated then it is
perhaps a plus to have all the other (custom) modules included when
testing. On the other hand, if you are a RPM package builder or similar
it is perhaps better to inherit from a certain standard configuration.
That's why t/TEST accepts the --httpd_conf and --httpd_conf_extra options.

However, Andy's problem is an error. Directives that are provided by
optional modules should be wrapped in a  block. Apache::Test
also provides need* and have* routines to skip tests if a module is
missing. Though, it is a nightmare to get all this optional stuff right.


Thanks, I will try to fix that in the tests I've touched.


Torsten



Jan Kaluza


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

Re: httpd24 branch

2013-02-25 Thread Jan Kaluža 

On 02/22/2013 09:02 PM, Andy Colson wrote:

On 2/21/2013 1:41 AM, Jan Kaluža wrote:

Hi,

I think I've committed all my patches [1] to httpd24 branch. It builds
OK for me and I think it's now time for more people to build it and
report your problems with this branch.

To compile it, I just checkout the httpd24 and run:

/usr/bin/perl Makefile.PL MP_APXS=/usr/bin/apxs
MP_APR_CONFIG=/usr/bin/apr-1-config

make

If you want to run tests, you have to at first create ./t/run directory
(to create this automatically, I would have to patch Apache-Test which I
can't since it's separate component and lives outside my httpd24 branch
if I'm right)

Then you can just run 'make test'.

The only failing test is t/directive/perlloadmodule3.t. I don't know
perl enough to parse that code which merges configurations in this test
yet.





Make worked fine for me.  Make test died again because of the lfs thing:


Oh, and I forgot to mention I've committed this patch few minutes ago.

Thanks,
Jan Kaluza



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

Re: httpd24 branch

2013-02-25 Thread Jan Kaluža 

On 02/22/2013 09:02 PM, Andy Colson wrote:

After applying mod_perl-2.0.5-nolfs.patch, then re-making, I got this on
make test:

t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.16.2
/home/andy/apps/mod_perl24/t/TEST -clean
APACHE_TEST_GROUP= APACHE_TEST_HTTPD= APACHE_TEST_PORT=
APACHE_TEST_USER= APACHE_TEST_APXS= \
/usr/bin/perl5.16.2 -Iblib/arch -Iblib/lib \
t/TEST -bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.16.2
/home/andy/apps/mod_perl24/t/TEST -bugreport -verbose=0
/usr/sbin/httpd  -d /home/andy/apps/mod_perl24/t -f
/home/andy/apps/mod_perl24/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.4.3 (event MPM)

waiting 300 seconds for server to start: .[Fri Feb 22 13:55:18.809928
2013] [env:warn] [pid 7261:tid 3070203648] AH01506: PassEnv variable
LD_LIBRARY_PATH was undefined
AH00526: Syntax error on line 296 of
/home/andy/apps/mod_perl24/t/conf/httpd.conf:
Unknown Authz provider: valid-user
[  error]
server has died with status 255 (t/logs/error_log wasn't created, start
the server in the debug mode)
sh: line 1:  7165 Terminated  /usr/bin/perl5.16.2
/home/andy/apps/mod_perl24/t/TEST -bugreport -verbose=0
make: *** [run_tests] Error 143


I've played with my systems /etc/httpd/httpd.conf file, is that a problem?


I'm not sure how exactly Apache-Test works, but there are some comments 
about "system-wide httpd.conf", so I presume it gets the list of modules 
from the system-wide httpd.conf.


Please check you have "LoadModule authz_user_module 
modules/mod_authz_user.so" included in your system-wide httpd.conf and 
check if it's included in /home/andy/apps/mod_perl24/t/conf/httpd.conf.


"valid-user" should be provided by that httpd module.


-Andy





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



Jan Kaluza


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

Re: httpd24 branch

2013-02-20 Thread Jan Kaluža 

Hi,

I think I've committed all my patches [1] to httpd24 branch. It builds 
OK for me and I think it's now time for more people to build it and 
report your problems with this branch.


To compile it, I just checkout the httpd24 and run:

/usr/bin/perl Makefile.PL MP_APXS=/usr/bin/apxs 
MP_APR_CONFIG=/usr/bin/apr-1-config


make

If you want to run tests, you have to at first create ./t/run directory 
(to create this automatically, I would have to patch Apache-Test which I 
can't since it's separate component and lives outside my httpd24 branch 
if I'm right)


Then you can just run 'make test'.

The only failing test is t/directive/perlloadmodule3.t. I don't know 
perl enough to parse that code which merges configurations in this test yet.


If the build ends up with error message that it can't link against 
-laprutil-1, we will have to fix workaroud (and little hack) I've done 
in commit 1448043 [2].


[1] 
http://mail-archives.apache.org/mod_mbox/perl-modperl-cvs/201302.mbox/browser

[2] http://svn.apache.org/viewvc?view=revision&revision=1448043

Regards,
Jan Kaluza

On 02/18/2013 08:28 AM, Jan Kaluža wrote:

Hi,

I've been granted commit access to mod_perl (Thanks to Torsten), so I
want to inform you about my intentions with httpd24 branch.

1. Merge changes from trunk to httpd24 branch.
2. Review my patches from http://jkaluza.fedorapeople.org/mod_perl/ and
commit them to httpd24 branch.
3. Run make source_scan on my machine and commit the results to httpd24
branch.

Those three steps should allow people to just ./configure and make
mod_perl with httpd24 sources. They will also make httpd24 branch
*httpd24 only* and personally I think this is the way to go, because of
following reasons:

1. Build system (make source_scan) is not good enough to run properly on
all systems and I'm not going to rewrite it.
2. httpd 2.4 auth API changed in a way where it works very differently
than the one in 2.2. I will still try to put 2.4 code to proper #ifdefs,
but it would be really great to just have separate version for 2.4.

When all this is done, I will commit my second patchset which adds
httpd-2.4 features to mod_perl (mainly new auth API) and fixes lot of
mod_perl tests.

Please feel free to monitor my work in httpd24 branch and comment it on
list if you find some problem there. It's my first experience with
mod_perl and I really don't know everything about it.

Regards,
Jan Kaluza

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




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

Re: httpd24 branch

2013-02-19 Thread Jan Kaluža 

On 02/18/2013 07:36 PM, Kevin A. McGrail wrote:

On 2/18/2013 2:28 AM, Jan Kaluža wrote:

Hi,

I've been granted commit access to mod_perl (Thanks to Torsten), so I
want to inform you about my intentions with httpd24 branch.

1. Merge changes from trunk to httpd24 branch.
2. Review my patches from http://jkaluza.fedorapeople.org/mod_perl/
and commit them to httpd24 branch.
3. Run make source_scan on my machine and commit the results to
httpd24 branch.

I look forward to this course of action.  My only question is shouldn't
you need to run make xs_generate as well?  I haven't gotten far enough
to find out but if I can get past those hurdles, i believe I can assist
much more readily.


Yes, I just didn't mention it, but I will run both. Currently there is 
some problem with my mod_perl commit access, so I'm waiting for admins 
to fix that. Once I'll be able to commit, I will start doing changes 
described in m original email.


Regards,
Jan Kaluza


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

httpd24 branch

2013-02-17 Thread Jan Kaluža 

Hi,

I've been granted commit access to mod_perl (Thanks to Torsten), so I 
want to inform you about my intentions with httpd24 branch.


1. Merge changes from trunk to httpd24 branch.
2. Review my patches from http://jkaluza.fedorapeople.org/mod_perl/ and 
commit them to httpd24 branch.
3. Run make source_scan on my machine and commit the results to httpd24 
branch.


Those three steps should allow people to just ./configure and make 
mod_perl with httpd24 sources. They will also make httpd24 branch 
*httpd24 only* and personally I think this is the way to go, because of 
following reasons:


1. Build system (make source_scan) is not good enough to run properly on 
all systems and I'm not going to rewrite it.
2. httpd 2.4 auth API changed in a way where it works very differently 
than the one in 2.2. I will still try to put 2.4 code to proper #ifdefs, 
but it would be really great to just have separate version for 2.4.


When all this is done, I will commit my second patchset which adds 
httpd-2.4 features to mod_perl (mainly new auth API) and fixes lot of 
mod_perl tests.


Please feel free to monitor my work in httpd24 branch and comment it on 
list if you find some problem there. It's my first experience with 
mod_perl and I really don't know everything about it.


Regards,
Jan Kaluza

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

Re: Apache 2.4 make test

2012-10-03 Thread Jan Kaluža 

On 09/28/2012 05:50 PM, Andy Colson wrote:

I'm attempting to fix a "make test" that is failing:

$ t/TEST -verbose api/access
... lots of output ...

# testing : auth_type
# expected: none
# received: undef
not ok 8
# testing : auth_type
# expected: Basic
# received: Basic
ok 9
ok 10


After searching around a little (there are lots of generated files), I
think I've come across the source:

xs/Apache2/Access/Apache2__Access.h

static MP_INLINE
const char *mpxs_Apache2__RequestRec_auth_type(pTHX_ request_rec *r,
   char *type)
{
 if (type) {
 mpxs_insert_auth_cfg(aTHX_ r, "AuthType", type);
 }

 return ap_auth_type(r);
}

ap_auth_type():  Older doc say "If no authentication menthod is
applicable, this routine returns NULL".  I cannot seem to find the
function at http://apr.apache.org/docs/apr/1.4/index.html


Not sure if it's still actual, but this is not apr function, you can 
find its definition as it's in 2.2 branch in http_core.h [1].


In 2.4, it returns NULL only when mod_authn_core is not loaded I think [2].

[1] 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/include/http_core.h?revision=1166612&view=markup


[2] 
http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/server/core.c?revision=1373168&view=markup



I'm not sure how this used to work... but would I want to do something
like:


static MP_INLINE
const char *mpxs_Apache2__RequestRec_auth_type(pTHX_ request_rec *r,
   char *type)
{
 if (type) {
 mpxs_insert_auth_cfg(aTHX_ r, "AuthType", type);
 }

 const char *tmp = ap_auth_type(r);
 if (! tmp){
 return "none";
 }
 else {
 return tmp;
 }
}


am I in the right ballpark here?


I think this looks OK, but I don't have big experience with mod_perl :). 
I'm not sure if you should not return Perl equivalent of NULL in this 
case to do the same thing as ap_auth_type.



-Andy

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



Regards,
Jan Kaluza


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

Re: Fwd: Re: trying mod_perl patches for httpd 2.4

2012-09-26 Thread Jan Kaluža 

On 09/26/2012 10:20 AM, Jan Kaluža wrote:

On 09/26/2012 02:10 AM, Andy Colson wrote:

sorry, didn't cc the list.


 Original Message 
Subject: Re: trying mod_perl patches for httpd 2.4
Date: Tue, 25 Sep 2012 19:08:16 -0500
From: Andy Colson 
To: Jan Kaluža 

Try as I might, I cannot get mod_perl debug symbols to work:

perl Makefile.PL MP_APR_CONFIG=/usr/bin/apr-1-config MP_DEBUG=1
MP_TRACE=1

make
make test

 later ...

[  error] for stacktrace, run: gdb /usr/sbin/httpd -core
/home/andy/apps/mod_perl-2.0/core


$ gdb /usr/sbin/httpd -core /home/andy/apps/mod_perl-2.0/core
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/httpd...done.
[New LWP 26308]

warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `/usr/sbin/httpd -d /home/andy/apps/mod_perl-2.0/t
-f /home/andy/apps/mod_perl-2'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6efe253 in modperl_env_clear () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
(gdb) bt full
#0  0xb6efe253 in modperl_env_clear () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#1  0xb6ee672e in modperl_boot () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#2  0xb6e3b0a1 in Perl_leave_scope (my_perl=my_perl@entry=0xb7aefb78,
base=0) at scope.c:970
 uv = 30
 type = 30 '\036'
 sv = 
 value = 
 gv = 
 av = 
 hv = 
 ptr = 
 str = 
 i = 
 was = false
#3  0xb6e3bf63 in Perl_pop_scope (my_perl=my_perl@entry=0xb7aefb78) at
scope.c:110
 oldsave = 
#4  0xb6d9491d in S_parse_body (xsinit=0xb6ee682c ,
env=0x0, my_perl=0xb7aefb78) at perl.c:2270
 rsfp = 0xb7b07ec8
 dosearch = false
 doextract = 
 argc = 1
 linestr_sv = 0x0
 lex_start_flags = 0
 argv = 0xb7ae4d0c
 scriptname = 0xb6ea2c52 "/dev/null"
 c = 
 cddir = 
 add_read_e_script = 
#5  perl_parse (my_perl=0xb7aefb78, xsinit=0xb6ee682c ,
argc=6, argv=0xb7ae4cf8, env=0x0)
 at perl.c:1633
 oldscope = -1213255152
 ret = 0
 cur_env = {je_prev = 0xb7aefcf4, je_buf = {{__jmpbuf =
{-1225953968, -1225941384, -1213313800, 0, -261314454,
 -1795530632}, __mask_was_saved = 0, __saved_mask =
{__val = {0, 3068008408, 64, 3068861920,
   3081712096, 3069013328, 1, 3069013328, 3081736520,
3068688206, 64, 16, 3081737144, 3068110662, 8, 0,
   3069300928, 3451674880, 1, 16, 3069859476,
3069013328, 3069300928, 3081698168, 3219875352,
   3068690813, 3068887968, 3069252682, 3069300928, 0,
3069298720, 3081698168, je_ret = 0,
   je_mustcatch = false}
#6  0xb6ee6ae4 in modperl_startup () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#7  0xb6ee6984 in modperl_startup () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#8  0xb6ee7d8e in modperl_init () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#9  0xb6ee8368 in modperl_hook_init () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#10 0xb6ee83ae in modperl_run () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#11 0xb6eef499 in modperl_cmd_load_module () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#12 0xb774ce94 in invoke_cmd (cmd=0xb6f1c228 ,
parms=parms@entry=0xbfeb6a3c, mconfig=0xb79bf068,
 args=0xb79ef718 "TestCompat::apache_module") at config.c:1014
 override_list_ok = 
 w = 
 w2 = 
 w3 = 
 errmsg = 0x0
#13 0xb774f675 in ap_walk_config_sub (section_vector=0xb79a5bd8,
parms=0xbfeb6a3c, current=0xb79ef6f0) at config.c:1298
 dir_config = 
 retval = 
 cmd = 
 ml = 0xb79bac38
 dir = 
#14 ap_walk_config (current=0xb79ef6f0, current@entry=0xb79bf4c0,
parms=parms@entry=0xbfeb6a3c,
 section_vector=0xb79a5bd8) at config.c:1331
 errmsg = 0x0
 oldconfig = 0x0
#15

Re: Fwd: Re: trying mod_perl patches for httpd 2.4

2012-09-26 Thread Jan Kaluža 

On 09/26/2012 02:10 AM, Andy Colson wrote:

sorry, didn't cc the list.


 Original Message 
Subject: Re: trying mod_perl patches for httpd 2.4
Date: Tue, 25 Sep 2012 19:08:16 -0500
From: Andy Colson 
To: Jan Kaluža 

Try as I might, I cannot get mod_perl debug symbols to work:

perl Makefile.PL MP_APR_CONFIG=/usr/bin/apr-1-config MP_DEBUG=1 MP_TRACE=1

make
make test

 later ...

[  error] for stacktrace, run: gdb /usr/sbin/httpd -core
/home/andy/apps/mod_perl-2.0/core


$ gdb /usr/sbin/httpd -core /home/andy/apps/mod_perl-2.0/core
GNU gdb (GDB) 7.5
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/sbin/httpd...done.
[New LWP 26308]

warning: Could not load shared library symbols for linux-gate.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/libthread_db.so.1".
Core was generated by `/usr/sbin/httpd -d /home/andy/apps/mod_perl-2.0/t
-f /home/andy/apps/mod_perl-2'.
Program terminated with signal 11, Segmentation fault.
#0  0xb6efe253 in modperl_env_clear () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
(gdb) bt full
#0  0xb6efe253 in modperl_env_clear () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#1  0xb6ee672e in modperl_boot () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#2  0xb6e3b0a1 in Perl_leave_scope (my_perl=my_perl@entry=0xb7aefb78,
base=0) at scope.c:970
 uv = 30
 type = 30 '\036'
 sv = 
 value = 
 gv = 
 av = 
 hv = 
 ptr = 
 str = 
 i = 
 was = false
#3  0xb6e3bf63 in Perl_pop_scope (my_perl=my_perl@entry=0xb7aefb78) at
scope.c:110
 oldsave = 
#4  0xb6d9491d in S_parse_body (xsinit=0xb6ee682c ,
env=0x0, my_perl=0xb7aefb78) at perl.c:2270
 rsfp = 0xb7b07ec8
 dosearch = false
 doextract = 
 argc = 1
 linestr_sv = 0x0
 lex_start_flags = 0
 argv = 0xb7ae4d0c
 scriptname = 0xb6ea2c52 "/dev/null"
 c = 
 cddir = 
 add_read_e_script = 
#5  perl_parse (my_perl=0xb7aefb78, xsinit=0xb6ee682c ,
argc=6, argv=0xb7ae4cf8, env=0x0)
 at perl.c:1633
 oldscope = -1213255152
 ret = 0
 cur_env = {je_prev = 0xb7aefcf4, je_buf = {{__jmpbuf =
{-1225953968, -1225941384, -1213313800, 0, -261314454,
 -1795530632}, __mask_was_saved = 0, __saved_mask =
{__val = {0, 3068008408, 64, 3068861920,
   3081712096, 3069013328, 1, 3069013328, 3081736520,
3068688206, 64, 16, 3081737144, 3068110662, 8, 0,
   3069300928, 3451674880, 1, 16, 3069859476,
3069013328, 3069300928, 3081698168, 3219875352,
   3068690813, 3068887968, 3069252682, 3069300928, 0,
3069298720, 3081698168, je_ret = 0,
   je_mustcatch = false}
#6  0xb6ee6ae4 in modperl_startup () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#7  0xb6ee6984 in modperl_startup () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#8  0xb6ee7d8e in modperl_init () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#9  0xb6ee8368 in modperl_hook_init () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#10 0xb6ee83ae in modperl_run () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#11 0xb6eef499 in modperl_cmd_load_module () from
/home/andy/apps/mod_perl-2.0/src/modules/perl/mod_perl.so
No symbol table info available.
#12 0xb774ce94 in invoke_cmd (cmd=0xb6f1c228 ,
parms=parms@entry=0xbfeb6a3c, mconfig=0xb79bf068,
 args=0xb79ef718 "TestCompat::apache_module") at config.c:1014
 override_list_ok = 
 w = 
 w2 = 
 w3 = 
 errmsg = 0x0
#13 0xb774f675 in ap_walk_config_sub (section_vector=0xb79a5bd8,
parms=0xbfeb6a3c, current=0xb79ef6f0) at config.c:1298
 dir_config = 
 retval = 
 cmd = 
 ml = 0xb79bac38
 dir = 
#14 ap_walk_config (current=0xb79ef6f0, current@entry=0xb79bf4c0,
parms=parms@entry=0xbfeb6a3c,
 section_vector=0xb79a5bd8) at config.c:1331
 errmsg = 0x0
 oldconfig = 0x0
#15 0xb7750a5d in ap_process_config_tree (s=0xb79a4a

Re: trying mod_perl patches for httpd 2.4

2012-09-25 Thread Jan Kaluža 

On 09/24/2012 03:55 PM, Andy Colson wrote:

On 9/24/2012 1:02 AM, Jan Kaluža wrote:

On 09/22/2012 06:58 PM, Andy Colson wrote:

Bummer...

make test  totally dies:




/usr/sbin/httpd  -d /home/andy/apps/mod_perl-2.0/t -f
/home/andy/apps/mod_perl-2.0/t/conf/httpd.conf -D APACHE2 -D
PERL_USEITHREADS
using Apache/2.4.3 (event MPM)

waiting 300 seconds for server to start: .[Sat Sep 22 11:56:13.629096
2012] [env:warn] [pid 2330:tid 3069482752] AH01506: PassEnv variable
LD_LIBRARY_PATH was undefined


^ This looks like the problem, but I'm not sure why it's not set for
you. I will try to reproduce it during this week, but it works properly
for me on Fedora.



Actually I've found out I have this warning displayed too and it works 
properly here, so the problem is not here...


I've also added one more patch (number 28) which fixes test start for 
me, but the symptoms were different in my case.




 From what little googling I did, and some prior emails to the group,
I'm wondering if its mpm/threaded related?

Is Fedora using event mpm with a threaded perl?  (also, on perl 5.16.1?)


I'm using prefork mpm here with perl-5.14.2.


I think I kinda figured out the MP_TRACE stuff, would that be helpful at
all?

Also my gdb foo is not strong, but I'd be happy to attempt anything if
you think it might be useful.


It should be enough to install debugging info for httpd, run what "make 
test" suggests, type "bt full" and store the output somewhere. You could 
also check ./t/logs/error_log if it's there.



Ahh, hang on... what if I dont have LD_LIBRARY_PATH set to anything? I'm
almost positive it isnt set at all, anywhere.  Slackware uses
/etc/ld.so.conf and not LD_LIBRARY_PATH.  (this might be babble talk,
I'm outta my league here)


As I said, after tests I think this is not problem.


Thanks for your time on this,

-Andy


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



Regards,
Jan Kaluza


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

Re: Help Offered

2012-09-23 Thread Jan Kaluža 

On 09/22/2012 12:59 PM, Tom Browder wrote:

On Fri, Sep 21, 2012 at 11:55 PM, Fred Moyer  wrote:

On Thu, Sep 20, 2012 at 3:04 AM, Tom Browder  wrote:

I'm Tom Browder, a Perl  user with a fair amount of Perl, C, and C++

...

Welcome!


Thanks, Fred.


How can I help get mod_perl 2 up and running on the latest Apache?


There are a few patches on the users and dev list in which some users
have shown they can compile mod_perl with Apache 2.4. Those need to be


Okay, I found this most recent message on the dev list:

   http://marc.info/?l=apache-modperl-dev&m=134552778831100&w=2

but there seemed to be some confusion about currency and intertwining, etc.

Can anyone attach a complete set of patches for the current trunk to
get me started with a good build for Apache 2.4?


I'm not sure if my patches [1] work with current trunk, but you should 
be able to port them easily I think. Those patches are created against 
the latest released mod_perl version.


[1] http://jkaluza.fedorapeople.org/mod_perl


Thanks.

Best regards,

-Tom

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




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

  1   2   >