Stas Bekman wrote:
So the offending line is:
$string .= Apache::Test::install::nuke_Apache__test_target()
if APACHE_TEST_INSTALL();
You lost the actual constant that it was complaining about ;) I should
have looked closer.
Any change if you replace it with:
if (APACHE_TEST_INSTALL()
OK, I'm convinced on this one. We should add a new entry to
porting/compat.pod then, including you summary above. Should I do that,
or will you handle that.
I'll put it on my ToDo.
I still want to know why PERL5LIB is ignored by perl, I will ask p5p as
perlsec.pod doesn't say anything about it
Geoffrey Young wrote:
again, that's not required and it doesn't work now anyway - if it's
in %ENV it doesn't need to be passed to take effect. at least that's
what my tests show.
That's only true without -T, if -T is on $ENV{PERL5LIB} is ignored.
How about the following compromise: we make a
Steve Hay wrote:
Stas Bekman wrote:
before trying to look at your suggestions I want to have a clear
understanding of the path this roller coaster takes to the failure.
Can you please answer a few of these questions for this trace?
VMem::Free(void * 0x01208d6c) line 208 + 3 bytes
CPerlHost::Fre
again, that's not required and it doesn't work now anyway - if it's in
%ENV it doesn't need to be passed to take effect. at least that's
what my tests show.
That's only true without -T, if -T is on $ENV{PERL5LIB} is ignored.
How about the following compromise: we make a special case for
'Pe
Geoffrey Young wrote:
[...]
I'm not arguing that - if it's in their %ENV then it will be (and is)
respected (within the normal limits of -T, that is).
what I'm suggesting is that we remove PerlSetEnv PERL5LIB as a special
case, the main reason being that PerlSetEnv has the wrong scope for what
Geoffrey Young wrote:
[...]
It had to be fixed locally in mp2 since 5.8.1 has been released
already, meaning that anybody who uses 5.8.1 is vulnerable to this
problem. Hopefully 5.8.2 will get it fixed in perl.
well, I guess that was kinda my question. as an application itself,
perl will alwa
can you explain why this is important? I mean, why does mod_perl need
to know the pid of the parent apache process? or, better, why is it
important that mod_perl take the initiative and fix this. is a
workaround patch in mod_perl core really required? what breaks if we
don't fix it?
if any
Steve Hay wrote:
Stas Bekman wrote:
Steve Hay wrote:
[...]
I suppose we could have Apache::TestSmoke::run_test() look for the
"server is not running" message, and have it just warn about it
rather than error and exit, but there's nearly nothing else after
that anyway so we don't gain much by no
Geoffrey Young wrote:
taken off p5p so I don't look so stupid...
I have a workaround for mp2:
#if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 1
{
#ifdef THREADS_HAVE_PIDS
#ifdef USE_ITHREADS
MP_dSCFG(s);
dTHXa(scfg->mip->parent->perl);
PL_ppid = (IV)
taken off p5p so I don't look so stupid...
I have a workaround for mp2:
#if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 1
{
#ifdef THREADS_HAVE_PIDS
#ifdef USE_ITHREADS
MP_dSCFG(s);
dTHXa(scfg->mip->parent->perl);
PL_ppid = (IV)getppid();
#endif
#end
Rafael Garcia-Suarez wrote:
Stas Bekman wrote:
It looks like 5.8.1 started to cache ppids in PL_ppid, which wasn't the case
in 5.8.0. When ithreads are enabled the new logic updates PL_ppid in pp_fork,
which now does:
PP(pp_fork)
{
...
#ifdef THREADS_HAVE_PIDS
PL_ppid = (IV)getppid();
#
right. and that was my point all along - (Perl)SetEnv doesn't work in
2.0. it did work in 1.0, but the syntax is funky since you can
PerlSetEnv anywhere, even within a container, so sometimes it works
and sometimes it doesn't, depending on when the one-per-request
processing happens.
it do
Stas Bekman wrote:
> It looks like 5.8.1 started to cache ppids in PL_ppid, which wasn't the case
> in 5.8.0. When ithreads are enabled the new logic updates PL_ppid in pp_fork,
> which now does:
>
> PP(pp_fork)
> {
> ...
> #ifdef THREADS_HAVE_PIDS
> PL_ppid = (IV)getppid();
> #endif
THRE
Steve Hay wrote:
[...]
sub table {
$Table ||= parse_table(\*DATA);
+close DATA;
+return $Table;
}
close DATA? but we have never opened it. What if this handler is
reused second time under the same perl, it'll find the DATA fh closed?
are you sure that this is the right solution?
Geoffrey Young wrote:
in src/modules/perl/mod_perl.c:
/* SetEnv PERL5LIB */
if (!MP_INCPUSH(cld)) {
char *path = (char *)table_get(r->subprocess_env, "PERL5LIB");
if (path) {
perl_inc_unshift(path);
MP_INCPUSH_on(cld);
}
}
right. and
[for modperl dev only]
Stas Bekman wrote:
It looks like 5.8.1 started to cache ppids in PL_ppid, which wasn't the
case in 5.8.0. When ithreads are enabled the new logic updates PL_ppid
in pp_fork, which now does:
BTW, mp1 is not affected, since it doesn't do anything special when threads
are en
Stas Bekman wrote:
Geoffrey Young wrote:
if you're seeing something different but following the same steps,
then we clearly need some tests to flesh this out, though I'm not sure
now how we would undo -T for a single set of tests in the suite.
Sorry, you are right, I was looking at the wrong
Geoffrey Young wrote:
if you're seeing something different but following the same steps, then
we clearly need some tests to flesh this out, though I'm not sure now
how we would undo -T for a single set of tests in the suite.
Sorry, you are right, I was looking at the wrong printout. I did:
Works perfectly fine for me. I removed -T added PerlPassEnv PERL5LIB to
httpd.conf, changed the apr/pool test to dump @INC, run the tests with:
env PERL5LIB=/tmp t/TEST apr/pool
got /tmp printed out.
but that's different - it's already in your environment, so it's available
when the interprete
Randy Kobes wrote:
On Thu, 16 Oct 2003, Philippe M. Chiasson wrote:
On Wed, 2003-10-15 at 12:53, Randy Kobes wrote:
On Wed, 15 Oct 2003, Philippe M. Chiasson wrote:
[ .. ]
Looking at the build system, there seems to still be
code there to build ApacheModulePerl.dll if httpd <
1.3.15. Is that st
On Thu, 16 Oct 2003, Philippe M. Chiasson wrote:
> On Wed, 2003-10-15 at 12:53, Randy Kobes wrote:
> > On Wed, 15 Oct 2003, Philippe M. Chiasson wrote:
[ .. ]
> > > Looking at the build system, there seems to still be
> > > code there to build ApacheModulePerl.dll if httpd <
> > > 1.3.15. Is that
Geoffrey Young wrote:
Stas Bekman wrote:
Geoffrey Young wrote:
and of course need to fix that in mp2.
I'll tacked the mp2 bits this week.
just looking at it now...
it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't
find it in the code and can't get it to work in the te
It looks like 5.8.1 started to cache ppids in PL_ppid, which wasn't the case
in 5.8.0. When ithreads are enabled the new logic updates PL_ppid in pp_fork,
which now does:
PP(pp_fork)
{
...
#ifdef THREADS_HAVE_PIDS
PL_ppid = (IV)getppid();
#endif
...
So if an application running embedded
Stas Bekman wrote:
Geoffrey Young wrote:
and of course need to fix that in mp2.
I'll tacked the mp2 bits this week.
just looking at it now...
it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't find
it in the code and can't get it to work in the tests.
It's not mp2, it's
Geoffrey Young wrote:
and of course need to fix that in mp2.
I'll tacked the mp2 bits this week.
just looking at it now...
it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't find
it in the code and can't get it to work in the tests.
It's not mp2, it's perl. See the last para:
and of course need to fix that in mp2.
I'll tacked the mp2 bits this week.
just looking at it now...
it seems that mp2 doesn't respect (Perl)SetEnv PERL5LIB - I can't find it in
the code and can't get it to work in the tests.
as I looked at implementing it, I can't decide on where to put it, s
On Wed, 2003-10-15 at 12:53, Randy Kobes wrote:
> On Wed, 15 Oct 2003, Philippe M. Chiasson wrote:
>
> > On Tue, 2003-10-14 at 11:40, Randy Kobes wrote:
> > > On Tue, 14 Oct 2003 [EMAIL PROTECTED] wrote:
> > >
> > > > gozer 2003/10/14 11:23:08
> > > >
> > > > Modified:.MANIFEST
Stas Bekman wrote:
Steve Hay wrote:
[...]
I suppose we could have Apache::TestSmoke::run_test() look for the
"server is not running" message, and have it just warn about it
rather than error and exit, but there's nearly nothing else after
that anyway so we don't gain much by not exiting. In fa
Stas Bekman wrote:
Also, can you please get the trace, after commenting out all the
irrelevant config from httpd.conf, leaving only the config needed to
reproduce the problem? It'll make the trace much more useful. Thanks
Steve.
I've reduced the httpd.conf file to just this (!):-
=
LoadMo
Stas Bekman wrote:
Steve Hay wrote:
[...]
I'm trying to figure out why the trace says that the failure is at the
startup, while you say that it fails much later.
What happens if you run Apache.exe -t (or whatever is the win32
equivalent for config check. On my machine that would be:
/home/stas
Stas Bekman wrote:
before trying to look at your suggestions I want to have a clear
understanding of the path this roller coaster takes to the failure.
Can you please answer a few of these questions for this trace?
VMem::Free(void * 0x01208d6c) line 208 + 3 bytes
CPerlHost::Free(void * 0x01208d
Also, can you please get the trace, after commenting out all the irrelevant
config from httpd.conf, leaving only the config needed to reproduce the
problem? It'll make the trace much more useful. Thanks Steve.
__
Stas Bekman
Stas Bekman wrote:
Randy Kobes wrote:
On Wed, 15 Oct 2003, Steve Hay wrote:
Attached is a patch to stop this warning being printed every time I run
"perl Makefile.PL ...":
Use of uninitialized value in concatenation (.) or string at
lib/ModPerl/BuildOptions.pm line 107, line 20.
- Steve
=
34 matches
Mail list logo
