ANNOUNCE: Compress::LeadingBlankSpaces 0.04
This is a new feature version. Tag code is not compressed anymore. Upgrade is necessary for users of Apache::Dynagzip experiencing corrupted content associated with code tag. The uploaded file Compress-LeadingBlankSpaces-0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/S/SL/SLAVA/Compress-LeadingBlankSpaces-0.04.tar.gz size: 3720 bytes md5: ecb282cbd223510bc990fff02b2ff079 Thanks, Slava -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache
Stas Bekman [EMAIL PROTECTED] 05/05/2004 19:56 Pour :[EMAIL PROTECTED] cc :mod_perl Mailing List [EMAIL PROTECTED] Objet :Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache % nm modperl_bucket.o | grep modperl_bucket_sv_create 01e2 T modperl_bucket_sv_create Here is the result : [37] | 0| 92|FUNC |GLOB |0| .text|modperl_bucket_sv_create Sorry, I'm not familiar with nm's output on your platform. What does 0 mean? That it's unresolved? What do you get for other symbols (just to compare), e.g. nm mod_perl.a | grep modperl_callback [EMAIL PROTECTED]:/var/tmp/apache_perl/modperl-2.0/src/modules/perl nm mod_perl.a | grep modperl_callback [197] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_per_dir [117] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_process [59] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_per_dir [94] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback Symbols from mod_perl.a[modperl_callback.o]: [11] | 0|8|OBJT |LOCAL|0| .rodata|S$158$modperl_callback [32] | 0| 1852|FUNC |GLOB |0| .text|modperl_callback [84] | 0| 68|FUNC |GLOB |0| .text|modperl_callback_connection [87] | 0| 64|FUNC |GLOB |0| .text|modperl_callback_files [82] | 0| 68|FUNC |GLOB |0| .text|modperl_callback_per_dir [83] | 0| 68|FUNC |GLOB |0| .text|modperl_callback_per_srv [85] | 0| 68|FUNC |GLOB |0| .text|modperl_callback_pre_connection [86] | 0| 68|FUNC |GLOB |0| .text|modperl_callback_process [64] | 0| 1316|FUNC |GLOB |0| .text|modperl_callback_run_handlers [66] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback [38] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_connection [56] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_files [44] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_per_dir [52] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_per_srv [42] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_pre_connection [40] | 0|0|FUNC |GLOB |0| UNDEF|modperl_callback_process Here is a part of man nm Default Output Format - 64 bit If the default (neither the -p nor the -P option) output format is specified, each symbol has the following columns, separated by vertical bars (|). The default for numbers is decimal (-d or -t d). If decimal: [%u]%s|%22llu|%8u|%s|%s|%1d|%s|%s, index, value, size, type, bind, O, shndx, name If octal: [%u]%s|%022llo|%010o|%s|%s|%1o|%s|%s, index, value, size, type, bind, O, shndx, name If hexadecimal: [%u]%s|0x%016llx|0x%08x|%s|%s|%1x|%s|%s, index, value, size, type, bind, O, shndx, name The descriptions are explained below: name The name of the symbol. value Its value expressed as an offset or an address depending on its storage class. scope The scope of the symbol (external, sdef, static, or undefined). The sdef scope indicates an external symbol that is flagged as a secondary definition. type The type of the symbol (absolute, arg_ext, code, data, entry, milli_ext, millicode, module, null, oct_dis, plabel, pri_prog, sec_prog, storage, stub, sym_ext, tstor). subspaceThe subspace to which the symbol belongs. bind Specifies the symbol binding type (local, weak, global). O This field is used for files that have large section tables (65K sections). For smaller files, the value of this field is 0. Shndx Identifies the index of the section that the symbol belongs to. Identifies the index of the symbol in the symbol table. Olivier
Re: Callback called exit.
On Wed, 2004-05-05 at 22:11, Brian Hirt wrote: I've been running across a problem lately where a child process terminates because of an out of memory error. It prints Out of Memory once, the the process sucks up all available cpu print Callback called exit. to the log file until it hit's it's 2GB max size. I'm just guessing here, but this is probably because apache is trying to spawn new processes, and they keep dying because there's no memory. = See Perl's INSTALL document for this item: This might have been true at one point. Newer versions of perl 5.6 and 5.8 have no reference to this option in the INSTALL document There was discussion about this on PerlMonks: http://perlmonks.org/index.pl?node_id=287850 The most informative quote was this one: $^M was an Ilya-thing, which he added in during his work on perl's built-in memory allocation system. Nobody else ever really cared about it so far as I remember from p5p, so it suffers some from both neglect and unfinshedness. I remember in the 5.004/5.005 days that it used to work, but I honestly don't remember how, nor whether it ever worked for anyone other than Ilya. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Transactions corruption and persistent connections
On Thu, 2004-05-06 at 12:42, Hans Poo R. wrote: I removed the manual rollback and let the job to Apache::DBI, the problem is that after the change, the message about the handle destroyed still appears in the log. I activated the $Apache::DBI::DEBUG variable, but the message persist (now with the DEBUG information). Does the debug info show that Apache::DBI is holding onto the connection or making a new connection every time? The error you're getting is one that DBI gives when a database handle goes out of scope (or gets explicitly undef'ed) without being disconnected. A handle that Apache::DBI is keeping persistent should not get DESTROY'd when it goes out of scope. You might want to run this in the debugger and see where this is happening. It looks like it's a postgreSQL specific problem. I don't see anything PostgreSQL-specific in the errors you showed us. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Callback called exit.
I too followed the advice too, but it did nothing but lead my down the
wrong path. The advice should be updated.
My point is that $^M does absolutely nothing unless you use perl's
malloc, which isn't true for most common perl installations these days.
compiling with PERL_EMERGENCY_SBRK doesn't help either because it's
the default if you usemymalloc, and useless if you don't You MUST
compile perl with -Dusemymalloc=y. A simple grep in the perl hints
directory shows that many popular systems such as linux, freebsd and
openbsd default to the system malloc which disables the functionality
of $^M.
I'd simply like to see the documentation updated, and I'm happy to do
it. I know it would have saved me hours and hours of headaches. The
documentation as it stands now is misleading.
of course if you use perl's malloc, the advice helps.
I'd still like to know why mod_perl can get into an infinite loop
writtitng Callback called exit.In perl.c, when that happens
my_exit_jump(); is called which should presumably exit the process, but
somehow that doesn't happen and some sort of infinite loop occurs
outside of my code that fills the log of with gigibytes of 'Callback
called exit' messages.
regards,
brian
On May 5, 2004, at 11:00 PM, Glenn wrote:
On Wed, May 05, 2004 at 08:11:56PM -0600, Brian Hirt wrote:
I've been running across a problem lately where a child process
terminates because of an out of memory error. It prints Out of
Memory
once, the the process sucks up all available cpu print Callback
called
exit. to the log file until it hit's it's 2GB max size.
I have some Apache::Resource limits set, and they probably need to be
raised, but the way the error is handled is not very graceful. I'd
expect the child to just terminate after reporting the first error
message. I'm not sure if this is a perl problem or a mod_perl
problem. I'd still like to figure out how to prevent the repeating
message from happening.
Anyway, I've been pulling my hair out trying to prevent this, and I've
finally figured out how to trap this. I have some suggestions for
the
documentation, because the following url could use some help:
http://perl.apache.org/docs/1.0/guide/
troubleshooting.html#Callback_called_exit
I've followed that advice and explicitly allocated memory into $^M.
I have the following in my mod_perl_startup.pl, which I run from
httpd.conf with PerlRequire /path/to/mod_perl_startup.pl
If 64K is not enough for you, try increasing the allocation.
Cheers,
Glenn
use strict;
## --
## --
## This section is similar in scope to Apache::Debug.
## Delivers a stack backtrace to the error log when perl code dies.
## Allocate 64K as an emergency memory pool for use in out of memory
situation
$^M = 0x00 x 65536;
## Little trick to initialize this routine here so that in the case of
OOM,
## compiling this routine doesn't eat memory from the emergency memory
pool $^M
use CGI::Carp ();
eval { CGI::Carp::confess('init') };
## Importing CGI::Carp sets $main::SIG{__DIE__} = \CGI::Carp::die;
## Override that to additionally give a stack backtrace
$main::SIG{__DIE__} = \CGI::Carp::confess;
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Callback called exit.
On May 6, 2004, at 10:27 AM, Perrin Harkins wrote: On Wed, 2004-05-05 at 22:11, Brian Hirt wrote: I've been running across a problem lately where a child process terminates because of an out of memory error. It prints Out of Memory once, the the process sucks up all available cpu print Callback called exit. to the log file until it hit's it's 2GB max size. I'm just guessing here, but this is probably because apache is trying to spawn new processes, and they keep dying because there's no memory. Thanks for the response, interesting insight into the history of $^M. When I've seen this happen, it's the same PID spewing the messages, there are no forkings going on. The system isn't actually out of memory, and there is plenty of it available for the parent httpd process to fork.The child process has an rlimit set which is why it's getting an out of memory error. I initially set the rlimit, because at one point in the past the ImageMagick module would every now and then go crazy and consume all available memory which would bring down everything. -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Howto use emacs and perldb to debug mod_perl?
On Thu, 6 May 2004 16:12:16 +, [EMAIL PROTECTED] wrote:
James Moore claimed to have gotten it right:
http://groups.google.ch/groups?q=emacs+mod_perlhl=enlr=lang_en|lang_deie=UTF-8oe=UTF-8selm=1051404465.5094
+85%40yasurernum=1
It partially works for me. The last part doesn't:
James Moore wrote:
Not elegant, but it does get you full functionality (or at least the
only
bit I cared about, the = pointer into your code buffer for the current
line
of execution).
His method ruins it if you want to run the debugger w/o emacs.
Here's a modification that gets around that problem:
in the Apache/perl5db.pl file add the line:
$slave_editor ||= $ENV{SLAVE_EMACS};
right after the assignment to $slave_editor.
Then in your httpd.conf add the line:
PerlPassEnv SLAVE_EMACS
And in the script you pass to emacs when it says Run perldb (like this):
SLAVE_EMACS=1 exec httpd -X -DPERLDB
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache
TimeZones are not fun, hey :) [EMAIL PROTECTED] wrote: Here is the result : [37] | 0| 92|FUNC |GLOB |0| .text|modperl_bucket_sv_create Thanks for the manpage quoting, so now we know that the symbol is seen from mod_perl.a. Next mod_perl.a gets linked to httpd. Earlier you said that you can't see that symbol in httpd. May be it's because httpd gets stripped of its symbols? Try to build httpd with --enable-maintainer-mode (just for the debugging). What I suspect is that httpd doesn't link mod_perl.a at all and that's why you get this problem. the modperl_bucket_sv_create probably just happens to be the first symbol that is attempted to be used. BTW, Philippe has a new version of the static build patch: http://marc.theaimsgroup.com/?l=apache-modperl-devm=108386907921853w=2 -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Callback called exit.
Brian Hirt wrote: I too followed the advice too, but it did nothing but lead my down the wrong path. The advice should be updated. My point is that $^M does absolutely nothing unless you use perl's malloc, which isn't true for most common perl installations these days. compiling with PERL_EMERGENCY_SBRK doesn't help either because it's the default if you usemymalloc, and useless if you don't You MUST compile perl with -Dusemymalloc=y. A simple grep in the perl hints directory shows that many popular systems such as linux, freebsd and openbsd default to the system malloc which disables the functionality of $^M. I'd simply like to see the documentation updated, and I'm happy to do it. I know it would have saved me hours and hours of headaches. The documentation as it stands now is misleading. of course if you use perl's malloc, the advice helps. Doc patches are always welcome here. Please patch against the source pod. http://perl.apache.org/download/docs.html#Download I'd still like to know why mod_perl can get into an infinite loop writtitng Callback called exit.In perl.c, when that happens my_exit_jump(); is called which should presumably exit the process, but somehow that doesn't happen and some sort of infinite loop occurs outside of my code that fills the log of with gigibytes of 'Callback called exit' messages. Normally that happens when perl gets its calls stack messed up and it starts to loop. I know I hit that myself while developing mp2 when I was trying to write my own version of die/exit/etc, which I quickly gave up. It is possible that there is a bug in perl, which gets triggered only in certain situations. If you can give p5p a reproducable case, I'm sure it'll be fixed. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Callback called exit.
Glenn wrote:
[...]
http://perl.apache.org/docs/1.0/guide/troubleshooting.html#Callback_called_exit
I've followed that advice and explicitly allocated memory into $^M.
I have the following in my mod_perl_startup.pl, which I run from
httpd.conf with PerlRequire /path/to/mod_perl_startup.pl
If 64K is not enough for you, try increasing the allocation.
Cheers,
Glenn
use strict;
## --
## --
## This section is similar in scope to Apache::Debug.
## Delivers a stack backtrace to the error log when perl code dies.
## Allocate 64K as an emergency memory pool for use in out of memory situation
$^M = 0x00 x 65536;
## Little trick to initialize this routine here so that in the case of OOM,
## compiling this routine doesn't eat memory from the emergency memory pool $^M
use CGI::Carp ();
eval { CGI::Carp::confess('init') };
## Importing CGI::Carp sets $main::SIG{__DIE__} = \CGI::Carp::die;
## Override that to additionally give a stack backtrace
$main::SIG{__DIE__} = \CGI::Carp::confess;
Brian, you may want to include Glenn's useful tips as well in the patch.
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Howto use emacs and perldb to debug mod_perl?
Paul G. Weiss wrote:
On Thu, 6 May 2004 16:12:16 +, [EMAIL PROTECTED] wrote:
James Moore claimed to have gotten it right:
http://groups.google.ch/groups?q=emacs+mod_perlhl=enlr=lang_en|lang_deie=UTF-8oe=UTF-8selm=1051404465.5094
+85%40yasurernum=1
It partially works for me. The last part doesn't:
James Moore wrote:
Not elegant, but it does get you full functionality (or at least the
only
bit I cared about, the = pointer into your code buffer for the
current line
of execution).
His method ruins it if you want to run the debugger w/o emacs.
Here's a modification that gets around that problem:
in the Apache/perl5db.pl file add the line:
$slave_editor ||= $ENV{SLAVE_EMACS};
right after the assignment to $slave_editor.
Then in your httpd.conf add the line:
PerlPassEnv SLAVE_EMACS
And in the script you pass to emacs when it says Run perldb (like this):
SLAVE_EMACS=1 exec httpd -X -DPERLDB
If someone can write a section explaining how to do that properly, I think
it'll be a great addition to our docs. Just post the pod here and I'll add it.
Thanks.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mp2 Apache2.0.49 on HPUX11i : mod_perl does not load in Apache
Stas Bekman wrote: What I suspect is that httpd doesn't link mod_perl.a at all and that's why you get this problem. the modperl_bucket_sv_create probably just happens to be the first symbol that is attempted to be used. Please scratch that last part, as it's obviously wrong, since once you linked APR/Bucket.so statically it did work fine. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
[Patch mp2] Fix api/module test to pass on static builds
Stas Bekman wrote:
Here are the results you asked for :
t/TEST -clean
t/TEST -v t/api/module.t t/apr/netlib.t t/compat/conn_rec.t
t/modperl/setupenv.t t/preconnection/note.t
Thanks. So it all comes down to two issues.
1) Apache::Module::loaded('mod_perl.so')
t/api/module1..11
# testing : Apache::Module::loaded('mod_perl.so')
# expected: 1
# received: 0
not ok 6
It makes sense that mod_perl.so is not loaded, since it doesn't exist.
Philippe, I wonder how this test has passed for you.
That's correct, and really, it's a borked test then. It did pass for me once
strangely, as I managed to have 2 mod_perls in my httpd, a static one and a dso
loaded one ( can't reproduce that, lol)
Index: t/response/TestAPI/module.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/module.pm,v
retrieving revision 1.9
diff -u -I$Id -r1.9 module.pm
--- t/response/TestAPI/module.pm8 Apr 2004 01:56:31 - 1.9
+++ t/response/TestAPI/module.pm6 May 2004 20:24:04 -
@@ -7,6 +7,7 @@
use Apache::Test;
use Apache::TestConfig;
use Apache::TestUtil;
+use Apache::BuildConfig;
use Apache::Module ();
use DynaLoader ();
@@ -84,9 +85,12 @@
Apache::Module::loaded('Apache__Module_foo.c'));
#.so
-ok t_cmp(1, Apache::Module::loaded('mod_perl.so'),
+{
+my $expect = Apache::BuildConfig-new-{MP_USE_STATIC} ? 0 : 1;
+ok t_cmp($expect, Apache::Module::loaded('mod_perl.so'),
Apache::Module::loaded('mod_perl.so'));
-
+}
+
ok t_cmp(0, Apache::Module::loaded('Apache__Module__foo.so'),
Apache::Module::loaded('Apache__Module_foo.so'));
2) the rest of the tests fail on $ENV{REMOTE_ADDR} and $r-remote_address
returning 0.0.0.0 instead of 127.0.0.1. Sounds like an ipv6 issue to me. but
since all those running ipv6 didn't report that problem that sounds as either
a bug in Apache on HPUX11i or some OS issues. Olivier, could you try a mod_cgi
script that prints out $ENV{REMOTE_ADDR}, when your client is running on the
same machine and when it's running from another machine? Thanks.
__
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
--
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [Patch mp2] Fix api/module test to pass on static builds
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Here are the results you asked for :
t/TEST -clean
t/TEST -v t/api/module.t t/apr/netlib.t t/compat/conn_rec.t
t/modperl/setupenv.t t/preconnection/note.t
Thanks. So it all comes down to two issues.
1) Apache::Module::loaded('mod_perl.so')
t/api/module1..11
# testing : Apache::Module::loaded('mod_perl.so')
# expected: 1
# received: 0
not ok 6
It makes sense that mod_perl.so is not loaded, since it doesn't exist.
Philippe, I wonder how this test has passed for you.
That's correct, and really, it's a borked test then. It did pass for me once
strangely, as I managed to have 2 mod_perls in my httpd, a static one and a dso
loaded one ( can't reproduce that, lol)
Shouldn't loaded() be fixed instead to tell you whether mod_perl is linked? Or
was the idea for it to work only for DSO modules?
If it doesn't I can't see any value in this API, since to check mod_perl you
can check $ENV{MOD_PERL} and to check for any other module, you can't really
say that the module is not available if its linked statically. No?
Index: t/response/TestAPI/module.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/module.pm,v
retrieving revision 1.9
diff -u -I$Id -r1.9 module.pm
--- t/response/TestAPI/module.pm8 Apr 2004 01:56:31 - 1.9
+++ t/response/TestAPI/module.pm6 May 2004 20:24:04 -
@@ -7,6 +7,7 @@
use Apache::Test;
use Apache::TestConfig;
use Apache::TestUtil;
+use Apache::BuildConfig;
use Apache::Module ();
use DynaLoader ();
@@ -84,9 +85,12 @@
Apache::Module::loaded('Apache__Module_foo.c'));
#.so
-ok t_cmp(1, Apache::Module::loaded('mod_perl.so'),
+{
+my $expect = Apache::BuildConfig-new-{MP_USE_STATIC} ? 0 : 1;
+ok t_cmp($expect, Apache::Module::loaded('mod_perl.so'),
Apache::Module::loaded('mod_perl.so'));
-
+}
+
ok t_cmp(0, Apache::Module::loaded('Apache__Module__foo.so'),
Apache::Module::loaded('Apache__Module_foo.so'));
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [Patch mp2] Fix api/module test to pass on static builds
Stas Bekman wrote:
Philippe M. Chiasson wrote:
Stas Bekman wrote:
Here are the results you asked for :
t/TEST -clean
t/TEST -v t/api/module.t t/apr/netlib.t t/compat/conn_rec.t
t/modperl/setupenv.t t/preconnection/note.t
Thanks. So it all comes down to two issues.
1) Apache::Module::loaded('mod_perl.so')
t/api/module1..11
# testing : Apache::Module::loaded('mod_perl.so')
# expected: 1
# received: 0
not ok 6
It makes sense that mod_perl.so is not loaded, since it doesn't exist.
Philippe, I wonder how this test has passed for you.
That's correct, and really, it's a borked test then. It did pass for me once
strangely, as I managed to have 2 mod_perls in my httpd, a static one and a dso
loaded one ( can't reproduce that, lol)
Shouldn't loaded() be fixed instead to tell you whether mod_perl is linked? Or
was the idea for it to work only for DSO modules?
No, you can chose to check for a DSO module with -loaded('module.so').
But you can also check for a module with -loaded('module.c') and that will
be true for both static or dso loaded modules.
If it doesn't I can't see any value in this API, since to check mod_perl you
can check $ENV{MOD_PERL} and to check for any other module, you can't really
say that the module is not available if its linked statically. No?
Yes, for mod_perl you can check $ENV{MOD_PERL}, but let's say you want to know
if mod_autoindex is installed, you check for -loaded('mod_autoindex.c') and
this will work.
Actually, I can't think of a good reason why checking for 'module.so' and not
'module.c' would make sense.
Index: t/response/TestAPI/module.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/module.pm,v
retrieving revision 1.9
diff -u -I$Id -r1.9 module.pm
--- t/response/TestAPI/module.pm 8 Apr 2004 01:56:31 - 1.9
+++ t/response/TestAPI/module.pm 6 May 2004 20:24:04 -
@@ -7,6 +7,7 @@
use Apache::Test;
use Apache::TestConfig;
use Apache::TestUtil;
+use Apache::BuildConfig;
use Apache::Module ();
use DynaLoader ();
@@ -84,9 +85,12 @@
Apache::Module::loaded('Apache__Module_foo.c'));
#.so
-ok t_cmp(1, Apache::Module::loaded('mod_perl.so'),
+{
+my $expect = Apache::BuildConfig-new-{MP_USE_STATIC} ? 0 : 1;
+ok t_cmp($expect, Apache::Module::loaded('mod_perl.so'),
Apache::Module::loaded('mod_perl.so'));
-
+}
+
ok t_cmp(0, Apache::Module::loaded('Apache__Module__foo.so'),
Apache::Module::loaded('Apache__Module_foo.so'));
__
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
--
Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5
http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variable $some_var will not stay shared
On Thursday 06 May 2004 04:41 am, Wiggins d Anconia wrote:
[snip]
Generally when I hit an unrecognized warning it is time to check the
perldiag docs,
perldoc perldiag
Conveniently,
Variable %s will not stay shared
(W closure) An inner (nested) named subroutine is referencing a lexical
variable defined in an outer subroutine.
When the inner subroutine is called, it will probably see the value of
the outer subroutine's variable as it was before and during the *first*
call to the outer subroutine; in this case, after the first call to the
outer subroutine is complete, the inner and outer subroutines will no
longer share a common value for the variable. In other words, the
variable will no longer be shared.
Furthermore, if the outer subroutine is anonymous and references a
lexical variable outside itself, then the outer and inner subrou
tines will never share the given variable. This problem can usually
be solved by making the inner subroutine anonymous, using the sub {}
syntax. When inner anonymous subs that reference variables in outer
subroutines are called or referenced, they are automatically rebound to
the current values of such variables.
Thank you Wiggins,
But maybe I could explain the overall picture. I am trying to embed
'any' script (whthout modification) in perl; I use a perl package
(which is run via a c program) to maintain 'persistence' of the script
which is read from disk. This must be done in the mod_perl registry
for cgi scripts, but my search of the mod_perl source so far has
been fruitless.
Suppose this script (ev1.pl) is read from disk:
#!/usr/bin/perl
use strict;
use warnings;
my $arg1 = shift @ARGV;
my $arg2 = shift @ARGV;
show_stuff();
sub show_stuff
{
print $arg1 and $arg2\n;
}
Standalone, this runs fine. Now my perl package (listed at the end),
maintains a cache of scripts that have been read from disk, If a
script has not yet been seen (tne generated package name for the
script is not in the cache), a package name is generated from
the script file name and it makes a package of it as follows:
package Embed::ev1_2epl; sub __handler__ { shift; @ARGV = @_; my $code = sub
{ #!/usr/bin/perl
use strict;
use warnings;
my $arg1 = shift @ARGV;
my $arg2 = shift @ARGV;
show_stuff();
sub show_stuff
{
print $arg1 and $arg2\n;
}
}; $code; }
An 'eval' of the above statement is done to 'compile' it and the
package name is saved a cache.
Next the script is 'run' using the package name generated (either
a package just compiled or from the cache):
eval {$package-__handler__(@user_args);};
is done. Same problem (of course - because as you pointed out
it has a nested subroutine issue) :
$ perl t1.pl
ev1.pl is package Embed::ev1_2epl
Variable $arg1 will not stay shared at (eval 1) line 13.
Variable $arg2 will not stay shared at (eval 1) line 13.
jack and jill
already compiled Embed::ev1_2epl
jack and jill
Sorry all, I know this is a bit much...
Aloha = Beau;
'persistent' perl package (Embed::Persistent) and test code follows.
It is a knock-off of the sample in the perlembed man page.
t1.pl:
#!/usr/bin/perl
package Embed::Persistent;
use strict;
use warnings;
our %Cache;
sub valid_package_name {
my($string) = @_;
$string =~ s/([^A-Za-z0-9\/])/sprintf(_%x,unpack(C,$1))/eg;
$string =~ s|/(\d)|sprintf(/_%x,unpack(C,$1))|eg;
$string =~ s|/|::|g;
$string = ::$string unless $string =~ /^::/;
return Embed . $string;
}
sub _eval_file {
my ($filename, @user_args) = @_;
my $package = valid_package_name ($filename);
my $mtime = -M $filename;
if(defined $Cache{$package}{mtime}
$Cache{$package}{mtime} = $mtime)
{
print already compiled $package\n;
} else {
local *FH;
open FH, $filename || die;
my $sub = do { local $/; FH; };
close FH;
my @chunks = split (\n__END__), $sub;
$sub = shift @chunks;
my $end = join( , @chunks ) || '';
my $eval = package $package; sub __handler__ { shift; [EMAIL PROTECTED] =
[EMAIL PROTECTED];
my \$code = sub { $sub \n}; \$code; } \n$end;
print $eval;
print $filename is package $package\n;
my $cmpl_error = do {
my($filename,$mtime,$package,$sub);
@_ = @user_args;
eval $eval;
$@;
};
die perl compile error in $filename: $cmpl_error\n
if $cmpl_error;
$Cache{$package}{mtime} = $mtime;
}
my $eval_error = $@ = do {
eval {$package-__handler__(@user_args);};
$@;
};
die perl run-time error in $filename: $eval_error\n
if $eval_error;
}
1;
Embed::Persistent::_eval_file( 'ev1.pl', 'jack', 'jill' );
Embed::Persistent::_eval_file( 'ev1.pl', 'william', 'mary' );
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: [Patch mp2] Fix api/module test to pass on static builds
Philippe M. Chiasson wrote:
That's correct, and really, it's a borked test then. It did pass for me once
strangely, as I managed to have 2 mod_perls in my httpd, a static one and a dso
loaded one ( can't reproduce that, lol)
Shouldn't loaded() be fixed instead to tell you whether mod_perl is linked? Or
was the idea for it to work only for DSO modules?
No, you can chose to check for a DSO module with -loaded('module.so').
But you can also check for a module with -loaded('module.c') and that will
be true for both static or dso loaded modules.
So most likely you always want to check for .c
If it doesn't I can't see any value in this API, since to check mod_perl you
can check $ENV{MOD_PERL} and to check for any other module, you can't really
say that the module is not available if its linked statically. No?
Yes, for mod_perl you can check $ENV{MOD_PERL}, but let's say you want to know
if mod_autoindex is installed, you check for -loaded('mod_autoindex.c') and
this will work.
Actually, I can't think of a good reason why checking for 'module.so' and not
'module.c' would make sense.
Hmm, may be someone will want to know that it was loaded as DSO.
Please commit that patch. Thanks.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variable $some_var will not stay shared
On Thu, 2004-05-06 at 17:19, Beau E. Cox wrote: But maybe I could explain the overall picture. I am trying to embed 'any' script (whthout modification) in perl; I use a perl package (which is run via a c program) to maintain 'persistence' of the script which is read from disk. This must be done in the mod_perl registry for cgi scripts, but my search of the mod_perl source so far has been fruitless. The code is in Apache::Registry, or ModPerl::RegistryCooker for mp2. It's pure perl and pretty easy to read. It has the same problem as yours though, i.e. subs that refer to lexicals declared outside of them generate this error. Normally, that sub would just be a closure, but once you nest it you get an actual leak. Workarounds are described in the mod_perl docs here: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my___Scoped_Variable_in_Nested_Subroutines I don't think you can solve this nicely without limiting the sort of code that you allow. - Perrin -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Variable $some_var will not stay shared
On Thursday 06 May 2004 11:40 am, Perrin Harkins wrote: On Thu, 2004-05-06 at 17:19, Beau E. Cox wrote: But maybe I could explain the overall picture. I am trying to embed 'any' script (whthout modification) in perl; I use a perl package (which is run via a c program) to maintain 'persistence' of the script which is read from disk. This must be done in the mod_perl registry for cgi scripts, but my search of the mod_perl source so far has been fruitless. The code is in Apache::Registry, or ModPerl::RegistryCooker for mp2. It's pure perl and pretty easy to read. It has the same problem as yours though, i.e. subs that refer to lexicals declared outside of them generate this error. Normally, that sub would just be a closure, but once you nest it you get an actual leak. Workarounds are described in the mod_perl docs here: http://perl.apache.org/docs/general/perl_reference/perl_reference.html#my__ _Scoped_Variable_in_Nested_Subroutines I don't think you can solve this nicely without limiting the sort of code that you allow. Perrin - thanks so much. The reference you give explains all! This thread is now closed ;) Aloha = Beau; -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Callback called exit.
I've typed up my suggestions to the troubleshooting doc, and
incorporated glen's suggestions too. Stas wants me to post to the
list to see if there are any comments / corrections.
I wasn't sure if I should put a comment in about __DIE__ handlers and
their use with evals, it seemed like that might be too general perl.
Index: src/docs/1.0/guide/troubleshooting.pod
===
RCS file:
/home/cvspublic/modperl-docs/src/docs/1.0/guide/troubleshooting.pod,v
retrieving revision 1.28
diff -u -r1.28 troubleshooting.pod
--- src/docs/1.0/guide/troubleshooting.pod 5 May 2004 03:29:38
- 1.28
+++ src/docs/1.0/guide/troubleshooting.pod 6 May 2004 22:40:07
-
@@ -589,27 +589,45 @@
If something goes really wrong with your code, Perl may die with an
Out of memory! message and/or Callback called exit. Common causes
of this
-are never-ending loops, deep recursion, or calling an
-undefined subroutine. Here's one way to catch the problem: See Perl's
-INSTALL document for this item:
+are never-ending loops, deep recursion, or calling an undefined
subroutine.
- =item -DPERL_EMERGENCY_SBRK
+If you are using perl 5.005 or later, and perl is compiled to use
it's own
+malloc rutines, you can trap out of memory errors by setting aside an
extra
+memory pool in the special variable $^M. By default perl uses the
operating
+system malloc for many popular systems, so unless you build perl with
+'usemymalloc=y' you probably wont be able to use $^M. To check if
your mod_perl
+was compiled to use perl's internal malloc(), stick the following code
in a
+handler and see if usemymalloc is set to 'y'
+
+ use Config;
+
+ print Config::myconfig();
+
+Here is an explanation of $^M from perlvar(i):
+
+ $^M By default, running out of memory is an untrap-
+ pable, fatal error. However, if suitably built,
+ Perl can use the contents of $^M as an emergency
+ memory pool after die()ing. Suppose that your
+ Perl were compiled with -DPERL_EMERGENCY_SBRK and
+ used Perl's malloc. Then
+
+ $^M = 'a' x (1 16);
+
+ would allocate a 64K buffer for use in an emer-
+ gency. See the INSTALL file in the Perl distribu-
+ tion for information on how to enable this option.
+ To discourage casual use of this advanced feature,
+ there is no English long name for this variable.
- If PERL_EMERGENCY_SBRK is defined, running out of memory need not be
a
- fatal error: a memory pool can allocated by assigning to the special
- variable $^M. See perlvar(1) for more details.
-
-If you compile with that option and add 'Cuse Apache::Debug level
+If your perl installation supports $^M and you add 'Cuse
Apache::Debug level
=Egt 4;' to your Perl script, it will allocate the C$^M emergency
pool and the C$SIG{__DIE__} handler will call CCarp::confess,
giving you a stack trace which should reveal where the problem is.
See the CApache::Resource module for ways to control httpd
processes.
-Note that Perl 5.005 and later have CPERL_EMERGENCY_SBRK turned on
-by default.
-
-The other trick is to have a startup script initialize
+Another trick is to have a startup script initialize
CCarp::confess, like so:
use Carp ();
@@ -617,6 +635,24 @@
this way, when the real problem happens, CCarp::confess doesn't eat
memory in the emergency pool (C$^M).
+
+Some other mod_perl users have reported that this works well for them:
+
+## Allocate 64K as an emergency memory pool for use in out of
memory situation
+$^M = 0x00 x 65536;
+
+## Little trick to initialize this routine here so that in the
case of OOM,
+## compiling this routine doesn't eat memory from the emergency
memory pool $^M
+use CGI::Carp ();
+eval { CGI::Carp::confess('init') };
+
+## Importing CGI::Carp sets $main::SIG{__DIE__} = \CGI::Carp::die;
+## Override that to additionally give a stack backtrace
+$main::SIG{__DIE__} = \CGI::Carp::confess;
+
+Discussion of $^M has come up on PerlMonks, and there is speculation
that $^M is a
+forgotten feature that's not well supported. See
+http://perlmonks.org/index.pl?node_id=287850 for more information.
=head2 server reached MaxClients setting, consider raising the
MaxClients setting
regards,
Brian
On May 6, 2004, at 1:19 PM, Stas Bekman wrote:
Brian Hirt wrote:
I too followed the advice too, but it did nothing but lead my down
the wrong path. The advice should be updated.
My point is that $^M does absolutely nothing unless you use perl's
malloc, which isn't true for most common perl installations these
days. compiling with PERL_EMERGENCY_SBRK doesn't help either
because it's the default if you usemymalloc, and useless if you
don't You MUST compile perl with -Dusemymalloc=y. A simple
grep in the perl hints directory shows that many popular systems
such as linux, freebsd and openbsd
Re: Callback called exit.
Brian Hirt wrote: I've typed up my suggestions to the troubleshooting doc, and incorporated glen's suggestions too. Stas wants me to post to the list to see if there are any comments / corrections. I wasn't sure if I should put a comment in about __DIE__ handlers and their use with evals, it seemed like that might be too general perl. While true for the rest of the documentation, there is no limit to what you can put it into the troubleshooting section, as long as it helps to troubleshoot the issue :) -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Database handle destroyed.....
Hello, I have a new Solaris server that runs on Solaris 8 and has been upgraded to Perl 5.8.3, Apache 2.49, mod_perl 1.99.13, and DB2 running as Database. When I start the apache server with startup.pl I get, Database handle destroyed without explicit disconnect at /usr/local/lib/perl5/site_perl/5.8.3/Apache/DBI.pm line 146 error. I have searched on this a little bit and there are several different approaches from mod_perl to module versions. Any ideas? Thanks much, Hulya
Re: Database handle destroyed.....
Hulya Gurer wrote: Hello, I have a new Solaris server that runs on Solaris 8 and has been upgraded to Perl 5.8.3, Apache 2.49, mod_perl 1.99.13, and DB2 running as Database. When I start the apache server with startup.pl I get, Database handle destroyed without explicit disconnect at /usr/local/lib/perl5/site_perl/5.8.3/Apache/DBI.pm line 146 error. I have searched on this a little bit and there are several different approaches from mod_perl to module versions. Looks like the old issue of opening the connection in the parent process: http://perl.apache.org/docs/1.0/guide/databases.html#Skipping_connection_cache_during_server_startup Apache::DBI doc doesn't claim to be ported to 2.0, it only suggests that it may work or may not. I suppose that someone needs to port it. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: Database handle destroyed.....
Hulya Gurer wrote: Sorry Stas, here it's. We are already using Apache::DBI-connect_on_init() and there are not many accesses to the database at this point that concern more than one connection. As I suggested: Apache::DBI doc doesn't claim to be ported to 2.0, it only suggests that it may work or may not. I suppose that someone needs to port it. Anybody to port it? Shouldn't be too hard to do that. It'd be nice to equip it with a full Apache-Test based test suite, but that could be a next step. __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
cvs commit: modperl-2.0/t/protocol/TestProtocol echo_filter.pm echo_timeout.pm
stas2004/05/06 20:46:27
Modified:t/filter/TestFilter both_str_con_add.pm
t/protocol/TestProtocol echo_filter.pm echo_timeout.pm
Log:
workaround to a problem on some platforms (solaris, bsd,
etc), where Apache 2.0.49+ forgets to set the blocking mode on
the socket
Revision ChangesPath
1.11 +7 -0 modperl-2.0/t/filter/TestFilter/both_str_con_add.pm
Index: both_str_con_add.pm
===
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/both_str_con_add.pm,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -u -r1.10 -r1.11
--- both_str_con_add.pm 4 May 2004 06:19:11 - 1.10
+++ both_str_con_add.pm 7 May 2004 03:46:27 - 1.11
@@ -53,6 +53,13 @@
sub handler {
my Apache::Connection $c = shift;
+# XXX: workaround to a problem on some platforms (solaris, bsd,
+# etc), where Apache 2.0.49+ forgets to set the blocking mode on
+# the socket
+require APR::Socket;
+BEGIN { use APR::Const -compile = qw(SO_NONBLOCK); }
+$c-client_socket-opt_set(APR::SO_NONBLOCK = 0);
+
my $bb = APR::Brigade-new($c-pool, $c-bucket_alloc);
for (;;) {
1.10 +7 -0 modperl-2.0/t/protocol/TestProtocol/echo_filter.pm
Index: echo_filter.pm
===
RCS file: /home/cvs/modperl-2.0/t/protocol/TestProtocol/echo_filter.pm,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -u -r1.9 -r1.10
--- echo_filter.pm4 May 2004 06:14:44 - 1.9
+++ echo_filter.pm7 May 2004 03:46:27 - 1.10
@@ -16,6 +16,13 @@
sub handler {
my Apache::Connection $c = shift;
+# XXX: workaround to a problem on some platforms (solaris, bsd,
+# etc), where Apache 2.0.49+ forgets to set the blocking mode on
+# the socket
+require APR::Socket;
+BEGIN { use APR::Const -compile = qw(SO_NONBLOCK); }
+$c-client_socket-opt_set(APR::SO_NONBLOCK = 0);
+
my $bb = APR::Brigade-new($c-pool, $c-bucket_alloc);
for (;;) {
1.3 +6 -0 modperl-2.0/t/protocol/TestProtocol/echo_timeout.pm
Index: echo_timeout.pm
===
RCS file: /home/cvs/modperl-2.0/t/protocol/TestProtocol/echo_timeout.pm,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -u -r1.2 -r1.3
--- echo_timeout.pm 4 May 2004 06:14:44 - 1.2
+++ echo_timeout.pm 7 May 2004 03:46:27 - 1.3
@@ -20,6 +20,12 @@
my Apache::Connection $c = shift;
my APR::Socket $socket = $c-client_socket;
+# XXX: workaround to a problem on some platforms (solaris, bsd,
+# etc), where Apache 2.0.49+ forgets to set the blocking mode on
+# the socket
+BEGIN { use APR::Const -compile = qw(SO_NONBLOCK) }
+$c-client_socket-opt_set(APR::SO_NONBLOCK = 0);
+
# set timeout (20 sec) so later we can do error checking on
# read/write timeouts
$socket-timeout_set(20_000_000);
cvs commit: modperl-2.0/t/response/TestAPI module.pm
gozer 2004/05/06 15:23:09
Modified:t/response/TestAPI module.pm
Log:
Make sure t/api/module will not fail when mod_perl is statically compiled
in httpd (upcoming feature)
Revision ChangesPath
1.10 +6 -2 modperl-2.0/t/response/TestAPI/module.pm
Index: module.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestAPI/module.pm,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- module.pm 8 Apr 2004 01:56:31 - 1.9
+++ module.pm 6 May 2004 22:23:09 - 1.10
@@ -7,6 +7,7 @@
use Apache::Test;
use Apache::TestConfig;
use Apache::TestUtil;
+use Apache::BuildConfig;
use Apache::Module ();
use DynaLoader ();
@@ -84,9 +85,12 @@
Apache::Module::loaded('Apache__Module_foo.c'));
#.so
-ok t_cmp(1, Apache::Module::loaded('mod_perl.so'),
+{
+my $expect = Apache::BuildConfig-new-{MP_USE_STATIC} ? 0 : 1;
+ok t_cmp($expect, Apache::Module::loaded('mod_perl.so'),
Apache::Module::loaded('mod_perl.so'));
-
+}
+
ok t_cmp(0, Apache::Module::loaded('Apache__Module__foo.so'),
Apache::Module::loaded('Apache__Module_foo.so'));
cvs commit: modperl-2.0/t/protocol/TestProtocol echo_block.pm
stas2004/05/06 18:13:57
Modified:t/protocol/TestProtocol echo_block.pm
Log:
comment fix
Revision ChangesPath
1.4 +2 -2 modperl-2.0/t/protocol/TestProtocol/echo_block.pm
Index: echo_block.pm
===
RCS file: /home/cvs/modperl-2.0/t/protocol/TestProtocol/echo_block.pm,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -u -r1.3 -r1.4
--- echo_block.pm 7 May 2004 01:13:05 - 1.3
+++ echo_block.pm 7 May 2004 01:13:57 - 1.4
@@ -27,9 +27,9 @@
if ($nonblocking) {
$socket-opt_set(APR::SO_NONBLOCK = 0);
-# test that we really are in the blocking mode
+# test that we really *are* in the blocking mode
!$socket-opt_get(APR::SO_NONBLOCK)
-or die failed to set non-blocking mode;
+or die failed to set blocking mode;
}
while (1) {
