Re: Apache2::Reload Segmentation Fault
Vince Moneymaker wrote:
Okay, all of the tests are being passed. I have added the contents of my
startup.pl file to the modperl_startup.pl file and no segfaults are
occurring including even when I change the Handler.pm file as the tests
are being run on it. I have also added some items to the conf file to try
and reproduced how my httpd.conf file is set up and again no segfaults.
Should I go the whole way and add the entire contents of my httpd.conf
file to the test conf file? Or is there some other approach I should take
in order to reproduce the problem?
Stas Bekman wrote
Yes, the easiest approach is to start with everything that you have and you
get a segfault. And then follow the "binary search" approach, where you try
to cut the stuff to the minimum but trying to remove halves of
config/code/whatever.
I discovered what was causing the problem. Even though I had used the
following in the startup.pl file
use Apache2::Const -compile => ':common';
the Apache modules were segfaulting on the straight 'OK' constant
declarations in them. So I fixed the problem by replacing the above line
with the following line in the startup.pl file
use Apache2::Const -compile => qw(OK REDIRECT FORBIDDEN SERVER_ERROR);
I then went through each Apache module and removed the 'use Apache2::Const'
declarations and changed all of the 'OK' constants to Apache2::Const::OK .
I did the same thing for the REDIRECT, FORBIDDEN, etc constants in the
modules. The only problem I am still having is with the REMOTE_HOST
constant which caused a changed module to segfault no matter how I declare
it.
Otherwise, all of the Apache modules work fine.
However, the other modules I have in the Melior namespace are not getting
reloaded. Apparently the reason for this as noted in the following post at
http://forums.devside.net/viewtopic.php?t=671&start=0&postdays=0&postorder=asc&highlight=
is that they are being called from within the Apache2 modules. In other
words, because the Melior modules only get requested by modules in the
Apache2 namespace, they don't get reloaded even though their own separate
namespace is declared within them, as well as in the Apache2 modules and the
startup.pl file.
With regard to debugging this problem, the reload debugger shows that the
Melior modules do get reloaded when they change but the change doesn't show
up on the page that gets spit out. Here is a sample from the error_log
#Apache2::Reload: process 24620 reloading Melior::Menus from Melior/Menus.pm
# Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)') called
at /opt/prod/apache/Melior/Menus.pm line 0
# eval {...} called at /opt/prod/apache/Melior/Menus.pm line 0
# Apache2::Reload: Checking mtime of CCMckErrno3_2.pm
# Apache2::Reload::handler('Apache2::RequestRec=SCALAR(0xcce5d18)') called
at -e line 0
# eval {...} called at -e line 0
BTW, as I mentioned last time, I believe this problem first cropped up with
modperl version 1.99.17. If you have any suggestions on what I should
tinker with in order to get modules called by other modules reloaded that
would be great.
And again thanks for all of your help, Vince
can't "use mod_perl" on debian
Hi, I've got mod_perl installed on my debian sarge/testing box via: aptitude install libapache2-mod-perl2 and I know my webserver is mod_perl aware # head /var/log/apache2/error.log [Sat Apr 23 06:56:28 2005] [notice] Apache/2.0.53 (Debian GNU/Linux) mod_perl/1.999.21 Perl/v5.8.4 configured -- resuming normal operations but when I do: # perl -Mmod_perl Can't locate mod_perl.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.4 /usr/local/share/perl/5.8.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .). I'm trying to install Kwiki::ModPerl, but it "use mod_perl" and blows up during the install any hints? Thanks Jay
Re: reading post data.
Michael Schout wrote: I am wondering what the best way is to read POST data under MP2. In MP1, I was using $r->content for this. In MP2, $r->content does not exist, so I used the version from an earlier copy of Apache::compat, which was using $r->get_client_block() instead. Now, get_client_block() is apparently deprecated, and I am left with the choice of: 1) using $r->read(). CGI.pm apparently does it this way. 2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides content() this way. 3) some other way that I do not know about :). I am unclear what the advantages are for either approach. The APR::Brigade docs do not really clarify this for me. Does anyone know which of these methods is better and why? Michael, as Jonathan has replied it's now the job of CGI.pm, APR::Request and other modules to provide this service. In the lack of it, you can use the following code: http://svn.apache.org/viewcvs.cgi/perl/modperl/trunk/t/lib/TestCommon/Utils.pm?rev=160947&view=markup (see the read_post sub in it, drop the debug code to not add the overhead) -- __ 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
Re: Apache2::Reload Segmentation Fault
Vincent Moneymaker wrote: OK, so yours crash is in require, Vincent. Any chance you could prepare a tarball that reproduces the problem, so Philippe can reproduce it easily? Please grab the template from geoff's site: http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz In fact better use the attachment in this message: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=45170703909&w=2 it's already designed for this specific problem. Just swap my setup with yours. Please don't hesitate to ask questions if you have any, Vincent. Okay, all of the tests are being passed. I have added the contents of my startup.pl file to the modperl_startup.pl file and no segfaults are occurring including even when I change the Handler.pm file as the tests are being run on it. I have also added some items to the conf file to try and reproduced how my httpd.conf file is set up and again no segfaults. Should I go the whole way and add the entire contents of my httpd.conf file to the test conf file? Or is there some other approach I should take in order to reproduce the problem? Yes, the easiest approach is to start with everything that you have and you get a segfault. And then follow the "binary search" approach, where you try to cut the stuff to the minimum but trying to remove halves of config/code/whatever. -- __ 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
Re: reading post data.
works in RC4 + libapreq 2.04
use Apache::Request()
sub handler
{
my $r = shift;
my $apr = Apache::Request->new( $r , DISABLE_UPLOADS=>0,
POST_MAX=>10 );
$stringvalue = $apr->param($stringname);
}
RC5 is slightly different from the namespace stuff, and you need to run
one of the svn branches of libapreq -- either trunk or multi-env -- its
under active development right now
personally, i think libapreq is the best way to read GET/POST data
under MP2
On Apr 23, 2005, at 3:56 PM, Michael Schout wrote:
I am wondering what the best way is to read POST data under MP2.
In MP1, I was using $r->content for this. In MP2, $r->content does not
exist, so I used the version from an earlier copy of Apache::compat,
which was using $r->get_client_block() instead.
Now, get_client_block() is apparently deprecated, and I am left with
the
choice of:
1) using $r->read(). CGI.pm apparently does it this way.
2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides
content() this way.
3) some other way that I do not know about :).
I am unclear what the advantages are for either approach. The
APR::Brigade docs do not really clarify this for me.
Does anyone know which of these methods is better and why?
Regards,
Michael Schout
reading post data.
I am wondering what the best way is to read POST data under MP2. In MP1, I was using $r->content for this. In MP2, $r->content does not exist, so I used the version from an earlier copy of Apache::compat, which was using $r->get_client_block() instead. Now, get_client_block() is apparently deprecated, and I am left with the choice of: 1) using $r->read(). CGI.pm apparently does it this way. 2) Use APR::Brigade. Apache2::compat from 2.0.0 RC5 does provides content() this way. 3) some other way that I do not know about :). I am unclear what the advantages are for either approach. The APR::Brigade docs do not really clarify this for me. Does anyone know which of these methods is better and why? Regards, Michael Schout
Re: Apache2::Reload Segmentation Fault
Vincent Moneymaker wrote Vincent Moneymaker wrote: Vincent Moneymaker wrote: Here is the output from the backtrace (hope I did it correctly) Program received signal SIGSEGV, Segmentation fault. 0xdeb3618f in Perl_gv_efullname3 () from /opt/prod/apache/modules/mod_perl.so (gdb) bt #6 0xdeb9293f in Perl_pp_require () from /opt/prod/apache/modules/mod_perl.so #7 0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69 #8 0xdeb6d61e in Perl_runops_standard () from /opt/prod/apache/modules/mod_perl.so #9 0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so Stas Bekman wrote: OK, so yours crash is in require, Vincent. Any chance you could prepare a tarball that reproduces the problem, so Philippe can reproduce it easily? Please grab the template from geoff's site: http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz In fact better use the attachment in this message: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=45170703909&w=2 it's already designed for this specific problem. Just swap my setup with yours. Please don't hesitate to ask questions if you have any, Vincent. Okay, all of the tests are being passed. I have added the contents of my startup.pl file to the modperl_startup.pl file and no segfaults are occurring including even when I change the Handler.pm file as the tests are being run on it. I have also added some items to the conf file to try and reproduced how my httpd.conf file is set up and again no segfaults. Should I go the whole way and add the entire contents of my httpd.conf file to the test conf file? Or is there some other approach I should take in order to reproduce the problem?
Re: Apache2::Reload Segmentation Fault
Vincent Moneymaker wrote: Vincent Moneymaker wrote: Here is the output from the backtrace (hope I did it correctly) Program received signal SIGSEGV, Segmentation fault. 0xdeb3618f in Perl_gv_efullname3 () from /opt/prod/apache/modules/mod_perl.so (gdb) bt #6 0xdeb9293f in Perl_pp_require () from /opt/prod/apache/modules/mod_perl.so #7 0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69 #8 0xdeb6d61e in Perl_runops_standard () from /opt/prod/apache/modules/mod_perl.so #9 0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so Stas Bekman wrote: OK, so yours crash is in require, Vincent. Any chance you could prepare a tarball that reproduces the problem, so Philippe can reproduce it easily? Please grab the template from geoff's site: http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz In fact better use the attachment in this message: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=45170703909&w=2 it's already designed for this specific problem. Just swap my setup with yours. Please don't hesitate to ask questions if you have any, Vincent. I downloaded your attachment and I get the following with 'use Apache2 ();' in the Makefile.PL Can't locate Apache2.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i86pc-solaris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i86pc-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 3. BEGIN failed--compilation aborted at Makefile.PL line 3. When I pull out 'use Apache2 ();', I then the server starts and I get the following error in the error_log [Sat Apr 23 10:08:28 2005] [error] [client 127.0.0.1] Can't locate object method "dir_config" via package "Apache2::RequestRec" at /usr/local/lib/perl5/site_per l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n [Sat Apr 23 10:08:31 2005] [error] [client 127.0.0.1] Can't locate object method "dir_config" via package "Apache2::RequestRec" at /usr/local/lib/perl5/site_per l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n [Sat Apr 23 10:08:31 2005] [info] removed PID file /home/vince/mod_perl-2.0.0-RC 5/AR-segv-mp2/t/logs/httpd.pid (pid=17237) [Sat Apr 23 10:08:31 2005] [notice] caught SIGTERM, shutting down Yes, sorry, it was created before the move to the Apache2:: name space. I've attached a new version which works with RC5. The Reload module in the Apache namespace is the old 0.08 Reload module. When I place a copy of the new 0.09 version of Reload that is in the Apache2 namespace in the Apache namespace, the server won't start. I suspect I am doing something wrong. No, it should be Apache2::Reload coming with RC5. as mentioned above that tarball needed a fixup. Also, when you talk about preparing a tarball that reproduces the problem, could you give me a pointer on how I prepare that so I can send one to Philippe? That's the tarball you've been trying to use. Vincent, please try again with the fixed attachment. -- __ 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 AR-segv-mp2.tar.gz Description: GNU Zip compressed data
Re: Apache2::Reload Segmentation Fault
Vincent Moneymaker wrote: Here is the output from the backtrace (hope I did it correctly) Program received signal SIGSEGV, Segmentation fault. 0xdeb3618f in Perl_gv_efullname3 () from /opt/prod/apache/modules/mod_perl.so (gdb) bt #6 0xdeb9293f in Perl_pp_require () from /opt/prod/apache/modules/mod_perl.so #7 0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69 #8 0xdeb6d61e in Perl_runops_standard () from /opt/prod/apache/modules/mod_perl.so #9 0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so Stas Bekman wrote: OK, so yours crash is in require, Vincent. Any chance you could prepare a tarball that reproduces the problem, so Philippe can reproduce it easily? Please grab the template from geoff's site: http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz In fact better use the attachment in this message: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=45170703909&w=2 it's already designed for this specific problem. Just swap my setup with yours. Please don't hesitate to ask questions if you have any, Vincent. I downloaded your attachment and I get the following with 'use Apache2 ();' in the Makefile.PL Can't locate Apache2.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.0/i86pc-solaris /usr/local/lib/perl5/5.8.0 /usr/local/lib/perl5/site_perl/5.8.0/i86pc-solaris /usr/local/lib/perl5/site_perl/5.8.0 /usr/local/lib/perl5/site_perl .) at Makefile.PL line 3. BEGIN failed--compilation aborted at Makefile.PL line 3. When I pull out 'use Apache2 ();', I then the server starts and I get the following error in the error_log [Sat Apr 23 10:08:28 2005] [error] [client 127.0.0.1] Can't locate object method "dir_config" via package "Apache2::RequestRec" at /usr/local/lib/perl5/site_per l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n [Sat Apr 23 10:08:31 2005] [error] [client 127.0.0.1] Can't locate object method "dir_config" via package "Apache2::RequestRec" at /usr/local/lib/perl5/site_per l/5.8.0/i86pc-solaris/Apache/Reload.pm line 52.\n [Sat Apr 23 10:08:31 2005] [info] removed PID file /home/vince/mod_perl-2.0.0-RC 5/AR-segv-mp2/t/logs/httpd.pid (pid=17237) [Sat Apr 23 10:08:31 2005] [notice] caught SIGTERM, shutting down The Reload module in the Apache namespace is the old 0.08 Reload module. When I place a copy of the new 0.09 version of Reload that is in the Apache2 namespace in the Apache namespace, the server won't start. I suspect I am doing something wrong. Also, when you talk about preparing a tarball that reproduces the problem, could you give me a pointer on how I prepare that so I can send one to Philippe? Thanks, Vince
Re: Apache2::Reload Segmentation Fault
Vincent Moneymaker wrote: Vincent Moneymaker wrote: I am running Apache 2.0.52 on a solaris 8 box with mod_perl-2.0.0-RC5. I previously had problems using Apache::Reload with mod_perl 1.99_19 version back in December and gave up trying to find a fix. I thought I would try again with the RC5 version but after having upgraded from mod_perl 1.99_12 to RC5 I am getting segmentation fault errors when the Apache2::Reload module is present in my httpd.conf file and a change is then made in a module and the web page that is created via the changed module is then called up. I know that the segmentation fault is related to the Apache2::Reload module because the segmentation fault errors don't appear when the same change is made in the module (i.e. a simple print statement) but without Apache2::Reload being present in the httpd.conf file. Stas Bekman wrote: It's probably related to the similar segfaults I've been seeing and reported here [1]. But if you don't show the backtrace of the core file as explained at http://perl.apache.org/bugs/ we will never know. I've CC'ed Philippe on this one, hoping that he will find the time to fix this problem. Here is the output from the backtrace (hope I did it correctly) Program received signal SIGSEGV, Segmentation fault. 0xdeb3618f in Perl_gv_efullname3 () from /opt/prod/apache/modules/mod_perl.so (gdb) bt #6 0xdeb9293f in Perl_pp_require () from /opt/prod/apache/modules/mod_perl.so #7 0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69 #8 0xdeb6d61e in Perl_runops_standard () from /opt/prod/apache/modules/mod_perl.so #9 0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so OK, so yours crash is in require, Vincent. Any chance you could prepare a tarball that reproduces the problem, so Philippe can reproduce it easily? Please grab the template from geoff's site: http://people.apache.org/~geoff/Apache-Test-skeleton-mp2.tar.gz In fact better use the attachment in this message: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=45170703909&w=2 it's already designed for this specific problem. Just swap my setup with yours. Please don't hesitate to ask questions if you have any, Vincent. -- __ 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
Re: CPAN modules
Philip M. Gollucci wrote: Stas Bekman wrote: Philip, we have Bundle::Apache2 which is exactly for that purpose. Feel free to send a patch to add the missing modules. Yes, I added IPC::Run3 and uped the CGI version :) things to in a patch. Yup, thank you :) Though as it can be seen from your list, most modules are either not needed by normal users (used only by developers, i.e. Tie::IxHash) or they are not required by mod_perl test suite, but they are dependencies of other modules, and therefore should't be on that list. Yes, the plus of this is that CPAN won't ask me if I want to follow the dpendencies if I install them in this order even for 5.6.2. I wasn't suggesting to put these all in the Apache2::Bundle file. Right. But those dependencies lists always change, so it's better to tell CPAN.pm to follow deps (which in my setup is automatic). I've just tested, the only modules required are: BSD::Resources CGI Chatbot::Eliza Compress::Zlib HTML::HeadParser LWP all in the bundle file already, but HTML::HeadParser, which I'll add shortly Did you check that will perl 5.8.6 or perl 5.6.2 as the list is slightly different since less is in CORE in 5.6.x; I forget what though. I have checked that w/o perl, all requirements are in the plan() call. -- __ 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
Re: Apache2::Reload Segmentation Fault
Vincent Moneymaker wrote: I am running Apache 2.0.52 on a solaris 8 box with mod_perl-2.0.0-RC5. I previously had problems using Apache::Reload with mod_perl 1.99_19 version back in December and gave up trying to find a fix. I thought I would try again with the RC5 version but after having upgraded from mod_perl 1.99_12 to RC5 I am getting segmentation fault errors when the Apache2::Reload module is present in my httpd.conf file and a change is then made in a module and the web page that is created via the changed module is then called up. I know that the segmentation fault is related to the Apache2::Reload module because the segmentation fault errors don't appear when the same change is made in the module (i.e. a simple print statement) but without Apache2::Reload being present in the httpd.conf file. Stas Bekman wrote: It's probably related to the similar segfaults I've been seeing and reported here [1]. But if you don't show the backtrace of the core file as explained at http://perl.apache.org/bugs/ we will never know. I've CC'ed Philippe on this one, hoping that he will find the time to fix this problem. Here is the output from the backtrace (hope I did it correctly) Program received signal SIGSEGV, Segmentation fault. 0xdeb3618f in Perl_gv_efullname3 () from /opt/prod/apache/modules/mod_perl.so (gdb) bt #0 0xdeb3618f in Perl_gv_efullname3 () from /opt/prod/apache/modules/mod_perl.so #1 0xdeb4ba96 in S_gv_ename () from /opt/prod/apache/modules/mod_perl.so #2 0xdeb57917 in Perl_ck_subr () from /opt/prod/apache/modules/mod_perl.so #3 0xdeb4faf2 in Perl_newUNOP () from /opt/prod/apache/modules/mod_perl.so #4 0xdeb4b706 in Perl_yyparse () from /opt/prod/apache/modules/mod_perl.so #5 0xdeb9169d in S_doeval () from /opt/prod/apache/modules/mod_perl.so #6 0xdeb9293f in Perl_pp_require () from /opt/prod/apache/modules/mod_perl.so #7 0xdeb226a1 in modperl_pp_require () at modperl_perl_pp.c:69 #8 0xdeb6d61e in Perl_runops_standard () from /opt/prod/apache/modules/mod_perl.so #9 0xdeb31361 in S_call_body () from /opt/prod/apache/modules/mod_perl.so #10 0xdeb3113c in Perl_call_sv () from /opt/prod/apache/modules/mod_perl.so #11 0xdeb14727 in modperl_callback (handler=0x8681fc0, p=0xcd12d10, r=0xcd12d48, s=0xc79c908, args=0xccf13ac) at modperl_callback.c:100 #12 0xdeb14dfc in modperl_callback_run_handlers (idx=0, type=5, r=0xcd12d48, c=0x0, s=0xc79c908, pconf=0x0, plog=0x0, ptemp=0x0, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:261 #13 0xdeb1521e in modperl_callback_per_srv (idx=0, r=0xcd12d48, run_mode=MP_HOOK_RUN_ALL) at modperl_callback.c:376 #14 0xdeb2bd20 in modperl_post_read_request_handler (r=0xcd12d48) at modperl_hooks.c:67 #15 0x0807fd3e in ap_run_post_read_request (r=0xcd12d48) at protocol.c:1555 #16 0x0807eff3 in ap_read_request (conn=0xccf9948) at protocol.c:994 #17 0x0806c754 in ap_process_http_connection (c=0xccf9948) at http_core.c:242 #18 0x0807b4e6 in ap_run_process_connection (c=0xccf9948) at connection.c:42 #19 0x08071b55 in child_main (child_num_arg=0) at prefork.c:609 #20 0x08071d0a in make_child (s=0x80b9d80, slot=0) at prefork.c:649 #21 0x08071d63 in startup_children (number_to_start=8) at prefork.c:721 #22 0x08072479 in ap_mpm_run (_pconf=0x80b7fe0, plog=0x80e2088, s=0x80b9d80) at prefork.c:940 #23 0x0807758e in main (argc=6, argv=0x8047c54) at main.c:617
