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

This is a discussion on mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault - modperl ; Looks like we've narrowed the problem that I've described here ( http://mail-archives.apache.org/mod_...808.mbox/%3c5C AFF755525FC5418CCF35FAEB2683BE12A31A...eh.lbcorp.lehm an. 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 ...

+ Reply to Thread
Results 1 to 5 of 5

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

  1. 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_...808.mbox/%3c5C
    AFF755525FC5418CCF35FAEB2683BE12A31A...eh.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 = sub { return $_[0] };
    *lock = sub { 0 };

    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.


  2. 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


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

    Hey, Perrin,

    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.

    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?

    Eric

    > -----Original Message-----
    > From: pharkins@gmail.com [mailtoharkins@gmail.com] On
    > Behalf Of Perrin Harkins
    > Sent: Thursday, September 04, 2008 6:36 PM
    > To: Berg, Eric
    > Cc: modperl@perl.apache.org
    > Subject: 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
    >

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    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.


  4. 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


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

    > On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric
    > > 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?


    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.

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


    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!) 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.


+ Reply to Thread