Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote: On Thu, 23 May 2002, Jie Gao wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 15349)] 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134 134 if (!symbol-hash) { (gdb) bt #0 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134 #1 0x403103ed in modperl_callback (handler=0x83dcd68, p=0x83d3438, r=0x83d3470, s=0x80d1540, args=0x8131110) at modperl_callback.c:19 this is with modperl-2.0 from cvs? if you have a simple test case to reproduce, that would help. looks related to method handlers based on your stacktrace. I have found the following: In httpd.conf: Directory /export/softwares # Document root. Options All AllowOverride All Order allow,deny allow from all /Directory Segmentation fault happens when accessing /export/softwares/data, a subdirectory which does not have an .htaccess file itself, but a subdirectory of which has an .htaccess file containing: IndexOptions FancyIndexing NameWidth=* ScanHTMLTitles IconsAreLinks PerlAuthenHandler XXX::AuthCookieHandler-authen PerlAuthzHandler XXX::AuthCookieHandler-authz AuthType XXX AuthName XXX PerlSetVar AuthenLoginPageLocation 'https://xxx.xxx.xxx.xx/login.cgi' PerlSetVar VirtualServerName xxx.xxx.xxx.xxx. PerlSetVar AuthCookieDebug 0 PerlSetVar TimeOut 10 require group /export/softserv/acl/nero ErrorDocument 403 /server_response/software_403.html Changing AllowOverride All to AllowOverride None does not incur a Segmentation fault. The .htaccess file might have a problem, but having a problem accessing the parent directory makes it very hard to debug. Regards, Jie
Re: compatibility problem
On Fri, 24 May 2002, Jie Gao wrote: Segmentation fault happens when accessing /export/softwares/data, a subdirectory which does not have an .htaccess file itself, but a subdirectory of which has an .htaccess file containing: hmm. you might want to try building modperl with MP_DEBUG=1 and configure 'PerlTrace all' in httpd.conf which might give some clues to what the problem is.
Re: compatibility problem
On Mon, 20 May 2002, Doug MacEachern wrote: On Fri, 17 May 2002, Jie Gao wrote: use Apache::Constants qw(:common :response M_GET M_POST AUTH_REQUIRED REDIRECT); the :response group in 1.x consists of names which apache has deprecated in 1.3.x and removed in 2.0, for which there are HTTP_* names that replace the old names. so for example, if you had imported the :response group to use 'BAD_GATEWAY', you should instead explicity import HTTP_BAD_GATEWAY, which will work with both 1.x and 2.x. I put this in my module: use Apache::Constants qw(:common BAD_GATEWAY M_GET M_POST AUTH_REQUIRED REDIRECT FORBIDDEN SERVER_ERROR); and make test says BAD_GATEWAY is not exported by Apache::Constants. Also perl-status doesn't seem to be functioning: [Thu May 23 14:14:43 2002] [error] [client 129.xx.xx.xx] Undefined subroutine Apache::Constants::SERVER_VERSION called at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache/Status.pm line 86. I am also getting: [Thu May 23 14:11:45 2002] [notice] child pid 32213 exit signal Segmentation fault (11) when running my 1.3 module. I couldn't find any coredump, though. Anyone can help? Regards, Jie
Re: compatibility problem
On Thu, 23 May 2002, Jie Gao wrote: and make test says BAD_GATEWAY is not exported by Apache::Constants. are you actually using that constant? i only was using it as an example. Also perl-status doesn't seem to be functioning: Apache::Status doesn't work with 2.0 yet. I am also getting: [Thu May 23 14:11:45 2002] [notice] child pid 32213 exit signal Segmentation fault (11) when running my 1.3 module. I couldn't find any coredump, though. Anyone can help? modperl-1.xx/SUPPORT: % gdb ../apache_x.xx/src/httpd (gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t [now make request that causes core dump] (gdb) bt
Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote: On Thu, 23 May 2002, Jie Gao wrote: and make test says BAD_GATEWAY is not exported by Apache::Constants. are you actually using that constant? i only was using it as an example. if you are, you need to change it to HTTP_BAD_GATEWAY. one caveat for 1.x compat, not all of the Apache::Constants are in EXPORT/EXPORT_OK in 1.x. reason is because Exporter.pm is such a memory hog, we tried to limit the number of exports. this particular HTTP_ constant is one that was left out of the default list. it is however available if you export it in 1.x. to do this you need to call: Apache::Constants-export(qw(HTTP_BAD_GATEWAY)); i just added a stub to Apache::compat to provide that method (which does nothing). all constants are available for import in 2.0 since we no longer use Exporter.pm
Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote: Apache::Status doesn't work with 2.0 yet. actually, it kinda does after added SERVER_VERSION to Apache::compat. Enabled mod_perl Hooks does not work, nor does Compiled Registry Scripts, but everything else seems to.
Re: compatibility problem
On Wed, 22 May 2002, Doug MacEachern wrote: On Thu, 23 May 2002, Jie Gao wrote: I am also getting: [Thu May 23 14:11:45 2002] [notice] child pid 32213 exit signal Segmentation fault (11) when running my 1.3 module. I couldn't find any coredump, though. Anyone can help? modperl-1.xx/SUPPORT: % gdb ../apache_x.xx/src/httpd (gdb) run -X -f `pwd`/t/conf/httpd.conf -d `pwd`/t [now make request that causes core dump] (gdb) bt OK, here you are: (gdb) run -X -f /usr/local/apache2/conf/httpd.conf -d /usr/local/apache2 Starting program: /usr/local/apache2/bin/httpd -X -f /usr/local/apache2/conf/httpd.conf -d /usr/local/apache2 [New Thread 1024 (LWP 15349)] bt Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 15349)] 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134 134 if (!symbol-hash) { (gdb) bt #0 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134 #1 0x403103ed in modperl_callback (handler=0x83dcd68, p=0x83d3438, r=0x83d3470, s=0x80d1540, args=0x8131110) at modperl_callback.c:19 #2 0x40310aec in modperl_callback_run_handlers (idx=2, type=5, r=0x83d3470, c=0x0, s=0x80d1540, pconf=0x0, plog=0x0, ptemp=0x0) at modperl_callback.c:175 #3 0x40310b9a in modperl_callback_per_dir (idx=2, r=0x83d3470) at modperl_callback.c:199 #4 0x403186f0 in modperl_authen_handler (r=0x83d3470) at modperl_hooks.c:42 #5 0x0807734a in ap_run_check_user_id (r=0x83d3470) at request.c:111 #6 0x08077b31 in ap_process_request_internal (r=0x83d3470) at request.c:220 #7 0x08064715 in ap_process_request (r=0x83d3470) at http_request.c:259 #8 0x08060c4d in ap_process_http_connection (c=0x83cd528) at http_core.c:291 #9 0x0806e3e2 in ap_run_process_connection (c=0x83cd528) at connection.c:85 #10 0x08065a85 in child_main (child_num_arg=0) at prefork.c:671 #11 0x08065b38 in make_child (s=0x8098790, slot=0) at prefork.c:711 #12 0x08065c22 in startup_children (number_to_start=10) at prefork.c:783 #13 0x08065f24 in ap_mpm_run (_pconf=0x8096a40, plog=0x80c0ae8, s=0x8098790) at prefork.c:999 #14 0x0806ac0f in main (argc=6, argv=0xb944) at main.c:632 #15 0x40109647 in __libc_start_main (main=0x806a500 main, argc=6, ubp_av=0xb944, init=0x805e6c4 _init, fini=0x80802a0 _fini, rtld_fini=0x4000dcd4 _dl_fini, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:129 (gdb) Subsequent requests hang. Regards, Jie
Re: compatibility problem
On Thu, 23 May 2002, Jie Gao wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 15349)] 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134 134 if (!symbol-hash) { (gdb) bt #0 0x4031575d in modperl_mgv_lookup (symbol=0x0) at modperl_mgv.c:134 #1 0x403103ed in modperl_callback (handler=0x83dcd68, p=0x83d3438, r=0x83d3470, s=0x80d1540, args=0x8131110) at modperl_callback.c:19 this is with modperl-2.0 from cvs? if you have a simple test case to reproduce, that would help. looks related to method handlers based on your stacktrace.
Re: compatibility problem
On Fri, 17 May 2002, Jie Gao wrote: use Apache::Constants qw(:common :response M_GET M_POST AUTH_REQUIRED REDIRECT); the :response group in 1.x consists of names which apache has deprecated in 1.3.x and removed in 2.0, for which there are HTTP_* names that replace the old names. so for example, if you had imported the :response group to use 'BAD_GATEWAY', you should instead explicity import HTTP_BAD_GATEWAY, which will work with both 1.x and 2.x. If I take out response, it croaks at REDIRECT. i've added REDIRECT to the list of shortcut names which apache had deprecated, but are common/handy enough to carry forward with modperl. the full list of shortcut names supported in modperl2 that are deprecated in apache (in favor of the long-winded HTTP_ names): NOT_FOUND(HTTP_NOT_FOUND) FORBIDDEN(HTTP_FORBIDDEN) AUTH_REQUIRED(HTTP_UNAUTHORIZED) SERVER_ERROR (HTTP_INTERNAL_SERVER_ERROR) REDIRECT (HTTP_MOVED_TEMPORARILY)
Re: compatibility problem
You'll find a few other issues with AuthCookie and mod_perl-1.9.9_01 beyond the REDIRECT constant. Here's a quick summary: 1) move all the $r-connection-user() calls to $r-user() calls 2) change all the err_header_out() calls to err_headers_out() calls. $r-err_headers_out-{'Pragma'} = no-cache; --- $r-err_header_out(Pragma = no-cache); This is the bulk of the changes that I did to get things going. I'm going to send my in to the maintainer of the Module as soon as I get some help with method handles. This module makes use of the technique of derived method handlers. I have been able to get a regular, much less a derived, method handler working in mod_perl1.99. As a temporary hack I hacked the module code to be a non-method handler. good luck, -pete Stas Bekman wrote: Jie Gao wrote: Hi all, I've been trying to get httpd-2.0.35 + mod_perl-1.99_01 work with backward compatibility. MY startupl.pl: #! /usr/bin/perl use lib '/usr/lib/perl5/site_perl/5.6.1/i386-linux/Apache2'; use strict; use Apache::compat (); use Apache2 (); use My::AuthCookieHandler; 1; and this script won't run to finish with the error: unknown group `response' at /usr/lib/perl5/site_perl/5.6.1/My/AuthCookieHandler.pm line 6. BEGIN failed--compilation aborted at /usr/lib/perl5/site_perl/5.6.1/My/AuthCookieHandler.pm line 6. Compilation failed in require at ./startup.pl line 6. BEGIN failed--compilation aborted at ./startup.pl line 6. And this is the line in question: use Apache::Constants qw(:common :response M_GET M_POST AUTH_REQUIRED REDIRECT); If I take out response, it croaks at REDIRECT. Any ideas why? Yes, it's not fully compatible :( in 2.0 we take all the Constants from APR and Apache, and they have changed. I guess we can manually do the adjustments in compat.pm. Currently there is no group :response in Apache::Const, these mainly reside in the new group :http and all the codes start with HTTP_ For now try to replace REDIRECT with HTTP_TEMPORARY_REDIRECT and whatever constants you need from :response by looking them up in xs/ModPerl/Const/modperl_constants.c (which is autogenerated when you build mod_perl). We will discuss this issue at the dev list and the compat docs will be updated appropriately. __ 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