Re: Apache segfaults with Oracle AS10g (9.0.4.0) when attempting to use mod_perl

[Maruthi Vara Prasad Chirravuri]

Hi,

Can u send the /var/log/httpd/error.log and /var/log/messages output.

Ch. Maruthi Vara Prasad.

On 10/5/05, Rafael Caceres <[EMAIL PROTECTED]> wrote:
> When trying to use any mod_perl functionality in the Apache server
> included with Oracle AS10g under AIX 5.3, such as
> -'PerlModule Apache::Status'
> -'PerlModule Apache::DBI'
> or others using XS, Apache does a coredump.
>
> The same coredump occurs if no XS using module is loaded from httpd.conf
> but used in a script run from the /perl location.
>
> The same occurs if an XS using module is run with 'PerlRequire
> initial_load.pl'
>
> The PERL5LIB value is correctly set in the Apache httpd.conf, so that is
> not the problem. Oracle support has provided very little help to date,
> and mod_perl usage is critical for our SingleSignOn system.
>
> Any help is appreciated,
> Rafael Caceres
>
>

Re: Apache segfaults with Oracle AS10g (9.0.4.0) when attempting to use mod_perl

[Frank Wiles]

On Tue, 04 Oct 2005 18:01:36 -0500
Rafael Caceres <[EMAIL PROTECTED]> wrote:

> When trying to use any mod_perl functionality in the Apache server
> included with Oracle AS10g under AIX 5.3, such as
> -'PerlModule Apache::Status'
> -'PerlModule Apache::DBI'
> or others using XS, Apache does a coredump.
> 
> The same coredump occurs if no XS using module is loaded from
> httpd.conf but used in a script run from the /perl location.
> 
> The same occurs if an XS using module is run with 'PerlRequire
> initial_load.pl'
> 
> The PERL5LIB value is correctly set in the Apache httpd.conf, so that
> is not the problem. Oracle support has provided very little help to
> date, and mod_perl usage is critical for our SingleSignOn system.

  So this only happens when you load an XS module or run a script that
  uses one?  This sounds to me like a binary incompatibility problem.
  Such as Apache, mod_perl, and Perl itself were compiled under one
  compiler and your XS modules under another ( or just a different 
  version ). 

  Unless the version that Oracle gave you gives you some special
  features, I would recommend recompiling Apache, mod_perl, perl, 
  and your XS modules with the compiler on your server.

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -

Apache segfaults with Oracle AS10g (9.0.4.0) when attempting to use mod_perl

[Rafael Caceres]

When trying to use any mod_perl functionality in the Apache server
included with Oracle AS10g under AIX 5.3, such as
-'PerlModule Apache::Status'
-'PerlModule Apache::DBI'
or others using XS, Apache does a coredump.

The same coredump occurs if no XS using module is loaded from httpd.conf
but used in a script run from the /perl location.

The same occurs if an XS using module is run with 'PerlRequire
initial_load.pl'

The PERL5LIB value is correctly set in the Apache httpd.conf, so that is
not the problem. Oracle support has provided very little help to date,
and mod_perl usage is critical for our SingleSignOn system.

Any help is appreciated,
Rafael Caceres

Re: ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

I think I may now have a better understanding of this and that the 
problem lies in CGI.pm. I've emailed the following to Lincoln Stein 
explaining what I believe to be true. Perhaps someone can either confirm 
my understanding or otherwise correct me.


My email to Lincoln Stein is as follows:
I did some more research and I believe I understand the problem and why 
it only happens when the mod_perled x.cgi is used multiple times as a 
server side include within the same html file.


The issue is with this line of code in CGI::new
$r->pool->cleanup_register(\&CGI::_reset_globals);

From my understanding, that sets up a apache callback to clean up your 
globals **after** the apache process is done serving the request.


However, in the case where x.cgi is used multiple times as a server side 
include in the same html file, _reset_globals is not called until the 
apache process is done with the request.


It seems to me it would be best simply to call _reset_globals first 
thing in your new() method when you detect a mod_perl environment. That 
way we know all those globals are clean for each use.


Unless you can offer another suggestion, my solution at present is to 
add the following to all my mod_perled scripts that use CGI.pm:

CGI::initialize_globals();

I hope you can help with this.

Jim Albert wrote:


I'm trying to debug a strange situation with the following environment:
Apache 2.0.54
mod_perl 2.0.1
perl 5.8.6
CGI.pm 3.10
Linux 2.6.12-1.1447_FC4smp

Say I have a mod_perl script called x.cgi configured for mod_perl as 
follows:


  SetHandler perl-script
  PerlHandler ModPerl::PerlRun
  Options ExecCGI
  PerlSendHeader On


**NOTE that I am using ModPerl::PerlRun

x.cgi uses CGI.pm as follows:

use strict;
use CGI qw (:cgi);

my $inp = param('inp');
print STDERR ("inp = $inp\n");


x.cgi works fine as a ModPerl::PerlRun script except for the case where 
I use it multiple times as a Server Side Include in the same .html file 
as follows:










In such a case the value of inp prints as 50 for both calls.

I've tested this on a single httpd process system and x.cgi works 
properly for multiple calls to it (with different values for inp) during 
the life of that single httpd process. I only get the strange incorrect 
results when used as a server side include multiple times within the 
same html file.


After attempting to track down the problem, the best I can come up with 
is there is a global @QUERY_PARAM array in CGI.pm that does not get 
cleared when x.cgi is uses multiple times as server side include in the 
same html file. If @QUERY_PARAM is not cleared, CGI.pm continues to use 
the same QUERY_STRING.


However, I don't believe this is a CGI.pm bug. I believe 
ModPerl::PerlRun appears to be clearing @QUERY_PARAM properly between 
multiple calls of x.cgi. However, ModPerl::PerlRun does not appear to 
clearing @QUERY_PARAM between multiple calls to x.cgi when x.cgi is used 
mutliple times as a server side include in the same html file.


I'm guessing there is either a problem with ModPerl::PerlRun or Apache 
2.0.54.


Perhaps there is some httpd.conf or perl.conf configuration I should be 
looking at?


Thanks for any help you can provide as currently the only solution I 
have is to hack up CGI.pm but I don't believe that is the best solution 
as the relevant code of CGI.pm does not appear to have changed from 
another version of CGI.pm on a different system where this works fine.





--
Jim Albert

Re: Problems Getting Mod Perl To Work on Windows

[Frank Wiles]

On Tue, 04 Oct 2005 14:00:42 -0500
Troy Bull <[EMAIL PROTECTED]> wrote:

> I removed that line and it started up.  And when I ran my test script
> at the following location
> 
> /ir/test.pl
> 
> (this script echos out the envronment variables)  I get the following 
> output  It was my understanding that GATEWAY_INTERFACE should say 
> something like CGI-Perl/1.1 is that true or am I working and to dumb
> to know it?

  Nope you're working. And these two below let you know that. 

> # MOD_PERL = "mod_perl/2.0.1"
> # MOD_PERL_API_VERSION = "2"


  See
http://perl.apache.org/docs/2.0/user/portingcompat.html#C__ENV_GATEWAY_INTERFACE__

  for more information on this. 

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -

mod_perl 1.28 + 1.29 seg fault

[Terry, Jason]

Net::SSLeay causes a seg fault in mod_perl.  This only happens in
mod_perl when using RegistryLoader on a script in apache startup.
 
For example if I have this line
Apache::RegistryLoader->new->handler('myscript.cgi',
"/home/htmlmanager/public_html/myscript.cgi");

But if I don't load the file in RegistryLoader then everything works.

I've tried several versions of Net::SSLeay and OpenSSL to no avail.  I
recompiled everything to get this gdb output.

[src]# gdb httpd
GNU gdb Red Hat Linux (6.3.0.0-1.21rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for
details.
This GDB was configured as "i386-redhat-linux-gnu"...Using host
libthread_db library "/lib/libthread_db.so.1".

(gdb) run -X -f /usr/local/apache/conf/httpd.conf
Starting program: /home/jter/working/apache_1.3.33/src/httpd -X -f
/usr/local/apache/conf/httpd.conf
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xb45000
[Thread debugging using libthread_db enabled]
[New Thread 1152704 (LWP 8477)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1152704 (LWP 8477)]
0x00af4866 in ssl3_version_str () from /lib/libssl.so.5
(gdb) bt
#0  0x00af4866 in ssl3_version_str () from /lib/libssl.so.5
#1  0x0020 in ?? ()
#2  0x0835dd9d in PBE2PARAM_seq_tt ()
#3  0x005a in ?? ()
#4  0x0c0ed538 in ?? ()
#5  0x0b591fd4 in ?? ()
#6  0x in ?? ()

Re: Problems Getting Mod Perl To Work on Windows

[Troy Bull]

I removed that line and it started up.  And when I ran my test script
at the following location

/ir/test.pl

(this script echos out the envronment variables)  I get the following
output  It was my understanding that GATEWAY_INTERFACE should say
something like CGI-Perl/1.1 is that true or am I working and to dumb to
know it?

Output: 
COMSPEC = "C:\WINNT\system32\cmd.exe"
DOCUMENT_ROOT = "C:/apache/htdocs"
GATEWAY_INTERFACE = "CGI/1.1"
HTTP_ACCEPT =
"text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"
HTTP_ACCEPT_CHARSET = "ISO-8859-1,utf-8;q=0.7,*;q=0.7"
HTTP_ACCEPT_ENCODING = "gzip,deflate"
HTTP_ACCEPT_LANGUAGE = "en-us,en;q=0.5"
HTTP_CACHE_CONTROL = "no-cache"
HTTP_CONNECTION = "keep-alive"
HTTP_HOST = "server.bulls.com:8080"
HTTP_KEEP_ALIVE = "300"
HTTP_PRAGMA = "no-cache"
HTTP_USER_AGENT = "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
rv:1.7.12) Gecko/20050915 Firefox/1.0.7"
MOD_PERL = "mod_perl/2.0.1"
MOD_PERL_API_VERSION = "2"
PATH =
"C:\Perl\bin\;C:\WINNT\system32;C:\WINNT;C:\WINNT\System32\Wbem;C:\Program
Files\ATI Technologies\ATI Control Panel;C:\Program Files\Easy Software
Products\HTMLDOC\;C:\Program Files\Microsoft SQL
Server\80\Tools\BINN;C:\Program
Files\SecureCRT\;c:\cygwin\bin;C:\Program
Files\QuickTime\QTSystem\;C:\Program Files\Executive
Software\Diskeeper\;C:\Program Files\IDM Computer
Solutions\UltraEdit-32"
PATHEXT = ".COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH"
QUERY_STRING = ""
REMOTE_ADDR = "192.168.1.200"
REMOTE_PORT = "2462"
REQUEST_METHOD = "GET"
REQUEST_URI = "/ir/test.pl"
SCRIPT_FILENAME = "C:/apache/ir/test.pl"
SCRIPT_NAME = "/ir/test.pl"
SERVER_ADDR = "192.168.1.200"
SERVER_ADMIN = "[EMAIL PROTECTED]"
SERVER_NAME = "server.bulls.com"
SERVER_PORT = "8080"
SERVER_PROTOCOL = "HTTP/1.1"
SERVER_SIGNATURE = "
  Apache/2.0.54 (Win32) mod_apreq2-20050712/2.1.3-dev
mod_perl/2.0.1 Perl/v5.8.7 Server at server.bulls.com Port 8080
\n"
SERVER_SOFTWARE = "Apache/2.0.54 (Win32)
mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.1 Perl/v5.8.7"
SystemRoot = "C:\WINNT"
WINDIR = "C:\WINNT"


Frank Wiles wrote:

  On Tue, 04 Oct 2005 13:23:50 -0500
Troy Bull <[EMAIL PROTECTED]> wrote:

  
  
PerlModule Apache2

  
  
  Try removing this from your config file.  This shouldn't be 
  necessary since you are running mod_perl 2.0.1.  

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -
  

Re: [RELEASE CANDIDATE] Apache-Test-1.27 RC

[Philip M. Gollucci]

Philip M. Gollucci wrote:

A release candidate for Apache-Test 1.27 is now available.

  http://people.apache.org/~pgollucci/at/Apache-Test-1.27-dev.tar.gz
I've noticed we include the RELEASE file in the release tarball.  I don't believe mod_perl or apreq do.  Is this 
intentional ?


--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
  http://www.liquidityservicesinc.com
   http://www.liquidation.com
   http://www.uksurplus.com
   http://www.govliquidation.com
   http://www.gowholesale.com

Re: Problems Getting Mod Perl To Work on Windows

[Frank Wiles]

On Tue, 04 Oct 2005 13:23:50 -0500
Troy Bull <[EMAIL PROTECTED]> wrote:

> PerlModule Apache2

  Try removing this from your config file.  This shouldn't be 
  necessary since you are running mod_perl 2.0.1.  

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -

Re: Problems Getting Mod Perl To Work on Windows

[Randy Kobes]

On Tue, 4 Oct 2005, Troy Bull wrote:


Here is a bit more info  my httpd.conf where I load the mod perl :

LoadModule perl_module modules/mod_perl.so
LoadFile "C:/Perl/bin/perl58.dll"
LoadFile "c:/apache/Server/Apache2/bin/libapreq2.dll"
LoadModule apreq_module modules/mod_apreq2.so

PerlModule Apache2


In the current mod_perl 2 (which the Win32 ppm package is
based on), there is no Apache2.pm; see
   http://perl.apache.org/docs/2.0/rename.html

--
best regards,
randy kobes

Re: Problems Getting Mod Perl To Work on Windows

[Troy Bull]

Here is a bit more info  my httpd.conf where I load the mod perl :

LoadModule perl_module modules/mod_perl.so
LoadFile "C:/Perl/bin/perl58.dll"
LoadFile "c:/apache/Server/Apache2/bin/libapreq2.dll"
LoadModule apreq_module modules/mod_apreq2.so

PerlModule Apache2

-
where I configure my directory

Alias /ir/ "C:/apache/ir/"


    SetHandler perl-script
      Options +ExecCGI
    PerlSendHeader On
    Allow from all


-
the error log after I try to start apache

[Tue Oct 04 13:24:00 2005] [error] Can't load Perl module Apache2 for
server server.bulls.com:8080, exiting...



Any help greatly appreciated.

thanks
troy


-

Tom Schindl wrote:

  -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Troy Bull wrote:
  
  
I have Apache I downloaded from apache.org.  I got the ppm for mod_perl
from the binary distribution site mentioned on the apache help page.  I
installed it using ppm (active state).  And when I add the following line

PerlModune Apache2

My Apache wont start up.  I tried to carefully follow every direction on
the apache site, does anyone have any ideas where I might look?

The error it gives me is :
The Apache2 service terminated with service-specific error 1.

Thanks
Troy



  
  
What's with the error_log-File?

Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFDQsFZkVPeOFLgZFIRAr9KAJ98m0j2cypABLAHLn5/ONeyPI4AogCfbj6m
0kWKoWtG0OigigJdPA4vS/U=
=7sHl
-END PGP SIGNATURE-
  

Re: Problems Getting Mod Perl To Work on Windows

[Tom Schindl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Troy Bull wrote:
> I have Apache I downloaded from apache.org.  I got the ppm for mod_perl
> from the binary distribution site mentioned on the apache help page.  I
> installed it using ppm (active state).  And when I add the following line
> 
> PerlModune Apache2
> 
> My Apache wont start up.  I tried to carefully follow every direction on
> the apache site, does anyone have any ideas where I might look?
> 
> The error it gives me is :
> The Apache2 service terminated with service-specific error 1.
> 
> Thanks
> Troy
> 
> 

What's with the error_log-File?

Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFDQsFZkVPeOFLgZFIRAr9KAJ98m0j2cypABLAHLn5/ONeyPI4AogCfbj6m
0kWKoWtG0OigigJdPA4vS/U=
=7sHl
-END PGP SIGNATURE-

Problems Getting Mod Perl To Work on Windows

[Troy Bull]

I have Apache I downloaded from apache.org.  I got the ppm for mod_perl 
from the binary distribution site mentioned on the apache help page.  I 
installed it using ppm (active state).  And when I add the following line


PerlModune Apache2

My Apache wont start up.  I tried to carefully follow every direction on 
the apache site, does anyone have any ideas where I might look?


The error it gives me is :
The Apache2 service terminated with service-specific error 1.

Thanks
Troy

ModPerl::PerlRun CGI.pm SSI

[Jim Albert]

I'm trying to debug a strange situation with the following environment:
Apache 2.0.54
mod_perl 2.0.1
perl 5.8.6
CGI.pm 3.10
Linux 2.6.12-1.1447_FC4smp

Say I have a mod_perl script called x.cgi configured for mod_perl as 
follows:


  SetHandler perl-script
  PerlHandler ModPerl::PerlRun
  Options ExecCGI
  PerlSendHeader On


**NOTE that I am using ModPerl::PerlRun

x.cgi uses CGI.pm as follows:

use strict;
use CGI qw (:cgi);

my $inp = param('inp');
print STDERR ("inp = $inp\n");


x.cgi works fine as a ModPerl::PerlRun script except for the case where 
I use it multiple times as a Server Side Include in the same .html file 
as follows:










In such a case the value of inp prints as 50 for both calls.

I've tested this on a single httpd process system and x.cgi works 
properly for multiple calls to it (with different values for inp) during 
the life of that single httpd process. I only get the strange incorrect 
results when used as a server side include multiple times within the 
same html file.


After attempting to track down the problem, the best I can come up with 
is there is a global @QUERY_PARAM array in CGI.pm that does not get 
cleared when x.cgi is uses multiple times as server side include in the 
same html file. If @QUERY_PARAM is not cleared, CGI.pm continues to use 
the same QUERY_STRING.


However, I don't believe this is a CGI.pm bug. I believe 
ModPerl::PerlRun appears to be clearing @QUERY_PARAM properly between 
multiple calls of x.cgi. However, ModPerl::PerlRun does not appear to 
clearing @QUERY_PARAM between multiple calls to x.cgi when x.cgi is used 
mutliple times as a server side include in the same html file.


I'm guessing there is either a problem with ModPerl::PerlRun or Apache 
2.0.54.


Perhaps there is some httpd.conf or perl.conf configuration I should be 
looking at?


Thanks for any help you can provide as currently the only solution I 
have is to hack up CGI.pm but I don't believe that is the best solution 
as the relevant code of CGI.pm does not appear to have changed from 
another version of CGI.pm on a different system where this works fine.


--
Jim Albert

Re: Looking for good MP2 reference material

[Philip M. Gollucci]

Perrin Harkins wrote:
Hmmm, not sure where you got that idea, Philip.  The site has been 
around for many years.  I don't even know how old it is because when I 
first heard of mod_perl (in 1998) it already existed.  However, the nice 
design it has now (thanks to hard work by a few generous people) is 
fairly new.

Right the one Stas maintained.  I was refering to the new design on 
perl.apache.org

--
END

What doesn't kill us can only make us stronger.
Nothing is impossible.

Philip M. Gollucci ([EMAIL PROTECTED]) 301.254.5198
Consultant / http://p6m7g8.net/Resume/
Senior Developer / Liquidity Services, Inc.
  http://www.liquidityservicesinc.com
   http://www.liquidation.com
   http://www.uksurplus.com
   http://www.govliquidation.com
   http://www.gowholesale.com

Re: [mp2] $| doesn't work with mod_perl

[Tom Schindl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi pradeep,

is $r->flush(); working, or not?

Tom

pradeep kumar wrote:
> mod_deflate is not loaded on my system and I can still see this problem.
> 
> I instrumented some portion of the code to understand the flow and I
> have some questions. The modperl_filter.c has a function
> modperl_wbucket_flush(). Now the add_flush_bucket variable that is
> passed to this function is not set even when $| is enabled. If I
> manually set it, the autoflush happens as expected. I wanted to know
> when this variable is set and why setting it manually seems to solve the
> problem.
> 
> Thanks in advance for any help on this.
> 
> 
> On 9/23/05, *Tom Schindl* <[EMAIL PROTECTED] >
> wrote:
> 
> Does $r->rflush(); help? Although it should do the same then seting $|
> to undef.
> 
> Tom
> 
> Tom Schindl wrote:
>> pradeep kumar wrote:
> 
Can you please elaborate on why apache filters can be an issue
> with the
autoflush problem that I noticed ?

Also, I noticed that the autoflush work properly when I flush it to a
regular file. Its only when I choose STDOUT that the flushing gets
delayed. Is there some buffering that happens with STDOUT alone ?
> I am
confused if this is a modperl problem or an Apache problem.

> 
> 
>> Well I guess that I read it a while ago but I'm not sure of. As
> far as I
>> understand the Apache2-Filter-System because a bucket is only sent to
>> the filter system after the BUFFER is full. But I really have no idea
>> what happens behind the scences after the print-call.
> 
>> Maybe Stas, Geoff or someone else can look at this and tell you more.
> 
>> Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org

iD8DBQFDQpqikVPeOFLgZFIRAtbPAJ92zeoQZ9varLcVyGRgXEIK5kJBiACeKJWT
Co6Ie/a0wN0sNMTioRnezPw=
=ft3W
-END PGP SIGNATURE-

Re: GlobaRequest, restart_count, and RequestUtil

[Christopher H. Laco]

Michael Peters wrote:


Christopher H. Laco wrote:



use Data::UUID;



I know this isn't what you're looking for since it doesn't answer the
question you have, but just out of curiosity why do you need Data::UUID?
Would something like mod_unique_id work better?

http://httpd.apache.org/docs/1.3/mod/mod_unique_id.html
http://httpd.apache.org/docs/2.0/mod/mod_unique_id.html

It even works well in clusters because it take hostnames into
consideration. And no stray temp files :)



I use uuid generators in the core modules, which operate outside of any 
web serving mechanism.


Once I found the workaround to keep things from segfaulting, I also 
added support for APR::UUID, so it's even more of a non-issue. :-)


-=Chris


smime.p7s
Description: S/MIME Cryptographic Signature

Re: GlobaRequest, restart_count, and RequestUtil

[Michael Peters]

Christopher H. Laco wrote:

>>> use Data::UUID;

I know this isn't what you're looking for since it doesn't answer the
question you have, but just out of curiosity why do you need Data::UUID?
Would something like mod_unique_id work better?

http://httpd.apache.org/docs/1.3/mod/mod_unique_id.html
http://httpd.apache.org/docs/2.0/mod/mod_unique_id.html

It even works well in clusters because it take hostnames into
consideration. And no stray temp files :)

-- 
Michael Peters
Developer
Plus Three, LP

Re: GlobaRequest, restart_count, and RequestUtil

[Christopher H. Laco]

Christopher H. Laco wrote:

Christopher H. Laco wrote:


No love. This block segfaults my apache2/mp2:

if (exists $ENV{MOD_PERL_API_VERSION} && 
$ENV{MOD_PERL_API_VERSION} == 2) {

require Apache2::RequestRec;
require Apache2::RequestUtil;
require Apache2::RequestIO;
require Apache2::ServerUtil;

my $c = eval {Apache2::RequestUtil->request} || 
Apache2::ServerUtil->server;


if ($c) {
$value = $c->dir_config($key) || $ENV{$key} || $default;
};
} elsif ($ENV{MOD_PERL}) {




Commenting out the eval line lets the server run fine and dandy. :-(

-=Chris



Oh geez. I think I found the most obscure bug ever. :-/
I'm working on narrowing down the code to a test case. In a nutshell of 
seudo code, it looks like this:




$ rm -rf /var/tmp/.*

use Data::UUID;
use Apache2::RequestRec;
use Apache2::RequestUtil;
use Apache2::RequestIO;
use Apache2::ServerRec;
use Apache2::ServerUtil;

my $ug = Data::UUID->new;
my $uuid = $ug->create;
print $ug->to_string($uuid);




There is some variance in there.

If I simply 'require' instead of 'use' all of the Apache2 modules, all 
works fine, unless I call ->dir_config, then it goes boom.


It only happens on the first call to Data::UUID, where it creates two 
state files in /var/tmp. Every request after that initial segfault works 
just dandy. On the segfaulted run, it creates the first file, and dies 
on creating the second. If I run the code again, it creates the second 
and goes just dandy only if I use the Apache modules, or 'require' 
them and call dir_config.


If I take the apache2 modules out of the picture and clean /var/tmp, the 
 first call to Data::UUID succeeds , it creates both files in temp, and 
there are no segfaults.


Like I said, the strangest damn thing I've ever seen.

More to come when I get a specific narrowed test case and a ktrace for it.

-=Chris




Just as a followup to this. I found a workaround, but that doesn't 
really make any sense either. If I moved the require block outside of 
the sub, the segfault never happens on the first Data::UUID->new with 
the Apache2: modules loaded...



require Apache2::RequestRec;
require Apache2::RequestUtil;
require Apache2::RequestIO;
require Apache2::ServerUtil;


if (exists $ENV{MOD_PERL_API_VERSION} && $ENV{MOD_PERL_API_VERSION} == 2) {
my $c = eval {Apache2::RequestUtil->request} || Apache2::ServerUtil->server;

if ($c) {
$value = $c->dir_config($key) || $ENV{$key} || $default;};
} elsif ($ENV{MOD_PERL}) { 



That doesn't make a bit of sense to me, but after 5 days of headaches, 
I'll take it.


-=Chris





smime.p7s
Description: S/MIME Cryptographic Signature

Re: Installing Modperl problem

[Maruthi Vara Prasad Chirravuri]

HI All,

This is Maruthi Vara Prasad. I have newly joined in the modperl group.
I hope this could help you in solving the problem.

Plz Make Sure that first Apache is to be Installed, Next Perl and then
Modperl. Also make sure that the Installation tree of mod_perl and
apache are different and not as a subdirectory of the other.

Regards,

Ch. Maruthi Vara Prasad.

On 9/28/05, Brenda Washington <[EMAIL PROTECTED]> wrote:
> I have been working on installing Apache-2.0.54, Mod_perl-2.0.1 with
> perl-5.6.1 for a week now with little or no success. Is there anyone who
> can give me any help with the problem I'm experiencing? When I run perl
> Makefile.PL command, I get the following error messages. How can I resolve
> these errors?
>
>
> $ perl Makefile.PL
> Undefined subroutine &Cwd::abs_path called at /opt/perl5/lib/5.6.1/Cwd.pm
> line 128.
> BEGIN failed--compilation aborted at /opt/perl5/lib/5.6.1/FindBin.pm line
> 166.
> Compilation failed in require at Apache-Test/lib/Apache/TestSmoke.pm line
> 29.
> BEGIN failed--compilation aborted at Apache-Test/lib/Apache/TestSmoke.pm
> line 29.
> Compilation failed in require at Apache-Test/lib/Apache/TestSmokePerl.pm
> line 20.
> BEGIN failed--compilation aborted at Apache-Test/lib/Apache/TestSmokePerl.pm 
> line 20.
> Compilation failed in require at Makefile.PL line 37.
> BEGIN failed--compilation aborted at Makefile.PL line 37.
>
>
>
>
> Brenda Washington
> Unix System Specialist
> 1401 W. Hwy 421
> Westville, Ind. 46360
> (219) 785- 5417
> [EMAIL PROTECTED]
>
>