Re: early perl startup in vhost on win32

2003-10-23 Thread Steve Hay
Stas Bekman wrote:

Steve, Randy, please try the current cvs (just cvs up + make, no need 
to rebuild from scratch). I have finally been able to solve the 
segfault with the short config Steve presented. I hope that it solves 
the problem for you as well. If it does, please try again with the 
vhost patch that was failing before.

I moved quite a few things in mod_perl.c, but the only real change was 
adding:

  +#ifdef USE_ITHREADS
  +/* after other parent perls were started in vhosts, make sure that
  + * the context is set to the base_perl */
  +PERL_SET_CONTEXT(base_perl);
  +#endif
after setting up vhosts, without which, PerlLoadModule in the main 
server was segfaulting for me. 
The good news: The short configuration file that I posted now works for 
me too (both the -t test and actually starting up the server).

The bad news: The vhost tests still fail as before :(

Here's a backtrace of the crash:

=
VMem::Free(void * 0x0123d68c) line 208 + 3 bytes
CPerlHost::Free(void * 0x0123d68c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x012916e4, void * 0x0123d68c) line 302
Perl_safesysfree(void * 0x0123d68c) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002644c4, sv * 0x009244c0) line 5198 + 13 
bytes
Perl_sv_replace(interpreter * 0x002644c4, sv * 0x009244c0, sv * 
0x012845d4) line 5046 + 13 bytes
Perl_leave_scope(interpreter * 0x002644c4, long 290) line 699 + 17 bytes
Perl_newATTRSUB(interpreter * 0x002644c4, long 290, op * 0x012b6558, op 
* 0x, op * 0x, op * 0x012b6578) line 4402 + 24 bytes
Perl_utilize(interpreter * 0x002644c4, int 1, long 290, op * 0x, 
op * 0x012b6714, op * 0x) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x002644c4) line 414 + 44 bytes
S_doeval(interpreter * 0x002644c4, int 0, op * * 0x, cv * 
0x, unsigned long 6796) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x002644c4) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x002644c4) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x002644c4) line 1434 + 13 bytes
S_call_body(interpreter * 0x002644c4, op * 0x0006f8b0, int 1) line 2193 
+ 13 bytes
Perl_eval_sv(interpreter * 0x002644c4, sv * 0x0128e3e0, long 2) line 
2253 + 15 bytes
modperl_require_module(interpreter * 0x002644c4, const char * 
0x008ae700, int 0) line 13 + 15 bytes
modperl_cmd_modules(cmd_parms_struct * 0x0006f9fc, void * 0x00854768, 
const char * 0x008ae700) line 122 + 15 bytes
invoke_cmd(const command_struct * 0x10025038, cmd_parms_struct * 
0x0006f9fc, void * 0x00854768, const char * 0x008ae590) line 800 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x008ae560, cmd_parms_struct * 
0x0006f9fc, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x008ae560, cmd_parms_struct * 
0x0006f9fc, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
modperl_config_insert(interpreter * 0x012ba014, server_rec * 0x0082c4d8, 
apr_pool_t * 0x0028acb0, apr_pool_t * 0x, int 150, char * 
0x, ap_conf_vector_t * 0x0082caa8, sv * 0x013a22d0) line 446 + 
18 bytes
modperl_config_insert_server(interpreter * 0x012ba014, server_rec * 
0x0082c4d8, sv * 0x013a22d0) line 464 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x012ba014, cv * 0x01304364) 
line 99 + 17 bytes
Perl_pp_entersub(interpreter * 0x012ba014) line 2817 + 16 bytes
Perl_runops_debug(interpreter * 0x012ba014) line 1434 + 13 bytes
S_call_body(interpreter * 0x012ba014, op * 0x0006fbe0, int 1) line 2193 
+ 13 bytes
Perl_eval_sv(interpreter * 0x012ba014, sv * 0x012c7af8, long 2) line 
2253 + 15 bytes
Perl_require_pv(interpreter * 0x012ba014, const char * 0x0088ca80) line 
2351 + 15 bytes
modperl_require_file(interpreter * 0x012ba014, const char * 0x0088ca80, 
int 1) line 30 + 13 bytes
modperl_config_apply_PerlRequire(server_rec * 0x0088bb88, 
modperl_config_srv_t * 0x0088c5a8, interpreter * 0x012ba014, apr_pool_t 
* 0x0028acb0) line 360 + 21 bytes
modperl_startup(server_rec * 0x0088bb88, apr_pool_t * 0x0028acb0) line 
320 + 21 bytes
modperl_init_vhost(server_rec * 0x0088bb88, apr_pool_t * 0x0028acb0, 
server_rec * 0x0082c4d8) line 393 + 13 bytes
modperl_init(server_rec * 0x0082c4d8, apr_pool_t * 0x0028acb0) line 457 
+ 17 bytes
modperl_hook_init(apr_pool_t * 0x0028acb0, apr_pool_t * 0x, 
apr_pool_t * 0x, server_rec * 0x0082c4d8) line 589 + 13 bytes
modperl_run() line 603 + 21 bytes
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void * 
0x00854768, const char * 0x00864db0) line 503
invoke_cmd(const command_struct * 0x100251b8, cmd_parms_struct * 
0x0006fec8, void * 0x00854768, const char * 0x00864db0) line 713 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x00864d90, cmd_parms_struct * 
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x00864d90, cmd_parms_struct * 
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
ap_process_config_tree(server_rec * 0x0082c4d8, ap_directive_t * 
0x00854a38, apr_pool_t *

Re: early perl startup in vhost on win32

2003-10-23 Thread Stas Bekman
Steve Hay wrote:
Stas Bekman wrote:

Steve, Randy, please try the current cvs (just cvs up + make, no need 
to rebuild from scratch). I have finally been able to solve the 
segfault with the short config Steve presented. I hope that it solves 
the problem for you as well. If it does, please try again with the 
vhost patch that was failing before.

I moved quite a few things in mod_perl.c, but the only real change was 
adding:

  +#ifdef USE_ITHREADS
  +/* after other parent perls were started in vhosts, make sure that
  + * the context is set to the base_perl */
  +PERL_SET_CONTEXT(base_perl);
  +#endif
after setting up vhosts, without which, PerlLoadModule in the main 
server was segfaulting for me. 


The good news: The short configuration file that I posted now works for 
me too (both the -t test and actually starting up the server).

The bad news: The vhost tests still fail as before :(
Thanks Steve.

Here's a backtrace of the crash:
This and your trace proves my suspicion that my solution just happened to work 
for the particular setup you had the crush with. But I think we are on the 
right track. We get the crash when the wrong perl is set as the current 
context. I will try to remove my recent solution and try to see why 
modperl_cmd_modules doesn't use the correct perl. This is the place where the 
problem comes from.

I'll try to cut down the conf file to the minimum that still crashes, 
and post a full trace then.
If it takes too much of your time, just let me play with it and I'll post a 
proper fix tomorrow, hopefully this time doing it right for all configs.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: early perl startup in vhost on win32

2003-10-23 Thread Steve Hay
Steve Hay wrote:

Stas Bekman wrote:

Steve, Randy, please try the current cvs (just cvs up + make, no need 
to rebuild from scratch). I have finally been able to solve the 
segfault with the short config Steve presented. I hope that it solves 
the problem for you as well. If it does, please try again with the 
vhost patch that was failing before.

I moved quite a few things in mod_perl.c, but the only real change 
was adding:

  +#ifdef USE_ITHREADS
  +/* after other parent perls were started in vhosts, make sure 
that
  + * the context is set to the base_perl */
  +PERL_SET_CONTEXT(base_perl);
  +#endif

after setting up vhosts, without which, PerlLoadModule in the main 
server was segfaulting for me. 


The bad news: The vhost tests still fail as before :(

I'll try to cut down the conf file to the minimum that still crashes, 
and post a full trace then. 
Here's a minimal conf file which still fails when running "perl t/TEST 
-start" (or even "C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t 
-f C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"):

=
LoadModule   perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName   localhost:8529
Listen   8529
ServerRoot   C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen   8530

 PerlOptions  +Parent
 
   1;
 

=
Here's the stack trace:

=
VMem::Free(void * 0x0093122c) line 208 + 3 bytes
CPerlHost::Free(void * 0x0093122c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x0093122c) line 302
Perl_safesysfree(void * 0x0093122c) line 143 + 26 bytes
Perl_av_extend(interpreter * 0x0092c12c, av * 0x0092cefc, long 4) line 
135 + 14 bytes
Perl_av_store(interpreter * 0x0092c12c, av * 0x0092cefc, long 4, sv * 
0x0095a9b4) line 315 + 17 bytes
Perl_av_push(interpreter * 0x0092c12c, av * 0x0092cefc, sv * 0x0095a9b4) 
line 542 + 29 bytes
Perl_newPMOP(interpreter * 0x0092c12c, long 31, long 0) line 2650 + 65 bytes
S_scan_pat(interpreter * 0x0092c12c, char * 0x00958012, long 31) line 
6353 + 15 bytes
Perl_yylex(interpreter * 0x0092c12c) line 3613 + 15 bytes
Perl_yyparse(interpreter * 0x0092c12c) line 1470 + 9 bytes
S_doeval(interpreter * 0x0092c12c, int 0, op * * 0x, cv * 
0x, unsigned long 19) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x0092c12c) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x0092c12c) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x0092c12c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0092c12c, op * 0x0006f0b4, int 0) line 2193 
+ 13 bytes
Perl_call_sv(interpreter * 0x0092c12c, sv * 0x0094a01c, long 6) line 
2111 + 15 bytes
S_call_list_body(interpreter * 0x0092c12c, cv * 0x0094a01c) line 4361 + 
15 bytes
Perl_call_list(interpreter * 0x0092c12c, long 11, av * 0x00949f8c) line 
4290 + 13 bytes
Perl_newATTRSUB(interpreter * 0x0092c12c, long 501, op * 0x0094dc04, op 
* 0x, op * 0x, op * 0x0094dc24) line 4365 + 23 bytes
Perl_utilize(interpreter * 0x0092c12c, int 1, long 501, op * 0x, 
op * 0x0093fb38, op * 0x0093fb1c) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x0092c12c) line 414 + 44 bytes
S_doeval(interpreter * 0x0092c12c, int 0, op * * 0x, cv * 
0x, unsigned long 17) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x0092c12c) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x0092c12c) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x0092c12c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0092c12c, op * 0x0006f600, int 0) line 2193 
+ 13 bytes
Perl_call_sv(interpreter * 0x0092c12c, sv * 0x00942720, long 6) line 
2111 + 15 bytes
S_call_list_body(interpreter * 0x0092c12c, cv * 0x00942720) line 4361 + 
15 bytes
Perl_call_list(interpreter * 0x0092c12c, long 5, av * 0x009426f0) line 
4290 + 13 bytes
Perl_newATTRSUB(interpreter * 0x0092c12c, long 292, op * 0x0093fc7c, op 
* 0x, op * 0x, op * 0x0093fc9c) line 4365 + 23 bytes
Perl_utilize(interpreter * 0x0092c12c, int 1, long 292, op * 0x, 
op * 0x0093fe78, op * 0x0093fe14) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x0092c12c) line 414 + 44 bytes
S_doeval(interpreter * 0x0092c12c, int 0, op * * 0x, cv * 
0x, unsigned long 2) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x0092c12c) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x0092c12c) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x0092c12c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0092c12c, op * 0x0006faf8, int 1) line 2193 
+ 13 bytes
Perl_eval_sv(interpreter * 0x0092c12c, sv * 0x00942624, long 2) line 
2253 + 15 bytes
modperl_require_module(interpreter * 0x0092c12c, const char * 
0x00851470, int 0) line 13 + 15 bytes
modperl_mgv_resolve(interpreter * 0x0092c12c, modperl_handler_t * 
0x00851518, apr_pool_t * 0x0028a9f8, const char * 0x00851470, int 0) 
line 267 + 15 bytes
modperl_handler_resolve(interpreter * 0x0092c12c, modperl_handler_t * * 
0x0006fcb8, apr_pool_t * 0

Re: early perl startup in vhost on win32

2003-10-23 Thread Stas Bekman
Stas Bekman wrote:

This and your trace proves my suspicion that my solution just happened 
to work for the particular setup you had the crush with. But I think we 
are on the right track. We get the crash when the wrong perl is set as 
the current context. I will try to remove my recent solution and try to 
see why modperl_cmd_modules doesn't use the correct perl. This is the 
place where the problem comes from.
Please try this patch:

Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.201
diff -u -r1.201 mod_perl.c
--- src/modules/perl/mod_perl.c 23 Oct 2003 05:57:46 -  1.201
+++ src/modules/perl/mod_perl.c 23 Oct 2003 08:30:45 -
@@ -458,13 +458,6 @@
 exit(1); /*XXX*/
 }
 }
-
-#ifdef USE_ITHREADS
-/* after other parent perls were started in vhosts, make sure that
- * the context is set to the base_perl */
-PERL_SET_CONTEXT(base_perl);
-#endif
-
 }
 #ifdef USE_ITHREADS
Index: src/modules/perl/modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.48
diff -u -r1.48 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c  16 Sep 2003 01:57:27 -  1.48
+++ src/modules/perl/modperl_cmd.c  23 Oct 2003 08:30:45 -
@@ -116,6 +116,7 @@
 #ifdef USE_ITHREADS
 /* XXX: .htaccess support cannot use this perl with threaded MPMs */
 dTHXa(scfg->mip->parent->perl);
+PERL_SET_CONTEXT(my_perl);
 #endif
 MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -145,6 +146,7 @@
 #ifdef USE_ITHREADS
 /* XXX: .htaccess support cannot use this perl with threaded MPMs */
 dTHXa(scfg->mip->parent->perl);
+PERL_SET_CONTEXT(my_perl);
 #endif
 MP_TRACE_d(MP_FUNC, "load PerlRequire %s\n", arg);
@@ -381,6 +383,7 @@
 #ifdef USE_ITHREADS
 /* XXX: .htaccess support cannot use this perl with threaded MPMs */
 aTHX = scfg->mip->parent->perl;
+PERL_SET_CONTEXT(scfg->mip->parent->perl);
 #endif
 /* data will be set by a  section */

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: early perl startup in vhost on win32

2003-10-23 Thread Steve Hay
Stas Bekman wrote:

Stas Bekman wrote:

This and your trace proves my suspicion that my solution just 
happened to work for the particular setup you had the crush with. But 
I think we are on the right track. We get the crash when the wrong 
perl is set as the current context. I will try to remove my recent 
solution and try to see why modperl_cmd_modules doesn't use the 
correct perl. This is the place where the problem comes from.


Please try this patch: 
Trying your patch with the short conf file that I posted a few minutes 
ago, the -t test now passes "syntax OK", but the server still won't start.

Running "C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t -f 
C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS" 
still crashes at the same "Free to wrong pool" place in the code, 
although its much earlier and I don't see that error message in the 
console now.  Here's the stack trace:

=
VMem::Free(void * 0x009fa3ac) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fa3ac) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fa3ac) line 302
Perl_safesysfree(void * 0x009fa3ac) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13 
bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 144 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x00924e80) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00851230) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=

and the mp2 trace:

=

C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t 
-f C:/Tem
p/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
mod_perl trace flags dump:

c On  (configuration for directive handlers)

d On  (directive processing)

e Off (environment variables)

f Off (filters)

g On  (Perl runtime interaction)

h On  (handlers)

i On  (interpreter pool management)

m On  (memory allocations)

o On  (I/O)

s On  (perl sections)

t Off (benchmark-ish timings)

mod_perl.c:515: mod_perl globals are configured

modperl_global.c:88: init pconf

modperl_global.c:88: init threaded_mpm

modperl_global.c:88: init server_rec

modperl_config.c:187: p=0x28aa50, s=0x82c4d8, virtual=0

modperl_config.c:137: 0x84fd38

modperl_config.c:137: 0x8509e8

modperl_config.c:121: 0x850ca8

modperl_config.c:187: p=0x28aa50, s=0x850670, virtual=1

modperl_cmd.c:259: arg = +Parent

MpSrv flags dump (localhost):

Clone Off

Parent Off

Enable On

Autoload Off

MergeHandlers Off

Authz On

Authen On

PostConfig On

ChildExit On

OutputFilter On

Response On

Log On

PostReadRequest On

OpenLogs On

PreConnection On

MapToStorage On

ProcessConnection On

ChildInit On

Fixup On

HeaderParser On

InputFilter On

Type On

Trans On

Cleanup On

Access On

Unset On

mod_perl.c:235: starting the parent perl for the base server

modperl_config_srv_argv_init =>

  0 = Apache.exe

  1 = -e;0

modperl_interp.c:232: server=localhost:8529

modperl_interp.c:107: 0x928af8

mod_perl.c:304: constructed interpreter=0x2643ec

mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8

MpSrv flags dump ((null)):

Clone Off

Parent On

Enable On

Autoload Off

MergeHandlers Off

Authz On

Authen On

PostConfig On

ChildExit On

OutputFilter On

Response On

Log On

PostReadRequest On

OpenLogs On

PreConnection On

MapToStorage On

ProcessConnection On

ChildInit On

Fixup On

HeaderParser On

InputFilter On

Type On

Trans On

Cleanup On

Access On

Unset On

mod_perl.c:239: starting the parent perl for vhost (null):8530

modperl_config_srv_argv_init =>

  0 = Apache.exe

  1 = -e;0

modperl_interp.c:232: server=(null):8530

modperl_interp.c:107: 0x93eef0

mod_perl.c:304: constructed interpreter=0x92c25c

mod_perl.c:394: created parent interpreter for VirtualHost (null):8530

mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8

mod_perl.c:375: server (null):8530 already initialized

modperl_handler.c:23: [2644/1936] new handler Apache::PerlSections

modperl_util.c:160: sv_setref_pv(Apache::CmdParms, 0x6fec8)

modperl_handler.c:75: dup handler Apache::PerlSections

modperl_handler.c:23: [2644/1936] new handler Apache::PerlSections

MpHandler flags dump (Apache::PerlSections):

Parsed Off

Method Off

Object Off

Anon Off

Autoload Off

Dynamic Off

Fake Off

modperl_handler.c:52: [2644/1936 (null):8530] handler 
Apache::PerlSections was n
ot compiled at startup, attempting to resolve using current pool 0x28aa50

modperl_mgv.c:264: package Apache::PerlSections not defined, attempting 
to load


[mp2] Installation report - mod_perl 1.99_10 on Slackware 9.1

2003-10-23 Thread Enrico Sorcinelli
Hi all,

just for statistics informations, I've successfully built (from sources, w/gcc
3.2.3) Perl/5.8.1, Apache/2.0.47 and mod_perl/1.99_10 on Slackware 9.1 (2.4.22,
Intel)

by

- Enrico



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: early perl startup in vhost on win32

2003-10-23 Thread Stas Bekman
Steve Hay wrote:

Here's a minimal conf file which still fails when running "perl t/TEST 
-start" (or even "C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t 
-f C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"):

=
LoadModule   perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName   localhost:8529
Listen   8529
ServerRoot   C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen   8530

 PerlOptions  +Parent
 
   1;
 

The problem with this config, is that you don't handle @INC to use the fresh 
build. So it loads stuff from the previously installed system-wide mod_perl. 
Probably it doesn't affect the outcome, but please set it right (e.g. nuke the 
preinstalled things so it won't load them). You need something like this:


 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib/Apache2
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch/Apache2
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/lib
 PerlOptions  +Parent
 
   1;
 

In any case it works fine on linux.

modperl_mgv.c:264: package Apache::PerlSections not defined, attempting 
to load

Free to wrong pool 262770 not 925938.
The problems is this: perl uses dTHX; calls in some functions which disregards 
the passed context and retrieves the globally stored context. Which means that 
*every* time we select an interpreter, we must call PERL_SET_CONTEXT() and 
pass to it the parent interpreter of the currently used pool :(

In particular for your and mine segfaults the Perl_safesysfree() call is the 
one that uses dTHX and gets the wrong context at times, and then it crashes.

This short conf file is OK if I remove the "+Parent" line.

I can also "fix" it by removing the ... section, but 
trying the same trick with the full vhost test setup (commenting out the 
appropriate add_config() call from t/htdocs/vhost/startup.pl) doesn't 
fix that :(

I notice that the ... section in that startup.pl file is 
commented "this used to have problems on win32".  Looks like it still does?
Probably it just moved to a different place. Most likely it's the same 
problem, I have explained above.

I also notice that the short conf file gives this syntax error if I 
change the  to :

   Syntax error on line 10 of C:/Temp/modperl-2.0/t/conf/httpd.conf:
directive missing closing '>'
You need the current httpd cvs for  to work. Unfortunately it seems that 
 Phillipe's fix won't make it to 2.0.48 (which should be released shortly), 
but only 2.0.49 :(

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: early perl startup in vhost on win32

2003-10-23 Thread Stas Bekman
Stas Bekman wrote:
Steve Hay wrote:

Here's a minimal conf file which still fails when running "perl t/TEST 
-start" (or even "C:\apache2\bin\Apache.exe -t -d 
C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf 
-DAPACHE2 -DPERL_USEITHREADS"):

=
LoadModule   perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName   localhost:8529
Listen   8529
ServerRoot   C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen   8530

 PerlOptions  +Parent
 
   1;
 



The problem with this config, is that you don't handle @INC to use the 
fresh build. So it loads stuff from the previously installed system-wide 
mod_perl. Probably it doesn't affect the outcome, but please set it 
right (e.g. nuke the preinstalled things so it won't load them). You 
need something like this:


 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib/Apache2
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch/Apache2
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch
 PerlSwitches -I/home/stas/apache.org/mp2-vhost/lib
 PerlOptions  +Parent
 
   1;
 

In any case it works fine on linux.

modperl_mgv.c:264: package Apache::PerlSections not defined, 
attempting to load

Free to wrong pool 262770 not 925938.


The problems is this: perl uses dTHX; calls in some functions which 
disregards the passed context and retrieves the globally stored context. 
Which means that *every* time we select an interpreter, we must call 
PERL_SET_CONTEXT() and pass to it the parent interpreter of the 
currently used pool :(

In particular for your and mine segfaults the Perl_safesysfree() call is 
the one that uses dTHX and gets the wrong context at times, and then it 
crashes.
I think if you build perl without using perl's malloc this particular segfault 
will go away. Certainly it's not a good solution.

__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: early perl startup in vhost on win32

2003-10-23 Thread Stas Bekman
Steve Hay wrote:
Stas Bekman wrote:

Stas Bekman wrote:

This and your trace proves my suspicion that my solution just 
happened to work for the particular setup you had the crush with. But 
I think we are on the right track. We get the crash when the wrong 
perl is set as the current context. I will try to remove my recent 
solution and try to see why modperl_cmd_modules doesn't use the 
correct perl. This is the place where the problem comes from.


Please try this patch: 


Trying your patch with the short conf file that I posted a few minutes 
ago, the -t test now passes "syntax OK", but the server still won't start.

Running "C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t -f 
C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS" 
still crashes at the same "Free to wrong pool" place in the code, 
although its much earlier and I don't see that error message in the 
console now.  Here's the stack trace:

=
VMem::Free(void * 0x009fa3ac) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fa3ac) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fa3ac) line 302
Perl_safesysfree(void * 0x009fa3ac) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13 
bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13 
bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 144 + 9 bytes
So here we get perl_destruct calling some functions that rely on the right 
context. I don't get this problem, but please try this patch:

Index: src/modules/perl/mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.201
diff -u -r1.201 mod_perl.c
--- src/modules/perl/mod_perl.c 23 Oct 2003 05:57:46 -  1.201
+++ src/modules/perl/mod_perl.c 23 Oct 2003 23:28:59 -
@@ -458,13 +458,6 @@
 exit(1); /*XXX*/
 }
 }
-
-#ifdef USE_ITHREADS
-/* after other parent perls were started in vhosts, make sure that
- * the context is set to the base_perl */
-PERL_SET_CONTEXT(base_perl);
-#endif
-
 }
 #ifdef USE_ITHREADS
Index: src/modules/perl/modperl_cmd.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.49
diff -u -r1.49 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c  20 Oct 2003 17:44:48 -  1.49
+++ src/modules/perl/modperl_cmd.c  23 Oct 2003 23:28:59 -
@@ -116,6 +116,11 @@
 #ifdef USE_ITHREADS
 /* XXX: .htaccess support cannot use this perl with threaded MPMs */
 dTHXa(scfg->mip->parent->perl);
+PERL_SET_CONTEXT(scfg->mip->parent->perl);
+MP_TRACE_d(MP_FUNC,
+   "using mip=0x%lx, my_perl=0x%lx, PL_curinterp=0x%lx\n",
+   (PerlInterpreter *)scfg->mip->parent->perl, my_perl,
+   PERL_GET_CONTEXT);
 #endif
 MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -145,6 +150,7 @@
 #ifdef USE_ITHREADS
 /* XXX: .htaccess support cannot use this perl with threaded MPMs */
 dTHXa(scfg->mip->parent->perl);
+PERL_SET_CONTEXT(scfg->mip->parent->perl);
 #endif
 MP_TRACE_d(MP_FUNC, "load PerlRequire %s\n", arg);
@@ -381,6 +387,7 @@
 #ifdef USE_ITHREADS
 /* XXX: .htaccess support cannot use this perl with threaded MPMs */
 aTHX = scfg->mip->parent->perl;
+PERL_SET_CONTEXT(scfg->mip->parent->perl);
 #endif
 /* data will be set by a  section */
Index: src/modules/perl/modperl_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl.c,v
retrieving revision 1.19
diff -u -r1.19 modperl_perl.c
--- src/modules/perl/modperl_perl.c 18 Oct 2003 21:01:30 -  1.19
+++ src/modules/perl/modperl_perl.c 23 Oct 2003 23:28:59 -
@@ -135,12 +135,14 @@
 {
 dTHXa(perl);
+PERL_SET_CONTEXT(perl);
 if ((module_commands = modperl_module_config_table_get(aTHX_ FALSE))) {
 modperl_svptr_table_destroy(aTHX_ module_commands);
 }
 }
+PERL_SET_CONTEXT(perl);
 perl_destruct(perl);
 /* XXX: big bug in 5.6.1 fixed in 5.7.2+



Using the full vhost test setup I do still see the "Free to wrong pool" 
message as before, but the stack trace is still shorter.  Here it is:

=
VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13 
bytes
Perl_sv_free(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5342 + 13 
bytes
Perl_av_undef(interpreter * 0x012aff6c, av * 0x013a1ae8) line 498 + 32 
by

[ANNOUNCE] Apache-Test 1.05

2003-10-23 Thread Geoffrey Young
The URL

http://perl.apache.org/~geoff/Apache-Test-1.05.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/G/GE/GEOFF/Apache-Test-1.05.tar.gz
  size: 92764 bytes
   md5: 53654c4e47240d2494db010a0a15751d
Changes since 1.04:

core scanning changes [Stas]
- speedup by not chdir'ing into subdirs
- an optional scanning of only t/ dir (used by TestSmoke)
- don't scan on win32, since it has no core files
in the autogenerated t/conf/modperl_inc.pl don't add the project/lib
directory, unless a special env var APACHE_TEST_LIVE_DEV is true. This
is because some projects change things in project/blib and pushing
project/lib on top of @INC, breaks the test suite for them [Stas]
TestRun was using httpd.pid file to ensure that the server is killed
before starting it, if the file existed. This was a problem on win32
platforms, where a process scheduler tries to re-use the pids that
were just freed, which may have killed a valid process which is not
even Apache.exe. So we try not to rely on that file, and if the server
wasn't properly stopped and still running, users will learn about
that, since the port will be busy, and Apache will fail to
start. Users have to kill it manually. TestSmoke is no longer using an
explicit kill `cat httpd.pid` to stop Apache, but delegates the
stopping procedure to TestRun [Steve Hay, Randy Kobes]
use IPC::Run3 in Apache::TestSmoke to run t/TEST commands,
so as t/SMOKE can be used on Win32 [Stas, Steve Hay, Randy Kobes]
place mod_perl-specific directives in  containers
within httpd.conf, allowing the default server to start if
mod_perl isn't present.  [Geoffrey Young]
fix t/request.t to get /index.html, instead of / since not everybody
uses mod_dir [Steve Piner <[EMAIL PROTECTED]>]
when testing whether Apache started as root and running under 'nobody'
or alike, will be able to -r/-w/-x in t/ use 'su' instead of 'sudo',
the latter is not available on all unix platforms. [Vivek Khera
<[EMAIL PROTECTED]>]
in the Apache/test.pm nuke code s/PERLRUN/FULLPERL/ as older MakeMaker
doesn't have the PERLRUN target [Stas]
Apache 1.3 servers now run in standard prefork mode under
normal operation.  single server mode (httpd -X) was replaced
with MaxClients set to 1 by default.  [Geoffrey Young]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]