I am experimenting with using mod_perl 1.2x as a DSO and have noticed that
it does not share much memory between process and also seems to utilize
much more memory.
I thought that it is possible to use mod_perl 1.2x as a DSO when perl is
compile with -Uusemymalloc and -Ubincompat5005 which
Hi there,
On Fri, 29 Aug 2003, Stathy G. Touloumis wrote:
should building a DSO in mod_perl 1.x versions just be avoided?
I think so, and so I think does Randal. This was discussed briefly
here not long ago in a couple of threads, check the archives.
73,
Ged.
--
Reporting bugs: http
should building a DSO in mod_perl 1.x versions just be avoided?
I think so, and so I think does Randal. This was discussed briefly
here not long ago in a couple of threads, check the archives.
Thanks, I will check the archives.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info
Sorry that I neglected to list all info :
Apache version 1.3.27
mod_perl version 1.26
OS version RedHat Linux 2.4.20-18.7
perl -V :
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
Platform:
osname=linux, osvers=2.4.18-3smp, archname=i386-linux
uname='linux
and selective loading (via LoadModule) didn't really save me
that much stuff... only the AddModule selected whether the module had
been activated, and therefore allocated its private memory.
Has anyone else seen this? Am I crazy for suggesting that DSO doesn't
really gain you much, and a simple selective
Hi Randal,
On 11 Jun 2003, Randal L. Schwartz wrote:
Am I crazy for suggesting that DSO doesn't really gain you much...?
'Sfunny you should say that...
Also, has anyone gotten experience with AddModule mod_perl but keeping
the front-end's mod_perl tasks to a minimum, and therefore
With regard to the RT (http://www.fsck.com/rt) program, there were notes in
the README file that said mod_perl DSO has/had massive scalability
problems when using HTML::Mason.
I inquired to the RT author, who isn't certain that issues till persists -
so I also inquired to the HTML::Mason
From: Forrest Aldrich [EMAIL PROTECTED]
With regard to the RT (http://www.fsck.com/rt) program, there were notes in
the README file that said mod_perl DSO has/had massive scalability
problems when using HTML::Mason.
This is probably old info based on the DSO build shipped through RedHat 7.2
(... revisiting old thread about my problems with compiling
apache/mod_perl as DSO on Tru64 unix)
My problem is still not solved but I get it up to the point where it
probably lies in some customary modules (which does not behave
correctly when unloaded/reloaded) and is not directly related
object
file either. I'm kinda stumped ont this. I was thinking of upgrading to
Solaris 8.
Thanks
as
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]]
Sent: Monday, January 13, 2003 4:29 PM
To: Sinclair, Alan (CORP, GEAccess)
Cc: '[EMAIL PROTECTED]'
Subject: Re: 1.3.27 DSO
(CORP, GEAccess) [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, January 15, 2003 12:40 PM
Subject: RE: 1.3.27 DSO hassles
I was attempting to configure mod_perl first before factoring in mod_ssl.
I
cannot find the library that contains the symbol __floatdisf. It's not in
libcrypt
: Paul Weiss [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 15, 2003 11:20 AM
To: Sinclair, Alan (CORP, GEAccess); [EMAIL PROTECTED]
Subject: Re: 1.3.27 DSO hassles
Hi--
I also had this problem when I built on Solaris (2.7).
Here is how I fixed it:
The symbol is in libgcc.a. Use
gcc -print
Sinclair, Alan (CORP, GEAccess) wrote:
Here's the solution to resolve the __floatdisf symbol error. Thanks to Paul
Weiss who provided the hint.
Configure and install Apache
Relink mod_negotiation.so with libgcc.a (I opted to statically link mod_perl
into the core)
cd apache_1.3.27/src/modules
ld
All,
Having been successfully using modperl for the last 2 years statically
linked with Apache, I have been trying again to make modperl work with
1.3.27 when the Apache core modules are loaded as DSOs. There has been some
traffic in the past on this subject and I checked the archives and
Sinclair, Alan (CORP, GEAccess) wrote:
All,
Having been successfully using modperl for the last 2 years statically
linked with Apache, I have been trying again to make modperl work with
1.3.27 when the Apache core modules are loaded as DSOs. There has been some
traffic in the past on this subject
/modperl works fine for me as DSO under Solaris 7,8,9.
2.6 is EOL, but I suspect it will work with latest recommended patches.
Using gcc2.95.3
Using perl5.8, but also worked under 5.6.1 and 5.00503
Build openssl
./config --prefix=/opt/openssl \
--openssldir=/opt/openssl shared
env LD_RUN_PATH=/opt
Stas Bekman [EMAIL PROTECTED] writes:
Marcin Kasperski wrote:
[...]
It seems to me, they had problem with the '-Wl,-rpath' issue which I
found to be minor and easily patched (by the way: maybe someone would
want to correct it in distribution?).
I wasn't following that thread, but if
The problem is that the
-Wl,-rpath,/tools/perl/lib/5.6.1/alpha-dec_osf/CORE
option (which, by the way, is returned by
perl -V:ccdlflags
when perl is compiled with -Duseshrplib) is not an option for 'ld' but
for 'cc'. In fact it means 'dear cc, be so kind and pass to ld
the
The results are exactly the same: link succeeded,
PL_perl_destruct_level is unresolved while running apache.
I found the workaround to avoid this effect: slightly patching apache
build procedure so that the httpd binary is linked with perl
libperl.so helped. The error disappears... now I get
Marcin Kasperski [EMAIL PROTECTED] writes:
The results are exactly the same: link succeeded,
PL_perl_destruct_level is unresolved while running apache.
I found the workaround to avoid this effect: slightly patching apache
build procedure so that the httpd binary is linked with perl
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
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
Stas Bekman [EMAIL PROTECTED] writes:
Marcin Kasperski wrote:
In short: I tried different compilation methods with two possible
outcomes:
a) apache and modperl compile succesfully but I get coredump while the
application is starting (in all cases SEGVs, in some cases core's
confused
In short: I tried different compilation methods with two possible
outcomes:
a) apache and modperl compile succesfully but I get coredump while the
application is starting (in all cases SEGVs, in some cases core's
confused the debugger, in other I managed to notice __at_fork in
Marcin Kasperski wrote:
In short: I tried different compilation methods with two possible
outcomes:
a) apache and modperl compile succesfully but I get coredump while the
application is starting (in all cases SEGVs, in some cases core's
confused the debugger, in other I managed to notice
.
PMFJI :]
Back in RH 6.2 I would hazard that the segfault was more related to Perl
being set to uselargefiles and Apache NOT being set. This only became
visible when one tried to build mod_perl as a DSO. Building as STATIC caused
Apache to be rebuilt using the now current uselargefiles setting
On Tue, 23 Jul 2002, WC -Sx- Jones wrote:
Back in RH 6.2 I would hazard that the segfault was more related to Perl
being set to uselargefiles and Apache NOT being set. This only became
visible when one tried to build mod_perl as a DSO. Building as STATIC caused
Apache to be rebuilt using
? :)
To better clarify - I said that IF you had tried to build the mod_perl as a
DSO and the uselargefiles setting is NOT the same between Perl and Apache (IE
- both are either uselargefiles or they are both undef) you WILL get a
segfault -- even today.
Building as STATIC causes the httpd
I've seen a lot of comments which seem to me to say that a static
mod_perl is the only way to go.
But Redhat ships it as a DSO.
Now, on the one hand, I wouldn't just automatically assume that Redhat
knew what they were doing.
On the other hand, I've asked a couple local mod_perl junkies I
Hi!
On Mon, Jul 22, 2002 at 10:26:32AM -0500, David Dyer-Bennet wrote:
So, specifically for the Linux environment, what are the downsides of
running mod_perl as a DSO? (Pointers to the FM so I can R it would be
fine.)
Did you take a look at this:
http://perl.apache.org/docs/1.0/guide
On 22 Jul 2002, David Dyer-Bennet wrote:
So, specifically for the Linux environment, what are the downsides of
running mod_perl as a DSO? (Pointers to the FM so I can R it would be
fine.)
Segmentation faults, pure and simple. The Apache/mod_perl that ships with
Redhat, and I assume other
Hi David,
On 22 Jul 2002, David Dyer-Bennet wrote:
But Redhat ships it as a DSO.
Debian also, but I think that is only for simplicity. It would be
'expensive' to produce static versions of apache with mod_perl,
or with mod_php or both.
On the other hand, I've asked a couple local mod_perl
On 22 Jul 2002 10:26:32 -0500, David Dyer-Bennet [EMAIL PROTECTED] said:
DD I've seen a lot of comments which seem to me to say that a static
DD mod_perl is the only way to go.
I've been using mod_perl as DSO for more than one year (or even maybe
two) without any problems on FreeBSD/Linux
Of course this is an old conversation, but we use mod_perl as a DSO here extensively
with no problems. We have servers that have uptimes of almost 1 year (306 days as of
today) and were taken down because the servers were moved to a new server room and not
because of a problem with the DSO
Thomas Klausner [EMAIL PROTECTED] writes:
Hi!
On Mon, Jul 22, 2002 at 10:26:32AM -0500, David Dyer-Bennet wrote:
So, specifically for the Linux environment, what are the downsides of
running mod_perl as a DSO? (Pointers to the FM so I can R it would be
fine.)
Did you take a look
In response to my question, Ged Haywood pointed me at a message from Chip
Turner, reproduced here in part:
When it comes to perl and mod_perl, we've been working to try to make
sure it works reliably from RPMs. RH 7.3 should work well out of the
box, as should 7.2, once all errata applied.
Wilbur, Charlton wrote:
Or am
I looking at rolling my own RPMs or installing from source RPMs? My
suspicion, confirmed by Mr Turner, is that this is tied directly to shared
libraries and toolchains, and so I suspect further that the problem will go
away if I build everything from scratch
We built our own RPM that did source level builds on our
entire system.
So you load the rpm and it in turn executes a build script
that built our entire system. Not just apache, modperl and
mason but also it rebuilt all the modules that were
needed, compiled external binaries, installed the
Hi there,
On Mon, 24 Jun 2002, Wilbur, Charlton wrote:
I have the task of making Apache, mod_perl, and HTML::Mason work together
under RedHat. I know this is a problem;
Not necessarily; look at this thread for example...
73,
Ged.
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?
Arnold
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
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
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
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
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
-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
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
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
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
upgrades for applications that maintain state - since a user might
have a session created using a new-code box, then hit an old-code box
on the next page view. it takes us many minutes to work through
restarting the entire array.
were you ever concerned about something like that?
I
I'm looking at how to best avoid downtime during a code upgrade, as we often
do spot releases of critical code fixes and we're getting to the usage level
that I don't want to interrupt service to deploy that code. At the same
time, I want to avoid running 200 stat()'s per request for all of the
Gordon Henriksen wrote:
I'm looking at how to best avoid downtime during a code upgrade, as we often
do spot releases of critical code fixes and we're getting to the usage level
that I don't want to interrupt service to deploy that code. At the same
time, I want to avoid running 200
Gordon Henriksen wrote:
I see three options open to me:
1. static mod_perl w/ PerlFreshRestart
Reloads %INC.
downside: Heresay claims historical instablity.
2. dynamic mod_perl
Tears down cleans up Perl interpreter on graceful restart.
downside: Heresay
The best way I've found to deal with this problem is to have multiple
servers behind a load-balancer and do a rolling restart. If you have
servers A and B, you take A out of the load balancer temporarilly,
upgrade it, add it back in, take B out, upgrade it, add it back in.
Using this
Geoffrey Young wrote:
we do that frequently here - 7 servers behind a BigIP. I've always
wondered, though, whether this approach is foolproof for major
upgrades for applications that maintain state - since a user might
have a session created using a new-code box, then hit an old-code box
on
. I have posted this details 2/3 weeks
back but haven't got any reply.
I had to go for option 1, since I was not sure about
DSO StatINC does stats() for every request that
comes in - not too good. (even with a touchfile, it
has to do stat() !)
Sreeji
--- Gordon Henriksen [EMAIL PROTECTED] wrote
We had been using Option 1 for a long time we had
absolutely no problems
But doesn't it totally wreck your shared memory? For me that would make
it unusable. I usually get a pretty large percentage of memory to be
shared and count on that for getting maximum capacity from each box.
-
Hi,
I'm trying to get the php module to work on Apache_1.3.22 under AIX 4.3.3.
This works OK if I load mod_perl dynamically, but if I build mod_perl in
statically, when httpd loads libphp4.so it gives a segmentation error.
I've tried recompiling but that's made no difference. Everything was
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
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
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
Hi All,
While it seems to be well-known anecdotally that one should never use a
DSO install of mod_perl (particularly among Mason developers), is there
yet any place where all the known issues surrounding the use of DSO
mod_perl are documented? I see a place in the guide where Stas mentions
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
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
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
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
I noticed you list XML::Simple. It is a favorite module of mine, but it uses
XML::Parser which uses the expat XML parser. It is seems that mod_perl has problems
with XML::Parser. This problem is supposed to be fixed in Apache 1.3.22, but I still
had problems with strange segfaults and munched
Hi.
On 24 November 2001 12:35 (+0800), Stas Bekman wrote:
Check this out:
http://perl.apache.org/guide/install.html#When_DSO_can_be_Used
Nope. Still segfaulting. Same place.
yes, the output of perl -V, the args used to build mod_perl (grab the
src.rpm, rpm -i and look at the spec file.
Hi there,
On Mon, 26 Nov 2001, John Chia wrote:
Still segfaulting. Same place.
[snip]
Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
[snip]
Compiler:
[snip]
gccversion='2.96 2731 (Red Hat Linux 7.12.96-98)',
Did you compile Perl yourself?
73,
Ged.
On 26 November 2001 23:41 (+), Ged Haywood wrote:
Did you compile Perl yourself?
Yep.
--
john chia [EMAIL PROTECTED] starnix inc.
tollfree: 1-87-pro-linuxthornhill, ontario, canada
http://www.starnix.com professional
On Fri, 9 Nov 2001, SubbaReddy M wrote:
Hello Gurus,
please help me to get update for mod_perl.
[...]
PLEASE -don't- post any HTML mails on the list.
We are humans here, not browsers.
M [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Friday, November 09, 2001 12:21 AM
Subject: Re: Proble by Build mod_perl as a DSO outside the Apache Source
Tree via APXS
On Fri, 9 Nov 2001, SubbaReddy M wrote:
Hello Gurus,
please help me to get update for mod_perl.
[...]
PLEASE -don't
When I tried from browser not any page and checked log file
[root@qclinux /root]# tail /var/log/httpd/error_log
[Fri Nov 9 07:16:44 2001] [notice] child pid 856 exit signal Segmentation
fault (11)
[Fri Nov 9 07:16:44 2001] [notice] child pid 855 exit signal Segmentation
fault (11)
SubbaReddy M wrote:
How can I get backtrace info to send you?
If you want to solve your problem at least read the replies thoroughly
and you will be all set. Here it is again. And DO NOT reply to me, but
to the list.
Since you have a segfault, we cannot help you until you send us the
, November 09, 2001 3:03 AM
Subject: Re: Proble by Build mod_perl as a DSO outside the Apache Source
Tree via APXS
Try my tips for doing this at:
www.hamptonandassociates.net/apache_tips.htm
Good luck.
- Original Message -
From: SubbaReddy M [EMAIL PROTECTED]
To: [EMAIL PROTECTED
09, 2001 2:02 AM
Subject: Re: Proble by Build mod_perl as a DSO outside the Apache Source
Tree via APXS
SubbaReddy M wrote:
How can I get backtrace info to send you?
If you want to solve your problem at least read the replies thoroughly
and you will be all set. Here it is again. And DO
/install.html#Build_mod_perl_as_a_DSO_outside_
But, unable to access the apache httpd from browser (
http://192.168.1.235/
).
i.e.,
Build mod_perl as a DSO
outside the Apache Source Tree via APXS
This will build the
DSO libperl.so outside
the Apache source tree with the new Apache 1.3 support tool
#Build_mod_perl_as_a_DSO_outside_
But, unable to access the apache httpd from browser (
http://192.168.1.235/ ).
i.e.,
Build mod_perl as a DSO outside the Apache Source Tree via APXS
This will build the DSO libperl.so outside the Apache source tree with the
new Apache 1.3 support tool apxs
Hi,
I emailed the list a few days ago with some troubles i had with
Apache::AuthenSMB. Turns out It didn't work because I did not have
mod_perl correctly installed
Now for my question, I recompiled mod_perl in apache (no DSO) and then
it worked; problem is I really want it as a DSO and tried
Hi,
some weeks ago here was the discussion about DSO-mod_perl and leaking; as
far as I understand it the solution was, that on SOME platforms (solaris)
mod_perl should be build as static.
It seems that FreeBSD is such a platform ;-)
I build Apache from the Ports-Collection with mod-ssl
what the p5-apache port did.
I added the mod_perl port
_specifically_ to make mod_perl available to FreeBSD admins dynamically.
but it's build as DSO and I guess this makes the troubles.
i prefer DSO and ports too, but i guess that DSO is the problem.
Also the standard perl of FreeBSD is 5.005
because you
maintain the ports and maybe heard about the problem.
about two months ago in the list there was a discussion about building
mod_perl as DSO and the result was, that on some platforms it leaks memory
if build as DSO.
Ciao
Alvar
. 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
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
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
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)
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
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
On 22 Jun 2001, Jay Thorne wrote:
Hmm. I've tried this on perl 5.5.x and 1.25 on a linux box, and I still
get the 4meg leak per HUP
hi, for the nth time, 5.005 leaks, 5.6.1 does not.
On 21 Jun 2001 19:34:03 -0700, Doug MacEachern wrote:
On Thu, 21 Jun 2001, Paul G. Weiss wrote:
I've done it with 5.6.1. There was a fairly detailed thread on it last
week on how it was done. In order to avoid a memory leak on restart you
need to build with a bleed modperl though. If
Has anyone had any luck getting mod_perl to work as a DSO on
Solaris? In looking through the sources, it looks like my only option
is to upgrade to bleed perl. If that really is the only thing I can
do, can someone quickly second my thoughts before I go and subject
myself
Chittenden [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 21, 2001 7:32 PM
To: [EMAIL PROTECTED]
Subject: Solaris mod_perl DSO...
Has anyone had any luck getting mod_perl to work as a DSO on
Solaris? In looking through the sources, it looks like my only option
is to upgrade to bleed perl
On Thu, 21 Jun 2001, Paul G. Weiss wrote:
I've done it with 5.6.1. There was a fairly detailed thread on it last
week on how it was done. In order to avoid a memory leak on restart you
need to build with a bleed modperl though. If you can start and stop your
server you're fine with 1.25.
(was: mod_perl DSO leaking on restart)
ah ha, right, since i always have PERL_DEBUG=1, perl_destruct_level is
always set to 2. good find! it should always be 2 for dso,
this patch
seems to fix USE_APXS too.
--- src/modules/perl/mod_perl.c 2001/06/14 04:49:08 1.137
+++ src/modules/perl
DM == Doug MacEachern [EMAIL PROTECTED] writes:
DM On 19 Jun 2001, Vivek Khera wrote:
Drat. Not here. I just sucked down the latest mod_perl CVS with this
patch, and I still lose 9M per USR1... Lemme try some tracing to see
what gives here. (FreeBSD 4.3, perl 5.005_03)
DM i mentioned
On Tue, 19 Jun 2001, Christian Gilmore wrote:
Doug,
Will this patch make it into 1.26?
yes.
If so, is there a slated release date for 1.26?
soon-ish. you can always configure: PerlSetEnv PERL_DESTRUCT_LEVEL 2
in the meantime.
On 19 Jun 2001, Vivek Khera wrote:
Drat. Not here. I just sucked down the latest mod_perl CVS with this
patch, and I still lose 9M per USR1... Lemme try some tracing to see
what gives here. (FreeBSD 4.3, perl 5.005_03)
i mentioned earlier in the thread 5.005_03 has leaks. although,
as a dso.
I've not been able to avoid a leak with a USE_APXS build.
-Paul
On Sun, 17 Jun 2001, Paul G. Weiss wrote:
Now I'm really confused. I built the whole thing statically and it still
leaks:
the static build (using the same Perl):
~/test/prefix/bin/perl Makefile.PL EVERYTHING=1
ah ha, right, since i always have PERL_DEBUG=1, perl_destruct_level is
always set to 2. good find! it should always be 2 for dso, this patch
seems to fix USE_APXS too.
--- src/modules/perl/mod_perl.c 2001/06/14 04:49:08 1.137
+++ src/modules/perl/mod_perl.c 2001/06/19 01:59:18
@@ -259,8
Doug,
I'm confused as to how you managed to *not* leak when I'm still
leaking. I've tried these tests on both a Solaris 2.7 system and
a Linux 7.1.
Here is a summary of what I do:
I build Perl
./Configure -des -Uusemymalloc -Dprefix=$(echo ~/test/prefix) -Dcc=gcc
make make test make
1 - 100 of 249 matches
Mail list logo
