RE: Search Engine Theory
Title: RE: Search Engine Theory Check out the book Managing Gigabytes Text indexing theory and algorithms. Source code too. -Original Message- From: Jamie Krasnoo [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 27, 2001 3:03 PM To: Modperl Subject: Search Engine Theory Can anyone point me to any documents on search engine theory and programming search engines with perl? Jamie Krasnoo www.MyEBoard.com [EMAIL PROTECTED]
RE: Debugging mod_perl with gdb
Title: RE: Debugging mod_perl with gdb Hey thanks. I'll try this. I tried the 'man gdb' command and it didn't help much I'm afraid... -Original Message- From: sterling [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 06, 2001 12:33 PM To: Shane Adams Cc: [EMAIL PROTECTED] Subject: Re: Debugging mod_perl with gdb If you're looking for which piece of perl code being processed, there are some gdb macros to help. If you source the .gdbinit in the root of your modperl dir you have access to a bunch of cool macros to use. In this case, curinfo will give you the current line number in your perl code. here's the macro: define curinfo printf %d:%s\n, PL_curcop-cop_line, \ ((XPV*)(*(XPVGV*)PL_curcop-cop_filegv-sv_any)\ -xgv_gp-gp_sv-sv_any)-xpv_pv end hope that helps. sterling On Tue, 6 Feb 2001, Shane Adams wrote: Hey there - I've successfully built apache/mod_perl with full debugging. In addition, I'm running the whole setup through insure, a commercial memory leak/corruption tool. I've found a write to a dangling pointer when apache/mod_perl evaluates a perl section of the apache config file. My question: How do I go about attacking this problem? I only know that I'm in a Perl section due to printing out some variables somewhere at ap_read_config() to invoke_cmd(). I guess I'm trying to find out what the perl script is doing when the memory corruption occurs. Obviously if I could narrow the offending line of code (if possible) I might be able to better understand where the real bug is. Shane -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 30, 2001 5:25 PM To: AxKit Users Mailing List Cc: [EMAIL PROTECTED] Subject: (Correction) Re: Object-XML serialization [was Re: AxKit Users?] On Tue, 30 Jan 2001 [EMAIL PROTECTED] wrote: Castor (for Java, from www.exolab.com), uses an actual XML Schema for this. The advantage is that you can leverage off the fairly rich existing set of defined datatypes. Sorry, it's www.exolab.org, don't you hate that? --Chris
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault
Yes. We found a problem in Expat.pm line 451 (in sub parse). The following chunk of code (latest version from cpan)
sub parse {
my $self = shift;
my $arg = shift;
croak Parse already in progress (Expat) if $self-{_State_};
$self-{_State_} = 1;
my $parser = $self-{Parser};
my $ioref;
my $result = 0;
if (defined $arg) {
if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) {
$ioref = $arg;
} else {
eval {
$ioref = *{$arg}{IO}; ### Problem code
};
undef $@;
}
}
## Rest snipped
As you can see it's trying to oddly reference what you passs in to parse as some screwed up typeglof reference. In your example (and indeed in our code) we where simply passing a scalar. This generated coredumps. We got around the problem by just commenting out the eval and $ioref code, So The above became
if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) {
$ioref = $arg;
} else {
##eval {
## $ioref = *{$arg}{IO}; ### Problem code
##};
undef $@;
}
Clean fix? No, but we are always dealing with scalars, not some other sort of odd input stream and just punted on the problem. Core dumps disappeared.
-Original Message-
From: Herrington, Jack [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 3:03 PM
To: '[EMAIL PROTECTED]'
Subject: XML::Parse segmentation fault
This code works as a perl script executed off the command line:
use XML::Parser;
my $parser = new XML::Parser();
$parser-parse( form/form );
This code fails with a segmentation fault when called from mod_perl:
package CBL::mod_perl::test1;
use strict;
use XML::Parser;
sub handler
{
my $r = shift;
my $parser = new XML::Parser();
$parser-parse( form/form );
$r-content_type( 'text/html' );
$r-send_http_header;
$r-print( htmlbody );
$r-print( Testing );
$r-print( /body/html );
return OK;
}
1;
Is there some inherint problem with XML::Parser and mod_perl?
Jack Herrington
Engineering Manager
Certive - Building the world's first broadband B2B network
(650) 701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault
Hmmm
well I *have* to have Xml parsing. Not sure if what you are suggesting totally
turns it off or just does something else?
-Original Message-From: Herrington, Jack
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000
3:49 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE:
:Parse segmentation fault
I did a
little more digging around and found that you could also avoid the problem by
turning off EXPAT in apache with:
Rule
EXPAT=no
Which fix
is more preferable?
-Original Message-From: Shane Adams
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43
PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject:
RE: :Parse segmentation fault
Yes. We found a problem in Expat.pm line 451 (in sub
parse). The following chunk of code (latest version from cpan)
sub parse { my $self =
shift; my $arg = shift; croak "Parse already in progress (Expat)" if
$self-{_State_}; $self-{_State_} =
1; my $parser = $self-{Parser};
my $ioref; my $result
= 0;
if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else {
eval { $ioref =
*{$arg}{IO}; ### Problem code }; undef $@; } }
## Rest snipped
As you can see it's trying to oddly reference what you passs
in to parse as some screwed up typeglof reference. In your example
(and indeed in our code) we where simply passing a scalar. This
generated coredumps. We got around the problem by just commenting out
the eval and $ioref code, So The above became
if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else {
##eval { ## $ioref =
*{$arg}{IO}; ### Problem code ##}; undef $@; }
Clean fix? No, but we are always dealing with scalars,
not some other sort of odd input stream and just punted on the
problem. Core dumps disappeared.
-Original Message- From:
Herrington, Jack [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject: XML::Parse
segmentation fault
This code works as a perl script executed off the command
line:
use
XML::Parser; my $parser = new XML::Parser();
$parser-parse( "form/form" );
This code fails with a segmentation fault when called from
mod_perl:
package
CBL::mod_perl::test1;
use
strict; use XML::Parser;
sub
handler { my $r = shift;
my $parser = new
XML::Parser(); $parser-parse(
"form/form" );
$r-content_type(
'text/html' );
$r-send_http_header;
$r-print(
"htmlbody" );
$r-print( "Testing"
); $r-print(
"/body/html" );
return OK;
}
1;
Is there some inherint problem with XML::Parser and
mod_perl?
Jack Herrington
Engineering
Manager Certive - Building the world's first broadband B2B network
(650)
701-8809
RE: :Parse segmentation fault
Title: RE: :Parse segmentation fault
no
clue. I emailed your comment to a friend at work and see what he can make
of it. He's the fellow that found the cause of the segfault in the first
place.
Shane
-Original Message-From: Herrington, Jack
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000
3:59 PMTo: Shane Adams; '[EMAIL PROTECTED]'Subject: RE:
:Parse segmentation fault
This allows
for XML parsing with no change to the Perl code. I'm just not sure what
I am losing in Apache (which is where I make the change). What does
losing EXPAT do to Apache?
-Original Message-From: Shane Adams
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 4:02
PMTo: Herrington, Jack; '[EMAIL PROTECTED]'Subject:
RE: :Parse segmentation fault
Hmmm well I *have* to have Xml parsing. Not sure if
what you are suggesting totally turns it off or just does something
else?
-Original Message-From: Herrington, Jack
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09,
2000 3:49 PMTo: Shane Adams;
'[EMAIL PROTECTED]'Subject: RE: :Parse segmentation
fault
I did a
little more digging around and found that you could also avoid the problem
by turning off EXPAT in apache with:
Rule
EXPAT=no
Which
fix is more preferable?
-Original Message-From: Shane Adams
[mailto:[EMAIL PROTECTED]]Sent: Monday, October 09, 2000 3:43
PMTo: Herrington, Jack;
'[EMAIL PROTECTED]'Subject: RE: :Parse segmentation
fault
Yes. We found a problem in Expat.pm line 451 (in
sub parse). The following chunk of code (latest version from
cpan)
sub parse { my $self =
shift; my $arg = shift; croak "Parse already in progress (Expat)" if
$self-{_State_}; $self-{_State_}
= 1; my $parser =
$self-{Parser}; my $ioref;
my $result = 0;
if (defined $arg) { if (ref($arg) and UNIVERSAL::isa($arg,
'IO::Handler')) {
$ioref = $arg; } else
{ eval {
$ioref =
*{$arg}{IO}; ### Problem code }; undef $@; } }
## Rest snipped
As you can see it's trying to oddly reference what you
passs in to parse as some screwed up typeglof reference. In your
example (and indeed in our code) we where simply passing a scalar.
This generated coredumps. We got around the problem by just
commenting out the eval and $ioref code, So The above became
if (ref($arg) and
UNIVERSAL::isa($arg, 'IO::Handler')) { $ioref = $arg; } else { ##eval { ## $ioref =
*{$arg}{IO}; ### Problem code ##}; undef $@; }
Clean fix? No, but we are always dealing with
scalars, not some other sort of odd input stream and just punted on the
problem. Core dumps disappeared.
-Original Message- From:
Herrington, Jack [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 3:03 PM To: '[EMAIL PROTECTED]' Subject:
XML::Parse segmentation fault
This code works as a perl script executed off the
command line:
use
XML::Parser; my $parser = new XML::Parser();
$parser-parse( "form/form" );
This code fails with a segmentation fault when called
from mod_perl:
package
CBL::mod_perl::test1;
use
strict; use XML::Parser;
sub
handler { my $r = shift;
my $parser = new
XML::Parser();
$parser-parse( "form/form" );
$r-content_type(
'text/html' );
$r-send_http_header;
$r-print(
"htmlbody" );
$r-print(
"Testing" ); $r-print(
"/body/html" );
return OK;
}
1;
Is there some inherint problem with XML::Parser and
mod_perl?
Jack Herrington
Engineering
Manager Certive - Building the world's first broadband B2B network
(650)
701-8809
Core file (debugging info turned on/stack trace)
Title: Core file (debugging info turned on/stack trace) Apache 1.3.12, mod_perl 1.24, Perl 5.6.0, Redhat 6.1 ... Program terminated with signal 11, Segmentation fault. ... 0 0x814abd4 in Perl_sv_setsv (dstr=0x8d34514, sstr=0x84afba4) at sv.c:2774 #1 0x813b6b3 in Perl_pp_sassign () at pp_hot.c:117 #2 0x813aeda in Perl_runops_debug () at run.c:56 #3 0x80e4b2f in S_call_body (myop=0x72f0, is_eval=0) at perl.c:1761 #4 0x80e4415 in perl_call_sv (sv=0x8845bd4, flags=2) at perl.c:1638 #5 0x812a892 in Perl_vdie ( pat=0x81d46a0 Can't use string (\%.32s\) as %s ref while \strict refs\ in use, args=0x736c) at util.c:1532 #6 0x812aa71 in Perl_die ( pat=0x81d46a0 Can't use string (\%.32s\) as %s ref while \strict refs\ in use) at util.c:1567 #7 0x8155127 in Perl_pp_rv2gv () at pp.c:249 #8 0x813aeda in Perl_runops_debug () at run.c:56 #9 0x80e4b2f in S_call_body (myop=0x74b8, is_eval=0) at perl.c:1761 #10 0x80e4780 in perl_call_sv (sv=0x82e7bcc, flags=4) at perl.c:1677 #11 0x8075aac in perl_call_handler (sv=0x82e7bcc, r=0x88ac844, args=0x0) at mod_perl.c:1643 #12 0x8074fd8 in perl_run_stacked_handlers (hook=0x81ac879 PerlHandler, r=0x88ac844, handlers=0x876f72c) at mod_perl.c:1362 #13 0x80726a8 in perl_handler (r=0x88ac844) at mod_perl.c:905 #14 0x80a0913 in ap_invoke_handler () #15 0x80b3f29 in process_request_internal () #16 0x80b3f8c in ap_process_request () #17 0x80ab82e in child_main () #18 0x80aba6c in make_child () #19 0x80abde6 in perform_idle_server_maintenance () #20 0x80ac315 in standalone_main () #21 0x80ac8d3 in main () So far I've applied a mason related patch thanks to Doug, and a path on perl itself that was listed on this list. Still getting faults however, and they are frequent enough for me to worry about in a production scenario. We are using the HTML::Mason package if it helps any.
RE: Core file (debugging info turned on/stack trace)
Title: RE: Core file (debugging info turned on/stack trace)
Well I did a little more investigation - it seems that we are dieing in Expat.pm line 451. The offending Function is:
sub parse {
my $self = shift;
my $arg = shift;
croak Parse already in progress (Expat) if $self-{_State_};
$self-{_State_} = 1;
my $parser = $self-{Parser};
my $ioref;
my $result = 0;
if (defined $arg) {
if (ref($arg) and UNIVERSAL::isa($arg, 'IO::Handler')) {
$ioref = $arg;
} else {
eval {
$ioref = *{$arg}{IO}; # *** = This is where we are losing it ***
};
undef $@;
}
}
if (defined($ioref)) {
my $delim = $self-{Stream_Delimiter};
my $prev_rs;
$prev_rs = ref($ioref)-input_record_separator(\n$delim\n)
if defined($delim);
$result = ParseStream($parser, $ioref, $delim);
ref($ioref)-input_record_separator($prev_rs)
if defined($delim);
} else {
$result = ParseString($parser, $arg);
}
$self-{_State_} = 2;
$result or croak $self-{ErrorMessage};
}
As I recall, Doug, you helped me patch part of HTML::Mason dealing with typeglobs under an eval ... I believe that * is a typeglob in perl yes?
-Original Message-
From: Shane Adams
Sent: Tuesday, September 26, 2000 4:16 PM
To: [EMAIL PROTECTED]
Subject: Core file (debugging info turned on/stack trace)
Apache 1.3.12, mod_perl 1.24, Perl 5.6.0, Redhat 6.1
...
Program terminated with signal 11, Segmentation fault.
...
0 0x814abd4 in Perl_sv_setsv (dstr=0x8d34514, sstr=0x84afba4) at sv.c:2774
#1 0x813b6b3 in Perl_pp_sassign () at pp_hot.c:117
#2 0x813aeda in Perl_runops_debug () at run.c:56
#3 0x80e4b2f in S_call_body (myop=0x72f0, is_eval=0) at perl.c:1761
#4 0x80e4415 in perl_call_sv (sv=0x8845bd4, flags=2) at perl.c:1638
#5 0x812a892 in Perl_vdie (
pat=0x81d46a0 Can't use string (\%.32s\) as %s ref while \strict refs\ in use,
args=0x736c) at util.c:1532
#6 0x812aa71 in Perl_die (
pat=0x81d46a0 Can't use string (\%.32s\) as %s ref while \strict refs\ in use)
at util.c:1567
#7 0x8155127 in Perl_pp_rv2gv () at pp.c:249
#8 0x813aeda in Perl_runops_debug () at run.c:56
#9 0x80e4b2f in S_call_body (myop=0x74b8, is_eval=0) at perl.c:1761
#10 0x80e4780 in perl_call_sv (sv=0x82e7bcc, flags=4) at perl.c:1677
#11 0x8075aac in perl_call_handler (sv=0x82e7bcc, r=0x88ac844, args=0x0)
at mod_perl.c:1643
#12 0x8074fd8 in perl_run_stacked_handlers (hook=0x81ac879 PerlHandler, r=0x88ac844,
handlers=0x876f72c) at mod_perl.c:1362
#13 0x80726a8 in perl_handler (r=0x88ac844) at mod_perl.c:905
#14 0x80a0913 in ap_invoke_handler ()
#15 0x80b3f29 in process_request_internal ()
#16 0x80b3f8c in ap_process_request ()
#17 0x80ab82e in child_main ()
#18 0x80aba6c in make_child ()
#19 0x80abde6 in perform_idle_server_maintenance ()
#20 0x80ac315 in standalone_main ()
#21 0x80ac8d3 in main ()
So far I've applied a mason related patch thanks to Doug, and a path on perl itself that was listed on this list. Still getting faults however, and they are frequent enough for me to worry about in a production scenario. We are using the HTML::Mason package if it helps any.
RE: Core dumping
Title: Core dumping I was able to build mod_perl/apache with debugging. The line at which apache drops is: Program received signal SIGSEGV, Segmentation fault.0x81714f7 in Perl_dounwind (cxix=3) at pp_ctl.c:12541254 POPSUB(cx,sv); So it looks like in Perl_dounwind a seg fault is received on line 1254 in pp_ctl.c (course you could probably tell that =) To bad I can't take a peek into the POPSUB macro itself... It's like 20 lines long and there is no way to get gdb to display the macro. Least no way I know. Shane How the hell do people actually try to fix this? The learning curve on trying to understand the internals of perl is enormous! -Original Message-From: Shane Adams Sent: Friday, September 08, 2000 10:38 PMTo: ModperlSubject: Core dumping Hello - I am experiencing a situation where apache core dumps. We are using HTML-Mason. The relevant revision numbers are: Apache_1.3.12 mod_perl-1.24 perl-5.6.0 HTML-Mason .87 redhat 6.1 (no patches) Our apache server is built in 2 flavors, one that uses Mason, another that doesn but uses mod_perl. httpd-mason -l reveals Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c whereas httpd-soap (straight mod_perl, but it is used to answer SOAP requests via SOAP.pm) http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c Running a barebonse component (nothing tricky, just loads a normal html component) under Mason causes apache to core dump after a few dozen requests. A stack trace reveals: eading symbols from /lib/libnss_nis.so.2...done. #0 0x8143b34 in Perl_pp_entersub () (gdb) where #0 0x8143b34 in Perl_pp_entersub () #1 0x813aeda in Perl_runops_debug () #2 0x80e4b2f in perl_call_sv () #3 0x80e4780 in perl_call_sv () #4 0x8075aac in perl_call_handler () #5 0x8074fd8 in perl_run_stacked_handlers () #6 0x80726a8 in perl_handler () #7 0x80a0913 in ap_invoke_handler () #8 0x80b3f29 in ap_some_auth_required () #9 0x80b3f8c in ap_process_request () #10 0x80ab82e in ap_child_terminate () #11 0x80ab9bc in ap_child_terminate () #12 0x80abb19 in ap_child_terminate () #13 0x80ac146 in ap_child_terminate () #14 0x80ac8d3 in main () #15 0x400d31eb in __libc_start_main (main=0x80ac58c main, argc=2, argv=0xb944, init=0x806286c _init, fini=0x81a998c _fini, rtld_fini=0x4000a610 _dl_fini, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90 (gdb) I've tried building perl and apache and mod_perl with debugging turned on. I can't seem to get more out of the core dump than this. My point in listing the 2 flavors of our apache configurations is that httpd-soap does *not* core whereas the mason server does. Normally I'd just try upgrading but I've hit the latest releases of each piece it seems. I don't know if this will shed any details as to what the problem is. Any help is appreciated. Shane
RE: Core dumping
Title: Core dumping Sorry I forgot to include the stack trace with debugging turned on: #0 0x81714f7 in Perl_dounwind (cxix=3) at pp_ctl.c:1254#1 0x8171bd1 in Perl_die_where ( message=0x848eb68 "Can't upgrade that kind of scalar at /home/shane/sparty/runtime/perl/lib/site_perl/5.6.0/HTML/Mason/ApacheHandler.pm line 547.\n", msglen=127) at pp_ctl.c:1371#2 0x81289f3 in Perl_vcroak (pat=0x81cc200 "Can't upgrade that kind of scalar", args=0xb284) at util.c:1623#3 0x8128ad1 in Perl_croak (pat=0x81cc200 "Can't upgrade that kind of scalar") at util.c:1670#4 0x814317a in Perl_sv_upgrade (sv=0x81eff50, mt=13) at sv.c:916#5 0x80e5ef0 in Perl_gv_init (gv=0x81eff50, stash=0x81efed8, name=0x81accb6 "_", len=1, multi=0) at gv.c:93#6 0x80e76c3 in Perl_gv_fetchpv (nambeg=0x81accb6 "_", add=1, sv_type=15) at gv.c:681#7 0x80894de in XS_Apache_finfo (cv=0x8207410) at Apache.xs:1844#8 0x8140fc5 in Perl_pp_entersub () at pp_hot.c:2533#9 0x813891a in Perl_runops_debug () at run.c:56#10 0x80e256f in S_call_body (myop=0xb6f8, is_eval=0) at perl.c:1761#11 0x80e21c0 in perl_call_sv (sv=0x85d1ee8, flags=4) at perl.c:1677#12 0x807474c in perl_call_handler (sv=0x85d1ee8, r=0x86d227c, args=0x0) at mod_perl.c:1643#13 0x8073e7a in perl_run_stacked_handlers (hook=0x81aa2b9 "PerlHandler", r=0x86d227c, handlers=0x85d7d80) at mod_perl.c:1362#14 0x8072011 in perl_handler (r=0x86d227c) at mod_perl.c:905#15 0x809e353 in ap_invoke_handler ()#16 0x80b1969 in process_request_internal ()#17 0x80b19cc in ap_process_request ()#18 0x80a926e in child_main ()#19 0x80a93fc in make_child ()#20 0x80a9559 in startup_children ()#21 0x80a9b86 in standalone_main ()#22 0x80aa313 in main ()#23 0x400d31eb in __libc_start_main (main=0x80a9fcc main, argc=2, argv=0xb944, init=0x8062820 _init, fini=0x81a73cc _fini, rtld_fini=0x4000a610 _dl_fini, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90(gdb) q -Original Message-From: Shane Adams Sent: Saturday, September 09, 2000 5:34 PMTo: ModperlSubject: RE: Core dumping I was able to build mod_perl/apache with debugging. The line at which apache drops is: Program received signal SIGSEGV, Segmentation fault.0x81714f7 in Perl_dounwind (cxix=3) at pp_ctl.c:12541254 POPSUB(cx,sv); So it looks like in Perl_dounwind a seg fault is received on line 1254 in pp_ctl.c (course you could probably tell that =) To bad I can't take a peek into the POPSUB macro itself... It's like 20 lines long and there is no way to get gdb to display the macro. Least no way I know. Shane How the hell do people actually try to fix this? The learning curve on trying to understand the internals of perl is enormous! -Original Message-From: Shane Adams Sent: Friday, September 08, 2000 10:38 PMTo: ModperlSubject: Core dumping Hello - I am experiencing a situation where apache core dumps. We are using HTML-Mason. The relevant revision numbers are: Apache_1.3.12 mod_perl-1.24 perl-5.6.0 HTML-Mason .87 redhat 6.1 (no patches) Our apache server is built in 2 flavors, one that uses Mason, another that doesn but uses mod_perl. httpd-mason -l reveals Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c whereas httpd-soap (straight mod_perl, but it is used to answer SOAP requests via SOAP.pm) http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c Running a barebonse component (nothing tricky, just loads a normal html component) under Mason causes apache to core dump after a few dozen requests. A stack trace reveals: eading symbols from /lib/libnss_nis.so.2...done. #0 0x8143b34 in Perl_pp_entersub () (gdb) where #0 0x8143b34 in Perl_pp_entersub () #1 0x813aeda in Perl_runops_debug () #2 0x80e4b2f in perl_call_sv () #3 0x80e4780 in perl_call_sv () #4 0x8075aac in perl_call_handler () #5 0x8074fd8 in perl_run_stacked_handlers () #6 0x80726a8 in perl_handler () #7 0x80a0913 in ap_invoke_handler () #8 0x80b3f29 in ap_some_auth_required () #9 0x80b3f8c in ap_process_request () #10 0x80ab82e in ap_child_terminate () #11 0x80ab9bc in ap_child_terminate () #12 0x80abb19 in ap_child_terminate () #13 0x80ac146 in ap_child_terminate () #14 0x80ac8d3 in main () #15 0x400d31eb in __libc_start_main (main=0x80ac58c main, argc=2, argv=0xb944, init=0x806286c _init, fini=0x81a998c _fini, rtld_fini=0x4000a610 _dl_fini, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90 (gdb) I've tried building perl and apache and mod_perl with debugging turned on. I can't seem to get more out of the core dump th
RE: open(FH,'|qmail-inject') fails
Title: RE: open(FH,'|qmail-inject') fails Another approach to is to write the email directly into the queue. I've used this approach and it's very fast. After you write your email to the qmail queue, you write a value of 1 to a named pipe that qmail reads off of. This causes a qmail process (there are like 20 different ones and I forget which is which - check the docs) to wake up and drain the queue. If you want anymore speed then that, you have to either install ram disks or seriously write your own mta. We installed ram disks =) Shane -Original Message- From: Andrew Dunstan [mailto:[EMAIL PROTECTED]] Sent: Friday, September 08, 2000 9:52 PM To: Modperl Subject: Re: open(FH,'|qmail-inject') fails Regarding cost of forking etc.: Your mileage will undoubtedly vary, according to OS and MTA. Last time I did work on this was about a year ago on Solaris 2.6, with sendmail and postfix. In both cases using Net::SMTP was far faster. IIRC, with postfix there is no forking cost at all, as its daemon does not fork on connect (it uses a select() loop instead). Talking on the SMTP port is actually Wietse Venema's recommended method for fastest injection into the postfix queue. It also has the advantage over other methods that it is totally MTA independent. andrew
Core dumping
Title: Core dumping Hello - I am experiencing a situation where apache core dumps. We are using HTML-Mason. The relevant revision numbers are: Apache_1.3.12 mod_perl-1.24 perl-5.6.0 HTML-Mason .87 redhat 6.1 (no patches) Our apache server is built in 2 flavors, one that uses Mason, another that doesn but uses mod_perl. httpd-mason -l reveals Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c whereas httpd-soap (straight mod_perl, but it is used to answer SOAP requests via SOAP.pm) http_core.c mod_log_config.c mod_mime.c mod_rewrite.c mod_access.c mod_setenvif.c mod_perl.c Running a barebonse component (nothing tricky, just loads a normal html component) under Mason causes apache to core dump after a few dozen requests. A stack trace reveals: eading symbols from /lib/libnss_nis.so.2...done. #0 0x8143b34 in Perl_pp_entersub () (gdb) where #0 0x8143b34 in Perl_pp_entersub () #1 0x813aeda in Perl_runops_debug () #2 0x80e4b2f in perl_call_sv () #3 0x80e4780 in perl_call_sv () #4 0x8075aac in perl_call_handler () #5 0x8074fd8 in perl_run_stacked_handlers () #6 0x80726a8 in perl_handler () #7 0x80a0913 in ap_invoke_handler () #8 0x80b3f29 in ap_some_auth_required () #9 0x80b3f8c in ap_process_request () #10 0x80ab82e in ap_child_terminate () #11 0x80ab9bc in ap_child_terminate () #12 0x80abb19 in ap_child_terminate () #13 0x80ac146 in ap_child_terminate () #14 0x80ac8d3 in main () #15 0x400d31eb in __libc_start_main (main=0x80ac58c main, argc=2, argv=0xb944, init=0x806286c _init, fini=0x81a998c _fini, rtld_fini=0x4000a610 _dl_fini, stack_end=0xb93c) at ../sysdeps/generic/libc-start.c:90 (gdb) I've tried building perl and apache and mod_perl with debugging turned on. I can't seem to get more out of the core dump than this. My point in listing the 2 flavors of our apache configurations is that httpd-soap does *not* core whereas the mason server does. Normally I'd just try upgrading but I've hit the latest releases of each piece it seems. I don't know if this will shed any details as to what the problem is. Any help is appreciated. Shane
