Re: segfault in worker mpm
I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... -- __ 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: [mp2] NetBSD-2.0_RC1 httpd-2.0.52 modperl-1.99_17-dev configure error
"Philippe M. Chiasson" <[EMAIL PROTECTED]> wrote on 05.10.2004 21:50:11:
>
> That's a slightly misleading error message, can you try again with this
> smallish patch? (it will correctly report the include directory it
didn't
> find)
>
> And just to be clear, you configured & build httpd in
> /home/mgorb/mp-test/httpd-2.0
> or did you do that elsewhere and just installed httpd there (--
> prefix=/home/mgorb/mp-test/httpd-2.0) ?
>
> Index: lib/Apache/Build.pm
> ===
> RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v
> retrieving revision 1.186
> diff -u -I$Id -r1.186 Build.pm
> --- lib/Apache/Build.pm 26 Sep 2004 07:06:23 - 1.186
> +++ lib/Apache/Build.pm 5 Oct 2004 17:48:16 -
> @@ -82,7 +82,7 @@
> my $include_dir = $self->apxs(-q => 'INCLUDEDIR');
>
> unless (-d $include_dir) {
> -return "include/ directory not found in $prefix";
> +return "$include_dir directory not found in $prefix";
> }
>
> return '';
>
>
applied the above, here is the result:
$ $HOME/mp-test/perl/bin/perl Makefile.PL \
> MP_AP_PREFIX=$HOME/mp-test/httpd-2.0 \
> MP_CCOPTS="-march=pentium2 -O2"
Reading Makefile.PL args from @ARGV
MP_AP_PREFIX = /home/mgorb/mp-test/httpd-2.0
MP_CCOPTS = -march=pentium2 -O2
[ error] invalid MP_AP_PREFIX: directory not found in
/home/mgorb/mp-test/httpd-2.0
$
httpd is build in /home/mgorb/mp-test/src/httpd-2.0.52 and installed here
/home/mgorb/mp-test/httpd-2.0
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/apr/bucket is dumping core on me
"Philippe M. Chiasson" <[EMAIL PROTECTED]> writes:
[...]
> #2 0x0021b45c in apr_bucket_alloc_create_ex (allocator=0x0) at
> apr_buckets_alloc.c:67
> #3 0x0021b405 in apr_bucket_alloc_create (p=0x9353f70) at
APU_DECLARE_NONSTD(apr_bucket_alloc_t *) apr_bucket_alloc_create(apr_pool_t *p)
{
apr_allocator_t *allocator = apr_pool_allocator_get(p);
apr_bucket_alloc_t *list;
#if APR_POOL_DEBUG
/* may be NULL for debug mode. */
if (allocator == NULL) {
if (apr_allocator_create(&allocator) != APR_SUCCESS) {
abort();
}
}
#endif
list = apr_bucket_alloc_create_ex(allocator);
list->pool = p;
apr_pool_cleanup_register(list->pool, list, alloc_cleanup,
apr_pool_cleanup_null);
return list;
}
Is it somehow possible that apr was compiled with
APR_POOL_DEBUG defined, but apr-util was not?
--
Joe Schaefer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: segfault in worker mpm
Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
> > Stas Bekman <[EMAIL PROTECTED]> writes:
> > [...]
> >
> >>Joe, this still needs to applied? But please make sure that you
> >>restore the context when you are done with it. Look at the other
> >>places where this is done (grep for SET_CONTEXT).
> > AFAICT the only place where the context is "localized" is in modperl_cmd.c:
> > #define MP_PERL_DECLARE_CONTEXT \
> > PerlInterpreter *orig_perl; \
> > pTHX;
> > /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> > #define MP_PERL_OVERRIDE_CONTEXT\
> > orig_perl = PERL_GET_CONTEXT; \
> > aTHX = scfg->mip->parent->perl; \
> > PERL_SET_CONTEXT(aTHX);
> > #define MP_PERL_RESTORE_CONTEXT \
> > PERL_SET_CONTEXT(orig_perl);
> > Is that what you have in mind here?
>
> Exactly.
Here's the patch- unfortunately it doesn't quite work...
I get a similar segfault when the perl handler runs
(this patch only affects modperl_module_config_merge).
Index: src/modules/perl/modperl_module.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v
retrieving revision 1.17
diff -u -r1.17 modperl_module.c
--- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 - 1.17
+++ src/modules/perl/modperl_module.c 7 Oct 2004 18:50:57 -
@@ -169,6 +169,7 @@
#ifdef USE_ITHREADS
modperl_interp_t *interp;
dTHX;
+PerlInterpreter *orig_perl = aTHX;
#endif
/* if the module is loaded in vhost, base==NULL */
@@ -185,6 +186,7 @@
#ifdef USE_ITHREADS
interp = modperl_interp_pool_select(p, s);
aTHX = interp->perl;
+PERL_SET_CONTEXT(aTHX);
#endif
table = modperl_module_config_table_get(aTHX_ TRUE);
@@ -239,7 +241,7 @@
if (!is_startup) {
modperl_module_config_obj_cleanup_register(aTHX_ p, table, mrg);
}
-
+PERL_SET_CONTEXT(orig_perl);
return (void *)mrg;
}
~>
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1099901296 (LWP 5305)]
0x002a967c286d in Perl_safesysmalloc (size=96) at util.c:75
(gdb) up
#1 0x002a967f01d7 in Perl_sv_upgrade (my_perl=0x14204c0, sv=0x1490250, mt=13)
at sv.c:1506
(gdb)
#2 0x002a96764286 in Perl_gv_init (my_perl=0x14204c0, gv=0x1490250,
stash=0x2fa2720, name=0x2a968b2e45 "DESTROY", len=7, multi=1) at gv.c:112
(gdb) #3 0x002a96764807 in Perl_gv_fetchmeth (my_perl=0x14204c0, stash=0x2fa2720,
name=0x2a968b2e45 "DESTROY", len=7, level=0) at gv.c:225
(gdb)
#4 0x002a96764e47 in Perl_gv_fetchmeth_autoload (my_perl=0x14204c0,
stash=0x2fa2720, name=0x2a968b2e45 "DESTROY", len=7, level=0) at gv.c:338
(gdb)
#5 0x002a967681db in Perl_Gv_AMupdate (my_perl=0x14204c0, stash=0x2fa2720)
at gv.c:1363
(gdb)
#6 0x002a96801108 in Perl_sv_bless (my_perl=0x14204c0, sv=0x1490230,
stash=0x2fa2720) at sv.c:7894
(gdb)
#7 0x002a96800e34 in Perl_newSVrv (my_perl=0x14204c0, rv=0x1490230,
classname=0x2a96615908 "Apache::RequestRec") at sv.c:7748
(gdb)
#8 0x002a96800ea6 in Perl_sv_setref_pv (my_perl=0x14204c0, rv=0x1490230,
classname=0x2a96615908 "Apache::RequestRec", pv=0x274a6a8) at sv.c:7779
(gdb)
#9 0x002a965f9576 in modperl_ptr2obj (my_perl=0x14204c0,
classname=0x2a96615908 "Apache::RequestRec", ptr=0x274a6a8)
at modperl_util.c:192
(gdb)
#10 0x002a965f7d99 in modperl_handler_make_args (my_perl=0x14204c0,
avp=0x418f2158) at modperl_handler.c:238
(gdb)
#11 0x002a965f6c23 in modperl_callback_run_handlers (idx=6, type=4,
r=0x274a6a8, c=0x0, s=0x5a0b80, pconf=0x0, plog=0x0, ptemp=0x0,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:237
--
Joe Schaefer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
t/modules/proxy.t failure with 2.1
hi all... just FYI, 2.1 is failing t/modules/proxy.t with a 404. I've spent some time this afternoon trying to see what (of importance) has changed in between 2.0 and HEAD but I can't see where it is at the moment. so, if anyone has been following proxy development of late and knows what the issue is, feel free to jump in. otherwise, just know that I'm working on it. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/apr/bucket is dumping core on me
Joe Schaefer wrote:
"Philippe M. Chiasson" <[EMAIL PROTECTED]> writes:
[...]
#2 0x0021b45c in apr_bucket_alloc_create_ex (allocator=0x0) at
apr_buckets_alloc.c:67
#3 0x0021b405 in apr_bucket_alloc_create (p=0x9353f70) at
APU_DECLARE_NONSTD(apr_bucket_alloc_t *) apr_bucket_alloc_create(apr_pool_t *p)
{
apr_allocator_t *allocator = apr_pool_allocator_get(p);
apr_bucket_alloc_t *list;
#if APR_POOL_DEBUG
/* may be NULL for debug mode. */
if (allocator == NULL) {
if (apr_allocator_create(&allocator) != APR_SUCCESS) {
abort();
}
}
#endif
list = apr_bucket_alloc_create_ex(allocator);
list->pool = p;
apr_pool_cleanup_register(list->pool, list, alloc_cleanup,
apr_pool_cleanup_null);
return list;
}
Is it somehow possible that apr was compiled with
APR_POOL_DEBUG defined, but apr-util was not?
I thought it might be something like that, so I rebuilt a clean httpd-2.0-HEAD
worker as
of a few minutes ago and rebuilt.
#0 0x008bf65c in allocator_alloc (allocator=0x0, size=8192) at apr_pools.c:188
#1 0x008bf617 in apr_allocator_alloc (allocator=0x0, size=8168) at apr_pools.c:370
#2 0x0053745c in apr_bucket_alloc_create_ex (allocator=0x0) at apr_buckets_alloc.c:67
#3 0x00537405 in apr_bucket_alloc_create (p=0x96d8448) at apr_buckets_alloc.c:52
#4 0x004fa6fd in XS_APR__Bucket_alloc_create (my_perl=0xa2a1aa8, cv=0x9db8f0c) at
Bucket.c:66
#5 0x00373709 in Perl_pp_entersub (my_perl=0xa2a1aa8) at pp_hot.c:2857
#6 0x0034f24f in Perl_runops_debug (my_perl=0xa2a1aa8) at dump.c:1442
#7 0x002f59b4 in S_call_body (my_perl=0xa2a1aa8, myop=0xf598e720, is_eval=0) at
perl.c:2288
#8 0x002f54e8 in Perl_call_sv (my_perl=0xa2a1aa8, sv=0xad45170, flags=4) at
perl.c:2206
#9 0x00fa4852 in modperl_callback (my_perl=0xa2a1aa8, handler=0xa2e05b0, p=0x9d3b2b0,
r=0x97d5ca8, s=0xaca44f0, args=0x96929f8)
at modperl_callback.c:115
#10 0x00fa511f in modperl_callback_run_handlers (idx=6, type=4, r=0x97d5ca8, c=0x0,
s=0xaca44f0, pconf=0x0, plog=0x0, ptemp=0x0,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:276
#11 0x00fa5368 in modperl_callback_per_dir (idx=6, r=0x97d5ca8,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:364
#12 0x00f9dfec in modperl_response_handler_run (r=0x97d5ca8, finish=1) at
mod_perl.c:909
#13 0x00f9e102 in modperl_response_handler (r=0x97d5ca8) at mod_perl.c:949
#14 0x0806c394 in ap_run_handler (r=0x97d5ca8) at config.c:151
#15 0x0806cab1 in ap_invoke_handler (r=0x97d5ca8) at config.c:358
#16 0x0806777f in ap_process_request (r=0x97d5ca8) at http_request.c:246
#17 0x080611fc in ap_process_http_connection (c=0x9ef61b0) at http_core.c:250
#18 0x080773f4 in ap_run_process_connection (c=0x9ef61b0) at connection.c:42
#19 0x080778ae in ap_process_connection (c=0x9ef61b0, csd=0x9dce0f8) at
connection.c:175
#20 0x08068bbf in process_socket (p=0xa3446b0, sock=0x9dce0f8, my_child_num=0,
my_thread_num=1, bucket_alloc=0xa79cff8)
at worker.c:520
#21 0x0806935d in worker_thread (thd=0x9782c08, dummy=0x9a22cf8) at worker.c:834
#22 0x008b9cab in dummy_worker (opaque=0x9782c08) at thread.c:88
#23 0x00d5e98c in start_thread () from /lib/tls/libpthread.so.0
Funny thing is that when I look at apr_buckets_alloc.c:67, seems you are looking at
apr-util HEAD,
and not at the APU_0_9_BRANCH.
--
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/apr/bucket is dumping core on me
"Philippe M. Chiasson" <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: [...] > > Is it somehow possible that apr was compiled with APR_POOL_DEBUG > > defined, but apr-util was not? > > I thought it might be something like that, so I rebuilt a clean > httpd-2.0-HEAD worker as of a few minutes ago and rebuilt. With or without --enable-pool-debug? (config.nice will tell you). [...] > Funny thing is that when I look at apr_buckets_alloc.c:67, seems you > are looking at apr-util HEAD, and not at the APU_0_9_BRANCH. True, but AFAICT the difference is only the new APR_POOL_DEBUG section. -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/apr/bucket is dumping core on me
Joe Schaefer wrote: "Philippe M. Chiasson" <[EMAIL PROTECTED]> writes: Joe Schaefer wrote: [...] Is it somehow possible that apr was compiled with APR_POOL_DEBUG defined, but apr-util was not? I thought it might be something like that, so I rebuilt a clean httpd-2.0-HEAD worker as of a few minutes ago and rebuilt. With or without --enable-pool-debug? (config.nice will tell you). Without as far as I can see, the only debug flag being turned on is --enable-debug [...] Funny thing is that when I look at apr_buckets_alloc.c:67, seems you are looking at apr-util HEAD, and not at the APU_0_9_BRANCH. True, but AFAICT the difference is only the new APR_POOL_DEBUG section. -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: t/apr/bucket is dumping core on me
"Philippe M. Chiasson" <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: > > "Philippe M. Chiasson" <[EMAIL PROTECTED]> writes: > > > >>Joe Schaefer wrote: > > [...] > > > >>>Is it somehow possible that apr was compiled with APR_POOL_DEBUG > >>>defined, but apr-util was not? > >> > >>I thought it might be something like that, so I rebuilt a clean > >>httpd-2.0-HEAD worker as of a few minutes ago and rebuilt. > > With or without --enable-pool-debug? (config.nice will tell you). > > Without as far as I can see, the only debug flag being turned on is > --enable-debug I'm not able to reproduce it with the 2.0.52 release. Here's my config.nice: ! /bin/sh # # Created by configure "../../httpd-2.0.52/configure" \ "--with-mpm=worker" \ "--enable-so" \ "--enable-mods-shared=all" \ "--prefix=/home/smoke/apache/httpd-2.0.52-worker" \ "--enable-debug" \ "$@" However if I change the last line from --enable-debug to --enable-pool-debug, the modperl-2.0 tests cannot seem to get past server startup. But I can get the same backtrace as you with t/TEST -no-httpd t/apr-ext/bucket.t so I still suspect --enable-pool-debug is somewherebehind this. Maybe there's an older installed libapr0 that's sneaking into your httpd/modperl build? -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: segfault in worker mpm
Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. -- __ 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: segfault in worker mpm
Stas Bekman wrote: Philippe M. Chiasson wrote: Stas Bekman wrote: I did some binary search and found that: mp2-20040922 - no core mp2-20040923 - core So we need to diff these two checkouts... For a start, I've got these changes exposed in between those 2 dates: http://www.apache.org/~gozer/mp2/2004-09-22+23/ That's a handy output. I'll try applying each separately to see which one was the trigger. For some reason, your output doesn't match mine. for me the difference between 22nd and 23 starts from 3428 [1] and goes into the next day, which is not included in your output: [1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch but I think I'm getting there -- __ 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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: [...] Joe, this still needs to applied? But please make sure that you restore the context when you are done with it. Look at the other places where this is done (grep for SET_CONTEXT). AFAICT the only place where the context is "localized" is in modperl_cmd.c: #define MP_PERL_DECLARE_CONTEXT \ PerlInterpreter *orig_perl; \ pTHX; /* XXX: .htaccess support cannot use this perl with threaded MPMs */ #define MP_PERL_OVERRIDE_CONTEXT\ orig_perl = PERL_GET_CONTEXT; \ aTHX = scfg->mip->parent->perl; \ PERL_SET_CONTEXT(aTHX); #define MP_PERL_RESTORE_CONTEXT \ PERL_SET_CONTEXT(orig_perl); Is that what you have in mind here? Exactly. Here's the patch- unfortunately it doesn't quite work... I get a similar segfault when the perl handler runs (this patch only affects modperl_module_config_merge). Index: src/modules/perl/modperl_module.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v retrieving revision 1.17 diff -u -r1.17 modperl_module.c --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 - 1.17 +++ src/modules/perl/modperl_module.c 7 Oct 2004 18:50:57 - @@ -169,6 +169,7 @@ #ifdef USE_ITHREADS modperl_interp_t *interp; dTHX; +PerlInterpreter *orig_perl = aTHX; #endif I wonder why do we have dTHX there. It's most likely the cause of the problem, as essentially it grabs the latest context that was used recently. It should be: Index: src/modules/perl/modperl_module.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v retrieving revision 1.17 diff -u -r1.17 modperl_module.c --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 - 1.17 +++ src/modules/perl/modperl_module.c 8 Oct 2004 02:04:48 - @@ -168,7 +168,7 @@ #ifdef USE_ITHREADS modperl_interp_t *interp; -dTHX; +pTHX; #endif /* if the module is loaded in vhost, base==NULL */ need to check if we have other places that use dTHX instead of pTHX pTHX: register PerlInterpreter *my_perl dTHX: register PerlInterpreter *my_perl = PERL_GET_THX Could that be the problem that you see? Could you please try with my patch above, reversing yours first? -- __ 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: thread pools & dynamic config (was Re: segfault in worker mpm)
Joe Schaefer wrote:
[...]
Thanks Stas for the clear explanation. Although I don't fully
understand how the interpreter pools operate yet,
Feel free to ask additional questions, Joe. I have explained that several
times on the modperl list, but never had a chance to throughly document
that. One day...
I'm still of
the opinion that the best way to resolve this problem is to
ensure the same interpreter always runs whatever extra hooks it
creates (eg pool cleanups, filters/handlers added, etc.).
That will be only possible if you drop the pools functionality, the
interpreter scopes, etc.
I was thinking that something is flawed in my explanation, but no, I've
checked mp1 source and in mod_perl.c it has:
#if 0 /* XXX: CV lookup cache disabled for now */
if(!is_method && defined_sub) { /* cache it */
MP_TRACE_h(fprintf(stderr,
"perl_call: caching CV pointer to `%s'\n",
(anon ? "__ANON__" : SvPV(sv,na;
SvREFCNT_dec(sv);
sv = (SV*)newRV((SV*)cv); /* let newRV inc the refcnt */
}
#endif
so I suppose caching of anon CVs compiled at run-time never worked.
Now, let's say we could somehow store those CVs in each interpreter,
rather than mod_perl's handlers (which I can't see how is it possible
w/o turning anon subs into named, which may have some bad
side-effects. We still have problems:
if we have:
PerlInterpScope handler
http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlInterpScope_
it's possible that the module was compiled during PerlTranshandler, by
interpreter A, but interpreter B was selected to run
PerlResponseHandler (which is the anon sub). What do we do now? B has
no idea what that anon-sub is, as it didn't compile it.
Is it really ok for interpreter B to deparse A's sub here?
It doesn't do that. A deparses the function and stores its source in the
mod_perl struct. Then B compiles it before running it.
--
__
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Stas Bekman <[EMAIL PROTECTED]> writes: [...] > Index: src/modules/perl/modperl_module.c > === > RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v > retrieving revision 1.17 > diff -u -r1.17 modperl_module.c > --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 - 1.17 > +++ src/modules/perl/modperl_module.c 8 Oct 2004 02:04:48 - > @@ -168,7 +168,7 @@ > > #ifdef USE_ITHREADS > modperl_interp_t *interp; > -dTHX; > +pTHX; > #endif > > /* if the module is loaded in vhost, base==NULL */ > > need to check if we have other places that use dTHX instead of pTHX > > pTHX: register PerlInterpreter *my_perl > dTHX: register PerlInterpreter *my_perl = PERL_GET_THX > > Could that be the problem that you see? Could you please try with my > patch above, reversing yours first? No luck. In fact, actually I am wondering why modperl_interp_pool_select() does not call PERL_SET_CONTEXT, but modperl_interp_select() does. If it did, that would resolve my segfault: Index: src/modules/perl/modperl_interp.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v retrieving revision 1.63 diff -u -p -r1.63 modperl_interp.c --- src/modules/perl/modperl_interp.c 18 Sep 2004 04:33:34 - 1.63 +++ src/modules/perl/modperl_interp.c 8 Oct 2004 02:36:29 - @@ -368,6 +368,7 @@ modperl_interp_t *modperl_interp_pool_se } } +PERL_SET_CONTEXT(interp->perl); return interp; } -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: thread pools & dynamic config (was Re: segfault in worker mpm)
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > I'm still of the opinion that the best way to resolve this problem is to
> > ensure the same interpreter always runs whatever extra hooks it creates (eg
> > pool cleanups, filters/handlers added, etc.).
>
> That will be only possible if you drop the pools functionality, the
> interpreter scopes, etc.
Obviously I don't see why that is so. In fact, I see that it is already
implemented in parts of mod_perl, for instance when registering a
pool-cleanup callback:
$sp->cleanup_register(sub { print @{ $_[0] || [] } }, [1..3]);
Here the currently active interpreter has its refcount incremented by
mpxs_apr_pool_cleanup_register(). AFAICT the interpreter is not allowed
to reenter the thread pool until this cleanup has run. I don't see how
PerlInterpScope influences this behavior at all.
I still believe that this is the right approach, and again I wonder
why this cannot also be used in the situations you cited earlier in
this thread.
[...]
> > Is it really ok for interpreter B to deparse A's sub here?
>
> It doesn't do that. A deparses the function and stores its source in
> the mod_perl struct. Then B compiles it before running it.
Thanks for clearing that up for me!
--
Joe Schaefer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: segfault in worker mpm
Stas Bekman wrote:
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
I did some binary search and found that:
mp2-20040922 - no core
mp2-20040923 - core
So we need to diff these two checkouts...
For a start, I've got these changes exposed in between those 2 dates:
http://www.apache.org/~gozer/mp2/2004-09-22+23/
That's a handy output. I'll try applying each separately to see which
one was the trigger.
For some reason, your output doesn't match mine. for me the difference
between 22nd and 23 starts from 3428 [1] and goes into the next day,
which is not included in your output:
[1] http://www.apache.org/~gozer/mp2/2004-09-22+23/3428.patch
but I think I'm getting there
It seems that this patch applied as reversed to the checkout from 23 Sept
resolves the segfault in t/filter/both_str_req_add.t. As you can see all
the changes are in creating new Vhosts entries.
However this doesn't resolve the current cvs problem, as I think there
were more entries added after Sept 23th, that cause the latest one.
diff -ru --exclude=CVS t/hooks/TestHooks/init.pm t/hooks/TestHooks/init.pm
--- t/hooks/TestHooks/init.pm 2003-08-11 16:34:22.0 -0400
+++ t/hooks/TestHooks/init.pm 2004-09-22 21:44:10.0 -0400
@@ -54,11 +54,15 @@
1;
__DATA__
-PerlInitHandler TestHooks::init::second
-
+
+
PerlModule TestHooks::init
PerlInitHandler TestHooks::init::first
-
-PerlResponseHandler TestHooks::init
-PerlResponseHandler TestHooks::init::response
-SetHandler modperl
+
+PerlInitHandler TestHooks::init::second
+PerlResponseHandler TestHooks::init
+PerlResponseHandler TestHooks::init::response
+SetHandler modperl
+
+
+
diff -ru --exclude=CVS t/response/TestUser/rewrite.pm
t/response/TestUser/rewrite.pm
--- t/response/TestUser/rewrite.pm 2004-07-09 17:52:49.0 -0400
+++ t/response/TestUser/rewrite.pm 2004-09-22 21:44:11.0 -0400
@@ -62,6 +62,7 @@
1;
__END__
+
PerlModule TestUser::rewrite
PerlTransHandlerTestUser::rewrite::trans
PerlMapToStorageHandler TestUser::rewrite::map2storage
@@ -69,5 +70,6 @@
SetHandler modperl
PerlResponseHandler TestUser::rewrite::response
+
diff -ru --exclude=CVS t/modules/proxy.t t/modules/proxy.t
--- t/modules/proxy.t 2004-08-03 12:16:22.0 -0400
+++ t/modules/proxy.t 2004-09-22 21:44:11.0 -0400
@@ -3,14 +3,19 @@
use Apache::Test;
use Apache::TestUtil;
-
use Apache::TestRequest;
-my $location = "/TestModules__proxy";
+my $module = 'TestModules::proxy';
+
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
plan tests => 1, (need_module('proxy') &&
need_access);
my $expected = "ok";
-my $received = GET_BODY_ASSERT $location;
+my $received = GET_BODY_ASSERT "http://$hostport/$path";;;
ok t_cmp($received, $expected, "internally proxified request");
diff -ru --exclude=CVS t/response/TestModules/proxy.pm
t/response/TestModules/proxy.pm
--- t/response/TestModules/proxy.pm 2004-07-09 04:01:21.0 -0400
+++ t/response/TestModules/proxy.pm 2004-09-22 21:44:11.0 -0400
@@ -43,6 +43,7 @@
1;
__END__
+
http://@servername@:@port@/*>
@@ -59,5 +60,6 @@
PerlResponseHandler TestModules::proxy::response
+
diff -ru --exclude=CVS t/hooks/TestHooks/trans.pm t/hooks/TestHooks/trans.pm
--- t/hooks/TestHooks/trans.pm 2003-04-18 02:18:58.0 -0400
+++ t/hooks/TestHooks/trans.pm 2004-09-22 21:44:11.0 -0400
@@ -37,5 +37,12 @@
1;
__DATA__
-PerlResponseHandler Apache::TestHandler::ok1
-SetHandler modperl
+
+
+PerlTransHandler TestHooks::trans
+
+PerlResponseHandler Apache::TestHandler::ok1
+SetHandler modperl
+
+
+
diff -ru --exclude=CVS t/hooks/trans.t t/hooks/trans.t
--- t/hooks/trans.t 2003-03-31 23:39:30.0 -0500
+++ t/hooks/trans.t 2004-09-22 21:44:10.0 -0400
@@ -8,15 +8,20 @@
use Apache2 ();
use Apache::Const ':common';
+my $module = 'TestHooks::trans';
+Apache::TestRequest::module($module);
+my $path = Apache::TestRequest::module2path($module);
+my $config = Apache::Test::config();
+my $hostport = Apache::TestRequest::hostport($config);
+t_debug("connecting to $hostport");
+
plan tests => 3;
t_client_log_error_is_expected();
-ok GET_RC('/nope') == NOT_FOUND;
-
-my $module = '/TestHooks/trans.pm';
+ok t_cmp GET_RC("http://$hostport/nope";), NOT_FOUND;
-my $body = GET_BODY $module;
+my $body = GET_BODY "http://$hostport/TestHooks/trans.pm";;
-ok $body =~ /package TestHooks::trans/;
+ok $body =~ /package $module/;
-ok GET_OK '/phooey';
+ok GET_OK "http://$hostport/phooey";;
--
__
Stas BekmanJAm
Re: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Joe Schaefer wrote: Stas Bekman <[EMAIL PROTECTED]> writes: [...] Index: src/modules/perl/modperl_module.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_module.c,v retrieving revision 1.17 diff -u -r1.17 modperl_module.c --- src/modules/perl/modperl_module.c 4 Mar 2004 06:01:07 - 1.17 +++ src/modules/perl/modperl_module.c 8 Oct 2004 02:04:48 - @@ -168,7 +168,7 @@ #ifdef USE_ITHREADS modperl_interp_t *interp; -dTHX; +pTHX; #endif /* if the module is loaded in vhost, base==NULL */ need to check if we have other places that use dTHX instead of pTHX pTHX: register PerlInterpreter *my_perl dTHX: register PerlInterpreter *my_perl = PERL_GET_THX Could that be the problem that you see? Could you please try with my patch above, reversing yours first? No luck. In fact, actually I am wondering why modperl_interp_pool_select() does not call PERL_SET_CONTEXT, but modperl_interp_select() does. I suppose these were added as the problems were appearing. If it did, that would resolve my segfault: You mean with this patch, the segfault goes away? Index: src/modules/perl/modperl_interp.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v retrieving revision 1.63 diff -u -p -r1.63 modperl_interp.c --- src/modules/perl/modperl_interp.c 18 Sep 2004 04:33:34 - 1.63 +++ src/modules/perl/modperl_interp.c 8 Oct 2004 02:36:29 - @@ -368,6 +368,7 @@ modperl_interp_t *modperl_interp_pool_se } } +PERL_SET_CONTEXT(interp->perl); return interp; } I think it has a problem, since potentially you haven't had a chance to save the original context yet, before calling ..._select, and this SET call will lose it. I think we should write MACRO wrappers around these calls, which will do the following: get the original context and store it in the interp struct. the override the current context with the context of the selected interpreter. On unselect it should make sure to restore the original context. -- __ 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: thread pools & dynamic config (was Re: segfault in worker mpm)
Joe Schaefer wrote:
Stas Bekman <[EMAIL PROTECTED]> writes:
Joe Schaefer wrote:
[...]
I'm still of the opinion that the best way to resolve this problem is to
ensure the same interpreter always runs whatever extra hooks it creates (eg
pool cleanups, filters/handlers added, etc.).
That will be only possible if you drop the pools functionality, the
interpreter scopes, etc.
Obviously I don't see why that is so. In fact, I see that it is already
implemented in parts of mod_perl, for instance when registering a
pool-cleanup callback:
$sp->cleanup_register(sub { print @{ $_[0] || [] } }, [1..3]);
Here the currently active interpreter has its refcount incremented by
mpxs_apr_pool_cleanup_register(). AFAICT the interpreter is not allowed
to reenter the thread pool until this cleanup has run. I don't see how
PerlInterpScope influences this behavior at all.
I still believe that this is the right approach, and again I wonder
why this cannot also be used in the situations you cited earlier in
this thread.
Anti-Example 1: parent interpreter compiles the anon-sub, which
interpreter are you going to stick to that anon-sub?
Anti-Example 2: PerlPreConnectionHandler compiles the anon-sub, that sub
is to run in PerlResponseHandler. If the interpreter scope is set to
'handler' (and if there is a different pool for each phase), the
interpreter that has run PerlPreConnectionHandler can't possible come even
close around PerlResponseHandler.
In any case, this is not feasible, the way things are initialized now,
since anon-subs aren't accessible from perl once you've compiled them
(i.e. if you didn't store it somewhere, you can't find it anymore). And
you can't store them in mod_perl, since it can store only one entry per
registered handler - it can't store N entries.
Just try to take each of the 3 cases I've explained earlier and see how
can you compile and where can you store it (even if you could stick the
perl interpreter to it).
regarding the example of pool cleanup, I believe that it's broken in the
case of interpreter scope functionality utilization.
As mentioned before hardly any of these interpreter scope/pool features
are exercised, so...
--
__
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: t/TEST t/directive/cmdparms.t segfaults w/5.8.5+ithreads
Stas Bekman <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote: [...] > > No luck. In fact, actually I am wondering why > > modperl_interp_pool_select() does not call PERL_SET_CONTEXT, but > > modperl_interp_select() does. > > I suppose these were added as the problems were appearing. > > > If it did, that would resolve my segfault: > > You mean with this patch, the segfault goes away? Yes- both with and without your patch. > > Index: src/modules/perl/modperl_interp.c > > === > > RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v > > retrieving revision 1.63 > > diff -u -p -r1.63 modperl_interp.c > > --- src/modules/perl/modperl_interp.c 18 Sep 2004 04:33:34 - 1.63 > > +++ src/modules/perl/modperl_interp.c 8 Oct 2004 02:36:29 - > > @@ -368,6 +368,7 @@ modperl_interp_t *modperl_interp_pool_se > > } > > } > > +PERL_SET_CONTEXT(interp->perl); > > return interp; > > } > > I think it has a problem, since potentially you haven't had a chance > to save the original context yet, In this case the original context is bogus (the interpreter which first set it seems to have left the building), so restoring it doesn't offer any protection in this case. Indeed, as mentioned earlier modperl_callback_run_handlers segfaults when localization is attempted, because it seems to assume modperl_interp_select will call PERL_SET_CONTEXT (which isn't always so). > before calling ..._select, and this SET call will lose it. > I think we should write MACRO wrappers around these calls, which will > do the following: get the original context and store it in the interp > struct. the override the current context with the context of the > selected interpreter. On unselect it should make sure to restore the > original context. Perhaps. I'll think about this more after the "thread pools & dynamic config" enlightens me a bit more. -- Joe Schaefer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: thread pools & dynamic config (was Re: segfault in worker mpm)
Stas Bekman <[EMAIL PROTECTED]> writes:
> Joe Schaefer wrote:
[...]
> > Obviously I don't see why that is so. In fact, I see that it is
> > already implemented in parts of mod_perl, for instance when
> > registering a pool-cleanup callback:
> > $sp->cleanup_register(sub { print @{ $_[0] || [] } }, [1..3]);
> > Here the currently active interpreter has its refcount incremented
> > by mpxs_apr_pool_cleanup_register(). AFAICT the interpreter is not
> > allowed to reenter the thread pool until this cleanup has run. I
> > don't see how PerlInterpScope influences this behavior at all.
> > I still believe that this is the right approach, and again I wonder
> > why this cannot also be used in the situations you cited earlier in
> > this thread.
>
> Anti-Example 1: parent interpreter compiles the anon-sub, which
> interpreter are you going to stick to that anon-sub?
A: As I stated, I expect the intepreter which invokes cleanup_register()
to also be the one which executes the anonymous sub during $sp's pool
cleanup. Are you saying that doesn't work if the interpreter is actually
a clone, and not the parent?
Bear in mind I'm learning about threads|ithreads as I go here, so please
don't intrepret my inquisitiveness as anything other than naivete. I'm
just trying to sort all this out so I can write a few useful patches.
As I slowly digest the rest of your post, it looks like I'll
derive the most benefit from it by writing a few tests first. :-)
--
Joe Schaefer
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
