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)
compatibility problem
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? Thanks, Jie
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
