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