Re: [mp2] HASH_SEED question
Randy Kobes wrote: ActiveState just released version 807, which is based on the perl-5.8.1 sources with some 5.8.2 enhancements. The sources they use don't include the hash randomization stuff of 5.8.1/5.8.2 (so that builds using 807 will be binary compatible with pre-807 builds), and they define NO_HASH_SEED in the compile-time flags when building extensions. perl -v reports 5.8.1. My reading of src/modules/perl/(mod_perl|modperl_perl).c is that the MP_NEED_HASH_SEED_FIXUP doesn't need additional logic in this case, but I'm worried I might be missing something? That's correct. MP_NEED_HASH_SEED_FIXUP is needed only if perl is compiled with -DUSE_HASH_SEED or -DUSE_HASH_SEED_EXPLICIT. If there are any problems you most likely will see them immediately in the test suite. But I doubt that there will be any if -DNO_HASH_SEED is used, since it can't coexist with the other two defines. __ 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] HASH_SEED question
On Wed, 12 Nov 2003, Stas Bekman wrote: > Randy Kobes wrote: > > ActiveState just released version 807, which is based on the > > perl-5.8.1 sources with some 5.8.2 enhancements. The sources > > they use don't include the hash randomization stuff of > > 5.8.1/5.8.2 (so that builds using 807 will be binary > > compatible with pre-807 builds), and they define > > NO_HASH_SEED in the compile-time flags when building > > extensions. perl -v reports 5.8.1. My reading of > > src/modules/perl/(mod_perl|modperl_perl).c is that the > > MP_NEED_HASH_SEED_FIXUP doesn't need additional logic in > > this case, but I'm worried I might be missing something? > > That's correct. MP_NEED_HASH_SEED_FIXUP is needed only if perl is compiled > with -DUSE_HASH_SEED or -DUSE_HASH_SEED_EXPLICIT. If there are any problems > you most likely will see them immediately in the test suite. But I doubt that > there will be any if -DNO_HASH_SEED is used, since it can't coexist with the > other two defines. Thanks, Stas! The tests did run successfully, so all seems well ... -- best regards, randy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
At 10:58 -0500 11/12/03, Geoffrey Young wrote: Rafael Garcia-Suarez wrote: Geoffrey Young wrote: the problem with this, though, is that we don't really want a clean interpreter, we want an _almost_ clean one - one with only the data we know is important (like the globals set within the section). so, if we could copy the relevant data from the first interpreter and insert it into the one we're about to clone for the request, we'd have the best situation possible - minimal data in the parent interpreter. Problem : how to separate the relevant data from the irrelevant one ? Does it live in a particular package ? for the stuff I was talking about, I believe so. however, for directive handlers it does not, so we'd probably need to tweak the interface a bit. but the idea, I guess, is that mod_perl would (eventually) know what data is required to be copied, so long as we had a way to do it. Wouldn't Storable or Data::Dumper be able to do such a thing? At the end of config, dump the pertinent bits to memory (or possibly even a file), and then read them back in the other interpreter? Liz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [mp2] perl_clone takes 5 and more seconds to complete
At 18:06 -0800 11/12/03, Stas Bekman wrote: Geoffrey Young wrote: for the stuff I was talking about, I believe so. however, for directive handlers it does not, so we'd probably need to tweak the interface a bit. And not for , because a random code can be run there in random packages. But you could document that only the "real" config bits would be available later and anything else lost (unless re-required later). And copy the config bits in a Storable / Data::Dumper format between the interpreters. This is not too dissimilar to what forks.pm does for shared variables and Thread::Tie does. Liz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mp2 - still cannot start server on solaris
- Original Message - > From: "Stas Bekman" <[EMAIL PROTECTED]> > [EMAIL PROTECTED] wrote: > > I guess I just was not lucky enough. > > I upgraded my env to > > Apache 2.0.48, mod_perl 1.99_11, perl 5.8.2, gcc 3.3 on solaris 2.8. > > > > I'm still having the same problem. the server just cannot be started. > > I had successfully built an older version of mod_perl with gcc 2.95.2; > > however, I have no luck with gcc 3.3 at all. > > > > Any special gcc flags or a solaris patch that I need? > [...] > > #0 0xfc6fff60 in ?? () > > (gdb) bt #0 0xfc6fff60 in ?? () #1 0xfe2ac43c in Perl_runops_debug () at dump.c:1438 #2 0xfe225bdc in S_call_body (myop=0xffbede80, is_eval=0) at perl.c:2224 #3 0xfe2255e4 in Perl_call_sv (sv=0x16df80, flags=6) at perl.c:2142 #4 0xfe22c62c in S_call_list_body (cv=0x16df80) at perl.c:4393 #5 0xfe22bfd4 in Perl_call_list (oldscope=12, paramList=0x16dd7c) at perl.c:4322 #6 0xfe27dbf8 in Perl_newATTRSUB (floor=499, o=0x166208, proto=0x0, attrs=0x0, block=0x166280) at op.c:4367 #7 0xfe27780c in Perl_utilize (aver=1, floor=499, version=0x0, idop=0x1669b0, arg=0x13fc00) at op.c:2975 #8 0xfe2695c0 in Perl_yyparse () at perly.y:414 #9 0xfe335f4c in S_doeval (gimme=0, startop=0x0, outside=0x0, seq=146) at pp_ctl.c:2802 #10 0xfe338e40 in Perl_pp_require () at pp_ctl.c:3299 #11 0xfe20f0f4 in modperl_pp_require () at modperl_perl_pp.c:54 #12 0xfe2ac43c in Perl_runops_debug () at dump.c:1438 #13 0xfe225bdc in S_call_body (myop=0xffbee720, is_eval=0) at perl.c:2224 #14 0xfe2255e4 in Perl_call_sv (sv=0x1424b8, flags=6) at perl.c:2142 #15 0xfe22c62c in S_call_list_body (cv=0x1424b8) at perl.c:4393 #16 0xfe22bfd4 in Perl_call_list (oldscope=4, paramList=0x142434) at perl.c:4322 #17 0xfe27dbf8 in Perl_newATTRSUB (floor=287, o=0xd3228, proto=0x0, attrs=0x0, block=0x1664b0) at op.c:4367 #18 0xfe269214 in Perl_yyparse () at perly.y:355 #19 0xfe335f4c in S_doeval (gimme=0, startop=0x0, outside=0x0, seq=143) at pp_ctl.c:2802 #20 0xfe338e40 in Perl_pp_require () at pp_ctl.c:3299 #21 0xfe20f0f4 in modperl_pp_require () at modperl_perl_pp.c:54 #22 0xfe2ac43c in Perl_runops_debug () at dump.c:1438 #23 0xfe225bdc in S_call_body (myop=0xffb8, is_eval=1) at perl.c:2224 #24 0xfe225f3c in Perl_eval_sv (sv=0x133d80, flags=2) at perl.c:2284 #25 0xfe226764 in Perl_require_pv ( pv=0xd9a28 "/s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t/conf/modperl_sta rtup.pl") at perl.c:2382 #26 0xfe1ff9cc in modperl_require_file ( pv=0xd9a28 "/s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t/conf/modperl_sta rtup.pl", logfailure=1) at modperl_util.c:30 #27 0xfe1f8ee8 in modperl_config_apply_PerlRequire (s=0x97cd0, scfg=0xdba90, perl=0x8dbe0, p=0x94a60) at modperl_config.c:360 #28 0xfe1f46b8 in modperl_startup (s=0x97cd0, p=0x94a60) at mod_perl.c:255 #29 0xfe1f430c in modperl_startup (s=0x97cd0, p=0x94a60) at mod_perl.c:158 #30 0xfe1f6084 in modperl_init (base_server=0x97cd0, p=0x94a60) at mod_perl.c:389 #31 0xfe1f630c in modperl_hook_init (pconf=0x94a60, plog=0x0, ptemp=0x0, s=0x97cd0) at mod_perl.c:524 #32 0xfe1f6350 in modperl_run () at mod_perl.c:535 #33 0xfe1fb800 in modperl_cmd_load_module (parms=0xffbef5f0, mconfig=0xdbef8, arg=0xec848 "TestDirective::perlloadmodule4") at modperl_cmd.c:501 #34 0x00048424 in invoke_cmd (cmd=0xfe3dd338, parms=0xffbef5f0, mconfig=0xdbef8, args=0xec848 "TestDirective::perlloadmodule4") at config.c:703 #35 0x00048a88 in ap_walk_config_sub (current=0xec828, parms=0xffbef5f0, section_vector=0xd3c88) at config.c:1085 #36 0x00048b24 in ap_walk_config (current=0xec828, parms=0xffbef5f0, section_vector=0xd3c88) at config.c:1124 #37 0x0004976c in ap_process_config_tree (s=0x97cd0, conftree=0xec828, p=0x94a60, ptemp=0xd0b50) at config.c:1654 #38 0x0004be40 in main (argc=6, argv=0xffbef734) at main.c:581 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Segmentation fault
Hi, Stas:
thx ur quck reply. The problem remained although i applied ur patch to last cvs
mod_per and run on last cvs apache2.
perl -v
This is perl, v5.8.2 built for i686-linux
./httpd -v
Server version: Apache/2.0.49-dev
Server built: Nov 16 2003 21:48:57
But the place change where Segmentation fault raise, here is the gdb output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 8102)]
0x40174670 in apr_file_read (thefile=0x1, buf=0x824f6f0, nbytes=0xb468)
at readwrite.c:79
79 if (thefile->buffered) {
(gdb) backtrace
#0 0x40174670 in apr_file_read (thefile=0x1, buf=0x824f6f0, nbytes=0xb468)
at readwrite.c:79
#1 0x403ab840 in modperl_slurp_filename (r=0x819f680, tainted=0)
at modperl_util.c:722
#2 0x406b177b in XS_Apache__RequestRec_slurp_filename (cv=0x81c4b14)
at RequestUtil.xs:249
#3 0x4041250b in Perl_pp_entersub ()
from /usr/local/apache2/modules/mod_perl.so
#4 0x4040ce68 in Perl_runops_standard ()
from /usr/local/apache2/modules/mod_perl.so
#5 0x403bfc26 in S_call_body () from /usr/local/apache2/modules/mod_perl.so
#6 0x403bfa1a in Perl_call_sv () from /usr/local/apache2/modules/mod_perl.so
#7 0x403a7f42 in modperl_callback (handler=0x81a3070, p=0x819f648,
r=0x819f680, s=0x80c2140, args=0x8155fb8) at modperl_callback.c:69
#8 0x403a8564 in modperl_callback_run_handlers (idx=6, type=4, r=0x819f680,
c=0x0, s=0x80c2140, pconf=0x0, plog=0x0, ptemp=0x0,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:227
#9 0x403a8733 in modperl_callback_per_dir (idx=6, r=0x819f680,
run_mode=MP_HOOK_RUN_FIRST) at modperl_callback.c:299
#10 0x403a465a in modperl_response_handler_run (r=0x819f680, finish=0)
at mod_perl.c:827
#11 0x403a4850 in modperl_response_handler_cgi (r=0x819f680) at mod_perl.c:892
#12 0x08081435 in ap_run_handler (r=0x819f680) at config.c:195
#13 0x08081a3f in ap_invoke_handler (r=0x7) at config.c:401
#14 0x0806e846 in ap_process_request (r=0x812ce5c) at http_request.c:288
#15 0x08069cac in ap_process_http_connection (c=0x7) at http_core.c:293
#16 0x0808c265 in ap_run_process_connection (c=0x8199740) at connection.c:85
#17 0x0807fa5c in child_main (child_num_arg=7123) at prefork.c:694
#18 0x0807fc6a in make_child (s=0x1, slot=0) at prefork.c:734
#19 0x0807fcc8 in startup_children (number_to_start=5) at prefork.c:806
#20 0x0808050f in ap_mpm_run (_pconf=0x80bfa38, plog=0x80f7b18, s=0x80c2140)
at prefork.c:1022
#21 0x0808696f in main (argc=4, argv=0xba74) at main.c:660
#22 0x40214917 in __libc_start_main () from /lib/libc.so.6
(gdb) print thefile
$1 = (apr_file_t *) 0x1
Stas Bekman <[EMAIL PROTECTED]> wrote:
>[In the future please don't reply to some thread when starting a new topic,
>but post a new email. thank you!]
>
>Bobber Cheng wrote:
>> Hi,
>>
>> Apache(2.0.48) with perl_mod(1.99_10) got a Segmentation fault when i
>> access a perl script from apache. I use perl-5.8.2 built from source
>> without thread-support. perl_mod is complied by perl "Makefile.PL
>> MP_INST_APACHE2=1 MP_DEBUG=1 MP_AP_PREFIX=/usr/local/apache2".
>[...]
>> 0x4027b14a in memcpy () from /lib/libc.so.6
>> (gdb) backtrace
>> #0 0x4027b14a in memcpy () from /lib/libc.so.6
>> #1 0x40174728 in apr_file_read (thefile=0x8433e58, buf=0x0,
>> nbytes=0x81b33ec)
>>at readwrite.c:122
>> #2 0x403ab52e in modperl_slurp_filename (r=0x8433e58, tainted=0)
>>at modperl_util.c:710
>> #3 0x406c677b in XS_Apache__RequestRec_slurp_filename (cv=0x81b33ec)
>
>Please try this patch:
>
>Index: src/modules/perl/modperl_util.c
>===
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
>retrieving revision 1.56
>diff -u -r1.56 modperl_util.c
>--- src/modules/perl/modperl_util.c 3 Nov 2003 09:29:49 - 1.56
>+++ src/modules/perl/modperl_util.c 12 Nov 2003 09:09:10 -
>@@ -706,6 +706,12 @@
>
> size = r->finfo.size;
> sv = newSV(size);
>+
>+if (!size) {
>+sv_setpvn(sv, "", 0);
>+return newRV_noinc(sv);
>+}
>+
> file = r->finfo.filehand;
> if (!file) {
> rc = apr_file_open(&file, r->filename, APR_READ|APR_BINARY,
>
>You may need to use the latest cvs (or mod_perl 1.99_11) if the patch doesn't
>apply cleanly, but I think it should be fine. You want to use 1.99_11 in any case.
>
>__
>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
>
>
__
McAfee VirusScan Online from the Netscape Network.
Comprehensive protection for your entire computer. Get your free trial today!
http://channels.netscape.com/ns/computing/mcafee/index.jsp?promo=39
Re: [mp2] perl_clone takes 5 and more seconds to complete
Elizabeth Mattijsen wrote: At 18:06 -0800 11/12/03, Stas Bekman wrote: Geoffrey Young wrote: for the stuff I was talking about, I believe so. however, for directive handlers it does not, so we'd probably need to tweak the interface a bit. And not for , because a random code can be run there in random packages. But you could document that only the "real" config bits would be available later and anything else lost (unless re-required later). And copy the config bits in a Storable / Data::Dumper format between the interpreters. This is not too dissimilar to what forks.pm does for shared variables and Thread::Tie does. Even we did enforce that, we still have things like PerlLoadModule which extend the config directives dictionary. >> for the stuff I was talking about, I believe so. however, for >> directive handlers it does not, so we'd probably need to tweak the >> interface a bit. >> but the idea, I guess, is that mod_perl would (eventually) know what >> data is required to be copied, so long as we had a way to do it. > > > Wouldn't Storable or Data::Dumper be able to do such a thing? At the > end of config, dump the pertinent bits to memory (or possibly even a > file), and then read them back in the other interpreter? I'm not sure as those bits include references to internal C structs. __ 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: Segmentation fault
Bobber Cheng wrote:
Hi, Stas:
thx ur quck reply. The problem remained although i applied ur patch to last cvs mod_per and run on last cvs apache2.
perl -v
This is perl, v5.8.2 built for i686-linux
./httpd -v
Server version: Apache/2.0.49-dev
Server built: Nov 16 2003 21:48:57
But the place change where Segmentation fault raise, here is the gdb output:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 8102)]
0x40174670 in apr_file_read (thefile=0x1, buf=0x824f6f0, nbytes=0xb468)
at readwrite.c:79
79 if (thefile->buffered) {
(gdb) backtrace
#0 0x40174670 in apr_file_read (thefile=0x1, buf=0x824f6f0, nbytes=0xb468)
at readwrite.c:79
#1 0x403ab840 in modperl_slurp_filename (r=0x819f680, tainted=0)
at modperl_util.c:722
OK, so filehandle thefile is not initilized or corrupt. What are you trying to
slurp? Can you go one frame up and do:
gdb> p r->filename
__
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 - still cannot start server on solaris
Tulan W. Hu wrote: - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> [EMAIL PROTECTED] wrote: I guess I just was not lucky enough. I upgraded my env to Apache 2.0.48, mod_perl 1.99_11, perl 5.8.2, gcc 3.3 on solaris 2.8. I'm still having the same problem. the server just cannot be started. I had successfully built an older version of mod_perl with gcc 2.95.2; however, I have no luck with gcc 3.3 at all. Any special gcc flags or a solaris patch that I need? [...] #0 0xfc6fff60 in ?? () (gdb) bt #0 0xfc6fff60 in ?? () #1 0xfe2ac43c in Perl_runops_debug () at dump.c:1438 #2 0xfe225bdc in S_call_body (myop=0xffbede80, is_eval=0) at perl.c:2224 #3 0xfe2255e4 in Perl_call_sv (sv=0x16df80, flags=6) at perl.c:2142 #4 0xfe22c62c in S_call_list_body (cv=0x16df80) at perl.c:4393 #5 0xfe22bfd4 in Perl_call_list (oldscope=12, paramList=0x16dd7c) at perl.c:4322 #6 0xfe27dbf8 in Perl_newATTRSUB (floor=499, o=0x166208, proto=0x0, attrs=0x0, block=0x166280) at op.c:4367 #7 0xfe27780c in Perl_utilize (aver=1, floor=499, version=0x0, idop=0x1669b0, arg=0x13fc00) at op.c:2975 #8 0xfe2695c0 in Perl_yyparse () at perly.y:414 #9 0xfe335f4c in S_doeval (gimme=0, startop=0x0, outside=0x0, seq=146) at pp_ctl.c:2802 #10 0xfe338e40 in Perl_pp_require () at pp_ctl.c:3299 #11 0xfe20f0f4 in modperl_pp_require () at modperl_perl_pp.c:54 #12 0xfe2ac43c in Perl_runops_debug () at dump.c:1438 #13 0xfe225bdc in S_call_body (myop=0xffbee720, is_eval=0) at perl.c:2224 #14 0xfe2255e4 in Perl_call_sv (sv=0x1424b8, flags=6) at perl.c:2142 #15 0xfe22c62c in S_call_list_body (cv=0x1424b8) at perl.c:4393 #16 0xfe22bfd4 in Perl_call_list (oldscope=4, paramList=0x142434) at perl.c:4322 #17 0xfe27dbf8 in Perl_newATTRSUB (floor=287, o=0xd3228, proto=0x0, attrs=0x0, block=0x1664b0) at op.c:4367 #18 0xfe269214 in Perl_yyparse () at perly.y:355 #19 0xfe335f4c in S_doeval (gimme=0, startop=0x0, outside=0x0, seq=143) at pp_ctl.c:2802 #20 0xfe338e40 in Perl_pp_require () at pp_ctl.c:3299 #21 0xfe20f0f4 in modperl_pp_require () at modperl_perl_pp.c:54 #22 0xfe2ac43c in Perl_runops_debug () at dump.c:1438 #23 0xfe225bdc in S_call_body (myop=0xffb8, is_eval=1) at perl.c:2224 #24 0xfe225f3c in Perl_eval_sv (sv=0x133d80, flags=2) at perl.c:2284 #25 0xfe226764 in Perl_require_pv ( pv=0xd9a28 "/s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t/conf/modperl_sta rtup.pl") at perl.c:2382 #26 0xfe1ff9cc in modperl_require_file ( pv=0xd9a28 "/s5/twh/papache/httpd-2.0.48/mod_perl-1.99_11/t/conf/modperl_sta rtup.pl", logfailure=1) at modperl_util.c:30 #27 0xfe1f8ee8 in modperl_config_apply_PerlRequire (s=0x97cd0, scfg=0xdba90, perl=0x8dbe0, p=0x94a60) at modperl_config.c:360 #28 0xfe1f46b8 in modperl_startup (s=0x97cd0, p=0x94a60) at mod_perl.c:255 #29 0xfe1f430c in modperl_startup (s=0x97cd0, p=0x94a60) at mod_perl.c:158 #30 0xfe1f6084 in modperl_init (base_server=0x97cd0, p=0x94a60) at mod_perl.c:389 #31 0xfe1f630c in modperl_hook_init (pconf=0x94a60, plog=0x0, ptemp=0x0, s=0x97cd0) at mod_perl.c:524 #32 0xfe1f6350 in modperl_run () at mod_perl.c:535 #33 0xfe1fb800 in modperl_cmd_load_module (parms=0xffbef5f0, mconfig=0xdbef8, arg=0xec848 "TestDirective::perlloadmodule4") at modperl_cmd.c:501 #34 0x00048424 in invoke_cmd (cmd=0xfe3dd338, parms=0xffbef5f0, mconfig=0xdbef8, args=0xec848 "TestDirective::perlloadmodule4") at config.c:703 #35 0x00048a88 in ap_walk_config_sub (current=0xec828, parms=0xffbef5f0, section_vector=0xd3c88) at config.c:1085 #36 0x00048b24 in ap_walk_config (current=0xec828, parms=0xffbef5f0, section_vector=0xd3c88) at config.c:1124 #37 0x0004976c in ap_process_config_tree (s=0x97cd0, conftree=0xec828, p=0x94a60, ptemp=0xd0b50) at config.c:1654 #38 0x0004be40 in main (argc=6, argv=0xffbef734) at main.c:581 Thanks for the trace, Tulan. Something goes wrong on the perl side, though I'm not sure what :( I think I saw a similar problem when fighting with the AIX build some time ago. Chances are that you will be able to install and run your code without any problems though. This particular problem happens because of PerlLoadModule causing and early perl startup. Let me know if you have problems to run your own code with 1.99_11. I'm trying to solve some other problems with the startup at the moment. Let's hope that if I come up with a robust solution it'll resolve these as well. __ 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] perl_clone takes 5 and more seconds to complete
At 09:53 -0800 11/13/03, Stas Bekman wrote: Elizabeth Mattijsen wrote: > Wouldn't Storable or Data::Dumper be able to do such a thing? At the end of config, dump the pertinent bits to memory (or possibly even a > file), and then read them back in the other interpreter? I'm not sure as those bits include references to internal C structs. Ok, that's out of the question, then... Liz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [PATCH mp2] sections not setting filename/lineno correctly
On Tue, 2003-11-11 at 17:04, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > Until now, code executing within sections was not 'tweaked' to
> > match the filename/lineno of the httpd configuration file it was in.
> >
> > So, for example, error reporting would appear to be coming from obscure
> > eval contexts.
> >
> > Following patch restores the same behaviour than in mp1.
>
> +1, with a single style fix below
I lack in style ;-p
Style fixed and change applied!
> > Index: Changes
> > ===
> > RCS file: /home/cvs/modperl-2.0/Changes,v
> > retrieving revision 1.249
> > diff -u -I$Id: -r1.249 Changes
> > --- Changes 10 Nov 2003 21:11:53 - 1.249
> > +++ Changes 11 Nov 2003 20:24:24 -
> > @@ -14,6 +14,9 @@
> >
> > =item 1.99_11 - November 10, 2003
> >
> > + sections now proprely set filename and line number information,
> > +making error messages report the correct location. [Philippe M. Chiasson]
>
> You probably didn't cvs update your Changes ;)
>
> > Index: src/modules/perl/modperl_cmd.c
> > ===
> [...]
> > +line_header = apr_psprintf(p, "\n#line %d %s\n",
> > parms->directive->line_num, parms->directive->filename);
>
> This line needs to be wrapped.
>
>
> __
> 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
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'
signature.asc
Description: This is a digitally signed message part
Re: mp2 - still cannot start server on solaris
> Thanks for the trace, Tulan. Something goes wrong on the perl side, though I'm > not sure what :( I think I saw a similar problem when fighting with the AIX > build some time ago. I have the same problem when I tried the Apache 2.0.46 with perl 5.8.0 on solaris. I installed it and got a core dump when I started the server. Builting Apache 2.0.48 mod_perl 1.99_11 with perl 5.8.1 gave me an compile error. I have tried the "gcc" with and without "-B/usr/ccs/bin" option when I built perl and both gave me same results. > Chances are that you will be able to install and run your code without any > problems though. This particular problem happens because of PerlLoadModule > causing and early perl startup. Let me know if you have problems to run your > own code with 1.99_11. I installed it without testing and still got a core dump when I started the server. > I'm trying to solve some other problems with the startup at the moment. Let's > hope that if I come up with a robust solution it'll resolve these as well. I guess I should not be in a hurry to upgrade my server because we must use mod_perl. Shall I upgrade the perl first? We are currently using mp1 with perl 5.6.0. Do you think perl 5.8.2 is stable for using? I shall rebuild the mp1 server if I upgrade my perl right? Thanks for your time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mp2 - still cannot start server on solaris
Tulan W. Hu wrote: Thanks for the trace, Tulan. Something goes wrong on the perl side, though I'm not sure what :( I think I saw a similar problem when fighting with the AIX build some time ago. I have the same problem when I tried the Apache 2.0.46 with perl 5.8.0 on solaris. I installed it and got a core dump when I started the server. Builting Apache 2.0.48 mod_perl 1.99_11 with perl 5.8.1 gave me an compile error. I have tried the "gcc" with and without "-B/usr/ccs/bin" option when I built perl and both gave me same results. It'd be useful for you to report more details on the compile error. In any case you always want to build perl and apache using the same compiler. mod_perl automatically picks the compiler used to build perl (and the compile options) Chances are that you will be able to install and run your code without any problems though. This particular problem happens because of PerlLoadModule causing and early perl startup. Let me know if you have problems to run your own code with 1.99_11. I installed it without testing and still got a core dump when I started the server. :( I'm trying to solve some other problems with the startup at the moment. Let's hope that if I come up with a robust solution it'll resolve these as well. I guess I should not be in a hurry to upgrade my server because we must use mod_perl. Sorry for not being able to solve this at the moment. Please do try to see if new versions get it resolved and report back if you have any discoveries that may help us. Ideally someone on Solaris with undertstanding of perl guts should try to fix it. At the moment I'm swamped with quite a few annoying problems, so I can't do that. Shall I upgrade the perl first? We are currently using mp1 with perl 5.6.0. Do you think perl 5.8.2 is stable for using? Most likely 5.8.2 is fine. Or you could go with 5.6.1 which is pretty good and 5.6.2 should be released shortly. Since you most likely do a thorough testing before you go update your production server, I'd give a try to 5.8.2. I shall rebuild the mp1 server if I upgrade my perl right? That's correct. __ 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]
