Re:
Norman Virus Control hat die Original-E-Mail gelöscht da er den Virus enthielt [EMAIL PROTECTED]
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Stas Bekman wrote:
>Markus Wichitill wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>Almost all OK on Win32 (Apache 2.0.54 and a recent bleadperl). Main
>>>tests are all successful, but ModPerl-Registry tests failed 404.t test
>>>1 and redirect.t test 2.
>>>
>>>
>>Same here (WinXP, 2.0.54, 5.8.6). modperl_slurp_filename doesn't raise a
>>ENOENT exception when it should. The
>>
>>if (!size) {
>>sv_setpvn(sv, "", 0);
>>return newRV_noinc(sv);
>>}
>>
>>part looks fishy to me. size is 0 and therefore we never get to
>>SLURP_SUCCESS("opening"), which should throw the exception.
>>
>>
>
>Hmm, please see the comment:
>
> /* XXX: could have checked whether r->finfo.filehand is valid and
> * save the apr_file_open call, but apache gives us no API to
> * check whether filehand is valid. we can't test whether it's
> * NULL or not, as it may contain garbagea
> */
>
>how can we test if the filehandle is valid then? may be we should skip
>that bit altogether? Steve, does it work if you comment out the whole
>
> if (!size) { ... }
>
>block?
>
No, it doesn't :(
I even did a complete rebuild in case something didn't get relinked
properly after the change, but it still doesn't fix the two test failures.
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [mp2] modperl2 compile error
El dc 04 de 05 del 2005 a les 10:09 -0500, en/na Tom Caldwell va escriure: I have to concur with Marc - that there was no -fPIC and the necessary libraries were missing as well on my x86_64 red hat box. This seems to be happening with all the builds - perl, mod_perl, and probably apache too. Ok, If Perl is configured OK, mod_perl gets the args from Perl and everytning goes well, the same on all normal Makefile.PL building modules. But you must take care that the rests of things you had to use are compiled also with -fPIC. All RedHat or Fedora default builds seems to have been compiled that way, so no problems for default libs. (I haven't had a chance to get back to rebuilding apache as last suggested.) Different from Marc, I have been working as root, but still experiencing the same problems. The other thing I noticed was that a random directory (from the src tree) was added to the CCDLFLAGS when I added '-rdynamic -W1' during configure (as per the rpm version of perl). I had to remove this manually from the Makefile. Tom --On Wednesday, May 04, 2005 12:09 PM +0200 Marc Gràcia <[EMAIL PROTECTED]> wrote: > El dl 02 de 05 del 2005 a les 10:05 -0700, en/na Stas Bekman va > escriure: > > > > Marc Gràcia wrote: >> I had some problems like this on my new x86_64 machine with >> mod_perl2, seems that not only perl must be compiled with -fPIC >> , also apache and all libraries or modules you plan to use. I >> think it's a general issue with this architecture, not mod_perl >> related. > > That's correct, Marc. > >> If not, there are runtime linking relocation errors everywhere.. >> (I also had to recompile with -fPIC db and libz, for example) >> Maybe that's the problem... > > I supposed that Tom has recompiled everything after rebuilding > perl. > mod_perl will pick up -fPIC automatically at compile time, if > perl was > compiled with it. > > > Yes that's Ok for all perl modules. > But BTW, my Perl Compilation did not put automaticaly the -fPIC > flag when configuring and also didn't detect the needed libraries > (The line when Config script lets you add additional libraries > was empty except for the ones i compiled for myself, see below). > I had to put all that manually (After a lot of recompilations > trying to find what was happening) > > I was using a closed environment in a user with no root > permissions. All dependencies except most basic ones > (libc,lpthreads,etc..) are compiled and self contained in the > user's home (I'm doing a untar-and-forget instalation for our > product). > The same procedure went OK on all other kind of machines... so > maybe perl Config has some problem with x86_64. > The base system was a Fedora Core 3 EM64T version with no 32bits > compatibility packages installed. > But everything is running OK after all, only the Configure script > failed.. > > > > > > > > > -- > Marc Gràcia <[EMAIL PROTECTED]> Tom Caldwell Vanderbilt University Medical Center
Re: libapreq2-2.05-dev-rc2 release candidate #2
Randy Kobes wrote:
> Unfortunately, I
> missed one problem on Win32 in my earlier testing - the
> subdirectory module/t/cgi-bin/ has to be created before
> testing.
I thought the cgi script(s?) were written out via t_write_perl_script()?
my $cgi = File::Spec->catfile(Apache::Test::vars('serverroot'),
qw(cgi-bin test_cgi.pl));
t_write_perl_script($cgi, );
so that should create t/cgi-bin. unless you're talking about a different
script, in which case the proper solution is to probably use
t_write_perl_script() there as well. but I don't immediately see what that
would be...
--Geoff
Having problems with simple threaded perl CGI in mod_perl 1.29 (Apache 1.3.33)
I am trying to write a simple threaded perl CGI script to run under Apache::Registry on mod_perl 1.29 and Apache 1.3.33. The perl scipt only creates 2 or 3 threads and perform a join() on each one to wait for data each thread returns. The script seems to work fine, returning all the data I expect and all the HTML is generated using CGI.pm, thus rendering a complete and accurate page in a web browser. On the server I get errors in my Apache error_log: [Thu May 5 01:01:03 2005] null: semi-panic: attempt to dup freed string. [Thu May 5 01:01:03 2005] [error] Undefined subroutine &main:: called.\n [Thu May 5 01:01:03 2005] null: semi-panic: attempt to dup freed string. [Thu May 5 01:01:03 2005] [error] Undefined subroutine &main:: called.\n [Thu May 5 01:01:04 2005] [notice] child pid 13166 exit signal Segmentation fault (11), possible coredump in /usr/local/dmx/www Running on RH 9 Linux - Perl 5.8.6, Apache 1.3.33, and mod_perl 1.29 all built by myself from source (not using RPM's) Any Ideas? Thanks... -- Bill Hess
Re: libapreq2-2.05-dev-rc2 release candidate #2
On Thu, 5 May 2005, Geoffrey Young wrote:
> Randy Kobes wrote:
> > Unfortunately, I
> > missed one problem on Win32 in my earlier testing - the
> > subdirectory module/t/cgi-bin/ has to be created before
> > testing.
>
> I thought the cgi script(s?) were written out via t_write_perl_script()?
>
> my $cgi = File::Spec->catfile(Apache::Test::vars('serverroot'),
> qw(cgi-bin test_cgi.pl));
>
>
> t_write_perl_script($cgi, );
>
> so that should create t/cgi-bin. unless you're talking about a different
> script, in which case the proper solution is to probably use
> t_write_perl_script() there as well. but I don't immediately see what that
> would be...
Thanks for pointing that out, but unfortunately, that occurs
too late, at least in the way that I've built things on
Win32 - before that point, the test_cgi.exe executable is
built from module/test_cgi.c and placed under
module/t/cgi-bin/. I guess another alternative is to build
it under an existing directory and copy it afterwards; I'll
see which one is easier.
--
best regards,
randy
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Steve Hay wrote:
Stas Bekman wrote:
Markus Wichitill wrote:
Steve Hay wrote:
Almost all OK on Win32 (Apache 2.0.54 and a recent bleadperl). Main
tests are all successful, but ModPerl-Registry tests failed 404.t test
1 and redirect.t test 2.
Same here (WinXP, 2.0.54, 5.8.6). modperl_slurp_filename doesn't raise a
ENOENT exception when it should. The
if (!size) {
sv_setpvn(sv, "", 0);
return newRV_noinc(sv);
}
part looks fishy to me. size is 0 and therefore we never get to
SLURP_SUCCESS("opening"), which should throw the exception.
Hmm, please see the comment:
/* XXX: could have checked whether r->finfo.filehand is valid and
* save the apr_file_open call, but apache gives us no API to
* check whether filehand is valid. we can't test whether it's
* NULL or not, as it may contain garbagea
*/
how can we test if the filehandle is valid then? may be we should skip
that bit altogether? Steve, does it work if you comment out the whole
if (!size) { ... }
block?
No, it doesn't :(
I even did a complete rebuild in case something didn't get relinked
properly after the change, but it still doesn't fix the two test failures.
So what has changed? You didn't have these problems with RC6? Could you
trace what change has affected that? Unless Randy or someone who can
reproduce that can look at 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
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Steve Hay wrote:
how can we test if the filehandle is valid then? may be we should skip
that bit altogether? Steve, does it work if you comment out the whole
if (!size) { ... }
block?
No, it doesn't :(
I've removed the size code, too, and the problem is that after the exception
is thrown, neither of the tests in RegistryCooker::read_script apply:
if (ref $@ eq 'APR::Error') {
return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
# oops
}
The actual error code returned by apr_file_open is 720002.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
On Thu, 5 May 2005, Markus Wichitill wrote:
> Steve Hay wrote:
> >>how can we test if the filehandle is valid then? may be we should skip
> >>that bit altogether? Steve, does it work if you comment out the whole
> >>
> >> if (!size) { ... }
> >>
> >>block?
> >
> > No, it doesn't :(
>
> I've removed the size code, too, and the problem is that after the exception
> is thrown, neither of the tests in RegistryCooker::read_script apply:
>
> if (ref $@ eq 'APR::Error') {
> return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
> return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
> # oops
> }
>
> The actual error code returned by apr_file_open is 720002.
>
Does the following fix this?
===
Index: xs/APR/Status/APR__Status.h
===
--- xs/APR/Status/APR__Status.h (revision 168337)
+++ xs/APR/Status/APR__Status.h (working copy)
@@ -16,3 +16,5 @@
#include "apr_errno.h"
#define mpxs_APR__Status_is_EAGAIN APR_STATUS_IS_EAGAIN
+#define mpxs_APR__Status_is_EACCES APR_STATUS_IS_EACCES
+#define mpxs_APR__Status_is_ENOENT APR_STATUS_IS_ENOENT
Index: xs/maps/apr_functions.map
===
--- xs/maps/apr_functions.map (revision 168337)
+++ xs/maps/apr_functions.map (working copy)
@@ -649,3 +649,5 @@
MODULE=APR::Status PREFIX=mpxs_APR__STATUS_
int:DEFINE_is_EAGAIN | | apr_status_t:rc
+ int:DEFINE_is_EACCES | | apr_status_t:rc
+ int:DEFINE_is_ENOENT | | apr_status_t:rc
Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
===
--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (revision 168337)
+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (working copy)
@@ -34,6 +34,7 @@
use Apache2::Access ();
use APR::Table ();
+use APR::Status ();
use ModPerl::Util ();
use ModPerl::Global ();
@@ -41,7 +42,6 @@
use File::Spec::Functions ();
use File::Basename;
-use APR::Const -compile => qw(EACCES ENOENT);
use Apache2::Const -compile => qw(:common &OPT_EXECCGI);
use ModPerl::Const -compile => 'EXIT';
@@ -542,8 +542,8 @@
$self->log_error("$@");
if (ref $@ eq 'APR::Error') {
-return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
-return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
+return Apache2::Const::FORBIDDEN if APR::Status::is_EACCES($@);
+return Apache2::Const::NOT_FOUND if APR::Status::is_ENOENT($@);
}
else {
return Apache2::Const::SERVER_ERROR;
--
best regards,
randy
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Randy Kobes wrote:
>On Thu, 5 May 2005, Markus Wichitill wrote:
>
>
>
>>Steve Hay wrote:
>>
>>
how can we test if the filehandle is valid then? may be we should skip
that bit altogether? Steve, does it work if you comment out the whole
if (!size) { ... }
block?
>>>No, it doesn't :(
>>>
>>>
>>I've removed the size code, too, and the problem is that after the exception
>>is thrown, neither of the tests in RegistryCooker::read_script apply:
>>
>> if (ref $@ eq 'APR::Error') {
>> return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
>> return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
>> # oops
>> }
>>
>>The actual error code returned by apr_file_open is 720002.
>>
>>
>>
>
>Does the following fix this?
>
>
No. I was just in the process of trying the same thing myself, but it
doesn't fix it for me :(
>===
>Index: xs/APR/Status/APR__Status.h
>===
>--- xs/APR/Status/APR__Status.h(revision 168337)
>+++ xs/APR/Status/APR__Status.h(working copy)
>@@ -16,3 +16,5 @@
> #include "apr_errno.h"
>
> #define mpxs_APR__Status_is_EAGAIN APR_STATUS_IS_EAGAIN
>+#define mpxs_APR__Status_is_EACCES APR_STATUS_IS_EACCES
>+#define mpxs_APR__Status_is_ENOENT APR_STATUS_IS_ENOENT
>Index: xs/maps/apr_functions.map
>===
>--- xs/maps/apr_functions.map (revision 168337)
>+++ xs/maps/apr_functions.map (working copy)
>@@ -649,3 +649,5 @@
>
> MODULE=APR::Status PREFIX=mpxs_APR__STATUS_
> int:DEFINE_is_EAGAIN | | apr_status_t:rc
>+ int:DEFINE_is_EACCES | | apr_status_t:rc
>+ int:DEFINE_is_ENOENT | | apr_status_t:rc
>Index: ModPerl-Registry/lib/ModPerl/RegistryCooker.pm
>===
>--- ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (revision 168337)
>+++ ModPerl-Registry/lib/ModPerl/RegistryCooker.pm (working copy)
>@@ -34,6 +34,7 @@
> use Apache2::Access ();
>
> use APR::Table ();
>+use APR::Status ();
>
> use ModPerl::Util ();
> use ModPerl::Global ();
>@@ -41,7 +42,6 @@
> use File::Spec::Functions ();
> use File::Basename;
>
>-use APR::Const -compile => qw(EACCES ENOENT);
> use Apache2::Const -compile => qw(:common &OPT_EXECCGI);
> use ModPerl::Const -compile => 'EXIT';
>
>@@ -542,8 +542,8 @@
> $self->log_error("$@");
>
> if (ref $@ eq 'APR::Error') {
>-return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
>-return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
>+return Apache2::Const::FORBIDDEN if APR::Status::is_EACCES($@);
>+return Apache2::Const::NOT_FOUND if APR::Status::is_ENOENT($@);
> }
> else {
> return Apache2::Const::SERVER_ERROR;
>
>
>
>
>
Radan Computational Ltd.
The information contained in this message and any files transmitted with it are
confidential and intended for the addressee(s) only. If you have received this
message in error or there are any problems, please notify the sender
immediately. The unauthorized use, disclosure, copying or alteration of this
message is strictly forbidden. Note that any views or opinions presented in
this email are solely those of the author and do not necessarily represent
those of Radan Computational Ltd. The recipient(s) of this message should
check it and any attached files for viruses: Radan Computational will accept no
liability for any damage caused by any virus transmitted by this email.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Steve Hay wrote:
I've removed the size code, too, and the problem is that after the exception
is thrown, neither of the tests in RegistryCooker::read_script apply:
if (ref $@ eq 'APR::Error') {
return Apache2::Const::FORBIDDEN if $@ == APR::Const::EACCES;
return Apache2::Const::NOT_FOUND if $@ == APR::Const::ENOENT;
# oops
}
The actual error code returned by apr_file_open is 720002.
Does the following fix this?
No. I was just in the process of trying the same thing myself, but it
doesn't fix it for me :(
Works for me, though.
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
On Thu, 5 May 2005, Steve Hay wrote: > Randy Kobes wrote: > > >On Thu, 5 May 2005, Markus Wichitill wrote: [ ... ] > >>The actual error code returned by apr_file_open is 720002. > > > >Does the following fix this? > > > No. I was just in the process of trying the same thing > myself, but it doesn't fix it for me :( You probably have to 'nmake clean', then rebuild, for these changes to propagate - does that work? -- best regards, randy
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Randy Kobes wrote: >On Thu, 5 May 2005, Steve Hay wrote: > > > >>Randy Kobes wrote: >> >> >> >>>On Thu, 5 May 2005, Markus Wichitill wrote: >>> >>> >[ ... ] > > The actual error code returned by apr_file_open is 720002. >>>Does the following fix this? >>> >>> >>> >>No. I was just in the process of trying the same thing >>myself, but it doesn't fix it for me :( >> >> > >You probably have to 'nmake clean', then rebuild, for these >changes to propagate - does that work? > No :-s Just did a complete rebuild: Extracted RC6 afresh, applied your patch again. Double-checked it applied correctly. Retested. Still get the same two test failures. Now I'm really confused. If I have a chance tomorrow, I'll have a closer look at what the offending $@ is on my system, but I'm off now... Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.
[mp1] binmode(STDOUT, ':utf8') fails silently
Hi, I'm trying to set binmode(STDOUT, ':utf8') from within a PerlRun script (mod_perl 1.29, apache 1.3.29, perl 5.8.6), and it's failing (returning undef) without setting $!, as the docs claim it should. I really shouldn't even have to do this at all, since I'm already setting Content-type: text/html; charset=UTF-8 as the header, at the start of the document AND, just to be thorough, in the section of all my generated HTML. When I invoke my script at the command line, the output shows up in the terminal with the proper unicode characters. Málaga is Málaga. But the same script, when run by mod_perl, sends "Málaga" to the browser instead. Why is this, and why is it that the only obvious workaround, binmode(), has decided to quietly quit? (and yes, I'm setting binmode() before using print() for for the first time). Let me know if that's not enough information. Unfortunately I cannot post the entire script in a public forum.
Re: [mp1] binmode(STDOUT, ':utf8') fails silently
Ha, nevermind, I figured it out. Turns out that when a param was sent to the script indicating a cookie should be changed, it was using CGI's header() function to generate the header rather than my header text. Adding -charset => 'UTF-8' to header() did the trick, naturally. Still curious about binmode(), though; is there some mod_perl-specific reason that it would fail? Brian Dimeler wrote: Hi, I'm trying to set binmode(STDOUT, ':utf8') from within a PerlRun script (mod_perl 1.29, apache 1.3.29, perl 5.8.6), and it's failing (returning undef) without setting $!, as the docs claim it should. I really shouldn't even have to do this at all, since I'm already setting Content-type: text/html; charset=UTF-8 as the header, at the start of the document AND, just to be thorough, in the section of all my generated HTML. When I invoke my script at the command line, the output shows up in the terminal with the proper unicode characters. Málaga is Málaga. But the same script, when run by mod_perl, sends "Málaga" to the browser instead. Why is this, and why is it that the only obvious workaround, binmode(), has decided to quietly quit? (and yes, I'm setting binmode() before using print() for for the first time). Let me know if that's not enough information. Unfortunately I cannot post the entire script in a public forum.
Re: [mp1] binmode(STDOUT, ':utf8') fails silently
Brian Dimeler wrote: Ha, nevermind, I figured it out. Turns out that when a param was sent to the script indicating a cookie should be changed, it was using CGI's header() function to generate the header rather than my header text. Adding -charset => 'UTF-8' to header() did the trick, naturally. Still curious about binmode(), though; is there some mod_perl-specific reason that it would fail? Under mod_perl 1.x, binmode() is just a stub that does nothing. Should probably be fixed to return true. It's under mod_perl 2.x where things get really interesting. There you have tied IO or PerlIO, and actually need to call binmode(). And calling it just before the first print() doesn't seem always enough either, I had to move it rather close to the script start.
Re: [mp2] modperl2 compile error
Marc GrÃcia wrote: El dl 02 de 05 del 2005 a les 10:05 -0700, en/na Stas Bekman va escriure: Marc GrÃcia wrote: I had some problems like this on my new x86_64 machine with mod_perl2, seems that not only perl must be compiled with -fPIC , also apache and all libraries or modules you plan to use. I think it's a general issue with this architecture, not mod_perl related. That's correct, Marc. If not, there are runtime linking relocation errors everywhere.. (I also had to recompile with -fPIC db and libz, for example) Maybe that's the problem... I supposed that Tom has recompiled everything after rebuilding perl. mod_perl will pick up -fPIC automatically at compile time, if perl was compiled with it. Yes that's Ok for all perl modules. But BTW, my Perl Compilation did not put automaticaly the -fPIC flag when configuring and also didn't detect the needed libraries (The line when Config script lets you add additional libraries was empty except for the ones i compiled for myself, see below). I had to put all that manually (After a lot of recompilations trying to find what was happening) I was using a closed environment in a user with no root permissions. All dependencies except most basic ones (libc,lpthreads,etc..) are compiled and self contained in the user's home (I'm doing a untar-and-forget instalation for our product). The same procedure went OK on all other kind of machines... so maybe perl Config has some problem with x86_64. The base system was a Fedora Core 3 EM64T version with no 32bits compatibility packages installed. But everything is running OK after all, only the Configure script failed.. Marc, you may want to ask perl5-porters to help you with this issue. As you have figured out, mod_perl just picks perl's flags, so it's a perl 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
Re: [ANNOUNCE] mod_perl 2.0.0-RC6
Randy Kobes wrote: [...] Does the following fix this? === Index: xs/APR/Status/APR__Status.h === --- xs/APR/Status/APR__Status.h (revision 168337) +++ xs/APR/Status/APR__Status.h (working copy) @@ -16,3 +16,5 @@ #include "apr_errno.h" #define mpxs_APR__Status_is_EAGAIN APR_STATUS_IS_EAGAIN +#define mpxs_APR__Status_is_EACCES APR_STATUS_IS_EACCES +#define mpxs_APR__Status_is_ENOENT APR_STATUS_IS_ENOENT +1 Randy, if you spot locations in docs and tests that do a comparison with these two constants, which we will now have right, please adjust those. Thank you! -- __ 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: Having problems with simple threaded perl CGI in mod_perl 1.29 (Apache 1.3.33)
Bill Hess wrote: I am trying to write a simple threaded perl CGI script to run under Apache::Registry on mod_perl 1.29 and Apache 1.3.33. The perl scipt only creates 2 or 3 threads and perform a join() on each one to wait for data each thread returns. The script seems to work fine, returning all the data I expect and all the HTML is generated using CGI.pm, thus rendering a complete and accurate page in a web browser. On the server I get errors in my Apache error_log: [Thu May 5 01:01:03 2005] null: semi-panic: attempt to dup freed string. [Thu May 5 01:01:03 2005] [error] Undefined subroutine &main:: called.\n [Thu May 5 01:01:03 2005] null: semi-panic: attempt to dup freed string. [Thu May 5 01:01:03 2005] [error] Undefined subroutine &main:: called.\n [Thu May 5 01:01:04 2005] [notice] child pid 13166 exit signal Segmentation fault (11), possible coredump in /usr/local/dmx/www Running on RH 9 Linux - Perl 5.8.6, Apache 1.3.33, and mod_perl 1.29 all built by myself from source (not using RPM's) Any Ideas? Thanks... Certainly, Bill. The short answer: mod_perl1 can't be used with perl ithreads. The longer answer: I'm now working on making mp2 thread safe, you can try this branch: https://svn.apache.org/repos/asf/perl/modperl/branches/clone-skip-unstable/ If you are interested I can explain why this is happening, and how we are going to fix it. In any case, at the moment perl threads suck and I won't suggest to use them in production in the general case. It may work for you in certain cases. Try using the threads emulation with Liz's forks.pm from CPAN. -- __ 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: [ANNOUNCE] mod_perl 2.0.0-RC6
On Thu, 5 May 2005, Stas Bekman wrote: > Randy Kobes wrote: > [...] > > Does the following fix this? > > > > === > > Index: xs/APR/Status/APR__Status.h > > === > > --- xs/APR/Status/APR__Status.h (revision 168337) > > +++ xs/APR/Status/APR__Status.h (working copy) > > @@ -16,3 +16,5 @@ > > #include "apr_errno.h" > > > > #define mpxs_APR__Status_is_EAGAIN APR_STATUS_IS_EAGAIN > > +#define mpxs_APR__Status_is_EACCES APR_STATUS_IS_EACCES > > +#define mpxs_APR__Status_is_ENOENT APR_STATUS_IS_ENOENT > > +1 > > Randy, if you spot locations in docs and tests that do a comparison with > these two constants, which we will now have right, please adjust those. > Thank you! Thanks, Stas. I've done that, but unfortunately, like Steve, I'm also finding these 2 tests still have problems :( I'll keep looking ... -- best regards, randy
