Re: [mp2] segfault using Time::Piece and mod_perl2 on Debian
Cees Hek wrote: I was getting segfaults with mod_perl2 (1.99_10 on 2.0.48) on my development box today. After a lot of searching, it turns out it was because of a problem with Time::Piece. I could recreate it by placing 'use Time::Piece::MySQL' in the startup.pl file. This would cause the server to segfault on startup. Time::Piece::MySQL has a BEGIN statement that calls 'strptime' in Time::Piece, and that was triggering the Segfault. I thought it had to be mod_perl2, because Time::Piece worked fine on it's own and appeared to work under mod_perl1 as well, just not under mod_perl2. However, it turns out that by re-compiling Time::Piece the problem went away. I was using a debian package libtime-piece-perl 1.08-2 and debian perl 5.8.1-4 (threaded). Are you sure that both libtime-piece-perl and modperl were compiled with that same perl. is it possible that libtime-piece-perl was compiled against 5.8.0? In which case the issue is clear: 5.8.0 and 5.8.1 aren't binary compatible, and one has to recompile XS modules when moving to 5.8.1. That was of course not intentional and 5.8.2 (which will be released shortly) restores the binary compatibility with 5.8.0. By reinstalling and recompiling Time::Piece using CPAN (still version 1.08), the problem went away. [...] __ 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: [Fwd: AuthenNTLM and slow web server]
Shannon Eric Peevey wrote: Original Message Subject: AuthenNTLM and slow web server Date: Thu, 30 Oct 2003 17:59:49 +0100 From: Stefano Ciancio <[EMAIL PROTECTED]> Organization: Italia On Line To: [EMAIL PROTECTED] Hi, I am using the apache module Apache-AuthenNTLM-2.04 with apache 1.3, but I am having some problem with it. I view some time_wait session to windows pdc and many error in apache's error.log. Moreover this also seems to cause the web server to go _very_ slow. My httpd.conf configuration is standard PerlAuthenHandler Apache::AuthenNTLMAuthType ntlm,basic AuthName test require valid-user PerlAddVar ntdomain "name_domain1 name_of_pdc1" PerlAddVar ntdomain "other_domain pdc_for_domain bdc_for_domain" PerlSetVar defaultdomain wingr1 PerlSetVar ntlmdebug 0 with keepAlive setted to On. Have you an an idea why this is happening? Thanks, Stefano Hi! Can you set "ntlmdebug" = 2 and send me the sections of the error_log that you are talking about? thanks, speeves cws BTW, did you have this working correctly with any other version Apache-AuthenNTLM?
Re: [mp2] segfault using Time::Piece and mod_perl2 on Debian
Quoting Stas Bekman <[EMAIL PROTECTED]>: > Cees Hek wrote: > Are you sure that both libtime-piece-perl and modperl were compiled with that > > same perl. is it possible that libtime-piece-perl was compiled against 5.8.0? Since it was a debian package, I am not sure which perl it was compiled against, but you are probably right. I figured it was a debian problem, but I was confused as to why the segfault was happening in mod_perl (mod_perl was definately compiled against 5.8.1 by the way), and it wasn't occuring when using it on the command line. Anyway, I will check with the debian guys to make sure it gets resolved. Cheers, Cees
RE: [mp2] CGI.pm param's always empty from only some clients (bug or mistake on my part?)
> There are two things I'd suggest to try:
>
> 1) pass $r to CGI->new($r), in which case it won't rely on the global
> Apache->request. And you can switch then to 'PerlHandler modperl'.
I tried this first, no luck.
> 2) use the IO trace to debug what's going on:
>
> you need to rebuild mp with MP_TRACE=1 and then add to httpd.conf:
>
>PerlTrace o
>
> http://perl.apache.org/docs/2.0/user/config/config.html#C_PerlTrace_
>
> compare the traces you get on the good and the bad machines.
I did this, and the result is interesting to me.
First, as a side note, when I put 'PerlTrace o' in the httpd.conf right off
the bat, Apache segfaulted on restart. So then I instead put the following
in the
section: ' $ENV{MOD_PERL_TRACE} = "o";' and it started fine.
Oh and another side note... today I discovered that I am now seeing the
issue
from my own client here on my windows workstation *sometimes*. So it's no
longer
a per client issue.
The trace is quote noisy considering the size of the pages I am returning,
but
let me try to paraphrase the juicy bits (at least to my untrained eyes):
- error_log --
[Fri Oct 31 10:12:58 2003] [notice] SIGHUP received. Attempting to restart
[Fri Oct 31 10:12:58 2003] [notice] seg fault or similar nasty error
detected in the parent process
mod_perl trace flags dump:
[Fri Oct 31 10:16:13 2003] [warn] pid file /usr/local/apache/logs/httpd.pid
overwritten -- Unclean shutdown of previous Apache run?
[Fri Oct 31 10:16:13 2003] [notice] Apache/2.0.48 (Unix) mod_perl/1.99_10
Perl/v5.8.0 configured -- resuming normal operations
*** reading POST data: CGI/usr/lib/perl5/5.8.0/CGI.pm518 at (eval 18) line
8.
PerlIOApache_read: wanted 3362b, read 189b
[f_table=R_rtrallint05m_&f_colour_availability_admin=%23F4E204&f_colour_avai
lability_oper
ational=%23F4B904&f_vars=bits_in&f_colour_bits_in=%23F4E204&f_vars=bits_out&
f_colour_bits_out=%23F4B9;
PerlIOApache_write: 48 bytes [
PerlIOApache_read: wanted 3361b, read 28b
[f_table=R_rtrallint05m_&f_cotipart {
*** reading POST data: CGI/usr/lib/perl5/5.8.0/CGI.pm518 at (eval 18) line
8.
PerlIOApache_read: wanted 3361b, read 3361b
[f_table=R_rtrallint05m_&f_colour_availability_admin=%23F4E204&f_colour_avai
lability_ope
)
- /error_log -
So in summary, it seems there is an issue reading all the form data on the
requests that do not work. The variable that I use to determine which
sub-routine to call is the submit button which, not surprisingly, comes last
and so is being cut off. In case you missed it above, the square brackets
which are seemingly supposed to contain the data that is read are not closed
until AFTER the source code that appears. Buffer issues?
Just in case it is of interest, here is the source that is printed during
the failed read:
- error_log --
PerlIOApache_read: wanted 3362b, read 189b
[f_table=R_rtrallint05m_&f_colour_availability_admin=%23F4E204&f_colour_avai
lability_oper
ational=%23F4B904&f_vars=bits_in&f_colour_bits_in=%23F4E204&f_vars=bits_out&
f_colour_bits_out=%23F4B9;
my(%header,$body);
my $filenumber = 0;
while (!$buffer->eof) {
%header = $buffer->readHeader;
unless (%header) {
$self->cgi_error("400 Bad request (malformed multipart POST)");
return;
}
my($param)= $header{'Content-Disposition'}=~/ name="?([^\";]*)"?/;
$param .= $TAINTED;
# Bug: Netscape doesn't escape quotation marks in file names!!!
my($filename) = $header{'Content-Disposition'}=~/
filename="?([^\"]*)"?/;
# Test for Opera's multiple upload feature
my($multipart) = ( defined( $header{'Content-Type'} ) &&
$header{'Content-Type'} =~ /multipart\/mixed/ ) ?
1 : 0;
# add this parameter to our list
$self->add_parameter($param);
# If no filename specified, then just read the data and assign it
# to our parameter list.
if ( ( !defined($filename) || $filename eq '' ) && !$multipart ) {
my($value) = $buffer->readBody;
$value .= $TAINTED;
push(@{$self->{$param}},$value);
next;
}
my ($tmpfile,$tmp,$filehandle);
UPLOADS: {
# If we get here, then we are dealing with a potentially large
# uploaded form. Save the data to a temporary file, then open
# the file for reading.
# skip the file if uploads disabled
if ($DISABLE_UPLOADS) {
while (defined($data = $buffer->read)) { }
last UPLOADS;
}
# set the filename to some recognizable value
if ( ( !defined($filename) || $filename eq '' ) && $multipart ) {
$filename = "multipart/mixed";
}
# choose a relatively unpredictable tmpfile sequence number
my $seqno = unpack("%16C*",join('',localtime,values %ENV));
for (my $cnt=10;$cnt>0;$cnt--) {
next unless $tmpfile =
RE: [mp2] CGI.pm param's always empty from only some clients (bug or mistake on my part?)
> kyle's post got me thinking. it would be interesting to see
> the output of
> this along with those traces. this is against CGI.pm 3.00.
> untested, but
> you get the idea :)
When I tried your patch as is, I got the following error:
*** reading POST data: CGI/usr/lib/perl5/5.8.0/CGI.pm518 at (eval 18) line
8.
[Fri Oct 31 09:44:07 2003] [error] 30899: ModPerl::Registry: argument is not
a blessed reference (expecting an APR::Table derived object) at (eval 18)
line 9.
So then I removed the second warn... I figure if it's reading
twice, you will just see two warns (I was watching as the requests
came in so there was no confusion):
+if ($MOD_PERL) {
+ warn ('*** reading POST data: ', caller);
+}
The end result is I only ever saw one warning per POST for both
the good and bad requests. You can see your warn's in amongst the
other stuff in the error_log in my previous response to Stas.
Cheers,
Scott Beuker
PATCH perl_reference.pod "Remedies for Inner Subroutines"
Stas Bekman <[EMAIL PROTECTED]> writes:
> Brian McCauley wrote:
>
> > I think porting.pod is done.
>
> Indeed.
>
> > Now I have to attack perl_reference.pod,
> > and I assume from what you said before you don't want to release the
> > one without the other.
>
> Yes. Let's commit them together.
Here's a _very_ rough first cut at perl_reference.pod. I haven't even
proof-read it yet so it's probably got spelling a and grammar errors
but I just want to be sure I'm going in the right direction.
--- perl_reference.pod.orig Thu Aug 14 18:11:11 2003
+++ perl_reference.pod Fri Oct 31 19:46:56 2003
@@ -863,16 +863,17 @@
problem, Perl will always alert you.
Given that you have a script that has this problem, what are the ways
-to solve it? There are many of them and we will discuss some of them
-here.
+to solve it? There have been many of them suggested in the past and we
+will discuss some of them here.
We will use the following code to show the different solutions.
multirun.pl
---
- #!/usr/bin/perl -w
+ #!/usr/bin/perl
use strict;
+ use warnings;
for (1..3){
print "run: [time $_]\n";
@@ -925,20 +926,26 @@
Counter is equal to 5 !
Counter is equal to 6 !
-Obviously, the C<$counter> variable is not reinitialized on each
-execution of run(). It retains its value from the previous execution,
-and sub increment_counter() increments that.
-
-One of the workarounds is to use globally declared variables, with the
-C pragma.
+Apparently, the C<$counter> variable is not reinitialized on each
+execution of run(), it retains its value from the previous execution,
+and increment_counter() increments that. Actually that's not quite
+what happens. On each execution of run() a new C<$counter> variable
+is initialized to zero but increment_counter is remains bound to the
+C<$counter> variable from the first call to run().
+
+The simplest of the workarounds is to use package-scoped variables,
+declared using C or, on older versions of Perl, the C
+pragma. Note that whereas using C declaration also implicitly
+initializes variables to undefined the C declaration does not,
+and so you may need to add explicit initialisation.
multirun1.pl
- ---
- #!/usr/bin/perl -w
+
+ #!/usr/bin/perl
use strict;
- use vars qw($counter);
-
+ use warnings;
+
for (1..3){
print "run: [time $_]\n";
run();
@@ -946,7 +953,7 @@
sub run {
-$counter = 0;
+our $counter = 0;
increment_counter();
increment_counter();
@@ -977,11 +984,34 @@
problem, since there is no C (lexically defined) variable used
in the nested subroutine.
-Another approach is to use fully qualified variables. This is better,
-since less memory will be used, but it adds a typing overhead:
+In the above example we know C<$counter> is just a simple small
+scalar. In the general case variables could reference external
+resource handles or large data structures. In that situation the fact
+that the variable would not be released immediately when run()
+completes could be a problem. To avoid this you should put C
+in front of all you C declarations for all variables other than
+simple scalars. This has the effect of restoring the variable to its
+previous value (usually undefined) upon exit from the current scope.
+As a side-effect C also initializes the variables to C.
+So, you recall that thing I said about needing to remeber to add
+explicit initialization when you replace C by C, well you can
+forget it again if you replace C with C.
+
+Be warned that C will not release circular data structures and
+if the original CGI script relied on process termination to clean up
+after it then it will leak memory as a registry script.
+
+A varient of the package variable approach is to use explicit package
+qualified variables. This has the advantage on old versions of Perl
+that there is no need to load the C module, but it adds a
+significant typing overhead. This approach is not suitable for
+registry scripts because they would all be stomping on the C
+namespace rather than each staying within the namespace allocated to
+them. And, besides, the overhead of loading the C module would
+only have to be paid one per Perl interpreter.
multirun2.pl
- ---
+
#!/usr/bin/perl -w
use strict;
@@ -993,14 +1023,14 @@
sub run {
-$main::counter = 0;
+$::counter = 0;
increment_counter();
increment_counter();
sub increment_counter{
- $main::counter++;
- print "Counter is equal to $main::counter !\n";
+ $::counter++;
+ print "Counter is equal to $::counter !\n";
}
} # end of sub run
@@ -1019,10 +1049,11 @@
and then submit it for your script to process.
multirun3.pl
- ---
- #!/usr/bin/perl -w
+
+ #!/usr/bin/perl
use strict;
+ use warnings;
for (1..3){
print "run: [time $_]\n";
@@ -1056,10 +1087,11
Re: [mp2] CGI.pm param's always empty from only some clients (bug or mistake on my part?)
Scott, please try this patch:
--- CGI.pm.orig 2003-10-31 13:45:06.0 -0800
+++ CGI.pm 2003-10-31 13:58:28.0 -0800
@@ -515,8 +515,15 @@
}
if ($meth eq 'POST') {
- $self->read_from_client(\*STDIN,\$query_string,$content_length,0)
- if $content_length > 0;
+ if ($content_length > 0) {
+ my $len = $content_length;
+ while ($len > 0) {
+ my $data = '';
+ my $read = $self->read_from_client(\*STDIN,\$data,$len,0);
+ $len -= $read;
+ $query_string .= $data if $read > 0;
+ }
+ }
# Some people want to have their cake and eat it too!
# Uncomment this line to have the contents of the query string
# APPENDED to the POST data.
__
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: [mp2] CGI.pm param's always empty from only some clients (bug or mistake on my part?)
Stas,
The patch seems to work based on one previously affected client! However,
it's
evening here and everyone has gone home. I'll unfortunately need to wait
until
Monday to test more affected clients. I'll let you know then the results,
but
so far so good!
Thanks,
Scott
> Scott, please try this patch:
>
> --- CGI.pm.orig 2003-10-31 13:45:06.0 -0800
> +++ CGI.pm 2003-10-31 13:58:28.0 -0800
> @@ -515,8 +515,15 @@
> }
>
> if ($meth eq 'POST') {
> -
$self->read_from_client(\*STDIN,\$query_string,$content_length,0)
> - if $content_length > 0;
> + if ($content_length > 0) {
> + my $len = $content_length;
> + while ($len > 0) {
> + my $data = '';
> + my $read =
$self->read_from_client(\*STDIN,\$data,$len,0);
> + $len -= $read;
> + $query_string .= $data if $read > 0;
> + }
> + }
># Some people want to have their cake and eat it too!
># Uncomment this line to have the contents of the query string
># APPENDED to the POST data.
Fwd: ezmlm response
Hello, I have been getting the error messages below and not sure if "$r wasn't passed" is related with mod_perl/apache or it's something about server configurations. The web server I am getting this error message from is SunFire280R. Any ideas? [Fri Oct 31 01:02:17 2003] -e: $r wasn't passed. [Fri Oct 31 01:02:24 2003] [error] 27969: ModPerl::Registry: $r wasn't passed [Fri Oct 31 01:02:24 2003] -e: $r wasn't passed. Thanks much, Hulya
Re: Problem with libapreq + possible fix
Shannon D Schlueter <[EMAIL PROTECTED]> writes: > While trying to install the GMOD/CMAP perl modules, I encountered a > problem where Apache::Cookie->new(...) was returning an object method > not found. As per the suggestion at > http://marc.theaimsgroup.com/?l=apreq-dev&m=105965131008577&w=2 > I altered the Makefile.PL files in the Request and Cookie > directories. This seems to have fixed the problem. Great! What operating system and perl version are you running? > We found this using the latest CPAN libapreq (1.3) and perl 5.8.1. > > Was this an appropriate patch? > > Have I messed something else up by doing this? The patch is correct. The problem is that the apreq-dev folks don't know if it works on OSX or not, so it hasn't been applied. -- Joe Schaefer
