Re: Children dying
On Tue, 14 Aug 2001, Aleksandr Vladimirskiy wrote: Hi all, I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? sounds like the largefiles problem, which mod_perl's Makefile.PL should have warned you about: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) first option is the easiest way to fix.
Re: Children dying
Stas Bekman wrote: No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? So what is the point of having DSO at all then? The question was 'How do I build on Solaris with DSO?', the answer was 'Build perl to use the system malloc', I don't see what the problem with that is. -- Alan Burlison -- $ head -1 /dev/bollocks repurpose collaborative focus groups, going forwards
DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alan Burlison wrote: Stas Bekman wrote: No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? So what is the point of having DSO at all then? The question was 'How do I build on Solaris with DSO?', the answer was 'Build perl to use the system malloc', I don't see what the problem with that is. You are right, it was my mistake. I read the solution to the problem was not to build it as DSO. (mail overload problem :( ) I'll add this note regarding Solaris. I think the best thing would be if somebody who has an extensive DSO build experience across many platforms could summarize the problems, so we can put it into the guide. Personally I always build my production servers as static, so I only rely on comments from others. Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc * My server leaks memory on restart with DSO = don't use DSO _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Children dying
Thanks very much to all of you. I've upgraded my perl distro to 5.6.1 and recompiled everything and the children stopped dying. Alex
RE: Children dying
On Thu, 16 Aug 2001, Stas Bekman wrote: The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? because solaris is a special case. as is any platform where perl defaults to using its own malloc. the problem is perl's malloc pollutes the main httpd program with 'free' and 'malloc' symbols. when apache restarts (happens at startup too), any references in the main program to 'free' and 'malloc' now point to la-la land, things go boom. with 5.6.0+ this pollution can be prevented with -Ubincompat5005. or -Uusemymalloc for any version of perl, but there's a chance that might hurt performance depending on platform, so -Ubincompat5005 is likely a better choice. the modperl Makefile.PL has warned about this problem for ages, but i think the warning is often missed/ignored.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Stas Bekman wrote: Currently what I've is: * How do I build on Solaris with DSO? = Build perl and mod_perl using the system malloc that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; which can be turned off with: % Configure -Ubincompat5005 ... * My server leaks memory on restart with DSO = don't use DSO shouldn't happen with 5.6.1, at least it doesn't with my testing.
Re: DSO problems summary? (was Re: Children dying)
On Thu, Aug 16, 2001 at 09:35:43AM -0700, Doug MacEachern wrote: that should be any platform where perl defaults to using its own malloc, that is, if: % perl -V:usemymalloc reports: usemymalloc='y' which is fine if: % perl -V:bincompat5005 reports: bincompat5005='undef'; but the default for 5.6.x is: bincompat5005='define'; Well... With # perl -v This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; # perl -V:bincompat5005 bincompat5005='define'; on # uname -a SunOS netra 5.8 Generic_108528-09 sun4u sparc SUNW,UltraAX-i2 am I safe? Or what should I rebuild with what flags? Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. Alex.
Re: DSO problems summary? (was Re: Children dying)
On Thu, 16 Aug 2001, Alex Povolotsky wrote: This is perl, v5.6.1 built for sun4-solaris # perl -V:usemymalloc usemymalloc='n'; that's fine. Seems like I'm suffering from dying children problem... My main apache dies sometimes, bringing neraly everything (well, except server-status) down. how did you build modperl? if USE_APXS=1 you may have missed this other warning: Your Perl is uselargefiles enabled, but Apache is not, suggestions: *) Rebuild mod_perl with Makefile.PL PERL_USELARGEFILES=0 *) Rebuild Apache with CFLAGS=-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 *) Rebuild Perl with Configure -Uuselargefiles *) Let mod_perl build Apache (USE_DSO=1 instead of USE_APXS=1) the first option is the easiest cure.
RE: Children dying
No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-) exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? Because the admonition to -Dusemymalloc is not the same as, nor easily deduce-able from, advice to compile static. The guy who had the problem that started this thread did everything right, i.e. use the same compiler, start from fresh sources, compile static, no Expat, yet he still had segfaults. Maybe the Guide ISN'T the best place. Maybe the best place is mod_perl's INSTALL document. But somehow I'd be willing to bet that this advice holds true for earlier versions than, oh, the NEXT release of mod_perl... which is where/when such a change to INSTALL would be for those of us who aren't yet brave enough to use the CVS version daily. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
RE: Children dying
-Original Message- From: Rob Bloodgood [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 16, 2001 11:20 AM To: Stas Bekman Cc: mod_perl Subject: RE: Children dying sigh... I didn't see the other thread that spawned from my orignal post... rendering this reply redundant. Apologies.
Re: Children dying
Hi Andrew, On Tue, 14 Aug 2001, Andrew Ho wrote: AVI am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. [snip] AV[Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) [snip] A few other folks have given useful references on how to get stack traces, as well as some other common causes of core dumps (compiling Apache with its bundled expat is a big one). Here's another one--did you build mod_perl on Solaris as a DSO? In general, you want to compile mod_perl statically on Solaris because it will core otherwise. Oooohh I do hope Doug doesn't read this... 73, Ged.
Re: Children dying
Andrew Ho wrote: A few other folks have given useful references on how to get stack traces, as well as some other common causes of core dumps (compiling Apache with its bundled expat is a big one). Here's another one--did you build mod_perl on Solaris as a DSO? In general, you want to compile mod_perl statically on Solaris because it will core otherwise. Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. Alan Burlison
Re: Children dying
Vasily S. Petrushin wrote: Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. Fine, point us please to documentation how to do it. http://cpan.valueclick.com/authors/Doug_MacEachern/mod_perl-1.26.tar.gz Alan Burlison
Re: Children dying
Hello, AVI am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. AHIn general, you want to compile mod_perl statically on Solaris because AHit will core otherwise. ABUntrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Children dying
Andrew Ho wrote: ABUntrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Humbly, And no need for that either! :-) Regards, -- Alan Burlison -- $ head -1 /dev/bollocks drive proximal infomediaries, going forwards
RE: Children dying
AB Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. L8r, Rob #!/usr/bin/perl -w use Disclaimer qw/:standard/;
RE: Children dying
On Wed, 15 Aug 2001, Rob Bloodgood wrote: AB Untrue. We ship mod_perl in Solaris 8 as a DSO, and it works fine. I apologize. Let me qualify my original statement. In general, you want to compile mod_perl statically on Solaris 2.6 or 2.7 because in many instances, it core dumps when built as a DSO. FWIW, my particular experiences were with Perl 5.005_03 and 5.6.0, mod_perl 1.24 and 1.25, and Apache 1.3.12, 1.3.14, 1.3.17, and 1.3.19 under Solaris 2.6 (both Sparc and Intel) and 2.7 (Intel only). No need for an apology :-) The trick is to build perl using the Solaris malloc (-Dusemymalloc as a flag to Configure), then apache, mod_perl and perl all agree on who manages memory. Might I suggest that this golden piece of information find it's way into the guide? It's so rare to see a DEFINITIVE answer to one of the many (YMMV! :-)exceptions to the vanilla mod_perl build process. The definitive answer is there for at least 2 years: If in doubt compile statically, which covers Solaris as well. Why having a special case? _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://localhost/ http://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Children dying
On Tue, Aug 14, 2001 at 10:48:48AM -0400, Aleksandr Vladimirskiy wrote: Hi all, I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? What are you trying to do on the page that makes it segfault? If you are using XML::Parser in some way (with AxKit, for example) you need to make sure it and Apache are using the same expat library. Otherwise, it depends on what you are doing. --jim
Re: Children dying
Jim Smith wrote: On Tue, Aug 14, 2001 at 10:48:48AM -0400, Aleksandr Vladimirskiy wrote: Hi all, I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? What are you trying to do on the page that makes it segfault? If you are using XML::Parser in some way (with AxKit, for example) you need to make sure it and Apache are using the same expat library. Otherwise, it depends on what you are doing. --jim I also get that alot. Although, I am not using XML::Parser. I am using Template Toolkit to generate dynamic content. My Templates are plain templates. -r
Re: Children dying
On Tue, 14 Aug 2001, Aleksandr Vladimirskiy wrote: I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? There is info in the distribution and in the guide (debug section) on how to get stack traces of your code or of Perl itself. - Perrin
Re: Children dying
This happens whenever I do anything with mod_perl - serve a URL by a handler I wrote or by a cgi script under Apache::Registry. If I knew what was causing this I wouldn't be asking this list. Alex On Tue, 14 Aug 2001, Rasoul Hajikhani wrote: Jim Smith wrote: On Tue, Aug 14, 2001 at 10:48:48AM -0400, Aleksandr Vladimirskiy wrote: Hi all, I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? What are you trying to do on the page that makes it segfault? If you are using XML::Parser in some way (with AxKit, for example) you need to make sure it and Apache are using the same expat library. Otherwise, it depends on what you are doing. --jim I also get that alot. Although, I am not using XML::Parser. I am using Template Toolkit to generate dynamic content. My Templates are plain templates. -r
RE: Children dying
I have also experienced the same without any [known] xml parsers or templates. -Original Message- From: Aleksandr Vladimirskiy [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 14, 2001 1:54 PM To: Rasoul Hajikhani Cc: Jim Smith; [EMAIL PROTECTED] Subject: Re: Children dying This happens whenever I do anything with mod_perl - serve a URL by a handler I wrote or by a cgi script under Apache::Registry. If I knew what was causing this I wouldn't be asking this list. Alex On Tue, 14 Aug 2001, Rasoul Hajikhani wrote: Jim Smith wrote: On Tue, Aug 14, 2001 at 10:48:48AM -0400, Aleksandr Vladimirskiy wrote: Hi all, I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: [Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) It looks like the child serves a request and immidiately dies. Does anyone have any ideas on how to figure out why this keeps happenning? What are you trying to do on the page that makes it segfault? If you are using XML::Parser in some way (with AxKit, for example) you need to make sure it and Apache are using the same expat library. Otherwise, it depends on what you are doing. --jim I also get that alot. Although, I am not using XML::Parser. I am using Template Toolkit to generate dynamic content. My Templates are plain templates. -r
Re: Children dying
Hello, AVI am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. AVI get the following error in my logs: AV AV[Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) AV AVIt looks like the child serves a request and immidiately dies. A few other folks have given useful references on how to get stack traces, as well as some other common causes of core dumps (compiling Apache with its bundled expat is a big one). Here's another one--did you build mod_perl on Solaris as a DSO? In general, you want to compile mod_perl statically on Solaris because it will core otherwise. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Children dying
Hi Andrew, thanks for the suggestions. I compiled mod_perl statically. I haven't seen expat mentioned anywhere, can you expand on that? Thanks Alex On Tue, 14 Aug 2001, Andrew Ho wrote: Hello, AVI am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. AVI get the following error in my logs: AV AV[Tue Aug 14 10:45:10 2001] [notice] child pid 2630 exit signal Segmentation Fault (11) AV AVIt looks like the child serves a request and immidiately dies. A few other folks have given useful references on how to get stack traces, as well as some other common causes of core dumps (compiling Apache with its bundled expat is a big one). Here's another one--did you build mod_perl on Solaris as a DSO? In general, you want to compile mod_perl statically on Solaris because it will core otherwise. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: Children dying
Hi Aleksandr,
Aleksandr Vladimirskiy wrote:
Hi Andrew, thanks for the suggestions. I compiled mod_perl statically.
I haven't seen expat mentioned anywhere, can you expand on that?
You can check by doing:
strings /path/to/apache/bin/httpd | grep -i XML
If you get anything back from that, then Expat is compiled in.
HTH,
-kip
--
print join ' ', map { ucfirst($_-getFirstChild-getData)}
XML::LibXML-new()-parse_string(join '', pack c*, (60, 122, 62, 60,
97, 62, 106, 117, 115, 116, 60, 47, 97, 62, 60, 98, 62, 97, 110, 111,
116, 104, 101, 114, 60, 47, 98, 62, 60, 99, 62, 112, 101, 114, 108, 60,
47, 99, 62, 60, 100, 62, 88, 77, 76, 60, 47, 100, 62, 60, 101, 62, 104,
97, 99, 107, 101, 114, 60, 47, 101, 62, 60, 47, 122,
62))-findnodes('//*[name() != z]')-get_nodelist;
Re: Children dying
Hey, thanks I ran the command and no output, so I guess I don't have
expat?
On Tue, 14 Aug 2001, Kip Hampton wrote:
Hi Aleksandr,
Aleksandr Vladimirskiy wrote:
Hi Andrew, thanks for the suggestions. I compiled mod_perl statically.
I haven't seen expat mentioned anywhere, can you expand on that?
You can check by doing:
strings /path/to/apache/bin/httpd | grep -i XML
If you get anything back from that, then Expat is compiled in.
HTH,
-kip
--
print join ' ', map { ucfirst($_-getFirstChild-getData)}
XML::LibXML-new()-parse_string(join '', pack c*, (60, 122, 62, 60,
97, 62, 106, 117, 115, 116, 60, 47, 97, 62, 60, 98, 62, 97, 110, 111,
116, 104, 101, 114, 60, 47, 98, 62, 60, 99, 62, 112, 101, 114, 108, 60,
47, 99, 62, 60, 100, 62, 88, 77, 76, 60, 47, 100, 62, 60, 101, 62, 104,
97, 99, 107, 101, 114, 60, 47, 101, 62, 60, 47, 122,
62))-findnodes('//*[name() != z]')-get_nodelist;
Re: Children dying
Aleksandr Vladimirskiy [EMAIL PROTECTED] said something to this effect on 08/14/2001: I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: perl 5.6.0 has DynaLoader bug that minifests itself under mod_perl. Upgrade to 5.6.1, downgrade to 5.00503, or wait for 5.8.0 to fix the bug. (darren) -- Not only is there no God, but try getting a plumber on weekends. -- Woody Allen
Re: Children dying
I've got the same configuration and it's working fine. No seg faults unless I cause'em. If nothing else is giving you adequate information, you can always remove code until it works. Not very elegant but it works consistently. --Jeff On Tue, 14 Aug 2001, darren chamberlain wrote: Aleksandr Vladimirskiy [EMAIL PROTECTED] said something to this effect on 08/14/2001: I am running a perl 5.6.0, mod_perl 1.26, apache 1.3.19 on Solaris 2.6. I get the following error in my logs: perl 5.6.0 has DynaLoader bug that minifests itself under mod_perl. Upgrade to 5.6.1, downgrade to 5.00503, or wait for 5.8.0 to fix the bug. (darren) -- Jeff Beard ___ Web:www.cyberxape.com Email: jeff at cyberxape dot com Earth: Boulder, CO, USA
