You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Stas Bekman <st...@stason.org> on 2003/03/28 06:08:40 UTC
picking the right mod_perl.so when configuring t/conf/httpd.conf
for 3rd party modules
When running t/TEST -conf we have a potential problem of picking mod_perl.so
built against a different perl. I'm trying to think how to resolve that. Is
there a portable way to run 'ldd', to check the signature? e.g I can do:
/tmp> ldd /home/stas/httpd/prefork/modules/mod_perl.so | grep libperl.so
libperl.so =>
/home/stas/perl/blead-ithread/lib/5.9.0/i686-linux-thread-multi/CORE/libperl.so
(0x40030000)
/tmp> ldd ~/perl/blead-ithread/bin/perl | grep libperl.so
libperl.so =>
/home/stas/perl/blead-ithread/lib/5.9.0/i686-linux-thread-multi/CORE/libperl.so
(0x40014000)
and compare if the two point to the same file.
Alternative solutions I could think of:
- do binary compatibility test at mod_perl.so boot time. How can we do that?
(test the perl version and path to libperl.so?)
sometimes mod_perl.so from the same perl with different parameters (e.g. w/
and w/o ithreads) will boot OK, but won't work. In other cases mod_perl.so
simply won't load, so it'll fail before we can do the testing.
- test the timestamp of the mod_perl.so and mod_perl.pm if they differ wildly
there must a problem. But I guess this approach is not very practical.
- install some signature along with mod_perl.so. e.g. could create an MD5 hash
of libperl.so install it next to mod_perl.so (in mod_perl.sig and check it at
configure time). This looks like a practical solution.
Any other ideas?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 31 Mar 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>
>
>>>- First off, in xs/modperl.def, an entry for MP_debug_level
>>>appears, which the linker can't find when building mod_perl.so.
>>>For Win32, src/modules/perl/modperl_log.h sets MP_debug_level
>>>to modperl_debug_level(), which is in xs/modperl.def. This diff:
>>
>>Ah, I guess since I've used berok on aix this didn't trigger
>>the problem. I've applied a similar fix adding this symbol only
>>when MP_DEBUG=1. Does this work on windows?
>
>
> That works when not building with MP_DEBUG=1, but if you do
> enable MP_DEBUG, it can't find the MP_debug_level symbol in
> modperl.def when building mod_perl.lib. Since for WIN32
> MP_debug_level is defined to be modperl_debug_level, shouldn't
> MP_debug_level be skipped in modperl.def? modperl_debug_level
> does occur in modperl.def.
Ah, of course, I've committed the fix that ensures that. Other platforms may
need that symbol no matter what MP_DEBUG setting is.
Thanks Randy.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 31 Mar 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > - First off, in xs/modperl.def, an entry for MP_debug_level
> > appears, which the linker can't find when building mod_perl.so.
> > For Win32, src/modules/perl/modperl_log.h sets MP_debug_level
> > to modperl_debug_level(), which is in xs/modperl.def. This diff:
>
> Ah, I guess since I've used berok on aix this didn't trigger
> the problem. I've applied a similar fix adding this symbol only
> when MP_DEBUG=1. Does this work on windows?
That works when not building with MP_DEBUG=1, but if you do
enable MP_DEBUG, it can't find the MP_debug_level symbol in
modperl.def when building mod_perl.lib. Since for WIN32
MP_debug_level is defined to be modperl_debug_level, shouldn't
MP_debug_level be skipped in modperl.def? modperl_debug_level
does occur in modperl.def.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 31 Mar 2003, Stas Bekman wrote:
> Randy Kobes wrote:
[ .. ]
> > - secondly, there's a problem in starting the tests, with a free
> > to a wrong pool and then an access violation in the perl58 lib.
> > No error log is created, but I've attached a trace from enabling
> > PerlTrace All in httpd.conf. This problem arose in the last week
> > or so - I'll look into this later when I get a chance to rebuild
> > Perl/Apache with debugging enabled.
>
> I've just built the worker on linux, but haven't seen any problems.
>
> I think the only change in that area was a move of mips
> intialization to an earlier stage, before any modules or files
> are required.
It looks like this problem (Win32, perl-5.8.0, Apache 2.0.45, cvs
modperl-2.0) relates to t/response/TestDirective/perlrequire.pm,
particularly the presence of PerlOptions +Parent in the
configuration appearing there. If I comment out this
PerlOptions +Parent in the generated httpd.conf, then
all tests pass, save for one of t/directive/perlrequire.t,
which I guess is expected.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> I haven't tested the worker-mpm for a while and now that I did, there
> are segfaults here and there (different with 5.8.0 and blead-perl). I'll
> investigate these next week and hopefully they will trigger similar
> problems to yours).
I spent a whole lot of time trying to debug misterious segfaults, just to
discover by an accident that I had worker mod_perl.so loading prefork Foo.so
modules and of course since the structs are different I was getting this problems.
I'm thinking to add binary compatibility checks to the boot sections of the
.so modules.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
>
> Have you overridden the map_to_storage hook?
As Randy replied he sees the same problem with both versions. It also seems to
be non-specific to mod_perl.
The problem disappears if we supply ap_hook_translate_name which sets r->filename.
#XXX: temp workaround, core_translate trips on :'s
if (Apache::TestConfig::WIN32()) {
if ($uri =~ m,^/Test[A-Z]\w+::,) {
$r->filename(__FILE__);
return Apache::OK;
}
}
But this is not a proper solution.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
>
> Have you overridden the map_to_storage hook?
As Randy replied he sees the same problem with both versions. It also seems to
be non-specific to mod_perl.
The problem disappears if we supply ap_hook_translate_name which sets r->filename.
#XXX: temp workaround, core_translate trips on :'s
if (Apache::TestConfig::WIN32()) {
if ($uri =~ m,^/Test[A-Z]\w+::,) {
$r->filename(__FILE__);
return Apache::OK;
}
}
But this is not a proper solution.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
The general issue of ':' in locations happens in both 1.3 and
2.0.
>
> Have you overridden the map_to_storage hook? Several modules
> hook map_to storage; mod_proxy (FIRST) looks for any URI that
> is in proxy space - and sums up the <Proxy > sections for that
> URI, the core (MIDDLE) finds the TRACE requests and finishes
> them up already (nothing more to-do about TRACE after Proxy had
> a chance) and finally VERY_LAST (should have been simply LAST)
> we try the <Directory > and <File > request paths.
>
> It doesn't sound like you are looking at real files, which
> make <Directory > and <Files > sections sort of silly. And
> prone to confusion.
That's right that this wasn't with real files, just virtual
locations. For example, a working location
<Location /hello>
# some directives
</Location>
gives a 403 with the simple change
<Location /hell::o>
# same directives as above
</Location>
but
<Location /hello/hell::o>
# same directives as above
</Location>
works. This is with no physical directory "/hello"
within DocumentRoot.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, William A. Rowe, Jr. wrote:
> Two fast questions;
>
> Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
The general issue of ':' in locations happens in both 1.3 and
2.0.
>
> Have you overridden the map_to_storage hook? Several modules
> hook map_to storage; mod_proxy (FIRST) looks for any URI that
> is in proxy space - and sums up the <Proxy > sections for that
> URI, the core (MIDDLE) finds the TRACE requests and finishes
> them up already (nothing more to-do about TRACE after Proxy had
> a chance) and finally VERY_LAST (should have been simply LAST)
> we try the <Directory > and <File > request paths.
>
> It doesn't sound like you are looking at real files, which
> make <Directory > and <Files > sections sort of silly. And
> prone to confusion.
That's right that this wasn't with real files, just virtual
locations. For example, a working location
<Location /hello>
# some directives
</Location>
gives a 403 with the simple change
<Location /hell::o>
# same directives as above
</Location>
but
<Location /hello/hell::o>
# same directives as above
</Location>
works. This is with no physical directory "/hello"
within DocumentRoot.
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Two fast questions;
Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
Have you overridden the map_to_storage hook? Several modules
hook map_to storage; mod_proxy (FIRST) looks for any URI that is
in proxy space - and sums up the <Proxy > sections for that URI,
the core (MIDDLE) finds the TRACE requests and finishes them up
already (nothing more to-do about TRACE after Proxy had a chance)
and finally VERY_LAST (should have been simply LAST) we try the
<Directory > and <File > request paths.
It doesn't sound like you are looking at real files, which make
<Directory > and <Files > sections sort of silly. And prone to confusion.
Try putting a map_to_storage hook MIDDLE-1 or LAST + 1 - and return
OK if translate_name phase picked up this request as it's own. Otherwise
continue to fall through to <Directory > and <Files > walks.
Note that <Location > happens both before and after map_to_storage.
Nobody can modify those phases in map_to_storage
Bill
At 11:50 PM 4/13/2003, Randy Kobes wrote:
>On 14 Apr 2003, Joe Schaefer wrote:
>
>> I'd bet apache is just returning a 403 for security purposes,
>> since ':' is what separates the drive letter from the file path
>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>> full answer, so you might want to take this issue up on
>> dev@httpd.
>
>That looks like it's probably it - there's some discussions in
>the httpd-dev list that were along these lines. Further to this,
>a location like
> <Location /hello/hell::o>
> ....
> </Location>
>does work - what might be happening is Win32 Apache is rejecting,
>via the 403, anything that looks like a leading drive
>designation, for security purposes.
>
>So it's probably easier to just s!::!-! or s!::!/!, as
>Stas proposed ...
>
>--
>best regards,
>randy
Re: [win32] Locations in Apache-Test framework
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Two fast questions;
Is this 1.3 or 2.0 (I'm presuming 2.0 in the second point below...)
Have you overridden the map_to_storage hook? Several modules
hook map_to storage; mod_proxy (FIRST) looks for any URI that is
in proxy space - and sums up the <Proxy > sections for that URI,
the core (MIDDLE) finds the TRACE requests and finishes them up
already (nothing more to-do about TRACE after Proxy had a chance)
and finally VERY_LAST (should have been simply LAST) we try the
<Directory > and <File > request paths.
It doesn't sound like you are looking at real files, which make
<Directory > and <Files > sections sort of silly. And prone to confusion.
Try putting a map_to_storage hook MIDDLE-1 or LAST + 1 - and return
OK if translate_name phase picked up this request as it's own. Otherwise
continue to fall through to <Directory > and <Files > walks.
Note that <Location > happens both before and after map_to_storage.
Nobody can modify those phases in map_to_storage
Bill
At 11:50 PM 4/13/2003, Randy Kobes wrote:
>On 14 Apr 2003, Joe Schaefer wrote:
>
>> I'd bet apache is just returning a 403 for security purposes,
>> since ':' is what separates the drive letter from the file path
>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>> full answer, so you might want to take this issue up on
>> dev@httpd.
>
>That looks like it's probably it - there's some discussions in
>the httpd-dev list that were along these lines. Further to this,
>a location like
> <Location /hello/hell::o>
> ....
> </Location>
>does work - what might be happening is Win32 Apache is rejecting,
>via the 403, anything that looks like a leading drive
>designation, for security purposes.
>
>So it's probably easier to just s!::!-! or s!::!/!, as
>Stas proposed ...
>
>--
>best regards,
>randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Fri, 18 Apr 2003, Stas Bekman wrote:
>>
>>
>>> Stas Bekman wrote:
>>>
>>>> Randy Kobes wrote:
>>>>
>>>>
>>>>> On 14 Apr 2003, Joe Schaefer wrote:
>>>>>
>>>>>
>>>>>> I'd bet apache is just returning a 403 for security purposes,
>>>>>> since ':' is what separates the drive letter from the file path
>>>>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>> full answer, so you might want to take this issue up on
>>>>>> dev@httpd.
>>>>>
>>>>>
>>>>> That looks like it's probably it - there's some discussions in
>>>>> the httpd-dev list that were along these lines. Further to this,
>>>>> a location like
>>>>> <Location /hello/hell::o>
>>>>> ....
>>>>> </Location>
>>>>> does work - what might be happening is Win32 Apache is rejecting,
>>>>> via the 403, anything that looks like a leading drive designation,
>>>>> for security purposes.
>>>>
>>>>
>>>> Hmm, is this valid at all on winFU to supply a drive: entry in the
>>>> URI path? I wonder why Apache can't reject paths with : in the first
>>>> segment only if virtual mapping have failed.
>>>>
>>>>
>>>>> So it's probably easier to just s!::!-! or s!::!/!, as
>>>>> Stas proposed ...
>>>>
>>>>
>>>> I think that even though <Location Foo/Bar> is more intuitive,
>>>> <Location Foo-Bar> is less error-prone.
>>>>
>>>> I think <Location Foo/Bar> is potentially error-prone, since if one
>>>> of the test package is 'Foo' we will have a location <Location Foo>
>>>> and then we will get merging with <Location Foo/Bar> something that
>>>> could be undesired.
>>>
>>>
>>> I think that at the end I'm simply going to install a default
>>> TransHandler, semi-transparent to the developer (put it into
>>> the autogenerated httpd.conf), rather than change the URLs.
>>
>>
>>
>> That's certainly the most straightforward thing to do, and less
>> subject to introducing new bugs. One downside though is that if
>> people use the mod_perl tests as a basis for their own
>> installations (which, given the extensive nature, is a wonderful
>> source of examples), they might not realize that it's this
>> TransHandler that makes such locations with ':' in their names
>> work on Win32. And getting 403s isn't the most intuitive error to
>> track down ....
>>
>> I'd be willing to go through the mod_perl 2 tests and track
>> the changes needed to s/::/-/, if that'd be useful ....
>
>
> Thank you, Randy!
>
> Doug suggests to rename as well, though to do it similar to XS naming
> convention so we would do s/::/__/.
>
> I'll take care of the renaming.
>
> I'll also remove the workaround afterwards.
>
> Joe, that means that apreq tests need to be updated as well.
Joe, this is the patch that needs to be applied after you 'cvs up' your
Apache-Test dir. I didn't commit it since I can't test it at this moment,
because I can't build httpd-apreq (will look at it later)
Index: t/apreq/big_input.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/big_input.t,v
retrieving revision 1.1
diff -u -r1.1 big_input.t
--- t/apreq/big_input.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/big_input.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
use Apache::TestUtil;
use Apache::TestRequest qw(GET_BODY POST_BODY);
-my $location = "/TestApReq::big_input";
+my $location = "/TestApReq__big_input";
my @key_len = (5, 100, 305);
my @key_num = (5, 15, 26);
Index: t/apreq/cookie.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/cookie.t,v
retrieving revision 1.1
diff -u -r1.1 cookie.t
--- t/apreq/cookie.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/cookie.t 18 Apr 2003 06:26:24 -0000
@@ -9,7 +9,7 @@
plan tests => 1;
-my $location = "/TestApReq::cookie";
+my $location = "/TestApReq__cookie";
{
# basic param() test
Index: t/apreq/inherit.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/inherit.t,v
retrieving revision 1.1
diff -u -r1.1 inherit.t
--- t/apreq/inherit.t 5 Apr 2003 23:29:37 -0000 1.1
+++ t/apreq/inherit.t 18 Apr 2003 06:26:24 -0000
@@ -7,7 +7,7 @@
use Apache::TestRequest qw(GET_BODY UPLOAD_BODY);
plan tests => 1;
-my $location = "/TestApReq::inherit";
+my $location = "/TestApReq__inherit";
ok t_cmp(<< 'VALUE', GET_BODY($location), "inheritance");
method => GET
VALUE
Index: t/apreq/request.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/request.t,v
retrieving revision 1.1
diff -u -r1.1 request.t
--- t/apreq/request.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/request.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
plan tests => 2;
-my $location = "/TestApReq::request";
+my $location = "/TestApReq__request";
#print GET_BODY $location;
{
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Fri, 18 Apr 2003, Stas Bekman wrote:
>>
>>
>>> Stas Bekman wrote:
>>>
>>>> Randy Kobes wrote:
>>>>
>>>>
>>>>> On 14 Apr 2003, Joe Schaefer wrote:
>>>>>
>>>>>
>>>>>> I'd bet apache is just returning a 403 for security purposes,
>>>>>> since ':' is what separates the drive letter from the file path
>>>>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>> full answer, so you might want to take this issue up on
>>>>>> dev@httpd.
>>>>>
>>>>>
>>>>> That looks like it's probably it - there's some discussions in
>>>>> the httpd-dev list that were along these lines. Further to this,
>>>>> a location like
>>>>> <Location /hello/hell::o>
>>>>> ....
>>>>> </Location>
>>>>> does work - what might be happening is Win32 Apache is rejecting,
>>>>> via the 403, anything that looks like a leading drive designation,
>>>>> for security purposes.
>>>>
>>>>
>>>> Hmm, is this valid at all on winFU to supply a drive: entry in the
>>>> URI path? I wonder why Apache can't reject paths with : in the first
>>>> segment only if virtual mapping have failed.
>>>>
>>>>
>>>>> So it's probably easier to just s!::!-! or s!::!/!, as
>>>>> Stas proposed ...
>>>>
>>>>
>>>> I think that even though <Location Foo/Bar> is more intuitive,
>>>> <Location Foo-Bar> is less error-prone.
>>>>
>>>> I think <Location Foo/Bar> is potentially error-prone, since if one
>>>> of the test package is 'Foo' we will have a location <Location Foo>
>>>> and then we will get merging with <Location Foo/Bar> something that
>>>> could be undesired.
>>>
>>>
>>> I think that at the end I'm simply going to install a default
>>> TransHandler, semi-transparent to the developer (put it into
>>> the autogenerated httpd.conf), rather than change the URLs.
>>
>>
>>
>> That's certainly the most straightforward thing to do, and less
>> subject to introducing new bugs. One downside though is that if
>> people use the mod_perl tests as a basis for their own
>> installations (which, given the extensive nature, is a wonderful
>> source of examples), they might not realize that it's this
>> TransHandler that makes such locations with ':' in their names
>> work on Win32. And getting 403s isn't the most intuitive error to
>> track down ....
>>
>> I'd be willing to go through the mod_perl 2 tests and track
>> the changes needed to s/::/-/, if that'd be useful ....
>
>
> Thank you, Randy!
>
> Doug suggests to rename as well, though to do it similar to XS naming
> convention so we would do s/::/__/.
>
> I'll take care of the renaming.
>
> I'll also remove the workaround afterwards.
>
> Joe, that means that apreq tests need to be updated as well.
Joe, this is the patch that needs to be applied after you 'cvs up' your
Apache-Test dir. I didn't commit it since I can't test it at this moment,
because I can't build httpd-apreq (will look at it later)
Index: t/apreq/big_input.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/big_input.t,v
retrieving revision 1.1
diff -u -r1.1 big_input.t
--- t/apreq/big_input.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/big_input.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
use Apache::TestUtil;
use Apache::TestRequest qw(GET_BODY POST_BODY);
-my $location = "/TestApReq::big_input";
+my $location = "/TestApReq__big_input";
my @key_len = (5, 100, 305);
my @key_num = (5, 15, 26);
Index: t/apreq/cookie.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/cookie.t,v
retrieving revision 1.1
diff -u -r1.1 cookie.t
--- t/apreq/cookie.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/cookie.t 18 Apr 2003 06:26:24 -0000
@@ -9,7 +9,7 @@
plan tests => 1;
-my $location = "/TestApReq::cookie";
+my $location = "/TestApReq__cookie";
{
# basic param() test
Index: t/apreq/inherit.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/inherit.t,v
retrieving revision 1.1
diff -u -r1.1 inherit.t
--- t/apreq/inherit.t 5 Apr 2003 23:29:37 -0000 1.1
+++ t/apreq/inherit.t 18 Apr 2003 06:26:24 -0000
@@ -7,7 +7,7 @@
use Apache::TestRequest qw(GET_BODY UPLOAD_BODY);
plan tests => 1;
-my $location = "/TestApReq::inherit";
+my $location = "/TestApReq__inherit";
ok t_cmp(<< 'VALUE', GET_BODY($location), "inheritance");
method => GET
VALUE
Index: t/apreq/request.t
===================================================================
RCS file: /home/cvs/httpd-apreq/t/apreq/request.t,v
retrieving revision 1.1
diff -u -r1.1 request.t
--- t/apreq/request.t 5 Apr 2002 19:42:20 -0000 1.1
+++ t/apreq/request.t 18 Apr 2003 06:26:24 -0000
@@ -8,7 +8,7 @@
plan tests => 2;
-my $location = "/TestApReq::request";
+my $location = "/TestApReq__request";
#print GET_BODY $location;
{
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 18 Apr 2003, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Randy Kobes wrote:
>>>
>>>
>>>>On 14 Apr 2003, Joe Schaefer wrote:
>>>>
>>>>
>>>>>I'd bet apache is just returning a 403 for security purposes,
>>>>>since ':' is what separates the drive letter from the file path
>>>>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>full answer, so you might want to take this issue up on
>>>>>dev@httpd.
>>>>
>>>>That looks like it's probably it - there's some discussions in
>>>>the httpd-dev list that were along these lines. Further to this,
>>>>a location like
>>>> <Location /hello/hell::o>
>>>> ....
>>>> </Location>
>>>>does work - what might be happening is Win32 Apache is rejecting,
>>>>via the 403, anything that looks like a leading drive designation, for
>>>>security purposes.
>>>
>>>Hmm, is this valid at all on winFU to supply a drive: entry in the URI
>>>path? I wonder why Apache can't reject paths with : in the first segment
>>>only if virtual mapping have failed.
>>>
>>>
>>>>So it's probably easier to just s!::!-! or s!::!/!, as
>>>>Stas proposed ...
>>>
>>>I think that even though <Location Foo/Bar> is more intuitive,
>>><Location Foo-Bar> is less error-prone.
>>>
>>>I think <Location Foo/Bar> is potentially error-prone, since if one of
>>>the test package is 'Foo' we will have a location <Location Foo> and
>>>then we will get merging with <Location Foo/Bar> something that could be
>>>undesired.
>>
>>I think that at the end I'm simply going to install a default
>>TransHandler, semi-transparent to the developer (put it into
>>the autogenerated httpd.conf), rather than change the URLs.
>
>
> That's certainly the most straightforward thing to do, and less
> subject to introducing new bugs. One downside though is that if
> people use the mod_perl tests as a basis for their own
> installations (which, given the extensive nature, is a wonderful
> source of examples), they might not realize that it's this
> TransHandler that makes such locations with ':' in their names
> work on Win32. And getting 403s isn't the most intuitive error to
> track down ....
>
> I'd be willing to go through the mod_perl 2 tests and track
> the changes needed to s/::/-/, if that'd be useful ....
Thank you, Randy!
Doug suggests to rename as well, though to do it similar to XS naming
convention so we would do s/::/__/.
I'll take care of the renaming.
I'll also remove the workaround afterwards.
Joe, that means that apreq tests need to be updated as well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Fri, 18 Apr 2003, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>Randy Kobes wrote:
>>>
>>>
>>>>On 14 Apr 2003, Joe Schaefer wrote:
>>>>
>>>>
>>>>>I'd bet apache is just returning a 403 for security purposes,
>>>>>since ':' is what separates the drive letter from the file path
>>>>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>>>>full answer, so you might want to take this issue up on
>>>>>dev@httpd.
>>>>
>>>>That looks like it's probably it - there's some discussions in
>>>>the httpd-dev list that were along these lines. Further to this,
>>>>a location like
>>>> <Location /hello/hell::o>
>>>> ....
>>>> </Location>
>>>>does work - what might be happening is Win32 Apache is rejecting,
>>>>via the 403, anything that looks like a leading drive designation, for
>>>>security purposes.
>>>
>>>Hmm, is this valid at all on winFU to supply a drive: entry in the URI
>>>path? I wonder why Apache can't reject paths with : in the first segment
>>>only if virtual mapping have failed.
>>>
>>>
>>>>So it's probably easier to just s!::!-! or s!::!/!, as
>>>>Stas proposed ...
>>>
>>>I think that even though <Location Foo/Bar> is more intuitive,
>>><Location Foo-Bar> is less error-prone.
>>>
>>>I think <Location Foo/Bar> is potentially error-prone, since if one of
>>>the test package is 'Foo' we will have a location <Location Foo> and
>>>then we will get merging with <Location Foo/Bar> something that could be
>>>undesired.
>>
>>I think that at the end I'm simply going to install a default
>>TransHandler, semi-transparent to the developer (put it into
>>the autogenerated httpd.conf), rather than change the URLs.
>
>
> That's certainly the most straightforward thing to do, and less
> subject to introducing new bugs. One downside though is that if
> people use the mod_perl tests as a basis for their own
> installations (which, given the extensive nature, is a wonderful
> source of examples), they might not realize that it's this
> TransHandler that makes such locations with ':' in their names
> work on Win32. And getting 403s isn't the most intuitive error to
> track down ....
>
> I'd be willing to go through the mod_perl 2 tests and track
> the changes needed to s/::/-/, if that'd be useful ....
Thank you, Randy!
Doug suggests to rename as well, though to do it similar to XS naming
convention so we would do s/::/__/.
I'll take care of the renaming.
I'll also remove the workaround afterwards.
Joe, that means that apreq tests need to be updated as well.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 18 Apr 2003, Stas Bekman wrote:
> Stas Bekman wrote:
> > Randy Kobes wrote:
> >
> >> On 14 Apr 2003, Joe Schaefer wrote:
> >>
> >>> I'd bet apache is just returning a 403 for security purposes,
> >>> since ':' is what separates the drive letter from the file path
> >>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> >>> full answer, so you might want to take this issue up on
> >>> dev@httpd.
> >>
> >> That looks like it's probably it - there's some discussions in
> >> the httpd-dev list that were along these lines. Further to this,
> >> a location like
> >> <Location /hello/hell::o>
> >> ....
> >> </Location>
> >> does work - what might be happening is Win32 Apache is rejecting,
> >> via the 403, anything that looks like a leading drive designation, for
> >> security purposes.
> >
> > Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> > path? I wonder why Apache can't reject paths with : in the first segment
> > only if virtual mapping have failed.
> >
> >> So it's probably easier to just s!::!-! or s!::!/!, as
> >> Stas proposed ...
> >
> > I think that even though <Location Foo/Bar> is more intuitive,
> > <Location Foo-Bar> is less error-prone.
> >
> > I think <Location Foo/Bar> is potentially error-prone, since if one of
> > the test package is 'Foo' we will have a location <Location Foo> and
> > then we will get merging with <Location Foo/Bar> something that could be
> > undesired.
>
> I think that at the end I'm simply going to install a default
> TransHandler, semi-transparent to the developer (put it into
> the autogenerated httpd.conf), rather than change the URLs.
That's certainly the most straightforward thing to do, and less
subject to introducing new bugs. One downside though is that if
people use the mod_perl tests as a basis for their own
installations (which, given the extensive nature, is a wonderful
source of examples), they might not realize that it's this
TransHandler that makes such locations with ':' in their names
work on Win32. And getting 403s isn't the most intuitive error to
track down ....
I'd be willing to go through the mod_perl 2 tests and track
the changes needed to s/::/-/, if that'd be useful ....
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 18 Apr 2003, Stas Bekman wrote:
> Stas Bekman wrote:
> > Randy Kobes wrote:
> >
> >> On 14 Apr 2003, Joe Schaefer wrote:
> >>
> >>> I'd bet apache is just returning a 403 for security purposes,
> >>> since ':' is what separates the drive letter from the file path
> >>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> >>> full answer, so you might want to take this issue up on
> >>> dev@httpd.
> >>
> >> That looks like it's probably it - there's some discussions in
> >> the httpd-dev list that were along these lines. Further to this,
> >> a location like
> >> <Location /hello/hell::o>
> >> ....
> >> </Location>
> >> does work - what might be happening is Win32 Apache is rejecting,
> >> via the 403, anything that looks like a leading drive designation, for
> >> security purposes.
> >
> > Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> > path? I wonder why Apache can't reject paths with : in the first segment
> > only if virtual mapping have failed.
> >
> >> So it's probably easier to just s!::!-! or s!::!/!, as
> >> Stas proposed ...
> >
> > I think that even though <Location Foo/Bar> is more intuitive,
> > <Location Foo-Bar> is less error-prone.
> >
> > I think <Location Foo/Bar> is potentially error-prone, since if one of
> > the test package is 'Foo' we will have a location <Location Foo> and
> > then we will get merging with <Location Foo/Bar> something that could be
> > undesired.
>
> I think that at the end I'm simply going to install a default
> TransHandler, semi-transparent to the developer (put it into
> the autogenerated httpd.conf), rather than change the URLs.
That's certainly the most straightforward thing to do, and less
subject to introducing new bugs. One downside though is that if
people use the mod_perl tests as a basis for their own
installations (which, given the extensive nature, is a wonderful
source of examples), they might not realize that it's this
TransHandler that makes such locations with ':' in their names
work on Win32. And getting 403s isn't the most intuitive error to
track down ....
I'd be willing to go through the mod_perl 2 tests and track
the changes needed to s/::/-/, if that'd be useful ....
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On 14 Apr 2003, Joe Schaefer wrote:
>>
>>
>>> I'd bet apache is just returning a 403 for security purposes,
>>> since ':' is what separates the drive letter from the file path
>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>> full answer, so you might want to take this issue up on
>>> dev@httpd.
>>
>>
>>
>> That looks like it's probably it - there's some discussions in
>> the httpd-dev list that were along these lines. Further to this,
>> a location like
>> <Location /hello/hell::o>
>> ....
>> </Location>
>> does work - what might be happening is Win32 Apache is rejecting,
>> via the 403, anything that looks like a leading drive designation, for
>> security purposes.
>
>
> Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> path? I wonder why Apache can't reject paths with : in the first segment
> only if virtual mapping have failed.
>
>> So it's probably easier to just s!::!-! or s!::!/!, as
>> Stas proposed ...
>
>
> I think that even though <Location Foo/Bar> is more intuitive,
> <Location Foo-Bar> is less error-prone.
>
> I think <Location Foo/Bar> is potentially error-prone, since if one of
> the test package is 'Foo' we will have a location <Location Foo> and
> then we will get merging with <Location Foo/Bar> something that could be
> undesired.
I think that at the end I'm simply going to install a default TransHandler,
semi-transparent to the developer (put it into the autogenerated httpd.conf),
rather than change the URLs.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On 14 Apr 2003, Joe Schaefer wrote:
>>
>>
>>> I'd bet apache is just returning a 403 for security purposes,
>>> since ':' is what separates the drive letter from the file path
>>> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>> full answer, so you might want to take this issue up on
>>> dev@httpd.
>>
>>
>>
>> That looks like it's probably it - there's some discussions in
>> the httpd-dev list that were along these lines. Further to this,
>> a location like
>> <Location /hello/hell::o>
>> ....
>> </Location>
>> does work - what might be happening is Win32 Apache is rejecting,
>> via the 403, anything that looks like a leading drive designation, for
>> security purposes.
>
>
> Hmm, is this valid at all on winFU to supply a drive: entry in the URI
> path? I wonder why Apache can't reject paths with : in the first segment
> only if virtual mapping have failed.
>
>> So it's probably easier to just s!::!-! or s!::!/!, as
>> Stas proposed ...
>
>
> I think that even though <Location Foo/Bar> is more intuitive,
> <Location Foo-Bar> is less error-prone.
>
> I think <Location Foo/Bar> is potentially error-prone, since if one of
> the test package is 'Foo' we will have a location <Location Foo> and
> then we will get merging with <Location Foo/Bar> something that could be
> undesired.
I think that at the end I'm simply going to install a default TransHandler,
semi-transparent to the developer (put it into the autogenerated httpd.conf),
rather than change the URLs.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On 14 Apr 2003, Joe Schaefer wrote:
>
>
>>I'd bet apache is just returning a 403 for security purposes,
>>since ':' is what separates the drive letter from the file path
>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>full answer, so you might want to take this issue up on
>>dev@httpd.
>
>
> That looks like it's probably it - there's some discussions in
> the httpd-dev list that were along these lines. Further to this,
> a location like
> <Location /hello/hell::o>
> ....
> </Location>
> does work - what might be happening is Win32 Apache is rejecting,
> via the 403, anything that looks like a leading drive
> designation, for security purposes.
Hmm, is this valid at all on winFU to supply a drive: entry in the URI path? I
wonder why Apache can't reject paths with : in the first segment only if
virtual mapping have failed.
> So it's probably easier to just s!::!-! or s!::!/!, as
> Stas proposed ...
I think that even though <Location Foo/Bar> is more intuitive,
<Location Foo-Bar> is less error-prone.
I think <Location Foo/Bar> is potentially error-prone, since if one of the
test package is 'Foo' we will have a location <Location Foo> and then we will
get merging with <Location Foo/Bar> something that could be undesired.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On 14 Apr 2003, Joe Schaefer wrote:
>
>
>>I'd bet apache is just returning a 403 for security purposes,
>>since ':' is what separates the drive letter from the file path
>>on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
>>full answer, so you might want to take this issue up on
>>dev@httpd.
>
>
> That looks like it's probably it - there's some discussions in
> the httpd-dev list that were along these lines. Further to this,
> a location like
> <Location /hello/hell::o>
> ....
> </Location>
> does work - what might be happening is Win32 Apache is rejecting,
> via the 403, anything that looks like a leading drive
> designation, for security purposes.
Hmm, is this valid at all on winFU to supply a drive: entry in the URI path? I
wonder why Apache can't reject paths with : in the first segment only if
virtual mapping have failed.
> So it's probably easier to just s!::!-! or s!::!/!, as
> Stas proposed ...
I think that even though <Location Foo/Bar> is more intuitive,
<Location Foo-Bar> is less error-prone.
I think <Location Foo/Bar> is potentially error-prone, since if one of the
test package is 'Foo' we will have a location <Location Foo> and then we will
get merging with <Location Foo/Bar> something that could be undesired.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On 14 Apr 2003, Joe Schaefer wrote:
> I'd bet apache is just returning a 403 for security purposes,
> since ':' is what separates the drive letter from the file path
> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> full answer, so you might want to take this issue up on
> dev@httpd.
That looks like it's probably it - there's some discussions in
the httpd-dev list that were along these lines. Further to this,
a location like
<Location /hello/hell::o>
....
</Location>
does work - what might be happening is Win32 Apache is rejecting,
via the 403, anything that looks like a leading drive
designation, for security purposes.
So it's probably easier to just s!::!-! or s!::!/!, as
Stas proposed ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On 14 Apr 2003, Joe Schaefer wrote:
> I'd bet apache is just returning a 403 for security purposes,
> since ':' is what separates the drive letter from the file path
> on Windows. Superman^H^H^H^H^H^HWilliam Rowe probably knows the
> full answer, so you might want to take this issue up on
> dev@httpd.
That looks like it's probably it - there's some discussions in
the httpd-dev list that were along these lines. Further to this,
a location like
<Location /hello/hell::o>
....
</Location>
does work - what might be happening is Win32 Apache is rejecting,
via the 403, anything that looks like a leading drive
designation, for security purposes.
So it's probably easier to just s!::!-! or s!::!/!, as
Stas proposed ...
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Somebody will probably have a reason why ':' is invalid in uri path ;)
I'd bet apache is just returning a 403 for security purposes, since ':'
is what separates the drive letter from the file path on Windows.
Superman^H^H^H^H^H^HWilliam Rowe probably knows the full answer, so you
might want to take this issue up on dev@httpd.
> So, we are stuck with the current situation no matter what would be
> the outcome of this issue. Randy suggests to s/::/-/. Any other
> suggestions? I thought it'd be nicer to s|::|/| so it better maps to
> the file, but it's probably a bad idea for possible overlaps of
> handlers within the same top-level namespace (error-prone).
>
> Unless somebody thinks that s/::/-/ is not good enough we will go with
> this change.
+1 to eliminating ':' from the test locations; I don't have a
preference on '-' vs '/' though.
--
Joe Schaefer
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
> Somebody will probably have a reason why ':' is invalid in uri path ;)
I'd bet apache is just returning a 403 for security purposes, since ':'
is what separates the drive letter from the file path on Windows.
Superman^H^H^H^H^H^HWilliam Rowe probably knows the full answer, so you
might want to take this issue up on dev@httpd.
> So, we are stuck with the current situation no matter what would be
> the outcome of this issue. Randy suggests to s/::/-/. Any other
> suggestions? I thought it'd be nicer to s|::|/| so it better maps to
> the file, but it's probably a bad idea for possible overlaps of
> handlers within the same top-level namespace (error-prone).
>
> Unless somebody thinks that s/::/-/ is not good enough we will go with
> this change.
+1 to eliminating ':' from the test locations; I don't have a
preference on '-' vs '/' though.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 14 Apr 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>>
>>>On Mon, 14 Apr 2003, Stas Bekman wrote:
>>>
>>>[ .. ]
>>>
>>>
>>>>Randy, what happens if you configure some valid virtual
>>>>resource as foo::bar (outside of Apache::Test) and try
>>>>accessing it? Do you get 403?
>>>
>>>Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
>>>working
>>> <Location /hello>
>>> SetHandler perl-script
>>> PerlHandler Apache::Hello
>>> </Location>
>>>(PerlResponseHandler for modperl 2) generates a 403 by simply
>>>changing this to, eg, <Location /hel::lo>. For some reason the
>>>modperl 2 tests don't run into this problem - I'll try to see
>>>why.
>>
>>Could it be due to this handler, running for all requests?
>>
>>PerlTransHandler TestHooks::trans
>>
>>May be after calling $r->uri, Apache initializes some data structure, which
>>doesn't cause a latter problem?
>
>
> You're good at this stuff :) Commenting out the PerlTransHandler
> in httpd.conf in the mod_perl 2 tests does lead to the 403 errors
> in tests that successfully run with PerlTransHandler.
I was just looking for something odd that mp2 test suite does ;)
>>>Actually, again on both 1.3.x and 2.0.45, making a request for
>>>http://localhost/foo::bar (where foo::bar doesn't appear in a
>>><Location>) generates a 403, rather than a 404.
>>
>>Randy, can you please run this by httpd-dev? This doesn't seem right.
>>
>>(Certainly we still want to be able to run tests on winFU, but let's first
>>figure out why this thing happens).
>
> I'll do that - I looked for a bug report for this earlier, but
> couldn't find one. And just in case it was some quirk of my
> system, I tried this on f3.freespace.jp, which netcraft reports
> as running Apache/1.3.27 on Win32 - a request there for
> some (presumably) non-existent thing results in a 403 if
> that thing has a ':' in it.
Somebody will probably have a reason why ':' is invalid in uri path ;)
So, we are stuck with the current situation no matter what would be the
outcome of this issue. Randy suggests to s/::/-/. Any other suggestions? I
thought it'd be nicer to s|::|/| so it better maps to the file, but it's
probably a bad idea for possible overlaps of handlers within the same
top-level namespace (error-prone).
Unless somebody thinks that s/::/-/ is not good enough we will go with this
change.
Of course we could also automatically add this handler to the autogenerated
httpd.conf ;)
PerlTransHandler TestHooks::trans "sub handler {shift->uri; return
Apache::DECLINED}"
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 14 Apr 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>>
>>>On Mon, 14 Apr 2003, Stas Bekman wrote:
>>>
>>>[ .. ]
>>>
>>>
>>>>Randy, what happens if you configure some valid virtual
>>>>resource as foo::bar (outside of Apache::Test) and try
>>>>accessing it? Do you get 403?
>>>
>>>Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
>>>working
>>> <Location /hello>
>>> SetHandler perl-script
>>> PerlHandler Apache::Hello
>>> </Location>
>>>(PerlResponseHandler for modperl 2) generates a 403 by simply
>>>changing this to, eg, <Location /hel::lo>. For some reason the
>>>modperl 2 tests don't run into this problem - I'll try to see
>>>why.
>>
>>Could it be due to this handler, running for all requests?
>>
>>PerlTransHandler TestHooks::trans
>>
>>May be after calling $r->uri, Apache initializes some data structure, which
>>doesn't cause a latter problem?
>
>
> You're good at this stuff :) Commenting out the PerlTransHandler
> in httpd.conf in the mod_perl 2 tests does lead to the 403 errors
> in tests that successfully run with PerlTransHandler.
I was just looking for something odd that mp2 test suite does ;)
>>>Actually, again on both 1.3.x and 2.0.45, making a request for
>>>http://localhost/foo::bar (where foo::bar doesn't appear in a
>>><Location>) generates a 403, rather than a 404.
>>
>>Randy, can you please run this by httpd-dev? This doesn't seem right.
>>
>>(Certainly we still want to be able to run tests on winFU, but let's first
>>figure out why this thing happens).
>
> I'll do that - I looked for a bug report for this earlier, but
> couldn't find one. And just in case it was some quirk of my
> system, I tried this on f3.freespace.jp, which netcraft reports
> as running Apache/1.3.27 on Win32 - a request there for
> some (presumably) non-existent thing results in a 403 if
> that thing has a ':' in it.
Somebody will probably have a reason why ':' is invalid in uri path ;)
So, we are stuck with the current situation no matter what would be the
outcome of this issue. Randy suggests to s/::/-/. Any other suggestions? I
thought it'd be nicer to s|::|/| so it better maps to the file, but it's
probably a bad idea for possible overlaps of handlers within the same
top-level namespace (error-prone).
Unless somebody thinks that s/::/-/ is not good enough we will go with this
change.
Of course we could also automatically add this handler to the autogenerated
httpd.conf ;)
PerlTransHandler TestHooks::trans "sub handler {shift->uri; return
Apache::DECLINED}"
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 14 Apr 2003, Stas Bekman wrote:
> >
> > [ .. ]
> >
> >>Randy, what happens if you configure some valid virtual
> >>resource as foo::bar (outside of Apache::Test) and try
> >>accessing it? Do you get 403?
> >
> > Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
> > working
> > <Location /hello>
> > SetHandler perl-script
> > PerlHandler Apache::Hello
> > </Location>
> > (PerlResponseHandler for modperl 2) generates a 403 by simply
> > changing this to, eg, <Location /hel::lo>. For some reason the
> > modperl 2 tests don't run into this problem - I'll try to see
> > why.
>
> Could it be due to this handler, running for all requests?
>
> PerlTransHandler TestHooks::trans
>
> May be after calling $r->uri, Apache initializes some data structure, which
> doesn't cause a latter problem?
You're good at this stuff :) Commenting out the PerlTransHandler
in httpd.conf in the mod_perl 2 tests does lead to the 403 errors
in tests that successfully run with PerlTransHandler.
> > Actually, again on both 1.3.x and 2.0.45, making a request for
> > http://localhost/foo::bar (where foo::bar doesn't appear in a
> > <Location>) generates a 403, rather than a 404.
>
> Randy, can you please run this by httpd-dev? This doesn't seem right.
>
> (Certainly we still want to be able to run tests on winFU, but let's first
> figure out why this thing happens).
I'll do that - I looked for a bug report for this earlier, but
couldn't find one. And just in case it was some quirk of my
system, I tried this on f3.freespace.jp, which netcraft reports
as running Apache/1.3.27 on Win32 - a request there for
some (presumably) non-existent thing results in a 403 if
that thing has a ':' in it.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Mon, 14 Apr 2003, Stas Bekman wrote:
> >
> > [ .. ]
> >
> >>Randy, what happens if you configure some valid virtual
> >>resource as foo::bar (outside of Apache::Test) and try
> >>accessing it? Do you get 403?
> >
> > Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
> > working
> > <Location /hello>
> > SetHandler perl-script
> > PerlHandler Apache::Hello
> > </Location>
> > (PerlResponseHandler for modperl 2) generates a 403 by simply
> > changing this to, eg, <Location /hel::lo>. For some reason the
> > modperl 2 tests don't run into this problem - I'll try to see
> > why.
>
> Could it be due to this handler, running for all requests?
>
> PerlTransHandler TestHooks::trans
>
> May be after calling $r->uri, Apache initializes some data structure, which
> doesn't cause a latter problem?
You're good at this stuff :) Commenting out the PerlTransHandler
in httpd.conf in the mod_perl 2 tests does lead to the 403 errors
in tests that successfully run with PerlTransHandler.
> > Actually, again on both 1.3.x and 2.0.45, making a request for
> > http://localhost/foo::bar (where foo::bar doesn't appear in a
> > <Location>) generates a 403, rather than a 404.
>
> Randy, can you please run this by httpd-dev? This doesn't seem right.
>
> (Certainly we still want to be able to run tests on winFU, but let's first
> figure out why this thing happens).
I'll do that - I looked for a bug report for this earlier, but
couldn't find one. And just in case it was some quirk of my
system, I tried this on f3.freespace.jp, which netcraft reports
as running Apache/1.3.27 on Win32 - a request there for
some (presumably) non-existent thing results in a 403 if
that thing has a ':' in it.
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 14 Apr 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>Randy, what happens if you configure some valid virtual
>>resource as foo::bar (outside of Apache::Test) and try
>>accessing it? Do you get 403?
>
>
> Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
> working
> <Location /hello>
> SetHandler perl-script
> PerlHandler Apache::Hello
> </Location>
> (PerlResponseHandler for modperl 2) generates a 403 by simply
> changing this to, eg, <Location /hel::lo>. For some reason the
> modperl 2 tests don't run into this problem - I'll try to see
> why.
Could it be due to this handler, running for all requests?
PerlTransHandler TestHooks::trans
May be after calling $r->uri, Apache initializes some data structure, which
doesn't cause a latter problem?
> Actually, again on both 1.3.x and 2.0.45, making a request for
> http://localhost/foo::bar (where foo::bar doesn't appear in a
> <Location>) generates a 403, rather than a 404.
Randy, can you please run this by httpd-dev? This doesn't seem right.
(Certainly we still want to be able to run tests on winFU, but let's first
figure out why this thing happens).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 14 Apr 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>Randy, what happens if you configure some valid virtual
>>resource as foo::bar (outside of Apache::Test) and try
>>accessing it? Do you get 403?
>
>
> Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
> working
> <Location /hello>
> SetHandler perl-script
> PerlHandler Apache::Hello
> </Location>
> (PerlResponseHandler for modperl 2) generates a 403 by simply
> changing this to, eg, <Location /hel::lo>. For some reason the
> modperl 2 tests don't run into this problem - I'll try to see
> why.
Could it be due to this handler, running for all requests?
PerlTransHandler TestHooks::trans
May be after calling $r->uri, Apache initializes some data structure, which
doesn't cause a latter problem?
> Actually, again on both 1.3.x and 2.0.45, making a request for
> http://localhost/foo::bar (where foo::bar doesn't appear in a
> <Location>) generates a 403, rather than a 404.
Randy, can you please run this by httpd-dev? This doesn't seem right.
(Certainly we still want to be able to run tests on winFU, but let's first
figure out why this thing happens).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, Stas Bekman wrote:
[ .. ]
> Randy, what happens if you configure some valid virtual
> resource as foo::bar (outside of Apache::Test) and try
> accessing it? Do you get 403?
Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
working
<Location /hello>
SetHandler perl-script
PerlHandler Apache::Hello
</Location>
(PerlResponseHandler for modperl 2) generates a 403 by simply
changing this to, eg, <Location /hel::lo>. For some reason the
modperl 2 tests don't run into this problem - I'll try to see
why.
Actually, again on both 1.3.x and 2.0.45, making a request for
http://localhost/foo::bar (where foo::bar doesn't appear in a
<Location>) generates a 403, rather than a 404.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 14 Apr 2003, Stas Bekman wrote:
[ .. ]
> Randy, what happens if you configure some valid virtual
> resource as foo::bar (outside of Apache::Test) and try
> accessing it? Do you get 403?
Yes I do, with both apache-1.3.27 and httpd-2.0.45 - a
working
<Location /hello>
SetHandler perl-script
PerlHandler Apache::Hello
</Location>
(PerlResponseHandler for modperl 2) generates a 403 by simply
changing this to, eg, <Location /hel::lo>. For some reason the
modperl 2 tests don't run into this problem - I'll try to see
why.
Actually, again on both 1.3.x and 2.0.45, making a request for
http://localhost/foo::bar (where foo::bar doesn't appear in a
<Location>) generates a 403, rather than a 404.
--
best regards,
randy
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
>>This looks like a bug in apreq then.
>
> ^^^^^
>
> ITYM apache-1.3.X on Windows?
Yes.
> In any case, it's
> certainly not apreq that's producing a 403 status.
Right, httpd-test/perl-framework has no <Location foo::bar> entries, so it's
not tested. So it's a bug in apache-1.3 then?
Randy, what happens if you configure some valid virtual resource as foo::bar
(outside of Apache::Test) and try accessing it? Do you get 403?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
>>This looks like a bug in apreq then.
>
> ^^^^^
>
> ITYM apache-1.3.X on Windows?
Yes.
> In any case, it's
> certainly not apreq that's producing a 403 status.
Right, httpd-test/perl-framework has no <Location foo::bar> entries, so it's
not tested. So it's a bug in apache-1.3 then?
Randy, what happens if you configure some valid virtual resource as foo::bar
(outside of Apache::Test) and try accessing it? Do you get 403?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
>
> This looks like a bug in apreq then.
^^^^^
ITYM apache-1.3.X on Windows? In any case, it's
certainly not apreq that's producing a 403 status.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Stas Bekman <st...@stason.org> writes:
[...]
>
> This looks like a bug in apreq then.
^^^^^
ITYM apache-1.3.X on Windows? In any case, it's
certainly not apreq that's producing a 403 status.
--
Joe Schaefer
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
[CC'ing apreq-dev]
Randy Kobes wrote:
> In trying to run the tests under Win32 in httpd-apreq (which are
> being converted over to use the Apache-Test framework), I ran
> into something. At present, under certain conditions some
> <Location > directives will be automatically generated like
> <Location /TestApReq::inherit>
> SetHandler perl-script
> PerlHandler TestApReq::inherit
> </Location>
> Such tests in httpd-apreq generate 403 errors, I think because on
> Win32 colons are invalid in filenames - manually changing the
> location to, eg, TestApReq-inherit, and adjusting the request in
> the corresponding .t file accordingly, gets rid of this error. I
> checked this also happens in my "real" Apache configuration (both
> 1 and 2) - simply changing a working <Location> directive (not
> corresponding to any physical file) to having a colon in the name
> generates an error.
>
> This problem seems subtle ... For one thing, the mod_perl 2 tests
> use this <Location> convention with colons, and they work on
> Win32. So this can be made to work, somehow. Also, I would have
> thought <Location> directives would be checked even before
> filenames - for example, a <Location /hello> takes precedence
> over a physical file @@DocumentRoot@@/hello. But perhaps, for the
> purposes of Apache-Test, these subtelties may be academic - since
> the httpd-apreq tests seem OK, and might be something that a
> typical user might generate, it might save some problems in the
> future to change the <Location> directives to use, eg, '-' rather
> than '::' in the names?
This looks like a bug in apreq then.
':' is a valid character in the path component
http://www.cs.tut.fi/~jkorpela/rfc/2396/full.html#3.3
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [win32] Locations in Apache-Test framework
Posted by Stas Bekman <st...@stason.org>.
[CC'ing apreq-dev]
Randy Kobes wrote:
> In trying to run the tests under Win32 in httpd-apreq (which are
> being converted over to use the Apache-Test framework), I ran
> into something. At present, under certain conditions some
> <Location > directives will be automatically generated like
> <Location /TestApReq::inherit>
> SetHandler perl-script
> PerlHandler TestApReq::inherit
> </Location>
> Such tests in httpd-apreq generate 403 errors, I think because on
> Win32 colons are invalid in filenames - manually changing the
> location to, eg, TestApReq-inherit, and adjusting the request in
> the corresponding .t file accordingly, gets rid of this error. I
> checked this also happens in my "real" Apache configuration (both
> 1 and 2) - simply changing a working <Location> directive (not
> corresponding to any physical file) to having a colon in the name
> generates an error.
>
> This problem seems subtle ... For one thing, the mod_perl 2 tests
> use this <Location> convention with colons, and they work on
> Win32. So this can be made to work, somehow. Also, I would have
> thought <Location> directives would be checked even before
> filenames - for example, a <Location /hello> takes precedence
> over a physical file @@DocumentRoot@@/hello. But perhaps, for the
> purposes of Apache-Test, these subtelties may be academic - since
> the httpd-apreq tests seem OK, and might be something that a
> typical user might generate, it might save some problems in the
> future to change the <Location> directives to use, eg, '-' rather
> than '::' in the names?
This looks like a bug in apreq then.
':' is a valid character in the path component
http://www.cs.tut.fi/~jkorpela/rfc/2396/full.html#3.3
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
[win32] Locations in Apache-Test framework
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
In trying to run the tests under Win32 in httpd-apreq (which are
being converted over to use the Apache-Test framework), I ran
into something. At present, under certain conditions some
<Location > directives will be automatically generated like
<Location /TestApReq::inherit>
SetHandler perl-script
PerlHandler TestApReq::inherit
</Location>
Such tests in httpd-apreq generate 403 errors, I think because on
Win32 colons are invalid in filenames - manually changing the
location to, eg, TestApReq-inherit, and adjusting the request in
the corresponding .t file accordingly, gets rid of this error. I
checked this also happens in my "real" Apache configuration (both
1 and 2) - simply changing a working <Location> directive (not
corresponding to any physical file) to having a colon in the name
generates an error.
This problem seems subtle ... For one thing, the mod_perl 2 tests
use this <Location> convention with colons, and they work on
Win32. So this can be made to work, somehow. Also, I would have
thought <Location> directives would be checked even before
filenames - for example, a <Location /hello> takes precedence
over a physical file @@DocumentRoot@@/hello. But perhaps, for the
purposes of Apache-Test, these subtelties may be academic - since
the httpd-apreq tests seem OK, and might be something that a
typical user might generate, it might save some problems in the
future to change the <Location> directives to use, eg, '-' rather
than '::' in the names?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
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::Free(void * 0x01208d6c) line 59 + 34 bytes
>> PerlMemFree(IPerlMem * 0x01236e7c, void * 0x01208d6c) line 302
>> Perl_safesysfree(void * 0x01208d6c) line 143 + 26 bytes
>> Perl_sv_clear(interpreter * 0x002644c4, sv * 0x00924478) line 5196 +
>> 13 bytes
>> Perl_sv_replace(interpreter * 0x002644c4, sv * 0x00924478, sv *
>> 0x0126ec98) line 5046 + 13 bytes
>>
>> It fails to free 'sv * 0x00924478', any idea what is it? You should be
>> able to peek inside of it using:
>>
>> ((XPV*) (sv)->sv_any )->xpv_pv // 2pvx\n\
>> ((XPVIV*) (sv)->sv_any )->xiv_iv // 2ivx
>>
>> or a global catch-all peek:
>>
>> Perl_sv_peek(my_perl, (SV*)(sv)) // sv_peek
>>
>> replace sv with the name of the variable. You can go up the stack with
>> 'up' in order to look inside that variable.
>
>
> Looks like you've cut-and-pasted that from perlhack, but that seems to
> relate to DDD+gdb. I'm using MSVC++, and have no idea how to do
> anything like that :(
Yup, I added it there ;) ddd rocks!
> Instead, I've done this: (If anyone (Randy?) knows a better way to do
> this, I'd love to hear it!)...
>
> I've inserted:
>
> buf = savepv(SvPVX(sv));
> Safefree(buf);
>
> into Perl_leave_scope(), just above the offending call to
> sv_replace(sv,value) on line 695 of Perl 5.8.1's scope.c, and rebuilt
> Perl and mod_perl.
in the future you can probably just run 'make' and copy the library to where
it should go (will save you the time to recompile things) and you don't need
to recompile mp. that's what I do when I change just a .c file.
> I then find that buf contains "TestHooks::stacked_handlers2::filter" at
> the point where the subsequent call to sv_replace() crashes.
I guess I'll try to analize first your new trace with the minimal config
first, which doesn't involve any of these things, and then come back to this
data after resolving it.
BTW, if you post new traces please drop 'e' since we don't care about env
tracing. I guess this will do: PerlTrace cdghimos (instead of all). That gives
us a much shorter trace.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
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 * 0x01208d6c) line 59 + 34 bytes
> PerlMemFree(IPerlMem * 0x01236e7c, void * 0x01208d6c) line 302
> Perl_safesysfree(void * 0x01208d6c) line 143 + 26 bytes
> Perl_sv_clear(interpreter * 0x002644c4, sv * 0x00924478) line 5196 +
> 13 bytes
> Perl_sv_replace(interpreter * 0x002644c4, sv * 0x00924478, sv *
> 0x0126ec98) line 5046 + 13 bytes
>
> It fails to free 'sv * 0x00924478', any idea what is it? You should be
> able to peek inside of it using:
>
> ((XPV*) (sv)->sv_any )->xpv_pv // 2pvx\n\
> ((XPVIV*) (sv)->sv_any )->xiv_iv // 2ivx
>
> or a global catch-all peek:
>
> Perl_sv_peek(my_perl, (SV*)(sv)) // sv_peek
>
> replace sv with the name of the variable. You can go up the stack with
> 'up' in order to look inside that variable.
Looks like you've cut-and-pasted that from perlhack, but that seems to
relate to DDD+gdb. I'm using MSVC++, and have no idea how to do
anything like that :(
Instead, I've done this: (If anyone (Randy?) knows a better way to do
this, I'd love to hear it!)...
I've inserted:
buf = savepv(SvPVX(sv));
Safefree(buf);
into Perl_leave_scope(), just above the offending call to
sv_replace(sv,value) on line 695 of Perl 5.8.1's scope.c, and rebuilt
Perl and mod_perl.
I then find that buf contains "TestHooks::stacked_handlers2::filter" at
the point where the subsequent call to sv_replace() crashes.
>
>
> Perl_leave_scope(interpreter * 0x002644c4, long 290) line 695 + 17 bytes
> Perl_newATTRSUB(interpreter * 0x002644c4, long 290, op * 0x01386e5c,
> op * 0x00000000, op * 0x00000000, op * 0x01386e7c) line 4402 + 24 bytes
> Perl_utilize(interpreter * 0x002644c4, int 1, long 290, op *
> 0x00000000, op * 0x012970b4, op * 0x00000000) line 2983 + 173 bytes
> Perl_yyparse(interpreter * 0x002644c4) line 414 + 44 bytes
> S_doeval(interpreter * 0x002644c4, int 0, op * * 0x00000000, cv *
> 0x00000000, unsigned long 6743) line 2802 + 9 bytes
> Perl_pp_require(interpreter * 0x002644c4) line 3298 + 102 bytes
> modperl_pp_require(interpreter * 0x002644c4) line 54 + 10 bytes
> Perl_runops_debug(interpreter * 0x002644c4) line 1434 + 13 bytes
> S_call_body(interpreter * 0x002644c4, op * 0x0006f8c8, int 1) line
> 2193 + 13 bytes
> Perl_eval_sv(interpreter * 0x002644c4, sv * 0x01268200, long 2) line
> 2253 + 15 bytes
> modperl_require_module(interpreter * 0x002644c4, const char *
> 0x008ac6c8, int 0) line 13 + 15 bytes
>
> Here we have a new perl interpreter, not the same one as started the
> require. What's inside 'const char * 0x008ac6c8'? what file is it
> loading?
"TestVhost::basic"
>
>
> modperl_cmd_modules(cmd_parms_struct * 0x0006fa14, void * 0x00854718,
> const char * 0x008ac6c8) line 122 + 15 bytes
> invoke_cmd(const command_struct * 0x10025038, cmd_parms_struct *
> 0x0006fa14, void * 0x00854718, const char * 0x008ac558) line 800 + 18
> bytes
> ap_walk_config_sub(const ap_directive_t * 0x008ac528, cmd_parms_struct
> * 0x0006fa14, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
> ap_walk_config(ap_directive_t * 0x008ac528, cmd_parms_struct *
> 0x0006fa14, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
> modperl_config_insert(interpreter * 0x0129104c, server_rec *
> 0x0082c4d8, apr_pool_t * 0x0028ace0, apr_pool_t * 0x00000000, int 150,
> char * 0x00000000, ap_conf_vector_t * 0x0082caa8, sv * 0x013834b8)
> line 443 + 18 bytes
> modperl_config_insert_server(interpreter * 0x0129104c, server_rec *
> 0x0082c4d8, sv * 0x013834b8) line 461 + 36 bytes
> XS_Apache__Server_add_config(interpreter * 0x0129104c, cv *
> 0x012e5338) line 99 + 17 bytes
> Perl_pp_entersub(interpreter * 0x0129104c) line 2817 + 16 bytes
> Perl_runops_debug(interpreter * 0x0129104c) line 1434 + 13 bytes
> S_call_body(interpreter * 0x0129104c, op * 0x0006fbf8, int 1) line
> 2193 + 13 bytes
> Perl_eval_sv(interpreter * 0x0129104c, sv * 0x012a92bc, long 2) line
> 2253 + 15 bytes
> Perl_require_pv(interpreter * 0x0129104c, const char * 0x0088ad20)
> line 2351 + 15 bytes
> modperl_require_file(interpreter * 0x0129104c, const char *
> 0x0088ad20, int 1) line 30 + 13 bytes
>
> what's inside 'const char * 0x0088ad20'?
"conf/modperl_inc.pl"
>
>
> modperl_config_apply_PerlRequire(server_rec * 0x00889e28,
> modperl_config_srv_t * 0x0088a848, interpreter * 0x0129104c,
> apr_pool_t * 0x0028ace0) line 357 + 21 bytes
> modperl_startup(server_rec * 0x00889e28, apr_pool_t * 0x0028ace0) line
> 285 + 21 bytes
> modperl_init_vhost(server_rec * 0x00889e28, apr_pool_t * 0x0028ace0,
> server_rec * 0x0082c4d8) line 355 + 13 bytes
> modperl_init(server_rec * 0x0082c4d8, apr_pool_t * 0x0028ace0) line
> 431 + 17 bytes
> modperl_hook_init(apr_pool_t * 0x0028ace0, apr_pool_t * 0x00000000,
> apr_pool_t * 0x00000000, server_rec * 0x0082c4d8) line 554 + 13 bytes
> modperl_run() line 568 + 21 bytes
> modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void *
> 0x00854718, const char * 0x00864808) line 503
> invoke_cmd(const command_struct * 0x100251b8, cmd_parms_struct *
> 0x0006fec8, void * 0x00854718, const char * 0x00864808) line 713 + 18
> bytes
> ap_walk_config_sub(const ap_directive_t * 0x008647e8, cmd_parms_struct
> * 0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
> ap_walk_config(ap_directive_t * 0x008647e8, cmd_parms_struct *
> 0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
> ap_process_config_tree(server_rec * 0x0082c4d8, ap_directive_t *
> 0x008549e8, apr_pool_t * 0x0028ace0, apr_pool_t * 0x0084c550) line
> 1594 + 20 bytes
> main(int 8, const char * const * 0x00282918) line 582
> mainCRTStartup() line 338 + 17 bytes
> KERNEL32! 77e814c7()
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
>>Yes, that's a known problem in perl threads. Try replacing detach call with join:
>>
>
> Yeah, that fixes it.
Thanks, Steve. I've committed it (to my local rep).
Kurt on the modperl list has just reported a similar problem (free the wrong
pool), looking forward to his details. May be this time I'll be lucky and be
able to reproduce it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>
>>>But I don't get the segfault.
>>>
>>>I'd like to explore the possibility that we have a need for CLONE in Perl
>>>sections and PerlLoadModule next. I wish I had the segfault, though. I need to
>>>think how to create it. But if I fail I'll try to analyze whether we CLONE is
>>>needed. If you don't know what CLONE is please see:
>>>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>>
>>>
>>>
>>I had a look at Example-CLONE. When I run "nmake test" it passes all
>>tests successfully, but then I get an application error popup, and it
>>spits out "A thread exited while 2 threads were running" on the
>>console. It's OK if I run the two tests, basic.t and threads.t,
>>individually.
>>
>>
>
>Yes, that's a known problem in perl threads. Try replacing detach call with join:
>
Yeah, that fixes it.
- Steve
>
>
>Index: t/threads.t
>===================================================================
>RCS file: /home/stas/cvs/modules/Example-CLONE/t/threads.t,v
>retrieving revision 1.1
>diff -u -r1.1 threads.t
>--- t/threads.t 31 Dec 2003 05:40:32 -0000 1.1
>+++ t/threads.t 12 Jan 2004 17:17:25 -0000
>@@ -31,7 +31,7 @@
>
> # as the new threads are spawned they will inherit the count from the
> # main thread
>-threads->new(\&read_test)->detach for 1..$threads;
>+threads->new(\&read_test) for 1..$threads;
>
> sub read_test : locked {
> for my $count (1..2) {
>@@ -42,8 +42,5 @@
> }
> }
>
>-# workaround the situations where the main thread exits before the
>-# child threads, which shouldn't be a problem since all threads are
>-# detached, but something is broken in perl
>-select(undef, undef, undef, 0.25); # sleep 0.25sec
>+$_->join() for threads->list();
>
>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>
>
>
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:44 -0800 1/21/04, Stas Bekman wrote:
>
>>> No, he did say that. ;-)
>>
>> so no problemo then. Go for it Liz.
>
>
> Eh... tuits? I won't have hardly any until at least the summer... ;-(
How about moving to AU, it's summer there already ;)
NZ is another great choice ;)
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:44 -0800 1/21/04, Stas Bekman wrote:
>>No, he did say that. ;-)
>so no problemo then. Go for it Liz.
Eh... tuits? I won't have hardly any until at least the summer... ;-(
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 01:16 -0800 1/21/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>>> I guess I could implement this in my test script using a simple
>>>> semaphore (shared variable), making sure that all callbacks pull
>>>> down that semaphore just before they are done and having the main
>>>> thread block till that semaphore gets to 0. e.g. your Running
>>>> implementation could drop the other dependencies list and just
>>>> override threads::create to wrap it in a semaphore up and down calls
>>>> around the callback.
>>>
>>> Indeed. Don't forget that you need to steal threads::new as well ;-)
>>
>> isn't one the alias of the other?
>
>
> Yes. But if you steal "create" like:
>
> *threads::create = sub {};
>
> then threads::new is still pointing to the old, unwrapped sub. This
> caught me off guard with Thread::Exit as well, as the CHANGELOG will
> tell you... ;-)
Yup ;)
>>> Well, and that's exactly the conundrum: any work done on threads may
>>> well only appear in blead (and not in 5.8.4). How many people use
>>> blead on production systems?
>>
>> I remember sky saying that threads.xs will be released on CPAN. oh was
>> I dreaming
>
>
> No, he did say that. ;-)
so no problemo then. Go for it Liz.
>>> "If you want to block until all threads have finished, you will have
>>> to do it yourself" was Jarkko's decision.
>>
>> OK, I didn't remember that. In which case threads should have
>> running() or similar, but not call it by itself.
>
> ??? You mean, threads::running should exist by default in threads:: ?
I mean the method should be in the core, but only used if called by the user.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 01:16 -0800 1/21/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>>I guess I could implement this in my test script using a simple
>>>semaphore (shared variable), making sure that all callbacks pull
>>>down that semaphore just before they are done and having the main
>>>thread block till that semaphore gets to 0. e.g. your Running
>>>implementation could drop the other dependencies list and just
>>>override threads::create to wrap it in a semaphore up and down
>>>calls around the callback.
>>Indeed. Don't forget that you need to steal threads::new as well ;-)
>isn't one the alias of the other?
Yes. But if you steal "create" like:
*threads::create = sub {};
then threads::new is still pointing to the old, unwrapped sub. This
caught me off guard with Thread::Exit as well, as the CHANGELOG will
tell you... ;-)
>>Well, and that's exactly the conundrum: any work done on threads
>>may well only appear in blead (and not in 5.8.4). How many people
>>use blead on production systems?
>I remember sky saying that threads.xs will be released on CPAN. oh
>was I dreaming
No, he did say that. ;-)
>>"If you want to block until all threads have finished, you will
>>have to do it yourself" was Jarkko's decision.
>OK, I didn't remember that. In which case threads should have
>running() or similar, but not call it by itself.
??? You mean, threads::running should exist by default in threads:: ?
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
>> I guess I could implement this in my test script using a simple
>> semaphore (shared variable), making sure that all callbacks pull down
>> that semaphore just before they are done and having the main thread
>> block till that semaphore gets to 0. e.g. your Running implementation
>> could drop the other dependencies list and just override
>> threads::create to wrap it in a semaphore up and down calls around the
>> callback.
>
>
> Indeed. Don't forget that you need to steal threads::new as well ;-)
isn't one the alias of the other?
>>>> The bottom line is that I don't want to see that error/warning
>>>> message in my programs. Ideas?
>>>
>>> Convince p5p that there should be a blocking call until all threads
>>> have finished. I tried to convince p5p about this and associated
>>> functionality about 18 months ago (if I remember correctly). I
>>> wasn't successful.
>>
>> Because perl-ithreads has lost its owner when Arthur has moved to ride
>> the ponie and no-one has stepped up to replace him. Until this happens
>> there is no point to talk to p5p about threads, besides core dumps,
>> because nobody is going to work on it.
>
>
> Well, and that's exactly the conundrum: any work done on threads may
> well only appear in blead (and not in 5.8.4). How many people use blead
> on production systems?
I remember sky saying that threads.xs will be released on CPAN. oh was I dreaming
>> May be you should try to port your modules into XS. It isn't very
>> complex and you can always ask p5p gurus if you have any questions. so
>> you could start with implementing that blocking call.
>> BTW, IMHO, that should be called by default by the parent thread,
>> users should need to call threads->running.
>
>
> No, that was _specifically_ vetoed by Jarkko 18 months ago. When _any_
> thread exits, it will take all other threads with it. Including if it is
> the main thread exiting. The thing is that one of the threads may never
> exit for whatever reason, and then you're stuck.
>
> "If you want to block until all threads have finished, you will have to
> do it yourself" was Jarkko's decision.
OK, I didn't remember that. In which case threads should have running() or
similar, but not call it by itself.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 00:59 -0800 1/21/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>>So I think we need to have a new blocking call that will prevent
>>>the main program/thread from exiting till all child threads are
>>>done.
>>Thread::Running solves this basically.
>> 1 while threads->running;
>I looked at the implementation. You are such a cheater, Liz ;) But
>hey, it works. Very cool.
*blush* ;-)
>I guess I could implement this in my test script using a simple
>semaphore (shared variable), making sure that all callbacks pull
>down that semaphore just before they are done and having the main
>thread block till that semaphore gets to 0. e.g. your Running
>implementation could drop the other dependencies list and just
>override threads::create to wrap it in a semaphore up and down calls
>around the callback.
Indeed. Don't forget that you need to steal threads::new as well ;-)
>>>The bottom line is that I don't want to see that error/warning
>>>message in my programs. Ideas?
>>Convince p5p that there should be a blocking call until all threads
>>have finished. I tried to convince p5p about this and associated
>>functionality about 18 months ago (if I remember correctly). I
>>wasn't successful.
>Because perl-ithreads has lost its owner when Arthur has moved to
>ride the ponie and no-one has stepped up to replace him. Until this
>happens there is no point to talk to p5p about threads, besides core
>dumps, because nobody is going to work on it.
Well, and that's exactly the conundrum: any work done on threads may
well only appear in blead (and not in 5.8.4). How many people use
blead on production systems?
>May be you should try to port your modules into XS. It isn't very
>complex and you can always ask p5p gurus if you have any questions.
>so you could start with implementing that blocking call.
>BTW, IMHO, that should be called by default by the parent thread,
>users should need to call threads->running.
No, that was _specifically_ vetoed by Jarkko 18 months ago. When
_any_ thread exits, it will take all other threads with it.
Including if it is the main thread exiting. The thing is that one of
the threads may never exit for whatever reason, and then you're stuck.
"If you want to block until all threads have finished, you will have
to do it yourself" was Jarkko's decision.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 17:23 -0800 1/20/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> One could argue that detached threads shouldn't be counted. But, as
>>> I said, a detached thread is also yanked from existence as soon as
>>> any other thread does an exit().
>>> Hope this explains it a bit.
>>
>> Thanks, Liz. But how do we deal with this problem. Should I always
>> finish threads programs with:
>>
>> $_->join() for threads->list();
>>
>> but that won't work with detached threads, since list() will return
>> only a list of non-detached threads.
>>
>> So I think we need to have a new blocking call that will prevent the
>> main program/thread from exiting till all child threads are done.
>
>
> Thread::Running solves this basically.
>
> 1 while threads->running;
>
> Note that this module uses a method of operation that suffered in tha
> last Apache module discussion: it creates additional methods in the
> threads:: namespace ;-)
I looked at the implementation. You are such a cheater, Liz ;) But hey, it
works. Very cool.
I guess I could implement this in my test script using a simple semaphore
(shared variable), making sure that all callbacks pull down that semaphore
just before they are done and having the main thread block till that semaphore
gets to 0. e.g. your Running implementation could drop the other dependencies
list and just override threads::create to wrap it in a semaphore up and down
calls around the callback.
> Mind you, I think this should be done in threads.xs, but I haven't build
> up the courage to undertake that.
It certainly should be done in threads.xs. It shouldn't be too hard to
implement. The accounting data could be stored in PL_modglobal (the global
hash/object per interpreter).
>> The bottom line is that I don't want to see that error/warning message
>> in my programs. Ideas?
>
>
> Convince p5p that there should be a blocking call until all threads have
> finished. I tried to convince p5p about this and associated
> functionality about 18 months ago (if I remember correctly). I wasn't
> successful.
Because perl-ithreads has lost its owner when Arthur has moved to ride the
ponie and no-one has stepped up to replace him. Until this happens there is no
point to talk to p5p about threads, besides core dumps, because nobody is
going to work on it.
May be you should try to port your modules into XS. It isn't very complex and
you can always ask p5p gurus if you have any questions. so you could start
with implementing that blocking call.
BTW, IMHO, that should be called by default by the parent thread, users should
need to call threads->running.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 17:23 -0800 1/20/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>One could argue that detached threads shouldn't be counted. But,
>>as I said, a detached thread is also yanked from existence as soon
>>as any other thread does an exit().
>>Hope this explains it a bit.
>Thanks, Liz. But how do we deal with this problem. Should I always
>finish threads programs with:
>
> $_->join() for threads->list();
>
>but that won't work with detached threads, since list() will return
>only a list of non-detached threads.
>
>So I think we need to have a new blocking call that will prevent the
>main program/thread from exiting till all child threads are done.
Thread::Running solves this basically.
1 while threads->running;
Note that this module uses a method of operation that suffered in tha
last Apache module discussion: it creates additional methods in the
threads:: namespace ;-)
Mind you, I think this should be done in threads.xs, but I haven't
build up the courage to undertake that.
>The bottom line is that I don't want to see that error/warning
>message in my programs. Ideas?
Convince p5p that there should be a blocking call until all threads
have finished. I tried to convince p5p about this and associated
functionality about 18 months ago (if I remember correctly). I
wasn't successful.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 10:15 -0800 1/12/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> At 10:00 -0800 1/12/04, Stas Bekman wrote:
>>>
>>>> % perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>>>> 1})->detach for 1..1'
>>>> A thread exited while 2 threads were running.
>>>
>>> Ah. That! That is considered to be correct behaviour (unless you're
>>> referring to the "2" instead of "1").
>>
>> What's correct about it? I've detached the threads and shouldn't get
>> any errors.
>
>
> The problem is not in the detach. the problem is that your program
> finishes before all the threads have finished. This was discussed
> extensively on p5p in the summer of 2002 prior to the 5.8.0 release. The
> problem is that a thread cannot continue if any other thread does an
> exit(). To indicate that you're doing that, the message occurs. Only
> problem is that the hidden thread that's used to store shared values, is
> counted as well.
>
> One could argue that detached threads shouldn't be counted. But, as I
> said, a detached thread is also yanked from existence as soon as any
> other thread does an exit().
>
>
> Hope this explains it a bit.
Thanks, Liz. But how do we deal with this problem. Should I always finish
threads programs with:
$_->join() for threads->list();
but that won't work with detached threads, since list() will return only a
list of non-detached threads.
So I think we need to have a new blocking call that will prevent the main
program/thread from exiting till all child threads are done.
The bottom line is that I don't want to see that error/warning message in my
programs. Ideas?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 10:15 -0800 1/12/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>At 10:00 -0800 1/12/04, Stas Bekman wrote:
>>>% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>>>1})->detach for 1..1'
>>>A thread exited while 2 threads were running.
>>Ah. That! That is considered to be correct behaviour (unless
>>you're referring to the "2" instead of "1").
>What's correct about it? I've detached the threads and shouldn't get
>any errors.
The problem is not in the detach. the problem is that your program
finishes before all the threads have finished. This was discussed
extensively on p5p in the summer of 2002 prior to the 5.8.0 release.
The problem is that a thread cannot continue if any other thread does
an exit(). To indicate that you're doing that, the message occurs.
Only problem is that the hidden thread that's used to store shared
values, is counted as well.
One could argue that detached threads shouldn't be counted. But, as
I said, a detached thread is also yanked from existence as soon as
any other thread does an exit().
Hope this explains it a bit.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 10:00 -0800 1/12/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> Oh? That's news to me. I was under the impression the problem only
>>> existed on Win32.
>>> Could you show me how to reproduce the problem on *nix?
>>
>>
>> % perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>> 1})->detach for 1..1'
>> A thread exited while 2 threads were running.
>
>
> Ah. That! That is considered to be correct behaviour (unless you're
> referring to the "2" instead of "1").
What's correct about it? I've detached the threads and shouldn't get any errors.
>> Besides, I find it worrying that we have a flurry of workaround
>> modules instead of trying to fix the core. Of course it's better than
>> nothing, but it all should really be fixed in the core.
>
>
> There is another bug with detach() in Win32 which can cause crashes. It
> was decided on p5p that it would _not_ get fixed for 5.8.3. So, that
> means at least 3 - 4 months of Windows users running into this. I have
> no doubt it will get fixed (actually, I'm assuming 5.8.4 in the source
> of Thread::Detach). Until then, Thread::Detach is a workaround if you
> don't want to change your source.
So I should remember to try to avoid using detach in my code. Thanks for the
heads up, Liz. Luckily in mp2 we don't quite need this feature.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 10:00 -0800 1/12/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>Oh? That's news to me. I was under the impression the problem
>>only existed on Win32.
>>Could you show me how to reproduce the problem on *nix?
>
>% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep
>1})->detach for 1..1'
>A thread exited while 2 threads were running.
Ah. That! That is considered to be correct behaviour (unless you're
referring to the "2" instead of "1").
>>>In any case, for my test using join instead of detach does the
>>>trick just fine.
>>Yes, but some people prefer to be able to use detach() at one point
>>in the future, hence my repair module. I thought it would just be
>>needed on Win32. If it is needed on more platforms, I would like
>>to know so that I can fix either the documentation and the internal
>>OS checks.
>Sure, but I have another workaround for my module and I don't want
>to create dependencies if I can avoid to.
Indeed.
>Besides, I find it worrying that we have a flurry of workaround
>modules instead of trying to fix the core. Of course it's better
>than nothing, but it all should really be fixed in the core.
There is another bug with detach() in Win32 which can cause crashes.
It was decided on p5p that it would _not_ get fixed for 5.8.3. So,
that means at least 3 - 4 months of Windows users running into this.
I have no doubt it will get fixed (actually, I'm assuming 5.8.4 in
the source of Thread::Detach). Until then, Thread::Detach is a
workaround if you don't want to change your source.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 09:37 -0800 1/12/04, Stas Bekman wrote:
>
>> Elizabeth Mattijsen wrote:
>>
>>> You might also want to check out my Thread::Detach from CPAN:
>>
>> Thanks, Liz. But the problem exists not only on Win32. I can easily
>> reproduce it on linux.
>
>
> Oh? That's news to me. I was under the impression the problem only
> existed on Win32.
>
> Could you show me how to reproduce the problem on *nix?
% perl-5.8.3-ithread -le 'use threads; threads->new(sub { sleep 1})->detach
for 1..1'
A thread exited while 2 threads were running.
>> So I don't think your doc is correct to say: "All of this happens on
>> Windows only and if the version of the Perl executor is known to have
>> the problem."
>
>
> Well, to my knowledge it was... I've never had any problems with
> detaching threads.
of course ;)
>> In any case, for my test using join instead of detach does the trick
>> just fine.
>
>
> Yes, but some people prefer to be able to use detach() at one point in
> the future, hence my repair module. I thought it would just be needed
> on Win32. If it is needed on more platforms, I would like to know so
> that I can fix either the documentation and the internal OS checks.
Sure, but I have another workaround for my module and I don't want to create
dependencies if I can avoid to.
Besides, I find it worrying that we have a flurry of workaround modules
instead of trying to fix the core. Of course it's better than nothing, but it
all should really be fixed in the core.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 09:37 -0800 1/12/04, Stas Bekman wrote:
>Elizabeth Mattijsen wrote:
>>You might also want to check out my Thread::Detach from CPAN:
>Thanks, Liz. But the problem exists not only on Win32. I can easily
>reproduce it on linux.
Oh? That's news to me. I was under the impression the problem only
existed on Win32.
Could you show me how to reproduce the problem on *nix?
>So I don't think your doc is correct to say: "All of this happens on
>Windows only and if the version of the Perl executor is known to
>have the problem."
Well, to my knowledge it was... I've never had any problems with
detaching threads.
>In any case, for my test using join instead of detach does the trick
>just fine.
Yes, but some people prefer to be able to use detach() at one point
in the future, hence my repair module. I thought it would just be
needed on Win32. If it is needed on more platforms, I would like to
know so that I can fix either the documentation and the internal OS
checks.
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Elizabeth Mattijsen wrote:
> At 09:17 -0800 1/12/04, Stas Bekman wrote:
>
>> Steve Hay wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> But I don't get the segfault.
>>>>
>>>> I'd like to explore the possibility that we have a need for CLONE in
>>>> Perl sections and PerlLoadModule next. I wish I had the segfault,
>>>> though. I need to think how to create it. But if I fail I'll try to
>>>> analyze whether we CLONE is needed. If you don't know what CLONE is
>>>> please see:
>>>> http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>>>
>>>
>>> I had a look at Example-CLONE. When I run "nmake test" it passes all
>>> tests successfully, but then I get an application error popup, and it
>>> spits out "A thread exited while 2 threads were running" on the
>>> console. It's OK if I run the two tests, basic.t and threads.t,
>>> individually.
>>
>>
>> Yes, that's a known problem in perl threads. Try replacing detach call
>> with join:
>
>
> You might also want to check out my Thread::Detach from CPAN:
>
>
> http://search.cpan.org/~elizabeth/Thread-Detach-0.01/lib/Thread/Detach.pm
>
> that should allow you to keep your source code unchanged (just add
> Thread::Detach to PERL5OPTS).
Thanks, Liz. But the problem exists not only on Win32. I can easily reproduce
it on linux. So I don't think your doc is correct to say: "All of this happens
on Windows only and if the version of the Perl executor is known to have the
problem."
In any case, for my test using join instead of detach does the trick just fine.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Elizabeth Mattijsen <li...@dijkmat.nl>.
At 09:17 -0800 1/12/04, Stas Bekman wrote:
>Steve Hay wrote:
>>Stas Bekman wrote:
>>
>>>But I don't get the segfault.
>>>
>>>I'd like to explore the possibility that we have a need for CLONE
>>>in Perl sections and PerlLoadModule next. I wish I had the
>>>segfault, though. I need to think how to create it. But if I fail
>>>I'll try to analyze whether we CLONE is needed. If you don't know
>>>what CLONE is please see:
>>>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>>
>>
>>I had a look at Example-CLONE. When I run "nmake test" it passes
>>all tests successfully, but then I get an application error popup,
>>and it spits out "A thread exited while 2 threads were running" on
>>the console. It's OK if I run the two tests, basic.t and
>>threads.t, individually.
>
>Yes, that's a known problem in perl threads. Try replacing detach
>call with join:
You might also want to check out my Thread::Detach from CPAN:
http://search.cpan.org/~elizabeth/Thread-Detach-0.01/lib/Thread/Detach.pm
that should allow you to keep your source code unchanged (just add
Thread::Detach to PERL5OPTS).
Liz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>But I don't get the segfault.
>>
>>I'd like to explore the possibility that we have a need for CLONE in Perl
>>sections and PerlLoadModule next. I wish I had the segfault, though. I need to
>>think how to create it. But if I fail I'll try to analyze whether we CLONE is
>>needed. If you don't know what CLONE is please see:
>>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>>
>
> I had a look at Example-CLONE. When I run "nmake test" it passes all
> tests successfully, but then I get an application error popup, and it
> spits out "A thread exited while 2 threads were running" on the
> console. It's OK if I run the two tests, basic.t and threads.t,
> individually.
Yes, that's a known problem in perl threads. Try replacing detach call with join:
Index: t/threads.t
===================================================================
RCS file: /home/stas/cvs/modules/Example-CLONE/t/threads.t,v
retrieving revision 1.1
diff -u -r1.1 threads.t
--- t/threads.t 31 Dec 2003 05:40:32 -0000 1.1
+++ t/threads.t 12 Jan 2004 17:17:25 -0000
@@ -31,7 +31,7 @@
# as the new threads are spawned they will inherit the count from the
# main thread
-threads->new(\&read_test)->detach for 1..$threads;
+threads->new(\&read_test) for 1..$threads;
sub read_test : locked {
for my $count (1..2) {
@@ -42,8 +42,5 @@
}
}
-# workaround the situations where the main thread exits before the
-# child threads, which shouldn't be a problem since all threads are
-# detached, but something is broken in perl
-select(undef, undef, undef, 0.25); # sleep 0.25sec
+$_->join() for threads->list();
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>But I don't get the segfault.
>
>I'd like to explore the possibility that we have a need for CLONE in Perl
>sections and PerlLoadModule next. I wish I had the segfault, though. I need to
>think how to create it. But if I fail I'll try to analyze whether we CLONE is
>needed. If you don't know what CLONE is please see:
>http://apache.org/~stas/Example-CLONE-0.02.tar.gz
>
I had a look at Example-CLONE. When I run "nmake test" it passes all
tests successfully, but then I get an application error popup, and it
spits out "A thread exited while 2 threads were running" on the
console. It's OK if I run the two tests, basic.t and threads.t,
individually.
- Steve
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
[...]
> I get a strange error with perl < 5.8.3 and the above config:
>
> failed to resolve handler `Apache::PerlSections'
> Syntax error on line 33 of /home/stas/apache.org/cvs/t/conf/httpd.conf:
> Modification of a read-only value attempted at
> /home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/DynaLoader.pm
> line 79.
> Compilation failed in require at
> /home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/XSLoader.pm
> line 93.
> Compilation failed in require at
> /home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
> BEGIN failed--compilation aborted at
> /home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
> Compilation failed in require at (eval 2) line 3.
>
> looked at line 79, and I can't see any readonly vars there, must be a
> shifted counter. will try to get this resolved first. But I don't get
> this error with 5.8.3 and it starts just fine for me.
Apparently Dynaloader needs to be preloaded. Will shortly commit the fix.
But I don't get the segfault.
I'd like to explore the possibility that we have a need for CLONE in Perl
sections and PerlLoadModule next. I wish I had the segfault, though. I need to
think how to create it. But if I fail I'll try to analyze whether we CLONE is
needed. If you don't know what CLONE is please see:
http://apache.org/~stas/Example-CLONE-0.02.tar.gz
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> I've just tried it with the current CVS and still get the old "Free to
> wrong pool" error:
>
> =====
> C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
> C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf.short
> -DAPACHE2 -DPERL_USEITHREADS
> Free to wrong pool 262828 not 863270.
> Note the errors or messages above, and press the <ESC> key to exit. 30...
> =====
:(
> Attached is a .tar.gz of the three files that I added which comprise the
> vhost tests, just so that we can be clear about what I'm testing here.
yes, but it fails before it tries to run the tests, so it's not really needed,
no? All you need is this short config file.
> I used a different httpd.conf.short file to the one quoted above:
>
> =====
> LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
> ServerName localhost:8529
> Listen 8529
> ServerRoot C:/Temp/modperl-2.0/t
> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
> LogLevel debug
> Listen 8530
> <VirtualHost _default_:8530>
> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
> PerlOptions +Parent
> <Perl >
> 1;
> </Perl>
> </VirtualHost>
> =====
>
> I think this conf file was produced a little later in the thread; it
> simplifies things even further by omitting the
> TestDirective::perlloadmodule bit.
I get a strange error with perl < 5.8.3 and the above config:
failed to resolve handler `Apache::PerlSections'
Syntax error on line 33 of /home/stas/apache.org/cvs/t/conf/httpd.conf:
Modification of a read-only value attempted at
/home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/DynaLoader.pm
line 79.
Compilation failed in require at
/home/stas/perl/5.8.2-ithread/lib/5.8.2/i686-linux-thread-multi/XSLoader.pm
line 93.
Compilation failed in require at
/home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
BEGIN failed--compilation aborted at
/home/stas/apache.org/cvs/blib/lib/Apache2/Apache/PerlSections.pm line 8.
Compilation failed in require at (eval 2) line 3.
looked at line 79, and I can't see any readonly vars there, must be a shifted
counter. will try to get this resolved first. But I don't get this error with
5.8.3 and it starts just fine for me.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>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 (!):-
>>>
>>>=====
>>>LoadModule perl_module C:/Temp/modperl-2.0/src/modules/perl/mod_perl.so
>>>ServerName localhost:8529
>>>Listen 8529
>>>ServerRoot C:/Temp/modperl-2.0/t
>>>DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>>>LogLevel debug
>>>PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
>>>PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
>>>PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
>>>PerlSwitches -IC:/Temp/modperl-2.0/t/response
>>>Listen 8542
>>><VirtualHost _default_:8542>
>>> PerlOptions +Parent
>>></Virtualhost>
>>>PerlLoadModule TestDirective::perlloadmodule
>>>=====
>>>
>>>The server still crashes on startup, even when started with the "-t"
>>>switch. Attached is a trace (MOD_PERL_TRACE=all) of it crashing with
>>>this minimal configuration.
>>>
>>>If I move the "PerlLoadModule TestDirective::perlloadmodule" line to
>>>above the <VirtualHost> then the "-t" test passes OK (the only output
>>>is "syntax OK"). The server still doesn't start, though -- without
>>>the "-t" switch it crashes in the same way as before (i.e. the "Free
>>>to wrong pool" error). Here's the (much shorter) stacktrace from that
>>>crash:
>>>
>>>
>>The good news is that with the short config you posted above, I'm now
>>able to reproduce the segfault, though a totally different one (in
>>PerlLoadModule as well). I hope that the two have the same origin.
>>
>>
>
>Steve, Randy, what's the status with this +Parent issue. I was carried away
>with other issues and now that I come back I no longer can reproduce the
>problem, which I seemed to 3 months ago. Do things any different with the
>current mod_perl cvs?
>
I've just tried it with the current CVS and still get the old "Free to
wrong pool" error:
=====
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf.short
-DAPACHE2 -DPERL_USEITHREADS
Free to wrong pool 262828 not 863270.
Note the errors or messages above, and press the <ESC> key to exit. 30...
=====
Attached is a .tar.gz of the three files that I added which comprise the
vhost tests, just so that we can be clear about what I'm testing here.
I used a different httpd.conf.short file to the one quoted above:
=====
LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName localhost:8529
Listen 8529
ServerRoot C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen 8530
<VirtualHost _default_:8530>
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlOptions +Parent
<Perl >
1;
</Perl>
</VirtualHost>
=====
I think this conf file was produced a little later in the thread; it
simplifies things even further by omitting the
TestDirective::perlloadmodule bit.
This is all now using Apache 2.0.48 and Perl 5.8.2.
- Steve
------------------------------------------------
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: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Steve Hay wrote:
>
>> 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 (!):-
>>
>> =====
>> LoadModule perl_module C:/Temp/modperl-2.0/src/modules/perl/mod_perl.so
>> ServerName localhost:8529
>> Listen 8529
>> ServerRoot C:/Temp/modperl-2.0/t
>> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>> LogLevel debug
>> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
>> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
>> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
>> PerlSwitches -IC:/Temp/modperl-2.0/t/response
>> Listen 8542
>> <VirtualHost _default_:8542>
>> PerlOptions +Parent
>> </Virtualhost>
>> PerlLoadModule TestDirective::perlloadmodule
>> =====
>>
>> The server still crashes on startup, even when started with the "-t"
>> switch. Attached is a trace (MOD_PERL_TRACE=all) of it crashing with
>> this minimal configuration.
>>
>> If I move the "PerlLoadModule TestDirective::perlloadmodule" line to
>> above the <VirtualHost> then the "-t" test passes OK (the only output
>> is "syntax OK"). The server still doesn't start, though -- without
>> the "-t" switch it crashes in the same way as before (i.e. the "Free
>> to wrong pool" error). Here's the (much shorter) stacktrace from that
>> crash:
>
>
> The good news is that with the short config you posted above, I'm now
> able to reproduce the segfault, though a totally different one (in
> PerlLoadModule as well). I hope that the two have the same origin.
Steve, Randy, what's the status with this +Parent issue. I was carried away
with other issues and now that I come back I no longer can reproduce the
problem, which I seemed to 3 months ago. Do things any different with the
current mod_perl cvs?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Stas Bekman wrote:
>
>
>>Another one to try (w/ and w/o last patch). As you realize I'm shooting
>>in the dark, trying to guess where the context could go wrong. Thanks.
>>
>>
>
>BTW, this one if it'll do anything should affect the PerlLoadModule faulty
>scenario and not the <Perl>1</Perl> one.
>
I've now tried the patch below both with and without the previous
patch. Either way, both short conf files (the <Perl> one and the
PerlLoadModule one) are still fixed as before, but the vhost test still
fails with the usual "free to wrong pool" error.
Actually, now that I've tried it again, the short conf file with the
PerlLoadModule doesn't seem to fail any more anyway, i.e. without either
patch! Something else must have fixed it somewhere along the line.
>
>
>
>>Index: src/modules/perl/modperl_interp.c
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
>>retrieving revision 1.60
>>diff -u -r1.60 modperl_interp.c
>>--- src/modules/perl/modperl_interp.c 18 Oct 2003 23:45:29 -0000 1.60
>>+++ src/modules/perl/modperl_interp.c 21 Jan 2004 04:24:07 -0000
>>@@ -89,6 +89,7 @@
>> */
>> if ((clone_flags & CLONEf_KEEP_PTR_TABLE)) {
>> dTHXa(interp->perl);
>>+ PERL_SET_CONTEXT(interp->perl);
>> ptr_table_free(PL_ptr_table);
>> PL_ptr_table = NULL;
>> }
>>
>>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>.
>
>
>
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Another one to try (w/ and w/o last patch). As you realize I'm shooting
> in the dark, trying to guess where the context could go wrong. Thanks.
BTW, this one if it'll do anything should affect the PerlLoadModule faulty
scenario and not the <Perl>1</Perl> one.
> Index: src/modules/perl/modperl_interp.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
> retrieving revision 1.60
> diff -u -r1.60 modperl_interp.c
> --- src/modules/perl/modperl_interp.c 18 Oct 2003 23:45:29 -0000 1.60
> +++ src/modules/perl/modperl_interp.c 21 Jan 2004 04:24:07 -0000
> @@ -89,6 +89,7 @@
> */
> if ((clone_flags & CLONEf_KEEP_PTR_TABLE)) {
> dTHXa(interp->perl);
> + PERL_SET_CONTEXT(interp->perl);
> ptr_table_free(PL_ptr_table);
> PL_ptr_table = NULL;
> }
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Another one to try (w/ and w/o last patch). As you realize I'm shooting in the
dark, trying to guess where the context could go wrong. Thanks.
Index: src/modules/perl/modperl_interp.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.60
diff -u -r1.60 modperl_interp.c
--- src/modules/perl/modperl_interp.c 18 Oct 2003 23:45:29 -0000 1.60
+++ src/modules/perl/modperl_interp.c 21 Jan 2004 04:24:07 -0000
@@ -89,6 +89,7 @@
*/
if ((clone_flags & CLONEf_KEEP_PTR_TABLE)) {
dTHXa(interp->perl);
+ PERL_SET_CONTEXT(interp->perl);
ptr_table_free(PL_ptr_table);
PL_ptr_table = NULL;
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>>>can't you pin-point which part of
>>>that patch causes the problem? I assume the problem is the same, right?
>>>
>>>
>>>
>>It is indeed the usual problem. I'll try produce another shortened
>>.conf file which reproduces the bug that's still lurking. Oh joy.
>>
>>
>
>The problem is that it doesn't bite you on unix, so I have to run a state
>machine in my head moving through the code and try to make sure that the
>context is right. (i'm sure you remember my woes about this unneeded context
>thing to p5p). So about a month ago I just tried to add these contextes
>everywhere we have redefined THX. I'm not sure it'll do any good, but try this
>patch against the current cvs (i'm not sure if your compiler will agree with
>// comments, but this is just some work in the middle, i may try to clean it
>up if you think it will do some good)
>
For some reason my patch program (from cygwin) doesn't like this patch
at all! All hunks fail in all files. Not my day.
I applied it by hand instead, but it makes no difference :(
With just this patch, the <Perl> conf file causes the "free to wrong
pool" error even doing a "-t" syntax check. Adding your earlier patch
as well (to save and restore the context within
MP_CMD_SRV_DECLARE(perldo)) fixes that as before, but the vhost test
still breaks as usual.
- Steve
>
>--- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
>+++ src/modules/perl/mod_perl.c 21 Jan 2004 09:56:02 -0000
>@@ -107,7 +107,10 @@
>
> static void set_taint_var(PerlInterpreter *perl)
> {
>- dTHXa(perl);
>+#ifdef USE_ITHREADS
>+ pTHX;
>+ PERL_SET_CONTEXT(aTHX = perl);
>+#endif
>
> /* 5.7.3+ has a built-in special ${^TAINT}, backport it to 5.6.0+ */
> #if PERL_REVISION == 5 && \
>@@ -186,7 +189,7 @@
> }
>
> #ifdef USE_ITHREADS
>- aTHX = perl;
>+ PERL_SET_CONTEXT(aTHX = perl);
> #endif
>
> perl_construct(perl);
>@@ -561,9 +564,9 @@
> {
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
>- dTHXa(scfg->mip->parent->perl);
>+ MP_dSCFG_dTHX;
> #endif
>-
>+
> #ifdef MP_TRACE
> /* httpd core open_logs handler re-opens s->error_log, which might
> * change, even though it still points to the same physical file
>@@ -861,7 +864,7 @@
>
> #ifdef USE_ITHREADS
> interp = modperl_interp_select(r, r->connection, r->server);
>- aTHX = interp->perl;
>+ PERL_SET_CONTEXT(aTHX = interp->perl);
> if (MpInterpPUTBACK(interp)) {
> rcfg->interp = interp;
> }
>Index: src/modules/perl/modperl_callback.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
>retrieving revision 1.65
>diff -u -r1.65 modperl_callback.c
>--- src/modules/perl/modperl_callback.c 9 Jan 2004 04:59:18 -0000 1.65
>+++ src/modules/perl/modperl_callback.c 21 Jan 2004 09:56:02 -0000
>@@ -165,6 +165,7 @@
> if (r || c) {
> interp = modperl_interp_select(r, c, s);
> aTHX = interp->perl;
>+ //PERL_SET_CONTEXT(aTHX);
> }
> else {
> /* Child{Init,Exit}, OpenLogs */
>Index: src/modules/perl/modperl_cmd.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
>retrieving revision 1.52
>diff -u -r1.52 modperl_cmd.c
>--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
>+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 09:56:02 -0000
>@@ -254,6 +254,8 @@
> apr_pool_t *p = parms->pool;
> const char *error;
>
>+ MP_TRACE_d(MP_FUNC, "%s:%d", parms->directive->filename,
>+ parms->directive->line_num);
> MP_TRACE_d(MP_FUNC, "arg = %s\n", arg);
> if ((error = modperl_options_set(p, opts, arg)) && !is_per_dir) {
> /* maybe a per-directory option outside of a container */
>@@ -380,8 +382,16 @@
> }
>
> /* we must init earlier than normal */
>- modperl_run();
>-
>+ if (!modperl_is_running()) {
>+ /* preload Apache::PerlSections in the case when <Perl>
>+ * triggers a server startup */
>+ MP_TRACE_d(MP_FUNC, "push PerlModule %s\n",
>+ MP_DEFAULT_PERLSECTION_HANDLER);
>+ //*(const char **)apr_array_push(scfg->PerlModule) =
>+ // MP_DEFAULT_PERLSECTION_HANDLER;
>+ modperl_run();
>+ }
>+
> if (modperl_init_vhost(s, p, NULL) != OK) {
> return "init mod_perl vhost failed";
> }
>@@ -389,6 +399,12 @@
> #ifdef USE_ITHREADS
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> aTHX = scfg->mip->parent->perl;
>+ //PERL_SET_CONTEXT(scfg->mip->parent->perl);
>+
>+ MP_TRACE_i(MP_FUNC, "perl == 0x%lx, PERL_GET_CONTEXT == 0x%lx\n",
>+ (unsigned long)scfg->mip->parent->perl,
>+ (unsigned long)PERL_GET_CONTEXT);
>+
> #endif
>
> /* data will be set by a <Perl> section */
>Index: src/modules/perl/modperl_config.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
>retrieving revision 1.74
>diff -u -r1.74 modperl_config.c
>--- src/modules/perl/modperl_config.c 10 Jan 2004 02:52:20 -0000 1.74
>+++ src/modules/perl/modperl_config.c 21 Jan 2004 09:56:02 -0000
>@@ -308,7 +308,9 @@
> {
> request_rec *r = (request_rec *)data;
> MP_dTHX;
>-
>+#ifdef USE_ITHREADS
>+ PERL_SET_CONTEXT(aTHX);
>+#endif
> return modperl_config_request_cleanup(aTHX_ r);
> }
>
>@@ -328,8 +330,11 @@
> {
> char **entries;
> int i;
>+#ifdef USE_ITHREADS
> dTHXa(perl);
>-
>+ PERL_SET_CONTEXT(aTHX);
>+#endif
>+
> entries = (char **)scfg->PerlModule->elts;
> for (i = 0; i < scfg->PerlModule->nelts; i++){
> if (modperl_require_module(aTHX_ entries[i], TRUE)){
>@@ -353,8 +358,11 @@
> {
> char **entries;
> int i;
>+#ifdef USE_ITHREADS
> dTHXa(perl);
>-
>+ PERL_SET_CONTEXT(aTHX);
>+#endif
>+
> entries = (char **)scfg->PerlRequire->elts;
> for (i = 0; i < scfg->PerlRequire->nelts; i++){
> if (modperl_require_file(aTHX_ entries[i], TRUE)){
>@@ -381,11 +389,14 @@
> static void *svav_getstr(void *buf, size_t bufsiz, void *param)
> {
> svav_param_t *svav_param = (svav_param_t *)param;
>- dTHXa(svav_param->perl);
> AV *av = svav_param->av;
> SV *sv;
> STRLEN n_a;
>-
>+#ifdef USE_ITHREADS
>+ dTHXa(svav_param->perl);
>+ PERL_SET_CONTEXT(aTHX);
>+#endif
>+
> if (svav_param->ix > AvFILL(av)) {
> return NULL;
> }
>Index: src/modules/perl/modperl_config.h
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.h,v
>retrieving revision 1.32
>diff -u -r1.32 modperl_config.h
>--- src/modules/perl/modperl_config.h 10 Jan 2004 02:52:20 -0000 1.32
>+++ src/modules/perl/modperl_config.h 21 Jan 2004 09:56:02 -0000
>@@ -91,8 +91,8 @@
>
> /* hopefully this macro will not need to be used often */
> #ifdef USE_ITHREADS
>-# define MP_dTHX \
>- modperl_interp_t *interp = \
>+# define MP_dTHX \
>+ modperl_interp_t *interp = \
> modperl_interp_select(r, r->connection, r->server); \
> dTHXa(interp->perl)
> #else
>Index: src/modules/perl/modperl_handler.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_handler.c,v
>retrieving revision 1.19
>diff -u -r1.19 modperl_handler.c
>--- src/modules/perl/modperl_handler.c 18 Sep 2003 07:55:52 -0000 1.19
>+++ src/modules/perl/modperl_handler.c 21 Jan 2004 09:56:02 -0000
>@@ -58,7 +58,7 @@
> duped ? "current" : "server conf",
> (unsigned long)rp);
>
>- if (!modperl_mgv_resolve(aTHX_ handler, rp, handler->name, FALSE)) {
>+ if (!modperl_mgv_resolve(aTHX_ handler, rp, handler->name, TRUE)) {
> ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
> "failed to resolve handler `%s'",
> handler->name);
>Index: src/modules/perl/modperl_interp.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
>retrieving revision 1.60
>diff -u -r1.60 modperl_interp.c
>--- src/modules/perl/modperl_interp.c 18 Oct 2003 23:45:29 -0000 1.60
>+++ src/modules/perl/modperl_interp.c 21 Jan 2004 09:56:02 -0000
>@@ -18,12 +18,11 @@
>
> void modperl_interp_clone_init(modperl_interp_t *interp)
> {
>- dTHXa(interp->perl);
>+ pTHX;
>+ PERL_SET_CONTEXT(aTHX = interp->perl);
>
> MpInterpCLONED_On(interp);
>
>- PERL_SET_CONTEXT(aTHX);
>-
> /* XXX: hack for bug fixed in 5.6.1 */
> if (PL_scopestack_ix == 0) {
> ENTER;
>@@ -59,10 +58,20 @@
> clone_flags |= CLONEf_CLONE_HOST;
> #endif
>
>- PERL_SET_CONTEXT(perl);
>-
>+ //PERL_SET_CONTEXT(perl);
> interp->perl = perl_clone(perl, clone_flags);
>+ /* 5.8.2 sets internall the context to the parent perl so we
>+ * need to restore it
>+ */
>+ PERL_SET_CONTEXT(interp->perl);
>+
>+ MP_TRACE_i(MP_FUNC, "interp->perl == 0x%lx, PERL_GET_CONTEXT == 0x%lx,"
>+ " interp->mip->parent->perl == 0x%lx\n",
>+ (unsigned long)interp->perl,
>+ (unsigned long)PERL_GET_CONTEXT,
>+ (unsigned long)interp->mip->parent->perl);
>
>+
> #if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 0 && \
> defined(USE_REENTRANT_API) && defined(HAS_CRYPT_R) && defined(__GLIBC__)
> {
>@@ -88,14 +97,15 @@
> * within modperl_svptr_table_clone.
> */
> if ((clone_flags & CLONEf_KEEP_PTR_TABLE)) {
>- dTHXa(interp->perl);
>+ pTHX;
>+ PERL_SET_CONTEXT(aTHX = interp->perl);
> ptr_table_free(PL_ptr_table);
> PL_ptr_table = NULL;
> }
>
> modperl_interp_clone_init(interp);
>
>- PERL_SET_CONTEXT(perl);
>+ //PERL_SET_CONTEXT(perl);
>
> #ifdef MP_USE_GTOP
> MP_TRACE_m_do(
>@@ -112,12 +122,17 @@
> void modperl_interp_destroy(modperl_interp_t *interp)
> {
> void **handles;
>- dTHXa(interp->perl);
>-
>- PERL_SET_CONTEXT(interp->perl);
>+ pTHX;
>+ PERL_SET_CONTEXT(aTHX = interp->perl);
>
>- MP_TRACE_i(MP_FUNC, "interp == 0x%lx\n",
>- (unsigned long)interp);
>+ /* this interp was created when the global PERL_GET_CONTEXT was set to
>+ * its parent perl so PERL_GET_CONTEXT must be set to the same value
>+ * for the destruction */
>+// PERL_SET_CONTEXT(interp->mip->parent->perl);
>+
>+ MP_TRACE_i(MP_FUNC, "interp == 0x%lx, perl == 0x%lx, PERL_GET_CONTEXT ==
>0x%lx\n",
>+ (unsigned long)interp, (unsigned long)interp->perl,
>+ (unsigned long)PERL_GET_CONTEXT);
>
> if (MpInterpIN_USE(interp)) {
> MP_TRACE_i(MP_FUNC, "*error - still in use!*\n");
>@@ -238,7 +253,7 @@
>
> mip->server = s;
> mip->parent = modperl_interp_new(mip, NULL);
>- aTHX = mip->parent->perl = perl;
>+ PERL_SET_CONTEXT(aTHX = mip->parent->perl = perl);
>
> /* this happens post-config in mod_perl.c:modperl_init_clones() */
> /* modperl_tipool_init(tipool); */
>Index: src/modules/perl/modperl_options.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_options.c,v
>retrieving revision 1.10
>diff -u -r1.10 modperl_options.c
>--- src/modules/perl/modperl_options.c 28 Sep 2001 15:16:06 -0000 1.10
>+++ src/modules/perl/modperl_options.c 21 Jan 2004 09:56:02 -0000
>@@ -42,9 +42,24 @@
> options->opts = options->unset =
> (type == MpSrvType ? MpSrv_f_UNSET : MpDir_f_UNSET);
>
>+ MP_TRACE_d(MP_FUNC, "opts: %d", options->opts);
>+
> return options;
> }
>
>+
>+static void modperl_options_dump(modperl_options_t *o, const char *str)
>+{
>+ const char *type = type_lookup(o);
>+ MP_TRACE_d(MP_FUNC, "option '%s', type: %s", str, type);
>+ MP_TRACE_d(MP_FUNC, "opts_add %d", o->opts_add);
>+ MP_TRACE_d(MP_FUNC, "opts_remove %d", o->opts_remove);
>+ MP_TRACE_d(MP_FUNC, "opts_override %d", o->opts_override);
>+ MP_TRACE_d(MP_FUNC, "opts_seen %d", o->opts_seen);
>+ MP_TRACE_d(MP_FUNC, "unset %d\n", o->unset);
>+}
>+
>+
> const char *modperl_options_set(apr_pool_t *p, modperl_options_t *o,
> const char *str)
> {
>@@ -56,6 +71,8 @@
> action = *(str++);
> }
>
>+ modperl_options_dump(o, str);
>+
> if (!(opt = flags_lookup(o, str))) {
> error = apr_pstrcat(p, "Invalid per-", type_lookup(o),
> " PerlOption: ", str, NULL);
>Index: src/modules/perl/modperl_perl.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl.c,v
>retrieving revision 1.20
>diff -u -r1.20 modperl_perl.c
>--- src/modules/perl/modperl_perl.c 3 Nov 2003 23:31:19 -0000 1.20
>+++ src/modules/perl/modperl_perl.c 21 Jan 2004 09:56:02 -0000
>@@ -101,10 +101,15 @@
> {
> char **orig_environ = NULL;
> PTR_TBL_t *module_commands;
>- dTHXa(perl);
>-
>- PERL_SET_CONTEXT(perl);
>+ PerlInterpreter *parent_perl;
>+#ifdef USE_ITHREADS
>+ pTHX;
>
>+ PERL_SET_CONTEXT(aTHX = perl);
>+#endif
>+ parent_perl = PERL_GET_CONTEXT;
>+// PERL_SET_CONTEXT(perl);
>+//PERL_SET_CONTEXT(parent_perl);
> PL_perl_destruct_level = modperl_perl_destruct_level();
>
> #ifdef USE_ENVIRON_ARRAY
>@@ -134,13 +139,19 @@
> }
>
> {
>- dTHXa(perl);
>+ //dTHXa(perl);
>
> if ((module_commands = modperl_module_config_table_get(aTHX_ FALSE))) {
> modperl_svptr_table_destroy(aTHX_ module_commands);
> }
> }
>
>+ //PERL_SET_CONTEXT(perl);
>+ //PERL_SET_CONTEXT(parent_perl);
>+ MP_TRACE_i(MP_FUNC, "perl == 0x%lx, PERL_GET_CONTEXT == 0x%lx\n",
>+ (unsigned long)perl,
>+ (unsigned long)PERL_GET_CONTEXT);
>+
> perl_destruct(perl);
>
> /* XXX: big bug in 5.6.1 fixed in 5.7.2+
>@@ -150,9 +161,13 @@
> # define MP_NO_PERL_FREE
> #endif
>
>+ //PERL_SET_CONTEXT(parent_perl);
> #ifndef MP_NO_PERL_FREE
> perl_free(perl);
> #endif
>+
>+ MP_TRACE_i(MP_FUNC, "after: PERL_GET_CONTEXT== 0x%lx\n",
>+ (unsigned long)PERL_GET_CONTEXT);
>
> #ifdef USE_ENVIRON_ARRAY
> if (orig_environ) {
>Index: src/modules/perl/modperl_perl.h
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl.h,v
>retrieving revision 1.14
>diff -u -r1.14 modperl_perl.h
>--- src/modules/perl/modperl_perl.h 7 Nov 2003 09:04:01 -0000 1.14
>+++ src/modules/perl/modperl_perl.h 21 Jan 2004 09:56:02 -0000
>@@ -29,4 +29,13 @@
>
> void modperl_hash_seed_set(pTHX);
>
>+#ifdef USE_ITHREADS
>+#define MP_THXa(perl) \
>+ PERL_SET_CONTEXT(aTHX = perl)
>+#else
>+#define MP_THXa(perl)
>+#endif
>+
>+#define dTHXCTXa
>+
> #endif /* MODPERL_PERL_H */
>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>
>
>
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve Hay wrote:
>>
>>
>>
>>>Stas Bekman wrote:
>>>
>>>
>>>
>>>
>>>
>>>>Steve, Randy, can you please try with this patch. This is against the conf
>>>>file with:
>>>>
>>>><VirtualHost _default_:8542>
>>>>PerlOptions +Parent
>>>><Perl>
>>>> 1;
>>>></Perl>
>>>></Virtualhost>
>>>>
>>>>
>>>>
>>>
>>>The Good News: The patch below fixes *both* of the short conf files
>>>that we've been playing with. Running "apache.exe -t ..." was
>>>previously enough to produce the crash; now I can even start the server
>>>up (i.e. without the "-t" option) without error.
>>>
>>>
>>
>>Great. So it was a wrong context issue after all.
>>
>>Could you try remove the last chunk of this patch. i.e. remove the part that
>>'restore the original perl context; and see if it still works.
>>
>
> With the last hunk of the patch removed, the short conf file with the
> <Perl> section does still work with Apache's "-t" option, but the server
> won't start up without it: It produces an access violation via the
> usual bit of "free to wrong pool" code (although I didn't actually see
> the message in the console this time).
>
> So the whole patch is required.
OK, thanks for testing, Steve.
>>>The Bad News: The vhost test that originally didn't work way back at
>>>the start of this thread (excuse the pun) still doesn't work.
>>>
>>>
>>
>>heh, I forgot what was the original one ;)
>>
>
> It's been a long hard slog, hasn't it?
;)
>>can't you pin-point which part of
>>that patch causes the problem? I assume the problem is the same, right?
>>
>
> It is indeed the usual problem. I'll try produce another shortened
> .conf file which reproduces the bug that's still lurking. Oh joy.
The problem is that it doesn't bite you on unix, so I have to run a state
machine in my head moving through the code and try to make sure that the
context is right. (i'm sure you remember my woes about this unneeded context
thing to p5p). So about a month ago I just tried to add these contextes
everywhere we have redefined THX. I'm not sure it'll do any good, but try this
patch against the current cvs (i'm not sure if your compiler will agree with
// comments, but this is just some work in the middle, i may try to clean it
up if you think it will do some good)
--- src/modules/perl/mod_perl.c 10 Jan 2004 05:01:04 -0000 1.206
+++ src/modules/perl/mod_perl.c 21 Jan 2004 09:56:02 -0000
@@ -107,7 +107,10 @@
static void set_taint_var(PerlInterpreter *perl)
{
- dTHXa(perl);
+#ifdef USE_ITHREADS
+ pTHX;
+ PERL_SET_CONTEXT(aTHX = perl);
+#endif
/* 5.7.3+ has a built-in special ${^TAINT}, backport it to 5.6.0+ */
#if PERL_REVISION == 5 && \
@@ -186,7 +189,7 @@
}
#ifdef USE_ITHREADS
- aTHX = perl;
+ PERL_SET_CONTEXT(aTHX = perl);
#endif
perl_construct(perl);
@@ -561,9 +564,9 @@
{
#ifdef USE_ITHREADS
MP_dSCFG(s);
- dTHXa(scfg->mip->parent->perl);
+ MP_dSCFG_dTHX;
#endif
-
+
#ifdef MP_TRACE
/* httpd core open_logs handler re-opens s->error_log, which might
* change, even though it still points to the same physical file
@@ -861,7 +864,7 @@
#ifdef USE_ITHREADS
interp = modperl_interp_select(r, r->connection, r->server);
- aTHX = interp->perl;
+ PERL_SET_CONTEXT(aTHX = interp->perl);
if (MpInterpPUTBACK(interp)) {
rcfg->interp = interp;
}
Index: src/modules/perl/modperl_callback.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_callback.c,v
retrieving revision 1.65
diff -u -r1.65 modperl_callback.c
--- src/modules/perl/modperl_callback.c 9 Jan 2004 04:59:18 -0000 1.65
+++ src/modules/perl/modperl_callback.c 21 Jan 2004 09:56:02 -0000
@@ -165,6 +165,7 @@
if (r || c) {
interp = modperl_interp_select(r, c, s);
aTHX = interp->perl;
+ //PERL_SET_CONTEXT(aTHX);
}
else {
/* Child{Init,Exit}, OpenLogs */
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.52
diff -u -r1.52 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 09:56:02 -0000
@@ -254,6 +254,8 @@
apr_pool_t *p = parms->pool;
const char *error;
+ MP_TRACE_d(MP_FUNC, "%s:%d", parms->directive->filename,
+ parms->directive->line_num);
MP_TRACE_d(MP_FUNC, "arg = %s\n", arg);
if ((error = modperl_options_set(p, opts, arg)) && !is_per_dir) {
/* maybe a per-directory option outside of a container */
@@ -380,8 +382,16 @@
}
/* we must init earlier than normal */
- modperl_run();
-
+ if (!modperl_is_running()) {
+ /* preload Apache::PerlSections in the case when <Perl>
+ * triggers a server startup */
+ MP_TRACE_d(MP_FUNC, "push PerlModule %s\n",
+ MP_DEFAULT_PERLSECTION_HANDLER);
+ //*(const char **)apr_array_push(scfg->PerlModule) =
+ // MP_DEFAULT_PERLSECTION_HANDLER;
+ modperl_run();
+ }
+
if (modperl_init_vhost(s, p, NULL) != OK) {
return "init mod_perl vhost failed";
}
@@ -389,6 +399,12 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
aTHX = scfg->mip->parent->perl;
+ //PERL_SET_CONTEXT(scfg->mip->parent->perl);
+
+ MP_TRACE_i(MP_FUNC, "perl == 0x%lx, PERL_GET_CONTEXT == 0x%lx\n",
+ (unsigned long)scfg->mip->parent->perl,
+ (unsigned long)PERL_GET_CONTEXT);
+
#endif
/* data will be set by a <Perl> section */
Index: src/modules/perl/modperl_config.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.c,v
retrieving revision 1.74
diff -u -r1.74 modperl_config.c
--- src/modules/perl/modperl_config.c 10 Jan 2004 02:52:20 -0000 1.74
+++ src/modules/perl/modperl_config.c 21 Jan 2004 09:56:02 -0000
@@ -308,7 +308,9 @@
{
request_rec *r = (request_rec *)data;
MP_dTHX;
-
+#ifdef USE_ITHREADS
+ PERL_SET_CONTEXT(aTHX);
+#endif
return modperl_config_request_cleanup(aTHX_ r);
}
@@ -328,8 +330,11 @@
{
char **entries;
int i;
+#ifdef USE_ITHREADS
dTHXa(perl);
-
+ PERL_SET_CONTEXT(aTHX);
+#endif
+
entries = (char **)scfg->PerlModule->elts;
for (i = 0; i < scfg->PerlModule->nelts; i++){
if (modperl_require_module(aTHX_ entries[i], TRUE)){
@@ -353,8 +358,11 @@
{
char **entries;
int i;
+#ifdef USE_ITHREADS
dTHXa(perl);
-
+ PERL_SET_CONTEXT(aTHX);
+#endif
+
entries = (char **)scfg->PerlRequire->elts;
for (i = 0; i < scfg->PerlRequire->nelts; i++){
if (modperl_require_file(aTHX_ entries[i], TRUE)){
@@ -381,11 +389,14 @@
static void *svav_getstr(void *buf, size_t bufsiz, void *param)
{
svav_param_t *svav_param = (svav_param_t *)param;
- dTHXa(svav_param->perl);
AV *av = svav_param->av;
SV *sv;
STRLEN n_a;
-
+#ifdef USE_ITHREADS
+ dTHXa(svav_param->perl);
+ PERL_SET_CONTEXT(aTHX);
+#endif
+
if (svav_param->ix > AvFILL(av)) {
return NULL;
}
Index: src/modules/perl/modperl_config.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_config.h,v
retrieving revision 1.32
diff -u -r1.32 modperl_config.h
--- src/modules/perl/modperl_config.h 10 Jan 2004 02:52:20 -0000 1.32
+++ src/modules/perl/modperl_config.h 21 Jan 2004 09:56:02 -0000
@@ -91,8 +91,8 @@
/* hopefully this macro will not need to be used often */
#ifdef USE_ITHREADS
-# define MP_dTHX \
- modperl_interp_t *interp = \
+# define MP_dTHX \
+ modperl_interp_t *interp = \
modperl_interp_select(r, r->connection, r->server); \
dTHXa(interp->perl)
#else
Index: src/modules/perl/modperl_handler.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_handler.c,v
retrieving revision 1.19
diff -u -r1.19 modperl_handler.c
--- src/modules/perl/modperl_handler.c 18 Sep 2003 07:55:52 -0000 1.19
+++ src/modules/perl/modperl_handler.c 21 Jan 2004 09:56:02 -0000
@@ -58,7 +58,7 @@
duped ? "current" : "server conf",
(unsigned long)rp);
- if (!modperl_mgv_resolve(aTHX_ handler, rp, handler->name, FALSE)) {
+ if (!modperl_mgv_resolve(aTHX_ handler, rp, handler->name, TRUE)) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s,
"failed to resolve handler `%s'",
handler->name);
Index: src/modules/perl/modperl_interp.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_interp.c,v
retrieving revision 1.60
diff -u -r1.60 modperl_interp.c
--- src/modules/perl/modperl_interp.c 18 Oct 2003 23:45:29 -0000 1.60
+++ src/modules/perl/modperl_interp.c 21 Jan 2004 09:56:02 -0000
@@ -18,12 +18,11 @@
void modperl_interp_clone_init(modperl_interp_t *interp)
{
- dTHXa(interp->perl);
+ pTHX;
+ PERL_SET_CONTEXT(aTHX = interp->perl);
MpInterpCLONED_On(interp);
- PERL_SET_CONTEXT(aTHX);
-
/* XXX: hack for bug fixed in 5.6.1 */
if (PL_scopestack_ix == 0) {
ENTER;
@@ -59,10 +58,20 @@
clone_flags |= CLONEf_CLONE_HOST;
#endif
- PERL_SET_CONTEXT(perl);
-
+ //PERL_SET_CONTEXT(perl);
interp->perl = perl_clone(perl, clone_flags);
+ /* 5.8.2 sets internall the context to the parent perl so we
+ * need to restore it
+ */
+ PERL_SET_CONTEXT(interp->perl);
+
+ MP_TRACE_i(MP_FUNC, "interp->perl == 0x%lx, PERL_GET_CONTEXT == 0x%lx,"
+ " interp->mip->parent->perl == 0x%lx\n",
+ (unsigned long)interp->perl,
+ (unsigned long)PERL_GET_CONTEXT,
+ (unsigned long)interp->mip->parent->perl);
+
#if PERL_REVISION == 5 && PERL_VERSION == 8 && PERL_SUBVERSION == 0 && \
defined(USE_REENTRANT_API) && defined(HAS_CRYPT_R) && defined(__GLIBC__)
{
@@ -88,14 +97,15 @@
* within modperl_svptr_table_clone.
*/
if ((clone_flags & CLONEf_KEEP_PTR_TABLE)) {
- dTHXa(interp->perl);
+ pTHX;
+ PERL_SET_CONTEXT(aTHX = interp->perl);
ptr_table_free(PL_ptr_table);
PL_ptr_table = NULL;
}
modperl_interp_clone_init(interp);
- PERL_SET_CONTEXT(perl);
+ //PERL_SET_CONTEXT(perl);
#ifdef MP_USE_GTOP
MP_TRACE_m_do(
@@ -112,12 +122,17 @@
void modperl_interp_destroy(modperl_interp_t *interp)
{
void **handles;
- dTHXa(interp->perl);
-
- PERL_SET_CONTEXT(interp->perl);
+ pTHX;
+ PERL_SET_CONTEXT(aTHX = interp->perl);
- MP_TRACE_i(MP_FUNC, "interp == 0x%lx\n",
- (unsigned long)interp);
+ /* this interp was created when the global PERL_GET_CONTEXT was set to
+ * its parent perl so PERL_GET_CONTEXT must be set to the same value
+ * for the destruction */
+// PERL_SET_CONTEXT(interp->mip->parent->perl);
+
+ MP_TRACE_i(MP_FUNC, "interp == 0x%lx, perl == 0x%lx, PERL_GET_CONTEXT ==
0x%lx\n",
+ (unsigned long)interp, (unsigned long)interp->perl,
+ (unsigned long)PERL_GET_CONTEXT);
if (MpInterpIN_USE(interp)) {
MP_TRACE_i(MP_FUNC, "*error - still in use!*\n");
@@ -238,7 +253,7 @@
mip->server = s;
mip->parent = modperl_interp_new(mip, NULL);
- aTHX = mip->parent->perl = perl;
+ PERL_SET_CONTEXT(aTHX = mip->parent->perl = perl);
/* this happens post-config in mod_perl.c:modperl_init_clones() */
/* modperl_tipool_init(tipool); */
Index: src/modules/perl/modperl_options.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_options.c,v
retrieving revision 1.10
diff -u -r1.10 modperl_options.c
--- src/modules/perl/modperl_options.c 28 Sep 2001 15:16:06 -0000 1.10
+++ src/modules/perl/modperl_options.c 21 Jan 2004 09:56:02 -0000
@@ -42,9 +42,24 @@
options->opts = options->unset =
(type == MpSrvType ? MpSrv_f_UNSET : MpDir_f_UNSET);
+ MP_TRACE_d(MP_FUNC, "opts: %d", options->opts);
+
return options;
}
+
+static void modperl_options_dump(modperl_options_t *o, const char *str)
+{
+ const char *type = type_lookup(o);
+ MP_TRACE_d(MP_FUNC, "option '%s', type: %s", str, type);
+ MP_TRACE_d(MP_FUNC, "opts_add %d", o->opts_add);
+ MP_TRACE_d(MP_FUNC, "opts_remove %d", o->opts_remove);
+ MP_TRACE_d(MP_FUNC, "opts_override %d", o->opts_override);
+ MP_TRACE_d(MP_FUNC, "opts_seen %d", o->opts_seen);
+ MP_TRACE_d(MP_FUNC, "unset %d\n", o->unset);
+}
+
+
const char *modperl_options_set(apr_pool_t *p, modperl_options_t *o,
const char *str)
{
@@ -56,6 +71,8 @@
action = *(str++);
}
+ modperl_options_dump(o, str);
+
if (!(opt = flags_lookup(o, str))) {
error = apr_pstrcat(p, "Invalid per-", type_lookup(o),
" PerlOption: ", str, NULL);
Index: src/modules/perl/modperl_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl.c,v
retrieving revision 1.20
diff -u -r1.20 modperl_perl.c
--- src/modules/perl/modperl_perl.c 3 Nov 2003 23:31:19 -0000 1.20
+++ src/modules/perl/modperl_perl.c 21 Jan 2004 09:56:02 -0000
@@ -101,10 +101,15 @@
{
char **orig_environ = NULL;
PTR_TBL_t *module_commands;
- dTHXa(perl);
-
- PERL_SET_CONTEXT(perl);
+ PerlInterpreter *parent_perl;
+#ifdef USE_ITHREADS
+ pTHX;
+ PERL_SET_CONTEXT(aTHX = perl);
+#endif
+ parent_perl = PERL_GET_CONTEXT;
+// PERL_SET_CONTEXT(perl);
+//PERL_SET_CONTEXT(parent_perl);
PL_perl_destruct_level = modperl_perl_destruct_level();
#ifdef USE_ENVIRON_ARRAY
@@ -134,13 +139,19 @@
}
{
- dTHXa(perl);
+ //dTHXa(perl);
if ((module_commands = modperl_module_config_table_get(aTHX_ FALSE))) {
modperl_svptr_table_destroy(aTHX_ module_commands);
}
}
+ //PERL_SET_CONTEXT(perl);
+ //PERL_SET_CONTEXT(parent_perl);
+ MP_TRACE_i(MP_FUNC, "perl == 0x%lx, PERL_GET_CONTEXT == 0x%lx\n",
+ (unsigned long)perl,
+ (unsigned long)PERL_GET_CONTEXT);
+
perl_destruct(perl);
/* XXX: big bug in 5.6.1 fixed in 5.7.2+
@@ -150,9 +161,13 @@
# define MP_NO_PERL_FREE
#endif
+ //PERL_SET_CONTEXT(parent_perl);
#ifndef MP_NO_PERL_FREE
perl_free(perl);
#endif
+
+ MP_TRACE_i(MP_FUNC, "after: PERL_GET_CONTEXT== 0x%lx\n",
+ (unsigned long)PERL_GET_CONTEXT);
#ifdef USE_ENVIRON_ARRAY
if (orig_environ) {
Index: src/modules/perl/modperl_perl.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl.h,v
retrieving revision 1.14
diff -u -r1.14 modperl_perl.h
--- src/modules/perl/modperl_perl.h 7 Nov 2003 09:04:01 -0000 1.14
+++ src/modules/perl/modperl_perl.h 21 Jan 2004 09:56:02 -0000
@@ -29,4 +29,13 @@
void modperl_hash_seed_set(pTHX);
+#ifdef USE_ITHREADS
+#define MP_THXa(perl) \
+ PERL_SET_CONTEXT(aTHX = perl)
+#else
+#define MP_THXa(perl)
+#endif
+
+#define dTHXCTXa
+
#endif /* MODPERL_PERL_H */
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
>>Ok, so here is a proper patch for modperl_cmd.c. Please try it (attached as
>>well), it's a bit different from the previous one.
>>
>
> Works a treat. The server starts up OK with the vhost test stuff in
> place, and the three conf files still work too.
Thanks Steve. We have missed the PerlRequire case, which would have had the
same problem. I have extended the fix for this hook too.
I've also changed the test name to TestVhost::config as it really deals with
configuration...
Now committed.
We still need to resolve the Apache->server issue.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Stas Bekman wrote:
>
>
>
>>I'll post later a better patch. That one was just a proof of concept.
>>
>>
>
>Ok, so here is a proper patch for modperl_cmd.c. Please try it (attached as
>well), it's a bit different from the previous one.
>
Works a treat. The server starts up OK with the vhost test stuff in
place, and the three conf files still work too.
I have the same test failures as before, details coming separately...
- Steve
>Plus added some macros to
>make the code more readable.
>
>I should add another test that dies if it finds TestVhost::basic loaded by the
>main server. Which is the case now and it's broken due to a problem with
>Apache->server as I've explained in the other thread.
>
>Index: src/modules/perl/modperl_cmd.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
>retrieving revision 1.52
>diff -u -r1.52 modperl_cmd.c
>--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
>+++ src/modules/perl/modperl_cmd.c 22 Jan 2004 10:47:13 -0000
>@@ -1,5 +1,28 @@
> #include "mod_perl.h"
>
>+#ifdef USE_ITHREADS
>+
>+#define MP_PERL_DECLARE_CONTEXT \
>+ PerlInterpreter *orig_perl; \
>+ pTHX;
>+
>+/* XXX: .htaccess support cannot use this perl with threaded MPMs */
>+#define MP_PERL_OVERRIDE_CONTEXT \
>+ orig_perl = PERL_GET_CONTEXT; \
>+ aTHX = scfg->mip->parent->perl; \
>+ PERL_SET_CONTEXT(aTHX);
>+
>+#define MP_PERL_RESTORE_CONTEXT \
>+ PERL_SET_CONTEXT(orig_perl);
>+
>+#else
>+
>+#define MP_PERL_DECLARE_CONTEXT
>+#define MP_PERL_OVERRIDE_CONTEXT
>+#define MP_PERL_RESTORE_CONTEXT
>+
>+#endif
>+
> static char *modperl_cmd_unclosed_directive(cmd_parms *parms)
> {
> return apr_pstrcat(parms->pool, parms->cmd->name,
>@@ -105,6 +128,7 @@
> MP_CMD_SRV_DECLARE(modules)
> {
> MP_dSCFG(parms->server);
>+ MP_PERL_DECLARE_CONTEXT;
>
> if (modperl_is_running() &&
> modperl_init_vhost(parms->server, parms->pool, NULL) != OK)
>@@ -113,22 +137,23 @@
> }
>
> if (modperl_is_running()) {
>-#ifdef USE_ITHREADS
>- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>- dTHXa(scfg->mip->parent->perl);
>-#endif
>- MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
>+ char *error = NULL;
>
>+ MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
>+
>+ MP_PERL_OVERRIDE_CONTEXT;
> if (!modperl_require_module(aTHX_ arg, FALSE)) {
>- return SvPVX(ERRSV);
>+ error = SvPVX(ERRSV);
> }
>- }
>- else {
>- MP_TRACE_d(MP_FUNC, "push PerlModule %s\n", arg);
>- *(const char **)apr_array_push(scfg->PerlModule) = arg;
>+ MP_PERL_RESTORE_CONTEXT;
>+
>+ return error;
> }
>
>+ MP_TRACE_d(MP_FUNC, "push PerlModule %s\n", arg);
>+ *(const char **)apr_array_push(scfg->PerlModule) = arg;
> return NULL;
>+
> }
>
> MP_CMD_SRV_DECLARE(requires)
>@@ -372,9 +397,9 @@
> int dollar_zero_tainted;
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
>- pTHX;
>+ MP_PERL_DECLARE_CONTEXT;
> #endif
>-
>+
> if (!(arg && *arg)) {
> return NULL;
> }
>@@ -386,10 +411,7 @@
> return "init mod_perl vhost failed";
> }
>
>-#ifdef USE_ITHREADS
>- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>- aTHX = scfg->mip->parent->perl;
>-#endif
>+ MP_PERL_OVERRIDE_CONTEXT;
>
> /* data will be set by a <Perl> section */
> if ((options = parms->directive->data)) {
>@@ -443,7 +465,9 @@
> if (SvTRUE(ERRSV)) {
> SV *strict;
> if ((strict = MP_STRICT_PERLSECTIONS_SV) && SvTRUE(strict)) {
>- return SvPVX(ERRSV);
>+ char *error = SvPVX(ERRSV);
>+ MP_PERL_RESTORE_CONTEXT;
>+ return error;
> }
> else {
> modperl_log_warn(s, apr_psprintf(p, "Syntax error at %s:%d %s",
>@@ -473,12 +497,15 @@
> }
>
> if (status != OK) {
>- return SvTRUE(ERRSV) ? SvPVX(ERRSV) :
>+ char *error = SvTRUE(ERRSV) ? SvPVX(ERRSV) :
> apr_psprintf(p, "<Perl> handler %s failed with status=%d",
> handler->name, status);
>+ MP_PERL_RESTORE_CONTEXT;
>+ return error;
> }
> }
>
>+ MP_PERL_RESTORE_CONTEXT;
> return NULL;
> }
>
>@@ -515,7 +542,7 @@
> char line[MAX_STRING_LEN];
>
> while (!ap_cfg_getline(line, sizeof(line), parms->config_file)) {
>- /* soak up rest of the file */
>+ /* soak up rest of the file */
> }
>
> return NULL;
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>------------------------------------------------------------------------
>
>Index: src/modules/perl/modperl_cmd.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
>retrieving revision 1.52
>diff -u -r1.52 modperl_cmd.c
>--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
>+++ src/modules/perl/modperl_cmd.c 22 Jan 2004 10:47:13 -0000
>@@ -1,5 +1,28 @@
> #include "mod_perl.h"
>
>+#ifdef USE_ITHREADS
>+
>+#define MP_PERL_DECLARE_CONTEXT \
>+ PerlInterpreter *orig_perl; \
>+ pTHX;
>+
>+/* XXX: .htaccess support cannot use this perl with threaded MPMs */
>+#define MP_PERL_OVERRIDE_CONTEXT \
>+ orig_perl = PERL_GET_CONTEXT; \
>+ aTHX = scfg->mip->parent->perl; \
>+ PERL_SET_CONTEXT(aTHX);
>+
>+#define MP_PERL_RESTORE_CONTEXT \
>+ PERL_SET_CONTEXT(orig_perl);
>+
>+#else
>+
>+#define MP_PERL_DECLARE_CONTEXT
>+#define MP_PERL_OVERRIDE_CONTEXT
>+#define MP_PERL_RESTORE_CONTEXT
>+
>+#endif
>+
> static char *modperl_cmd_unclosed_directive(cmd_parms *parms)
> {
> return apr_pstrcat(parms->pool, parms->cmd->name,
>@@ -105,6 +128,7 @@
> MP_CMD_SRV_DECLARE(modules)
> {
> MP_dSCFG(parms->server);
>+ MP_PERL_DECLARE_CONTEXT;
>
> if (modperl_is_running() &&
> modperl_init_vhost(parms->server, parms->pool, NULL) != OK)
>@@ -113,22 +137,23 @@
> }
>
> if (modperl_is_running()) {
>-#ifdef USE_ITHREADS
>- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>- dTHXa(scfg->mip->parent->perl);
>-#endif
>- MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
>+ char *error = NULL;
>
>+ MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
>+
>+ MP_PERL_OVERRIDE_CONTEXT;
> if (!modperl_require_module(aTHX_ arg, FALSE)) {
>- return SvPVX(ERRSV);
>+ error = SvPVX(ERRSV);
> }
>- }
>- else {
>- MP_TRACE_d(MP_FUNC, "push PerlModule %s\n", arg);
>- *(const char **)apr_array_push(scfg->PerlModule) = arg;
>+ MP_PERL_RESTORE_CONTEXT;
>+
>+ return error;
> }
>
>+ MP_TRACE_d(MP_FUNC, "push PerlModule %s\n", arg);
>+ *(const char **)apr_array_push(scfg->PerlModule) = arg;
> return NULL;
>+
> }
>
> MP_CMD_SRV_DECLARE(requires)
>@@ -372,9 +397,9 @@
> int dollar_zero_tainted;
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
>- pTHX;
>+ MP_PERL_DECLARE_CONTEXT;
> #endif
>-
>+
> if (!(arg && *arg)) {
> return NULL;
> }
>@@ -386,10 +411,7 @@
> return "init mod_perl vhost failed";
> }
>
>-#ifdef USE_ITHREADS
>- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>- aTHX = scfg->mip->parent->perl;
>-#endif
>+ MP_PERL_OVERRIDE_CONTEXT;
>
> /* data will be set by a <Perl> section */
> if ((options = parms->directive->data)) {
>@@ -443,7 +465,9 @@
> if (SvTRUE(ERRSV)) {
> SV *strict;
> if ((strict = MP_STRICT_PERLSECTIONS_SV) && SvTRUE(strict)) {
>- return SvPVX(ERRSV);
>+ char *error = SvPVX(ERRSV);
>+ MP_PERL_RESTORE_CONTEXT;
>+ return error;
> }
> else {
> modperl_log_warn(s, apr_psprintf(p, "Syntax error at %s:%d %s",
>@@ -473,12 +497,15 @@
> }
>
> if (status != OK) {
>- return SvTRUE(ERRSV) ? SvPVX(ERRSV) :
>+ char *error = SvTRUE(ERRSV) ? SvPVX(ERRSV) :
> apr_psprintf(p, "<Perl> handler %s failed with status=%d",
> handler->name, status);
>+ MP_PERL_RESTORE_CONTEXT;
>+ return error;
> }
> }
>
>+ MP_PERL_RESTORE_CONTEXT;
> return NULL;
> }
>
>@@ -515,7 +542,7 @@
> char line[MAX_STRING_LEN];
>
> while (!ap_cfg_getline(line, sizeof(line), parms->config_file)) {
>- /* soak up rest of the file */
>+ /* soak up rest of the file */
> }
>
> return NULL;
>
>
>
>
>
>------------------------------------------------------------------------
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> I'll post later a better patch. That one was just a proof of concept.
Ok, so here is a proper patch for modperl_cmd.c. Please try it (attached as
well), it's a bit different from the previous one. Plus added some macros to
make the code more readable.
I should add another test that dies if it finds TestVhost::basic loaded by the
main server. Which is the case now and it's broken due to a problem with
Apache->server as I've explained in the other thread.
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.52
diff -u -r1.52 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 22 Jan 2004 10:47:13 -0000
@@ -1,5 +1,28 @@
#include "mod_perl.h"
+#ifdef USE_ITHREADS
+
+#define MP_PERL_DECLARE_CONTEXT \
+ PerlInterpreter *orig_perl; \
+ pTHX;
+
+/* XXX: .htaccess support cannot use this perl with threaded MPMs */
+#define MP_PERL_OVERRIDE_CONTEXT \
+ orig_perl = PERL_GET_CONTEXT; \
+ aTHX = scfg->mip->parent->perl; \
+ PERL_SET_CONTEXT(aTHX);
+
+#define MP_PERL_RESTORE_CONTEXT \
+ PERL_SET_CONTEXT(orig_perl);
+
+#else
+
+#define MP_PERL_DECLARE_CONTEXT
+#define MP_PERL_OVERRIDE_CONTEXT
+#define MP_PERL_RESTORE_CONTEXT
+
+#endif
+
static char *modperl_cmd_unclosed_directive(cmd_parms *parms)
{
return apr_pstrcat(parms->pool, parms->cmd->name,
@@ -105,6 +128,7 @@
MP_CMD_SRV_DECLARE(modules)
{
MP_dSCFG(parms->server);
+ MP_PERL_DECLARE_CONTEXT;
if (modperl_is_running() &&
modperl_init_vhost(parms->server, parms->pool, NULL) != OK)
@@ -113,22 +137,23 @@
}
if (modperl_is_running()) {
-#ifdef USE_ITHREADS
- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
- dTHXa(scfg->mip->parent->perl);
-#endif
- MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
+ char *error = NULL;
+ MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
+
+ MP_PERL_OVERRIDE_CONTEXT;
if (!modperl_require_module(aTHX_ arg, FALSE)) {
- return SvPVX(ERRSV);
+ error = SvPVX(ERRSV);
}
- }
- else {
- MP_TRACE_d(MP_FUNC, "push PerlModule %s\n", arg);
- *(const char **)apr_array_push(scfg->PerlModule) = arg;
+ MP_PERL_RESTORE_CONTEXT;
+
+ return error;
}
+ MP_TRACE_d(MP_FUNC, "push PerlModule %s\n", arg);
+ *(const char **)apr_array_push(scfg->PerlModule) = arg;
return NULL;
+
}
MP_CMD_SRV_DECLARE(requires)
@@ -372,9 +397,9 @@
int dollar_zero_tainted;
#ifdef USE_ITHREADS
MP_dSCFG(s);
- pTHX;
+ MP_PERL_DECLARE_CONTEXT;
#endif
-
+
if (!(arg && *arg)) {
return NULL;
}
@@ -386,10 +411,7 @@
return "init mod_perl vhost failed";
}
-#ifdef USE_ITHREADS
- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
- aTHX = scfg->mip->parent->perl;
-#endif
+ MP_PERL_OVERRIDE_CONTEXT;
/* data will be set by a <Perl> section */
if ((options = parms->directive->data)) {
@@ -443,7 +465,9 @@
if (SvTRUE(ERRSV)) {
SV *strict;
if ((strict = MP_STRICT_PERLSECTIONS_SV) && SvTRUE(strict)) {
- return SvPVX(ERRSV);
+ char *error = SvPVX(ERRSV);
+ MP_PERL_RESTORE_CONTEXT;
+ return error;
}
else {
modperl_log_warn(s, apr_psprintf(p, "Syntax error at %s:%d %s",
@@ -473,12 +497,15 @@
}
if (status != OK) {
- return SvTRUE(ERRSV) ? SvPVX(ERRSV) :
+ char *error = SvTRUE(ERRSV) ? SvPVX(ERRSV) :
apr_psprintf(p, "<Perl> handler %s failed with status=%d",
handler->name, status);
+ MP_PERL_RESTORE_CONTEXT;
+ return error;
}
}
+ MP_PERL_RESTORE_CONTEXT;
return NULL;
}
@@ -515,7 +542,7 @@
char line[MAX_STRING_LEN];
while (!ap_cfg_getline(line, sizeof(line), parms->config_file)) {
- /* soak up rest of the file */
+ /* soak up rest of the file */
}
return NULL;
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> I also have a couple of test failures, including one from the vhost test
> itself:
>
> Failed Test Stat Wstat Total Fail Failed List of Failed
> --------------------------------------------------------------------
> api\server_util.t 24 10 41.67% 4-13
> compat\apache.t 16 2 12.50% 14-15
> modperl\perl_options.t 9 2304 ?? ?? % ??
> vhost\basic.t 1 1 100.00% 1
> 8 tests and 7 subtests skipped.
>
> but it's immeasurably better than it was ;)
Thanks, Steve ;) The usual drill please - run these with -v and send the
output of the client side and the error_log file. thanks.
>>p.s. I suppose the 3 short config test cases are working too, since the
>>vhost::basic setup seems to cover them all. but please test just in case.
>>
>
> Yes, I tested these as well. All three work fine (that's starting up
> the server too, not just running the "-t" test).
Great.
> Well done to Stas and Jan for resolving this issue at long last.
;) Thanks for patiently testing again and again ;)
I'll post later a better patch. That one was just a proof of concept.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Randy Kobes wrote:
>
>
>>On Wed, 21 Jan 2004, Stas Bekman wrote:
>>
>>
>>
>>
>>>Stas Bekman wrote:
>>>
>>>
>>>
>>>>It looks like Jan's patch allows me to reproduce the problems that you
>>>>see. So if that's true, we will be all set shortly. So don't waste your
>>>>time on testing things I've asked to. I'll keep you posted. Thanks.
>>>>
>>>>
>>>It's so much happier when things fail ;)
>>>
>>>Here is what happening:
>>>
>>>
>>[ ... ]
>>
>>
>>
>>>This is most likely not the final solution, but my guess
>>>is that the following patch resolves all the short conf
>>>and the whole TestVhost::basic problems.
>>>
>>>
>>And it does! Great work, Stas!
>>
>>
>
>Great news, Randy! You should really thank Jan, without whom we would have
>been doing the guess work for a long long time.
>
>Meanwhile I'm working on a proper patch.
>
It works for me too. (I tested with the patch that you sent off-list,
Stas.)
>
>
>
>>There's a couple of problems with some of the tests - a
>>quick glance indicates some of this is from comparing Unix
>>to Win32 file names (/ vs \), which we've run into before.
>>But I'll save that for another "thread" ...
>>
>>
>
>Sure ;)
>
>Thanks for testing!
>
I also have a couple of test failures, including one from the vhost test
itself:
Failed Test Stat Wstat Total Fail Failed List of Failed
--------------------------------------------------------------------
api\server_util.t 24 10 41.67% 4-13
compat\apache.t 16 2 12.50% 14-15
modperl\perl_options.t 9 2304 ?? ?? % ??
vhost\basic.t 1 1 100.00% 1
8 tests and 7 subtests skipped.
but it's immeasurably better than it was ;)
>
>p.s. I suppose the 3 short config test cases are working too, since the
>vhost::basic setup seems to cover them all. but please test just in case.
>
Yes, I tested these as well. All three work fine (that's starting up
the server too, not just running the "-t" test).
Well done to Stas and Jan for resolving this issue at long last.
- Steve
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 21 Jan 2004, Stas Bekman wrote:
>
>
>>Stas Bekman wrote:
>>
>>>It looks like Jan's patch allows me to reproduce the problems that you
>>>see. So if that's true, we will be all set shortly. So don't waste your
>>>time on testing things I've asked to. I'll keep you posted. Thanks.
>>
>>It's so much happier when things fail ;)
>>
>>Here is what happening:
>
> [ ... ]
>
>>This is most likely not the final solution, but my guess
>>is that the following patch resolves all the short conf
>>and the whole TestVhost::basic problems.
>
>
> And it does! Great work, Stas!
Great news, Randy! You should really thank Jan, without whom we would have
been doing the guess work for a long long time.
Meanwhile I'm working on a proper patch.
> There's a couple of problems with some of the tests - a
> quick glance indicates some of this is from comparing Unix
> to Win32 file names (/ vs \), which we've run into before.
> But I'll save that for another "thread" ...
Sure ;)
Thanks for testing!
p.s. I suppose the 3 short config test cases are working too, since the
vhost::basic setup seems to cover them all. but please test just in case.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 21 Jan 2004, Stas Bekman wrote:
> Stas Bekman wrote:
> > It looks like Jan's patch allows me to reproduce the problems that you
> > see. So if that's true, we will be all set shortly. So don't waste your
> > time on testing things I've asked to. I'll keep you posted. Thanks.
>
> It's so much happier when things fail ;)
>
> Here is what happening:
[ ... ]
> This is most likely not the final solution, but my guess
> is that the following patch resolves all the short conf
> and the whole TestVhost::basic problems.
And it does! Great work, Stas!
There's a couple of problems with some of the tests - a
quick glance indicates some of this is from comparing Unix
to Win32 file names (/ vs \), which we've run into before.
But I'll save that for another "thread" ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> It looks like Jan's patch allows me to reproduce the problems that you
> see. So if that's true, we will be all set shortly. So don't waste your
> time on testing things I've asked to. I'll keep you posted. Thanks.
It's so much happier when things fail ;)
Here is what happening:
<VirtualHost _default_:8530>
PerlOptions +Parent
<Perl>
use Apache::ServerUtil;
my $s = Apache->server;
$s->add_config(['PerlModule Whatever']);
</Perl>
</VirtualHost>
There are two contexts here. Base and vhost contexts. When <perl> section is
entered the context switches to vhost perl. and (with my recent patch)
everything is cool, untill we hit:
my $s = Apache->server;
which doesn't return the vhost server record, but the global server record!
When we next call:
$s->add_config(['PerlModule Whatever']);
it switches context to the base server context, allocating things from it when
'PerlModule' is alled, causing the 'free' problem. If I do:
- dTHXa(scfg->mip->parent->perl);
+ dTHXa(PERL_GET_CONTEXT);
which ignores $s and uses the context set by the <Perl> sections (vhost
context) everything rolls.
This is most likely not the final solution, but my guess is that the following
patch resolves all the short conf and the whole TestVhost::basic problems.
This patch includes both the workaround and the TestVhost::basic test.
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.52
diff -u -u -r1.52 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 22 Jan 2004 06:22:11 -0000
@@ -114,8 +114,13 @@
if (modperl_is_running()) {
#ifdef USE_ITHREADS
- /* XXX: .htaccess support cannot use this perl with threaded MPMs */
- dTHXa(scfg->mip->parent->perl);
+ /* XXX: .htaccess support cannot use this perl with threaded MPMs */
+ dTHXa(PERL_GET_CONTEXT);
+ /* dTHXa(scfg->mip->parent->perl); */
+ MP_TRACE_d(MP_FUNC,
+ "using mip_perl=0x%lx, my_perl=0x%lx, PL_curinterp=0x%lx\n",
+ (PerlInterpreter *)scfg->mip->parent->perl, aTHX,
+ PERL_GET_CONTEXT);
#endif
MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -373,6 +378,7 @@
#ifdef USE_ITHREADS
MP_dSCFG(s);
pTHX;
+ PerlInterpreter *orig_perl;
#endif
if (!(arg && *arg)) {
@@ -388,7 +394,9 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
+ orig_perl = PERL_GET_CONTEXT;
aTHX = scfg->mip->parent->perl;
+ PERL_SET_CONTEXT(aTHX);
#endif
/* data will be set by a <Perl> section */
@@ -478,6 +486,11 @@
handler->name, status);
}
}
+
+#ifdef USE_ITHREADS
+ /* restore the original perl context */
+ PERL_SET_CONTEXT(orig_perl);
+#endif
return NULL;
}
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/htdocs/vhost/startup.pl 2004-01-21 15:44:34.000000000 -0800
@@ -0,0 +1,32 @@
+use warnings;
+use strict;
+
+use Apache2;
+use Apache::ServerUtil ();
+use Apache::Server ();
+
+use File::Spec::Functions qw(catdir);
+
+# base server
+my $s = Apache->server;
+
+my $vhost_doc_root = catdir Apache::Server::server_root, qw(htdocs vhost);
+
+# testing $s->add_config() in vhost
+my $conf = <<"EOC";
+# must use PerlModule here to check for segfaults
+# (even though it's not required)
+PerlModule TestVhost::basic
+PerlSetVar DocumentRootCheck $vhost_doc_root
+<Location /TestVhost__basic>
+ SetHandler modperl
+ PerlResponseHandler TestVhost::basic
+</Location>
+EOC
+
+$s->add_config([split /\n/, $conf]);
+
+# this used to have problems on win32
+$s->add_config(['<Perl >', '1;', '</Perl>']);
+
+1;
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/response/TestVhost/basic.pm 2004-01-21 21:29:51.000000000 -0800
@@ -0,0 +1,59 @@
+package TestVhost::basic;
+
+# Test whether vhost with 'PerlOptions +Parent', which doesn't inherit
+# from the base, has its own INC and therefore can have a modules with
+# the same namespace as the base, but different content.
+#
+# Also see the parallel TestDirective::perlmodule handler
+
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+
+use Apache::RequestUtil ();
+use APR::Table ();
+
+use File::Spec::Functions qw(catdir);
+
+use Apache::Const -compile => 'OK';
+
+sub handler {
+ my $r = shift;
+
+ plan $r, tests => 1;
+
+ {
+ my $expected = $r->document_root;
+ my $received = $r->dir_config->get('DocumentRootCheck');
+ ok t_cmp($expected, $received, "DocumentRoot");
+ }
+
+ Apache::OK;
+}
+
+1;
+__END__
+<NoAutoConfig>
+<VirtualHost TestVhost::basic>
+ DocumentRoot @documentroot@/vhost
+
+ <IfDefine PERL_USEITHREADS>
+ # a new interpreter pool
+ PerlOptions +Parent
+ </IfDefine>
+
+ # use test system's @INC
+ PerlSwitches -I@serverroot@
+
+ # mp2 modules
+ PerlRequire "@serverroot@/conf/modperl_inc.pl"
+
+ # private to this vhost stuff
+ PerlRequire "@documentroot@/vhost/startup.pl"
+
+ # <Location /TestVhost__basic> container is added via add_config
+ # in t/htdocs/vhost/startup.pl
+</VirtualHost>
+</NoAutoConfig>
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/vhost/basic.t 2004-01-21 15:51:20.000000000 -0800
@@ -0,0 +1,33 @@
+# the handler is configured in modperl_extra.pl via
+# Apache->server->add_config
+
+use Apache::TestUtil;
+use Apache::TestRequest 'GET';
+
+my $config = Apache::Test::config();
+my $vars = $config->{vars};
+
+my $module = 'TestVhost::basic';
+my $path = Apache::TestRequest::module2path($module);
+
+Apache::TestRequest::module($module);
+my $hostport = Apache::TestRequest::hostport($config);
+
+t_debug("connecting to $hostport");
+my $res = GET "http://$hostport/$path";
+
+if ($res->is_success) {
+ print $res->content;
+}
+else {
+ if ($res->code == 404) {
+ my $docroot = $vars->{documentroot};
+ die "this test gets its <Location> configuration added via " .
+ "$documentroot/vhost/startup.pl, this could be the cause " .
+ "of the failure";
+ }
+ else {
+ die "server side has failed (response code: ", $res->code, "),\n",
+ "see t/logs/error_log for more details\n";
+ }
+}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
It looks like Jan's patch allows me to reproduce the problems that you see. So
if that's true, we will be all set shortly. So don't waste your time on
testing things I've asked to. I'll keep you posted. Thanks.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> This patch wouldn't compile for me - I get the errors
>
> cd "src/modules/perl" && NMAKE -f Makefile.modperl
[...]
> Does this make sense? Or might it be a mis-applied
> patch (although I did double-check it).
Yes, sorry, the usual declaration problem:
> + orig_perl = PERL_GET_CONTEXT;
> dTHXa(scfg->mip->parent->perl);
but please put it away till I get back.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 21 Jan 2004, Stas Bekman wrote:
> And here are two more patches to try (all against the
> fresh cvs). This is similar to one successful path that
> changes and restores context inside perldo
> (Apache::PerlSections).
>
> The first one adds the setting of the context inside modules
> (PerlModule/PerlLoadModule) though it doesn't restore it. The second one
> restores it as well.
>
> Index: src/modules/perl/modperl_cmd.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
> retrieving revision 1.52
> diff -u -r1.52 modperl_cmd.c
> --- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
> +++ src/modules/perl/modperl_cmd.c 22 Jan 2004 00:55:18 -0000
> @@ -116,6 +116,7 @@
> #ifdef USE_ITHREADS
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> dTHXa(scfg->mip->parent->perl);
> + PERL_SET_CONTEXT(aTHX);
> #endif
> MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
>
> @@ -373,6 +374,7 @@
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
> pTHX;
> + PerlInterpreter *orig_perl;
> #endif
>
> if (!(arg && *arg)) {
> @@ -388,7 +390,9 @@
>
> #ifdef USE_ITHREADS
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> + orig_perl = PERL_GET_CONTEXT;
> aTHX = scfg->mip->parent->perl;
> + PERL_SET_CONTEXT(aTHX);
> #endif
>
> /* data will be set by a <Perl> section */
> @@ -479,6 +483,11 @@
> }
> }
>
> +#ifdef USE_ITHREADS
> + /* restore the original perl context */
> + PERL_SET_CONTEXT(orig_perl);
> +#endif
> +
> return NULL;
> }
>
This patch for me, applied (manually) against the current
mp2 cvs sources and with the updated vhost test patch you
recently sent, fails for me on startup with the "free
to wrong pool" error. This is with ActivePerl 808, based
on perl-5.8.2 (with some ActiveState patches).
> The second patch:
>
> Index: src/modules/perl/modperl_cmd.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
> retrieving revision 1.52
> diff -u -r1.52 modperl_cmd.c
> --- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
> +++ src/modules/perl/modperl_cmd.c 22 Jan 2004 01:07:35 -0000
> @@ -105,7 +105,10 @@
> MP_CMD_SRV_DECLARE(modules)
> {
> MP_dSCFG(parms->server);
> -
> +#ifdef USE_ITHREADS
> + PerlInterpreter *orig_perl;
> +#endif
> +
> if (modperl_is_running() &&
> modperl_init_vhost(parms->server, parms->pool, NULL) != OK)
> {
> @@ -115,7 +118,9 @@
> if (modperl_is_running()) {
> #ifdef USE_ITHREADS
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> + orig_perl = PERL_GET_CONTEXT;
> dTHXa(scfg->mip->parent->perl);
> + PERL_SET_CONTEXT(aTHX);
> #endif
> MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
>
> @@ -128,6 +133,11 @@
> *(const char **)apr_array_push(scfg->PerlModule) = arg;
> }
>
> +#ifdef USE_ITHREADS
> + /* restore the original perl context */
> + PERL_SET_CONTEXT(orig_perl);
> +#endif
> +
> return NULL;
> }
>
> @@ -373,6 +383,7 @@
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
> pTHX;
> + PerlInterpreter *orig_perl;
> #endif
>
> if (!(arg && *arg)) {
> @@ -388,7 +399,9 @@
>
> #ifdef USE_ITHREADS
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
> + orig_perl = PERL_GET_CONTEXT;
> aTHX = scfg->mip->parent->perl;
> + PERL_SET_CONTEXT(aTHX);
> #endif
>
> /* data will be set by a <Perl> section */
> @@ -479,6 +492,11 @@
> }
> }
>
> +#ifdef USE_ITHREADS
> + /* restore the original perl context */
> + PERL_SET_CONTEXT(orig_perl);
> +#endif
> +
> return NULL;
> }
>
This patch wouldn't compile for me - I get the errors
cd "src/modules/perl" && NMAKE -f Makefile.modperl
cl -ID:/unzipped/MODPER~1.0/src/modules/perl
-ID:/unzipped/MODPER~1.0/xs -ID:\Apache2\include
-ID:/Apache2/include -nologo -Gf -W3 -MD -DNDEBUG -O1
-DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT
-DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS
-DUSE_PERLIO -DPERL_MSVCRT_READFIX -I"D:\Perl\lib\CORE"
-DMOD_PERL -DMP_COMPAT_1X -MD -DNDEBUG -O1 -c modperl_cmd.c
&& D:\Perl\bin\perl.exe -MExtUtils::Command -e mv
modperl_cmd.obj modperl_cmd.lo modperl_cmd.c
modperl_cmd.c(124) : error C2143: syntax error : missing ';' before 'type'
modperl_cmd.c(125) : error C2065: 'my_perl' : undeclared identifier
modperl_cmd.c(125) : warning C4022: 'Perl_set_context' :
pointer mismatch for actual parameter 1
modperl_cmd.c(129) : warning C4047: 'function' : 'struct
interpreter *' differs in levels of indirection from 'int '
modperl_cmd.c(129) : warning C4024: 'modperl_require_module'
: different types for formal and actual parameter 1
modperl_cmd.c(130) : warning C4047: 'function' : 'struct
interpreter *' differs in levels of indirection from 'int '
modperl_cmd.c(130) : warning C4024: 'Perl_Ierrgv_ptr' :
different types for formal and actual parameter 1
modperl_cmd.c(146) : error C2059: syntax error : 'const'
Does this make sense? Or might it be a mis-applied
patch (although I did double-check it).
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
And here are two more patches to try (all against the fresh cvs). This is
similar to one successful path that changes and restores context inside perldo
(Apache::PerlSections).
The first one adds the setting of the context inside modules
(PerlModule/PerlLoadModule) though it doesn't restore it. The second one
restores it as well.
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.52
diff -u -r1.52 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 22 Jan 2004 00:55:18 -0000
@@ -116,6 +116,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(aTHX);
#endif
MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -373,6 +374,7 @@
#ifdef USE_ITHREADS
MP_dSCFG(s);
pTHX;
+ PerlInterpreter *orig_perl;
#endif
if (!(arg && *arg)) {
@@ -388,7 +390,9 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
+ orig_perl = PERL_GET_CONTEXT;
aTHX = scfg->mip->parent->perl;
+ PERL_SET_CONTEXT(aTHX);
#endif
/* data will be set by a <Perl> section */
@@ -479,6 +483,11 @@
}
}
+#ifdef USE_ITHREADS
+ /* restore the original perl context */
+ PERL_SET_CONTEXT(orig_perl);
+#endif
+
return NULL;
}
The second patch:
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.52
diff -u -r1.52 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 22 Jan 2004 01:07:35 -0000
@@ -105,7 +105,10 @@
MP_CMD_SRV_DECLARE(modules)
{
MP_dSCFG(parms->server);
-
+#ifdef USE_ITHREADS
+ PerlInterpreter *orig_perl;
+#endif
+
if (modperl_is_running() &&
modperl_init_vhost(parms->server, parms->pool, NULL) != OK)
{
@@ -115,7 +118,9 @@
if (modperl_is_running()) {
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
+ orig_perl = PERL_GET_CONTEXT;
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(aTHX);
#endif
MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -128,6 +133,11 @@
*(const char **)apr_array_push(scfg->PerlModule) = arg;
}
+#ifdef USE_ITHREADS
+ /* restore the original perl context */
+ PERL_SET_CONTEXT(orig_perl);
+#endif
+
return NULL;
}
@@ -373,6 +383,7 @@
#ifdef USE_ITHREADS
MP_dSCFG(s);
pTHX;
+ PerlInterpreter *orig_perl;
#endif
if (!(arg && *arg)) {
@@ -388,7 +399,9 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
+ orig_perl = PERL_GET_CONTEXT;
aTHX = scfg->mip->parent->perl;
+ PERL_SET_CONTEXT(aTHX);
#endif
/* data will be set by a <Perl> section */
@@ -479,6 +492,11 @@
}
}
+#ifdef USE_ITHREADS
+ /* restore the original perl context */
+ PERL_SET_CONTEXT(orig_perl);
+#endif
+
return NULL;
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Jan Dubois wrote:
> On Wed, 21 Jan 2004 16:28:45 -0800, Stas Bekman <st...@stason.org> wrote:
>
>
>>Steve Hay wrote:
>>[...]
>>BTW, if you've read my request to p5p, I don't think the perl_destruct traces
>>(on the infamous error) are of any good use. Since they just tell that there
>>is a problem, but they don't say where. winFU-perl needs to spot the problem
>>when it's created and not when the perl exits. So as you could see from my
>>last patch, restoring the context fixes some things. So ideally i want
>>winFU-perl pin-point that place in the code where the context was wrong.
>
>
> It is really hard to detect where the problem is created: whenever you
> store a pointer to some memory you may be creating an invalid cross-link
> between 2 interpreters. This can be anything, from allocating a new SV
> for an RV, allocating or growing a PVX or changing magic attached to an
> SV. There are an awful lot of places in sv.c alone that store memory
> pointers in structures. Each of them can be the culprit if called in
> the wrong context.
>
> In general, the code in threads::shared is especially suspect because it
> has to deal with marshaling data from one interpreter to the other. It
> is very important to always use the correct context, as even innocent
> looking code like SvPV_nolen(sv) called in the wrong context can result
> in the PVX being allocated from the wrong pool.
Yup, and modperl-2.0 is very similar to threads::shared, and even more
complex. So we have to deal with the same problems.
> Sorry, I have no good suggestion how to deal with this problem beyond
> looking at what the "freed" memory block contains.
I can see your followup on p5p, let's continue there.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Jan Dubois <ja...@ActiveState.com>.
On Wed, 21 Jan 2004 16:28:45 -0800, Stas Bekman <st...@stason.org> wrote:
>Steve Hay wrote:
>[...]
>BTW, if you've read my request to p5p, I don't think the perl_destruct traces
>(on the infamous error) are of any good use. Since they just tell that there
>is a problem, but they don't say where. winFU-perl needs to spot the problem
>when it's created and not when the perl exits. So as you could see from my
>last patch, restoring the context fixes some things. So ideally i want
>winFU-perl pin-point that place in the code where the context was wrong.
It is really hard to detect where the problem is created: whenever you
store a pointer to some memory you may be creating an invalid cross-link
between 2 interpreters. This can be anything, from allocating a new SV
for an RV, allocating or growing a PVX or changing magic attached to an
SV. There are an awful lot of places in sv.c alone that store memory
pointers in structures. Each of them can be the culprit if called in
the wrong context.
In general, the code in threads::shared is especially suspect because it
has to deal with marshaling data from one interpreter to the other. It
is very important to always use the correct context, as even innocent
looking code like SvPV_nolen(sv) called in the wrong context can result
in the PVX being allocated from the wrong pool.
Sorry, I have no good suggestion how to deal with this problem beyond
looking at what the "freed" memory block contains.
Cheers,
-Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> OK, here's another short conf file which does now break again:
>
> =====
> LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
> ServerName localhost:8529
> Listen 8529
> ServerRoot C:/Temp/modperl-2.0/t
> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
> LogLevel debug
> Listen 8530
> <VirtualHost _default_:8530>
> PerlOptions +Parent
> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
> PerlSwitches -IC:/Temp/modperl-2.0/t/response
> PerlModule Apache::ServerUtil
> <Perl>
> my $s = Apache->server;
> $s->add_config(['PerlModule TestVhost::basic']);
> </Perl>
> </VirtualHost>
> =====
>
> The add_config() call there is taken from the t/htdocs/vhost/startup.pl,
> part of the vhost test patch that still breaks. Note that the above
> conf breaks (in the usual way) with seemingly *any* module in place of
> TestVhost::basic -- I tried Apache, File::Spec, CGI, DBI and a few
> others and they all broke.
> I'm testing with the latest CVS, plus the first of Stas' recent patches
> (the one here:
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107465681330157&w=2).
>
> With the above conf file, the following "-t" command-line fails with the
> good ol' "free to wrong pool" error:
>
> C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t -f
> C:/Temp/modperl-2.0/t/conf/httpd.conf.short3 -DAPACHE2 -DPERL_USEITHREADS
>
> It can be "fixed" by just commenting-out the add_config() call in the
> <Perl> section. (Indeed, without that add_config() call the server can
> be started up for real without the "-t" option.)
Thanks Steve, how about this config. I bet it breaks just the same.
....
<VirtualHost _default_:8530>
PerlOptions +Parent
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlSwitches -IC:/Temp/modperl-2.0/t/response
PerlModule Apache::ServerUtil
<Perl>
use Apache::ServerUtil;
use Apache::Log;
my $s = Apache->server;
$s->log_error('Trulala');
</Perl>
</VirtualHost>
And what about this:
....
<VirtualHost _default_:8530>
PerlOptions +Parent
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlSwitches -IC:/Temp/modperl-2.0/t/response
PerlModule Apache::ServerUtil
<Perl>
use Apache::Log;
Apache::warn("Oh la la");
</Perl>
</VirtualHost>
> Here's a stacktrace of the failure:
Thanks
BTW, if you've read my request to p5p, I don't think the perl_destruct traces
(on the infamous error) are of any good use. Since they just tell that there
is a problem, but they don't say where. winFU-perl needs to spot the problem
when it's created and not when the perl exits. So as you could see from my
last patch, restoring the context fixes some things. So ideally i want
winFU-perl pin-point that place in the code where the context was wrong.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>Steve Hay wrote:
>
>
>
>>>>The Bad News: The vhost test that originally didn't work way back at
>>>>the start of this thread (excuse the pun) still doesn't work.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>can't you pin-point which part of
>>>that patch causes the problem? I assume the problem is the same, right?
>>>
>>>
>>>
>>>
>>>
>>It is indeed the usual problem. I'll try produce another shortened
>>.conf file which reproduces the bug that's still lurking. Oh joy.
>>
>>
>>
>OK, here's another short conf file which does now break again:
>
>=====
>LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
>ServerName localhost:8529
>Listen 8529
>ServerRoot C:/Temp/modperl-2.0/t
>DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>LogLevel debug
>Listen 8530
><VirtualHost _default_:8530>
> PerlOptions +Parent
> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
> PerlSwitches -IC:/Temp/modperl-2.0/t/response
> PerlModule Apache::ServerUtil
> <Perl>
> my $s = Apache->server;
> $s->add_config(['PerlModule TestVhost::basic']);
> </Perl>
></VirtualHost>
>=====
>
I've just tried the above conf file with the Stas' big patch (just here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107467915115257&w=2)
applied as well as the earlier patch to save/restore the context in
MP_CMD_SRV_DECLARE(perldo).
As reported before it still doesn't fix things, but that big patch does
add some more trace output which might be helpful. Here it is, running
the above conf file with the "-t" option:
=====
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
C:/Temp/modperl-2.0/t -f C:/
Temp/modperl-2.0/t/conf/httpd.conf.short3 -DAPACHE2 -DPERL_USEITHREADS
mod_perl trace flags dump:
a Off (Apache API interaction)
c On (configuration for directive handlers)
d On (directive processing)
e Off (environment variables)
f Off (filters)
g On (Perl runtime interaction)
h On (handlers)
i On (interpreter pool management)
m On (memory allocations)
o On (I/O)
s On (perl sections)
t Off (benchmark-ish timings)
mod_perl.c:455: mod_perl globals are configured
modperl_global.c:88: init pconf
modperl_global.c:88: init threaded_mpm
modperl_global.c:88: init server_rec
modperl_config.c:187: p=0x28ab20, s=0x82c4d8, virtual=0
modperl_options.c:45: opts: 16
modperl_config.c:137: new dcfg: 0x84fd68
modperl_options.c:45: opts: 16
modperl_config.c:137: new dcfg: 0x850cb0
modperl_options.c:45: opts: 33554432
modperl_config.c:121: new scfg: 0x850f70
modperl_config.c:187: p=0x28ab20, s=0x850938, virtual=1
modperl_cmd.c:257: C:/Temp/modperl-2.0/t/conf/httpd.conf.short3:9
modperl_cmd.c:259: arg = +Parent
modperl_options.c:54: option 'Parent', type: server
modperl_options.c:55: opts_add 0
modperl_options.c:56: opts_remove 0
modperl_options.c:57: opts_override 0
modperl_options.c:58: opts_seen 0
modperl_options.c:59: unset 33554432
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/Apache-Test/lib
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/blib/lib
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/blib/arch
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/t/response
modperl_cmd.c:127: push PerlModule Apache::ServerUtil
modperl_cmd.c:389: push PerlModule Apache::PerlSections
MpSrv flags dump (localhost):
Access On
Authen On
Authz On
Autoload Off
ChildExit On
ChildInit On
Cleanup On
Clone Off
Enable On
Fixup On
HeaderParser On
InputFilter On
Log On
MapToStorage On
MergeHandlers Off
OpenLogs On
OutputFilter On
Parent Off
PostConfig On
PostReadRequest On
PreConnection On
ProcessConnection On
Response On
Trans On
Type On
Unset On
mod_perl.c:168: starting the parent perl for the base server
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -e;0
modperl_interp.c:247: server=localhost:8529
modperl_interp.c:117: 0x925ce8
mod_perl.c:237: constructed interpreter=0x26441c
mod_perl.c:288: Init vhost (null):8530: s=0x850938, base_s=0x82c4d8
MpSrv flags dump ((null)):
Access On
Authen On
Authz On
Autoload Off
ChildExit On
ChildInit On
Cleanup On
Clone Off
Enable On
Fixup On
HeaderParser On
InputFilter On
Log On
MapToStorage On
MergeHandlers Off
OpenLogs On
OutputFilter On
Parent On
PostConfig On
PostReadRequest On
PreConnection On
ProcessConnection On
Response On
Trans On
Type On
Unset On
mod_perl.c:172: starting the parent perl for vhost (null):8530
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -IC:/Temp/modperl-2.0/Apache-Test/lib
2 = -IC:/Temp/modperl-2.0/blib/lib
3 = -IC:/Temp/modperl-2.0/blib/arch
4 = -IC:/Temp/modperl-2.0/t/response
5 = -e;0
modperl_interp.c:247: server=(null):8530
modperl_interp.c:117: 0x9b68f8
mod_perl.c:237: constructed interpreter=0x9a4154
modperl_config.c:341: loaded Perl module Apache::ServerUtil for server
(null):85
30
mod_perl.c:327: created parent interpreter for VirtualHost (null):8530
mod_perl.c:288: Init vhost (null):8530: s=0x850938, base_s=0x82c4d8
mod_perl.c:308: server (null):8530 already initialized
modperl_cmd.c:407: perl == 0x9a4154, PERL_GET_CONTEXT == 0x9a4154
modperl_handler.c:23: [1788/1936] new handler Apache::PerlSections
mod_perl.c:288: Init vhost localhost:8529: s=0x82c4d8, base_s=0x82c4d8
mod_perl.c:292: base server is not vhost, skipping localhost:8529
modperl_cmd.c:120: load PerlModule TestVhost::basic
modperl_util.c:160: sv_setref_pv(Apache::CmdParms, 0x6fec8)
modperl_handler.c:75: dup handler Apache::PerlSections
modperl_handler.c:23: [1788/1936] new handler Apache::PerlSections
MpHandler flags dump (Apache::PerlSections):
Anon Off
Autoload Off
Dynamic Off
Fake Off
Method Off
Object Off
Parsed Off
modperl_handler.c:52: [1788/1936 (null):8530] handler
Apache::PerlSections was n
ot compiled at startup, attempting to resolve using current pool 0x28ab20
modperl_mgv.c:297: package Apache::PerlSections not in %INC, attempting
to load
'Apache/PerlSections.pm'
modperl_mgv.c:302: loaded Apache::PerlSections package
modperl_mgv.c:341: [1788/1936] found `handler' in class
`Apache::PerlSections' a
s a method
modperl_options.c:45: opts: 33554432
modperl_config.c:121: new scfg: 0x851ca0
modperl_config.c:220: basev==0x84f8a8, addv==0x850f70
modperl_options.c:45: opts: 16
mod_perl.c:288: Init vhost (null):8530: s=0x850938, base_s=0x82c4d8
mod_perl.c:308: server (null):8530 already initialized
modperl_options.c:45: opts: 16
modperl_config.c:137: new dcfg: 0x8524d0
modperl_config.c:63: basev==0x84fd68, addv==0x850cb0
modperl_options.c:45: opts: 16
Syntax OK
modperl_interp.c:196: parent == 0x9b68f8
modperl_interp.c:134: interp == 0x9b68f8, perl == 0x9a4154,
PERL_GET_CONTEXT ==
0x9a4154
modperl_util.c:352: Apache::ServerUtil dl handle == 0x3a0000
modperl_util.c:352: Apache::CmdParms dl handle == 0x3c0000
modperl_util.c:352: Apache::Directive dl handle == 0x3d0000
modperl_util.c:352: APR::Table dl handle == 0x3e0000
modperl_util.c:352: Apache::Server dl handle == 0x3f0000
modperl_util.c:352: Apache::Const dl handle == 0xc20000
modperl_perl.c:151: perl == 0x9a4154, PERL_GET_CONTEXT == 0x9a4154
modperl_perl.c:169: after: PERL_GET_CONTEXT== 0x9a4154
modperl_util.c:376: close 0x3a0000
modperl_util.c:376: close 0x3c0000
modperl_util.c:376: close 0x3d0000
modperl_util.c:376: close 0x3e0000
modperl_util.c:376: close 0x3f0000
modperl_util.c:376: close 0xc20000
modperl_interp.c:196: parent == 0x925ce8
modperl_interp.c:134: interp == 0x925ce8, perl == 0x26441c,
PERL_GET_CONTEXT ==
0x26441c
modperl_perl.c:151: perl == 0x26441c, PERL_GET_CONTEXT == 0x26441c
Free to wrong pool 262770 not 953be8.
=====
- Steve
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
>>>The Bad News: The vhost test that originally didn't work way back at
>>>the start of this thread (excuse the pun) still doesn't work.
>>>
>>>
>>>
>>>
>>can't you pin-point which part of
>>that patch causes the problem? I assume the problem is the same, right?
>>
>>
>>
>It is indeed the usual problem. I'll try produce another shortened
>.conf file which reproduces the bug that's still lurking. Oh joy.
>
OK, here's another short conf file which does now break again:
=====
LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName localhost:8529
Listen 8529
ServerRoot C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen 8530
<VirtualHost _default_:8530>
PerlOptions +Parent
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlSwitches -IC:/Temp/modperl-2.0/t/response
PerlModule Apache::ServerUtil
<Perl>
my $s = Apache->server;
$s->add_config(['PerlModule TestVhost::basic']);
</Perl>
</VirtualHost>
=====
The add_config() call there is taken from the t/htdocs/vhost/startup.pl,
part of the vhost test patch that still breaks. Note that the above
conf breaks (in the usual way) with seemingly *any* module in place of
TestVhost::basic -- I tried Apache, File::Spec, CGI, DBI and a few
others and they all broke.
I'm testing with the latest CVS, plus the first of Stas' recent patches
(the one here:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107465681330157&w=2).
With the above conf file, the following "-t" command-line fails with the
good ol' "free to wrong pool" error:
C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t -f
C:/Temp/modperl-2.0/t/conf/httpd.conf.short3 -DAPACHE2 -DPERL_USEITHREADS
It can be "fixed" by just commenting-out the add_config() call in the
<Perl> section. (Indeed, without that add_config() call the server can
be started up for real without the "-t" option.)
Here's a stacktrace of the failure:
=====
VMem::Free(void * 0x00a3a01c) line 208 + 3 bytes
CPerlHost::Free(void * 0x00a3a01c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x00a3a01c) line 302
Perl_safesysfree(void * 0x00a3a01c) line 140 + 26 bytes
Perl_sv_clear(interpreter * 0x002643fc, sv * 0x002653fc) line 5203 + 13
bytes
Perl_sv_free(interpreter * 0x002643fc, sv * 0x002653fc) line 5348 + 13 bytes
Perl_free_tmps(interpreter * 0x002643fc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643fc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643fc) line 155 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x009272d0) line 143 + 12 bytes
modperl_interp_pool_destroy(void * 0x008515f8) line 199 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1994 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 763 + 12 bytes
apr_pool_destroy(apr_pool_t * 0x0028aa98) line 760 + 12 bytes
apr_pool_destroy(apr_pool_t * 0x00288a60) line 760 + 12 bytes
destroy_and_exit_process(process_rec * 0x00288af0, int 0) line 252
main(int 8, const char * const * 0x00282918) line 587 + 11 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=====
Here's the trace output with MOD_PERL_TRACE set to "cdghimos":
=====
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
C:/Temp/modperl-2.0/t -f C:/
Temp/modperl-2.0/t/conf/httpd.conf.short3 -DAPACHE2 -DPERL_USEITHREADS
mod_perl trace flags dump:
a Off (Apache API interaction)
c On (configuration for directive handlers)
d On (directive processing)
e Off (environment variables)
f Off (filters)
g On (Perl runtime interaction)
h On (handlers)
i On (interpreter pool management)
m On (memory allocations)
o On (I/O)
s On (perl sections)
t Off (benchmark-ish timings)
mod_perl.c:455: mod_perl globals are configured
modperl_global.c:88: init pconf
modperl_global.c:88: init threaded_mpm
modperl_global.c:88: init server_rec
modperl_config.c:187: p=0x28ab20, s=0x82c4d8, virtual=0
modperl_options.c:45: opts: 16
modperl_config.c:137: new dcfg: 0x84fd68
modperl_options.c:45: opts: 16
modperl_config.c:137: new dcfg: 0x850cb0
modperl_options.c:45: opts: 33554432
modperl_config.c:121: new scfg: 0x850f70
modperl_config.c:187: p=0x28ab20, s=0x850938, virtual=1
modperl_cmd.c:257: arg = +Parent
modperl_options.c:54: option 'Parent', type: server
modperl_options.c:55: opts_add 0
modperl_options.c:56: opts_remove 0
modperl_options.c:57: opts_override 0
modperl_options.c:58: opts_seen 0
modperl_options.c:59: unset 33554432
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/Apache-Test/lib
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/blib/lib
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/blib/arch
modperl_cmd.c:100: arg = -IC:/Temp/modperl-2.0/t/response
modperl_cmd.c:127: push PerlModule Apache::ServerUtil
MpSrv flags dump (localhost):
Access On
Authen On
Authz On
Autoload Off
ChildExit On
ChildInit On
Cleanup On
Clone Off
Enable On
Fixup On
HeaderParser On
InputFilter On
Log On
MapToStorage On
MergeHandlers Off
OpenLogs On
OutputFilter On
Parent Off
PostConfig On
PostReadRequest On
PreConnection On
ProcessConnection On
Response On
Trans On
Type On
Unset On
mod_perl.c:168: starting the parent perl for the base server
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -e;0
modperl_interp.c:247: server=localhost:8529
modperl_interp.c:117: 0x925ce8
mod_perl.c:237: constructed interpreter=0x26441c
mod_perl.c:288: Init vhost (null):8530: s=0x850938, base_s=0x82c4d8
MpSrv flags dump ((null)):
Access On
Authen On
Authz On
Autoload Off
ChildExit On
ChildInit On
Cleanup On
Clone Off
Enable On
Fixup On
HeaderParser On
InputFilter On
Log On
MapToStorage On
MergeHandlers Off
OpenLogs On
OutputFilter On
Parent On
PostConfig On
PostReadRequest On
PreConnection On
ProcessConnection On
Response On
Trans On
Type On
Unset On
mod_perl.c:172: starting the parent perl for vhost (null):8530
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -IC:/Temp/modperl-2.0/Apache-Test/lib
2 = -IC:/Temp/modperl-2.0/blib/lib
3 = -IC:/Temp/modperl-2.0/blib/arch
4 = -IC:/Temp/modperl-2.0/t/response
5 = -e;0
modperl_interp.c:247: server=(null):8530
modperl_interp.c:117: 0x9b68f8
mod_perl.c:237: constructed interpreter=0x9a4154
modperl_config.c:341: loaded Perl module Apache::ServerUtil for server
(null):85
30
mod_perl.c:327: created parent interpreter for VirtualHost (null):8530
mod_perl.c:288: Init vhost (null):8530: s=0x850938, base_s=0x82c4d8
mod_perl.c:308: server (null):8530 already initialized
modperl_handler.c:23: [940/1936] new handler Apache::PerlSections
mod_perl.c:288: Init vhost localhost:8529: s=0x82c4d8, base_s=0x82c4d8
mod_perl.c:292: base server is not vhost, skipping localhost:8529
modperl_cmd.c:120: load PerlModule TestVhost::basic
modperl_util.c:160: sv_setref_pv(Apache::CmdParms, 0x6fec8)
modperl_handler.c:75: dup handler Apache::PerlSections
modperl_handler.c:23: [940/1936] new handler Apache::PerlSections
MpHandler flags dump (Apache::PerlSections):
Anon Off
Autoload Off
Dynamic Off
Fake Off
Method Off
Object Off
Parsed Off
modperl_handler.c:52: [940/1936 (null):8530] handler
Apache::PerlSections was no
t compiled at startup, attempting to resolve using current pool 0x28ab20
modperl_mgv.c:297: package Apache::PerlSections not in %INC, attempting
to load
'Apache/PerlSections.pm'
modperl_mgv.c:302: loaded Apache::PerlSections package
modperl_mgv.c:341: [940/1936] found `handler' in class
`Apache::PerlSections' as
a method
modperl_options.c:45: opts: 33554432
modperl_config.c:121: new scfg: 0x851ca0
modperl_config.c:220: basev==0x84f8a8, addv==0x850f70
modperl_options.c:45: opts: 16
mod_perl.c:288: Init vhost (null):8530: s=0x850938, base_s=0x82c4d8
mod_perl.c:308: server (null):8530 already initialized
modperl_options.c:45: opts: 16
modperl_config.c:137: new dcfg: 0x8524d0
modperl_config.c:63: basev==0x84fd68, addv==0x850cb0
modperl_options.c:45: opts: 16
Syntax OK
modperl_interp.c:196: parent == 0x9b68f8
modperl_interp.c:134: interp == 0x9b68f8, perl == 0x9a4154,
PERL_GET_CONTEXT ==
0x9a4154
modperl_util.c:352: Apache::ServerUtil dl handle == 0x3a0000
modperl_util.c:352: Apache::CmdParms dl handle == 0x3c0000
modperl_util.c:352: Apache::Directive dl handle == 0x3d0000
modperl_util.c:352: APR::Table dl handle == 0x3e0000
modperl_util.c:352: Apache::Server dl handle == 0x3f0000
modperl_util.c:352: Apache::Const dl handle == 0xc20000
modperl_perl.c:151: perl == 0x9a4154, PERL_GET_CONTEXT == 0x9a4154
modperl_perl.c:169: after: PERL_GET_CONTEXT== 0x9a4154
modperl_util.c:376: close 0x3a0000
modperl_util.c:376: close 0x3c0000
modperl_util.c:376: close 0x3d0000
modperl_util.c:376: close 0x3e0000
modperl_util.c:376: close 0x3f0000
modperl_util.c:376: close 0xc20000
modperl_interp.c:196: parent == 0x925ce8
modperl_interp.c:134: interp == 0x925ce8, perl == 0x26441c,
PERL_GET_CONTEXT ==
0x26441c
modperl_perl.c:151: perl == 0x26441c, PERL_GET_CONTEXT == 0x26441c
Free to wrong pool 262770 not 953be8.
=====
- Steve
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve Hay wrote:
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>
>>>Steve, Randy, can you please try with this patch. This is against the conf
>>>file with:
>>>
>>><VirtualHost _default_:8542>
>>>PerlOptions +Parent
>>><Perl>
>>> 1;
>>></Perl>
>>></Virtualhost>
>>>
>>>
>>>
>>The Good News: The patch below fixes *both* of the short conf files
>>that we've been playing with. Running "apache.exe -t ..." was
>>previously enough to produce the crash; now I can even start the server
>>up (i.e. without the "-t" option) without error.
>>
>>
>
>Great. So it was a wrong context issue after all.
>
>Could you try remove the last chunk of this patch. i.e. remove the part that
>'restore the original perl context; and see if it still works.
>
With the last hunk of the patch removed, the short conf file with the
<Perl> section does still work with Apache's "-t" option, but the server
won't start up without it: It produces an access violation via the
usual bit of "free to wrong pool" code (although I didn't actually see
the message in the console this time).
So the whole patch is required.
>
>
>
>>The Bad News: The vhost test that originally didn't work way back at
>>the start of this thread (excuse the pun) still doesn't work.
>>
>>
>
>heh, I forgot what was the original one ;)
>
It's been a long hard slog, hasn't it?
>can't you pin-point which part of
>that patch causes the problem? I assume the problem is the same, right?
>
It is indeed the usual problem. I'll try produce another shortened
.conf file which reproduces the bug that's still lurking. Oh joy.
- Steve
>
>
>
>>I'll try the other patch that you e-mailed separately as well and see if
>>that helps...
>>
>>
>
>probably won't change anything, but give it a try.
>
>
>
>>>Index: src/modules/perl/modperl_cmd.c
>>>===================================================================
>>>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
>>>retrieving revision 1.52
>>>diff -u -r1.52 modperl_cmd.c
>>>--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
>>>+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 03:35:36 -0000
>>>@@ -373,6 +373,7 @@
>>>#ifdef USE_ITHREADS
>>> MP_dSCFG(s);
>>> pTHX;
>>>+ PerlInterpreter *orig_perl;
>>>#endif
>>>
>>> if (!(arg && *arg)) {
>>>@@ -388,7 +389,9 @@
>>>
>>>#ifdef USE_ITHREADS
>>> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>>>+ orig_perl = PERL_GET_CONTEXT;
>>> aTHX = scfg->mip->parent->perl;
>>>+ PERL_SET_CONTEXT(aTHX);
>>>#endif
>>>
>>> /* data will be set by a <Perl> section */
>>>@@ -479,6 +482,11 @@
>>> }
>>> }
>>>
>>>+#ifdef USE_ITHREADS
>>>+ /* restore the original perl context */
>>>+ PERL_SET_CONTEXT(orig_perl);
>>>+#endif
>>>+
>>> return NULL;
>>>}
>>>
>>>
>
>
>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>
>
>
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve, Randy, can you please try with this patch. This is against the conf
>>file with:
>>
>><VirtualHost _default_:8542>
>> PerlOptions +Parent
>> <Perl>
>> 1;
>> </Perl>
>></Virtualhost>
>>
> The Good News: The patch below fixes *both* of the short conf files
> that we've been playing with. Running "apache.exe -t ..." was
> previously enough to produce the crash; now I can even start the server
> up (i.e. without the "-t" option) without error.
Great. So it was a wrong context issue after all.
Could you try remove the last chunk of this patch. i.e. remove the part that
'restore the original perl context; and see if it still works.
> The Bad News: The vhost test that originally didn't work way back at
> the start of this thread (excuse the pun) still doesn't work.
heh, I forgot what was the original one ;) can't you pin-point which part of
that patch causes the problem? I assume the problem is the same, right?
> I'll try the other patch that you e-mailed separately as well and see if
> that helps...
probably won't change anything, but give it a try.
>>Index: src/modules/perl/modperl_cmd.c
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
>>retrieving revision 1.52
>>diff -u -r1.52 modperl_cmd.c
>>--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
>>+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 03:35:36 -0000
>>@@ -373,6 +373,7 @@
>> #ifdef USE_ITHREADS
>> MP_dSCFG(s);
>> pTHX;
>>+ PerlInterpreter *orig_perl;
>> #endif
>>
>> if (!(arg && *arg)) {
>>@@ -388,7 +389,9 @@
>>
>> #ifdef USE_ITHREADS
>> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>>+ orig_perl = PERL_GET_CONTEXT;
>> aTHX = scfg->mip->parent->perl;
>>+ PERL_SET_CONTEXT(aTHX);
>> #endif
>>
>> /* data will be set by a <Perl> section */
>>@@ -479,6 +482,11 @@
>> }
>> }
>>
>>+#ifdef USE_ITHREADS
>>+ /* restore the original perl context */
>>+ PERL_SET_CONTEXT(orig_perl);
>>+#endif
>>+
>> return NULL;
>> }
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>
>>Steve, Randy, can you please try with this patch. This is against the conf
>>file with:
>>
>><VirtualHost _default_:8542>
>> PerlOptions +Parent
>> <Perl>
>> 1;
>> </Perl>
>></Virtualhost>
>>
> The Good News: The patch below fixes *both* of the short conf files
> that we've been playing with. Running "apache.exe -t ..." was
> previously enough to produce the crash; now I can even start the server
> up (i.e. without the "-t" option) without error.
Actually, I wonder how does it fix this case:
<VirtualHost _default_:8542>
PerlOptions +Parent
</Virtualhost>
PerlLoadModule TestDirective::perlloadmodule
it the one I have sent affects only perl sections. Shouldn't you apply a
similar patch to the MP_CMD_SRV_DECLARE(modules) part
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 09:38:39 -0000
@@ -116,6 +116,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(aTHX);
#endif
MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
not sure about the restoring the context part, try to play with it.
MP_CMD_SRV_DECLARE(modules) and MP_CMD_SRV_DECLARE(perldo) are very similar in
the way they are invoked and the way they use the context. (in fact these are
the two places where you have/had the problems).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
>Steve, Randy, can you please try with this patch. This is against the conf
>file with:
>
><VirtualHost _default_:8542>
> PerlOptions +Parent
> <Perl>
> 1;
> </Perl>
></Virtualhost>
>
The Good News: The patch below fixes *both* of the short conf files
that we've been playing with. Running "apache.exe -t ..." was
previously enough to produce the crash; now I can even start the server
up (i.e. without the "-t" option) without error.
The Bad News: The vhost test that originally didn't work way back at
the start of this thread (excuse the pun) still doesn't work.
I'll try the other patch that you e-mailed separately as well and see if
that helps...
- Steve
>
>
>
>
>Index: src/modules/perl/modperl_cmd.c
>===================================================================
>RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
>retrieving revision 1.52
>diff -u -r1.52 modperl_cmd.c
>--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
>+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 03:35:36 -0000
>@@ -373,6 +373,7 @@
> #ifdef USE_ITHREADS
> MP_dSCFG(s);
> pTHX;
>+ PerlInterpreter *orig_perl;
> #endif
>
> if (!(arg && *arg)) {
>@@ -388,7 +389,9 @@
>
> #ifdef USE_ITHREADS
> /* XXX: .htaccess support cannot use this perl with threaded MPMs */
>+ orig_perl = PERL_GET_CONTEXT;
> aTHX = scfg->mip->parent->perl;
>+ PERL_SET_CONTEXT(aTHX);
> #endif
>
> /* data will be set by a <Perl> section */
>@@ -479,6 +482,11 @@
> }
> }
>
>+#ifdef USE_ITHREADS
>+ /* restore the original perl context */
>+ PERL_SET_CONTEXT(orig_perl);
>+#endif
>+
> return NULL;
> }
>
>
>__________________________________________________________________
>Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
>http://stason.org/ mod_perl Guide ---> http://perl.apache.org
>mailto:stas@stason.org http://use.perl.org http://apacheweek.com
>http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
>For additional commands, e-mail: dev-help@perl.apache.org
>
>
>
>------------------------------------------------
>This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.
>
>
>
>
>
------------------------------------------------
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve, Randy, can you please try with this patch. This is against the conf
file with:
<VirtualHost _default_:8542>
PerlOptions +Parent
<Perl>
1;
</Perl>
</Virtualhost>
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.52
diff -u -r1.52 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 19 Dec 2003 01:17:31 -0000 1.52
+++ src/modules/perl/modperl_cmd.c 21 Jan 2004 03:35:36 -0000
@@ -373,6 +373,7 @@
#ifdef USE_ITHREADS
MP_dSCFG(s);
pTHX;
+ PerlInterpreter *orig_perl;
#endif
if (!(arg && *arg)) {
@@ -388,7 +389,9 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
+ orig_perl = PERL_GET_CONTEXT;
aTHX = scfg->mip->parent->perl;
+ PERL_SET_CONTEXT(aTHX);
#endif
/* data will be set by a <Perl> section */
@@ -479,6 +482,11 @@
}
}
+#ifdef USE_ITHREADS
+ /* restore the original perl context */
+ PERL_SET_CONTEXT(orig_perl);
+#endif
+
return NULL;
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> 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 (!):-
>
> =====
> LoadModule perl_module C:/Temp/modperl-2.0/src/modules/perl/mod_perl.so
> ServerName localhost:8529
> Listen 8529
> ServerRoot C:/Temp/modperl-2.0/t
> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
> LogLevel debug
> PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
> PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
> PerlSwitches -IC:/Temp/modperl-2.0/t/response
> Listen 8542
> <VirtualHost _default_:8542>
> PerlOptions +Parent
> </Virtualhost>
> PerlLoadModule TestDirective::perlloadmodule
> =====
>
> The server still crashes on startup, even when started with the "-t"
> switch. Attached is a trace (MOD_PERL_TRACE=all) of it crashing with
> this minimal configuration.
>
> If I move the "PerlLoadModule TestDirective::perlloadmodule" line to
> above the <VirtualHost> then the "-t" test passes OK (the only output is
> "syntax OK"). The server still doesn't start, though -- without the
> "-t" switch it crashes in the same way as before (i.e. the "Free to
> wrong pool" error). Here's the (much shorter) stacktrace from that crash:
The good news is that with the short config you posted above, I'm now able to
reproduce the segfault, though a totally different one (in PerlLoadModule as
well). I hope that the two have the same origin.
The bad news is that I wasn't able to figure out what's going on yet, as it
segfaults deep inside perl core. I'll keep working on it.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
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 (!):-
=====
LoadModule perl_module C:/Temp/modperl-2.0/src/modules/perl/mod_perl.so
ServerName localhost:8529
Listen 8529
ServerRoot C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlSwitches -IC:/Temp/modperl-2.0/t/response
Listen 8542
<VirtualHost _default_:8542>
PerlOptions +Parent
</Virtualhost>
PerlLoadModule TestDirective::perlloadmodule
=====
The server still crashes on startup, even when started with the "-t"
switch. Attached is a trace (MOD_PERL_TRACE=all) of it crashing with
this minimal configuration.
If I move the "PerlLoadModule TestDirective::perlloadmodule" line to
above the <VirtualHost> then the "-t" test passes OK (the only output is
"syntax OK"). The server still doesn't start, though -- without the
"-t" switch it crashes in the same way as before (i.e. the "Free to
wrong pool" error). Here's the (much shorter) stacktrace from that crash:
=====
VMem::Free(void * 0x00f0cab4) line 208 + 3 bytes
CPerlHost::Free(void * 0x00f0cab4) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x00f0cab4) line 302
Perl_safesysfree(void * 0x00f0cab4) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x0026438c, sv * 0x00f04e70) line 5198 + 13
bytes
Perl_sv_free(interpreter * 0x0026438c, sv * 0x00f04e70) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x0026438c) line 189 + 13 bytes
perl_destruct(interpreter * 0x0026438c) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x0026438c) line 130 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x009273d0) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00850818) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a958) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=====
- Steve
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
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 JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Shot in the dark: I notice there's a Perl_safesysfree() call near the
> end of the stacktrace. Is it anything to do with things being run "too
> soon", like the trouble we had before with Perl_safesysmalloc()? (See
> http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00960.html)
> I don't think this safesysfree() call is anything like as early as that
> safesysmalloc() call was, but I thought I'd bring it up just in case.
Probably unrelated, since I have explicitly used safesysmalloc(), which was wrong.
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 * 0x01208d6c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x01236e7c, void * 0x01208d6c) line 302
Perl_safesysfree(void * 0x01208d6c) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002644c4, sv * 0x00924478) line 5196 + 13 bytes
Perl_sv_replace(interpreter * 0x002644c4, sv * 0x00924478, sv * 0x0126ec98)
line 5046 + 13 bytes
It fails to free 'sv * 0x00924478', any idea what is it? You should be able to
peek inside of it using:
((XPV*) (sv)->sv_any )->xpv_pv // 2pvx\n\
((XPVIV*) (sv)->sv_any )->xiv_iv // 2ivx
or a global catch-all peek:
Perl_sv_peek(my_perl, (SV*)(sv)) // sv_peek
replace sv with the name of the variable. You can go up the stack with 'up' in
order to look inside that variable.
Perl_leave_scope(interpreter * 0x002644c4, long 290) line 695 + 17 bytes
Perl_newATTRSUB(interpreter * 0x002644c4, long 290, op * 0x01386e5c, op *
0x00000000, op * 0x00000000, op * 0x01386e7c) line 4402 + 24 bytes
Perl_utilize(interpreter * 0x002644c4, int 1, long 290, op * 0x00000000, op *
0x012970b4, op * 0x00000000) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x002644c4) line 414 + 44 bytes
S_doeval(interpreter * 0x002644c4, int 0, op * * 0x00000000, cv * 0x00000000,
unsigned long 6743) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x002644c4) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x002644c4) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x002644c4) line 1434 + 13 bytes
S_call_body(interpreter * 0x002644c4, op * 0x0006f8c8, int 1) line 2193 + 13 bytes
Perl_eval_sv(interpreter * 0x002644c4, sv * 0x01268200, long 2) line 2253 + 15
bytes
modperl_require_module(interpreter * 0x002644c4, const char * 0x008ac6c8, int
0) line 13 + 15 bytes
Here we have a new perl interpreter, not the same one as started the require.
What's inside 'const char * 0x008ac6c8'? what file is it loading?
modperl_cmd_modules(cmd_parms_struct * 0x0006fa14, void * 0x00854718, const
char * 0x008ac6c8) line 122 + 15 bytes
invoke_cmd(const command_struct * 0x10025038, cmd_parms_struct * 0x0006fa14,
void * 0x00854718, const char * 0x008ac558) line 800 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x008ac528, cmd_parms_struct *
0x0006fa14, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x008ac528, cmd_parms_struct * 0x0006fa14,
ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
modperl_config_insert(interpreter * 0x0129104c, server_rec * 0x0082c4d8,
apr_pool_t * 0x0028ace0, apr_pool_t * 0x00000000, int 150, char * 0x00000000,
ap_conf_vector_t * 0x0082caa8, sv * 0x013834b8) line 443 + 18 bytes
modperl_config_insert_server(interpreter * 0x0129104c, server_rec *
0x0082c4d8, sv * 0x013834b8) line 461 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x0129104c, cv * 0x012e5338) line
99 + 17 bytes
Perl_pp_entersub(interpreter * 0x0129104c) line 2817 + 16 bytes
Perl_runops_debug(interpreter * 0x0129104c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0129104c, op * 0x0006fbf8, int 1) line 2193 + 13 bytes
Perl_eval_sv(interpreter * 0x0129104c, sv * 0x012a92bc, long 2) line 2253 + 15
bytes
Perl_require_pv(interpreter * 0x0129104c, const char * 0x0088ad20) line 2351 +
15 bytes
modperl_require_file(interpreter * 0x0129104c, const char * 0x0088ad20, int 1)
line 30 + 13 bytes
what's inside 'const char * 0x0088ad20'?
modperl_config_apply_PerlRequire(server_rec * 0x00889e28, modperl_config_srv_t
* 0x0088a848, interpreter * 0x0129104c, apr_pool_t * 0x0028ace0) line 357 + 21
bytes
modperl_startup(server_rec * 0x00889e28, apr_pool_t * 0x0028ace0) line 285 +
21 bytes
modperl_init_vhost(server_rec * 0x00889e28, apr_pool_t * 0x0028ace0,
server_rec * 0x0082c4d8) line 355 + 13 bytes
modperl_init(server_rec * 0x0082c4d8, apr_pool_t * 0x0028ace0) line 431 + 17 bytes
modperl_hook_init(apr_pool_t * 0x0028ace0, apr_pool_t * 0x00000000, apr_pool_t
* 0x00000000, server_rec * 0x0082c4d8) line 554 + 13 bytes
modperl_run() line 568 + 21 bytes
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void * 0x00854718,
const char * 0x00864808) line 503
invoke_cmd(const command_struct * 0x100251b8, cmd_parms_struct * 0x0006fec8,
void * 0x00854718, const char * 0x00864808) line 713 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x008647e8, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x008647e8, cmd_parms_struct * 0x0006fec8,
ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
ap_process_config_tree(server_rec * 0x0082c4d8, ap_directive_t * 0x008549e8,
apr_pool_t * 0x0028ace0, apr_pool_t * 0x0084c550) line 1594 + 20 bytes
main(int 8, const char * const * 0x00282918) line 582
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> It seems to fall over at line 19 of the new t/htdocs/vhost/startup.pl
> -- the line "PerlModule TestVhost::basic" in $conf.
>
> I tried adding "use TestVhost::basic" before the
> "$s->add_config([split /\n/, $conf]);" call, but that made no difference.
I don't know if this is useful to know or not:
You can actually insert a "sleep 1;" call just before the "1;" at the
end of basic.pm, put a breakpoint on pp_sleep() in the Perl code and
break the execution there! I had been thinking that it was falling over
somewhere during the compilation of basic.pm, but actually it
all-but-finishes -- it falls over somewhere *after* that "sleep 1;"
call, presumably during some sort of clean up after the module has been
loaded.
One other thing: line 56 of perlhost.h (just above the Free() that
causes the crash) says:
/* Locks provided but should be unnecessary as this is private pool */
Could it be that this "private pool" has been violated somewhere?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> It then stopped complaining that it couldn't find things, and
> "Apache.exe -t ..." now says syntax OK, but trying to start the server
> still fails as before.
OK. Thanks for testing that, Steve.
>>> modperl_mgv.c:264: package Apache::PerlSections not defined,
>>> attempting to load
>>>
>>> Free to wrong pool 262770 not 925938.
>>
>>
>>
>> The problems is this: perl uses dTHX; calls in some functions which
>> disregards the passed context and retrieves the globally stored
>> context. Which means that *every* time we select an interpreter, we
>> must call PERL_SET_CONTEXT() and pass to it the parent interpreter of
>> the currently used pool :(
>>
>> In particular for your and mine segfaults the Perl_safesysfree() call
>> is the one that uses dTHX and gets the wrong context at times, and
>> then it crashes.
>
>
> :(
>
> I just saw your post on p5p, so I'll watch that to see what people say.
Doesn't seem to be an area we have many experts in. It's pretty quiet.
>>> This short conf file is OK if I remove the "+Parent" line.
>>>
>>> I can also "fix" it by removing the <Perl >...</Perl> section, but
>>> trying the same trick with the full vhost test setup (commenting out
>>> the appropriate add_config() call from t/htdocs/vhost/startup.pl)
>>> doesn't fix that :(
>>>
>>> I notice that the <Perl >...</Perl> section in that startup.pl file
>>> is commented "this used to have problems on win32". Looks like it
>>> still does?
>>
>>
>>
>> Probably it just moved to a different place. Most likely it's the same
>> problem, I have explained above.
>>
>>> I also notice that the short conf file gives this syntax error if I
>>> change the <Perl > to <Perl>:
>>>
>>> Syntax error on line 10 of C:/Temp/modperl-2.0/t/conf/httpd.conf:
>>> <Perl> directive missing closing '>'
>>
>>
>>
>> You need the current httpd cvs for <Perl> to work. Unfortunately it
>> seems that Phillipe's fix won't make it to 2.0.48 (which should be
>> released shortly), but only 2.0.49 :(
>
>
> Oh, right. I'll have to start using CVS Apache2 as well, I think.
It actually did make it to 2.0.48. Thanks to Sander!
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
>> Here's a minimal conf file which still fails when running "perl
>> t/TEST -start" (or even "C:\apache2\bin\Apache.exe -t -d
>> C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf
>> -DAPACHE2 -DPERL_USEITHREADS"):
>>
>> =====
>> LoadModule perl_module
>> C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
>> ServerName localhost:8529
>> Listen 8529
>> ServerRoot C:/Temp/modperl-2.0/t
>> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>> LogLevel debug
>> Listen 8530
>> <VirtualHost _default_:8530>
>> PerlOptions +Parent
>> <Perl >
>> 1;
>> </Perl>
>> </VirtualHost>
>
>
> The problem with this config, is that you don't handle @INC to use the
> fresh build. So it loads stuff from the previously installed
> system-wide mod_perl. Probably it doesn't affect the outcome, but
> please set it right (e.g. nuke the preinstalled things so it won't
> load them). You need something like this:
>
> <VirtualHost _default_:8530>
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib/Apache2
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch/Apache2
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/lib
> PerlOptions +Parent
> <Perl>
> 1;
> </Perl>
> </VirtualHost>
>
> In any case it works fine on linux.
Yes, it was using pre-installed stuff. Having deleted all the
preinstalled stuff it then complained it couldn't load various things.
I added a few @INC paths like this:
=====
LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName localhost:8529
Listen 8529
ServerRoot C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen 8530
<VirtualHost _default_:8530>
PerlSwitches -IC:/Temp/modperl-2.0/Apache-Test/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/lib
PerlSwitches -IC:/Temp/modperl-2.0/blib/arch
PerlOptions +Parent
<Perl >
1;
</Perl>
</VirtualHost>
=====
It then stopped complaining that it couldn't find things, and
"Apache.exe -t ..." now says syntax OK, but trying to start the server
still fails as before.
>
>
>> modperl_mgv.c:264: package Apache::PerlSections not defined,
>> attempting to load
>>
>> Free to wrong pool 262770 not 925938.
>
>
> The problems is this: perl uses dTHX; calls in some functions which
> disregards the passed context and retrieves the globally stored
> context. Which means that *every* time we select an interpreter, we
> must call PERL_SET_CONTEXT() and pass to it the parent interpreter of
> the currently used pool :(
>
> In particular for your and mine segfaults the Perl_safesysfree() call
> is the one that uses dTHX and gets the wrong context at times, and
> then it crashes.
:(
I just saw your post on p5p, so I'll watch that to see what people say.
>
>
>> This short conf file is OK if I remove the "+Parent" line.
>>
>> I can also "fix" it by removing the <Perl >...</Perl> section, but
>> trying the same trick with the full vhost test setup (commenting out
>> the appropriate add_config() call from t/htdocs/vhost/startup.pl)
>> doesn't fix that :(
>>
>> I notice that the <Perl >...</Perl> section in that startup.pl file
>> is commented "this used to have problems on win32". Looks like it
>> still does?
>
>
> Probably it just moved to a different place. Most likely it's the same
> problem, I have explained above.
>
>> I also notice that the short conf file gives this syntax error if I
>> change the <Perl > to <Perl>:
>>
>> Syntax error on line 10 of C:/Temp/modperl-2.0/t/conf/httpd.conf:
>> <Perl> directive missing closing '>'
>
>
> You need the current httpd cvs for <Perl> to work. Unfortunately it
> seems that Phillipe's fix won't make it to 2.0.48 (which should be
> released shortly), but only 2.0.49 :(
Oh, right. I'll have to start using CVS Apache2 as well, I think.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Stas Bekman wrote:
>>
>>> Steve Hay wrote:
>>>
>>>> modperl_mgv.c:264: package Apache::PerlSections not defined,
>>>> attempting to load
>>>>
>>>> Free to wrong pool 262770 not 925938.
>>>
>>>
>>>
>>>
>>> The problems is this: perl uses dTHX; calls in some functions which
>>> disregards the passed context and retrieves the globally stored
>>> context. Which means that *every* time we select an interpreter, we
>>> must call PERL_SET_CONTEXT() and pass to it the parent interpreter of
>>> the currently used pool :(
>>>
>>> In particular for your and mine segfaults the Perl_safesysfree() call
>>> is the one that uses dTHX and gets the wrong context at times, and
>>> then it crashes.
>>
>>
>>
>> I think if you build perl without using perl's malloc this particular
>> segfault will go away. Certainly it's not a good solution.
>
>
> No, that's not true - my Perl is built without Perl's malloc anyway :(
OK, than I probably was mislead by the source, as malloc is defined and
redefined in several places, I thought that Perl_safesysfree() has to do with
Perl's malloc. I guess I was wrong.
> It isn't possible to build mp2 using a Perl that doesn't have ithreads,
> and on Win32 at least (I don't know if this limitation exists on other
> OS's too or not?) you can't use Perl's malloc with ithreads! Perl's
> win32/Makefile says of the PERL_MALLOC option (equivalent to
> -Dusemymalloc): "Currently, this cannot be enabled if you ask for
> USE_IMP_SYS". Hence I have:
>
> C:\Temp\modperl-2.0>perl -V:usemymalloc
> usemymalloc='n';
>
> I've never liked that, nor understood why it is. I would rather use
> Perl's malloc if possible; I do with my current mp1 setup which doesn't
> require ithreads.
I have heard different stories about using perl's malloc vs. the native one. I
think the "concensus" was that it depends on the os and its version...
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Stas Bekman wrote:
>
>> Steve Hay wrote:
>>
>>> modperl_mgv.c:264: package Apache::PerlSections not defined,
>>> attempting to load
>>>
>>> Free to wrong pool 262770 not 925938.
>>
>>
>>
>> The problems is this: perl uses dTHX; calls in some functions which
>> disregards the passed context and retrieves the globally stored
>> context. Which means that *every* time we select an interpreter, we
>> must call PERL_SET_CONTEXT() and pass to it the parent interpreter of
>> the currently used pool :(
>>
>> In particular for your and mine segfaults the Perl_safesysfree() call
>> is the one that uses dTHX and gets the wrong context at times, and
>> then it crashes.
>
>
> I think if you build perl without using perl's malloc this particular
> segfault will go away. Certainly it's not a good solution.
No, that's not true - my Perl is built without Perl's malloc anyway :(
It isn't possible to build mp2 using a Perl that doesn't have ithreads,
and on Win32 at least (I don't know if this limitation exists on other
OS's too or not?) you can't use Perl's malloc with ithreads! Perl's
win32/Makefile says of the PERL_MALLOC option (equivalent to
-Dusemymalloc): "Currently, this cannot be enabled if you ask for
USE_IMP_SYS". Hence I have:
C:\Temp\modperl-2.0>perl -V:usemymalloc
usemymalloc='n';
I've never liked that, nor understood why it is. I would rather use
Perl's malloc if possible; I do with my current mp1 setup which doesn't
require ithreads.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Steve Hay wrote:
>
>> Here's a minimal conf file which still fails when running "perl t/TEST
>> -start" (or even "C:\apache2\bin\Apache.exe -t -d
>> C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf
>> -DAPACHE2 -DPERL_USEITHREADS"):
>>
>> =====
>> LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
>> ServerName localhost:8529
>> Listen 8529
>> ServerRoot C:/Temp/modperl-2.0/t
>> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
>> LogLevel debug
>> Listen 8530
>> <VirtualHost _default_:8530>
>> PerlOptions +Parent
>> <Perl >
>> 1;
>> </Perl>
>> </VirtualHost>
>
>
> The problem with this config, is that you don't handle @INC to use the
> fresh build. So it loads stuff from the previously installed system-wide
> mod_perl. Probably it doesn't affect the outcome, but please set it
> right (e.g. nuke the preinstalled things so it won't load them). You
> need something like this:
>
> <VirtualHost _default_:8530>
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib/Apache2
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch/Apache2
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch
> PerlSwitches -I/home/stas/apache.org/mp2-vhost/lib
> PerlOptions +Parent
> <Perl>
> 1;
> </Perl>
> </VirtualHost>
>
> In any case it works fine on linux.
>
>> modperl_mgv.c:264: package Apache::PerlSections not defined,
>> attempting to load
>>
>> Free to wrong pool 262770 not 925938.
>
>
> The problems is this: perl uses dTHX; calls in some functions which
> disregards the passed context and retrieves the globally stored context.
> Which means that *every* time we select an interpreter, we must call
> PERL_SET_CONTEXT() and pass to it the parent interpreter of the
> currently used pool :(
>
> In particular for your and mine segfaults the Perl_safesysfree() call is
> the one that uses dTHX and gets the wrong context at times, and then it
> crashes.
I think if you build perl without using perl's malloc this particular segfault
will go away. Certainly it's not a good solution.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Here's a minimal conf file which still fails when running "perl t/TEST
> -start" (or even "C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t
> -f C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"):
>
> =====
> LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
> ServerName localhost:8529
> Listen 8529
> ServerRoot C:/Temp/modperl-2.0/t
> DocumentRoot C:/Temp/modperl-2.0/t/htdocs
> LogLevel debug
> Listen 8530
> <VirtualHost _default_:8530>
> PerlOptions +Parent
> <Perl >
> 1;
> </Perl>
> </VirtualHost>
The problem with this config, is that you don't handle @INC to use the fresh
build. So it loads stuff from the previously installed system-wide mod_perl.
Probably it doesn't affect the outcome, but please set it right (e.g. nuke the
preinstalled things so it won't load them). You need something like this:
<VirtualHost _default_:8530>
PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib/Apache2
PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch/Apache2
PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/lib
PerlSwitches -I/home/stas/apache.org/mp2-vhost/blib/arch
PerlSwitches -I/home/stas/apache.org/mp2-vhost/lib
PerlOptions +Parent
<Perl>
1;
</Perl>
</VirtualHost>
In any case it works fine on linux.
> modperl_mgv.c:264: package Apache::PerlSections not defined, attempting
> to load
>
> Free to wrong pool 262770 not 925938.
The problems is this: perl uses dTHX; calls in some functions which disregards
the passed context and retrieves the globally stored context. Which means that
*every* time we select an interpreter, we must call PERL_SET_CONTEXT() and
pass to it the parent interpreter of the currently used pool :(
In particular for your and mine segfaults the Perl_safesysfree() call is the
one that uses dTHX and gets the wrong context at times, and then it crashes.
> This short conf file is OK if I remove the "+Parent" line.
>
> I can also "fix" it by removing the <Perl >...</Perl> section, but
> trying the same trick with the full vhost test setup (commenting out the
> appropriate add_config() call from t/htdocs/vhost/startup.pl) doesn't
> fix that :(
>
> I notice that the <Perl >...</Perl> section in that startup.pl file is
> commented "this used to have problems on win32". Looks like it still does?
Probably it just moved to a different place. Most likely it's the same
problem, I have explained above.
> I also notice that the short conf file gives this syntax error if I
> change the <Perl > to <Perl>:
>
> Syntax error on line 10 of C:/Temp/modperl-2.0/t/conf/httpd.conf:
> <Perl> directive missing closing '>'
You need the current httpd cvs for <Perl> to work. Unfortunately it seems that
Phillipe's fix won't make it to 2.0.48 (which should be released shortly),
but only 2.0.49 :(
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Steve, Randy, please try the current cvs (just cvs up + make, no need
>> to rebuild from scratch). I have finally been able to solve the
>> segfault with the short config Steve presented. I hope that it solves
>> the problem for you as well. If it does, please try again with the
>> vhost patch that was failing before.
>>
>> I moved quite a few things in mod_perl.c, but the only real change
>> was adding:
>>
>> +#ifdef USE_ITHREADS
>> + /* after other parent perls were started in vhosts, make sure
>> that
>> + * the context is set to the base_perl */
>> + PERL_SET_CONTEXT(base_perl);
>> +#endif
>>
>> after setting up vhosts, without which, PerlLoadModule in the main
>> server was segfaulting for me.
>
>
> The bad news: The vhost tests still fail as before :(
>
> I'll try to cut down the conf file to the minimum that still crashes,
> and post a full trace then.
Here's a minimal conf file which still fails when running "perl t/TEST
-start" (or even "C:\apache2\bin\Apache.exe -t -d C:/Temp/modperl-2.0/t
-f C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"):
=====
LoadModule perl_module C:\Temp\modperl-2.0\src\modules\perl\mod_perl.so
ServerName localhost:8529
Listen 8529
ServerRoot C:/Temp/modperl-2.0/t
DocumentRoot C:/Temp/modperl-2.0/t/htdocs
LogLevel debug
Listen 8530
<VirtualHost _default_:8530>
PerlOptions +Parent
<Perl >
1;
</Perl>
</VirtualHost>
=====
Here's the stack trace:
=====
VMem::Free(void * 0x0093122c) line 208 + 3 bytes
CPerlHost::Free(void * 0x0093122c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x0093122c) line 302
Perl_safesysfree(void * 0x0093122c) line 143 + 26 bytes
Perl_av_extend(interpreter * 0x0092c12c, av * 0x0092cefc, long 4) line
135 + 14 bytes
Perl_av_store(interpreter * 0x0092c12c, av * 0x0092cefc, long 4, sv *
0x0095a9b4) line 315 + 17 bytes
Perl_av_push(interpreter * 0x0092c12c, av * 0x0092cefc, sv * 0x0095a9b4)
line 542 + 29 bytes
Perl_newPMOP(interpreter * 0x0092c12c, long 31, long 0) line 2650 + 65 bytes
S_scan_pat(interpreter * 0x0092c12c, char * 0x00958012, long 31) line
6353 + 15 bytes
Perl_yylex(interpreter * 0x0092c12c) line 3613 + 15 bytes
Perl_yyparse(interpreter * 0x0092c12c) line 1470 + 9 bytes
S_doeval(interpreter * 0x0092c12c, int 0, op * * 0x00000000, cv *
0x00000000, unsigned long 19) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x0092c12c) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x0092c12c) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x0092c12c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0092c12c, op * 0x0006f0b4, int 0) line 2193
+ 13 bytes
Perl_call_sv(interpreter * 0x0092c12c, sv * 0x0094a01c, long 6) line
2111 + 15 bytes
S_call_list_body(interpreter * 0x0092c12c, cv * 0x0094a01c) line 4361 +
15 bytes
Perl_call_list(interpreter * 0x0092c12c, long 11, av * 0x00949f8c) line
4290 + 13 bytes
Perl_newATTRSUB(interpreter * 0x0092c12c, long 501, op * 0x0094dc04, op
* 0x00000000, op * 0x00000000, op * 0x0094dc24) line 4365 + 23 bytes
Perl_utilize(interpreter * 0x0092c12c, int 1, long 501, op * 0x00000000,
op * 0x0093fb38, op * 0x0093fb1c) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x0092c12c) line 414 + 44 bytes
S_doeval(interpreter * 0x0092c12c, int 0, op * * 0x00000000, cv *
0x00000000, unsigned long 17) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x0092c12c) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x0092c12c) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x0092c12c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0092c12c, op * 0x0006f600, int 0) line 2193
+ 13 bytes
Perl_call_sv(interpreter * 0x0092c12c, sv * 0x00942720, long 6) line
2111 + 15 bytes
S_call_list_body(interpreter * 0x0092c12c, cv * 0x00942720) line 4361 +
15 bytes
Perl_call_list(interpreter * 0x0092c12c, long 5, av * 0x009426f0) line
4290 + 13 bytes
Perl_newATTRSUB(interpreter * 0x0092c12c, long 292, op * 0x0093fc7c, op
* 0x00000000, op * 0x00000000, op * 0x0093fc9c) line 4365 + 23 bytes
Perl_utilize(interpreter * 0x0092c12c, int 1, long 292, op * 0x00000000,
op * 0x0093fe78, op * 0x0093fe14) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x0092c12c) line 414 + 44 bytes
S_doeval(interpreter * 0x0092c12c, int 0, op * * 0x00000000, cv *
0x00000000, unsigned long 2) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x0092c12c) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x0092c12c) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x0092c12c) line 1434 + 13 bytes
S_call_body(interpreter * 0x0092c12c, op * 0x0006faf8, int 1) line 2193
+ 13 bytes
Perl_eval_sv(interpreter * 0x0092c12c, sv * 0x00942624, long 2) line
2253 + 15 bytes
modperl_require_module(interpreter * 0x0092c12c, const char *
0x00851470, int 0) line 13 + 15 bytes
modperl_mgv_resolve(interpreter * 0x0092c12c, modperl_handler_t *
0x00851518, apr_pool_t * 0x0028a9f8, const char * 0x00851470, int 0)
line 267 + 15 bytes
modperl_handler_resolve(interpreter * 0x0092c12c, modperl_handler_t * *
0x0006fcb8, apr_pool_t * 0x0028a9f8, server_rec * 0x00850670) line 61 +
26 bytes
modperl_callback(interpreter * 0x0092c12c, modperl_handler_t *
0x00851518, apr_pool_t * 0x0028a9f8, request_rec * 0x00000000,
server_rec * 0x00850670, av * 0x0092d124) line 11 + 21 bytes
modperl_cmd_perldo(cmd_parms_struct * 0x0006fec8, void * 0x008509e8,
const char * 0x008514f8) line 427 + 27 bytes
invoke_cmd(const command_struct * 0x10025110, cmd_parms_struct *
0x0006fec8, void * 0x008509e8, const char * 0x00850428) line 713 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x00850430, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x00850848) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x00850430, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x00850848) line 1121 + 17 bytes
virtualhost_section(cmd_parms_struct * 0x0006fec8, void * 0x0082cbc8,
const char * 0x00850660) line 1974 + 26 bytes
invoke_cmd(const command_struct * 0x6ff356a8, cmd_parms_struct *
0x0006fec8, void * 0x0082cbc8, const char * 0x00850270) line 713 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x00850250, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x00850250, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
ap_process_config_tree(server_rec * 0x0082c4d8, ap_directive_t *
0x00850008, apr_pool_t * 0x0028a9f8, apr_pool_t * 0x0084c550) line 1594
+ 20 bytes
main(int 8, const char * const * 0x00282918) line 582
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=====
and here's the output from MOD_PERL_TRACE=cdghimos:
=====
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
C:/Temp/modperl-2.0/t -f C:/
Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
mod_perl trace flags dump:
c On (configuration for directive handlers)
d On (directive processing)
e Off (environment variables)
f Off (filters)
g On (Perl runtime interaction)
h On (handlers)
i On (interpreter pool management)
m On (memory allocations)
o On (I/O)
s On (perl sections)
t Off (benchmark-ish timings)
mod_perl.c:522: mod_perl globals are configured
modperl_global.c:88: init pconf
modperl_global.c:88: init threaded_mpm
modperl_global.c:88: init server_rec
modperl_config.c:187: p=0x28aa60, s=0x82c4d8, virtual=0
modperl_config.c:137: 0x84fd38
modperl_config.c:137: 0x8509e8
modperl_config.c:121: 0x850ca8
modperl_config.c:187: p=0x28aa60, s=0x850670, virtual=1
modperl_cmd.c:257: arg = +Parent
MpSrv flags dump (localhost):
Clone Off
Parent Off
Enable On
Autoload Off
MergeHandlers Off
Authz On
Authen On
PostConfig On
ChildExit On
OutputFilter On
Response On
Log On
PostReadRequest On
OpenLogs On
PreConnection On
MapToStorage On
ProcessConnection On
ChildInit On
Fixup On
HeaderParser On
InputFilter On
Type On
Trans On
Cleanup On
Access On
Unset On
mod_perl.c:235: starting the parent perl for the base server
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -e;0
modperl_interp.c:232: server=localhost:8529
modperl_interp.c:107: 0x925b40
mod_perl.c:304: constructed interpreter=0x2643ec
mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8
MpSrv flags dump ((null)):
Clone Off
Parent On
Enable On
Autoload Off
MergeHandlers Off
Authz On
Authen On
PostConfig On
ChildExit On
OutputFilter On
Response On
Log On
PostReadRequest On
OpenLogs On
PreConnection On
MapToStorage On
ProcessConnection On
ChildInit On
Fixup On
HeaderParser On
InputFilter On
Type On
Trans On
Cleanup On
Access On
Unset On
mod_perl.c:239: starting the parent perl for vhost (null):8530
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -e;0
modperl_interp.c:232: server=(null):8530
modperl_interp.c:107: 0x93c520
mod_perl.c:304: constructed interpreter=0x92c24c
mod_perl.c:394: created parent interpreter for VirtualHost (null):8530
mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8
mod_perl.c:375: server (null):8530 already initialized
modperl_handler.c:23: [3824/1936] new handler Apache::PerlSections
modperl_util.c:160: sv_setref_pv(Apache::CmdParms, 0x6fec8)
modperl_handler.c:75: dup handler Apache::PerlSections
modperl_handler.c:23: [3824/1936] new handler Apache::PerlSections
MpHandler flags dump (Apache::PerlSections):
Parsed Off
Method Off
Object Off
Anon Off
Autoload Off
Dynamic Off
Fake Off
modperl_handler.c:52: [3824/1936 (null):8530] handler
Apache::PerlSections was not compiled at startup, attempting to resolve
using current pool 0x28aa60
modperl_mgv.c:264: package Apache::PerlSections not defined, attempting
to load
Free to wrong pool 262770 not 925938.
=====
This short conf file is OK if I remove the "+Parent" line.
I can also "fix" it by removing the <Perl >...</Perl> section, but
trying the same trick with the full vhost test setup (commenting out the
appropriate add_config() call from t/htdocs/vhost/startup.pl) doesn't
fix that :(
I notice that the <Perl >...</Perl> section in that startup.pl file is
commented "this used to have problems on win32". Looks like it still does?
I also notice that the short conf file gives this syntax error if I
change the <Perl > to <Perl>:
Syntax error on line 10 of C:/Temp/modperl-2.0/t/conf/httpd.conf:
<Perl> directive missing closing '>'
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Steve Hay wrote:
>>
>> At least I have found a sure way to verify that a segfault is caused
>> by the wrong context. When you get a core trace where a Perl_ call,
>> passing interpreter argument (my_perl on Unix, interpreter on win32),
>> is followed by another Perl_ call, which doesn't pass this argument,
>> go that that frame with the latter call and issue
>>
>> (gdb) p PL_curinterp
>>
>> if it doesn't match the interepreter (or my_perl) argument from the
>> call one frame higher, you know what the problem is. In your trace:
>>
>>> VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
>>> CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
>>> PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
>>> Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
>>
>>
>>
>> (gdb) p PL_curinterp
>>
>>> Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 +
>>> 13 bytes
>>
>>
>>
>> (gdb) up
>> (gdb) p interpreter
>>
>> if the two are not the same, the problem is clear.
>
>
> I can't do _exactly_ what you've written above (I'm using MSVC++ rather
> than gdb), but I can watch the value of any visible variables within
> each frame. If I'm doing this correctly then I don't actually see the
> problem that you describe. The value of "interpreter" isn't shown by
> MSVC++ in the "watch" window (it just gives me "{...}"!) but I guess you
> can see it from the stacktrace itself. Here's the stacktrace for for
> what I'm looking at now:
>
> VMem::Free(void * 0x009fb864) line 208 + 3 bytes
> CPerlHost::Free(void * 0x009fb864) line 59 + 34 bytes
> PerlMemFree(IPerlMem * 0x00262434, void * 0x009fb864) line 302
> Perl_safesysfree(void * 0x009fb864) line 143 + 26 bytes
> Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13
> bytes
> Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13
> bytes
> Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
> perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
> modperl_perl_destruct(interpreter * 0x002643cc) line 146 + 9 bytes
> modperl_interp_destroy(modperl_interp_t * 0x00924db0) line 128 + 12 bytes
> modperl_interp_pool_destroy(void * 0x00851398) line 184 + 12 bytes
> run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
> apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
> apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
> main(int 7, const char * const * 0x00282908) line 619
> mainCRTStartup() line 338 + 17 bytes
> KERNEL32! 77e814c7()
>
> So "interpreter" is 0x002643cc in the calls to modperl_perl_destruct()
> through to Perl_sv_clear(). Here's what the "watch" window shows me for
> the values of PL_curinterp and my_perl in each of those frames and the
> later frames as well:
>
> VMem::Free()
> PL_curinterp: 0x002643cc
> my_perl: 0x002643cc
[...]
only the last one matters.
> In particular, the PL_curinterp value within the Perl_safesysfree()
> frame (which didn't get the interpreter passed) is the same as the
> my_perl value within the Perl_sv_clear() frame (which did get the
> interpreter passed).
That's a bad news. In which case I don't know what the problem is on your
side. Though we did see that messing with setting of the context helps things,
so we might be still around the right track.
Since I can reproduce segfaults and I do get different values for PL_curinterp
and the passed my_perl, I'll first tackle that one. And then we will get back
to try to figure out what's wrong is on win32.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
> At least I have found a sure way to verify that a segfault is caused
> by the wrong context. When you get a core trace where a Perl_ call,
> passing interpreter argument (my_perl on Unix, interpreter on win32),
> is followed by another Perl_ call, which doesn't pass this argument,
> go that that frame with the latter call and issue
>
> (gdb) p PL_curinterp
>
> if it doesn't match the interepreter (or my_perl) argument from the
> call one frame higher, you know what the problem is. In your trace:
>
>> VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
>> CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
>> PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
>> Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
>
>
> (gdb) p PL_curinterp
>
>> Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 +
>> 13 bytes
>
>
> (gdb) up
> (gdb) p interpreter
>
> if the two are not the same, the problem is clear.
I can't do _exactly_ what you've written above (I'm using MSVC++ rather
than gdb), but I can watch the value of any visible variables within
each frame. If I'm doing this correctly then I don't actually see the
problem that you describe. The value of "interpreter" isn't shown by
MSVC++ in the "watch" window (it just gives me "{...}"!) but I guess you
can see it from the stacktrace itself. Here's the stacktrace for for
what I'm looking at now:
VMem::Free(void * 0x009fb864) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fb864) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fb864) line 302
Perl_safesysfree(void * 0x009fb864) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13
bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 146 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x00924db0) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00851398) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
So "interpreter" is 0x002643cc in the calls to modperl_perl_destruct()
through to Perl_sv_clear(). Here's what the "watch" window shows me for
the values of PL_curinterp and my_perl in each of those frames and the
later frames as well:
VMem::Free()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
CPerlHost::Free()
PL_curinterp: 0x002643cc
my_perl: Error: symbol "my_perl" not found
PerlMemFree()
PL_curinterp: 0x002643cc
my_perl: Error: symbol "my_perl" not found
Perl_safesysfree()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
Perl_sv_clear()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
Perl_sv_free()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
Perl_free_tmps()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
perl_destruct()
PL_curinterp: 0x002643cc
my_perl: 0x002643cc
modperl_perl_destruct()
PL_curinterp: Error: symbol "PL_curinterp" not found
my_perl: 0x002643cc
In particular, the PL_curinterp value within the Perl_safesysfree()
frame (which didn't get the interpreter passed) is the same as the
my_perl value within the Perl_sv_clear() frame (which did get the
interpreter passed).
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Steve Hay wrote:
>
> At least I have found a sure way to verify that a segfault is caused by
> the wrong context. When you get a core trace where a Perl_ call, passing
> interpreter argument (my_perl on Unix, interpreter on win32), is
> followed by another Perl_ call, which doesn't pass this argument, go
> that that frame with the latter call and issue
>
> (gdb) p PL_curinterp
>
> if it doesn't match the interpreter (or my_perl) argument from the call
> one frame higher, you know what the problem is.
Actually it's not necessarily true. Since interpreter/my_perl could be a perl
from the pool, and PL_curinterp is always a parent perl. So you also need the
trace to see what pointer the parent pool has.
The opposite is true. If you get the same pointer for PL_curinterp and
interpreter/my_perl, then the issue is elsewhere.
> In your trace:
>
>> VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
>> CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
>> PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
>> Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
>
>
> (gdb) p PL_curinterp
>
>> Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 +
>> 13 bytes
>
>
> (gdb) up
> (gdb) p interpreter
>
> if the two are not the same, the problem is clear.
>
> PL_curinterp is a true global variable, so it's impossible to maintain
> it per interpreter.
>
> The next step is to figure out how to set the perl context every time we
> select a new interepreter without incurring too much overhead and
> encapsulate this function together with the selector code so not to
> clutter the code and prevent forgetting to set the context in the newly
> added code. I will keep you posted.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
At least I have found a sure way to verify that a segfault is caused by the
wrong context. When you get a core trace where a Perl_ call, passing
interpreter argument (my_perl on Unix, interpreter on win32), is followed by
another Perl_ call, which doesn't pass this argument, go that that frame with
the latter call and issue
(gdb) p PL_curinterp
if it doesn't match the interepreter (or my_perl) argument from the call one
frame higher, you know what the problem is. In your trace:
> VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
> CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
> PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
> Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
(gdb) p PL_curinterp
> Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13
> bytes
(gdb) up
(gdb) p interpreter
if the two are not the same, the problem is clear.
PL_curinterp is a true global variable, so it's impossible to maintain it per
interpreter.
The next step is to figure out how to set the perl context every time we
select a new interepreter without incurring too much overhead and encapsulate
this function together with the selector code so not to clutter the code and
prevent forgetting to set the context in the newly added code. I will keep you
posted.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
>> Stas Bekman wrote:
>>
>>> Stas Bekman wrote:
>>>
>>>> This and your trace proves my suspicion that my solution just
>>>> happened to work for the particular setup you had the crush with.
>>>> But I think we are on the right track. We get the crash when the
>>>> wrong perl is set as the current context. I will try to remove my
>>>> recent solution and try to see why modperl_cmd_modules doesn't use
>>>> the correct perl. This is the place where the problem comes from.
>>>
>>>
>>>
>>>
>>> Please try this patch:
>>
>>
>>
>> Trying your patch with the short conf file that I posted a few
>> minutes ago, the -t test now passes "syntax OK", but the server still
>> won't start.
>>
>> Running "C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t -f
>> C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"
>> still crashes at the same "Free to wrong pool" place in the code,
>> although its much earlier and I don't see that error message in the
>> console now. Here's the stack trace:
>>
>> =====
>> VMem::Free(void * 0x009fa3ac) line 208 + 3 bytes
>> CPerlHost::Free(void * 0x009fa3ac) line 59 + 34 bytes
>> PerlMemFree(IPerlMem * 0x00262434, void * 0x009fa3ac) line 302
>> Perl_safesysfree(void * 0x009fa3ac) line 143 + 26 bytes
>> Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 +
>> 13 bytes
>> Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 +
>> 13 bytes
>> Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
>> perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
>> modperl_perl_destruct(interpreter * 0x002643cc) line 144 + 9 bytes
>
>
> So here we get perl_destruct calling some functions that rely on the
> right context. I don't get this problem, but please try this patch:
>
> [...]
Still doesn't work :(
The backtrace and MOD_PERL_TRACE are the same as before (except for a
few extra lines in the MOD_PERL_TRACE relating to the new "PerlSwitches
-I..." that I've added to this minimal conf file).
>
>
>
>> Using the full vhost test setup I do still see the "Free to wrong
>> pool" message as before, but the stack trace is still shorter.
>
The full vhost setup also still fails as before. The backtrace is again
the same. I've attached the MOD_PERL_TRACE output since it includes a
couple of new lines (from the extra trace call that your patch added).
> Just to prove my assumptions I'd try to temporarely patch it as:
>
> Index: src/modules/perl/modperl_util.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
> retrieving revision 1.55
> diff -u -r1.55 modperl_util.c
> --- src/modules/perl/modperl_util.c 9 Oct 2003 23:56:52 -0000 1.55
> +++ src/modules/perl/modperl_util.c 23 Oct 2003 23:34:32 -0000
> @@ -4,6 +4,8 @@
> {
> SV *sv;
>
> + PERL_SET_CONTEXT(my_perl);
> +
> dSP;
> PUSHSTACKi(PERLSI_REQUIRE);
> PUTBACK;
I get errors compiling that:
modperl_util.c(7) : error C2275: 'SV' : illegal use of this type as an
expression
C:\apache2\perl5\lib\CORE\perl.h(1772) : see declaration of 'SV'
modperl_util.c(7) : error C2065: 'sp' : undeclared identifier
modperl_util.c(7) : error C2100: illegal indirection
modperl_util.c(8) : error C2113: pointer can only be subtracted from
another pointer
It compiles if I put the new PERL_SET_CONTEXT(my_perl) call after the
dSP. But it makes no difference either to the short or the full conf file.
- Steve
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Stas Bekman wrote:
>>
>>> This and your trace proves my suspicion that my solution just
>>> happened to work for the particular setup you had the crush with. But
>>> I think we are on the right track. We get the crash when the wrong
>>> perl is set as the current context. I will try to remove my recent
>>> solution and try to see why modperl_cmd_modules doesn't use the
>>> correct perl. This is the place where the problem comes from.
>>
>>
>>
>> Please try this patch:
>
>
> Trying your patch with the short conf file that I posted a few minutes
> ago, the -t test now passes "syntax OK", but the server still won't start.
>
> Running "C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t -f
> C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"
> still crashes at the same "Free to wrong pool" place in the code,
> although its much earlier and I don't see that error message in the
> console now. Here's the stack trace:
>
> =====
> VMem::Free(void * 0x009fa3ac) line 208 + 3 bytes
> CPerlHost::Free(void * 0x009fa3ac) line 59 + 34 bytes
> PerlMemFree(IPerlMem * 0x00262434, void * 0x009fa3ac) line 302
> Perl_safesysfree(void * 0x009fa3ac) line 143 + 26 bytes
> Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13
> bytes
> Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13
> bytes
> Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
> perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
> modperl_perl_destruct(interpreter * 0x002643cc) line 144 + 9 bytes
So here we get perl_destruct calling some functions that rely on the right
context. I don't get this problem, but please try this patch:
Index: src/modules/perl/mod_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.201
diff -u -r1.201 mod_perl.c
--- src/modules/perl/mod_perl.c 23 Oct 2003 05:57:46 -0000 1.201
+++ src/modules/perl/mod_perl.c 23 Oct 2003 23:28:59 -0000
@@ -458,13 +458,6 @@
exit(1); /*XXX*/
}
}
-
-#ifdef USE_ITHREADS
- /* after other parent perls were started in vhosts, make sure that
- * the context is set to the base_perl */
- PERL_SET_CONTEXT(base_perl);
-#endif
-
}
#ifdef USE_ITHREADS
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.49
diff -u -r1.49 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 20 Oct 2003 17:44:48 -0000 1.49
+++ src/modules/perl/modperl_cmd.c 23 Oct 2003 23:28:59 -0000
@@ -116,6 +116,11 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(scfg->mip->parent->perl);
+ MP_TRACE_d(MP_FUNC,
+ "using mip=0x%lx, my_perl=0x%lx, PL_curinterp=0x%lx\n",
+ (PerlInterpreter *)scfg->mip->parent->perl, my_perl,
+ PERL_GET_CONTEXT);
#endif
MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -145,6 +150,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(scfg->mip->parent->perl);
#endif
MP_TRACE_d(MP_FUNC, "load PerlRequire %s\n", arg);
@@ -381,6 +387,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
aTHX = scfg->mip->parent->perl;
+ PERL_SET_CONTEXT(scfg->mip->parent->perl);
#endif
/* data will be set by a <Perl> section */
Index: src/modules/perl/modperl_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_perl.c,v
retrieving revision 1.19
diff -u -r1.19 modperl_perl.c
--- src/modules/perl/modperl_perl.c 18 Oct 2003 21:01:30 -0000 1.19
+++ src/modules/perl/modperl_perl.c 23 Oct 2003 23:28:59 -0000
@@ -135,12 +135,14 @@
{
dTHXa(perl);
+ PERL_SET_CONTEXT(perl);
if ((module_commands = modperl_module_config_table_get(aTHX_ FALSE))) {
modperl_svptr_table_destroy(aTHX_ module_commands);
}
}
+ PERL_SET_CONTEXT(perl);
perl_destruct(perl);
/* XXX: big bug in 5.6.1 fixed in 5.7.2+
> Using the full vhost test setup I do still see the "Free to wrong pool"
> message as before, but the stack trace is still shorter. Here it is:
>
> =====
> VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
> CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
> PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
> Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
> Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13
> bytes
> Perl_sv_free(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5342 + 13
> bytes
> Perl_av_undef(interpreter * 0x012aff6c, av * 0x013a1ae8) line 498 + 32
> bytes
> Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1ae8) line 5161 + 13
> bytes
> Perl_sv_free(interpreter * 0x012aff6c, sv * 0x013a1ae8) line 5342 + 13
> bytes
> Perl_free_tmps(interpreter * 0x012aff6c) line 189 + 13 bytes
> Perl_pp_nextstate(interpreter * 0x012aff6c) line 41 + 23 bytes
> Perl_runops_debug(interpreter * 0x012aff6c) line 1434 + 13 bytes
> S_call_body(interpreter * 0x012aff6c, op * 0x0006fbe0, int 1) line 2193
> + 13 bytes
> Perl_eval_sv(interpreter * 0x012aff6c, sv * 0x012c759c, long 2) line
> 2253 + 15 bytes
> Perl_require_pv(interpreter * 0x012aff6c, const char * 0x0088cec8) line
> 2351 + 15 bytes
> modperl_require_file(interpreter * 0x012aff6c, const char * 0x0088cec8,
> int 1) line 30 + 13 bytes
> modperl_config_apply_PerlRequire(server_rec * 0x0088bfd0,
Just to prove my assumptions I'd try to temporarely patch it as:
Index: src/modules/perl/modperl_util.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_util.c,v
retrieving revision 1.55
diff -u -r1.55 modperl_util.c
--- src/modules/perl/modperl_util.c 9 Oct 2003 23:56:52 -0000 1.55
+++ src/modules/perl/modperl_util.c 23 Oct 2003 23:34:32 -0000
@@ -4,6 +4,8 @@
{
SV *sv;
+ PERL_SET_CONTEXT(my_perl);
+
dSP;
PUSHSTACKi(PERLSI_REQUIRE);
PUTBACK;
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Stas Bekman wrote:
>
>> This and your trace proves my suspicion that my solution just
>> happened to work for the particular setup you had the crush with. But
>> I think we are on the right track. We get the crash when the wrong
>> perl is set as the current context. I will try to remove my recent
>> solution and try to see why modperl_cmd_modules doesn't use the
>> correct perl. This is the place where the problem comes from.
>
>
> Please try this patch:
Trying your patch with the short conf file that I posted a few minutes
ago, the -t test now passes "syntax OK", but the server still won't start.
Running "C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t -f
C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS"
still crashes at the same "Free to wrong pool" place in the code,
although its much earlier and I don't see that error message in the
console now. Here's the stack trace:
=====
VMem::Free(void * 0x009fa3ac) line 208 + 3 bytes
CPerlHost::Free(void * 0x009fa3ac) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x009fa3ac) line 302
Perl_safesysfree(void * 0x009fa3ac) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002643cc, sv * 0x002653c4) line 5198 + 13
bytes
Perl_sv_free(interpreter * 0x002643cc, sv * 0x002653c4) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x002643cc) line 189 + 13 bytes
perl_destruct(interpreter * 0x002643cc) line 456 + 23 bytes
modperl_perl_destruct(interpreter * 0x002643cc) line 144 + 9 bytes
modperl_interp_destroy(modperl_interp_t * 0x00924e80) line 128 + 12 bytes
modperl_interp_pool_destroy(void * 0x00851230) line 184 + 12 bytes
run_cleanups(cleanup_t * * 0x00852608) line 1979 + 13 bytes
apr_pool_destroy(apr_pool_t * 0x008525f8) line 755 + 12 bytes
apr_pool_clear(apr_pool_t * 0x0028a9e8) line 715 + 12 bytes
main(int 7, const char * const * 0x00282908) line 619
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=====
and the mp2 trace:
=====
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -d C:/Temp/modperl-2.0/t
-f C:/Tem
p/modperl-2.0/t/conf/httpd.conf -DAPACHE2 -DPERL_USEITHREADS
mod_perl trace flags dump:
c On (configuration for directive handlers)
d On (directive processing)
e Off (environment variables)
f Off (filters)
g On (Perl runtime interaction)
h On (handlers)
i On (interpreter pool management)
m On (memory allocations)
o On (I/O)
s On (perl sections)
t Off (benchmark-ish timings)
mod_perl.c:515: mod_perl globals are configured
modperl_global.c:88: init pconf
modperl_global.c:88: init threaded_mpm
modperl_global.c:88: init server_rec
modperl_config.c:187: p=0x28aa50, s=0x82c4d8, virtual=0
modperl_config.c:137: 0x84fd38
modperl_config.c:137: 0x8509e8
modperl_config.c:121: 0x850ca8
modperl_config.c:187: p=0x28aa50, s=0x850670, virtual=1
modperl_cmd.c:259: arg = +Parent
MpSrv flags dump (localhost):
Clone Off
Parent Off
Enable On
Autoload Off
MergeHandlers Off
Authz On
Authen On
PostConfig On
ChildExit On
OutputFilter On
Response On
Log On
PostReadRequest On
OpenLogs On
PreConnection On
MapToStorage On
ProcessConnection On
ChildInit On
Fixup On
HeaderParser On
InputFilter On
Type On
Trans On
Cleanup On
Access On
Unset On
mod_perl.c:235: starting the parent perl for the base server
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -e;0
modperl_interp.c:232: server=localhost:8529
modperl_interp.c:107: 0x928af8
mod_perl.c:304: constructed interpreter=0x2643ec
mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8
MpSrv flags dump ((null)):
Clone Off
Parent On
Enable On
Autoload Off
MergeHandlers Off
Authz On
Authen On
PostConfig On
ChildExit On
OutputFilter On
Response On
Log On
PostReadRequest On
OpenLogs On
PreConnection On
MapToStorage On
ProcessConnection On
ChildInit On
Fixup On
HeaderParser On
InputFilter On
Type On
Trans On
Cleanup On
Access On
Unset On
mod_perl.c:239: starting the parent perl for vhost (null):8530
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -e;0
modperl_interp.c:232: server=(null):8530
modperl_interp.c:107: 0x93eef0
mod_perl.c:304: constructed interpreter=0x92c25c
mod_perl.c:394: created parent interpreter for VirtualHost (null):8530
mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8
mod_perl.c:375: server (null):8530 already initialized
modperl_handler.c:23: [2644/1936] new handler Apache::PerlSections
modperl_util.c:160: sv_setref_pv(Apache::CmdParms, 0x6fec8)
modperl_handler.c:75: dup handler Apache::PerlSections
modperl_handler.c:23: [2644/1936] new handler Apache::PerlSections
MpHandler flags dump (Apache::PerlSections):
Parsed Off
Method Off
Object Off
Anon Off
Autoload Off
Dynamic Off
Fake Off
modperl_handler.c:52: [2644/1936 (null):8530] handler
Apache::PerlSections was n
ot compiled at startup, attempting to resolve using current pool 0x28aa50
modperl_mgv.c:264: package Apache::PerlSections not defined, attempting
to load
modperl_mgv.c:268: loaded Apache::PerlSections package
modperl_mgv.c:296: [2644/1936] found `handler' in class
`Apache::PerlSections' a
s a method
modperl_config.c:121: 0x851658
modperl_config.c:220: basev==0x84f878, addv==0x850ca8
mod_perl.c:355: Init vhost (null):8530: s=0x850670, base_s=0x82c4d8
mod_perl.c:375: server (null):8530 already initialized
modperl_config.c:137: 0x851e88
modperl_config.c:63: basev==0x84fd38, addv==0x8509e8
modperl_callback.c:156: no PerlOpenLogsHandler handlers configured ()
=====
Using the full vhost test setup I do still see the "Free to wrong pool"
message as before, but the stack trace is still shorter. Here it is:
=====
VMem::Free(void * 0x00acea1c) line 208 + 3 bytes
CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302
Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13
bytes
Perl_sv_free(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5342 + 13 bytes
Perl_av_undef(interpreter * 0x012aff6c, av * 0x013a1ae8) line 498 + 32 bytes
Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1ae8) line 5161 + 13
bytes
Perl_sv_free(interpreter * 0x012aff6c, sv * 0x013a1ae8) line 5342 + 13 bytes
Perl_free_tmps(interpreter * 0x012aff6c) line 189 + 13 bytes
Perl_pp_nextstate(interpreter * 0x012aff6c) line 41 + 23 bytes
Perl_runops_debug(interpreter * 0x012aff6c) line 1434 + 13 bytes
S_call_body(interpreter * 0x012aff6c, op * 0x0006fbe0, int 1) line 2193
+ 13 bytes
Perl_eval_sv(interpreter * 0x012aff6c, sv * 0x012c759c, long 2) line
2253 + 15 bytes
Perl_require_pv(interpreter * 0x012aff6c, const char * 0x0088cec8) line
2351 + 15 bytes
modperl_require_file(interpreter * 0x012aff6c, const char * 0x0088cec8,
int 1) line 30 + 13 bytes
modperl_config_apply_PerlRequire(server_rec * 0x0088bfd0,
modperl_config_srv_t * 0x0088c9f0, interpreter * 0x012aff6c, apr_pool_t
* 0x0028a9e8) line 360 + 21 bytes
modperl_startup(server_rec * 0x0088bfd0, apr_pool_t * 0x0028a9e8) line
320 + 21 bytes
modperl_init_vhost(server_rec * 0x0088bfd0, apr_pool_t * 0x0028a9e8,
server_rec * 0x0082c4d8) line 393 + 13 bytes
modperl_init(server_rec * 0x0082c4d8, apr_pool_t * 0x0028a9e8) line 457
+ 17 bytes
modperl_hook_init(apr_pool_t * 0x0028a9e8, apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000, server_rec * 0x0082c4d8) line 582 + 13 bytes
modperl_run() line 596 + 21 bytes
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void *
0x00854bb8, const char * 0x00865200) line 506
invoke_cmd(const command_struct * 0x100251b8, cmd_parms_struct *
0x0006fec8, void * 0x00854bb8, const char * 0x00865200) line 713 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x008651e0, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x008651e0, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
ap_process_config_tree(server_rec * 0x0082c4d8, ap_directive_t *
0x00854e88, apr_pool_t * 0x0028a9e8, apr_pool_t * 0x0084c550) line 1594
+ 20 bytes
main(int 7, const char * const * 0x00282908) line 582
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=====
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> This and your trace proves my suspicion that my solution just happened
> to work for the particular setup you had the crush with. But I think we
> are on the right track. We get the crash when the wrong perl is set as
> the current context. I will try to remove my recent solution and try to
> see why modperl_cmd_modules doesn't use the correct perl. This is the
> place where the problem comes from.
Please try this patch:
Index: src/modules/perl/mod_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.201
diff -u -r1.201 mod_perl.c
--- src/modules/perl/mod_perl.c 23 Oct 2003 05:57:46 -0000 1.201
+++ src/modules/perl/mod_perl.c 23 Oct 2003 08:30:45 -0000
@@ -458,13 +458,6 @@
exit(1); /*XXX*/
}
}
-
-#ifdef USE_ITHREADS
- /* after other parent perls were started in vhosts, make sure that
- * the context is set to the base_perl */
- PERL_SET_CONTEXT(base_perl);
-#endif
-
}
#ifdef USE_ITHREADS
Index: src/modules/perl/modperl_cmd.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cmd.c,v
retrieving revision 1.48
diff -u -r1.48 modperl_cmd.c
--- src/modules/perl/modperl_cmd.c 16 Sep 2003 01:57:27 -0000 1.48
+++ src/modules/perl/modperl_cmd.c 23 Oct 2003 08:30:45 -0000
@@ -116,6 +116,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(my_perl);
#endif
MP_TRACE_d(MP_FUNC, "load PerlModule %s\n", arg);
@@ -145,6 +146,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
+ PERL_SET_CONTEXT(my_perl);
#endif
MP_TRACE_d(MP_FUNC, "load PerlRequire %s\n", arg);
@@ -381,6 +383,7 @@
#ifdef USE_ITHREADS
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
aTHX = scfg->mip->parent->perl;
+ PERL_SET_CONTEXT(scfg->mip->parent->perl);
#endif
/* data will be set by a <Perl> section */
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Steve, Randy, please try the current cvs (just cvs up + make, no need
>> to rebuild from scratch). I have finally been able to solve the
>> segfault with the short config Steve presented. I hope that it solves
>> the problem for you as well. If it does, please try again with the
>> vhost patch that was failing before.
>>
>> I moved quite a few things in mod_perl.c, but the only real change was
>> adding:
>>
>> +#ifdef USE_ITHREADS
>> + /* after other parent perls were started in vhosts, make sure that
>> + * the context is set to the base_perl */
>> + PERL_SET_CONTEXT(base_perl);
>> +#endif
>>
>> after setting up vhosts, without which, PerlLoadModule in the main
>> server was segfaulting for me.
>
>
> The good news: The short configuration file that I posted now works for
> me too (both the -t test and actually starting up the server).
>
> The bad news: The vhost tests still fail as before :(
Thanks Steve.
> Here's a backtrace of the crash:
This and your trace proves my suspicion that my solution just happened to work
for the particular setup you had the crush with. But I think we are on the
right track. We get the crash when the wrong perl is set as the current
context. I will try to remove my recent solution and try to see why
modperl_cmd_modules doesn't use the correct perl. This is the place where the
problem comes from.
> I'll try to cut down the conf file to the minimum that still crashes,
> and post a full trace then.
If it takes too much of your time, just let me play with it and I'll post a
proper fix tomorrow, hopefully this time doing it right for all configs.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve, Randy, please try the current cvs (just cvs up + make, no need
> to rebuild from scratch). I have finally been able to solve the
> segfault with the short config Steve presented. I hope that it solves
> the problem for you as well. If it does, please try again with the
> vhost patch that was failing before.
>
> I moved quite a few things in mod_perl.c, but the only real change was
> adding:
>
> +#ifdef USE_ITHREADS
> + /* after other parent perls were started in vhosts, make sure that
> + * the context is set to the base_perl */
> + PERL_SET_CONTEXT(base_perl);
> +#endif
>
> after setting up vhosts, without which, PerlLoadModule in the main
> server was segfaulting for me.
The good news: The short configuration file that I posted now works for
me too (both the -t test and actually starting up the server).
The bad news: The vhost tests still fail as before :(
Here's a backtrace of the crash:
=====
VMem::Free(void * 0x0123d68c) line 208 + 3 bytes
CPerlHost::Free(void * 0x0123d68c) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x012916e4, void * 0x0123d68c) line 302
Perl_safesysfree(void * 0x0123d68c) line 143 + 26 bytes
Perl_sv_clear(interpreter * 0x002644c4, sv * 0x009244c0) line 5198 + 13
bytes
Perl_sv_replace(interpreter * 0x002644c4, sv * 0x009244c0, sv *
0x012845d4) line 5046 + 13 bytes
Perl_leave_scope(interpreter * 0x002644c4, long 290) line 699 + 17 bytes
Perl_newATTRSUB(interpreter * 0x002644c4, long 290, op * 0x012b6558, op
* 0x00000000, op * 0x00000000, op * 0x012b6578) line 4402 + 24 bytes
Perl_utilize(interpreter * 0x002644c4, int 1, long 290, op * 0x00000000,
op * 0x012b6714, op * 0x00000000) line 2983 + 173 bytes
Perl_yyparse(interpreter * 0x002644c4) line 414 + 44 bytes
S_doeval(interpreter * 0x002644c4, int 0, op * * 0x00000000, cv *
0x00000000, unsigned long 6796) line 2802 + 9 bytes
Perl_pp_require(interpreter * 0x002644c4) line 3298 + 102 bytes
modperl_pp_require(interpreter * 0x002644c4) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x002644c4) line 1434 + 13 bytes
S_call_body(interpreter * 0x002644c4, op * 0x0006f8b0, int 1) line 2193
+ 13 bytes
Perl_eval_sv(interpreter * 0x002644c4, sv * 0x0128e3e0, long 2) line
2253 + 15 bytes
modperl_require_module(interpreter * 0x002644c4, const char *
0x008ae700, int 0) line 13 + 15 bytes
modperl_cmd_modules(cmd_parms_struct * 0x0006f9fc, void * 0x00854768,
const char * 0x008ae700) line 122 + 15 bytes
invoke_cmd(const command_struct * 0x10025038, cmd_parms_struct *
0x0006f9fc, void * 0x00854768, const char * 0x008ae590) line 800 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x008ae560, cmd_parms_struct *
0x0006f9fc, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x008ae560, cmd_parms_struct *
0x0006f9fc, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
modperl_config_insert(interpreter * 0x012ba014, server_rec * 0x0082c4d8,
apr_pool_t * 0x0028acb0, apr_pool_t * 0x00000000, int 150, char *
0x00000000, ap_conf_vector_t * 0x0082caa8, sv * 0x013a22d0) line 446 +
18 bytes
modperl_config_insert_server(interpreter * 0x012ba014, server_rec *
0x0082c4d8, sv * 0x013a22d0) line 464 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x012ba014, cv * 0x01304364)
line 99 + 17 bytes
Perl_pp_entersub(interpreter * 0x012ba014) line 2817 + 16 bytes
Perl_runops_debug(interpreter * 0x012ba014) line 1434 + 13 bytes
S_call_body(interpreter * 0x012ba014, op * 0x0006fbe0, int 1) line 2193
+ 13 bytes
Perl_eval_sv(interpreter * 0x012ba014, sv * 0x012c7af8, long 2) line
2253 + 15 bytes
Perl_require_pv(interpreter * 0x012ba014, const char * 0x0088ca80) line
2351 + 15 bytes
modperl_require_file(interpreter * 0x012ba014, const char * 0x0088ca80,
int 1) line 30 + 13 bytes
modperl_config_apply_PerlRequire(server_rec * 0x0088bb88,
modperl_config_srv_t * 0x0088c5a8, interpreter * 0x012ba014, apr_pool_t
* 0x0028acb0) line 360 + 21 bytes
modperl_startup(server_rec * 0x0088bb88, apr_pool_t * 0x0028acb0) line
320 + 21 bytes
modperl_init_vhost(server_rec * 0x0088bb88, apr_pool_t * 0x0028acb0,
server_rec * 0x0082c4d8) line 393 + 13 bytes
modperl_init(server_rec * 0x0082c4d8, apr_pool_t * 0x0028acb0) line 457
+ 17 bytes
modperl_hook_init(apr_pool_t * 0x0028acb0, apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000, server_rec * 0x0082c4d8) line 589 + 13 bytes
modperl_run() line 603 + 21 bytes
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec8, void *
0x00854768, const char * 0x00864db0) line 503
invoke_cmd(const command_struct * 0x100251b8, cmd_parms_struct *
0x0006fec8, void * 0x00854768, const char * 0x00864db0) line 713 + 18 bytes
ap_walk_config_sub(const ap_directive_t * 0x00864d90, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1082 + 24 bytes
ap_walk_config(ap_directive_t * 0x00864d90, cmd_parms_struct *
0x0006fec8, ap_conf_vector_t * 0x0082caa8) line 1121 + 17 bytes
ap_process_config_tree(server_rec * 0x0082c4d8, ap_directive_t *
0x00854a38, apr_pool_t * 0x0028acb0, apr_pool_t * 0x0084c550) line 1594
+ 20 bytes
main(int 8, const char * const * 0x00282918) line 582
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e814c7()
=====
and here's the end of the MOD_PERL_TRACE=cdghimos output:
=====
[...]
mod_perl.c:239: starting the parent perl for vhost localhost:8530
modperl_config_srv_argv_init =>
0 = Apache.exe
1 = -IC:/Temp/modperl-2.0/t
2 = -e;0
modperl_interp.c:232: server=localhost:8530
modperl_interp.c:107: 0x12c8908
mod_perl.c:304: constructed interpreter=0x12b0c34
modperl_config.c:361: loaded Perl file:
C:/Temp/modperl-2.0/t/conf/modperl_inc.pl for server localhost:8530
mod_perl.c:355: Init vhost localhost:8529: s=0x82c4d8, base_s=0x82c4d8
mod_perl.c:359: base server is not vhost, skipping localhost:8529
modperl_cmd.c:120: load PerlModule TestVhost::basic
Free to wrong pool 1291f38 not 262880.
=====
I'll try to cut down the conf file to the minimum that still crashes,
and post a full trace then.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Steve, Randy, please try the current cvs (just cvs up + make, no need to
rebuild from scratch). I have finally been able to solve the segfault with the
short config Steve presented. I hope that it solves the problem for you as
well. If it does, please try again with the vhost patch that was failing before.
I moved quite a few things in mod_perl.c, but the only real change was adding:
+#ifdef USE_ITHREADS
+ /* after other parent perls were started in vhosts, make sure that
+ * the context is set to the base_perl */
+ PERL_SET_CONTEXT(base_perl);
+#endif
after setting up vhosts, without which, PerlLoadModule in the main server was
segfaulting for me.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
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/httpd/prefork/bin/httpd -t -d `pwd`/t -f
> `pwd`/t/conf/httpd.conf -DAPACHE2
> [Wed Oct 15 23:27:39 2003] [info] 23 Apache:: modules loaded
> [Wed Oct 15 23:27:39 2003] [info] 5 APR:: modules loaded
> [Wed Oct 15 23:27:39 2003] [info] base server + 13 vhosts ready to run
> tests
> Syntax OK
> END in modperl_extra.pl, pid=6659
>
> Does this work? It runs the config phase only once.
Still fails:
C:\Temp\modperl-2.0>C:\apache2\bin\Apache.exe -t -d
C:/Temp/modperl-2.0/t -f C:/Temp/modperl-2.0/t/conf/httpd.conf -DAPACHE2
-DPERL_USEITHREADS
[Thu Oct 16 10:42:28 2003] [info] 23 Apache:: modules loaded
[Thu Oct 16 10:42:28 2003] [info] 5 APR:: modules loaded
[Thu Oct 16 10:42:28 2003] [info] base server + 13 vhosts ready to run tests
Free to wrong pool 124c668 not 262770.
Note the errors or messages above, and press the <ESC> key to exit. 29...
It does fail during the startup, but way down in the list of stuff that
the .conf file is loading.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Steve Hay <st...@uk.radan.com>.
[picking up this thread as requested by Stas deep in the bowels of the
t/SMOKE thread!...]
Stas Bekman wrote:
> Randy Kobes wrote:
>
>>> In the light of recent changes in pools, does this make any
>>> difference to the
>>> early startup in a vhost issue? Here is the patch again:
>>> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106166256116212&w=2
>>>
>>
>>
>>
>> Hi Stas,
>> Unfortunately, not. Without the above patch I got all
>> tests to pass, but with it, I get a "free to wrong pool ..",
>> coming from about line 1121 of perl-5.8.1/win32/vmem.h.
>
>
> Oh, that's the perl pool, not apr pool ;)
Just to confirm that I have the same problem: I've taken the latest
CVS, applied the above-cited patch (which adds the vhost test), and now
"perl t/TEST -start" doesn't even get off the ground. I get the same
"free to wrong pool" error.
>
>
>> I imagine you're busy now, so we can look at this later,
>> but the problem comes in the VMem::Free() of win32/vmem.h:
>
>
> aiy, that's going to be a tough one to debug remotely. I'd guess that
> on linux the code would be totally different. So if we can try to
> deduct the possible cause it'd be much better. There are a few things
> that could cause that, e.g. things in mod_perl.c that I'd look at:
>
> ====
> /* XXX: in 5.7.2+ we can call the body of modperl_boot here
> * but in 5.6.1 the Perl runtime is not properly setup yet
> * so we have to pull this stunt to delay
> */
> SAVEDESTRUCTOR_X(modperl_boot, 0);
> ====
> if (!scfg->mip) {
> /* since mips are created after merge_server_configs()
> * need to point to the base mip here if this vhost
> * doesn't have its own
> */
> MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n",
> vhost, modperl_server_desc(base_server, p));
> scfg->mip = base_scfg->mip;
> }
> ====
>
> Also anything that has to do with:
>
> PerlOptions +Parent
>
> So I'd follow any place that does things if MpSrvPARENT is true. I
> guess this is the first place to start looking it.
>
>> ================================================================
>> void VMem::Free(void* pMem)
>> {
>> #ifdef _USE_LINKED_LIST
>> if (pMem) {
>> PMEMORY_BLOCK_HEADER ptr =
>> (PMEMORY_BLOCK_HEADER)(((char*)pMem)-sizeof(MEMORY_BLOCK_HEADER));
>> if (ptr->owner != this) {
>> if (ptr->owner) {
>> #if 1
>> dTHX;
>> int *nowhere = NULL;
>> Perl_warn(aTHX_ "Free to wrong pool %p not
>> %p",this,ptr->owner);
>> *nowhere = 0;
>> #else
>> ptr->owner->Free(pMem);
>> #endif
>> }
>> return;
>> }
>> GetLock();
>> UnlinkBlock(ptr);
>> ptr->owner = NULL;
>> m_pfree(ptr);
>> FreeLock();
>> }
>> #else
>> m_pfree(pMem);
>> #endif
>> }
>> ================================================================
>> and, in the debugger, the "ptr" symbol can't be found (pMem
>> is). I'll try to look into this further - in the meantime,
>> here's a stacktrace:
>> =================================================================
>> VMem::Free(VMem * const 0x013567e8, void * 0x013464c4) line 208
>> PerlMemFree(IPerlMem * 0x012fe1b4, void * 0x013464c4) line 302
>> Perl_safesysfree(void * 0x013464c4) line 143 + 14 bytes
>> Perl_sv_clear(interpreter * 0x0026ee24, sv * 0x00000000) line 5197
>> Perl_sv_replace(interpreter * 0x0026ee24, sv * 0x008b3db8, sv *
>> 0x0133573c) line 5048
>> Perl_leave_scope(interpreter * 0x0026ee24, long 290) line 695 + 11 bytes
>> Perl_newATTRSUB(interpreter * 0x013680f4, long 290, op * 0x0134f0b4,
>> op * 0x00000000, op * 0x013680f4, op * 0x0134f0d4) line 4402 + 22 bytes
>> Perl_utilize(interpreter * 0x28029afb, int 0, long 20348780, op *
>> 0x00000122, op * 0x00000000, op * 0x0134f270) line 3002
>> Perl_yyparse(interpreter * 0x2803974a) line 414 + 21 bytes
>> S_doeval(interpreter * 0x0134f330, int 0, op * * 0x00000000, cv *
>> 0x00000000, unsigned long 8360) line 2802 + 6 bytes
>> Perl_pp_require(interpreter * 0x00901ad4) line 3298 + 58 bytes
>> modperl_pp_require(interpreter * 0x0026ee24) line 54 + 10 bytes
>> Perl_runops_standard(interpreter * 0x0026ee24) line 23 + 12 bytes
>> S_call_body(interpreter * 0x0026ee24, op * 0x0006f960, int 1) line
>> 2193 + 7 bytes
>> Perl_eval_sv(interpreter * 0x0026ee24, sv * 0x013375e0, long 2) line
>> 2274 + 13 bytes
>> modperl_require_module(interpreter * 0x0026ee24, const char *
>> 0x011924e0, int 0) line 13 + 15 bytes
>
>
> Can you please go up to this frame and lookup what module doesn't try
> to require? Apache::PerlSection I'd guess?
>
> What happens if you replace that code with:
>
> use Apache::PerlSection;
> $s->add_config(['<Perl >', '1;', '</Perl>']);
>
> I'd guess that this will workaround the problem. If it's not
> Apache::PerlSection, see which one is that and load it before
> $s->add_config.
It seems to fall over at line 19 of the new t/htdocs/vhost/startup.pl --
the line "PerlModule TestVhost::basic" in $conf.
I tried adding "use TestVhost::basic" before the "$s->add_config([split
/\n/, $conf]);" call, but that made no difference.
I've attached a stacktrace and the console output when running with
MOD_PERL_TRACE=all (!). Hopefully you can wade through it and find
something relevant?
Here's one interesting thing that I noticed when walking through it:-
We reach line 800 of Apache's server/config.c:
if ((errmsg = cmd->AP_TAKE1(parms, mconfig, w)))
Here cmf->func is modperl_cmd_modules, mconfig can't be expanded (but
it's a non-NULL pointer), and w is "TestVhost::basic". We go into
MP_CMD_SRV_DECLARE(modules) in mp2's src/modules/perl/modperl_cmd.c and
reach line 118 which has this interesting comment above it:
/* XXX: .htaccess support cannot use this perl with threaded MPMs */
dTHXa(scfg->mip->parent->perl);
I don't understand what it means, but it's got a nasty XXX and I think
the "threaded MPM" bit is relevant on Win32, isn't it? (Not that I know
what that means either...)
The "arg" that modperl_require_module() is called with next is, of
course, "TestVhost::basic" and it fails as you see from the stack trace.
Shot in the dark: I notice there's a Perl_safesysfree() call near the
end of the stacktrace. Is it anything to do with things being run "too
soon", like the trouble we had before with Perl_safesysmalloc()? (See
http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2003-09/msg00960.html)
I don't think this safesysfree() call is anything like as early as that
safesysmalloc() call was, but I thought I'd bring it up just in case.
- Steve
Re: early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
>>In the light of recent changes in pools, does this make any difference to the
>>early startup in a vhost issue? Here is the patch again:
>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106166256116212&w=2
>
>
> Hi Stas,
> Unfortunately, not. Without the above patch I got all
> tests to pass, but with it, I get a "free to wrong pool ..",
> coming from about line 1121 of perl-5.8.1/win32/vmem.h.
Oh, that's the perl pool, not apr pool ;)
> I imagine you're busy now, so we can look at this later,
> but the problem comes in the VMem::Free() of win32/vmem.h:
aiy, that's going to be a tough one to debug remotely. I'd guess that on linux
the code would be totally different. So if we can try to deduct the possible
cause it'd be much better. There are a few things that could cause that, e.g.
things in mod_perl.c that I'd look at:
====
/* XXX: in 5.7.2+ we can call the body of modperl_boot here
* but in 5.6.1 the Perl runtime is not properly setup yet
* so we have to pull this stunt to delay
*/
SAVEDESTRUCTOR_X(modperl_boot, 0);
====
if (!scfg->mip) {
/* since mips are created after merge_server_configs()
* need to point to the base mip here if this vhost
* doesn't have its own
*/
MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n",
vhost, modperl_server_desc(base_server, p));
scfg->mip = base_scfg->mip;
}
====
Also anything that has to do with:
PerlOptions +Parent
So I'd follow any place that does things if MpSrvPARENT is true. I guess this
is the first place to start looking it.
> ================================================================
> void VMem::Free(void* pMem)
> {
> #ifdef _USE_LINKED_LIST
> if (pMem) {
> PMEMORY_BLOCK_HEADER ptr = (PMEMORY_BLOCK_HEADER)(((char*)pMem)-sizeof(MEMORY_BLOCK_HEADER));
> if (ptr->owner != this) {
> if (ptr->owner) {
> #if 1
> dTHX;
> int *nowhere = NULL;
> Perl_warn(aTHX_ "Free to wrong pool %p not %p",this,ptr->owner);
> *nowhere = 0;
> #else
> ptr->owner->Free(pMem);
> #endif
> }
> return;
> }
> GetLock();
> UnlinkBlock(ptr);
> ptr->owner = NULL;
> m_pfree(ptr);
> FreeLock();
> }
> #else
> m_pfree(pMem);
> #endif
> }
> ================================================================
> and, in the debugger, the "ptr" symbol can't be found (pMem
> is). I'll try to look into this further - in the meantime,
> here's a stacktrace:
> =================================================================
> VMem::Free(VMem * const 0x013567e8, void * 0x013464c4) line 208
> PerlMemFree(IPerlMem * 0x012fe1b4, void * 0x013464c4) line 302
> Perl_safesysfree(void * 0x013464c4) line 143 + 14 bytes
> Perl_sv_clear(interpreter * 0x0026ee24, sv * 0x00000000) line 5197
> Perl_sv_replace(interpreter * 0x0026ee24, sv * 0x008b3db8, sv * 0x0133573c) line 5048
> Perl_leave_scope(interpreter * 0x0026ee24, long 290) line 695 + 11 bytes
> Perl_newATTRSUB(interpreter * 0x013680f4, long 290, op * 0x0134f0b4, op * 0x00000000, op * 0x013680f4, op * 0x0134f0d4) line 4402 + 22 bytes
> Perl_utilize(interpreter * 0x28029afb, int 0, long 20348780, op * 0x00000122, op * 0x00000000, op * 0x0134f270) line 3002
> Perl_yyparse(interpreter * 0x2803974a) line 414 + 21 bytes
> S_doeval(interpreter * 0x0134f330, int 0, op * * 0x00000000, cv * 0x00000000, unsigned long 8360) line 2802 + 6 bytes
> Perl_pp_require(interpreter * 0x00901ad4) line 3298 + 58 bytes
> modperl_pp_require(interpreter * 0x0026ee24) line 54 + 10 bytes
> Perl_runops_standard(interpreter * 0x0026ee24) line 23 + 12 bytes
> S_call_body(interpreter * 0x0026ee24, op * 0x0006f960, int 1) line 2193 + 7 bytes
> Perl_eval_sv(interpreter * 0x0026ee24, sv * 0x013375e0, long 2) line 2274 + 13 bytes
> modperl_require_module(interpreter * 0x0026ee24, const char * 0x011924e0, int 0) line 13 + 15 bytes
Can you please go up to this frame and lookup what module doesn't try to
require? Apache::PerlSection I'd guess?
What happens if you replace that code with:
use Apache::PerlSection;
$s->add_config(['<Perl >', '1;', '</Perl>']);
I'd guess that this will workaround the problem. If it's not
Apache::PerlSection, see which one is that and load it before $s->add_config.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: early perl startup in vhost on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 26 Sep 2003, Stas Bekman wrote:
> [picking up an old thread, giving it a better subject]
>
> >> On Sat, 23 Aug 2003, Stas Bekman wrote:
> >>> Randy, back to the drawing board. Can you try this patch
> >>> (you will need to rerun t/TEST -conf). This is regarding
> >>> the win32 issue you had with this change:
> >>> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
> >>>
> >>> I have restored it now in a separate vhost. I'm not sure
> >>> though if I have reproduced the problem as it was
> >>> originally. Hope you remember what was it.
> >>
> >> Thanks, Stas - that seems to have reproduced the problem; I
> >> get a "free to wrong pool 13ca860 not 26d4c8" message, then
> >> an unhandled exception in Apache.exe (Perl58.dll) regarding
> >> an access violation. I'll have to build a perl with
> >> debugging to get further - I'm in the middle of switching to
> >> 5.8.1-tobe.
> >
> > Great, thanks Randy! Looking forward to getting it resolved. However if
> > you are busy with other more urgent things, do them first. We will
> > commit this new test when you will get a chance to debug the problem.
>
> In the light of recent changes in pools, does this make any difference to the
> early startup in a vhost issue? Here is the patch again:
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106166256116212&w=2
Hi Stas,
Unfortunately, not. Without the above patch I got all
tests to pass, but with it, I get a "free to wrong pool ..",
coming from about line 1121 of perl-5.8.1/win32/vmem.h.
I imagine you're busy now, so we can look at this later,
but the problem comes in the VMem::Free() of win32/vmem.h:
================================================================
void VMem::Free(void* pMem)
{
#ifdef _USE_LINKED_LIST
if (pMem) {
PMEMORY_BLOCK_HEADER ptr = (PMEMORY_BLOCK_HEADER)(((char*)pMem)-sizeof(MEMORY_BLOCK_HEADER));
if (ptr->owner != this) {
if (ptr->owner) {
#if 1
dTHX;
int *nowhere = NULL;
Perl_warn(aTHX_ "Free to wrong pool %p not %p",this,ptr->owner);
*nowhere = 0;
#else
ptr->owner->Free(pMem);
#endif
}
return;
}
GetLock();
UnlinkBlock(ptr);
ptr->owner = NULL;
m_pfree(ptr);
FreeLock();
}
#else
m_pfree(pMem);
#endif
}
================================================================
and, in the debugger, the "ptr" symbol can't be found (pMem
is). I'll try to look into this further - in the meantime,
here's a stacktrace:
=================================================================
VMem::Free(VMem * const 0x013567e8, void * 0x013464c4) line 208
PerlMemFree(IPerlMem * 0x012fe1b4, void * 0x013464c4) line 302
Perl_safesysfree(void * 0x013464c4) line 143 + 14 bytes
Perl_sv_clear(interpreter * 0x0026ee24, sv * 0x00000000) line 5197
Perl_sv_replace(interpreter * 0x0026ee24, sv * 0x008b3db8, sv * 0x0133573c) line 5048
Perl_leave_scope(interpreter * 0x0026ee24, long 290) line 695 + 11 bytes
Perl_newATTRSUB(interpreter * 0x013680f4, long 290, op * 0x0134f0b4, op * 0x00000000, op * 0x013680f4, op * 0x0134f0d4) line 4402 + 22 bytes
Perl_utilize(interpreter * 0x28029afb, int 0, long 20348780, op * 0x00000122, op * 0x00000000, op * 0x0134f270) line 3002
Perl_yyparse(interpreter * 0x2803974a) line 414 + 21 bytes
S_doeval(interpreter * 0x0134f330, int 0, op * * 0x00000000, cv * 0x00000000, unsigned long 8360) line 2802 + 6 bytes
Perl_pp_require(interpreter * 0x00901ad4) line 3298 + 58 bytes
modperl_pp_require(interpreter * 0x0026ee24) line 54 + 10 bytes
Perl_runops_standard(interpreter * 0x0026ee24) line 23 + 12 bytes
S_call_body(interpreter * 0x0026ee24, op * 0x0006f960, int 1) line 2193 + 7 bytes
Perl_eval_sv(interpreter * 0x0026ee24, sv * 0x013375e0, long 2) line 2274 + 13 bytes
modperl_require_module(interpreter * 0x0026ee24, const char * 0x011924e0, int 0) line 13 + 15 bytes
modperl_cmd_modules(cmd_parms_struct * 0x0006fa88, void * 0x00851f50, const char * 0x011924e0) line 122 + 15 bytes
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x1001c528, void * 0x0006fa88, const char * 0x00851f50) line 800 + 10 bytes
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x01192338, ap_conf_vector_t * 0x0006fa88) line 1082 + 12 bytes
ap_walk_config(ap_directive_t * 0x100059aa, cmd_parms_struct * 0x01192338, ap_conf_vector_t * 0x0006fa88) line 1121 + 11 bytes
modperl_config_insert(interpreter * 0x0134fc44, server_rec * 0x0082a390, apr_pool_t * 0x0026a7e8, apr_pool_t * 0x00000000, int 150, char * 0x00000000, ap_conf_vector_t * 0x0082a960, sv * 0x01436e54) line 443 + 18 bytes
modperl_config_insert_server(interpreter * 0x0134fc44, server_rec * 0x0082a390, sv * 0x01436e54) line 461 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x0134fc44, cv * 0x0139a350) line 99 + 17 bytes
Perl_pp_entersub(interpreter * 0x0134fc44) line 2820
Perl_runops_standard(interpreter * 0x0134fc44) line 23 + 12 bytes
S_call_body(interpreter * 0x0134fc44, op * 0x0006fc08, int 1) line 2193 + 7 bytes
Perl_eval_sv(interpreter * 0x0134fc44, sv * 0x0135d908, long 2) line 2274 + 13 bytes
Perl_require_pv(interpreter * 0x0134fc44, const char * 0x00887530) line 2353
modperl_require_file(interpreter * 0x0134fc44, const char * 0x00887530, int 1) line 30 + 13 bytes
modperl_config_apply_PerlRequire(server_rec * 0x00886638, modperl_config_srv_t * 0x00887058, interpreter * 0x0134fc44, apr_pool_t * 0x0026a7e8) line 357 + 21 bytes
modperl_startup(server_rec * 0x00886638, apr_pool_t * 0x0026a7e8) line 285 + 21 bytes
modperl_init_vhost(server_rec * 0x00886638, apr_pool_t * 0x0026a7e8, server_rec * 0x0082a390) line 355 + 13 bytes
modperl_init(server_rec * 0x0082a390, apr_pool_t * 0x0026a7e8) line 431 + 17 bytes
modperl_hook_init(apr_pool_t * 0x0026a7e8, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, server_rec * 0x0082a390) line 554 + 13 bytes
modperl_run() line 568 + 21 bytes
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec0, void * 0x00851f50, const char * 0x00861840) line 503
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x1001c6a8, void * 0x0006fec0, const char * 0x00851f50) line 713 + 14 bytes
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x00861820, ap_conf_vector_t * 0x0006fec0) line 1082 + 12 bytes
ap_walk_config(ap_directive_t * 0x6ff032e3, cmd_parms_struct * 0x00852220, ap_conf_vector_t * 0x0006fec0) line 1121 + 11 bytes
ap_process_config_tree(server_rec * 0x0082a390, ap_directive_t * 0x00852220, apr_pool_t * 0x0026a7e8, apr_pool_t * 0x0084a108) line 1594 + 35 bytes
main(int 4201858, const char * const * 0x00000008) line 582
APACHE! mainCRTStartup + 227 bytes
KERNEL32! 77e7eb69()
===================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
early perl startup in vhost on win32
Posted by Stas Bekman <st...@stason.org>.
[picking up an old thread, giving it a better subject]
>> On Sat, 23 Aug 2003, Stas Bekman wrote:
>>
>>
>>> Randy, back to the drawing board. Can you try this patch
>>> (you will need to rerun t/TEST -conf). This is regarding
>>> the win32 issue you had with this change:
>>> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>>>
>>>
>>> I have restored it now in a separate vhost. I'm not sure
>>> though if I have reproduced the problem as it was
>>> originally. Hope you remember what was it.
>>
>>
>>
>> Thanks, Stas - that seems to have reproduced the problem; I
>> get a "free to wrong pool 13ca860 not 26d4c8" message, then
>> an unhandled exception in Apache.exe (Perl58.dll) regarding
>> an access violation. I'll have to build a perl with
>> debugging to get further - I'm in the middle of switching to
>> 5.8.1-tobe.
>
>
> Great, thanks Randy! Looking forward to getting it resolved. However if
> you are busy with other more urgent things, do them first. We will
> commit this new test when you will get a chance to debug the problem.
In the light of recent changes in pools, does this make any difference to the
early startup in a vhost issue? Here is the patch again:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106166256116212&w=2
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 23 Aug 2003, Stas Bekman wrote:
>
>
>>Randy, back to the drawing board. Can you try this patch
>>(you will need to rerun t/TEST -conf). This is regarding
>>the win32 issue you had with this change:
>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>>
>>I have restored it now in a separate vhost. I'm not sure
>>though if I have reproduced the problem as it was
>>originally. Hope you remember what was it.
>
>
> Thanks, Stas - that seems to have reproduced the problem; I
> get a "free to wrong pool 13ca860 not 26d4c8" message, then
> an unhandled exception in Apache.exe (Perl58.dll) regarding
> an access violation. I'll have to build a perl with
> debugging to get further - I'm in the middle of switching to
> 5.8.1-tobe.
Great, thanks Randy! Looking forward to getting it resolved. However if you
are busy with other more urgent things, do them first. We will commit this new
test when you will get a chance to debug the problem.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 23 Aug 2003, Stas Bekman wrote:
> Randy, back to the drawing board. Can you try this patch
> (you will need to rerun t/TEST -conf). This is regarding
> the win32 issue you had with this change:
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>
> I have restored it now in a separate vhost. I'm not sure
> though if I have reproduced the problem as it was
> originally. Hope you remember what was it.
Thanks, Stas - that seems to have reproduced the problem; I
get a "free to wrong pool 13ca860 not 26d4c8" message, then
an unhandled exception in Apache.exe (Perl58.dll) regarding
an access violation. I'll have to build a perl with
debugging to get further - I'm in the middle of switching to
5.8.1-tobe.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Sat, 12 Apr 2003, Stas Bekman wrote:
>>
>>
>>> Randy Kobes wrote:
>>>
>>>> On Sat, 12 Apr 2003, Stas Bekman wrote:
>>>> [ .. ]
>>>>
>>>>> Hmm, here is a wild guess. Could it be that this change has
>>>>> caused the trouble?
>>>>> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>>>>>
>>>>
>>>>
>>>> Undoing this addition does change things (see below), so this
>>>> looks on the right track, but there's still problems ... I'll
>>>> search around this date ...
>>>
>>>
>>> so it still happens during the destruction. Well it's
>>> definitely the change of
>>> moving mips before modules are required has caused this
>>> problem. Since this test committed separately, you didn't see
>>> the problem when reverting that change, I think.
>>
>>
>>
>> You're exactly right though that this is where the problem is - I
>> had undone the above particular change, but there was another one
>> involving Apache->server->add_config() that was still present.
>> Reverting to the March 24th t/conf/modperl_extra.pl (which
>> doesn't have any Apache->server->add_config() calls), but keeping
>> everything else at the current cvs level, allows the tests to
>> run.
>
>
> Thanks, Randy. Now need to imagine why would win32 have problems with
> this change.
>
>> There's a handful of failures now, but that might be another
>> related, or unrelated, problem.
Randy, back to the drawing board. Can you try this patch (you will need to
rerun t/TEST -conf). This is regarding the win32 issue you had with this change:
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
I have restored it now in a separate vhost. I'm not sure though if I have
reproduced the problem as it was originally. Hope you remember what was it.
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/htdocs/vhost/startup.pl 2003-08-23 11:06:00.000000000 -0700
@@ -0,0 +1,32 @@
+use Apache2;
+use Apache::ServerUtil ();
+use Apache::Server ();
+use Apache::Process ();
+
+use File::Spec::Functions qw(catdir);
+
+# gives us the current vhost's server
+
+my $s = Apache->server;
+my $p = $s->process->pool;
+
+# XXX: how do we get the docroot for the vhost? there is no such method
+my $doc_root = catdir Apache::server_root, qw(htdocs vhost);
+
+# testing $s->add_config() in vhost
+my $conf = <<"EOC";
+# must use PerlModule here to check for segfaults
+PerlModule TestVhost::basic
+PerlSetVar DocumentRoot $doc_root
+<Location /TestVhost__basic>
+ SetHandler modperl
+ PerlResponseHandler TestVhost::basic
+</Location>
+EOC
+
+$s->add_config([split /\n/, $conf]);
+
+# this used to have problems on win32
+$s->add_config(['<Perl >', '1;', '</Perl>']);
+
+1;
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/vhost/basic.t 2003-08-22 21:59:17.000000000 -0700
@@ -0,0 +1,30 @@
+# the handler is configured in modperl_extra.pl via
+# Apache->server->add_config
+
+use Apache::TestUtil;
+use Apache::TestRequest 'GET';
+
+my $config = Apache::Test::config();
+my $module = 'TestVhost::basic';
+my $path = Apache::TestRequest::module2path($module);
+
+Apache::TestRequest::module($module);
+my $hostport = Apache::TestRequest::hostport($config);
+
+t_debug("connecting to $hostport");
+my $res = GET "http://$hostport/$path";
+
+if ($res->is_success) {
+ print $res->content;
+}
+else {
+ if ($res->code == 404) {
+ die "this test gets its <Location> configuration added via " .
+ "\@documentroot@/vhost/startup.pl, this could be the cause " .
+ "of the failure";
+ }
+ else {
+ die "server side has failed (response code: ", $res->code, "),\n",
+ "see t/logs/error_log for more details\n";
+ }
+}
--- /dev/null 1969-12-31 16:00:00.000000000 -0800
+++ t/response/TestVhost/basic.pm 2003-08-22 22:45:19.000000000 -0700
@@ -0,0 +1,62 @@
+package TestVhost::basic;
+
+# Test whether vhost with 'PerlOptions +Parent', which doesn't inherit
+# from the base, has its own INC and therefore can have a modules with
+# the same namespace as the base, but different content.
+#
+# Also see the parallel TestDirective::perlmodule handler
+
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestUtil;
+
+use Apache::RequestUtil ();
+
+use File::Spec::Functions qw(catdir);
+
+use Apache::Const -compile => 'OK';
+
+my $vars = Apache::Test::config()->{vars};
+
+sub handler {
+ my $r = shift;
+
+ plan $r, tests => 1;
+
+ {
+ my $expected = $r->document_root;
+ my $received = $r->dir_config->get('DocumentRoot');
+ ok t_cmp($expected, $received, "Vhost DocumentRoot");
+ }
+
+ Apache::OK;
+}
+
+1;
+__END__
+<NoAutoConfig>
+<VirtualHost TestVhost::basic>
+ DocumentRoot @documentroot@/vhost
+
+ <IfDefine PERL_USEITHREADS>
+ # a new interpreter pool
+ PerlOptions +Parent
+ </IfDefine>
+
+ # use test system's @INC
+ PerlSwitches -I@serverroot@
+ PerlRequire "@serverroot@/conf/modperl_inc.pl"
+ PerlRequire "@documentroot@/vhost/startup.pl"
+
+ # <Location /TestVhost__basic> config is added via add_config in
+ # t/htdocs/vhost/startup.pladd_config_startup.pl
+#PerlModule TestVhost::basic
+#PerlSetVar DocumentRoot @documentroot@/vhost
+#<Location /TestVhost__basic>
+# SetHandler modperl
+# PerlResponseHandler TestVhost::basic
+#</Location>
+</VirtualHost>
+</NoAutoConfig>
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 12 Apr 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>>
>>>On Sat, 12 Apr 2003, Stas Bekman wrote:
>>>[ .. ]
>>>
>>>>Hmm, here is a wild guess. Could it be that this change has
>>>>caused the trouble?
>>>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>>>
>>>Undoing this addition does change things (see below), so this
>>>looks on the right track, but there's still problems ... I'll
>>>search around this date ...
>>
>>so it still happens during the destruction. Well it's
>>definitely the change of
>> moving mips before modules are required has caused this
>>problem. Since this test committed separately, you didn't see
>>the problem when reverting that change, I think.
>
>
> You're exactly right though that this is where the problem is - I
> had undone the above particular change, but there was another one
> involving Apache->server->add_config() that was still present.
> Reverting to the March 24th t/conf/modperl_extra.pl (which
> doesn't have any Apache->server->add_config() calls), but keeping
> everything else at the current cvs level, allows the tests to
> run.
Thanks, Randy. Now need to imagine why would win32 have problems with this change.
> There's a handful of failures now, but that might be another
> related, or unrelated, problem.
What are they?
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 12 Apr 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Sat, 12 Apr 2003, Stas Bekman wrote:
> > [ .. ]
> >>Hmm, here is a wild guess. Could it be that this change has
> >>caused the trouble?
> >>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
> >
> > Undoing this addition does change things (see below), so this
> > looks on the right track, but there's still problems ... I'll
> > search around this date ...
>
> so it still happens during the destruction. Well it's
> definitely the change of
> moving mips before modules are required has caused this
> problem. Since this test committed separately, you didn't see
> the problem when reverting that change, I think.
You're exactly right though that this is where the problem is - I
had undone the above particular change, but there was another one
involving Apache->server->add_config() that was still present.
Reverting to the March 24th t/conf/modperl_extra.pl (which
doesn't have any Apache->server->add_config() calls), but keeping
everything else at the current cvs level, allows the tests to
run. There's a handful of failures now, but that might be another
related, or unrelated, problem.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 12 Apr 2003, Stas Bekman wrote:
>
> [ .. ]
>
>>Hmm, here is a wild guess. Could it be that this change has caused the trouble?
>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>
>
> Undoing this addition does change things (see below), so this
> looks on the right track, but there's still problems ... I'll
> search around this date ...
so it still happens during the destruction. Well it's definitely the change of
moving mips before modules are required has caused this problem. Since this
test committed separately, you didn't see the problem when reverting that
change, I think.
I haven't tested the worker-mpm for a while and now that I did, there are
segfaults here and there (different with 5.8.0 and blead-perl). I'll
investigate these next week and hopefully they will trigger similar problems
to yours).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 12 Apr 2003, Stas Bekman wrote:
[ .. ]
> Hmm, here is a wild guess. Could it be that this change has caused the trouble?
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
Undoing this addition does change things (see below), so this
looks on the right track, but there's still problems ... I'll
search around this date ...
================================================================
VMem::Free(void * 0x01ace64c) line 208 + 3 bytes (/Perl/lib/CORE/vmem.h)
CPerlHost::Free(void * 0x01ace64c) line 59 + 34 bytes (/Perl/lib/CORE/perlhost.h)
PerlMemFree(IPerlMem * 0x0026cf54, void * 0x01ace64c) line 302 (/Perl/lib/CORE/perlhost.h)
Perl_safesysfree(void * 0x01ace64c) line 151 + 26 bytes (/Perl_src/util.c)
Perl_sv_clear(interpreter * 0x0089c794, sv * 0x0142f1fc) line 5047 +
13 bytes (/Perl_src/sv.c)
Perl_sv_free(interpreter * 0x0089c794, sv * 0x0142f1fc) line 5190 + 13
bytes (/Perl_src/sv.c)
Perl_free_tmps(interpreter * 0x0089c794) line 181 + 13 bytes (/Perl_src/scope.c)
perl_destruct(interpreter * 0x0089c794) line 431 + 23 bytes (/Perl_src/perl.c)
modperl_perl_destruct(interpreter * 0x0089c794) line 130 + 9 bytes (/modperl-2.0/src/modules/perl/modperl_perl.c)
modperl_interp_destroy(modperl_interp_t * 0x008a2d50) line 128 + 12
bytes (/modperl-2.0/src/modules/perl/modperl_interp.c)
modperl_interp_pool_destroy(void * 0x00898b48) line 184 + 12 bytes (/modperl-2.0/src/modules/perl/modperl_interp.c)
run_cleanups(cleanup_t * * 0x0089a7a8) line 1980 (/httpd-2.0.45/srclib/apr/memory/unix/apr_pools.c)
apr_pool_destroy(apr_pool_t * 0x00401585) line 758 (/httpd-2.0.45/srclib/apr/memory/unix/apr_pools.c)
main(int 0x00401d82, const char * const * 0x00000008) line 619 (/httpd-2.0.45/server/main.c)
APACHE! mainCRTStartup + 227 bytes
KERNEL32!
=========================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sat, 12 Apr 2003, Stas Bekman wrote:
> [ .. ]
>
>>any reason, why the source file is not reported in the backtrace?
>
>
> mostly because i can't figure out how to include it
> automatically :)
You mean, there is no configuration option for that? It includes the line
number but not the file name? May be they have assumed that any app will have
a single .c file ;)
> Here's another, with the source files
> added in by hand :
Thanks!
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 12 Apr 2003, Stas Bekman wrote:
[ .. ]
> any reason, why the source file is not reported in the backtrace?
mostly because i can't figure out how to include it
automatically :) Here's another, with the source files
added in by hand :
=============================================================
VMem::Free(void * 0x013a9d84) line 208 + 3 bytes (/Perl/lib/CORE/vmem.h)
CPerlHost::Free(void * 0x013a9d84) line 59 + 34 bytes (/Perl/lib/CORE/perlhost.h)
PerlMemFree(IPerlMem * 0x01457794, void * 0x013a9d84) line 302 (/Perl/lib/CORE/perlhost.h)
Perl_safesysfree(void * 0x013a9d84) line 151 + 26 bytes (/Perl_src/util.c)
Perl_sv_unmagic(interpreter * 0x0089c794, sv * 0x008f66cc, int
0x00000063) line 4688 + 12 bytes (/Perl_src/sv.c)
Perl_Gv_AMupdate(interpreter * 0x0089c794, hv * 0x008f66cc) line 1300
+ 15 bytes (/Perl_src/gv.c)
Perl_sv_bless(interpreter * 0x0089c794, sv * 0x014560dc, hv *
0x008f66cc) line 7297 + 25 bytes (/Perl_src/sv.c)
Perl_newSVrv(interpreter * 0x0089c794, sv * 0x014560dc, const char *
0x00c16dfc `string') line 7151 + 17 bytes (/Perl_src/sv.c)
Perl_sv_setref_pv(interpreter * 0x0089c794, sv * 0x014560dc, const
char * 0x00c16dfc `string', void * 0x0006f50c) line 7182 + 21 bytes (/Perl_src/sv.c)
modperl_ptr2obj(interpreter * 0x0089c794, char * 0x00c16dfc `string',
void * 0x0006f50c) line 162 + 21 bytes (/modperl-2.0/src/modules/perl/modperl_util.c)
modperl_handler_make_args(interpreter * 0x0089c794, av * * 0x0006f468)
line 167 + 17 bytes (/modperl-2.0/src/modules/perl/modperl_handler.c)
modperl_cmd_perldo(cmd_parms_struct * 0x0006f50c, void * 0x00854810,
const char * 0x0089a258) line 415 + 33 bytes (/modperl-2.0/src/modules/perl/modperl_cmd.c)
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct *
0x00c11110, void * 0x0006f50c, const char * 0x00854810) line 713 + 14
bytes (/httpd-2.0.45/server/config.c)
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct
* 0x0089a198, ap_conf_vector_t * 0x0006f50c) line 1082 + 12 bytes (/httpd-2.0.45/server/config.c)
ap_walk_config(ap_directive_t * 0x00bf7124, cmd_parms_struct *
0x0089a198, ap_conf_vector_t * 0x0006f50c) line 1121 + 11 bytes (/httpd-2.0.45/server/config.c)
modperl_config_insert(interpreter * 0x01450dbc, server_rec *
0x0082c398, apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000, int
0x00000096, char * 0x00000000, ap_conf_vector_t * 0x0082c960, sv *
0x015ff194) line 433 + 18 bytes (/modperl-2.0/src/modules/perl/modperl_config.c)
modperl_config_insert_server(interpreter * 0x01450dbc, server_rec *
0x0082c398, sv * 0x015ff194) line 451 + 36 bytes (/modperl-2.0/src/modules/perl/modperl_config.c)
XS_Apache__Server_add_config(interpreter * 0x01450dbc, cv * 0x015dbba0) line 99 + 17 bytes
Perl_pp_entersub(interpreter * 0x01450dbc) line 2781 + 16 bytes (/Perl_src/pp_hot.c)
Perl_runops_debug(interpreter * 0x01450dbc) line 1400 + 13 bytes (/Perl_src/dump.c)
S_call_body(interpreter * 0x01450dbc, op * 0x0006f758, int 0x00000000)
line 2045 + 13 bytes (/Perl_src/perl.c)
Perl_call_sv(interpreter * 0x01450dbc, sv * 0x01464f64, long
0x00000006) line 1963 + 15 bytes (/Perl_src/sv.c)
S_call_list_body(interpreter * 0x01450dbc, cv * 0x01464f64) line 4081
+ 15 bytes (/Perl_src/sv.c)
Perl_call_list(interpreter * 0x01450dbc, long 0x00000005, av *
0x01464f40) line 4009 + 13 bytes (/Perl_src/sv.c)
Perl_newATTRSUB(interpreter * 0x01450dbc, long 0x00000124, op *
0x0146ccc4, op * 0x00000000, op * 0x00000000, op * 0x014ad92c) line
5143 + 26 bytes (/Perl_src/op.c)
Perl_yyparse(interpreter * 0x01450dbc) line 355 + 43 bytes
S_doeval(interpreter * 0x01450dbc, int 0x00000000, op * * 0x00000000)
line 2771 + 9 bytes (/Perl_src/pp_ctl.c)
Perl_pp_require(interpreter * 0x01450dbc) line 3254 + 72 bytes (/Perl_src/pp_ctl.c)
modperl_pp_require(interpreter * 0x01450dbc) line 54 + 10 bytes (/modperl-2.0/src/modules/perl/modperl_perl_pp.c)
Perl_runops_debug(interpreter * 0x01450dbc) line 1400 + 13 bytes (/Perl_src/dump.c)
S_call_body(interpreter * 0x01450dbc, op * 0x0006fc08, int 0x00000001)
line 2045 + 13 bytes (/Perl_src/perl.c)
Perl_eval_sv(interpreter * 0x01450dbc, sv * 0x01451d88, long
0x00000002) line 2105 + 15 bytes (/Perl_src/perl.c)
Perl_require_pv(interpreter * 0x01450dbc, const char * 0x00897d08)
line 2203 + 15 bytes (/Perl_src/perl.c)
modperl_require_file(interpreter * 0x01450dbc, const char *
0x00897d08, int 0x00000001) line 30 + 13 bytes (/modperl-2.0/src/modules/perl/modperl_util.c)
modperl_config_apply_PerlRequire(server_rec * 0x00896f50,
modperl_config_srv_t * 0x00897860, interpreter * 0x01450dbc,
apr_pool_t * 0x0026a838) line 347 + 21 bytes (/modperl-2.0/src/modules/perl/modperl_config.c)
modperl_startup(server_rec * 0x00896f50, apr_pool_t * 0x0026a838) line
217 + 21 bytes (/modperl-2.0/src/modules/perl/mod_perl.c)
modperl_init_vhost(server_rec * 0x00896f50, apr_pool_t * 0x0026a838,
server_rec * 0x0082c398) line 287 + 13 bytes (/modperl-2.0/src/modules/perl/mod_perl.c)
modperl_init(server_rec * 0x0082c398, apr_pool_t * 0x0026a838) line
376 + 17 bytes (/modperl-2.0/src/modules/perl/mod_perl.c)
modperl_hook_init(apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000, server_rec * 0x0082c398) line 499 + 13 bytes (/modperl-2.0/src/modules/perl/mod_perl.c)
modperl_run(apr_pool_t * 0x0026a838, server_rec * 0x0082c398) line 515
+ 17 bytes (/modperl-2.0/src/modules/perl/mod_perl.c)
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec0, void *
0x00854810, const char * 0x008613e0) line 491 + 13 bytes (/modperl-2.0/src/modules/perl/modperl_cmd.c)
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct *
0x00c111b8, void * 0x0006fec0, const char * 0x00854810) line 713 + 14
bytes (/httpd-2.0.45/server/config.c)
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct
* 0x008613c0, ap_conf_vector_t * 0x0006fec0) line 1082 + 12 bytes (/httpd-2.0.45/server/config.c)
ap_walk_config(ap_directive_t * 0x6ff032e3, cmd_parms_struct *
0x00854ae0, ap_conf_vector_t * 0x0006fec0) line 1121 + 11 bytes (/httpd-2.0.45/server/config.c)
ap_process_config_tree(server_rec * 0x0082c398, ap_directive_t *
0x00854ae0, apr_pool_t * 0x0026a838, apr_pool_t * 0x0084c110) line
1594 + 35 bytes (/httpd-2.0.45/server/config.c)
main(int 0x00401d82, const char * const * 0x00000008) line 582 (/httpd-2.0.45/server/main.c)
APACHE! mainCRTStartup + 227 bytes
KERNEL32! 77e7eb69()
==========================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 9 Apr 2003, Stas Bekman wrote:
> [ .. ]
>
>>BTW, the problem is reported by perl:
>>
>>/home/stas/perl.org/perl-current> grep -Inr 'wrong pool' .
>>./win32/vmem.h:207: Perl_warn(aTHX_ "Free to wrong pool %p not
>>%p",this,ptr->owner);
>
>
> That's exactly where it crashes ...
Hmm, here is a wild guess. Could it be that this change has caused the trouble?
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/t/conf/modperl_extra.pl.diff?r1=1.24&r2=1.25&diff_format=h
>>but it's a warning, not a fatal error. Though it indicates that something is
>>wrong. Were you able to get a complete backtrace, the last time you've sent it
>>in, it was incomplete (perl wasn't build with debugging enabled).
>
>
> This is below - I'll work on the next day or two in getting the
> date of the last successful compile ....
any reason, why the source file is not reported in the backtrace?
> =====================================================================
> VMem::Free(void * 0x013a9d84) line 208 + 3 bytes
> CPerlHost::Free(void * 0x013a9d84) line 59 + 34 bytes
> PerlMemFree(IPerlMem * 0x01457794, void * 0x013a9d84) line 302
> Perl_safesysfree(void * 0x013a9d84) line 151 + 26 bytes
> Perl_sv_unmagic(interpreter * 0x0089c794, sv * 0x008f66cc, int 0x00000063) line 4688 + 12 bytes
> Perl_Gv_AMupdate(interpreter * 0x0089c794, hv * 0x008f66cc) line 1300 + 15 bytes
> Perl_sv_bless(interpreter * 0x0089c794, sv * 0x014560dc, hv * 0x008f66cc) line 7297 + 25 bytes
> Perl_newSVrv(interpreter * 0x0089c794, sv * 0x014560dc, const char * 0x00c16dfc `string') line 7151 + 17 bytes
> Perl_sv_setref_pv(interpreter * 0x0089c794, sv * 0x014560dc, const char * 0x00c16dfc `string', void * 0x0006f50c) line 7182 + 21 bytes
> modperl_ptr2obj(interpreter * 0x0089c794, char * 0x00c16dfc `string', void * 0x0006f50c) line 162 + 21 bytes
> modperl_handler_make_args(interpreter * 0x0089c794, av * * 0x0006f468) line 167 + 17 bytes
> modperl_cmd_perldo(cmd_parms_struct * 0x0006f50c, void * 0x00854810, const char * 0x0089a258) line 415 + 33 bytes
> invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x00c11110, void * 0x0006f50c, const char * 0x00854810) line 713 + 14 bytes
> ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x0089a198, ap_conf_vector_t * 0x0006f50c) line 1082 + 12 bytes
> ap_walk_config(ap_directive_t * 0x00bf7124, cmd_parms_struct * 0x0089a198, ap_conf_vector_t * 0x0006f50c) line 1121 + 11 bytes
> modperl_config_insert(interpreter * 0x01450dbc, server_rec * 0x0082c398, apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000, int 0x00000096, char * 0x00000000, ap_conf_vector_t * 0x0082c960, sv * 0x015ff194) line 433 + 18 bytes
> modperl_config_insert_server(interpreter * 0x01450dbc, server_rec * 0x0082c398, sv * 0x015ff194) line 451 + 36 bytes
> XS_Apache__Server_add_config(interpreter * 0x01450dbc, cv * 0x015dbba0) line 99 + 17 bytes
> Perl_pp_entersub(interpreter * 0x01450dbc) line 2781 + 16 bytes
> Perl_runops_debug(interpreter * 0x01450dbc) line 1400 + 13 bytes
> S_call_body(interpreter * 0x01450dbc, op * 0x0006f758, int 0x00000000) line 2045 + 13 bytes
> Perl_call_sv(interpreter * 0x01450dbc, sv * 0x01464f64, long 0x00000006) line 1963 + 15 bytes
> S_call_list_body(interpreter * 0x01450dbc, cv * 0x01464f64) line 4081 + 15 bytes
> Perl_call_list(interpreter * 0x01450dbc, long 0x00000005, av * 0x01464f40) line 4009 + 13 bytes
> Perl_newATTRSUB(interpreter * 0x01450dbc, long 0x00000124, op * 0x0146ccc4, op * 0x00000000, op * 0x00000000, op * 0x014ad92c) line 5143 + 26 bytes
> Perl_yyparse(interpreter * 0x01450dbc) line 355 + 43 bytes
> S_doeval(interpreter * 0x01450dbc, int 0x00000000, op * * 0x00000000) line 2771 + 9 bytes
> Perl_pp_require(interpreter * 0x01450dbc) line 3254 + 72 bytes
> modperl_pp_require(interpreter * 0x01450dbc) line 54 + 10 bytes
> Perl_runops_debug(interpreter * 0x01450dbc) line 1400 + 13 bytes
> S_call_body(interpreter * 0x01450dbc, op * 0x0006fc08, int 0x00000001) line 2045 + 13 bytes
> Perl_eval_sv(interpreter * 0x01450dbc, sv * 0x01451d88, long 0x00000002) line 2105 + 15 bytes
> Perl_require_pv(interpreter * 0x01450dbc, const char * 0x00897d08) line 2203 + 15 bytes
> modperl_require_file(interpreter * 0x01450dbc, const char * 0x00897d08, int 0x00000001) line 30 + 13 bytes
> modperl_config_apply_PerlRequire(server_rec * 0x00896f50, modperl_config_srv_t * 0x00897860, interpreter * 0x01450dbc, apr_pool_t * 0x0026a838) line 347 + 21 bytes
> modperl_startup(server_rec * 0x00896f50, apr_pool_t * 0x0026a838) line 217 + 21 bytes
> modperl_init_vhost(server_rec * 0x00896f50, apr_pool_t * 0x0026a838, server_rec * 0x0082c398) line 287 + 13 bytes
> modperl_init(server_rec * 0x0082c398, apr_pool_t * 0x0026a838) line 376 + 17 bytes
> modperl_hook_init(apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, server_rec * 0x0082c398) line 499 + 13 bytes
> modperl_run(apr_pool_t * 0x0026a838, server_rec * 0x0082c398) line 515 + 17 bytes
> modperl_cmd_load_module(cmd_parms_struct * 0x0006fec0, void * 0x00854810, const char * 0x008613e0) line 491 + 13 bytes
> invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x00c111b8, void * 0x0006fec0, const char * 0x00854810) line 713 + 14 bytes
> ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x008613c0, ap_conf_vector_t * 0x0006fec0) line 1082 + 12 bytes
> ap_walk_config(ap_directive_t * 0x6ff032e3, cmd_parms_struct * 0x00854ae0, ap_conf_vector_t * 0x0006fec0) line 1121 + 11 bytes
> ap_process_config_tree(server_rec * 0x0082c398, ap_directive_t * 0x00854ae0, apr_pool_t * 0x0026a838, apr_pool_t * 0x0084c110) line 1594 + 35 bytes
> main(int 0x00401d82, const char * const * 0x00000008) line 582
> APACHE! mainCRTStartup + 227 bytes
> KERNEL32! 77e7eb69()
>
> ============================================================================
>
--
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 9 Apr 2003, Stas Bekman wrote:
[ .. ]
> BTW, the problem is reported by perl:
>
> /home/stas/perl.org/perl-current> grep -Inr 'wrong pool' .
> ./win32/vmem.h:207: Perl_warn(aTHX_ "Free to wrong pool %p not
> %p",this,ptr->owner);
That's exactly where it crashes ...
> but it's a warning, not a fatal error. Though it indicates that something is
> wrong. Were you able to get a complete backtrace, the last time you've sent it
> in, it was incomplete (perl wasn't build with debugging enabled).
This is below - I'll work on the next day or two in getting the
date of the last successful compile ....
=====================================================================
VMem::Free(void * 0x013a9d84) line 208 + 3 bytes
CPerlHost::Free(void * 0x013a9d84) line 59 + 34 bytes
PerlMemFree(IPerlMem * 0x01457794, void * 0x013a9d84) line 302
Perl_safesysfree(void * 0x013a9d84) line 151 + 26 bytes
Perl_sv_unmagic(interpreter * 0x0089c794, sv * 0x008f66cc, int 0x00000063) line 4688 + 12 bytes
Perl_Gv_AMupdate(interpreter * 0x0089c794, hv * 0x008f66cc) line 1300 + 15 bytes
Perl_sv_bless(interpreter * 0x0089c794, sv * 0x014560dc, hv * 0x008f66cc) line 7297 + 25 bytes
Perl_newSVrv(interpreter * 0x0089c794, sv * 0x014560dc, const char * 0x00c16dfc `string') line 7151 + 17 bytes
Perl_sv_setref_pv(interpreter * 0x0089c794, sv * 0x014560dc, const char * 0x00c16dfc `string', void * 0x0006f50c) line 7182 + 21 bytes
modperl_ptr2obj(interpreter * 0x0089c794, char * 0x00c16dfc `string', void * 0x0006f50c) line 162 + 21 bytes
modperl_handler_make_args(interpreter * 0x0089c794, av * * 0x0006f468) line 167 + 17 bytes
modperl_cmd_perldo(cmd_parms_struct * 0x0006f50c, void * 0x00854810, const char * 0x0089a258) line 415 + 33 bytes
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x00c11110, void * 0x0006f50c, const char * 0x00854810) line 713 + 14 bytes
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x0089a198, ap_conf_vector_t * 0x0006f50c) line 1082 + 12 bytes
ap_walk_config(ap_directive_t * 0x00bf7124, cmd_parms_struct * 0x0089a198, ap_conf_vector_t * 0x0006f50c) line 1121 + 11 bytes
modperl_config_insert(interpreter * 0x01450dbc, server_rec * 0x0082c398, apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000, int 0x00000096, char * 0x00000000, ap_conf_vector_t * 0x0082c960, sv * 0x015ff194) line 433 + 18 bytes
modperl_config_insert_server(interpreter * 0x01450dbc, server_rec * 0x0082c398, sv * 0x015ff194) line 451 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x01450dbc, cv * 0x015dbba0) line 99 + 17 bytes
Perl_pp_entersub(interpreter * 0x01450dbc) line 2781 + 16 bytes
Perl_runops_debug(interpreter * 0x01450dbc) line 1400 + 13 bytes
S_call_body(interpreter * 0x01450dbc, op * 0x0006f758, int 0x00000000) line 2045 + 13 bytes
Perl_call_sv(interpreter * 0x01450dbc, sv * 0x01464f64, long 0x00000006) line 1963 + 15 bytes
S_call_list_body(interpreter * 0x01450dbc, cv * 0x01464f64) line 4081 + 15 bytes
Perl_call_list(interpreter * 0x01450dbc, long 0x00000005, av * 0x01464f40) line 4009 + 13 bytes
Perl_newATTRSUB(interpreter * 0x01450dbc, long 0x00000124, op * 0x0146ccc4, op * 0x00000000, op * 0x00000000, op * 0x014ad92c) line 5143 + 26 bytes
Perl_yyparse(interpreter * 0x01450dbc) line 355 + 43 bytes
S_doeval(interpreter * 0x01450dbc, int 0x00000000, op * * 0x00000000) line 2771 + 9 bytes
Perl_pp_require(interpreter * 0x01450dbc) line 3254 + 72 bytes
modperl_pp_require(interpreter * 0x01450dbc) line 54 + 10 bytes
Perl_runops_debug(interpreter * 0x01450dbc) line 1400 + 13 bytes
S_call_body(interpreter * 0x01450dbc, op * 0x0006fc08, int 0x00000001) line 2045 + 13 bytes
Perl_eval_sv(interpreter * 0x01450dbc, sv * 0x01451d88, long 0x00000002) line 2105 + 15 bytes
Perl_require_pv(interpreter * 0x01450dbc, const char * 0x00897d08) line 2203 + 15 bytes
modperl_require_file(interpreter * 0x01450dbc, const char * 0x00897d08, int 0x00000001) line 30 + 13 bytes
modperl_config_apply_PerlRequire(server_rec * 0x00896f50, modperl_config_srv_t * 0x00897860, interpreter * 0x01450dbc, apr_pool_t * 0x0026a838) line 347 + 21 bytes
modperl_startup(server_rec * 0x00896f50, apr_pool_t * 0x0026a838) line 217 + 21 bytes
modperl_init_vhost(server_rec * 0x00896f50, apr_pool_t * 0x0026a838, server_rec * 0x0082c398) line 287 + 13 bytes
modperl_init(server_rec * 0x0082c398, apr_pool_t * 0x0026a838) line 376 + 17 bytes
modperl_hook_init(apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, server_rec * 0x0082c398) line 499 + 13 bytes
modperl_run(apr_pool_t * 0x0026a838, server_rec * 0x0082c398) line 515 + 17 bytes
modperl_cmd_load_module(cmd_parms_struct * 0x0006fec0, void * 0x00854810, const char * 0x008613e0) line 491 + 13 bytes
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x00c111b8, void * 0x0006fec0, const char * 0x00854810) line 713 + 14 bytes
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x008613c0, ap_conf_vector_t * 0x0006fec0) line 1082 + 12 bytes
ap_walk_config(ap_directive_t * 0x6ff032e3, cmd_parms_struct * 0x00854ae0, ap_conf_vector_t * 0x0006fec0) line 1121 + 11 bytes
ap_process_config_tree(server_rec * 0x0082c398, ap_directive_t * 0x00854ae0, apr_pool_t * 0x0026a838, apr_pool_t * 0x0084c110) line 1594 + 35 bytes
main(int 0x00401d82, const char * const * 0x00000008) line 582
APACHE! mainCRTStartup + 227 bytes
KERNEL32! 77e7eb69()
============================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 9 Apr 2003, Stas Bekman wrote:
[ .. ]
> So if you checkout like this:
>
> cvs co -d old_mp2 -D "March 23, 2003 00:01" modperl-2.0
>
> it should build and pass all tests, right?
That's right - there was one failed subtest in ModPerl-Registry,
but I remember that was fixed shortly afterwards (so March
23 wasn't the absolute latest at which things were OK).
> Then move onto some date later till it breaks, so you narrow
> down what change broke things. Now do a recursive diff between
> the two checkouts and we will know what caused the problem.
I'll do that in the next few days - fortunately it's relatively
recent, so shouldn't be too hard ... Thanks for the pointer
on using cvs to co something by date.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 9 Apr 2003, Stas Bekman wrote:
> [ ... ]
>
>>Hmm, interesting. I was sure that it was the earlier execution of
>>modperl_interp_init that was the cause of the problem.
>>
>>So the problem must have been introduced by some earlier
>>change. Can you try an even earlier versions of it?
>>http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/mod_perl.c
>>1.158? When was the last time you have had no problems with?
>>Can you 'cvs co' using that date and then diff what has
>>changed? If I could reproduce the problem it'd be easier to
>>know where to look.
>
>
> I'm not sure if this is the absolute latest version, but that of
> March 23 worked. I tried replacing src/modules/perl/mod_perl.c of
> the current cvs version with that of March 23, but without
> success. I then also tried reverting to the March 23 versions of
> modperl_cmd.c and modperl_config.c (which were involved in the
> trace I sent earlier), but this also failed (although at a
> different place). Finally, I tried one version of mod_perl.c up
> from March 23 (with everything else current) - it didn't crash,
> but the server failed to start.
So if you checkout like this:
cvs co -d old_mp2 -D "March 23, 2003 00:01" modperl-2.0
it should build and pass all tests, right?
Then move onto some date later till it breaks, so you narrow down what change
broke things. Now do a recursive diff between the two checkouts and we will
know what caused the problem.
This could be made into a simple script, which tries several checkouts till it
breaks, perhaps using a binary search to narrow things down faster.
Andreas Koenig uses this approach to find the changes that broke perl and I
think he has a special code to do that, but it works with perforce, so I'm not
sure how much use this may have.
>>BTW, the problem is reported by perl:
>>
>>/home/stas/perl.org/perl-current> grep -Inr 'wrong pool' .
>>./win32/vmem.h:207: Perl_warn(aTHX_ "Free to wrong pool %p not
>>%p",this,ptr->owner);
>>
>>but it's a warning, not a fatal error. Though it indicates that
>>something is wrong. Were you able to get a complete backtrace,
>>the last time you've sent it in, it was incomplete (perl wasn't
>>build with debugging enabled).
>
>
> I'll do that, hopefully this weekend ...
Cool.
Once this issue is resolved we should try to push for a _09 release.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 9 Apr 2003, Stas Bekman wrote:
[ ... ]
>
> Hmm, interesting. I was sure that it was the earlier execution of
> modperl_interp_init that was the cause of the problem.
>
> So the problem must have been introduced by some earlier
> change. Can you try an even earlier versions of it?
> http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/mod_perl.c
> 1.158? When was the last time you have had no problems with?
> Can you 'cvs co' using that date and then diff what has
> changed? If I could reproduce the problem it'd be easier to
> know where to look.
I'm not sure if this is the absolute latest version, but that of
March 23 worked. I tried replacing src/modules/perl/mod_perl.c of
the current cvs version with that of March 23, but without
success. I then also tried reverting to the March 23 versions of
modperl_cmd.c and modperl_config.c (which were involved in the
trace I sent earlier), but this also failed (although at a
different place). Finally, I tried one version of mod_perl.c up
from March 23 (with everything else current) - it didn't crash,
but the server failed to start.
> BTW, the problem is reported by perl:
>
> /home/stas/perl.org/perl-current> grep -Inr 'wrong pool' .
> ./win32/vmem.h:207: Perl_warn(aTHX_ "Free to wrong pool %p not
> %p",this,ptr->owner);
>
> but it's a warning, not a fatal error. Though it indicates that
> something is wrong. Were you able to get a complete backtrace,
> the last time you've sent it in, it was incomplete (perl wasn't
> build with debugging enabled).
I'll do that, hopefully this weekend ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 7 Apr 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>>[...]
>>
>>>Thanks ... I tried it (after adding the assignment
>>> const char *vhost = modperl_server_desc(s, p);
>>>before the MP_TRACE_i call), but got the same problems
>>>as before, with a free to a wrong pool, occurring
>>>I think at about sv_setref_pv(sv, classname, ptr) within
>>>modperl_ptr2obj() in src/modules/modperl_util.c.
>>
>>Randy, can you please give one more try to the current cvs. I believe this
>>should work now.
>
>
> Hi Stas,
> Thanks very much for looking into thus, but unfortunately, the
> same error results at the same place ... I tried reverting to
> a previous mod_perl.c (back to 1.160), but the same error
> arises ...
Hmm, interesting. I was sure that it was the earlier execution of
modperl_interp_init that was the cause of the problem.
So the problem must have been introduced by some earlier change. Can you try
an even earlier versions of it?
http://cvs.apache.org/viewcvs.cgi/modperl-2.0/src/modules/perl/mod_perl.c
1.158? When was the last time you have had no problems with? Can you 'cvs co'
using that date and then diff what has changed? If I could reproduce the
problem it'd be easier to know where to look.
BTW, the problem is reported by perl:
/home/stas/perl.org/perl-current> grep -Inr 'wrong pool' .
./win32/vmem.h:207: Perl_warn(aTHX_ "Free to wrong pool %p not
%p",this,ptr->owner);
but it's a warning, not a fatal error. Though it indicates that something is
wrong. Were you able to get a complete backtrace, the last time you've sent it
in, it was incomplete (perl wasn't build with debugging enabled).
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 7 Apr 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> [...]
> > Thanks ... I tried it (after adding the assignment
> > const char *vhost = modperl_server_desc(s, p);
> > before the MP_TRACE_i call), but got the same problems
> > as before, with a free to a wrong pool, occurring
> > I think at about sv_setref_pv(sv, classname, ptr) within
> > modperl_ptr2obj() in src/modules/modperl_util.c.
>
> Randy, can you please give one more try to the current cvs. I believe this
> should work now.
Hi Stas,
Thanks very much for looking into thus, but unfortunately, the
same error results at the same place ... I tried reverting to
a previous mod_perl.c (back to 1.160), but the same error
arises ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> Thanks ... I tried it (after adding the assignment
> const char *vhost = modperl_server_desc(s, p);
> before the MP_TRACE_i call), but got the same problems
> as before, with a free to a wrong pool, occurring
> I think at about sv_setref_pv(sv, classname, ptr) within
> modperl_ptr2obj() in src/modules/modperl_util.c.
Randy, can you please give one more try to the current cvs. I believe this
should work now.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 4 Apr 2003, Stas Bekman wrote:
> Hmm, I still think that my mips init move wasn't complete.
> Please try this patch first:
>
> Index: src/modules/perl/mod_perl.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
> retrieving revision 1.163
> diff -u -r1.163 mod_perl.c
> --- src/modules/perl/mod_perl.c 3 Apr 2003 06:23:52 -0000 1.163
> +++ src/modules/perl/mod_perl.c 4 Apr 2003 06:10:17 -0000
> @@ -200,6 +200,20 @@
> if (MpSrvPARENT(scfg)) {
> MpInterpBASE_On(scfg->mip->parent);
> }
> +
> + if (!scfg->mip) {
> + /* since mips are created after merge_server_configs()
> + * need to point to the base mip here if this vhost
> + * doesn't have its own
> + */
> + server_rec *base_server = modperl_global_get_server_rec();
> + modperl_config_srv_t *base_scfg =
> + modperl_config_srv_get(base_server);
> + MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n",
> + vhost, modperl_server_desc(base_server, p));
> + scfg->mip = base_scfg->mip;
> + }
> +
> }
> else {
> /* base server */
> @@ -305,18 +319,6 @@
> return HTTP_INTERNAL_SERVER_ERROR;
> }
> }
> -
> -#ifdef USE_ITHREADS
> - if (!scfg->mip) {
> - /* since mips are created after merge_server_configs()
> - * need to point to the base mip here if this vhost
> - * doesn't have its own
> - */
> - MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n",
> - vhost, modperl_server_desc(base_server, p));
> - scfg->mip = base_scfg->mip;
> - }
> -#endif /* USE_ITHREADS */
>
> return OK;
> }
Thanks ... I tried it (after adding the assignment
const char *vhost = modperl_server_desc(s, p);
before the MP_TRACE_i call), but got the same problems
as before, with a free to a wrong pool, occurring
I think at about sv_setref_pv(sv, classname, ptr) within
modperl_ptr2obj() in src/modules/modperl_util.c.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Mon, 31 Mar 2003, Stas Bekman wrote:
>
>
>>Randy Kobes wrote:
>
>
>>>- secondly, there's a problem in starting the tests, with a free
>>>to a wrong pool and then an access violation in the perl58 lib.
>>
>>I've just built the worker on linux, but haven't seen any problems.
>>
>>I think the only change in that area was a move of mips
>>intialization to an earlier stage, before any modules or files
>>are required.
Hmm, I still think that my mips init move wasn't complete. Please try this
patch first:
Index: src/modules/perl/mod_perl.c
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.163
diff -u -r1.163 mod_perl.c
--- src/modules/perl/mod_perl.c 3 Apr 2003 06:23:52 -0000 1.163
+++ src/modules/perl/mod_perl.c 4 Apr 2003 06:10:17 -0000
@@ -200,6 +200,20 @@
if (MpSrvPARENT(scfg)) {
MpInterpBASE_On(scfg->mip->parent);
}
+
+ if (!scfg->mip) {
+ /* since mips are created after merge_server_configs()
+ * need to point to the base mip here if this vhost
+ * doesn't have its own
+ */
+ server_rec *base_server = modperl_global_get_server_rec();
+ modperl_config_srv_t *base_scfg =
+ modperl_config_srv_get(base_server);
+ MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n",
+ vhost, modperl_server_desc(base_server, p));
+ scfg->mip = base_scfg->mip;
+ }
+
}
else {
/* base server */
@@ -305,18 +319,6 @@
return HTTP_INTERNAL_SERVER_ERROR;
}
}
-
-#ifdef USE_ITHREADS
- if (!scfg->mip) {
- /* since mips are created after merge_server_configs()
- * need to point to the base mip here if this vhost
- * doesn't have its own
- */
- MP_TRACE_i(MP_FUNC, "%s mip inherited from %s\n",
- vhost, modperl_server_desc(base_server, p));
- scfg->mip = base_scfg->mip;
- }
-#endif /* USE_ITHREADS */
return OK;
}
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 31 Mar 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > - secondly, there's a problem in starting the tests, with a free
> > to a wrong pool and then an access violation in the perl58 lib.
>
> I've just built the worker on linux, but haven't seen any problems.
>
> I think the only change in that area was a move of mips
> intialization to an earlier stage, before any modules or files
> are required.
Below is a trace from building with MP_DEBUG on - I haven't
yet built a debug Perl, but before doing that, I'm wondering
if this is enough to point to the problem:
================================================================
PERL58! 28083437()
PERL58! 2800d128()
PERL58! 28066d46()
PERL58! 28066b87()
PERL58! 28066bd8()
modperl_ptr2obj(interpreter * 0x0089a78c, char * 0x00c15d50 `string', void * 0x0006f7ec) line 162 + 21 bytes
modperl_handler_make_args(interpreter * 0x0089a78c, av * * 0x0006f748) line 167 + 17 bytes
modperl_cmd_perldo(cmd_parms_struct * 0x0006f7ec, void * 0x00854810, const char * 0x013b7548) line 394 + 33 bytes
invoke_cmd(const command_struct * 0x6ff02358, cmd_parms_struct * 0x00c10110, void * 0x0006f7ec, const char * 0x00854810) line 713 + 14 bytes
ap_walk_config_sub(const ap_directive_t * 0x6ff022d5, cmd_parms_struct * 0x013b7488, ap_conf_vector_t * 0x0006f7ec) line 1082 + 12 bytes
ap_walk_config(ap_directive_t * 0x00bf7014, cmd_parms_struct * 0x013b7488, ap_conf_vector_t * 0x0006f7ec) line 1121 + 11 bytes
modperl_config_insert(interpreter * 0x0143854c, server_rec * 0x0082c398, apr_pool_t * 0x0026a838, apr_pool_t * 0x00000000, int 150, char * 0x00000000, ap_conf_vector_t * 0x0082c960, sv * 0x015ebe34) line 433 + 18 bytes
modperl_config_insert_server(interpreter * 0x0143854c, server_rec * 0x0082c398, sv * 0x015ebe34) line 451 + 36 bytes
XS_Apache__Server_add_config(interpreter * 0x0143854c, cv * 0x015d4624) line 99 + 17 bytes
PERL58! 2803f717()
PERL58! 2805d726()
PERL58! 28026f94()
PERL58! 2801e5df()
PERL58! 2802889a()
======================================================================
modperl_handler_make_args(interpreter *, av **) in
modperl_handler.c calls
sv = modperl_ptr2obj(aTHX_ classname, ptr);
with the values:
+ classname 0x00c15d50 "Apache::CmdParms"
ptr 0x0006f7ec
+ sv 0x013c0aec
========================================================================
while modperl_ptr2obj(pTHX_ char *classname, void *ptr) in
modperl_util.c calls
sv_setref_pv(sv, classname, ptr);
with values
+ classname 0x00c15d50 "Apache::CmdParms"
ptr 0x0006f7ec
+ sv 0x0143e514
======================================================================
That last call to sv_setref_pv(sv, classname, ptr) seems
to be where things stop - the last message from enabling
PerlTrace All in httpd.conf is
sv_setref_pv(Apache::CmdParms, something)
which I think is coming from the call to
MP_TRACE_h(MP_FUNC, "sv_setref_pv(....)", ....);
within modperl_ptr2obj(...) of modperl_util.c.
After that, there's a message about a free to a wrong pool.
I don't really understand the details of all this, but
might a problem be that, in the call
sv = modperl_ptr2obj(aTHX_ classname, ptr);
in modperl_handler_make_args(...) in modperl_handler.c, the
value of "sv" (0x013c0aec) isn't the same as that
(0x0143e514) found in modperl_ptr2obj(...) in
modperl_util.c? In any event, is there anything I could
do to try to track this down? If this isn't enough, would
building against a debug Perl help? Thanks.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Win32 problems
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> There's a couple of problems with the current cvs mod_perl 2
> on Win32 with Perl-5.8 (ActiveState 805 compatible) ... I need
> to rebuild a debug Perl/Apache2, but in the meantime, here's
> a description, in case it rings a bell ...
>
> - First off, in xs/modperl.def, an entry for MP_debug_level
> appears, which the linker can't find when building mod_perl.so.
> For Win32, src/modules/perl/modperl_log.h sets MP_debug_level
> to modperl_debug_level(), which is in xs/modperl.def. This diff:
Ah, I guess since I've used berok on aix this didn't trigger the problem. I've
applied a similar fix adding this symbol only when MP_DEBUG=1. Does this work
on windows?
> ===========================================================================
> skips adding MP_debug_level to xs/modperl.def for Win32.
>
> - secondly, there's a problem in starting the tests, with a free
> to a wrong pool and then an access violation in the perl58 lib.
> No error log is created, but I've attached a trace from enabling
> PerlTrace All in httpd.conf. This problem arose in the last week
> or so - I'll look into this later when I get a chance to rebuild
> Perl/Apache with debugging enabled.
I've just built the worker on linux, but haven't seen any problems.
I think the only change in that area was a move of mips intialization to an
earlier stage, before any modules or files are required.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
[mp2] Win32 problems
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
There's a couple of problems with the current cvs mod_perl 2
on Win32 with Perl-5.8 (ActiveState 805 compatible) ... I need
to rebuild a debug Perl/Apache2, but in the meantime, here's
a description, in case it rings a bell ...
- First off, in xs/modperl.def, an entry for MP_debug_level
appears, which the linker can't find when building mod_perl.so.
For Win32, src/modules/perl/modperl_log.h sets MP_debug_level
to modperl_debug_level(), which is in xs/modperl.def. This diff:
==============================================================
Index: lib/ModPerl/WrapXS.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/WrapXS.pm,v
retrieving revision 1.54
diff -u -r1.54 WrapXS.pm
--- lib/ModPerl/WrapXS.pm 24 Mar 2003 04:38:19 -0000 1.54
+++ lib/ModPerl/WrapXS.pm 29 Mar 2003 17:50:31 -0000
@@ -13,13 +13,15 @@
use Cwd qw(fastcwd);
use Data::Dumper;
use File::Spec::Functions qw(catfile catdir);
+use Apache::TestConfig;
our $VERSION = '0.01';
my(@xs_includes) = ('mod_perl.h',
map "modperl_xs_$_.h", qw(sv_convert util typedefs));
-my @global_structs = qw(perl_module MP_debug_level);
+my @global_structs = qw(perl_module);
+push @global_structs, qw(MP_debug_level) unless Apache::TestConfig::WIN32;
sub new {
my $class = shift;
===========================================================================
skips adding MP_debug_level to xs/modperl.def for Win32.
- secondly, there's a problem in starting the tests, with a free
to a wrong pool and then an access violation in the perl58 lib.
No error log is created, but I've attached a trace from enabling
PerlTrace All in httpd.conf. This problem arose in the last week
or so - I'll look into this later when I get a chance to rebuild
Perl/Apache with debugging enabled.
--
best regards,
randy