Output of external program is getting lost in mod_perl 2.0.4
Hi,
I am migrating my application from httpd 1.x and mod_perl 1.x to
mod_perl-2.0.4 and httpd-2.2.9. Some of the forms in my application uses
and standalone script which excutes some external scripts
like os commands or some other perl/shell scripts.
Here is the source code for the script that executes an external program
http://rafb.net/p/Wjj41u36.html
Here the function do_cmd executes and stores output to self->{DOCMD_OUTPUT}
. This was working fine when we executing mod_perl 1.x but after we migrated
to
mod_perl 2.0.4 as we call get_last_do_cmd_output function the output is
empty. Any idea where the output is lost ? . Look at do_cmd and _for_exec
function to see how
we are re-directing the output to a pipe
--Shibi Ns--
Stacktrace of segfault on fork in mp2/perl-5.10
I posted this a little while ago, and was hoping that some of you C-oriented folks could take a look at this stack trace and see if anything jumps out at you that would indicate why I'm consistently getting segmentation faults (11) when forking in a CGI running under ModPerl::RegistryPrefork. Thanks for any insight you can provide. [Wed Aug 27 18:29:29 2008] pid 24456 mod_backtrace backtrace for sig 11 (thread "pid" 24456) [Wed Aug 27 18:29:29 2008] pid 24456 mod_backtrace main() is at 8062fb8 /home/pointsrv/apache/config/dev/modules/mod_backtrace.so[0xa3fa43] /home/erberg/public_html/work/point-www/aut(ap_run_fatal_exception+0x2e) [0x8079ce2] /home/erberg/public_html/work/point-www/aut[0x807b0a0] /lib/tls/libpthread.so.0[0x5b9a98] /home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_PerlIO_flush+0 x68)[0x116e648] /home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_pp_fork+0x45)[ 0x1149b55] /home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_runops_standar d+0x18)[0x1102fe8] /home/pointsrv/apache/config/dev/modules/mod_perl.so(Perl_call_sv+0x49a) [0x110106a] /home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_callback+0x 180)[0x10764f0] /home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_callback_ru n_handlers+0x35a)[0x1076b3a] /home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_callback_pe r_dir+0x53)[0x1076e83] /home/pointsrv/apache/config/dev/modules/mod_perl.so(modperl_response_ha ndler_cgi+0x11b)[0x107354b] /home/erberg/public_html/work/point-www/aut(ap_run_handler+0x32)[0x80735 6e] /home/erberg/public_html/work/point-www/aut(ap_invoke_handler+0xad)[0x80 73939] /home/erberg/public_html/work/point-www/aut(ap_process_request+0x18d)[0x 807e669] /home/erberg/public_html/work/point-www/aut[0x807c145] /home/erberg/public_html/work/point-www/aut(ap_run_process_connection+0x 32)[0x8078e12] /home/erberg/public_html/work/point-www/aut[0x80822c9] /home/erberg/public_html/work/point-www/aut[0x808249e] /home/erberg/public_html/work/point-www/aut[0x808252c] [Wed Aug 27 18:29:29 2008] pid 24456 mod_backtrace end of backtrace [Wed Aug 27 18:29:30 2008] [notice] child pid 24456 exit signal Segmentation fault (11), possible coredump in /tmp Eric Berg - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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.
mod_perl 2 and IPC::Open3
Hi,
I'm using source-highlight in a mod_perl application. This program takes
code in STDIN and prints the html-highlighted code to STDOUT.
My code works fine from the commandline and in
Apache/1.3.37 (Unix) mod_perl/1.30
(perl 5.8.8)
On another machine it also works from the commandline, but not in
Apache/2.2.3 (Debian) mod_perl/2.0.2 Perl/v5.8.8
There is no error, I just cannot get anything from the read handle, it
seems to be empty.
Also an "or die $!" after the open3 is not executed.
I searched for similar problems, I found a posting where they said it would
help to untie STDIN before the open3, but this didn't help.
I also don't get any lines back from the error handle.
Does anybody have an idea what it could be? Maybe I should update to a
more recent mod_perl?
The version of IPC::Open3 is 1.02
Thanks,
tina
Here's the code:
# --
use strict;
use warnings;
use IPC::Open3;
use Data::Dumper;
use POSIX;
my $content = <<'EOM';
if ($foo) {
bar() # bar
}
EOM
my $highlighted = '';
my $success = 0;
my $pid;
eval {
my($wtr, $rdr, $err);
$pid = open3($wtr, $rdr, $err,
'/usr/bin/source-highlight', '-s', 'perl', '-css', '--no-doc');
print $wtr $content;
close $wtr;
warn __PACKAGE__.':'.__LINE__.": before read loop\n";
while (<$rdr>) {
# this is not executed
warn __PACKAGE__.':'.__LINE__.": line $_\n";
$highlighted .= $_;
}
# code after the loop is executed
};
if ($@) {
warn __PACKAGE__.':'.__LINE__.": ERROR happened: $@ ($$)\n";
$highlighted = "error";
POSIX::_exit(1);
die "oops ($$)";
}
else {
my $exit = waitpid $pid, 0;
$success = 1 if $exit;
}
# --
--
http://darkdance.net/
http://perlpunks.de/
http://www.trashcave.de/
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/200808.mbox/%3c5C
[EMAIL PROTECTED]
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.
Re: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault
On Thu, Sep 4, 2008 at 6:09 PM, Berg, Eric <[EMAIL PROTECTED]> 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,
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
> <[EMAIL PROTECTED]> 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.
Re: mod_perl2 + ModPerl::RegistryPrefork + Test::Builder = segfault
On Thu, Sep 4, 2008 at 6:58 PM, Berg, Eric <[EMAIL PROTECTED]> 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 > > 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.
