a bug [?] with mod_perl Perl directive
hey all
i was beating my hed against this
i thought i should post
all these modules load up and work fine
if i use the old location directive way
but thats tedious!
i thought
hey use the perl directive!
fine it works great
but i couldn't fiqure out why
all the modules would load but not the
viewmembers one
finally i figured out
if i changed view to viewzine it worked great
it could go past and get viewmember!!
what could be causing this?
my guess is there is some sort of wierd
regex prob or i am just missing something
Perl
#array has
#filename,directory,Module
my @modules=(
['login','','Login'],
['editzine','level1/','EditZine'],
['search','level2/','Search'],
['cats','level2/','Category'],
['viewzine','level2/','ViewZine'],
['register','','Register'],
['viewmember','level2/','ViewMember']
);
#go through em
foreach (@modules){
#make the location
my $dir = $_-[1] ne '' ? $EZS::Global::dir.$_-[1]:'/';
#set location to module
$Location{$dir.$_-[0]}={
SetHandler ='perl-script',
PerlHandler ='EZS::'.$_-[2]
};
}
/Perl
bug in mod_perl-1.24 request-args request-content
Apache.pm documents two methods "args" and "content" that should return
argument = value pairs (when called appropriately). In fact, args is
implemented as:
return map { Apache::unescape_url_info($_) } split /[=;]/, $string, -1;
However, this might return an odd number of values, for example for this url:
httpurl?arg1arg2=val2
I get (arg1 = "arg2", val2), which is not as documented.
This url format is often used for boolean arguments (CGI.pm creates an
arg1 = "", while I would prefer arg1 = undef in this case).
So either the documentation or the implementation is in error. I would
prefer if the implementation were in error ;)
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
RE: possible bug in mod_perl 1.24_01
-Original Message- From: Michael J Schout [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 18, 2000 2:54 PM To: [EMAIL PROTECTED] Subject: Re: possible bug in mod_perl 1.24_01 I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I have the same config and don't have any problems... however, from the debug output, it looks to me like it is the Include directive that is mucking things up... `@Include' directive is TAKE1, (1 elements) default: iterating over @Include handle_command (Include "/nis.home/mschout/dev/gkgdrs/gkgnsi/conf/httpd.conf"): loading perl module 'Apache'...ok `@Include' directive is TAKE1, (0 elements) default: iterating over @Include perl_section: /Directory `@Include' directive is TAKE1, (0 elements) default: iterating over @Include perl_section: /Directory ...etc are any of your configuration files a directory? 1.3.14 will now recurse through any config files that are directories and process all the files within... maybe that is going awry somehow? I suppose my suggestion might be to start stripping down your config file to something basic and add stuff until the looping starts - not much help, I know, but... --Geoff I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
possible bug in mod_perl 1.24_01
I have had an application working under apache 1.3.12/mod_perl 1.24 for several months now with no problems. I am currently trying to make the jump to apache 1.3.14/mod_perl 1.24_01 (since mod_perl 1.24 will not easily build agains 1.3.14). When I do this, and then try to start apache, it goes into an infinite loop proocessing perl sections. The stack trace from gdb looks like this: #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 1736vfprintf.c: No such file or directory. (gdb) bt #0 0x4010a6a1 in buffered_vfprintf (s=0xfbad2887, format=Cannot access memory at address 0xbf7ff184 ) at vfprintf.c:1736 #1 0x40105966 in _IO_vfprintf (s=0x401aea20, format=0x8119d18 "loading perl module '%s'...", ap=0xbf801910) at vfprintf.c:1029 #2 0x4010e027 in fprintf (stream=0x401aea20, format=0x8119d18 "loading perl module '%s'...") at fprintf.c:32 #3 0x806d0c0 in perl_require_module () #4 0x806b40c in perl_section () #5 0x806b231 in perl_section_self_boot () #6 0x8068d8e in perl_cmd_require () #7 0x8081f29 in invoke_cmd () #8 0x80822ac in ap_handle_command () #9 0x806acb7 in perl_handle_command () #10 0x806b826 in perl_section () #11 0x806b231 in perl_section_self_boot () #12 0x8068d8e in perl_cmd_require () #13 0x8081f29 in invoke_cmd () #14 0x80822ac in ap_handle_command () #15 0x806acb7 in perl_handle_command () #16 0x806b826 in perl_section () #17 0x806b231 in perl_section_self_boot () #18 0x8068d8e in perl_cmd_require () #19 0x8081f29 in invoke_cmd () #20 0x80822ac in ap_handle_command () snip a whole bunch of repetitions of steps 15-20 #5889 0x806acb7 in perl_handle_command () #5890 0x806b826 in perl_section () #5891 0x806b231 in perl_section_self_boot () #5892 0x8068c6c in perl_cmd_module () #5893 0x8081f29 in invoke_cmd () #5894 0x80822ac in ap_handle_command () #5895 0x80822f8 in ap_srm_command_loop () #5896 0x80827ed in ap_process_resource_config () #5897 0x8085f28 in include_config () #5898 0x808206c in invoke_cmd () #5899 0x80822ac in ap_handle_command () #5900 0x806acb7 in perl_handle_command () #5901 0x806b043 in perl_handle_command_av () #5902 0x806b9d8 in perl_section () #5903 0x808206c in invoke_cmd () #5904 0x80822ac in ap_handle_command () #5905 0x80822f8 in ap_srm_command_loop () #5906 0x80827ed in ap_process_resource_config () #5907 0x8082e74 in ap_read_config () #5908 0x808a745 in main () #5909 0x400d89cb in __libc_start_main (main=0x808a560 main, argc=4, argv=0xb914, init=0x8062524 _init, fini=0x811741c _fini, rtld_fini=0x4000ae60 _dl_fini, stack_end=0xb90c) at ../sysdeps/generic/libc-start.c:92 And when I run with "MOD_PERL_TRACE=all" I get a whole bunch of output. It starts out like this: perl_parse args: '/dev/null' ...allocating perl interpreter...ok constructing perl interpreter...ok ok running perl interpreter...ok mod_perl: 0 END blocks encountered during server startup loading perl module 'Apache'...loading perl module 'Apache::Constants::Exports'...ok ok loading perl module 'Tie::IxHash'...ok SVt_PV: $Group = `mschout' handle_command (Group mschout): OK SVt_PV: $ServerAdmin = `[EMAIL PROTECTED]' handle_command (ServerAdmin [EMAIL PROTECTED]): OK perl_section: /Location perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files perl_section: /Files SVt_PV: $ServerRoot = `/nis.home/mschout/httpd' handle_command (ServerRoot /nis.home/mschout/httpd): OK SVt_PV: $User = `mschout' handle_command (User mschout): OK perl_section: /Directory loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok PORTS CONFIGURATION HTTP : 8531 HTTPS: 4531 `@Listen' directive is TAKE1, (2 elements) default: iterating over @Listen handle_command (Listen 8531): OK handle_command (Listen "4531"): OK perl_section: /Location perl_section: VirtualHost _default_:4531 SSLVerifyDepth 10 (OK) Limit=no SSLCertificateKeyFile /etc/httpd/conf/ssl.key/server.key (OK) Limit=no SSLCertificateFile /etc/httpd/conf/ssl.crt/server.crt (OK) Limit=no SSLVerifyClient none (OK) Limit=no SSLEngine on (OK) Limit=no handle_command (SetEnvIf "User-Agent" ".*MSIE.*" "nokeepalive" "ssl-unclean-shutdown"): OK perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files SVt_PV: $Port = `8531' handle_command (Port 8531): OK perl_section: /Files perl_section: /Directory loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok SVt_PV: $DAVLockDB = `/var/tmp/DAVLock.mschout' handle_command (DAVLockDB /var/tmp/DAVLock.mschout): OK `@Listen' directive is TAKE1, (0 elements) default: iterating over @Listen perl_section: /Location perl_section: /VirtualHost perl_section: /Directory perl_section: /Location perl_section: /Files perl_section: /Files perl_section: /Directory SVt_PV: $DAVMinTimeout = `600' handle_command (DAVMinTimeout 600): OK loading perl module 'Apache'...ok loading perl module 'Tie::IxHash'...ok
Re: possible bug in mod_perl 1.24_01
I should also have mentioned: I am using perl 5.6.0, Linux 2.2.x I used the same perl / os for both apache1.3.12/mod_perl 1.24, and apache 1.3.14/mod_perl 1.24_01. Mike
Re: Bug in mod_perl
On Mon, 9 Oct 2000, Dave Rolsky wrote: I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive no output after the \0. Is this a mod_perl or Apache bug? Or is it a client bug (using Netscape 4.75) or is it the expected behavior. looks ok to me: % telnet localhost 8529 Trying 127.0.0.1... Connected to localhost (127.0.0.1). Escape character is '^]'. GET /foo http/1.0 HTTP/1.1 200 OK Date: Fri, 13 Oct 2000 17:35:52 GMT Server: Apache/1.3.15-dev (Unix) mod_perl/1.24_02-dev Perl/v5.7.0 Connection: close Content-Type: text/plain abc abcdef def Connection closed by foreign host. strace shows the \0 coming across: 5406 read(4, "HTTP/1.1 200 OK\r\nDate: Fri, 13 Oct 2000 17:38:47 GMT\r\nServer: Apache/1.3.15-dev (Unix) mod_perl/1.24_02-dev Perl/v5.7.0\r\nConnection: close\r\nContent-Type: text/plain\r\n\r\nabc\nabc\0def\ndef\n", 4096) = 184
Bug in mod_perl
Try the following handler:
package Foo;
use Apache::Request;
sub handler
{
my $r = shift;
my (@vars) = ( 'abc', "abc\0def", "def" );
$r-send_http_header;
$r-print("$_\n") foreach @vars;
}
1;
I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive
no output after the \0. Is this a mod_perl or Apache bug? Or is it a
client bug (using Netscape 4.75) or is it the expected behavior.
-dave
/*==
www.urth.org
We await the New Sun
==*/
Re: Bug in mod_perl
Interesting, the Mason bug report I just filed is obviously mis-filed.
Apache::Registry scripts suffer the same behaviour.
On Mon, 9 Oct 2000, Dave Rolsky wrote:
Try the following handler:
package Foo;
use Apache::Request;
sub handler
{
my $r = shift;
my (@vars) = ( 'abc', "abc\0def", "def" );
$r-send_http_header;
$r-print("$_\n") foreach @vars;
}
1;
I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive
no output after the \0. Is this a mod_perl or Apache bug? Or is it a
client bug (using Netscape 4.75) or is it the expected behavior.
-dave
/*==
www.urth.org
We await the New Sun
==*/
--
[EMAIL PROTECTED] | Drive thy business, or it will drive thee.
http://BareMetal.com/ | - Benjamin Franklin
web hosting since '95 |
Re: Bug in mod_perl
I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive
no output after the \0. Is this a mod_perl or Apache bug? Or is it a
client bug (using Netscape 4.75) or is it the expected behavior.
It would be expected, I'd assume. perl5-porters discussed this back
in January when phrack ran an article claiming it was a 'bug' with
security implications. To summarize, this isn't really bug, but
merely what you'd expect when the PV gets passed to a C function
which expects a NULL terminated string.
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00020.html
.g
--
- Crack RC5-64 with Bovine: http://www.distributed.net/rc5/ -
#!/bin/perl -sp0777iX+d*lMLa^*lN%0]dsXx++lMlN/dsM0j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
Re: Bug in mod_perl
[EMAIL PROTECTED] (Greg Williams) wrote: I'm using mod_perl 1.24/Apache 1.3.12/Perl 5.00503 and find that I receive no output after the \0. Is this a mod_perl or Apache bug? Or is it a client bug (using Netscape 4.75) or is it the expected behavior. It would be expected, I'd assume. perl5-porters discussed this back in January when phrack ran an article claiming it was a 'bug' with security implications. To summarize, this isn't really bug, but merely what you'd expect when the PV gets passed to a C function which expects a NULL terminated string. http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-01/msg00020.html I think I disagree with not calling this a bug. The entire p5p discussion was about the fact that *system calls* will see \0 as the end-of-string character, which in some cases is kind of a bad thing. However, Dave's code is just trying to send some *data* to the browser. It appears that $r-print (or somewhere down in the Apache code) can't handle embedded nulls, which I think should be either documented or fixed. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: Bug? in mod_perl when POST request yields REDIRECT
On Wed, 6 Sep 2000, Reif Peter wrote:
I am using a self written mod_perl module that does proxy requests. It acts
as content handler and fetches the requestet documents via LWP::UserAgent.
The program works fine but when the request is a POST request and the
response is a redirection (301, 302, ...) with a Location: header, no data
is sent to the browser.
If I don't read the postet data, everything works. So my suspicion is the
following:
For any reason, if the module returns a redirecting result code (301, 302,
...), mod_perl tries to read again the posted data and waits forever.
My solution is simple: Just set the Content-lengt: header to undef:
$r-header_in('Content-length' = undef);
Is this a bug or a feature?
it's a known issue, from the ToDo:
"- should $r-content unset $r-headers_in('content-length') ?
NOTE: im worried this could break apps who need to know content-length
after data has been read"
looking at mod_perl Changes:
=item 1.00b2 - 07/07/97
...
make compatible with 1.2.1 r-read_length change so we don't hang
on file uploads
the problem is that a drastic api change in Apache was made around that
time, which we had to fit into Perl's api. ap_setup_client_block() and
ap_should_client_block() are only supposed to be called once according to
the api spec. Apache.xs calls them everytime $r-read is called, and the
change above was setting r-read_length = 0; so ap_setup_client_block()
would return true the second time it is called. when a redirect or error
is thrown, ap_discard_request_body() also checks ap_should_client_block()
which returns true because we've set r-read_length = 0;
so, i think a reasonable fix for now is to localize the r-read_length
change with this patch:
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:19:20
@@ -954,7 +954,7 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
@@ -964,12 +964,15 @@
XSRETURN_UNDEF;
}
+old_read_length = r-read_length;
+r-read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r-read_length = 0;
-}
+}
+r-read_length += old_read_length;
if (nrd 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Re: Bug? in mod_perl when POST request yields REDIRECT
take 2 on that patch, this one adds a check so ap_setup_client_block() is
only called once. with this part of the fix you can call $r-content
multiple times without hanging:
my $data = $r-content;
$data = $r-content;
however, any calls to $r-content after the first will return undef.
(unless you happen to subclass and override the content method to cache
the read data somewhere)
Index: src/modules/perl/Apache.xs
===
RCS file: /home/cvs/modperl/src/modules/perl/Apache.xs,v
retrieving revision 1.109
diff -u -r1.109 Apache.xs
--- src/modules/perl/Apache.xs 2000/09/27 16:25:56 1.109
+++ src/modules/perl/Apache.xs 2000/09/27 19:38:34
@@ -954,22 +954,27 @@
int bufsiz
PREINIT:
-long nrd = 0;
+long nrd = 0, old_read_length;
int rc;
PPCODE:
-if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
- aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r-server,
- "mod_perl: setup_client_block failed: %d", rc);
- XSRETURN_UNDEF;
+if (!r-read_length) {
+if ((rc = setup_client_block(r, REQUEST_CHUNKED_ERROR)) != OK) {
+aplog_error(APLOG_MARK, APLOG_ERR | APLOG_NOERRNO, r-server,
+"mod_perl: setup_client_block failed: %d", rc);
+XSRETURN_UNDEF;
+}
}
+old_read_length = r-read_length;
+r-read_length = 0;
+
if (should_client_block(r)) {
SvUPGRADE(buffer, SVt_PV);
SvGROW(buffer, bufsiz+1);
nrd = get_client_block(r, SvPVX(buffer), bufsiz);
-r-read_length = 0;
-}
+}
+r-read_length += old_read_length;
if (nrd 0) {
XPUSHs(sv_2mortal(newSViv((long)nrd)));
Bug? in mod_perl when POST request yields REDIRECT
I am using a self written mod_perl module that does proxy requests. It acts
as content handler and fetches the requestet documents via LWP::UserAgent.
The program works fine but when the request is a POST request and the
response is a redirection (301, 302, ...) with a Location: header, no data
is sent to the browser.
If I don't read the postet data, everything works. So my suspicion is the
following:
For any reason, if the module returns a redirecting result code (301, 302,
...), mod_perl tries to read again the posted data and waits forever.
My solution is simple: Just set the Content-lengt: header to undef:
$r-header_in('Content-length' = undef);
Is this a bug or a feature?
I include my module and the part of my server config.
Peter
Server config:
==
Directory proxy:
SetHandler perl-script
PerlHandler Apache::Proxy_test
/Directory
Proxy_test.pm:
==
package Apache::Proxy_test;
use strict;
use Apache::Constants qw(:response :methods :http);
use Apache::File ();
use Apache::Log ();
use Apache::ModuleConfig ();
use Apache::Table;
use Apache::URI ();
use LWP::UserAgent ();
my $UA = LWP::UserAgent-new;
sub handler {
my $r = shift;
my $not_modified = $r-meets_conditions == HTTP_NOT_MODIFIED;
#
# create request
#
my $filename = $r-filename();
$filename =~ s/^proxy://;
my $parsed_uri = $r-parsed_uri;
my $query = $parsed_uri-query;
$filename .= "?$query" if $query;
$r-log-debug ("filename: $filename");
my $request = HTTP::Request-new($r-method, $filename);
$UA-agent ($r-header_in ('User-Agent'));
# copy POST data, if any
if($r-method eq 'POST') {
my $len = $r-header_in('Content-length');
my $buf;
my $ret = read(STDIN, $buf, $len);
$request-content($buf);
# next line prevents bug !!!
$r-header_in('Content-length' = undef);
}
$r-log-debug ("subrequest:\n\n", $request-as_string);
#
# evaluate response
#
my $response = $UA-simple_request($request);
if ($response-code != 200) {
$r-log-debug ("response not OK:\n\n",
$response-as_string);
$response-scan(sub {
my ($header, $value) = @_;
$r-log-debug ("Header-out: $header $value");
$r-header_out($header, $value);
});
} else {
$r-content_type($response-header('Content-type'));
$r-status($response-code);
$r-status_line(join " ", $response-code,
$response-message);
$r-send_http_header();
unless ($r-header_only) {
print $response-content;
}
}
$r-log-debug("send:\n\n", $r-as_string);
$r-log-debug("return ", $response-code);
return $response-code;
}
1;
__END__
Fwd: apache_1.3.12 / mod_perl-1.22 ... Bug in mod_perl 1.22 on certain platform ?
Hi
Following to my last email, I tried to build apache_1.3.12 with mod_perl-1.21.
And it worked well with the same makepl_args.mod_perl file .
So does that mean that there is a bug in mod_perl-1.22 ? Or That my conf file
had wrong arguments in it, even if I could build it on an other server (see my
other email)?
Fred
-
here is my make makepl_args.mod_perl file :
#example makepl_args.mod_perl files
#copy this file to $ENV{HOME}/.makepl_args.mod_perl and edit to taste
#mod_perl's Makefile.PL will also look for this file in ./ ../ relative
#to the mod_perl-x.xx source tree
#EVERYTHING=1 will enable:
#ALL_HOOKS=1 PERL_SSI=1 PERL_SECTIONS=1
#PERL_STACKED_HANDLERS=1 PERL_METHOD_HANDLERS=1 PERL_TABLE_API=1
EVERYTHING=1
#build against the first apache_x.xx source tree found, without prompts
# DO_HTTPD=1
DO_HTTPD=1
#could tell Makfile.PL exactly where the source is
# APACHE_SRC=/tmp/apache_x.xx/src
APACHE_SRC=../apache_1.3.12/src
#this would configure in mod_proxy, mod_unique_id, mod_info and mod_status
# ADD_MODULE=proxy,usertrack,unique_id,info,status
ADD_MODULE=info,status
#if you wish to use a Configuration file other than what's in the
#apache_x.xx/src directory
# CONFIG=Configuration.custom
#depending on your os and site_perl modules, see mod_perl's INSTALL
# PERL_STATIC_EXTS=...
#apache header files are installed by default, stop that if you wish
# APACHE_HEADER_INSTALL=0
#Apache and Apache::Constants modules will be built as shared libraries
# DYNAMIC=1
DYNAMIC=1
USE_APACI=1
APACI_ARGS=--enable-module=so
#turn on mod_perl tracing
# PERL_TRACE=1
#for perl.c's perl_destruct() which in run by mod_perl during child_exit
#comment from perl.c: /* 0=none, 1=full, 2=full with checks */
#default level is 0
# PERL_DESTRUCT_LEVEL=2
#-add `-g' to EXTRA_CFLAGS
#-turn on PERL_TRACE
#-set PERL_DESTRUCT_LEVEL=2
#-link against libperld if -e $Config{archlibexp}/CORE/libperld$Config{lib_ext}
# PERL_DEBUG=1
#
#experimental features, use at own risk
#but please report success or failure if you try
#try to stop "Use of uninitialized value." with no line/filename info
# PERL_MARK_WHERE=1
--
--
| Frédéric Schwien
| Administrateur WebMails.com
| E-mail: [EMAIL PROTECTED] Solutions Internet/Intranet sécurisées"
|http://www.igtech.fr
|Centre de Formation Agréé
|CheckPoint Software
| 153, avenue Jean Lolive
| 93500 Pantin
| Tél: 33 (0) 1 56 96 01 23
| Fax: 33 (0) 1 56 96 01 33
|Votre Email gratuit et sécurisé : http://www.webmails.com
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
On Tue, 11 Apr 2000, Ardo van Rangelrooij wrote: Hi! Hi, Steve Dunham (thanks!!!)provided a patch which should take care of this problem. I've made a package available as http://master.debian.org/~ardo/libxml-parser-perl_2.27-3_i386.deb Please try it out and let me know what's up. If no problems occur I'll upload it to master officially. OK, I will run it later today on my machine with the test-script, and then with the project I'm working on, which is more complex and crashed much fatser. I'll also forward this problem to the man upstream, Clark Cooper. Thanks, Ardo I'll let you know... Thanx, Remco Schaar /--\ | Remco Schaar | | e-mail: [EMAIL PROTECTED] | \--/ South Park meets Linux: - "Oh my God, they killed init!" - "You bastards!"
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
On Tue, 11 Apr 2000, Ardo van Rangelrooij wrote: Hi! Steve Dunham (thanks!!!)provided a patch which should take care of this problem. I've made a package available as http://master.debian.org/~ardo/libxml-parser-perl_2.27-3_i386.deb Please try it out and let me know what's up. If no problems occur I'll upload it to master officially. After running it several hours, using 3-4 different scripts each refreshing every second, the only problem I encountered was an unstable netscape (when using a refresh of _zero_ seconds :-) So, I consider the bg fixed and recommend the upload... I'll also forward this problem to the man upstream, Clark Cooper. Thanks, Ardo Thanks everybody, Remco Schaar /--\ | Remco Schaar | | e-mail: [EMAIL PROTECTED] | \--/ South Park meets Linux: - "Oh my God, they killed init!" - "You bastards!"
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
Hi! Steve Dunham (thanks!!!)provided a patch which should take care of this problem. I've made a package available as http://master.debian.org/~ardo/libxml-parser-perl_2.27-3_i386.deb Please try it out and let me know what's up. If no problems occur I'll upload it to master officially. I'll also forward this problem to the man upstream, Clark Cooper. Thanks, Ardo Daniel Jacobowitz [EMAIL PROTECTED] writes: reassign 61231 libxml-parser-perl thanks And sure enough, the man is right. This is not mod_perl's problem. When I disable RULE_EXPAT, apache ceases crashing. On Tue, Apr 04, 2000 at 02:49:36PM -0700, Doug MacEachern wrote: On Tue, 4 Apr 2000, Daniel Jacobowitz wrote: [mod_perl people - any comment? Please keep the Cc: list to the Debian bug tracking system.] When using the XML::Parser::Expat under mod_perl, this causes segmentation faults (quite random?) in the child-processes of httpd. The error message in the error.log of apache is: "[notice] child pid 28177 exit signal Segmentation fault (11)" yeah, try configuring Apache with: RULE_EXPAT=no otherwise, the symbols in XML::Parser clash with apache's. i've suggested several times that the XML::Parser author should consider making those symbols static or use a different prefix, but no idea if that's happened or not. -- Ardo van Rangelrooij home email: [EMAIL PROTECTED], [EMAIL PROTECTED] home page: http://home.flevonet.nl/~avrangel PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
[mod_perl people - any comment? Please keep the Cc: list to the Debian bug tracking system.] On Tue, Mar 28, 2000 at 12:50:45PM +0200, [EMAIL PROTECTED] wrote: Package: libapache-mod-perl Version: 1.21.2309-1 Severity: Important When using the XML::Parser::Expat under mod_perl, this causes segmentation faults (quite random?) in the child-processes of httpd. The error message in the error.log of apache is: "[notice] child pid 28177 exit signal Segmentation fault (11)" This can be repreduced with the following script, run under mod_perl, just wait a while, and monitor the error.log (takes a while, multiple request will speed up): It's very random, but I can reproduce this. However, I can also reproduce it with apache-perl (statically linked). It seems extremely unlikely to me that this is the DSO code's fault, therefore. Here's a backtrace: (gdb) bt #0 0x400f8b59 in free () from /lib/libc.so.6 #1 0x400f89ed in free () from /lib/libc.so.6 #2 0x4026eb7a in Perl_safefree () from /usr/lib/apache/1.3/mod_perl.so #3 0x4027fcb9 in Perl_sv_setsv () from /usr/lib/apache/1.3/mod_perl.so #4 0x402782dc in Perl_pp_sassign () from /usr/lib/apache/1.3/mod_perl.so #5 0x402a8440 in Perl_runops_standard () from /usr/lib/apache/1.3/mod_perl.so #6 0x4024c0a9 in perl_call_sv () from /usr/lib/apache/1.3/mod_perl.so #7 0x4023201e in perl_call_handler () from /usr/lib/apache/1.3/mod_perl.so #8 0x402318cc in perl_run_stacked_handlers () from /usr/lib/apache/1.3/mod_perl.so #9 0x402302cf in perl_handler () from /usr/lib/apache/1.3/mod_perl.so #10 0x8053e64 in ap_invoke_handler (r=0x826e23c) at http_config.c:508 #11 0x80625ec in process_request_internal (r=0x826e23c) at http_request.c:1214 #12 0x8062648 in ap_process_request (r=0x826e23c) at http_request.c:1230 #13 0x805c439 in child_main (child_num_arg=0) at http_main.c:4122 #14 0x805c5cc in make_child (s=0x8099c24, slot=0, now=954874778) at http_main.c:4235 #15 0x805c6e9 in startup_children (number_to_start=5) at http_main.c:4317 #16 0x805cb9b in standalone_main (argc=2, argv=0xbdc4) at http_main.c:4605 #17 0x805d24d in main (argc=2, argv=0xbdc4) at http_main.c:4933 Very interesting. I'll look at this further. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
Something, presumably XML::Parser::Expat, is corrupting malloc's and
perl's data structures randomly. Running under MALLOC_CHECK_=2 has a
high probability of showing this. It also occasionally cores in
Perl_sv_upgrade - the SV is hopelessly mangled:
(gdb) p *sv
$17 = {sv_any = 0x83e58955, sv_refcnt = 2203260140, sv_flags = 821518397}
(gdb) where
#0 0x402a5b95 in Perl_sv_upgrade (sv=0x4029d868, mt=136780768) at sv.c:823
#1 0x402a5810 in Perl_sv_upgrade (sv=0x4029d868, mt=136780768) at sv.c:732
#2 0x4029d93d in Perl_pp_or () at pp_hot.c:235
#3 0x4025c266 in Perl_moreswitches (s=0x81a14a4 "PZ\n\b\001") at perl.c:1641
#4 0x4024061e in perl_create_request_config ()
from /usr/lib/apache/1.3/mod_perl.so
#5 0x4023fcf1 in perl_config_getch () from /usr/lib/apache/1.3/mod_perl.so
#6 0x4023de1f in perl_fixup () from /usr/lib/apache/1.3/mod_perl.so
#7 0x8053e64 in ap_invoke_handler (r=0x8289a7c) at http_config.c:508
#8 0x80625ec in process_request_internal (r=0x8289a7c) at http_request.c:1214
#9 0x8062648 in ap_process_request (r=0x8289a7c) at http_request.c:1230
#10 0x805c439 in child_main (child_num_arg=0) at http_main.c:4122
#11 0x805c5cc in make_child (s=0x8099c2c, slot=0, now=954878307)
at http_main.c:4235
#12 0x805c6e9 in startup_children (number_to_start=5) at http_main.c:4317
#13 0x805cb9b in standalone_main (argc=2, argv=0xbdb4) at http_main.c:4605
#14 0x805d24d in main (argc=2, argv=0xbdb4) at http_main.c:4933
However, I don't think that's a reliable stack trace. The stack seems damaged.
On Tue, Mar 28, 2000 at 12:50:45PM +0200, [EMAIL PROTECTED] wrote:
Package: libapache-mod-perl
Version: 1.21.2309-1
Severity: Important
When using the XML::Parser::Expat under mod_perl, this causes segmentation
faults (quite random?) in the child-processes of httpd.
The error message in the error.log of apache is:
"[notice] child pid 28177 exit signal Segmentation fault (11)"
This can be repreduced with the following script,
run under mod_perl, just wait a while, and monitor the error.log (takes a
while, multiple request will speed up):
--- cut here -
#!/usr/bin/perl -w
use XML::Parser::Expat;
use strict;
main();
# bug creater under mod_perl, just results in some simple html
sub main()
{
my $problemXP = new XML::Parser::Expat;
$problemXP-setHandlers(Start = \Start, End = \End, Char = \Text);
print "Content-type: text/html\n\n";
$problemXP-parse("html\nmeta http-equiv='refresh' content='1'/\nbodysome
text/body\n/html\n");
$problemXP-release();
}
sub Start($$) {
my $caller = shift;
my $tag = shift;
print "" . $tag;
print " " . $_[0] . "='" . $_[1] . "'" if $#_ ge 1; # add attributes
print " " . $_[2] . "='" . $_[3] . "'" if $#_ ge 3; # add attributes
print "\n" unless $tag =~ /\s/;
}
sub End($$) {
my $caller = shift;
my $etag = shift;
print "/" . $etag . "\n" unless $etag =~ /\s/;
}
sub Text($$) {
my $caller = shift;
my $text = shift;
print $text . "\n" unless $text =~ /\s/;
}
--- cut here -
I guess this is caused by a memory-leak or a problem related to loading
Perl *.so (see bug #48069)
Related packages (frozen/potato, 27 march 2000):
- libapache-mod-perl 1.21.2309-1
- apache-common 1.3.9-12
- apache-ssl 1.3.9.10 + 1.37-1
- libxml-parser-perl 2.27-2
- perl-5.005 5.005.03-6
- perl-5.005-base 5.005.03-6
- libmime-base64-perl 2.11-2
- libdevel-symdump-perl 2.00-4
- data-dumper 2.09-1
- liburi-perl 1.04-2
- libc6 2.1.3-7
- libdb2 2.4.14-9
- libgdbmg1 1.7.3-26.2
kernel 2.2.14 (i586 and i686)
libc-2.1.3.so
* ( didn't encouter with slink, but i am not sure, used CPAN
instead of libxml-parser-perl.deb...)
used configuration:
httpd.conf:
LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config_ssl.so
LoadModule mime_module /usr/lib/apache/1.3/mod_mime_ssl.so
LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
LoadModule status_module /usr/lib/apache/1.3/mod_status.so
LoadModule includes_module /usr/lib/apache/1.3/mod_include.so
LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
LoadModule cgi_module /usr/lib/apache/1.3/mod_cgi.so
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
LoadModule alias_module /usr/lib/apache/1.3/mod_alias.so
LoadModule rewrite_module /usr/lib/apache/1.3/mod_rewrite.so
LoadModule access_module /usr/lib/apache/1.3/mod_access.so
LoadModule auth_module /usr/lib/apache/1.3/mod_auth_ssl.so
LoadModule expires_module /usr/lib/apach
Re: Bug#61231: mod_perl segfaults child-processes in combinationwith XML::Parser::Expat
On Tue, 4 Apr 2000, Daniel Jacobowitz wrote: [mod_perl people - any comment? Please keep the Cc: list to the Debian bug tracking system.] When using the XML::Parser::Expat under mod_perl, this causes segmentation faults (quite random?) in the child-processes of httpd. The error message in the error.log of apache is: "[notice] child pid 28177 exit signal Segmentation fault (11)" yeah, try configuring Apache with: RULE_EXPAT=no otherwise, the symbols in XML::Parser clash with apache's. i've suggested several times that the XML::Parser author should consider making those symbols static or use a different prefix, but no idea if that's happened or not.
Bug in mod_perl makefile?
Hi, I've just got my apache/modperl setup to work. This little nastie took me 2 days to find. In my /usr/src directory, I had: - apache_1.3.3 [dir] - apache_1.3.9 [dir] - mod_perl-1.21 [dir] and was compiling modperl/perl with: #perl Makefile.PL APACHE_SRC=/usr/src/apache_1.3.9 DO_HTTPD=1 USE_APACI=1 EVERYTHING=1 PERL_MARK_WHERE=1 APACI_ARGS=--enable-module=all #make make test make install and then a make install from apache_1.3.9 This setup was consistently failing, or rather ... - if I added --enable-shared=max apache compiled and started unless a call to mod_perl was made. If I tryed to load Embperl in httpd.conf, httpd would not start, claiming that Apache::Constants was not installed/found/whatever. - I upgraded perl, recompiled perl + all the perl modules I had + mod-perl + apache again. Several recompiles and shrieks. Now, today, with a fresh head, I noticed a little message when making mod_perl, which said it was 'getting into ../apache_1.3.3'. So I renamed the directory to be called old.apache_1.3.3 and recompiled. Voilá! So either my APACHE_SRC argument was wrong (I swear I read it in Stas' Guide) or the Makefile was ignoring it... Sadly, I'm going holidays tonight, so I can't [and won't] stay here to dissect Makefile.PL, but I thought it was nice to tell the list. Now if you find it was my mistake, one way or another, then please forgive me for saying the bug was yours [whoever wrote the makefile] when it was mine. ml -- -- To understand recursion, one must first understand recursion. -- -- - Martin Langhoff @ S C I M Multimedia Technology - - http://www.scim.net | God is real until - - mailto:[EMAIL PROTECTED] | declared integer -
Re: Bug in mod_perl makefile?
On Thu, 3 Feb 2000, Martin A. Langhoff wrote:
Hi,
I've just got my apache/modperl setup to work. This little nastie
took me 2 days to find.
In my /usr/src directory, I had:
- apache_1.3.3 [dir]
- apache_1.3.9 [dir]
- mod_perl-1.21 [dir]
and was compiling modperl/perl with:
#perl Makefile.PL APACHE_SRC=/usr/src/apache_1.3.9 DO_HTTPD=1
USE_APACI=1 EVERYTHING=1 PERL_MARK_WHERE=1
APACI_ARGS=--enable-module=all
#make make test make install
and then a make install from apache_1.3.9
This setup was consistently failing, or rather ...
- if I added --enable-shared=max apache compiled and started
unless a call to mod_perl was made. If I tryed to load Embperl in
httpd.conf, httpd would not start, claiming that Apache::Constants was
not installed/found/whatever.
- I upgraded perl, recompiled perl + all the perl modules I had
+ mod-perl + apache again. Several recompiles and shrieks.
Now, today, with a fresh head, I noticed a little message when
making mod_perl, which said it was 'getting into ../apache_1.3.3'. So I
renamed the directory to be called old.apache_1.3.3 and recompiled.
Voilá!
So either my APACHE_SRC argument was wrong (I swear I read it in
Stas' Guide) or the Makefile was ignoring it...
Seems to me like you forgot to make clean before rebuilding stuff. A few
folks reported in the past that starting from clean tar solved their
problems.
As for the APACHE_SRC, the scenario you have described can only happen if
you provided invalid APACHE_SRC paramter. Here is the relevant snippet
from Makefile.PL:
for $src_dir ($APACHE_SRC, ../apache*/src,
../stronghold*/src, /usr/local/stronghold*/src,
"../src", "./src")
{
next unless -d $src_dir;
next if $seen{$src_dir}++;
next unless $vers = httpd_version($src_dir);
unless(exists $vers_map{$vers}) {
print STDERR "Apache version '$vers' unsupported\n";
next;
}
$mft_map{$src_dir} = $vers_map{$vers};
#print STDERR "$src_dir - $vers_map{$vers}\n";
push @adirs, $src_dir;
$modified{$src_dir} = (stat($src_dir))[9];
last if $DO_HTTPD;
}
If $APACHE_SRC is defined correctly relative to mod_perl src tree, the
'for' loop goes thru only once.
Now if you find it was my mistake, one way or another, then please
forgive me for saying the bug was yours [whoever wrote the makefile]
when it was mine.
The bad thing is that you report about a potential problem, but don't stay
with us to follow up. So I thought twice before replying to your email,
since I feel that I talk to the wall until before you come back from your
vacation...
Enjoy the vacation :)
___
Stas Bekmanmailto:[EMAIL PROTECTED] http://www.stason.org/stas
Perl,CGI,Apache,Linux,Web,Java,PC http://www.stason.org/stas/TULARC
perl.apache.orgmodperl.sourcegarden.org perlmonth.comperl.org
single o- + single o-+ = singlesheavenhttp://www.singlesheaven.com
Re: Fix for Redhat(?) bug in mod_perl install
On Sat, 4 Dec 1999, Autarch wrote: I don't remember if this has been discussed before but anyway. If you're running Redhat 6.0 (and maybe 6.1?) Just this moment installed a RH-6.1 system. It did not exhibit this problem. there may be some weirdness when you try to install modperl. Basically, when you go to run make on apache, it gives it some -L or -I flags that include libgdbm, because your Perl was compiled with this. However, there is a missing symlink in the /usr/lib directory. Just do the following to fix it: ln -s libgdbm.so.2.0.0 libgdbm.so This should probably be added to the guide or something. The failure message you get is the compile failed the sanity check, with no mention of libgdbm at all. It's pretty wacky! -- -- Tom Mornini -- InfoMania Printing and Prepress
Fix for Redhat(?) bug in mod_perl install
I don't remember if this has been discussed before but anyway. If you're running Redhat 6.0 (and maybe 6.1?) there may be some weirdness when you try to install modperl. Basically, when you go to run make on apache, it gives it some -L or -I flags that include libgdbm, because your Perl was compiled with this. However, there is a missing symlink in the /usr/lib directory. Just do the following to fix it: ln -s libgdbm.so.2.0.0 libgdbm.so This should probably be added to the guide or something. The failure message you get is the compile failed the sanity check, with no mention of libgdbm at all. It's pretty wacky! -Dave /*== www.urth.org We await the New Sun ==*/
