perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cory Omand" <com...@blastwave.org>
Subject Fwd: Apache 2.2 and libapreq2 2.0.7 segfault
Date Thu, 30 Mar 2006 20:52:23 GMT
Copying the list

---------- Forwarded message ----------
From: Cory Omand <coryomand@gmail.com>
Date: Mar 30, 2006 12:51 PM
Subject: Re: Apache 2.2 and libapreq2 2.0.7 segfault
To: "Philip M. Gollucci" <pgollucci@p6m7g8.com>


On 3/30/06, Cory Omand <comand@blastwave.org> wrote:
> On 3/29/06, Philip M. Gollucci <pgollucci@p6m7g8.com> wrote:
> > > Can't load '/export/medusa/comand/csw/cpan/libapreq2/work/comand-ra.d/libapreq2-2.07/glue/perl/t/cgi-bin/../../blib/arch/auto/APR/Request/Request.so'
> > > for module APR::Request: ld.so.1: test_cgi.pl: fatal: libapreq2.so.3:
> > set the LD_LIBRARY_PATH in your shell to the appropriate paths.  Thats
> > strange.  This isn't your problem, but I'm hoping the test out will give me
> > something to go on.  I'm having some "issues" looking at ndm instead of gdb.
>
> It turned out that thanks to libtool, the module and library tests
> were pointing to the uninstalled version of libapreq, allowing the
> tests to run normally.  However, the uninstalled glue Request.so
> module was *not* pointing anywhere useful, and could not find either
> libapreq2 or libapr/aprutil.  No matter what I did, I could not make
> the glue test suite utilize my LD_LIBRARY_PATH.  Not sure why.
> Copying the libs from library/.libs to the destination path before
> running the tests finally allowed the tests to load the library.
>
> Fixing the library loading issues unmasked a different set of test
> failures.  It appears that the test suite relies on 'perltoc.pod' and
> 'perlport.pod' being installed.  My perl installation splits the pod
> docs out from the core perl, and other distributions may do the same.
> Perhaps relying on a pod that is required in the perl core (like
> perldiag.pod, or Config.pm) might be a better idea?
>
> After I installed the pod docs, all tests pass, but usage from within
> Apache still yields a segfault when creating new Request objects.  Now
> I am extremely confused.  I verified that the identical library
> versions are present on the target system, and that all shared objects
> are able to locate libapr/aprutil/apreq2.  Any ideas?

Here is an interesting fact that I did not realize until just a moment
ago.  If you declare a mod_perl 2.x handler as:

package Some::Module;

sub handler {
    my $r = shift;
}

Your $r will be an instance of Apache2::RequestRec.  However, if you
declare your handler as:

package Some::Module;

sub handler :method {
    my $r = shift;
}

Your $r will be an instance of Some::Module!  This is the way my test
handler was defined, which I gleaned recently from the mod_perl 2.0
docs.  I guess I didn't read far enough into the docs to realize what
':method' was doing to my argument list.

Anyway, if you pass an instance of Some::Module to the constructor of
Apache2::Request or Apache2::Cookie, apache will segfault.  I would
have expected Apache2::Request to complain to me about the object
class if I passed it an unexpected class, not a segv.  I've attached a
patch which would bail if anything but an instance of
Apache2::RequestRec is passed to Apache2::Request or Apache2::Cookie
constructors...

- C.

Mime
View raw message