Re: DSO/Tru64 (was Re: References for modperl usage in financialinstitutions?)
Marcin Kasperski wrote: PS If only someone had some idea how to solve the DSO/Tru64 problem... We really need to find people on these platforms (True64, AIX, HP-UX, etc.) who can help to reproduce and resolve this kind of probs. If you know of those willing to help please ask them to subscribe on this list. I am using Tru64 - and if you have any suggestions of what to try, I will do it... I wish it was that simple :( You really have to know the peculiarities of the system to know why the behavior is different. -- __ 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
Re: dso
At 11:41 29.05.2002, Arnold van Kampen wrote: Hi Some messages ago, someone still mentioned that modperl had been - compiled in -, when describing his configuration, that he was having trouble with. Does this mean it is still better to compile it in instead of using mod_perl as a dso? If you're having problems, it's often known to be the quick answer to try. If you're not having trouble, keep using DSO happily! -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: dso
I have to agree with this statement. We have a server farm with 15 apache servers running mod_perl as a DSO (not counting the several development and QC servers) with no problems. IMHO mod_perl as a DSO probably had problems in the beginning, but I couldn't confirm that without some research and I'm too lazy to do it, and as a result people now recommend compiling mod_perl into httpd. So I would say if DSO works for you use it, if not don't use it. -Original Message- From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 6:54 AM To: Arnold van Kampen Cc: [EMAIL PROTECTED] Subject: Re: dso At 11:41 29.05.2002, Arnold van Kampen wrote: Hi Some messages ago, someone still mentioned that modperl had been - compiled in -, when describing his configuration, that he was having trouble with. Does this mean it is still better to compile it in instead of using mod_perl as a dso? If you're having problems, it's often known to be the quick answer to try. If you're not having trouble, keep using DSO happily! -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: DSO on Solaris - child dies with seg fault
On Sun, 14 Apr 2002, Sreeji K Das wrote: Hi Stas, Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. wondering if this is the XSLoader vs DynaLoader mentioned earlier today. there is a workaround builtin to 1.27-tobe: http://perl.apache.org/~dougm/mod_perl-1.26_01-dev.tar.gz you could also try 'use DynaLoader ();' before loading any other modules.
Re: DSO on Solaris - child dies with seg fault
Thanx Doug for the reply. Unfortunately I still get segfaults :-( No difference. Once I have the time, I'll get the stacktrace see for any clues. Right now I have kept DSO in the backburner, as I have got PerlFreshRestart fully up and runnig (with a no. of patches to mod_perl) Sreeji --- Doug MacEachern [EMAIL PROTECTED] wrote: you might actually be hitting a problem i just found on solaris with 2.0 and perl 5.6.1. a problem that is fixed in 5.8.0-tobe, where certain DynaLoader and XSLoader combo prevents modperl from closing all of the dlhandles. try adding this to your startup.pl before use-ing any other modules: use DynaLoader (); __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: DSO on Solaris - child dies with seg fault
you might actually be hitting a problem i just found on solaris with 2.0 and perl 5.6.1. a problem that is fixed in 5.8.0-tobe, where certain DynaLoader and XSLoader combo prevents modperl from closing all of the dlhandles. try adding this to your startup.pl before use-ing any other modules: use DynaLoader ();
Re: DSO on Solaris - child dies with seg fault
Hi Stas, Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. I've attached some additional info., generated by trussing the child, as it was being restarted: $truss -ef -o ~/truss.out -r0,1,2 -w0,1,2 -p 26978 Note: I have also tried setting ENV PERL_DESTRUCT_LEVEL to -1 and also to 2, but got the same results. Thanx for any help. Sreeji --- Stas Bekman [EMAIL PROTECTED] wrote: Sreeji K Das wrote: Hi, I was trying to run mod_perl as DSO on Solaris. I see the following line in the logs: [notice] child pid 24323 exit signal Segmentation Fault (11) This happens whenever I send a USR1 to the server for restart. Also I see the same message whenever the child is about to exit (ie. after handling the prescribed no.of requests). Is DSO stable enough to be used under Solaris ? I have searched through the archives see differing opinions. Additional Info: $perl -V:uselargefiles -V:bincompat5005 uselargefiles='define'; bincompat5005='undef'; perl: 5.6.1, Apache: 1.3.23, mod_perl: 1.26 Using SunOS 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-80 I've compiled mod_perl with PERL_USELARGEFILES=0 and USE_DSO. The above problem is repeatable with PerlFreshRestart On and Off. Any clues ? Thanx Sreeji (BTW, make test has gone through w/o any errors) See if it helps you:http://perl.apache.org/guide/install.html#When_DSO_can_be_Used __ 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 __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com 26978: accept(16, 0xEFFFE95C, 0xEFFFE97C) (sleeping...) 26978: signotifywait() = 16 26978: Received signal #16, SIGUSR1, in accept() [caught] 26978:siginfo: SIGUSR1 pid=26322 uid=300528 26978: lwp_sigredirect(1, SIGUSR1) = 0 26978: accept(16, 0xEFFFE95C, 0xEFFFE97C) Err#4 EINTR 26978: sigprocmask(SIG_SETMASK, 0xEF276450, 0x) = 0 26978: setcontext(0xEFFFE5A8) 26978: sigaction(SIGHUP, 0xEFFFE6D0, 0xEFFFE7D4) = 0 26978: sigaction(SIGUSR1, 0xEFFFE6D0, 0xEFFFE7D4) = 0 26978: write(2, `, 1) = 1 26978: write(2, 0xEF547EE4, 20)= 20 26978: P e r l C h i l d E x i t H a n d l e r 26978: write(2, 0xEF51E8E3, 33)= 33 26978: ' p u s h _ h a n d l e r s ( ) s t a c k i s e m p t y 26978:\n 26978: write(2, 0xEF547EE4, 20)= 20 26978: P e r l C h i l d E x i t H a n d l e r 26978: write(2, 0xEF51E05A, 19)= 19 26978: h a n d l e r s r e t u r n e d 26978: write(2, - 1\n, 3) = 3 26978: write(2, r u n n i n g , 8) = 8 26978: write(2, 3, 1) = 1 26978: write(2, 0xEF51F95E, 16)= 16 26978: E N D b l o c k s f o r 26978: write(2, 0xEF547DCC, 13)= 13 26978: p e r l _ s h u t d o w n 26978: write(2, \n, 1) = 1 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: write(2, 0x00E90A80, 48)= 48 26978: T S T F o r m s s e r v e r p r o c e s s 2 6 9 7 8 s 26978: h u t t i n g d o w n . . .\n 26978: write(2, 0x013725C0, 40)= 40 26978: R e s e t t i n g c o n n e c t i o n t o d a t a b a s e 26978: @ s i g t e s t 26978: write(2, \n, 1) = 1 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: getcontext(0xEFFFE320) 26978: getcontext(0xEFFFE158) 26978: write(2, 0xEF51D770, 48)= 48 26978: d e s t r u c t i n g a n d f r e e i n g P e r l i n t 26978: e r p r e t e r ( l e v e l = 26978: write(2, 0, 1) = 1 26978: write(2, ) . . ., 4) = 4 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFDFE8) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFE120) 26978: getcontext(0xEFFFDFE8) 26978: write(2, o k\n, 3) = 3 26978: Incurred fault #6, FLTBOUNDS %pc = 0xEF1A3CFC 26978:siginfo: SIGSEGV SEGV_MAPERR addr=0xEF1A3CFC
Re: DSO on Solaris - child dies with seg fault
Sreeji K Das wrote: Thanx for the reply. However, I had already read the doc. and done everything mentioned there. I had recompiled perl with -Ubincompat5005 as mentioned. Good then. I just wasn't sure. Hopefully someone with Solaris access/knowledge will be able to help you out, but see below. I've attached some additional info., generated by trussing the child, as it was being restarted: $truss -ef -o ~/truss.out -r0,1,2 -w0,1,2 -p 26978 What's needed is the core dump backtrace, see http://perl.apache.org/preview/modperl-docs/dst_html/docs/1.0/guide/help.html#How_to_Report_Problems __ 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
Re: DSO on Solaris - child dies with seg fault
Sreeji K Das wrote: Hi, I was trying to run mod_perl as DSO on Solaris. I see the following line in the logs: [notice] child pid 24323 exit signal Segmentation Fault (11) This happens whenever I send a USR1 to the server for restart. Also I see the same message whenever the child is about to exit (ie. after handling the prescribed no.of requests). Is DSO stable enough to be used under Solaris ? I have searched through the archives see differing opinions. Additional Info: $perl -V:uselargefiles -V:bincompat5005 uselargefiles='define'; bincompat5005='undef'; perl: 5.6.1, Apache: 1.3.23, mod_perl: 1.26 Using SunOS 5.6 Generic_105181-16 sun4u sparc SUNW,Ultra-80 I've compiled mod_perl with PERL_USELARGEFILES=0 and USE_DSO. The above problem is repeatable with PerlFreshRestart On and Off. Any clues ? Thanx Sreeji (BTW, make test has gone through w/o any errors) See if it helps you:http://perl.apache.org/guide/install.html#When_DSO_can_be_Used __ 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
Re: DSO Issues
JC == John Chia [EMAIL PROTECTED] writes: JC On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. JC Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP JC it. Perl 5.005_03 has the leaks no matter what. And with DSO, PerlFreshStart is a no-op, since you get a fresh perl no matter what. One of these days I'll take the time to migrate to 5.6.1 and then regression test my whole app, which ain't easy to do on a web-based interactive system where you have hundreds of options to test in combination.
Re: DSO Issues
On Wed, Nov 28, 2001 at 10:34:00AM -0500, Vivek Khera wrote: SR == Stephen Reppucci [EMAIL PROTECTED] writes: SR If we're collecting a list of things that don't work in a DSO SR build, add perl subs (via !--#perl sub=My::handler--). SR At least, they didn't work as of January of this year. Doubtful that they ever will, either, since that introduces a dependency on mod_perl into mod_include. Both have to be linked together (ie, statically) for that to work. Not really, you can do it with just module DT_NEEDED depends. It does mean you have to build them together and load in the right order. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer
Re: DSO Issues
SR == Stephen Reppucci [EMAIL PROTECTED] writes: SR If we're collecting a list of things that don't work in a DSO SR build, add perl subs (via !--#perl sub=My::handler--). SR At least, they didn't work as of January of this year. Doubtful that they ever will, either, since that introduces a dependency on mod_perl into mod_include. Both have to be linked together (ie, statically) for that to work. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
RE: DSO Issues
Ditto. DSO makes my life so much better in terms of portability and administratability that having my services down for a few seconds during a log rotation is certainly worth it. Regards, Christian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vivek Khera Sent: Tuesday, November 27, 2001 2:17 PM To: [EMAIL PROTECTED] Subject: Re: DSO Issues DW == David Wheeler [EMAIL PROTECTED] writes: DW While it seems to be well-known anecdotally that one should never use a DW DSO install of mod_perl (particularly among Mason developers), is there DW yet any place where all the known issues surrounding the use of DSO The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. The amount of leakage depends on my particular application. Having a DSO makes it much easier for me to administer (having multiple instances of apache running on the same machine, some with and some without mod_perl), so I live with it and do a full stop/restart instead of SIGHUP to rotate logs. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: DSO Issues
On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP it. -- john chia [EMAIL PROTECTED] starnix inc. tollfree: 1-87-pro-linuxthornhill, ontario, canada http://www.starnix.com professional linux services products
Re: DSO Issues
DW == David Wheeler [EMAIL PROTECTED] writes: DW While it seems to be well-known anecdotally that one should never use a DW DSO install of mod_perl (particularly among Mason developers), is there DW yet any place where all the known issues surrounding the use of DSO The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. The amount of leakage depends on my particular application. Having a DSO makes it much easier for me to administer (having multiple instances of apache running on the same machine, some with and some without mod_perl), so I live with it and do a full stop/restart instead of SIGHUP to rotate logs. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: DSO Issues
If we're collecting a list of things that don't work in a DSO build, add perl subs (via !--#perl sub=My::handler--). At least, they didn't work as of January of this year. On Tue, 27 Nov 2001, John Chia wrote: On 27 November 2001 15:17 (-0500), Vivek Khera wrote: The *only* issue I encounter is a massive memory leak upon SIGHUP or SIGUSR to apache. Hm. I only get memory leaks if PerlFreshRestart is enabled and I SIGHUP it. -- Steve Reppucci [EMAIL PROTECTED] | Logical Choice Software http://logsoft.com/ | =-=-=-=-=-=-=-=-=-=- My God! What have I done? -=-=-=-=-=-=-=-=-=-=
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: DSO suexecx mod_perl
Oliver [EMAIL PROTECTED] wrote: Hello, OK, but I can I govern this: in the apache configuration of ./configure I tried to add some DSO (Dynamical Shared Objects) like this ./configure --enable-module=most --enable-shared=max --enable-suexec --suexe c-caller=apache --suexec-docroot=/home --suexec-userdir=/home --suexec-uidmi n=500 --suexec-gidmin=100 --suexec-safepath=/usr/local/bin:/usr/bin:/bin --a ctivate-module=src/modules/perl/libperl.a --enable-shared=perl - after running make and then make install I tried to restart httpd it failed. My Question: What can I do to have most of the DSO object modules for apache and mod_perl running as suExec. You can't. suExec is used to run other programs. DSOs are not programs but shared libraries. -- James Smith [EMAIL PROTECTED], 979-862-3725 Texas AM CIS Operating Systems Group, Unix
Re: DSO mod_perl HUP memory leak
DM == Doug MacEachern [EMAIL PROTECTED] writes: DM 1.21_01 had two dso fixes, one to close all .so's opened by DynaLoader and DM one to call perl_shutdown(), both of which were large leaks. with DM 1.25_01-dev and Perl 5.6.1 i see a 4k growth on the first kill -USR1 and DM no change after that. what is your perl -V and mod_perl version? On a FreeBSD 4.3-STABLE box, I get about 9M per HUP. This server is running every page through Template Toolkit. Apache is built from the FreeBSD ports collection with mod_ssl, and mod_perl is built via APXS from the 1.25_01-dev on Feb 8, 2001. I guess it's time to pull out my debuggerizer hat. ;-) [yertle]% ps xu USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND khera 48860 0.0 0.4 1452 1016 p1 Ss 11:22AM 0:00.17 -tcsh (tcsh) khera 20589 0.0 8.2 23404 21308 ?? Ss2:39PM 0:01.12 httpd -f /home/khe khera 20733 0.0 8.2 23416 21316 ?? I 2:39PM 0:00.01 httpd -f /home/khe khera 21190 0.0 8.2 23416 21316 ?? I 2:39PM 0:00.01 httpd -f /home/khe khera 22022 0.0 8.2 23416 21316 ?? I 2:39PM 0:00.01 httpd -f /home/khe khera 18230 0.0 0.1 392 232 p1 R+3:15PM 0:00.00 ps xu [yertle]% kill -USR1 `cat logs/httpd.pid ` [yertle]% ps xu USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND khera 20589 5.2 11.7 32524 30392 ?? Ss2:39PM 0:02.21 httpd -f /home/khe khera 48860 0.0 0.4 1452 1016 p1 Ss 11:22AM 0:00.18 -tcsh (tcsh) khera 19790 0.0 11.7 32536 30400 ?? S 3:15PM 0:00.01 httpd -f /home/khe khera 19955 0.0 11.7 32536 30400 ?? S 3:15PM 0:00.01 httpd -f /home/khe khera 20280 0.0 11.7 32536 30400 ?? S 3:15PM 0:00.01 httpd -f /home/khe khera 21037 0.0 0.1 392 232 p1 R+3:15PM 0:00.00 ps xu [yertle]% kill -USR1 `cat logs/httpd.pid ` [yertle]% ps xu USERPID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND khera 20589 7.6 15.2 41644 39480 ?? Ss2:39PM 0:03.31 httpd -f /home/khe khera 48860 0.0 0.4 1452 1016 p1 Ss 11:22AM 0:00.18 -tcsh (tcsh) khera 22075 0.0 15.2 41656 39488 ?? S 3:15PM 0:00.01 httpd -f /home/khe khera 22621 0.0 15.2 41656 39488 ?? S 3:15PM 0:00.01 httpd -f /home/khe khera 22851 0.0 15.2 41656 39488 ?? S 3:15PM 0:00.01 httpd -f /home/khe khera 24543 0.0 0.1 392 232 p1 R+3:15PM 0:00.00 ps xu -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/
Re: DSO mod_perl HUP memory leak
On Thu, 14 Jun 2001, Paul G. Weiss wrote: I know that this is an ongoing problem, but I seem to remember that someone somewhere had a patch that reduced the size of the memory leak on restarts to a manageable size. Has this patch been applied to the CVS version? If not, can some kind soul tell me where to find it? I've looked around the net in vain. 1.21_01 had two dso fixes, one to close all .so's opened by DynaLoader and one to call perl_shutdown(), both of which were large leaks. with 1.25_01-dev and Perl 5.6.1 i see a 4k growth on the first kill -USR1 and no change after that. what is your perl -V and mod_perl version?
RE: DSO mod_perl and preloading
All these tips and benchmarks on optimising mod_perl by preloading used modules/DBD-drivers etc. are great. However, I have seen warnings about preloading modules if mod_perl is loaded as a DSO. (e.g for HTML::Embperl). Does this still apply? My setup is redhat6.2/perl-5.6/mod_perl-1.23. This was true before mod_perl 1.22. So there should be no problem with your setup Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925151 WWW:http://www.ecos.de Fax: +49 6133 925152 -
Re: DSO build questions
Hi there, On Thu, 3 Feb 2000, Wang, Pin-Chieh wrote: Ged, Thanks much for your help, Please tell me if I asked too many questions, If you don't I'll keep on ask you questions. After I said that, here is another question. You aren't asking too many questions, but please forgive me if I can't get to them to answer them as quickly as you would like. I am building an Apache with Mod_perl under DSO. I thought I did right, I am using the following parameters for Makefile.PL under mod_perl-1.21 directory APACHE_SRC=../apache_1.3.11/src USE_APACI=1 DO_HTTPD=1 \ ADD_MODULE=rewrite,so,status,info \ APACHE_PREFIX=/usr/local/apache_dso \ PERL_MARK_WHERE=1 EVERYTHING=1 I then Make Su Make install I then cd ../apache_1.3.11 ./configure -enable-module=so -enable-module=info -prefix=/usr/local/apache_dso make su make install When you write USE_APACI=1, after you have done 'make install' in the mod_perl directory you do not have to build in the Apache directory, mod_perl does it for you. Watch the output of the scripts and the compiler as they run, and you will see what is happening if you are quick. Use control-s to stop the output if you are not quick, then use control-q to restart it. You need to read some more. Have a look especially at `scenario.pod' in the Guide. It builds mod_perl in several different ways, which you can probably manipulate to suit your own needs. Unfortunately I have been ill with 'flu' so my rewrite of this section of the Guide is only just finished today. I can't send it to you because Stas needs to look at it now to make sure I haven't completely screwed it up. All the technical information you need is in the existing version (which I am assuming you now have!), it's just slightly better English after my rewrite. I hope. When we've attended to the English, there will be some more reorganizing. Sorry for the inconvenience... To get mod_perl's Makefile.PL to add your modules you can add lines like this to your Makefile.PL argument list: % /usr/local/bin/perl Makefile.PL \ APACHE_SRC=../apache_1.3.11/src USE_APACI=1 DO_HTTPD=1 USE_DSO=1 \ APACHE_PREFIX=/usr/local/apache_dso \ PERL_MARK_WHERE=1 EVERYTHING=1 \ APACI_ARGS= --enable-module=so, \ --enable-module=info The line in your command to perl Makefile.PL which reads: APACHE_SRC=../apache_1.3.11/src USE_APACI=1 DO_HTTPD=1 \ tells Makefile.PL to make Apache as well as mod_perl but it does not tell mod_perl to make a DSO binary, that's why I put USE_DSO=1 in my version above. You won't save as much memory as you might think using DSO, and I'd avoid it until there are fewer questions about it. The line in your command which reads: ./configure -enable-module=so -enable-module=info should I think read: ./configure --enable-module=so --enable-module=info which tells Apache that it is to be linked with the mod_info module and it is to be built ready to load modules dynamically (at run-time, instead of linking them at compile-time) but it does not mean build mod_perl itself as a Dynamically Shared Object. Remember to do 'make clean' in both the mod_perl and the Apache directories before you start again. Read the Guide! Hope this helps. 73, Ged.
Re: DSO SEGV fix (was: A fix in sight: Apache::ASP: crash when placed in startup.pl)
"Frank D. Cringle" wrote: Daniel Jacobowitz [EMAIL PROTECTED] writes: This worked! Can I get opinions on the attached patch? I am not competent to check whether the patch has any hidden problems, but I hope Doug will be able to evaluate it and include it in the next release. Your description of the sequence leading up to the crash fits well with what I observed when trying to trace the problem with gcc. It looks like Alan Burlison is on to a different dynamic linking problem that also needs to be fixed. No, it's the exactly the same problem, and the fix works for me too. Alan Burlison
Re: DSO slows things down?
On Fri, Jan 14, 2000 at 06:31:50PM +0200, Stas Bekman wrote: Just read the mod_ssl vs. apache_ssl thread at /.org: http://slashdot.org/apache/99/12/22/1711203.shtml jimjag claims that DSO is slower than static builds at the runtime: QUOTE Q: Why has using DSOs anything to do with run-time performance? I always thought using DSOs just slows down the startup. A: Not at all. The code produced with DSOs, as well as the way modules are implemented, is less optimal than the non-DSO alternative. If you need best performance, avoid DSO. This is covered in the Apache performance docs. /QUOTE What do DSO benefactors have to say :) This depends on the machine architecture in question - DSO's require that the machine code produced is relocatable. This is so that a shared object can be loaded at varying virtual addresses in different processes. On some register starved machine architectures like x86 this causes more pressure to load and store registers in memory as one has to reserve an additional register for getting at your global data. Other architecures like SGI with MIPS processors or AIX with POWER/PowerPC processors do not even make the distinction, all code is always relocatable in their runtime model. I am not 100% familar with the GCC x86 code generator, but isn't the penalty mostly for accesses to global data and absolute function calls outside the module? I would suspect that in a well programmed module the globals should be very rare, and time critical functions are either local or called via function pointers, where the penalty does not apply. One additional point is that all the system libraries are normally used as shared libraries which also use relocatable code. There are few people that do really statically link in the system libraries into their programs (if that is possible at all on the machine in question). -- Jens-Uwe Mager HELIOS Software GmbH Steinriede 3 30827 Garbsen Germany Phone: +49 5131 709320 FAX:+49 5131 709325 Internet: [EMAIL PROTECTED]
