Re: EXPAT?
Forrest Aldrich wrote:
I did a test compile of mod_perl as a DSO, and ran into a problem with
another module I use (mod_dav). It requires EXPAT to be defined in the
ap_auto_config.h file. However, I found this in the mod_perl Makefile.PL:
# Do not disable the rule EXPAT for Stronghold, since this
# rule is not implementated yet and breaks the configure process.
if(is_ssl() !~ /stronghold/i) {
$cmd .= " --disable-rule=EXPAT";
}
So, I'm not certain about how to rectify this with mod_dav.
That comment is not very clear. Should it be disabled only for SSL servers,
but not stronghold? That change was made at:
revision 1.157
date: 2000/04/21 05:56:19; author: dougm; state: Exp; lines: +2 -1
--disable-rule=EXPAT is passed to Apache's configure to avoid
XML::Parser conflicts
PR:
Obtained from:
Submitted by:
Reviewed by:
I suggest that you search the mailing list archives for --disable-rule=EXPAT
around this date, find the discussion leading to this change and this will
clarify thinigs.
If this change was made only for ssl servers, this might work:
ndex: Makefile.PL
===
RCS file: /home/cvs/modperl/Makefile.PL,v
retrieving revision 1.213
diff -u -r1.213 Makefile.PL
--- Makefile.PL 5 Jun 2003 07:38:46 - 1.213
+++ Makefile.PL 11 Jun 2003 01:22:24 -
@@ -1033,7 +1033,8 @@
# Do not disable the rule EXPAT for Stronghold, since this
# rule is not implementated yet and breaks the configure process.
-if(is_ssl() !~ /stronghold/i) {
+my $is_ssl = is_ssl();
+if($is_ssl && $is_ssl !~ /stronghold/i) {
$cmd .= " --disable-rule=EXPAT";
}
But I'm not sure if that's the case.
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
EXPAT?
I did a test compile of mod_perl as a DSO, and ran into a problem with
another module I use (mod_dav). It requires EXPAT to be defined in the
ap_auto_config.h file. However, I found this in the mod_perl Makefile.PL:
# Do not disable the rule EXPAT for Stronghold, since this
# rule is not implementated yet and breaks the configure process.
if(is_ssl() !~ /stronghold/i) {
$cmd .= " --disable-rule=EXPAT";
}
So, I'm not certain about how to rectify this with mod_dav.
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Bill O'Hanlon wrote: > (Apologies if you see this twice -- I sent it from an unsubscribed > email address first.) > > > Hi folks, > > I just ran down a problem that was somewhat hard to find, and I didn't see any > mention of anything like it in the archives anywhere. I thought it might be > helpful to mention the details in case someone else is ever in the same > situation. > > I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working > installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd > get it running under Apache::Registry in mod_perl. To my surprise, the Apache > daemons would dump core whenever I tried to log in with manage.cgi. > > It turns out that the current FreeBSD port of Apache uses it's own internal > version of "expat", which is an XML library of some kind. This internal > version doesn't connect up well with the version that XML::Parser is expecting > to find. Turning this off in the Apache build fixed the problem, and the > OpenSRS code runs very nicely under mod_perl now. At this point, I don't > understand what functionality I've lost by not having the expat code built into > the Apache binary. > > The configure option to leave out expat is "--disable-rule=EXPAT". In the > FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the > Makefile. > > I don't know if this applies to any other platform. My guess is that it could, > since I think the default for Apache is to use the internal version of expat. > > Hope this helps someone! Thanks for this contribution Bill, but it has been documented for a long time in the guide: http://perl.apache.org/release/docs/1.0/guide/troubleshooting.html#Segfaults_when_using_XML__Parser __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
(Apologies if you see this twice -- I sent it from an unsubscribed email address first.) Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of "expat", which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is "--disable-rule=EXPAT". In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
On Sun, Jun 09, 2002 at 12:43:38PM -0400, Perrin Harkins wrote: > > I just ran down a problem that was somewhat hard to find, and I didn't > see any > > mention of anything like it in the archives anywhere. > > The expat issue has been discussed quite a bit on this list, and is > documented here: > http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_X > ML_Parser > > Sorry to hear you had trouble finding it. That section of the guide is > the first place you should look when you're having segfault problems. > > - Perrin > Eeek! Thanks the for the pointer to the warnings and errors guide. I guess when I first tried to find out what was going on by STFW, I thought it was something OpenSRS specific. Later, when I'd found something that seemed to work, I didn't go back and search for expat or XML_Parse. It's reassuring to see that the fix that I'd guessed at is the right one to use, though. Thanks again, -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Yeh, it does apply on other BSD platforms--but I don't think it's specific to BSD(s). I use the same args on Net and Open on Apaches I've built on those platforms. I came across this issue with AxKit. There's tons of references on the web as well: http://www.google.com/search?hl=en&ie=UTF8&oe=UTF8&q=disable-rule%3Dexpat -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 7:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of "expat", which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is "--disable-rule=EXPAT". In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
Re: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
> I just ran down a problem that was somewhat hard to find, and I didn't see any > mention of anything like it in the archives anywhere. The expat issue has been discussed quite a bit on this list, and is documented here: http://perl.apache.org/guide/troubleshooting.html#Segfaults_when_using_X ML_Parser Sorry to hear you had trouble finding it. That section of the guide is the first place you should look when you're having segfault problems. - Perrin
RE: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
I came across the same problem while trying to install a bunch of XML modules via the CPAN module. It was pretty frustrating when the module installations kept dying when it got to expat, even after a installed the expat port time and time again. I think I solved the problem similarly to the way you did, either that or I just decided I didn't need the XML modules installed. Mike -Original Message- From: Bill O'Hanlon [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 09, 2002 10:31 AM To: [EMAIL PROTECTED] Subject: FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of "expat", which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is "--disable-rule=EXPAT". In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
FreeBSD Apache/mod_perl/OpenSRS/expat problem + solution
Hi folks, I just ran down a problem that was somewhat hard to find, and I didn't see any mention of anything like it in the archives anywhere. I thought it might be helpful to mention the details in case someone else is ever in the same situation. I'm running FreeBSD 4.5, with perl 5.6.1 and Apache 1.3.24. I had a working installation of the regular OpenSRS perl code via cgi-bin, but I thought I'd get it running under Apache::Registry in mod_perl. To my surprise, the Apache daemons would dump core whenever I tried to log in with manage.cgi. It turns out that the current FreeBSD port of Apache uses it's own internal version of "expat", which is an XML library of some kind. This internal version doesn't connect up well with the version that XML::Parser is expecting to find. Turning this off in the Apache build fixed the problem, and the OpenSRS code runs very nicely under mod_perl now. At this point, I don't understand what functionality I've lost by not having the expat code built into the Apache binary. The configure option to leave out expat is "--disable-rule=EXPAT". In the FreeBSD port, that's easily added to the CONFIGURE_ARGS variable in the Makefile. I don't know if this applies to any other platform. My guess is that it could, since I think the default for Apache is to use the internal version of expat. Hope this helps someone! -Bill -- Bill O'Hanlon [EMAIL PROTECTED] Professional Network Services, Inc. 612-379-3958 http://www.pro-ns.net
use Apache2/use Apache::expat
Can one of the mod_perl 2 developers explain what each of these does? It seems that the first loads mod_perl 2.0 mode and the latter loads mod_perl 1 compatibility mode, or something to that extent, but what about other behind-the-scenes things which are happening that might be useful to know about? Issac
RE: :Parser & Expat cause segfaults
Reg this problem , Paul Kulchenko ( Soap::Lite wizard ) helped me with a solution given below, back last Fall . I used it with immediate success , and I hope it is applicable: ** SOLUTION ** If using SOAP::Lite (or XML::Parser::Expat) in combination with mod_perl causes random segmentation faults in httpd processes try to configure Apache with: RULE_EXPAT=no ** Sri Lakshmanan Market Data Services Koch Petroleum Group Tel (316) 828-3820 Fax (316) 828-4151 [EMAIL PROTECTED] > -Original Message- > From: Matt Sergeant [SMTP:[EMAIL PROTECTED]] > Sent: Thursday,May 03,2001 3:27 AM > To: Oskari 'Okko' Ojala > Cc: [EMAIL PROTECTED] > Subject: RE: :Parser & Expat cause segfaults > > On Thu, 3 May 2001, Oskari 'Okko' Ojala wrote: > > > On Thu, 3 May 2001, Stephen Anderson wrote: > > > > > > Got a problem: About 250 of 1000 requests cause a segfault > > > > (11) when using XML::Parser::parse() under mod_perl. > > > > > There's (apparently) a known symbol conflict between XML::Parser 2.30 > and > > > Apache (which I only know because it happened to someone here just the > other > > > day). Drop down to 2.29 and it should work fine. > > > > No success, I tried dropping the version down to 2.25, one by one. > > > > I also tried completely removing the expat from the apache source tree. > > The script still core dumps, but I found out that the same code as a > > mod_perl .cgi does not - it happens only when done under Mason. > > Make sure you comletely remove the old apache installation before your > recompile. This has caught me once. > > -- > > > /||** Founder and CTO ** ** http://axkit.com/ ** >//||** AxKit.com Ltd ** ** XML Application Serving ** > // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** > // \\| // ** mod_perl news and resources: http://take23.org ** > \\// > //\\ > // \\ >
RE: :Parser & Expat cause segfaults
On Thu, 3 May 2001, Oskari 'Okko' Ojala wrote: > I'll let you know if the problem gets solved. Upgrading to Perl 5.6.1 seems to do the job. Thanks to all who helped! Oskari Ojala
RE: :Parser & Expat cause segfaults
On Thu, 3 May 2001, Oskari 'Okko' Ojala wrote: > On Thu, 3 May 2001, Stephen Anderson wrote: > > > > Got a problem: About 250 of 1000 requests cause a segfault > > > (11) when using XML::Parser::parse() under mod_perl. > > > There's (apparently) a known symbol conflict between XML::Parser 2.30 and > > Apache (which I only know because it happened to someone here just the other > > day). Drop down to 2.29 and it should work fine. > > No success, I tried dropping the version down to 2.25, one by one. > > I also tried completely removing the expat from the apache source tree. > The script still core dumps, but I found out that the same code as a > mod_perl .cgi does not - it happens only when done under Mason. Make sure you comletely remove the old apache installation before your recompile. This has caught me once. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
RE: :Parser & Expat cause segfaults
On Thu, 3 May 2001, Stephen Anderson wrote: > > Got a problem: About 250 of 1000 requests cause a segfault > > (11) when using XML::Parser::parse() under mod_perl. > There's (apparently) a known symbol conflict between XML::Parser 2.30 and > Apache (which I only know because it happened to someone here just the other > day). Drop down to 2.29 and it should work fine. No success, I tried dropping the version down to 2.25, one by one. I also tried completely removing the expat from the apache source tree. The script still core dumps, but I found out that the same code as a mod_perl .cgi does not - it happens only when done under Mason. Someone reported to me that he has the same behaviour with Solaris 2.8 x86. He gets core dumps with XML::Parser::parse() under Mason, too, but not without it. I'll mail to Mason's developer about this. I'll let you know if the problem gets solved. Oskari Ojala
RE: :Parser & Expat cause segfaults
> -Original Message- > From: Oskari 'Okko' Ojala [mailto:[EMAIL PROTECTED]] > Got a problem: About 250 of 1000 requests cause a segfault > (11) when using > XML::Parser::parse() under mod_perl. In FAQs it is stated that this is > because of the bundled Expat in Apache. > > I've tried disabling Apache's Expat with --disable-rule=EXPAT, but it > doesn't help. > > Have you found any workarounds or patches, or is the reason to my > segfaults somewhere else? > > Platform: > > Red Hat 7.0 > Apache 1.3.19 > mod_perl 1.25 > perl 5.6.0 > expat 1.95.1 > HTML::Mason 1.02 > XML::Parser 2.30 There's (apparently) a known symbol conflict between XML::Parser 2.30 and Apache (which I only know because it happened to someone here just the other day). Drop down to 2.29 and it should work fine. Stephen.
Re: XML::Parser & Expat cause segfaults
On Wed, 2 May 2001, Matt Sergeant wrote: > Try changing PREP_HTTPD=1 to APACHE_PREFIX=/usr/local/apache, and add > APACI_ARGS='...' where ... are your --enable-module bits. Tried that too, but it doesn't seem to help. Still segfaults. :(
Re: XML::Parser & Expat cause segfaults
On Wed, 2 May 2001, Oskari 'Okko' Ojala wrote: > I compiled mod_perl with > > perl Makefile.PL APACHE_SRC=../apache_1.3.19/src DO_HTTPD=1 USE_APACI=1 > PREP_HTTPD=1 EVERYTHING=1 Try changing PREP_HTTPD=1 to APACHE_PREFIX=/usr/local/apache, and add APACI_ARGS='...' where ... are your --enable-module bits. Then mod_perl will compile and install Apache for you. That's the way I've found works best. -- /||** Founder and CTO ** ** http://axkit.com/ ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** mod_perl news and resources: http://take23.org ** \\// //\\ // \\
XML::Parser & Expat cause segfaults
Got a problem: About 250 of 1000 requests cause a segfault (11) when using XML::Parser::parse() under mod_perl. In FAQs it is stated that this is because of the bundled Expat in Apache. I've tried disabling Apache's Expat with --disable-rule=EXPAT, but it doesn't help. Have you found any workarounds or patches, or is the reason to my segfaults somewhere else? Platform: Red Hat 7.0 Apache 1.3.19 mod_perl 1.25 perl 5.6.0 expat 1.95.1 HTML::Mason 1.02 XML::Parser 2.30 I compiled mod_perl with perl Makefile.PL APACHE_SRC=../apache_1.3.19/src DO_HTTPD=1 USE_APACI=1 PREP_HTTPD=1 EVERYTHING=1 and Apache with ./configure --disable-rule=EXPAT --activate-module=src/modules/perl/libperl.a --enable-module=so --enable-module=unique_id --enable-module=rewrite --enable-module=info --enable-module=usertrack --enable-module=expires --prefix=/usr/local/apache All tips appreciated! Oskari Ojala Frantic Media
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
On Tue, 11 Apr 2000, Ardo van Rangelrooij wrote: Hi! > Steve Dunham (thanks!!!)provided a patch which should take care of > this problem. I've made a package available as > > http://master.debian.org/~ardo/libxml-parser-perl_2.27-3_i386.deb > > Please try it out and let me know what's up. If no problems occur > I'll upload it to master officially. After running it several hours, using 3-4 different scripts each refreshing every second, the only problem I encountered was an unstable netscape (when using a refresh of _zero_ seconds :-) So, I consider the bg fixed and recommend the upload... > I'll also forward this problem to the man upstream, Clark Cooper. > > Thanks, > Ardo Thanks everybody, Remco Schaar /--\ | Remco Schaar | | e-mail: [EMAIL PROTECTED] | \--/ South Park meets Linux: - "Oh my God, they killed init!" - "You bastards!"
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
On Tue, 11 Apr 2000, Ardo van Rangelrooij wrote: > Hi! Hi, > Steve Dunham (thanks!!!)provided a patch which should take care of > this problem. I've made a package available as > > http://master.debian.org/~ardo/libxml-parser-perl_2.27-3_i386.deb > > Please try it out and let me know what's up. If no problems occur > I'll upload it to master officially. OK, I will run it later today on my machine with the test-script, and then with the project I'm working on, which is more complex and crashed much fatser. > I'll also forward this problem to the man upstream, Clark Cooper. > > Thanks, > Ardo I'll let you know... Thanx, Remco Schaar /--\ | Remco Schaar | | e-mail: [EMAIL PROTECTED] | \--/ South Park meets Linux: - "Oh my God, they killed init!" - "You bastards!"
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
Hi! Steve Dunham (thanks!!!)provided a patch which should take care of this problem. I've made a package available as http://master.debian.org/~ardo/libxml-parser-perl_2.27-3_i386.deb Please try it out and let me know what's up. If no problems occur I'll upload it to master officially. I'll also forward this problem to the man upstream, Clark Cooper. Thanks, Ardo Daniel Jacobowitz <[EMAIL PROTECTED]> writes: > reassign 61231 libxml-parser-perl > thanks > > And sure enough, the man is right. This is not mod_perl's problem. > When I disable RULE_EXPAT, apache ceases crashing. > > > On Tue, Apr 04, 2000 at 02:49:36PM -0700, Doug MacEachern wrote: > > On Tue, 4 Apr 2000, Daniel Jacobowitz wrote: > > > > > [mod_perl people - any comment? Please keep the Cc: list to the Debian > > > bug tracking system.] > > > > > > When using the XML::Parser::Expat under mod_perl, this causes segmentation > > > > faults (quite random?) in the child-processes of httpd. > > > > The error message in the error.log of apache is: > > > > "[notice] child pid 28177 exit signal Segmentation fault (11)" > > > > yeah, try configuring Apache with: > > RULE_EXPAT=no > > > > otherwise, the symbols in XML::Parser clash with apache's. i've suggested > > several times that the XML::Parser author should consider making those > > symbols static or use a different prefix, but no idea if that's happened > > or not. -- Ardo van Rangelrooij home email: [EMAIL PROTECTED], [EMAIL PROTECTED] home page: http://home.flevonet.nl/~avrangel PGP fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
reassign 61231 libxml-parser-perl thanks And sure enough, the man is right. This is not mod_perl's problem. When I disable RULE_EXPAT, apache ceases crashing. On Tue, Apr 04, 2000 at 02:49:36PM -0700, Doug MacEachern wrote: > On Tue, 4 Apr 2000, Daniel Jacobowitz wrote: > > > [mod_perl people - any comment? Please keep the Cc: list to the Debian > > bug tracking system.] > > > > When using the XML::Parser::Expat under mod_perl, this causes segmentation > > > faults (quite random?) in the child-processes of httpd. > > > The error message in the error.log of apache is: > > > "[notice] child pid 28177 exit signal Segmentation fault (11)" > > yeah, try configuring Apache with: > RULE_EXPAT=no > > otherwise, the symbols in XML::Parser clash with apache's. i've suggested > several times that the XML::Parser author should consider making those > symbols static or use a different prefix, but no idea if that's happened > or not. > > Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Re: Bug#61231: mod_perl segfaults child-processes in combinationwith XML::Parser::Expat
On Tue, 4 Apr 2000, Daniel Jacobowitz wrote: > [mod_perl people - any comment? Please keep the Cc: list to the Debian > bug tracking system.] > > When using the XML::Parser::Expat under mod_perl, this causes segmentation > > faults (quite random?) in the child-processes of httpd. > > The error message in the error.log of apache is: > > "[notice] child pid 28177 exit signal Segmentation fault (11)" yeah, try configuring Apache with: RULE_EXPAT=no otherwise, the symbols in XML::Parser clash with apache's. i've suggested several times that the XML::Parser author should consider making those symbols static or use a different prefix, but no idea if that's happened or not.
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
Something, presumably XML::Parser::Expat, is corrupting malloc's and
perl's data structures randomly. Running under MALLOC_CHECK_=2 has a
high probability of showing this. It also occasionally cores in
Perl_sv_upgrade - the SV is hopelessly mangled:
(gdb) p *sv
$17 = {sv_any = 0x83e58955, sv_refcnt = 2203260140, sv_flags = 821518397}
(gdb) where
#0 0x402a5b95 in Perl_sv_upgrade (sv=0x4029d868, mt=136780768) at sv.c:823
#1 0x402a5810 in Perl_sv_upgrade (sv=0x4029d868, mt=136780768) at sv.c:732
#2 0x4029d93d in Perl_pp_or () at pp_hot.c:235
#3 0x4025c266 in Perl_moreswitches (s=0x81a14a4 "PZ\n\b\001") at perl.c:1641
#4 0x4024061e in perl_create_request_config ()
from /usr/lib/apache/1.3/mod_perl.so
#5 0x4023fcf1 in perl_config_getch () from /usr/lib/apache/1.3/mod_perl.so
#6 0x4023de1f in perl_fixup () from /usr/lib/apache/1.3/mod_perl.so
#7 0x8053e64 in ap_invoke_handler (r=0x8289a7c) at http_config.c:508
#8 0x80625ec in process_request_internal (r=0x8289a7c) at http_request.c:1214
#9 0x8062648 in ap_process_request (r=0x8289a7c) at http_request.c:1230
#10 0x805c439 in child_main (child_num_arg=0) at http_main.c:4122
#11 0x805c5cc in make_child (s=0x8099c2c, slot=0, now=954878307)
at http_main.c:4235
#12 0x805c6e9 in startup_children (number_to_start=5) at http_main.c:4317
#13 0x805cb9b in standalone_main (argc=2, argv=0xbdb4) at http_main.c:4605
#14 0x805d24d in main (argc=2, argv=0xbdb4) at http_main.c:4933
However, I don't think that's a reliable stack trace. The stack seems damaged.
On Tue, Mar 28, 2000 at 12:50:45PM +0200, [EMAIL PROTECTED] wrote:
> Package: libapache-mod-perl
> Version: 1.21.2309-1
> Severity: Important
>
> When using the XML::Parser::Expat under mod_perl, this causes segmentation
> faults (quite random?) in the child-processes of httpd.
> The error message in the error.log of apache is:
> "[notice] child pid 28177 exit signal Segmentation fault (11)"
>
> This can be repreduced with the following script,
> run under mod_perl, just wait a while, and monitor the error.log (takes a
> while, multiple request will speed up):
>
> --- cut here -
> #!/usr/bin/perl -w
>
> use XML::Parser::Expat;
> use strict;
>
> main();
>
> # bug creater under mod_perl, just results in some simple html
>
> sub main()
> {
> my $problemXP = new XML::Parser::Expat;
> $problemXP->setHandlers(Start => \&Start, End => \&End, Char => \&Text);
> print "Content-type: text/html\n\n";
> $problemXP->parse("\n\nsome
>text\n\n");
> $problemXP->release();
> }
>
> sub Start($$) {
> my $caller = shift;
> my $tag = shift;
> print "<" . $tag;
> print " " . $_[0] . "='" . $_[1] . "'" if $#_ ge 1; # add attributes
> print " " . $_[2] . "='" . $_[3] . "'" if $#_ ge 3; # add attributes
> print ">\n" unless $tag =~ /\s/;
> }
>
> sub End($$) {
> my $caller = shift;
> my $etag = shift;
> print "\n" unless $etag =~ /\s/;
> }
>
> sub Text($$) {
> my $caller = shift;
> my $text = shift;
> print $text . "\n" unless $text =~ /\s/;
> }
> --- cut here -
>
>
> I guess this is caused by a memory-leak or a problem related to loading
> Perl *.so (see bug #48069)
>
> Related packages (frozen/potato, 27 march 2000):
> - libapache-mod-perl 1.21.2309-1
> - apache-common 1.3.9-12
> - apache-ssl 1.3.9.10 + 1.37-1
> - libxml-parser-perl 2.27-2
> - perl-5.005 5.005.03-6
> - perl-5.005-base 5.005.03-6
> - libmime-base64-perl 2.11-2
> - libdevel-symdump-perl 2.00-4
> - data-dumper 2.09-1
> - liburi-perl 1.04-2
> - libc6 2.1.3-7
> - libdb2 2.4.14-9
> - libgdbmg1 1.7.3-26.2
>
> kernel 2.2.14 (i586 and i686)
> libc-2.1.3.so
>
> * ( didn't encouter with slink, but i am not sure, used CPAN
> instead of libxml-parser-perl.deb...)
>
>
>
> used configuration:
>
> httpd.conf:
> LoadModule config_log_module /usr/lib/apache/1.3/mod_log_config_ssl.so
> LoadModule mime_module /usr/lib/apache/1.3/mod_mime_ssl.so
> LoadModule negotiation_module /usr/lib/apache/1.3/mod_negotiation.so
> LoadModule status_module /usr/lib/apache/1.3/mod_status.so
> LoadModule includes_module /usr/lib/apache/1.3/mod_include.so
> LoadModule autoindex_module /usr/lib/apache/1.3/mod_autoindex.so
> LoadModule dir_module /usr/lib/apache/1.3/mod_dir.so
> LoadModule cgi_mod
Re: Bug#61231: mod_perl segfaults child-processes in combination with XML::Parser::Expat
[mod_perl people - any comment? Please keep the Cc: list to the Debian bug tracking system.] On Tue, Mar 28, 2000 at 12:50:45PM +0200, [EMAIL PROTECTED] wrote: > Package: libapache-mod-perl > Version: 1.21.2309-1 > Severity: Important > > When using the XML::Parser::Expat under mod_perl, this causes segmentation > faults (quite random?) in the child-processes of httpd. > The error message in the error.log of apache is: > "[notice] child pid 28177 exit signal Segmentation fault (11)" > > This can be repreduced with the following script, > run under mod_perl, just wait a while, and monitor the error.log (takes a > while, multiple request will speed up): It's very random, but I can reproduce this. However, I can also reproduce it with apache-perl (statically linked). It seems extremely unlikely to me that this is the DSO code's fault, therefore. Here's a backtrace: (gdb) bt #0 0x400f8b59 in free () from /lib/libc.so.6 #1 0x400f89ed in free () from /lib/libc.so.6 #2 0x4026eb7a in Perl_safefree () from /usr/lib/apache/1.3/mod_perl.so #3 0x4027fcb9 in Perl_sv_setsv () from /usr/lib/apache/1.3/mod_perl.so #4 0x402782dc in Perl_pp_sassign () from /usr/lib/apache/1.3/mod_perl.so #5 0x402a8440 in Perl_runops_standard () from /usr/lib/apache/1.3/mod_perl.so #6 0x4024c0a9 in perl_call_sv () from /usr/lib/apache/1.3/mod_perl.so #7 0x4023201e in perl_call_handler () from /usr/lib/apache/1.3/mod_perl.so #8 0x402318cc in perl_run_stacked_handlers () from /usr/lib/apache/1.3/mod_perl.so #9 0x402302cf in perl_handler () from /usr/lib/apache/1.3/mod_perl.so #10 0x8053e64 in ap_invoke_handler (r=0x826e23c) at http_config.c:508 #11 0x80625ec in process_request_internal (r=0x826e23c) at http_request.c:1214 #12 0x8062648 in ap_process_request (r=0x826e23c) at http_request.c:1230 #13 0x805c439 in child_main (child_num_arg=0) at http_main.c:4122 #14 0x805c5cc in make_child (s=0x8099c24, slot=0, now=954874778) at http_main.c:4235 #15 0x805c6e9 in startup_children (number_to_start=5) at http_main.c:4317 #16 0x805cb9b in standalone_main (argc=2, argv=0xbdc4) at http_main.c:4605 #17 0x805d24d in main (argc=2, argv=0xbdc4) at http_main.c:4933 Very interesting. I'll look at this further. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
