mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault

Looks like we've narrowed the problem that I've described here
(http://mail-archives.apache.org/mod_mbox/perl-modperl/20080 8.mbox/%3c5C
AFF755525FC5418CCF35FAEB2683BE12A31A6C=40njpcmg1exms305.leh. lbcorp.lehman.
com%3e)

It's something having to do with our use of Test::Builder. Simplly
including Test::Builder in a CGI running under ModPerl::RegistryPrefork
causes it to segfault on a very regular basis.

Here's the message I posted on CPAN Forum for Test::Simple:

>>>>>>>>>>>>>>>
Recently, during the process of porting all my apache 1.3/mod_perl 1.x
CGI's running under ModPerl::RegistryPrefork, I started running into
regular segfaults. After a whole bunch of head scratching and testing,
we narrowed down the problem to our use'ing Test::Builder.

It appears to be some kind of conflict that might have to do with the
BEGIN code block that contains these lines for non-threaded Perl:

*share =3D sub =7B return =24_=5B0=5D =7D;
*lock =3D sub =7B 0 =7D;

I don't completely understand what these do in the context of
non-threaded apps, though they appear to be fairly innocuous at first
glance.

In any case, it's just using Test::Builder that causes Apache 2.2/mp2 to
segfault.

Many of our core modules contain test methods that are executed during
our CVS checkin process as regression tests, so we'd have to completely
redo our regression testing architecture to decouple Test::Builder from
our code.

Has anybody had any similar experience with this problem, or can you
help shed some light on the problem to help get us to a solution?
<<<<<<<<<<<<<<<

Has anybody seen this or anything like it before?

Eric
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

Re: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault

On Thu, Sep 4, 2008 at 6:09 PM, Berg, Eric wrote:
> Many of our core modules contain test methods that are executed during
> our CVS checkin process as regression tests, so we'd have to completely
> redo our regression testing architecture to decouple Test::Builder from
> our code.

As a quick fix, you could load it conditionally based on whether or
not $ENV{MOD_PERL} is true.

- Perrin

RE: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault

Hey, Perrin,=20

When I say that Test::Builder/Test::More/etc. are tightly coupled, I'm
talking really entwined. In some cases, we have created a class with a
bunch of test-related methods that look through the symbol table and
find methods that =~ m/=5Etest_/ and then we run those tests, which
include calls to Test::Builder methods. There's no easy way to turn
this off.

When you say that we could load it conditionally -- again, not really an
option -- are you thinking that we could do a conditional require() and
import explicitly or use fully-qualified calls?=20

Eric

> -----Original Message-----
> From: pharkins=40gmail.com =5Bmailto:pharkins=40gmail.com=5D On=20
> Behalf Of Perrin Harkins
> Sent: Thursday, September 04, 2008 6:36 PM
> To: Berg, Eric
> Cc: modperl=40perl.apache.org
> Subject: Re: mod_perl2 + ModPerl::RegistryPrefork +=20
> Test::Builder =3D segfault
>=20
> On Thu, Sep 4, 2008 at 6:09 PM, Berg, Eric=20
> wrote:
> > Many of our core modules contain test methods that are=20
> executed during
> > our CVS checkin process as regression tests, so we'd have=20
> to completely
> > redo our regression testing architecture to decouple=20
> Test::Builder from
> > our code.
>=20
> As a quick fix, you could load it conditionally based on whether or
> not =24ENV=7BMOD_PERL=7D is true.
>=20
> - Perrin
>=20
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.

Re: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault

On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric wrote:
> When I say that Test::Builder/Test::More/etc. are tightly coupled, I'm
> talking really entwined. In some cases, we have created a class with a
> bunch of test-related methods that look through the symbol table and
> find methods that =~ m/^test_/ and then we run those tests, which
> include calls to Test::Builder methods. There's no easy way to turn
> this off.

This happens even when you're not testing? Or do you really want to
run those tests every time anyone loads the module?

> When you say that we could load it conditionally -- again, not really an
> option -- are you thinking that we could do a conditional require() and
> import explicitly or use fully-qualified calls?

The former - a BEGIN block that determines the situation and loads
test modules if you're not in mod_perl. You can also do tricks to
fake Test::Builder's API without loading it, but that's a really
roundabout way of dealing with the issue.

- Perrin

RE: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault

> On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric=20
> > When I say that Test::Builder/Test::More/etc. are tightly=20
> > coupled, I'm talking really entwined. In some cases, we have
created a=20
> > class with a bunch of test-related methods that look through the
symbol=20
> > table and find methods that =~ m/=5Etest_/ and then we run those
tests, which
> > include calls to Test::Builder methods. There's no easy way to turn
> > this off.
>=20
> This happens even when you're not testing? Or do you really want to
> run those tests every time anyone loads the module?

No, we only run those tests when we check them into CVS and the hooks
trigger scripts that run the test methods in our modules. The problem
is that when you load/use Test::Builder, it creates a singleton instance
that does some initialization, including mapping STDERR and STDOUT -- I
believe to class variables. Have you ever noticed how you never see
anything coming out of CPAN mods when you do a make test? I think this
is the reason: stdout and stderr are captured this way.

>=20
> > When you say that we could load it conditionally -- again,=20
> > not really an option -- are you thinking that we could do a
conditional=20
> > require() and import explicitly or use fully-qualified calls?
>=20
> The former - a BEGIN block that determines the situation and loads
> test modules if you're not in mod_perl. You can also do tricks to
> fake Test::Builder's API without loading it, but that's a really
> roundabout way of dealing with the issue.

Right. That'd be good if we were't a) subclassing from modules that
directly use Test::Builder methods, and b) have T::B calls throughout
our code.

Right now I'm working on figuring out how to disable the mapping (which
appears to happen in Test::Builder->_dup_stdhandles() so that we can
have everything play nicely together.

As much as I love having my modules validated whenver they're checked in
(especially for the other developers=21) this is killin' me.

E
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - =
- - - - - - -

This message is intended only for the personal and confidential use of the =
designated recipient(s) named above. If you are not the intended =
recipient of this message you are hereby notified that any review, =
dissemination, distribution or copying of this message is strictly =
prohibited. This communication is for information purposes only and =
should not be regarded as an offer to sell or as a solicitation of an =
offer to buy any financial product, an official confirmation of any =
transaction, or as an official statement of Lehman Brothers. Email =
transmission cannot be guaranteed to be secure or error-free. Therefore, =
we do not represent that this information is complete or accurate and it =
should not be relied upon as such. All information is subject to change =
without notice.

--------
IRS Circular 230 Disclosure:
Please be advised that any discussion of U.S. tax matters contained within =
this communication (including any attachments) is not intended or written =
to be used and cannot be used for the purpose of (i) avoiding U.S. tax =
related penalties or (ii) promoting, marketing or recommending to another =
party any transaction or matter addressed herein.