Re: [mp2] integration with apache threads
Thank you very much, gentelmen. I'm happy for now, I guess. I do undestand perl threading issue, my problem was rather on how mod_perl and apache thread work together. I'm quite satisfied with your explanations. Thanks a lot. Pavel P.S.: Stas, ... yes I saw many segfaults... :) Perrin Harkins wrote: Pavel Hlavnicka wrote: Is it possible, that some new interpreter is cloned later then the pool is created PerlInterpMax If all running interpreters are in use, mod_perl will clone new interpreters to handle the request, up until this number of interpreters is reached. when PerlInterpMax is reached, mod_perl will block (via COND_WAIT()) until one becomes available (signaled via COND_SIGNAL()). From http://perl.apache.org/docs/2.0/user/config/config.html#Threads_Mode_Specific_Directives and is it possible, that ANY interpreter cloning will clone my global data? (I really mean e.g object stored in my handler in global variables, perhaps just lexical ones) All of your data is always cloned, just as it was when apache forked in mod_perl 1.x. Remember, Perl threads share nothing unless you tell them to. Is there something specific that you're worried about? - Perrin -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
[mp2] integration with apache threads
Hello all, currently I'm working over XML::Sablotron module, bringing it alive in the multithreaded environment. I searched both of Apache and mod_perl documentation, but there is one issue, I do not understand. Is there some relation between Perl threads and Apache threads? What I mean: If Apache fires a new thread, what happens in mod_perl? Are perl structures copied from the parent thread interpreter to the new one? ... or is the new perl environment clean? Thanks in advance Pavel -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
Re: [mp2] integration with apache threads
Oops, I overlooked the forst reading. Sorry for this. Anyway, even after reading this, I'm not really sure, what may happen. Is it possible, that some new interpreter is cloned later then the pool is created, and is it possible, that ANY interpreter cloning will clone my global data? (I really mean e.g object stored in my handler in global variables, perhaps just lexical ones) Thank you very much Pavel Perrin Harkins wrote: Pavel Hlavnicka wrote: Is there some relation between Perl threads and Apache threads? What I mean: If Apache fires a new thread, what happens in mod_perl? Are perl structures copied from the parent thread interpreter to the new one? ... or is the new perl environment clean? Have you read this? http://perl.apache.org/docs/2.0/user/intro/overview.html#Threads_Support I believe this addresses your questions. For the details of how Perl threads work, read this: http://perldoc.com/perl5.8.0/pod/perlthrtut.html - Perrin -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
Ok, here is a complete backtrace (after a nice couple of hours
observing the compilation progress... :)
Can you please share the details of what you have changed, that
allowed you to get the args and line numbers/file names? Why didn't you
have them in the original report (I want this to be documented).
I did it easily, but I'm not sure, it is a way for everyone... I just
built Perl form the source with CFLAGS='-O0 -g' (-O0 is not necessary, I
guess, it just usually makes debugger more precise on line tracking).
What I exactly did was:
sh Configure -des -Dprefix='/home/pavel/perl-5.8' -Duseshrplib
-Doptimize='-O0 -g' -Uinstallusrbinperl -Dusethreads
I compiled mod_perl for debugging too:
env CFLAGS='-O0 -g' perl Makefile.PL
I'm telling it just to be complete, but having more perl installations
and calling the appropriate perl executable to generate mod_perl
Makefile puts everything nicely together in right directory structures.
#0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0,
nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4)
at gv.c:646
#1 0x4003726b in Perl_get_sv (my_perl=0x0,
name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at
perl.c:1712
#2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at
perl_config.c:428
The key here is my_perl=0x0, an attempt to call into perl was made
before it was started. Since you didn't provide the details requested
at:
http://perl.apache.org/docs/1.0/guide/help.html#How_to_Report_Problems
(in particular build arguments) I'm doing a wild guesswork, assuming
that you have built without PERL_STACKED_HANDLERS=1 (or
EVERYTHING=1). So if my guess was correct, does the following patch
fixes the problem with the threaded perl?
Mea culpa, but I didn't tell you, bacause I did nothing particular - no
swithes to Makefile.PL at all, so your wild guess was correct. Sorry for
this omission.
... and the good message at last.. your patch works great. Thank you
very much!
Have you got a clue, when (and whether) some maintenance release will go
out? Meanwhile I'll prefer the workaround and I'll build modperl with
stacked handlers. May it have some impact to the performance? (...ok not
so critical for me, indeed).
Many thanks, and thaks for modperl.
Pavel
Index: src/modules/perl/perl_config.c
===
RCS file: /home/cvs/modperl/src/modules/perl/perl_config.c,v
retrieving revision 1.114
diff -u -r1.114 perl_config.c
--- src/modules/perl/perl_config.c 24 Mar 2002 22:51:04 -
1.114
+++ src/modules/perl/perl_config.c 18 Feb 2003 03:20:52 -
@@ -466,6 +466,11 @@
#else
#define PERL_CMD_PUSH_HANDLERS(hook, cmd) \
+if(!PERL_RUNNING()) { \
+perl_startup(parms-server, parms-pool); \
+require_Apache(parms-server); \
+MP_TRACE_g(fprintf(stderr, mod_perl: calling perl_startup()\n)); \
+} \
mp_preload_module(arg); \
cmd = arg; \
return NULL
__
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
--
Pavel Hlavnicka
Ginger Alliance
www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
Ok, here is a complete backtrace (after a nice couple of hours observing
the compilation progress... :)
#0 0x4003e32d in Perl_gv_fetchpv (my_perl=0x0,
nambeg=0x80c68a7 Apache::Server::AutoPreLoad, add=0, sv_type=4)
at gv.c:646
#1 0x4003726b in Perl_get_sv (my_perl=0x0,
name=0x80c68a7 Apache::Server::AutoPreLoad, create=0) at perl.c:1712
#2 0x08058c40 in mp_preload_module (name=0xbfff93e8) at perl_config.c:428
#3 0x08058efa in perl_cmd_handler_handlers (parms=0xb7a0,
rec=0x80f468c,
arg=0x80f4834 Apache::Registry) at perl_config.c:554
#4 0x0809c649 in invoke_cmd (cmd=0x80db2a0, parms=0xb7a0,
mconfig=0x80f468c, args=0xbfff94cc ) at http_config.c:918
#5 0x0809ca4f in ap_handle_command (parms=0xb7a0, config=0x80f4364,
l=0xbfff94b0 PerlHandler Apache::Registry) at http_config.c:1030
#6 0x0809cad6 in ap_srm_command_loop (parms=0xb7a0, config=0x80f4364)
at http_config.c:1044
#7 0x080a02bc in urlsection (cmd=0xb7a0, dummy=0x80f3a14,
arg=0xbfffb5ef ) at http_core.c:1655
#8 0x0809c003 in invoke_cmd (cmd=0x80d3250, parms=0xb7a0,
mconfig=0x80f3a14, args=0xbfffb5ea /perl) at http_config.c:810
#9 0x0809ca4f in ap_handle_command (parms=0xb7a0, config=0x80f3894,
l=0xbfffb5e0 Location /perl) at http_config.c:1030
#10 0x0809cad6 in ap_srm_command_loop (parms=0xb7a0, config=0x80f3894)
at http_config.c:1044
#11 0x080a0ac7 in virtualhost_section (cmd=0xb7a0, dummy=0x80e6d7c,
arg=0xbfffd70d 212.24.153.10) at http_core.c:1913
#12 0x0809c003 in invoke_cmd (cmd=0x80d3280, parms=0xb7a0,
mconfig=0x80e6d7c, args=0xbfffd70d 212.24.153.10) at
http_config.c:810
#13 0x0809ca4f in ap_handle_command (parms=0xb7a0, config=0x80e61ec,
l=0xbfffd700 VirtualHost 212.24.153.10) at http_config.c:1030
#14 0x0809cad6 in ap_srm_command_loop (parms=0xb7a0, config=0x80e61ec)
at http_config.c:1044
#15 0x0809d265 in ap_process_resource_config (s=0x80e57a4,
fname=0x80e6e14 /usr/local/apache/conf/httpd.conf, p=0x80e577c,
ptemp=0x80e979c) at http_config.c:1332
#16 0x0809db43 in ap_read_config (p=0x80e577c, ptemp=0x80e979c,
confname=0x80ddf20 conf/httpd.conf) at http_config.c:1616
#17 0x080a8280 in main (argc=2, argv=0xb8e4) at http_main.c:5433
#18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6
The line in the Perl_gv_fetchpv is as follows:
for (namend = name; *namend; namend++) {
if ((*namend == ':' namend[1] == ':')
|| (*namend == '\'' namend[1]))
{
if (!stash)
stash = PL_defstash; /* --- THIS ONE
if (!stash || !SvREFCNT(stash))
return Nullgv;
stash is NULL, what the hell is the chance the PL_defstash macro makes
the trouble?
Have you got some clue?
Anyway, I'll continue my investigations.
Thank in advance
Pavel
Stas Bekman wrote:
Pavel Hlavnicka wrote:
Hi all,
recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled
Apache 1.3.27 with mod_perl 1.27 from source.
Now if I run Apache is works until I configure some location with
mod_perl and PerlHandler like this:
Location /perl
SetHandler perl-script
PerlHandler Apache::Registry
Options ExecCGI
allow from all
/Location
If PerlHandler line is commented out, the server starts fine.
--
Pavel Hlavnicka
Ginger Alliance
www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
One more info (seems be useful) if I build NON-threaded version of Perl, all seems be ok (at least, there is no crash during the startup. Threaded version of perl crashes regardless on the compiler optimization level (just if you wanted to know) Is it possible we have found a bug in Perl? Pavel Stas Bekman wrote: Pavel Hlavnicka wrote: Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Your trace is not as useful as it could be, because it neither shows the arguments nor the line numbers in the source code. I suggest to debug it with gdb, set breakpoint in perl_cmd_handler_handlers and step through to see what's wrong. If you don't know how to debug see: http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_when_Server_Crashes_on_Startup_before_Writing_to_Log_File_ and previous sections as well, though you don't need Apache::DB since the problem doesn't happen during the request. p.s. What app did you get this trace with? It'd be helpful to update the bug reporting section to explain how to get a more useful trace. The one that includes symbols, arguments and line numbers. __ 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 -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
Re: modperl segfault with threaded Perl 5.8
Actually, I've used gdb to produce the stack trace. Although it seems, that installed version of libperl.so is not stripped, the output was as you could see it. I'll try to investigate a bit more and let you know. Thanks so far. Pavel Stas Bekman wrote: Pavel Hlavnicka wrote: Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Your trace is not as useful as it could be, because it neither shows the arguments nor the line numbers in the source code. I suggest to debug it with gdb, set breakpoint in perl_cmd_handler_handlers and step through to see what's wrong. If you don't know how to debug see: http://perl.apache.org/docs/1.0/guide/debug.html#Debugging_when_Server_Crashes_on_Startup_before_Writing_to_Log_File_ and previous sections as well, though you don't need Apache::DB since the problem doesn't happen during the request. p.s. What app did you get this trace with? It'd be helpful to update the bug reporting section to explain how to get a more useful trace. The one that includes symbols, arguments and line numbers. __ 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 -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
modperl segfault with threaded Perl 5.8
Hi all, recently I upgraded to RH 8.0 with threaded Perl 5.8. I compiled Apache 1.3.27 with mod_perl 1.27 from source. Now if I run Apache is works until I configure some location with mod_perl and PerlHandler like this: Location /perl SetHandler perl-script PerlHandler Apache::Registry Options ExecCGI allow from all /Location If PerlHandler line is commented out, the server starts fine. Here is the backtrace of 'httpd -X' #0 0x4003cfa0 in Perl_gv_fetchpv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #1 0x40035635 in Perl_get_sv () from /usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE/libperl.so #2 0x08056b78 in mp_preload_module () #3 0x08056e32 in perl_cmd_handler_handlers () #4 0x08078a35 in invoke_cmd () #5 0x08078e3b in ap_handle_command () #6 0x08078ec2 in ap_srm_command_loop () #7 0x0807c6a8 in urlsection () #8 0x080783ef in invoke_cmd () #9 0x08078e3b in ap_handle_command () #10 0x08078ec2 in ap_srm_command_loop () #11 0x0807ceb3 in virtualhost_section () #12 0x080783ef in invoke_cmd () #13 0x08078e3b in ap_handle_command () #14 0x08078ec2 in ap_srm_command_loop () #15 0x08079651 in ap_process_resource_config () #16 0x08079f2f in ap_read_config () #17 0x0808466c in main () #18 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 Has anyone seen it before? and... here is what my perl says: This is perl, v5.8.0 built for i386-linux-thread-multi Many thanks in advance, and sorry if I overlooked something basic. Pavel -- Pavel Hlavnicka Ginger Alliance www.gingerall.com
