cvs commit: modperl-2.0/src/modules/perl mod_perl.c
dougm 2002/07/10 19:06:11 Modified:src/modules/perl mod_perl.c Log: fix for non-ithread perls Revision ChangesPath 1.131 +1 -1 modperl-2.0/src/modules/perl/mod_perl.c Index: mod_perl.c === RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v retrieving revision 1.130 retrieving revision 1.131 diff -u -r1.130 -r1.131 --- mod_perl.c29 Jun 2002 20:38:33 - 1.130 +++ mod_perl.c11 Jul 2002 02:06:11 - 1.131 -654,8 +654,8 MP_dDCFG; GV *h_stdin, *h_stdout; int retval; -#ifdef USE_ITHREADS MP_dRCFG; +#ifdef USE_ITHREADS pTHX; modperl_interp_t *interp; #endif
Re: [win32] new perl/apache/mod_perl binary
On Mon, 8 Jul 2002 00:24:30 -0500 (CDT), Randy Kobes wrote: Hi, I've placed an updated perl-5.6.1/Apache-1.3.26/mod_perl-1.27 Win32 binary package, perl-win32-bin-0.8.exe (a self-extracting archive), in ftp://theoryx5.uwinnipeg.ca/pub/other/. This I've update configure-apache.pl to match. See: http://savage.net.au/index.html First timers: configure-apache.pl simply patches a few Perl and Apache config files when you install these packages on a drive other than C:. The entire installation process is documented, including the environment, some security issues, installing and starting Apache as a service, and some MS Windows-specific DNS issues. -- Cheers Ron Savage, [EMAIL PROTECTED] on 10/07/2002 http://savage.net.au/index.html
Re: leaks with Apache::Request?
Joe Schaefer [EMAIL PROTECTED] writes:
[...]
Somehow the assignment operator MUST be involved in the leak here.
(You only get a leak when the *same* reference (*SV) is on both sides
of the assignment).
Could someone with modperl 1.2x built using a perl 5.8 release candidate
please test this out:
Perl
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache:Request;
package Apache::test;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
$r = $apr; # XXX: what's going on here???
Dump($apr); # fscked
$r-send_header;
$r-print('apr test');
return 200;
}
1;
/Perl
Location /test
SetHandler perl-script
PerlHandler Apache::test
/Location
My error log for a request to /test is below. The above
assignment on the line marked XXX is modifying $apr, which
it shouldn't.
I don't have a 5.8-RC handy to test this on, but if somebody
else sees the same problem on 5.8, I'll file a bug report to p5p.
Thanks alot.
--
SV = RV(0x814b154) at 0x82309b8
REFCNT = 1
FLAGS = (ROK)
RV = 0x82472f4
SV = PVMG(0x8244f58) at 0x82472f4
REFCNT = 1
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 136639644
NV = 0
PV = 0
MAGIC = 0x8244f80
MG_VIRTUAL = 0
MG_TYPE = '~'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x822dec4
SV = RV(0x814b14c) at 0x822dec4
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x82472dc
SV = PVMG(0x8244f30) at 0x82472dc
REFCNT = 2
FLAGS = (OBJECT,IOK,pIOK)
IV = 136628428
NV = 0
PV = 0
STASH = 0x81420e4 Apache
MG_LEN = -1
MG_PTR = 0x824c8cc - please notify IZ
STASH = 0x8224a18 Apache::Request
SV = RV(0x814b154) at 0x82309b8
REFCNT = 1
FLAGS = (ROK)
RV = 0x82472f4
SV = PVMG(0x8244f58) at 0x82472f4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 136639644
NV = 0
PV = 0
MAGIC = 0x8244f80
MG_VIRTUAL = 0
MG_TYPE = '~'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x822dec4
SV = RV(0x814b14c) at 0x822dec4
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x82472f4
SV = PVMG(0x8244f58) at 0x82472f4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 136639644
NV = 0
PV = 0
MAGIC = 0x8244f80
MG_VIRTUAL = 0
MG_TYPE = '~'
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x822dec4
SV = RV(0x814b14c) at 0x822dec4
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x82472f4
MG_LEN = -1
MG_PTR = 0x824c8cc - please notify IZ
STASH = 0x8224a18 Apache::Request
MG_LEN = -1
MG_PTR = 0x824c8cc - please notify IZ
STASH = 0x8224a18 Apache::Request
Dead: Apache=SCALAR(0x82472dc)
--
--
Joe Schaefer
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that correct? We were debating this just yesterday in our
office.
Actually my recommendation for this year's talk on exceptions is to just
use eval{}; if ($) {}. It's a little more typing, but at the end of the
day closures created by subroutine prototypes are a really bad thing (tm).
--
!-- Matt --
:-Get a smart net/:-
Re: leaks with Apache::Request?
Joe Schaefer wrote: Somehow the assignment operator MUST be involved in the leak here. (You only get a leak when the *same* reference (*SV) is on both sides of the assignment). Could someone with modperl 1.2x built using a perl 5.8 release candidate please test this out: I got the same behavior (Apache/1.3.26 (Unix) mod_perl/1.27 perl@17440) with a modified version of your code (it doesn't work as is.) HTH.
Re: leaks with Apache::Request?
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache::Request;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
$r = $apr; # XXX: what's going on here???
Dump($apr); # fscked
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
/Perl
Location /test
SetHandler perl-script
PerlHandler Apache::test
/Location
-- server error log for request to /test --
[Wed Jul 10 07:38:32 2002] [notice] Apache/1.3.27-dev (Unix)
mod_perl/1.27_01-dev Perl/v5.8.0 configured
[...]
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 1
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626c78
SV = PVMG(0x8703110) at 0x8626c78
REFCNT = 2
FLAGS = (OBJECT,IOK,pIOK)
IV = 148451868
NV = 0
PV = 0
STASH = 0x8298510 Apache
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
Dead: Apache=SCALAR(0x8626c78)
Re: Propogating Errors / E-Toys
Matt Sergeant wrote:
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that correct? We were debating this just yesterday in our
office.
Actually my recommendation for this year's talk on exceptions is to just
use eval{}; if ($) {}. It's a little more typing, but at the end of the
day closures created by subroutine prototypes are a really bad thing (tm).
I believe he was asking if Error.pm is a good class to use for
exceptions if you don't use the try/catch keywords. I think it is. It
provides handy methods for storing attributes of the exception and
getting stack traces, and it's easy to subclass. You could also use
Dave Rolsky's Exception::Class, which is pretty similar.
- Perrin
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Kent, Mr. John wrote: Greetings, Have noticed that modperl-2.0 servers running on Solaris 2.7 start off at 23M in size. Five hours later they were at 38M. If allowed to continue they could eventually use up all available RAM and crash the system. Stopping then restarting returned them to 23M. Has anyone else encountered this and is there a recommended solution other than periodically stopping and starting? Are you using the prefork mpm or a threaded one? If this is a prefork, use Apache::SizeLimit (or Apache::GTopLimit) just like in 1.0. See: http://perl.apache.org/release/docs/1.0/guide/performance.html#Preventing_Your_Processes_from_Growing If you are talking about threaded mpms, we will need to develop new tools to restrict the size of the perl interpreters in the pool. Other than try to figure out if your code (or the server) doesn't leak. __ 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: Growing Server Size modperl-2.0 on Solaris 2.7
Stas Bekman wrote: If you are talking about threaded mpms, we will need to develop new tools to restrict the size of the perl interpreters in the pool. I was thinking about that too. Are there hooks for causing an interpreter to exit? Is it safe to simply call CORE::exit? I'd like to make SizeLimit work for the threaded MPMs if possible. - Perrin
CGI::Carp qw(fatalsToBroswer); question
use CGI::Carp qw(fatalsToBrowser); was having no effect on my modules.
Changing a line in CGI::Carp
sub ineval { $^S || _longmess() =~ /eval [\{\']/m }
---
sub ineval { _longmess() =~ /eval [\{\']/m }
,by advise from a mail I found in archives from last year, produced the
results that I was expecting from fatalsToBrowser.
The __DIE__ handler: die() then defaults to standard CORE::die if ineval
returns True, not producing the desired results of presenting error back to
client.
I suspect that this has somthing to do with mod_perl/apache wanting the
return status of the modules and wrapping them all up in a nice cosey
blanket.
Are there any solutions to this problem that don't involve changing
CGI::Carp? Perhaps I should just rip the code that I want out of CGI::Carp?
Kind Regards,
Wes Cravens
Rev. FPCED(UK)
y n=-09hu6+40563
2136+-*+96,
3.-/n*+963.h
Re: Apache-print Timed Out
I think I made a mistake posting this query over the holiday weekend, so I'm gonna speak up again. I have a couple of strange bugs showing up in Bricolage that have something to do with Apache-print timing out (with Win 95 and Mac OS 9 -- yes, these folks need to join the new millennium), and have no idea how or under what circumstances print times out. Any enlightenment on this issue would be most welcome. Thanks! David On 7/5/02 1:25 PM, David Wheeler [EMAIL PROTECTED] claimed: Hi All, I'm seeing some strange behavior with IE/Mac OS Classic where pages aren't getting completely loaded and I'm seeing this message in the log error log: [Fri Jul 5 20:22:17 2002] [info] [client 192.168.1.1] mod_perl: Apache-print timed out Config: Apache/1.3.26 (Unix) mod_perl/1.27 mod_ssl/2.8.9 OpenSSL/0.9.6b This is on RedHat Linux 7.2. I did a quick google search, but found no obvious answers to this issue. Anyone got any ideas what could be happening? Why and under what circumstances will Apache-print time out? TIA, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: leaks with Apache::Request?
[resent to modperl list; earlier copy mistakenly cc'd to p5p]
Does anyone know what's causing the Apache::Request object to
leak here? See # XXX comment below:
Perl
package Apache::test;
sub Apache::Request::DESTROY{warn DEAD: $_[0]\n}
sub Apache::DESTROY{warn Dead: $_[0]\n}
use Devel::Peek;
use Apache::Request;
sub handler {
my $r = shift;
my $apr = Apache::Request-new($r);
Dump($apr); # OK
$r = $apr; # XXX: what's going on here???
Dump($apr); # fscked
$r-send_http_header;
$r-print('apr test');
return 200;
}
1;
/Perl
Location /test
SetHandler perl-script
PerlHandler Apache::test
/Location
-- server error log for request to /test --
[Wed Jul 10 07:38:32 2002] [notice] Apache/1.3.27-dev (Unix)
mod_perl/1.27_01-dev Perl/v5.8.0 configured
[...]
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 1
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626c78
SV = PVMG(0x8703110) at 0x8626c78
REFCNT = 2
FLAGS = (OBJECT,IOK,pIOK)
IV = 148451868
NV = 0
PV = 0
STASH = 0x8298510 Apache
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
SV = RV(0x87aca6c) at 0x89902b8
REFCNT = 1
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
SV = PVMG(0x8703130) at 0x8626da4
REFCNT = 2
FLAGS = (OBJECT,RMG,IOK,pIOK)
IV = 148456972
NV = 0
PV = 0
MAGIC = 0x8d7b2c8
MG_VIRTUAL = 0
MG_TYPE = PERL_MAGIC_ext(~)
MG_FLAGS = 0x02
REFCOUNTED
MG_OBJ = 0x89975dc
SV = RV(0x87aca64) at 0x89975dc
REFCNT = 2
FLAGS = (PADBUSY,PADMY,ROK)
RV = 0x8626da4
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
MG_LEN = -1
MG_PTR = 0x8d9321c - please notify IZ
STASH = 0x835f8ec Apache::Request
Dead: Apache=SCALAR(0x8626c78)
Perl-directive unknown
just upgraded from 1.3.22/mod_perl 1.26 to 1.3.26/1.27 and while all the other stuff is working fine my daemon does not recognize the Perl-directive anymore !? test in httpsd.conf: Perl my $test=hans; /Perl # /usr/local/apache/bin/httpsdctl start Syntax error on line 105 of /usr/local/apache/conf/httpd.conf: Invalid command 'Perl', perhaps mis-spelled or defined by a module not included in the server configuration /usr/local/apache/bin/httpsdctl start: httpsd could not be started If I remove all Perl-Directives all is working fine. mod_perl-environment-variable is set and all other directives related to mod_perl are recognized, like PerlModule or PerlHandler Apache::Registry. what is going on ?! thnx, peter ps: stuff is running on linux on a 2.4.x-kernel. -- mag. peter pilsl IT-Consulting tel: +43-699-1-3574035 fax: +43-699-4-3574035 [EMAIL PROTECTED]
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Perrin Harkins wrote: Stas Bekman wrote: If you are talking about threaded mpms, we will need to develop new tools to restrict the size of the perl interpreters in the pool. I was thinking about that too. Are there hooks for causing an interpreter to exit? Is it safe to simply call CORE::exit? I'd like to make SizeLimit work for the threaded MPMs if possible. I think the idea was to have a special thread running whose only purpose is monitoring the pool of idle interpreters. Inside that thread you could have various processes happening for each process: - garbage collection (walk the optree and free big chunks of reserved/unused memory, other optimizations) - destroy interpreters that have too much non-shared memory, etc - reload modified modules? - etc.. I think this was somewhat discussed about a year ago. I'm not sure if this approach can be somehow piggy-backed into Apache::SizeLimit so users will be able to run pretty much the same setup for threaded and non-threaded mpms. I believe that we can add a Perl space hook that sets a flag that condemns an interpreter to death. When an interpreter is put back into the pool, this flag can be checked and modperl_interp_cleanup() called if that flag is set, thus killing the interpreter. I'm not sure if CORE::exit will work, most likely not, because it'll probably unsync the pool state. Need to try though. __ 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: Growing Server Size modperl-2.0 on Solaris 2.7
Stas Bekman wrote: I think the idea was to have a special thread running whose only purpose is monitoring the pool of idle interpreters. That sounds like a better solution. I believe that we can add a Perl space hook that sets a flag that condemns an interpreter to death. The other problem, which might be harder, is to figure out how big a particular interpreter is. The current implementations of Apache::SizeLimit and GTopLimit cheat by asking the OS how big the current process is. That won't work with threads. - Perrin
Re: Growing Server Size modperl-2.0 on Solaris 2.7
Perrin Harkins wrote: Stas Bekman wrote: I think the idea was to have a special thread running whose only purpose is monitoring the pool of idle interpreters. That sounds like a better solution. The drawback is that there will be two different solutions for threaded and preforked mpms, meaning harder to do transitions. I believe that we can add a Perl space hook that sets a flag that condemns an interpreter to death. The other problem, which might be harder, is to figure out how big a particular interpreter is. The current implementations of Apache::SizeLimit and GTopLimit cheat by asking the OS how big the current process is. That won't work with threads. B::Size and B::TerseSize? Since the check can be run on the idle servers that shouldn't be a problem if they are slow. On the other hand since the idea is to always re-use the recently used interpreters, I'm not sure when there will be a chance to run checks on the interpreters on the top of the pool. Need to test how fast B::Size to decide whether it's feasible to run the check during the phase when the interpreter is being returned to the pool. Also it could be that we will need various schemes for pool management and for certain servers a round-robin solution will be more memory effective if we figure out that the interpreter memory usage measuring is slow and can be done only on the idle interpreters in the pool, because in that way fat interpreters can be killed. __ 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: Perl-directive unknown
Perl my $test=hans; /Perl Don't you also need PerlModule Apache::PerlSections Maybe? xoxo, Andy -- 'Andy Lester[EMAIL PROTECTED] Programmer/author petdance.com Daddy parsley.org/quinn Jk'=~/.+/s;print((split//,$) [unpack'C*',n2]3%+\34.'%.'^%4+!o.'])
Re: Perl-directive unknown
Andy Lester wrote: Perl my $test=hans; /Perl Don't you also need PerlModule Apache::PerlSections Maybe? that shouldn't be required. my guess is that EVERYTHING=1 was not specified in the upgrade build procedure. check /perl-status?hooks and make sure that PerlSections is enabled --Geoff
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Perrin Harkins wrote:
Matt Sergeant wrote:
On Wed, 10 Jul 2002, Fran Fabrizio wrote:
Just to confirm, the end result of Matt's slide presentation was that
Error.pm was good, and you should use it, but you should not use the
try/catch syntax, or at the bare minimum only catch in your outermost
handler. Is that correct? We were debating this just yesterday in our
office.
Actually my recommendation for this year's talk on exceptions is to just
use eval{}; if ($) {}. It's a little more typing, but at the end of the
day closures created by subroutine prototypes are a really bad thing (tm).
I believe he was asking if Error.pm is a good class to use for
exceptions if you don't use the try/catch keywords. I think it is. It
provides handy methods for storing attributes of the exception and
getting stack traces, and it's easy to subclass. You could also use
Dave Rolsky's Exception::Class, which is pretty similar.
Ah, in that case I'm recommending Dave's stuff. It's more flexible and
doesn't use that irritating -param stuff. Though I have to do a little
more research to be certain some things are possible (like turning on
stack traces globally).
--
!-- Matt --
:-Get a smart net/:-
Re: Propogating Errors / E-Toys
On Wed, 10 Jul 2002, Matt Sergeant wrote: Ah, in that case I'm recommending Dave's stuff. It's more flexible and doesn't use that irritating -param stuff. Though I have to do a little more research to be certain some things are possible (like turning on stack traces globally). Actually, traces are now _always_ created. And by default they're shown when stringifying the exception object. To turn this off you do: Exception::Class::Base-Trace(0); To turn it off for one branch of the hierarchy, do: My::Exception::Subclass-Trace(0); to turn it back on for a branch below that, do: My::Exception::Subclass::SubSubClass-Trace(1); I'm also planning to add some more features to it. One is something we're using with Mason, where we create convenience subs for throwing exceptions so we can do: param_error Missing 'foo' in call to new; instead of: HTML::Mason::Exception::Params-throw( error = Missing 'foo' in call to new ); plus as an added bonus the first version gets compile time checking of the sub name, versus runtime checking of the class name in the second. -dave /*== www.urth.org we await the New Sun ==*/
[JOB] Perl / mod_perl programmer in Orem, UT
Internet Software Engineer (PERL) About Web Services is seeking an Internet Software Engineer to maintain and develop new applications for it's hosting platform. About Web Services is a division of About.com that provides hosting solutions to more than 4 million web sites including freeservers.com and bizhosting.com. Job includes a competitive salary and benefits (Health and Dental Insurance, 401K, ESPP) Qualifications: -2 years+ Experience developing in PERL / modperl on Unix -Solid Understanding of Object Oriented Programming -Experience with HTML, JavaScript, and XML -Experience with SQL (Oracle and/or MySQL) -Experience with writing efficient highly scalable code -Experience with Red Hat Linux or equivalent -Experience with CVS -Experience in working in a team environment Qualified individuals should send a resume to [EMAIL PROTECTED] or About Web Services 1253 N. Research Way Suite Q-2500 Orem, Utah 84097. If you have questions you are welcome to email me as well. Thanks, Earl
solaris9+apache2+mod_perl2
Hey All, I'm getting this error when I try to make mod_perl2, under solaris 9 make cd src/modules/perl make -f Makefile.modperl make[1]: Entering directory `/usr/share/src/modperl-2.0/src/modules/perl' gcc -I/usr/share/src/modperl-2.0/src/modules/perl -I/usr/share/src/modperl-2.0/xs -I/usr/local/apache2/include -fno-strict-aliasing -I/usr/local/include -I/usr/local/lib/perl5/5.6.1/sun4-solaris/CORE -DMOD_PERL -O -fPIC \ -c mod_perl.c mv mod_perl.o mod_perl.lo cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory In file included from modperl_perl_includes.h:42, from mod_perl.h:5, from mod_perl.c:1: /usr/local/lib/perl5/5.6.1/sun4-solaris/CORE/perl.h:23:1: warning: VOIDUSED redefined In file included from modperl_perl_includes.h:12, from mod_perl.h:5, from mod_perl.c:1: /usr/local/lib/perl5/5.6.1/sun4-solaris/CORE/config.h:3118:1: warning: this is the location of the previous definition mod_perl.c: In function `modperl_response_handler_cgi': mod_perl.c:712: `rcfg' undeclared (first use in this function) mod_perl.c:712: (Each undeclared identifier is reported only once mod_perl.c:712: for each function it appears in.) make[1]: *** [mod_perl.lo] Error 1 make[1]: Leaving directory `/usr/share/src/modperl-2.0/src/modules/perl' make: *** [modperl_lib] Error 2 bash-2.05# cd src/modules/perl make -f Makefile.modperl from mod_perl.h:5, from mod_perl.c:1: /usr/local/lib/perl5/5.6.1/sun4-solaris/CORE/config.h:3118:1: warning: this is the location of the previous definition mod_perl.c: In function `modperl_response_handler_cgi': mod_perl.c:712: `rcfg' undeclared (first use in this function) mod_perl.c:712: (Each undeclared identifier is reported only once mod_perl.c:712: for each function it appears in.) make[1]: *** [mod_perl.lo] Error 1 make[1]: Leaving directory `/usr/share/src/modperl-gcc -I/usr/share/src/modperl-2.0/src/modules/perl -I/usr/share/src/modperl-2.0/xs -I/usr/local/apache2/include -fno-strict-aliasing -I/usr/local/include -I/usr/local/lib/perl5/5.6.1/sun4-solaris/CORE -DMOD_PERL -O -fPIC \ -c mod_perl.c mv mod_perl.o mod_perl.lo cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory In file included from modperl_perl_includes.h:42, from mod_perl.h:5, from mod_perl.c:1: /usr/local/lib/perl5/5.6.1/sun4-solaris/CORE/perl.h:23:1: warning: VOIDUSED redefined In file included from modperl_perl_includes.h:12, from mod_perl.h:5,from mod_perl.c:1: /usr/local/lib/perl5/5.6.1/sun4-solaris/CORE/config.h:3118:1: warning: this is the location of the previous definition mod_perl.c: In function `modperl_response_handler_cgi': mod_perl.c:712: `rcfg' undeclared (first use in this function) mod_perl.c:712: (Each undeclared identifier is reported only once mod_perl.c:712: for each function it appears in.) make[1]: *** [mod_perl.lo] Error 1 make[1]: Leaving directory `/usr/share/src/modperl-2.0/src/modules/perl' make: *** [modperl_lib] Error 2 Perl has been compilied with gcc 2.95, and I'm using system mallocs, I've also added the bincompat5005 option. sh Configure -Ubincompat5005 -Dcc=gcc -de -Uusemymalloc It then makes, tests and installs nicely to /usr/local/bin/perl5.6.1 I've configure mod_perl with: perl Makefile.PL MP_AP_PREFIX=/usr/local/apache2 MP_INST_APACHE2=1 Any one have any ideas? Oh and I'm running Solaris 9, with Apache 2.0.40cvs, it should also be noted that the mod_perl was pulled from CVS on July 8th. Is this just a broken build? -Joshua Bernstein Systems Administrator College of Engineering and Mines University of Arizona Tucson, Arizona, USA
Re: CGI::Carp qw(fatalsToBroswer); question
Changing a line in CGI::Carp
sub ineval { $^S || _longmess() =~ /eval [\{\']/m }
---
sub ineval { _longmess() =~ /eval [\{\']/m }
Are there any solutions to this problem that don't involve changing
CGI::Carp? Perhaps I should just rip the code that I want out of CGI::Carp?
Why not just pull in CGI::Carp and then have some code like:
# Redefine whatever subs we want to directly in the CGI::Carp package
# Just don't expect LDS to support this... :=)
use CGI::Carp;
sub CGI::Carp::ineval { _longmess() =~ /eval [\{\']/m }
I've done the same for many a change to CGI.pm to fix some nits I've run across.
Mike808/
-
http://www.valuenet.net
RE: param trouble
I went through this recently set $apr = Apache::Registry-instance($r) rather than -new($r); -Original Message- From: Tim Sebastian Böckers [mailto:[EMAIL PROTECTED]] Sent: 28 June 2002 18:44 To: [EMAIL PROTECTED] Subject: param trouble dear list, i run into some trouble today for which i couldn't figure ailment myself nor find it googling. i got a cgi-bin dir running cgi/perl scripts under Apache::PerlRun. the directory is protected by a function in a .pm (Cartas::handler) called as a PerlInitHandler which reads some session data passed to it via GET from which it builds a cookie. when i try to read the data using CGI's param function in my Cartas::handler routine nothing is read. however, Apache::Request reads the data just fine so i figured i had everything resolved. however, when i try to read the param's in my cgi scripts via CGI's param functions nothing is returned. if i avoid reading the params with Apache::Request::param CGI::param will return the data correctly inside the CGI scripts. basically the whole thing is starting to bite its own tail and i would be very happy if anybody could give me any pointers as to why CGI won't read my data from the PerlInitHandler or after Apache::Request read them. and by the way its Apache 1.3.22 with mod_perl 1.26, perl 5.6.1 and CGI.pm version 2.80 biting his nails, tim
Any way to list what compile options were used?
Is there any easy way to check which options were used to compile mod_perl. Or more specifically, is there an easy way to check which type handlers a mod_perl build allows, if it allows stacked handlers, if it allows method handlers and if it allows perl sections? Thanks. -- Eric L. Brine [EMAIL PROTECTED] Same email for ICQ MSN http://www.adaelis.com/
Re: Any way to list what compile options were used?
Eric L. Brine wrote: Is there any easy way to check which options were used to compile mod_perl. Or more specifically, is there an easy way to check which type handlers a mod_perl build allows, if it allows stacked handlers, if it allows method handlers and if it allows perl sections? Thanks. use the guide :) http://perl.apache.org/release/docs/1.0/guide/install.html#Discovering_Whether_Some_Option_Was_Configured __ 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
