Re: libapreq2 upload question

[eps com estem]

>> Here's a patch for $upload->slurp, see if it helps:
>Fast work, as always, Joe :) These patches I've incorporated
>in a new libapreq2.ppd ppm package at
>href="/app/message?l=es&o=8&url=http%3A%2F%2Ftheoryx5%2Euwinnipeg%2Eca%2Fppms%2F"
target="_blank">http://theoryx5.uwinnipeg.ca/ppms/
>The version hasn't changed, so you may have to uninstall
>libapreq2 and then reinstall it via ppm.

Hell, so fast ...
Installed and now everything runs smoothly. Fantastic.
One last question, would you use libapreq2 to handle all GET and POST data or 
only the
multipart-POST data??
I mean, what's the intention of libapreq to be? To handle this or simply to 
offer some adds?
Thanks cracks.

-
Esta Navidad, sé más original ¿Te atreves a enviar una postal con tu voz? 
http://greetingmania.ya.com
Ya.com ADSL Router Wi-Fi: Sólo 29,90 €/mes + IVA*. Router + Antivirus y 
firewall ¡Gratis! http://acceso.ya.com/adsl/256router

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Runs on Perl 5.8.0 but no on 5.8.3:[DBI]

[Chetan Anand]

Hi,
Whenever I execute a Perl script the following erroris displayed in apache's  error_log:[error] [client 127.0.0.1] Can't use string ("") as aHASH ref while "strict refs" in use at/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/DBI.pmline 514., referer: http://localhost/myforms/login.plThis happens for all  Perl scripts.My server versionon Fedora Core 2 is 2.0.49 and perl 5.8.3The same scripts run perfectly on Red Hat 9's  Apacheserver version 2.0.40 and perl 5.8.0How to fix this?__Do You Yahoo!?Tired of spam?  Yahoo! Mail has the best spam protection around http://mail.yahoo.com 

Re: What's wrong with this system's configuration?

[Nick ***]

 > Оригинално писмо 
 >От:  Stas Bekman <[EMAIL PROTECTED]>
 >Относно: Re: What's wrong with this system's configuration?
 >До: Nick *** <[EMAIL PROTECTED]>
 >Изпратено на: Петък, 2004, Декември 17 18:18:34 EET
 >--
 >
 >Nick *** wrote:
 >
 >>  >> # @(#)B11.23_LRhosts $Revision: 1.9.214.1 $ $Date: 96/10/08 13:20:01 $
 >>  >> #
 >>  >> # The form for each entry is:
 >>  >> #  
 >>  >> #
 >>  >> # For example:
 >>  >> # 192.1.2.34hpfcrm  loghost
 >>  >> #
 >>  >> # See the hosts(4) manual page for more information.
 >>  >> # Note: The entries cannot be preceded by a space.
 >>  >> #   The format described in this file is the correct format.
 >>  >> #   The original Berkeley manual page contains an error in
 >>  >> #   the format description.
 >>  >> #
 >>  >> 
 >>  >> 192.233.54.176  spe176.testdrive.hp.com spe176
 >>  >> 127.0.0.1   localhost   loopback
 >>  >> 192.233.54.253  spe253.testdrive.hp.com spe253
 >>  >> 
 >>  >> 
 >>  >> Is there anything else I can do to run perl Makefile.PL?
 >>  >
 >>  >[  error] Can't resolve host: 'localhost.testdrive.hp.com' (check 
 >> /etc/hosts)
 >>  >
 >>  >So you need to ask the admins to have that entry in /etc/hosts, because 
 >>  >your machine identifies itself as 'localhost.testdrive.hp.com'.
 >>  >
 >>  >--
 >> 
 >> The admin asked me what command I use in order to get the name 
 >> 'localhost.testdrive.hp.com'. How does MP2 get this?
 >
 >Something like the following:
 >
 >use Socket;
 >my $localhost_addr = pack('C4', 127, 0, 0, 1);
 >my $name = gethostbyaddr($localhost_addr, Socket::AF_INET()) || 'localhost';
 >my $iaddr = (gethostbyname($name))[-1];
 >unless (defined $iaddr) {
 > die "Can't resolve host: '$name' (check /etc/hosts)";
 >}
 >$remote_addr ||= Socket::inet_ntoa($iaddr);
 >print $remote_addr;
 >
 >prints 127.0.0.1 on my machine.
 >
 >--

They ask me this: :)

When I show this to one of the engineers here we are confused
as to what information or what you are trying to do with these
commands. Can you please explain what you are trying to do?

Thanks

Tim 


 >__
 >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
 >
 >-- 
 >Report problems: http://perl.apache.org/bugs/
 >Mail list info: http://perl.apache.org/maillist/modperl.html
 >List etiquette: http://perl.apache.org/maillist/email-etiquette.html
 >
 >

-
Абонирайте се за в. Пари - http://www.pari.bg/abonament/

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

multiple developers on one Sever

[Henning Meyer]

Hello,
I've got a mod_perl-Apache running, which hosts multiple
developement-versions (of multiple CVS-developers) of a webapp.
Therefore I've got this apache-config:

Options +Includes
XBitHack on


SetHandler perl-script
PerlHandler Apache::Registry
PerlModule Apache::DBI
PerlSendHeader On
Options ExecCGI +Includes
Order allow,deny
Allow from all
AllowOverride None


Each version has its own config (like a seperate DB per developer). This is
done by:
require 'config.pl';
in each of the mod_perl-scripts.
config.pl looks like this:

#!/usr/bin/perl
use strict;
package myconf;
use vars qw(%c);
%c = (DB=>"henningsDB"}; # or tutmannsDB in tutmanns config.pl
1;

The point is, that in each version everything may be the same except of the
config.pl.
But: Apache and mod_perl seem to mix up the configurations. The reason seems
to be, that the configuration is just read once the process starts, and not
each time a script is executed.
What is a good workaround? Local ini-Files? Or something even better?

Thanks

Henning


-- 
+++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: multiple developers on one Sever

[Pratik]

Please provide information about the versions of mod_perl and apache
that you are using. If you provide your fully working configuration
file, it will be easy to identify the issue.

- Pratik
-- 
http://pratik.syslock.org

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: multiple developers on one Sever

[Arun pandey]

I guess the problem might be with your PerlHandler, coz Apache::Registry,
caches all scripts, as a result certain global values will remain
persistent. In such a case you might want to use Apache::PerlRun instead ,
which  mimics mod_cgi  by flushing the namespace at the every start of
request.


Thanks
Arun






- Original Message - 
From: "Henning Meyer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, December 20, 2004 11:10 PM
Subject: multiple developers on one Sever


> Hello,
> I've got a mod_perl-Apache running, which hosts multiple
> developement-versions (of multiple CVS-developers) of a webapp.
> Therefore I've got this apache-config:
> 
> Options +Includes
> XBitHack on
> 
> 
> SetHandler perl-script
> PerlHandler Apache::Registry
> PerlModule Apache::DBI
> PerlSendHeader On
> Options ExecCGI +Includes
> Order allow,deny
> Allow from all
> AllowOverride None
> 
>
> Each version has its own config (like a seperate DB per developer). This
is
> done by:
> require 'config.pl';
> in each of the mod_perl-scripts.
> config.pl looks like this:
>
> #!/usr/bin/perl
> use strict;
> package myconf;
> use vars qw(%c);
> %c = (DB=>"henningsDB"}; # or tutmannsDB in tutmanns config.pl
> 1;
>
> The point is, that in each version everything may be the same except of
the
> config.pl.
> But: Apache and mod_perl seem to mix up the configurations. The reason
seems
> to be, that the configuration is just read once the process starts, and
not
> each time a script is executed.
> What is a good workaround? Local ini-Files? Or something even better?
>
> Thanks
>
> Henning
>
>
> -- 
> +++ Sparen Sie mit GMX DSL +++ http://www.gmx.net/de/go/dsl
> AKTION für Wechsler: DSL-Tarife ab 3,99 EUR/Monat + Startguthaben
>
> -- 
> Report problems: http://perl.apache.org/bugs/
> Mail list info: http://perl.apache.org/maillist/modperl.html
> List etiquette: http://perl.apache.org/maillist/email-etiquette.html
>


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1

[Jean-François Nadeau]

Hi 
all,
 
I was using 
mod_perl-1.99_14 under Apache 2.0.49,
 
I upgraded to 
mod_perl-2.0.0-RC1 under Apache 2.0.52.
 
Im using RedHat 8.0 
/ perl 5.8.0 / CGI.pm 3.05
 
Apache configuration 
:
 
 SetHandler 
perl-script PerlResponseHandler ModPerl::PerlRun PerlOptions 
+ParseHeaders +GlobalRequest
 
We only use the 
PerlRun handler.  
 
Since the 
upgrade,  Apache childs leak (fast).
 
Using the old 
PerlRun.pm with the current mod_perl.so does not leak.
 
I attached 
"mybugreport" 
 
Let me know if more 
information is needed
 
Regards,
 
Jean
 


mybugreport
Description: Binary data
-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Runs on Perl 5.8.0 but no on 5.8.3:[DBI]

[Tom Schindl]

Although I doubt this has something todo with mod_perl which this list 
is dedicated to you should at least state:

* Version of DBI.pm
* Maybe also the part of DBI.pm around line 514
* try to run a programm on the command-line using DBI if it also fails
  => upgrade DBI.pm (are the version on the 2 servers the same)?
* give it a try at the DBI-Mailling list
Tom
Chetan Anand wrote:
Hi,
Whenever I execute a Perl script the following error
is displayed in apache's  error_log:
[error] [client 127.0.0.1] Can't use string ("") as a
HASH ref while "strict refs" in use at
/usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/DBI.pm
line 514., referer: http://localhost/myforms/login.pl
This happens for all  Perl scripts.My server version
on Fedora Core 2 is 2.0.49 and perl 5.8.3
The same scripts run perfectly on Red Hat 9's  Apache
server version 2.0.40 and perl 5.8.0
How to fix this?
__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Apache::DBI and PerlChildExitHandler

[Joel]

Good morning,

This is not a problem, per se, nor is it something I especially need to
get done, but it would certainly be nice to have and might, in some small
way, benefit the world in general. Here's what's going on:


I am using mod_perl 1.99_13 (yes, I know I should upgrade) and Apache
2.0.52. I'm using Apache::DBI/DBD::Pg to connect to a PostgreSQL server.

Everything works beautifully and the server is stable and everything like
that. But my PostgreSQL server log file has a mess of these error
messages:

LOG:  pq_recvbuf: unexpected EOF on client connection

And from what I understand, this is caused when the Apache child exists
and does not execute an explicit $dbh->disconnect() on the database
handle. That is, the connection is not being closed properly before the
handle goes out of scope.

If this assumption is correct, I think it can be remedied by adding a
PerlChildExitHandler to simply do a $dbh->disconnect() as the child is
exiting.

In general, this is not a problem. PostgreSQL logs the 'error' and goes
about it's merry way. However, it would be nice to reduce the number of
messages in the log file, since it's all noise and gets in the way of
real errors.

Can anyone comment on the feasability of this solution? I plan to
implement it soon and if it works, provide a patch, but my brain is not
thread-enabled (I'm using prefork), so I have no knowledge of how this
would affect a threaded apache. 

The only nagging thing about this is why hasn't anyone thought of this
and implemented it before? :) Or maybe I'm just WAY off-base.

Thanks,
--Joel

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

RE: PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1

[Jean-François Nadeau]

The problem might be 
in RegistryCooker.pm 
 
I upgraded each 
script from 1.99_14 to current one by one to find the leak starts when 
using the current RegistryCooker.pm 
Let me know if this help...
 
thanks


From: Jean-François Nadeau 
[mailto:[EMAIL PROTECTED] Sent: 21 décembre 2004 
08:15To: [EMAIL PROTECTED]Subject: PerlRun Memory 
leak upgrading from 1.99_14 to 2.0.0-RC1

Hi 
all,
 
I was using 
mod_perl-1.99_14 under Apache 2.0.49,
 
I upgraded to 
mod_perl-2.0.0-RC1 under Apache 2.0.52.
 
Im using RedHat 8.0 
/ perl 5.8.0 / CGI.pm 3.05
 
Apache configuration 
:
 
 SetHandler 
perl-script PerlResponseHandler ModPerl::PerlRun PerlOptions 
+ParseHeaders +GlobalRequest
 
We only use the 
PerlRun handler.  
 
Since the 
upgrade,  Apache childs leak (fast).
 
Using the old 
PerlRun.pm with the current mod_perl.so does not leak.
 
I attached 
"mybugreport" 
 
Let me know if more 
information is needed
 
Regards,
 
Jean
 

Re: libapreq2 upload question

[Randy Kobes]

On Tue, 21 Dec 2004, eps com estem wrote:

> >> Here's a patch for $upload->slurp, see if it helps:
> >Fast work, as always, Joe :) These patches I've incorporated
> >in a new libapreq2.ppd ppm package at
> >> href="/app/message?l=es&o=8&url=http%3A%2F%2Ftheoryx5%2Euwinnipeg%2Eca%2Fppms%2F"
> target="_blank">http://theoryx5.uwinnipeg.ca/ppms/
> >The version hasn't changed, so you may have to uninstall
> >libapreq2 and then reinstall it via ppm.
>
> Hell, so fast ... Installed and now everything runs
> smoothly. Fantastic. One last question, would you use
> libapreq2 to handle all GET and POST data or only the
> multipart-POST data?? I mean, what's the intention of
> libapreq to be? To handle this or simply to offer some
> adds? Thanks cracks.

That's great that it works ... libapreq2 is pretty general;
from the README in the sources:

  libapreq is a safe, standards-compliant, high-performance library
  used for parsing HTTP cookies, query-strings and POST data. The
  original version (libapreq-1.X) was designed by Lincoln
  Stein and Doug MacEachern. The perl APIs Apache::Request
  and Apache::Cookie are the lightweight mod_perl analogs of
  the CGI and CGI::Cookie perl modules.



In fact, you can use libapreq2 in a CGI environment (to do
so with the Perl bindings you need mod_perl installed for
some APR::* modules, but these particular modules can also
be used outside of mod_perl).

-- 
best regards,
randy

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Apache::DBI and PerlChildExitHandler

[Stas Bekman]

Joel wrote:
Good morning,
This is not a problem, per se, nor is it something I especially need to
get done, but it would certainly be nice to have and might, in some small
way, benefit the world in general. Here's what's going on:
I am using mod_perl 1.99_13 (yes, I know I should upgrade) and Apache
2.0.52. I'm using Apache::DBI/DBD::Pg to connect to a PostgreSQL server.
Everything works beautifully and the server is stable and everything like
that. But my PostgreSQL server log file has a mess of these error
messages:
LOG:  pq_recvbuf: unexpected EOF on client connection
And from what I understand, this is caused when the Apache child exists
and does not execute an explicit $dbh->disconnect() on the database
handle. That is, the connection is not being closed properly before the
handle goes out of scope.
If this assumption is correct, I think it can be remedied by adding a
PerlChildExitHandler to simply do a $dbh->disconnect() as the child is
exiting.
In general, this is not a problem. PostgreSQL logs the 'error' and goes
about it's merry way. However, it would be nice to reduce the number of
messages in the log file, since it's all noise and gets in the way of
real errors.
Can anyone comment on the feasability of this solution? I plan to
implement it soon and if it works, provide a patch, but my brain is not
thread-enabled (I'm using prefork), so I have no knowledge of how this
would affect a threaded apache. 

The only nagging thing about this is why hasn't anyone thought of this
and implemented it before? :) Or maybe I'm just WAY off-base.
PerlChildExitHandler should work, but why your application doesn't do that 
by itself?

You could also subclass DBI::dbh (or whatever that class is) to implement 
DESTROY which will do just that: $dbh->disconnect(). So when the object is 
destroyed, it'll call disconnect.

Also it's possible that using Apache::DBI is the better solution, but it 
depends on your demands.

--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Runs on Perl 5.8.0 but no on 5.8.3:[DBI]

[Jay Scherrer]

Does this have something to do with SElinux?
At what security level is your SE-Linux turn on?
Because on FC2 SE was by default set to high.


Jay Scherrer

On Tuesday 21 December 2004 02:44 am, Chetan Anand wrote:
> Hi,
> Whenever I execute a Perl script the following error
> is displayed in apache's  error_log:
>
> [error] [client 127.0.0.1] Can't use string ("") as a
> HASH ref while "strict refs" in use at
> /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi/DBI.pm
> line 514., referer: http://localhost/myforms/login.pl
>
> This happens for all  Perl scripts.My server version
> on Fedora Core 2 is 2.0.49 and perl 5.8.3
>
> The same scripts run perfectly on Red Hat 9's  Apache
> server version 2.0.40 and perl 5.8.0
>
> How to fix this?
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1

[Stas Bekman]

Jean-François Nadeau wrote:
Hi all,
 
I was using mod_perl-1.99_14 under Apache 2.0.49,
 
I upgraded to mod_perl-2.0.0-RC1 under Apache 2.0.52.
 
Im using RedHat 8.0 / perl 5.8.0 / CGI.pm 3.05
 
Apache configuration :
 
 SetHandler perl-script
 PerlResponseHandler ModPerl::PerlRun
 PerlOptions +ParseHeaders +GlobalRequest
 
We only use the PerlRun handler.  

Since the upgrade,  Apache childs leak (fast).
 
Using the old PerlRun.pm with the current mod_perl.so does not leak.
 
I attached "mybugreport" 
Please inline those in the future, so one could comment on it in reply.
> *** The httpd binary was not found
Could you please attach (yes, attach this time :)
/root/NEW/mod_perl-2.0.0-RC1/lib/Apache/BuildConfig.pm
I'm trying to figure out why the above happens.
Also what were the exact arguments you've passed to Makefile.PL?
Now back to your problem.
> *** Packages of interest status:
>
> Apache::Request: -
> CGI: 3.05
> LWP: 5.64, 5.65
> mod_perl   : 1.9914, 1.9918
That's after you did 'make install' for RC1? how come you have both now?
It now looks that you've installed RC1 with MP_INST_APACHE2=1, whereas 
1.99_14 was installed w/o it. So you ended up with a mix of two modperls. 
I suggest you go and nuke any occurences of modperl from your perl tree 
and do 'make install' again. The above should report only one mod_perl of 
the 1.99_ generation.

If the leak still persist, please post a shortest possible script that we 
can reproduce the problem with. The best you can do is to prepare a bug 
reporting tarball, based on bug-reporting-skeleton-mp2.tar.gz from:
http://perl.apache.org/docs/2.0/user/help/help.html#Problem_Description

--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: libapreq2 upload question

[Joe Schaefer]

"eps com estem" <[EMAIL PROTECTED]> writes:


[...]

> One last question, would you use libapreq2 to handle all GET
> and POST data or only the multipart-POST data??

It's designed to be usable for all GET / POST data.
The Content-Types it currently understands are 

application/x-www-form-urlencoded
multipart/form-data
multipart/related

The first two are what HTML forms typically use,
but we've also laid enough groundwork within libapreq2
to support newer specs like XForms and WHATWG once
browsers start implementing them.  libapreq2 provides
a C API to extend/modify the parser list, so you
can even extend it yourself if apreq-dev@ isn't 
extending it fast enough for you.

> I mean, what's the intention of libapreq to be? 

libapreq2 is intended to provide a common request
parsing library for all apache2 modules (not just
a "faster CGI.pm").  There are already a few C modules 
(mod_spin is a nice example) that use libapreq2.  The
upshot is that such modules will all share the *parsed*
POST data, without stealing the *raw* POST data from 
other modules.

-- 
Joe Schaefer


-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

RE: PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1

[Jean-François Nadeau]

Thanks for the quick reply.

I cleaned up my installation and reinstalled.
See attached bug report and BuildConfig.pm.

Configured with:
perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache-2.0.52/ 
make && make install 

The leak persist after reinstall.  

I do not have a sample script at the moment...

Regards,

Jean
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED] 
Sent: 21 décembre 2004 11:26
To: Jean-François Nadeau
Cc: [EMAIL PROTECTED]
Subject: Re: PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1

Jean-François Nadeau wrote:
> Hi all,
>  
> I was using mod_perl-1.99_14 under Apache 2.0.49,
>  
> I upgraded to mod_perl-2.0.0-RC1 under Apache 2.0.52.
>  
> Im using RedHat 8.0 / perl 5.8.0 / CGI.pm 3.05
>  
> Apache configuration :
>  
>  SetHandler perl-script
>  PerlResponseHandler ModPerl::PerlRun
>  PerlOptions +ParseHeaders +GlobalRequest
>  
> We only use the PerlRun handler.  
>
> Since the upgrade,  Apache childs leak (fast).
>  
> Using the old PerlRun.pm with the current mod_perl.so does not leak.
>  
> I attached "mybugreport" 

Please inline those in the future, so one could comment on it in reply.

 > *** The httpd binary was not found

Could you please attach (yes, attach this time :)
/root/NEW/mod_perl-2.0.0-RC1/lib/Apache/BuildConfig.pm
I'm trying to figure out why the above happens.

Also what were the exact arguments you've passed to Makefile.PL?

Now back to your problem.

 > *** Packages of interest status:
 >
 > Apache::Request: -
 > CGI: 3.05
 > LWP: 5.64, 5.65
 > mod_perl   : 1.9914, 1.9918

That's after you did 'make install' for RC1? how come you have both now?
It now looks that you've installed RC1 with MP_INST_APACHE2=1, whereas
1.99_14 was installed w/o it. So you ended up with a mix of two modperls. 
I suggest you go and nuke any occurences of modperl from your perl tree and
do 'make install' again. The above should report only one mod_perl of the
1.99_ generation.

If the leak still persist, please post a shortest possible script that we
can reproduce the problem with. The best you can do is to prepare a bug
reporting tarball, based on bug-reporting-skeleton-mp2.tar.gz from:
http://perl.apache.org/docs/2.0/user/help/help.html#Problem_Description

--
__
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



mybugreport4
Description: Binary data


BuildConfig.pm
Description: Binary data
-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Can Apache::TestMB suppress APXS warnings?

[Joshua Hoblitt]

On Mon, 20 Dec 2004, Stas Bekman wrote:
Joshua Hoblitt wrote:
Hi Folks,
I've been unable to figure out how to get Apache::TestMB to setup my 
build
environment in such a way as to suppress APXS warnings during a test run. 
e.g.

--
t/10_client_newAPXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/10_client_newok
t/11_client_create.APXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/11_client_create.ok
t/12_client_replicate..APXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/12_client_replicate..ok
t/13_client_cull...APXS (/usr/local/apache/bin/apxs) 
query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/13_client_cull...ok
--

Is it possible to silence these gratuitous warnings?
which modperl is that?
"Apache/1.3.33 (Unix) mod_perl/1.29" and I'm using 
Apache::Test/Apache::TestMB 1.17.
what code do you have in your tests that invokes those?
Any of the .t files that have "use Apache::Test qw( -withtestmore );" in 
them.
The test files that only use just Test::More don't give any APXS errors
(although they are all being run by Apache::TestRunPerl). It also displays a
number of APXS warnings at the begnning of the test run.
Here is the complete output of a test run:
--
$ make test
/usr/bin/perl5.8.5 Build --makefile_env_macros 1 test
/usr/bin/perl5.8.5 -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/lib -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/arch t/TEST -clean
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.8.5 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/TEST -clean
/usr/bin/perl5.8.5 -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/lib -I 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/arch t/TEST 
-bugreport -verbose=0
[warning] setting ulimit to allow core files
ulimit -c unlimited; /usr/bin/perl5.8.5 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/TEST -bugreport 
-verbose=0
APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for TARGET failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
APXS (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
APXS (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
APXS (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
/usr/local/apache/bin/httpd  -d 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t -f 
/home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/conf/httpd.conf -D 
APACHE1
using Apache/1.3.33
waiting 60 seconds for server to start: .
waiting 60 seconds for server to start: ok (waited 0 secs)
server moa:8529 started
t/01_load...ok
t/02_server_setup...ok
t/03_server_create_object...ok
t/04_server_replicate_objectok
t/05_server_lock_object.ok
t/06_server_unlock_object...ok
t/07_server_find_instances..ok
t/08_server_delete_instance.ok
t/09_server_stat_object.ok
t/10_client_new.APXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/10_client_new.ok
t/11_client_create..APXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/11_client_create..ok
t/12_client_replicate...APXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/12_client_replicate...ok
t/13_client_cullAPXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/13_client_cullok
6/15 skipped: unsure if this should be part of the API
t/14_client_lockAPXS (/usr/local/apache/bin/apxs) query for 
SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed
APXS (/usr/local/apache/bin/apxs) query for PREFIX failed
t/14_client_lockok
t/15_client_unlock..APXS (/usr/local/apache/bin/apxs) que

Re: Can Apache::TestMB suppress APXS warnings?

[Stas Bekman]

Joshua Hoblitt wrote:
[This thread really belongs to the httpd-test list, since it has nothing 
to do with modperl]

[...]
"Apache/1.3.33 (Unix) mod_perl/1.29" and I'm using 
Apache::Test/Apache::TestMB 1.17.

what code do you have in your tests that invokes those?

Any of the .t files that have "use Apache::Test qw( -withtestmore );" in 
them.
The test files that only use just Test::More don't give any APXS errors
(although they are all being run by Apache::TestRunPerl). It also 
displays a
number of APXS warnings at the begnning of the test run.

Here is the complete output of a test run:

APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
what do you get when running: /usr/local/apache/bin/apxs -q SBINDIR

--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: PerlRun Memory leak upgrading from 1.99_14 to 2.0.0-RC1

[Stas Bekman]

Configured with:
perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=/usr/local/apache-2.0.52/ 
make && make install 
OK. Why do you use MP_AP_PREFIX and not MP_APXS? The docs suggest to use 
the latter:
http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Installation
http://perl.apache.org/docs/2.0/user/install/install.html#Dynamic_mod_perl

I guess you're reading this?
--
If however all Apache 2.0 files were installed under the same directory, 
mod_perl 2.0's build only needs to know the path to that directory, passed 
via the MP_AP_PREFIX option:

  % perl Makefile.PL MP_INST_APACHE2=1 MP_AP_PREFIX=$HOME/httpd/prefork
---
right?
/usr/local/apache-2.0.52/ is the Apache source, correct? Not the binaries.

The leak persist after reinstall.  

I do not have a sample script at the moment...
I have an idea of what could be the cause of the leak:
=item 1.99_17 - October 22, 2004
[...]
Added ModPerl::Util::unload_package() to remove a loaded package
as thoroughly as possible by clearing it's stash. [Gozer]
but I could be wrong. Please post a sample script that we can reproduce 
the problem with and we will look at it. Ideally it should be a bug
reporting tarball, based on bug-reporting-skeleton-mp2.tar.gz from:
http://perl.apache.org/docs/2.0/user/help/help.html#Problem_Description


--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Can Apache::TestMB suppress APXS warnings?

[Geoffrey Young]

> $ make test /usr/bin/perl5.8.5 Build --makefile_env_macros 1 test 
> /usr/bin/perl5.8.5 -I 
> /home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/lib -I 
> /home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/arch t/TEST 
> -clean [warning] setting ulimit to allow core files ulimit -c unlimited;
> /usr/bin/perl5.8.5 
> /home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/TEST -clean 
> /usr/bin/perl5.8.5 -I 
> /home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/lib -I 
> /home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/blib/arch t/TEST 
> -bugreport -verbose=0 [warning] setting ulimit to allow core files ulimit
> -c unlimited; /usr/bin/perl5.8.5 
> /home/moa/jhoblitt/docs/perl/dev/modules/PS-IPP-IData/t/TEST -bugreport 
> -verbose=0 APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed 
> APXS (/usr/local/apache/bin/apxs) query for TARGET failed APXS
> (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed APXS
> (/usr/local/apache/bin/apxs) query for PREFIX failed APXS
> (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS
> (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS
> (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed

I'm very surprised the run doesn't abort right here.  it probably should if
any apxs option was specified, and shouldn't hit this at all of an httpd
option is specified.

--Geoff

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Can Apache::TestMB suppress APXS warnings?

[Randy Kobes]

On Tue, 21 Dec 2004, Geoffrey Young wrote:

> > -verbose=0 APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
> > APXS (/usr/local/apache/bin/apxs) query for TARGET failed APXS
> > (/usr/local/apache/bin/apxs) query for SYSCONFDIR failed APXS
> > (/usr/local/apache/bin/apxs) query for PREFIX failed APXS
> > (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS
> > (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS
> > (/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
>
> I'm very surprised the run doesn't abort right here.  it
> probably should if any apxs option was specified, and
> shouldn't hit this at all of an httpd option is specified.

There was a similar problem on Win32 about these warnings,
related to the unsetting of the PATH environment variable
for tainting. A fix for this that works for Win32 is in the
current svn sources - can you try that to see if that helps?

-- 
best regards,
randy

-- 
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Can Apache::TestMB suppress APXS warnings?

[Stas Bekman]

Randy Kobes wrote:
On Tue, 21 Dec 2004, Geoffrey Young wrote:

-verbose=0 APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
APXS (/usr/local/apache/bin/apxs) query for TARGET failed APXS
(/usr/local/apache/bin/apxs) query for SYSCONFDIR failed APXS
(/usr/local/apache/bin/apxs) query for PREFIX failed APXS
(/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS
(/usr/local/apache/bin/apxs) query for LIBEXECDIR failed APXS
(/usr/local/apache/bin/apxs) query for LIBEXECDIR failed
I'm very surprised the run doesn't abort right here.  it
probably should if any apxs option was specified, and
shouldn't hit this at all of an httpd option is specified.

There was a similar problem on Win32 about these warnings,
related to the unsetting of the PATH environment variable
for tainting. A fix for this that works for Win32 is in the
current svn sources - can you try that to see if that helps?
svn sources of Apache-Test? Joshua is using mp1. so A-T 1.17 should be 
pretty good, no?

--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Can Apache::TestMB suppress APXS warnings?

[Joshua Hoblitt]

On Tue, 21 Dec 2004, Stas Bekman wrote:
Joshua Hoblitt wrote:
[This thread really belongs to the httpd-test list, since it has nothing to 
do with modperl]

[...]
"Apache/1.3.33 (Unix) mod_perl/1.29" and I'm using 
Apache::Test/Apache::TestMB 1.17.

what code do you have in your tests that invokes those?

Any of the .t files that have "use Apache::Test qw( -withtestmore );" in 
them.
The test files that only use just Test::More don't give any APXS errors
(although they are all being run by Apache::TestRunPerl). It also 
displays a
number of APXS warnings at the begnning of the test run.

Here is the complete output of a test run:

APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed
what do you get when running: /usr/local/apache/bin/apxs -q SBINDIR
$ /usr/local/apache/bin/apxs -q SBINDIR
apxs:Error: Sorry, no DSO support for Apache available
apxs:Error: under your platform. Make sure the Apache
apxs:Error: module mod_so is compiled into your server
apxs:Error: binary `/usr/local/apache/bin/httpd'.
Which doesn't matter since mod_perl isn't built as a DSO...
-J
--
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Can Apache::TestMB suppress APXS warnings?

[Stas Bekman]

Joshua Hoblitt wrote:
On Tue, 21 Dec 2004, Stas Bekman wrote:
Joshua Hoblitt wrote:
[This thread really belongs to the httpd-test list, since it has 
nothing to do with modperl]

[...]
"Apache/1.3.33 (Unix) mod_perl/1.29" and I'm using 
Apache::Test/Apache::TestMB 1.17.

what code do you have in your tests that invokes those?

Any of the .t files that have "use Apache::Test qw( -withtestmore );" 
in them.
The test files that only use just Test::More don't give any APXS errors
(although they are all being run by Apache::TestRunPerl). It also 
displays a
number of APXS warnings at the begnning of the test run.

Here is the complete output of a test run:

APXS (/usr/local/apache/bin/apxs) query for SBINDIR failed

what do you get when running: /usr/local/apache/bin/apxs -q SBINDIR

$ /usr/local/apache/bin/apxs -q SBINDIR
apxs:Error: Sorry, no DSO support for Apache available
apxs:Error: under your platform. Make sure the Apache
apxs:Error: module mod_so is compiled into your server
apxs:Error: binary `/usr/local/apache/bin/httpd'.
Which doesn't matter since mod_perl isn't built as a DSO...
right. I guess it should do something else rather than just print those 
errors (die or hide those). I'll look into this. I should be able to 
easily reproduce this.

--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html