You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2003/09/14 16:31:06 UTC
[mp2] filter tests on Win32
With the current cvs mod_perl 2 on Win32, I'm having a
problem running the filter tests from 'nmake test':
the following occurs in subtest 3 (I think) of
t/filter/both_str_con_add:
======================================================
modperl_run_filter(modperl_filter_t * 0x014bbd30) line 376 + 9 bytes
: src/modules/perl/modperl_filter.c
modperl_output_filter_handler(ap_filter_t * 0x014bc448,
apr_bucket_brigade * 0x014bc520) line 765 + 9 bytes
: src/modules/perl/modperl_filter.c
ap_pass_brigade(ap_filter_t * 0x014bc448,
apr_bucket_brigade * 0x014bc520) line 550 + 7 bytes
XS_Apache__Filter_pass_brigade(interpreter * 0x013eb3d4, cv * 0x01025f48)
line 180 + 14 bytes
: WrapXS/Apache/Filter/Filter.c
PERL58! 2803f772()
PERL58! 2805d77f()
modperl_callback(interpreter * 0x013eb3d4,
modperl_handler_t * 0x00898918, apr_pool_t * 0x014bbd30,
request_rec * 0x00000000, server_rec * 0x00895aa0, av * 0x034f802c)
line 53 + 17 bytes
: src/modules/perl/modperl_callback.c
modperl_callback_run_handlers(int 0x00000000,
int 0x00000001, request_rec * 0x00000000, conn_rec * 0x014bbe30,
server_rec * 0x00895aa0, apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 0x00000001)
line 188 + 35 bytes
: src/modules/perl/modperl_callback.c
modperl_callback_connection(int 0x00000000,
conn_rec * 0x014bbe30, int 0x00000001) line 279 + 34 bytes
: src/modules/perl/modperl_callback.c
modperl_process_connection_handler(conn_rec * 0x014bbe30) line 17 + 13 bytes
: src/modules/perl/modperl_hooks.c
ap_run_process_connection(conn_rec * 0x014bbe30) line 85 + 31 bytes
ap_process_connection(conn_rec * 0x014bbe30, void * 0x014bbd68)
line 211 + 6 bytes
worker_main(long 0x77c37fb8) line 731
MSVCRT! 77c37fb8()
08cf0016()
================================================================
However, if I install things, and run the tests as
perl t/TEST -verbose t/filter
they're all fine (save for a failure of
t/filter/in_str_consume.t, where it receives nothing, but
this also occurred before). Does this trigger something?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 14 Sep 2003, Randy Kobes wrote:
> With the current cvs mod_perl 2 on Win32, I'm having a
> problem running the filter tests from 'nmake test':
[ ... ]
Sorry, I forgot - this is with Win32 ActivePerl 806,
based on perl-5.8.0, and Apache/2.0.47.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Tue, 16 Sep 2003, Steve Hay wrote:
>
>[ .. ]
>
>
>>I tried running "perl t/SMOKE" but I just get this:
>>
>>=====
>>C:\Temp\modperl-2.0>perl t/SMOKE
>>*** Using random number seed: 1012582729 (autogenerated)
>>***
>>------------------------------------------------------------
>>*** [001-00-00] trying all tests 10 times
>>!!! failed to start server
>> '.' is not recognized as an internal or external command,
>>operable program or batch file.
>>=====
>>
>>What's that all about, then?
>>
>>
>
>I'll make up a proper patch for this later, but in
>Apache::TestSmoke, there's a line setting "./TEST".
>Try changing this to "$^X /path/to/modperl-2.0/t/TEST".
>However, when I tried running this it *seemed* to hang;
>but I may have just been too impatient, or tired ...
>
No, mine hangs as well :-(
It kicks off an Apache.exe now - that uses some CPU for a second or two
and then it all goes very quiet. CPU drops to 0% and Apache.exe just
sits there looking stupid.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 16 Sep 2003, Steve Hay wrote:
[ .. ]
> I tried running "perl t/SMOKE" but I just get this:
>
> =====
> C:\Temp\modperl-2.0>perl t/SMOKE
> *** Using random number seed: 1012582729 (autogenerated)
> ***
> ------------------------------------------------------------
> *** [001-00-00] trying all tests 10 times
> !!! failed to start server
> '.' is not recognized as an internal or external command,
> operable program or batch file.
> =====
>
> What's that all about, then?
I'll make up a proper patch for this later, but in
Apache::TestSmoke, there's a line setting "./TEST".
Try changing this to "$^X /path/to/modperl-2.0/t/TEST".
However, when I tried running this it *seemed* to hang;
but I may have just been too impatient, or tired ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 16 Sep 2003, Steve Hay wrote:
> Now that I've got ap2+mp2 running with perl-5.8.1, I get the same result
> as Randy running the test suite: It gets as far as:
>
> filter\both_str_con_add........ok 2/4
>
> and then crashes.
>
> Then line it crashed at was this:
>
> modperl_handler_t *handler =
> ((modperl_filter_ctx_t *)filter->f->ctx)->handler;
>
> and I notice that "filter->f->ctx" has the value 0x00000000 at this
> point, hence the access violation -- you can't access the "handler"
> member of a struct pointed to by "filter->f->ctx" when that pointer is NULL.
>
> Don't know if that helps anyone at all.
It helps me, knowing someone else finds this :)
I also found that, within this, the request_rec *r and
conn_rec *c were also apparently NULL.
--
best regards,
randy kobes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Large files conflict on Win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Good catch, Steve. I guess I have missed that because on linux Apache
>> always builds without LARGE_FILES and there is no way to enable it, so
>> apr/perlio.t has a hard-coded value of 1. Does the test work for you
>> if you set the conflict constant to 0 in that test? We really need to
>> provide a APR::LARGE_FILES_CONFLICT constant from mod_perl.
>
>
> Yes - the extra tests all pass too (15 now instead of just 12). Phew!
>
>>
>>
>> Though I'd like to be it defined(), so can you please try this patch?
>
>
> OK. I tried out your patch (below) and it all works fine. (I put in
> some extra #pragma message("...") lines to double-check that everything
> was being set correctly, which it is.)
Thanks Steve, now committed
__________________________________________________________________
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] Large files conflict on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Good catch, Steve. I guess I have missed that because on linux Apache
> always builds without LARGE_FILES and there is no way to enable it, so
> apr/perlio.t has a hard-coded value of 1. Does the test work for you
> if you set the conflict constant to 0 in that test? We really need to
> provide a APR::LARGE_FILES_CONFLICT constant from mod_perl.
Yes - the extra tests all pass too (15 now instead of just 12). Phew!
>
>
> Though I'd like to be it defined(), so can you please try this patch?
OK. I tried out your patch (below) and it all works fine. (I put in
some extra #pragma message("...") lines to double-check that everything
was being set correctly, which it is.)
- Steve
> I also fixed the logic of setting MP_LARGE_FILES_CONFLICT, I think
> it's correct now:
>
> - !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
> + defined(MP_LARGE_FILES_APR_ONLY) || defined(MP_LARGE_FILES_PERL_ONLY)
>
>
> Index: src/modules/perl/mod_perl.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
> retrieving revision 1.60
> diff -u -r1.60 mod_perl.h
> --- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60
> +++ src/modules/perl/mod_perl.h 19 Sep 2003 17:08:59 -0000
> @@ -22,26 +22,31 @@
> #include "modperl_constants.h"
>
> /* both perl and apr have largefile support enabled */
> -#define MP_LARGE_FILES_ENABLED \
> - (defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
> +#if defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES
> +#define MP_LARGE_FILES_ENABLED
> +#endif
>
> /* both perl and apr have largefile support disabled */
> -#define MP_LARGE_FILES_DISABLED \
> - (!defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
> +#if (!defined(USE_LARGE_FILES)) && !APR_HAS_LARGE_FILES
> +#define MP_LARGE_FILES_DISABLED
> +#endif
>
> -/* perl support is enabled, apr support is disabled */
> -#define MP_LARGE_FILES_PERL_ONLY \
> - (defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
> +/* perl largefile support is enabled, apr support is disabled */
> +#if defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES
> +#define MP_LARGE_FILES_PERL_ONLY
> +#endif
>
> -/* apr support is enabled, perl support is disabled */
> -#define MP_LARGE_FILES_APR_ONLY \
> - (!defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
> +/* apr largefile support is enabled, perl support is disabled */
> +#if (!defined(USE_LARGE_FILES)) && APR_HAS_LARGE_FILES
> +#define MP_LARGE_FILES_APR_ONLY
> +#endif
>
> /* conflict due to not have either both perl and apr
> * support enabled or both disabled
> */
> -#define MP_LARGE_FILES_CONFLICT \
> - !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
> +#if defined(MP_LARGE_FILES_APR_ONLY) ||
> defined(MP_LARGE_FILES_PERL_ONLY)
> +#define MP_LARGE_FILES_CONFLICT
> +#endif
>
> #ifdef MP_USE_GTOP
> #include "modperl_gtop.h"
> Index: xs/APR/PerlIO/apr_perlio.c
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
> retrieving revision 1.33
> diff -u -r1.33 apr_perlio.c
> --- xs/APR/PerlIO/apr_perlio.c 4 Sep 2003 23:57:58 -0000 1.33
> +++ xs/APR/PerlIO/apr_perlio.c 19 Sep 2003 17:09:00 -0000
> @@ -224,7 +224,7 @@
> apr_status_t rc;
> apr_off_t seek_offset = 0;
>
> -#if MP_LARGE_FILES_CONFLICT
> +#ifdef MP_LARGE_FILES_CONFLICT
> if (offset != 0) {
> Perl_croak(aTHX_ "PerlIO::APR::seek with non-zero offset"
> "is not supported with Perl built w/ -Duselargefiles"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] Large files conflict on Win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
> The attached patch fixes that. Now with the following check in place:
>
> #if MP_LARGE_FILES_CONFLICT
> #error "Large files conflict!"
> #endif
>
> I get no error about large files conflict.
>
> The filter/both_str_con_add, hooks/stacked_handlers and modules\include
> tests all still fail, though :-(
At least we are fixing another problem on the way ;) So the effort wasn't wasted.
> --- mod_perl.h.orig 2003-08-21 00:20:14.000000000 +0100
> +++ mod_perl.h 2003-09-19 13:24:39.935392000 +0100
> @@ -23,19 +23,19 @@
>
> /* both perl and apr have largefile support enabled */
> #define MP_LARGE_FILES_ENABLED \
> - (defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
> + ((defined USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
>
> /* both perl and apr have largefile support disabled */
> #define MP_LARGE_FILES_DISABLED \
> - (!defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
> + ((!defined USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
>
> /* perl support is enabled, apr support is disabled */
> #define MP_LARGE_FILES_PERL_ONLY \
> - (defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
> + ((defined USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
>
> /* apr support is enabled, perl support is disabled */
> #define MP_LARGE_FILES_APR_ONLY \
> - (!defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
> + ((!defined USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
>
> /* conflict due to not have either both perl and apr
> * support enabled or both disabled
Good catch, Steve. I guess I have missed that because on linux Apache always
builds without LARGE_FILES and there is no way to enable it, so apr/perlio.t
has a hard-coded value of 1. Does the test work for you if you set the
conflict constant to 0 in that test? We really need to provide a
APR::LARGE_FILES_CONFLICT constant from mod_perl.
Though I'd like to be it defined(), so can you please try this patch? I also
fixed the logic of setting MP_LARGE_FILES_CONFLICT, I think it's correct now:
- !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
+ defined(MP_LARGE_FILES_APR_ONLY) || defined(MP_LARGE_FILES_PERL_ONLY)
Index: src/modules/perl/mod_perl.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
retrieving revision 1.60
diff -u -r1.60 mod_perl.h
--- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60
+++ src/modules/perl/mod_perl.h 19 Sep 2003 17:08:59 -0000
@@ -22,26 +22,31 @@
#include "modperl_constants.h"
/* both perl and apr have largefile support enabled */
-#define MP_LARGE_FILES_ENABLED \
- (defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
+#if defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES
+#define MP_LARGE_FILES_ENABLED
+#endif
/* both perl and apr have largefile support disabled */
-#define MP_LARGE_FILES_DISABLED \
- (!defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
+#if (!defined(USE_LARGE_FILES)) && !APR_HAS_LARGE_FILES
+#define MP_LARGE_FILES_DISABLED
+#endif
-/* perl support is enabled, apr support is disabled */
-#define MP_LARGE_FILES_PERL_ONLY \
- (defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES)
+/* perl largefile support is enabled, apr support is disabled */
+#if defined(USE_LARGE_FILES) && !APR_HAS_LARGE_FILES
+#define MP_LARGE_FILES_PERL_ONLY
+#endif
-/* apr support is enabled, perl support is disabled */
-#define MP_LARGE_FILES_APR_ONLY \
- (!defined(USE_LARGE_FILES) && APR_HAS_LARGE_FILES)
+/* apr largefile support is enabled, perl support is disabled */
+#if (!defined(USE_LARGE_FILES)) && APR_HAS_LARGE_FILES
+#define MP_LARGE_FILES_APR_ONLY
+#endif
/* conflict due to not have either both perl and apr
* support enabled or both disabled
*/
-#define MP_LARGE_FILES_CONFLICT \
- !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
+#if defined(MP_LARGE_FILES_APR_ONLY) || defined(MP_LARGE_FILES_PERL_ONLY)
+#define MP_LARGE_FILES_CONFLICT
+#endif
#ifdef MP_USE_GTOP
#include "modperl_gtop.h"
Index: xs/APR/PerlIO/apr_perlio.c
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/PerlIO/apr_perlio.c,v
retrieving revision 1.33
diff -u -r1.33 apr_perlio.c
--- xs/APR/PerlIO/apr_perlio.c 4 Sep 2003 23:57:58 -0000 1.33
+++ xs/APR/PerlIO/apr_perlio.c 19 Sep 2003 17:09:00 -0000
@@ -224,7 +224,7 @@
apr_status_t rc;
apr_off_t seek_offset = 0;
-#if MP_LARGE_FILES_CONFLICT
+#ifdef MP_LARGE_FILES_CONFLICT
if (offset != 0) {
Perl_croak(aTHX_ "PerlIO::APR::seek with non-zero offset"
"is not supported with Perl built w/ -Duselargefiles"
__________________________________________________________________
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] Large files conflict on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> [changing title again...]
>
> Stas Bekman wrote:
>
>> One other explanation could be type sizes mismatch between perl and
>> apr, but I don't see anything like this happening in here. Though
>> this is something that needs to be checked. Usually this happens if
>> apache and perl are not both build with large_files or w/o. e.g. we
>> have this problem in apr/perlio's seek function. I was passing the
>> value to seek to and the function would convert it to zero. later
>> with help of Nick S.I. from p5p I have learned that the problem was
>> in the type mismatch, perl was passing 64 bit int and apr was
>> accepting 32 bit int, and voila some kind of truncation/alignment
>> was happening.
>>
>> In any case can you check whether you have both perl and apache built
>> with largefiles or both without? Just check whether you have
>> MP_LARGE_FILES_CONFLICT defined in src/modules/perl/mod_perl.h
>>
>> Index: src/modules/perl/mod_perl.h
>> ===================================================================
>> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
>> retrieving revision 1.60
>> diff -u -r1.60 mod_perl.h
>> --- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60
>> +++ src/modules/perl/mod_perl.h 19 Sep 2003 09:11:47 -0000
>> @@ -43,6 +43,10 @@
>> #define MP_LARGE_FILES_CONFLICT \
>> !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
>>
>> +#ifdef MP_LARGE_FILES_CONFLICT
>> +#error "Large files conflict!"
>> +#endif
>> +
>> #ifdef MP_USE_GTOP
>> #include "modperl_gtop.h"
>> #endif
>>
>> if it fails to compile you have this conflict.
>
>
> Yikes! I have a large files conflict!
>
> I specifically built my Perl *with* large files support, believing
> that Apache2 had it. (And conversely, I've always built Perl
> *without* LFS when I'm using mp1 because Apache1 doesn't have it.) Is
> this not the case?
>
> Do I need to do anything special to enable LFS in either Apache2 or
> mp2? Or should I just rebuild Perl without LFS?
Hmm. It seems that I don't actually have a large files conflict after
all - the above patch reported that I did have, but it is wrong!
I think the "#ifdef MP_LARGE_FILES_CONFLICT" should have been "'#if
MP_LARGE_FILES_CONFLICT" (i.e. we need to test the truth of that flag,
not its definedness), but that alone didn't fix it - there seems to be a
problem with the definition of the four MP_LARGE_FILES_* flags
beforehand anyway, at least on Win32.
Witness this:
=====
#define ONE 1
#define TWO 1
#define BOTH (defined(ONE) && TWO)
#if defined(ONE)
# pragma message("ONE is defined")
#else
# pragma message("ONE is not defined")
#endif
#if TWO
# pragma message("TWO is true")
#else
# pragma message("TWO is not true")
#endif
#if BOTH
# pragma message("BOTH is true")
#else
# pragma message("BOTH is not true")
#endif
void main(void) { }
=====
Compiling this with MSVC++ 6 produces the following output:
ONE is defined
TWO is true
BOTH is not true
It seems that it doesn't like "defined(ONE)". If I change the
definition of BOTH above to:
#define BOTH ((defined ONE) && TWO)
then the output is now as expected:
ONE is defined
TWO is true
BOTH is true
The attached patch fixes that. Now with the following check in place:
#if MP_LARGE_FILES_CONFLICT
#error "Large files conflict!"
#endif
I get no error about large files conflict.
The filter/both_str_con_add, hooks/stacked_handlers and modules\include
tests all still fail, though :-(
- Steve
[mp2] Large files conflict on Win32
Posted by Steve Hay <st...@uk.radan.com>.
[changing title again...]
Stas Bekman wrote:
> One other explanation could be type sizes mismatch between perl and
> apr, but I don't see anything like this happening in here. Though this
> is something that needs to be checked. Usually this happens if apache
> and perl are not both build with large_files or w/o. e.g. we have this
> problem in apr/perlio's seek function. I was passing the value to seek
> to and the function would convert it to zero. later with help of Nick
> S.I. from p5p I have learned that the problem was in the type
> mismatch, perl was passing 64 bit int and apr was accepting 32 bit
> int, and voila some kind of truncation/alignment was happening.
>
> In any case can you check whether you have both perl and apache built
> with largefiles or both without? Just check whether you have
> MP_LARGE_FILES_CONFLICT defined in src/modules/perl/mod_perl.h
>
> Index: src/modules/perl/mod_perl.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
> retrieving revision 1.60
> diff -u -r1.60 mod_perl.h
> --- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60
> +++ src/modules/perl/mod_perl.h 19 Sep 2003 09:11:47 -0000
> @@ -43,6 +43,10 @@
> #define MP_LARGE_FILES_CONFLICT \
> !(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
>
> +#ifdef MP_LARGE_FILES_CONFLICT
> +#error "Large files conflict!"
> +#endif
> +
> #ifdef MP_USE_GTOP
> #include "modperl_gtop.h"
> #endif
>
> if it fails to compile you have this conflict.
Yikes! I have a large files conflict!
I specifically built my Perl *with* large files support, believing that
Apache2 had it. (And conversely, I've always built Perl *without* LFS
when I'm using mp1 because Apache1 doesn't have it.) Is this not the case?
Do I need to do anything special to enable LFS in either Apache2 or
mp2? Or should I just rebuild Perl without LFS?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
>> Stas Bekman wrote:
>>
>>> Randy Kobes wrote:
>>>
>>>> For modperl_filter_new():
>>>>
>>>> apr_pool_t *p;
>>>> modperl_filter_t *filter;
>>>> p = f->r ? f->r->pool : f->c->pool;
>>>> filter = (modperl_filter_t *)
>>>> apr_pcalloc(p, sizeof(modperl_filter_t));
>>>
>>>
>>>
>>> >
>>>
>>>> before the apr_pcalloc() call, f->c->pool is defined, and p
>>>> is set equal to it (f->r is null). However, sometimes what
>>>> happens right after the apr_pcalloc() call is that f->r,
>>>> f->c, ... of f get set to null (including f->ctx, which
>>>> causes the crash in modperl_run_filter), and filter gets set
>>>> to the value of p.
>>>
>>>
>>>
>>>
>>> So it clobbers the previously allocated memory. It's possible that
>>> the pool frees that memory and f still points to the old memory and
>>> it works fine till the moment pool reallocs it for something else.
>>> But that's the whole point of pools that there is no free(), the
>>> whole pool is getting destroyed when its life is over and in the
>>> case of f->c->pool that's the life of the whole connection. Only if
>>> the connection object is destroyed the pool get destroyed as well.
>>>
>>> Can you step into apr_pcalloc and keep an eye on the values in p and
>>> f and see what goes wrong inside of it?
>>
>>
>>
>> Not really - only p (i.e. f->c->pool) gets passed into
>> apr_pcalloc(). f is not visible in apr_pcalloc(), so the debugger
>> doesn't show it. I can watch what happens to p, but I don't really
>> know what I'm looking for and it is a rather large structure.
>
>
> Yes, but you can get the address contained in f before you dive into
> apr_pcalloc.
Before the apr_pcalloc() call that breaks things, f->ctx is 0x008e23b8
and &(f->ctx) is 0x008e23cc (very close by!).
I opened the Memory window, entered 0x008e23cc and I see this there: B8
23 8E 00. This is 0x008e23b8 written in some odd way related to
{big|little}-endianness, presumably. (Read it backwards, pairs of hex
digits at a time.)
So then I stepped into apr_pcalloc(), watching that spot in the Memory
window, waiting to see which line changes the value stored at 0x008e23cc
to 00 00 00 00.
Answer: None of them!
None of the lines in apr_pcalloc() nulled that area of memory. However,
when I return to modperl_filter_new(), 0x8e23cc goes to 00 00 00 00 as
soon as the assignment of the return value from apr_pcalloc() to *filter
happens.
Where does this leave us?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>>>What you didn't tell me I think is whether the problem comes on the
>>>>incoming or outgoing filter.
>>>
>>>
>>>How do I tell? I have no idea what's going on here!
>>
>>just disable one in the test and see whether it's the
>>incoming or outgoing on that fails.
>
>
> Could one also look at the value of "mode" within
> modperl_filter_new(), and compare to MP_INPUT_FILTER_MODE?
certainly, but it'll give you the numerical value, which won't make much
sense, unless you lookup the constant. it's probably easier to just adjust the
test.
Of course there is a way to make the constants expandable, at least with the
new gcc and gdb:
http://perl.apache.org/docs/2.0/devel/debug/c.html#Expanding_C_Macros_with_C_gdb_
>>One other explanation could be type sizes mismatch between
>>perl and apr, but I don't see anything like this happening
>>in here. Though this is something that needs to be
>>checked. Usually this happens if apache and perl are not
>>both build with large_files or w/o. e.g. we have this
>>problem in apr/perlio's seek function. I was passing the
>>value to seek to and the function would convert it to
>>zero. later with help of Nick S.I. from p5p I have learned
>>that the problem was in the type mismatch, perl was
>>passing 64 bit int and apr was accepting 32
>> bit int, and voila some kind of truncation/alignment was happening.
>
>
> I built my perl with LFS (as that's what ActiveState uses
> now), and built Apache out of the box. There are some
> warnings generally about mismatches/conversions when
> compiling mp2 in this regard - within modperl_filter_new(),
> one such warning comes from the 'apr_off_t readbytes'
> argument. At one point I tried putting in a typecast to
> appease this warning, but I was also trying other things
> at the time - I'll look at this more closely in isolation.
Looks like it wasn't so right. See the other thread where Steve and I posted
patches to rectify this problem (unrelated to the issue of this test).
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 19 Sep 2003, Stas Bekman wrote:
> Steve Hay wrote:
> > Stas Bekman wrote:
> >
> >> Randy Kobes wrote:
> >>
> >>> For modperl_filter_new():
> >>>
> >>> apr_pool_t *p;
> >>> modperl_filter_t *filter;
> >>> p = f->r ? f->r->pool : f->c->pool;
> >>> filter = (modperl_filter_t *)
> >>> apr_pcalloc(p, sizeof(modperl_filter_t));
> >>
> >>> before the apr_pcalloc() call, f->c->pool is defined, and p
> >>> is set equal to it (f->r is null). However, sometimes what
> >>> happens right after the apr_pcalloc() call is that f->r,
> >>> f->c, ... of f get set to null (including f->ctx, which
> >>> causes the crash in modperl_run_filter), and filter gets set
> >>> to the value of p.
> >>
> >> So it clobbers the previously allocated memory. It's possible that the
> >> pool frees that memory and f still points to the old memory and it
> >> works fine till the moment pool reallocs it for something else. But
> >> that's the whole point of pools that there is no free(), the whole
> >> pool is getting destroyed when its life is over and in the case of
> >> f->c->pool that's the life of the whole connection. Only if the
> >> connection object is destroyed the pool get destroyed as well.
> >>
> >> Can you step into apr_pcalloc and keep an eye on the values in p and f
> >> and see what goes wrong inside of it?
> >
> >
> > Not really - only p (i.e. f->c->pool) gets passed into apr_pcalloc(). f
> > is not visible in apr_pcalloc(), so the debugger doesn't show it. I can
> > watch what happens to p, but I don't really know what I'm looking for
> > and it is a rather large structure.
>
> Yes, but you can get the address contained in f before you
> dive into apr_pcalloc.
I'll also look at this tonight ... I seem to remember that,
when there's a failure, f has the same address as an f
of a previously successful run-through (the failure
comes at about the 3rd pass through modperl_filter_new().
> > When we return from apr_pcalloc() p
> > itself (the pointer value) is unchanged, but f->c has gone NULL --
> > that's the "parent" of p (aka f->c->pool). Does p contain any pointer
> > to f->c through which apr_pcalloc() could NULL it?
>
> Not specifically about f->c, but internally it knows all the allocations.
> That's why I mentioned that everything else fails we need to move on to
> enabling debug support in the pools.
>
> >> What you didn't tell me I think is whether the problem comes on the
> >> incoming or outgoing filter.
> >
> >
> > How do I tell? I have no idea what's going on here!
>
> just disable one in the test and see whether it's the
> incoming or outgoing on that fails.
Could one also look at the value of "mode" within
modperl_filter_new(), and compare to MP_INPUT_FILTER_MODE?
[ ... ]
> One other explanation could be type sizes mismatch between
> perl and apr, but I don't see anything like this happening
> in here. Though this is something that needs to be
> checked. Usually this happens if apache and perl are not
> both build with large_files or w/o. e.g. we have this
> problem in apr/perlio's seek function. I was passing the
> value to seek to and the function would convert it to
> zero. later with help of Nick S.I. from p5p I have learned
> that the problem was in the type mismatch, perl was
> passing 64 bit int and apr was accepting 32
> bit int, and voila some kind of truncation/alignment was happening.
I built my perl with LFS (as that's what ActiveState uses
now), and built Apache out of the box. There are some
warnings generally about mismatches/conversions when
compiling mp2 in this regard - within modperl_filter_new(),
one such warning comes from the 'apr_off_t readbytes'
argument. At one point I tried putting in a typecast to
appease this warning, but I was also trying other things
at the time - I'll look at this more closely in isolation.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sat, 20 Sep 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> [...]
> >>Also it'd be interesting to see the trace =f, if you can get it.
> >
> > ^^^^
> > I'm not quite sure what that is - the apache filter f?
>
> Sorry,
> env MOD_PERL_TRACE=f t/TEST ...
OK - here it is, up until the point it fails:
==============================================================
[Sat Sep 20 23:32:52 2003] [info] mod_perl: using Perl HASH_SEED: 3479257090
mod_perl trace flags dump:
c Off (configuration for directive handlers)
d Off (directive processing)
e Off (environment variables)
f On (filters)
g Off (Perl runtime interaction)
h Off (handlers)
i Off (interpreter pool management)
m Off (memory allocations)
o Off (I/O)
s Off (perl sections)
t Off (benchmark-ish timings)
applied FilterConnectionHandler attribute to ModPerl::TestFilterDebug handler
applied FilterRequestHandler attribute to ModPerl::TestFilterDebug handler
[Sat Sep 20 23:32:58 2003] [info] 22 Apache:: modules loaded
[Sat Sep 20 23:32:58 2003] [info] 5 APR:: modules loaded
[Sat Sep 20 23:32:58 2003] [info] base server + 11 vhosts ready to run tests
applied FilterInitHandler attribute to TestFilter::out_init_basic handler
applied FilterRequestHandler attribute to TestFilter::out_init_basic handler
applied FilterHasInitHandler(get_pre_handler()) attribute to TestFilter::out_init_basic handler
applied FilterInitHandler attribute to TestFilter::in_init_basic handler
applied FilterRequestHandler attribute to TestFilter::in_init_basic handler
applied FilterHasInitHandler(\&transparent_init) attribute to TestFilter::in_init_basic handler
applied FilterInitHandler attribute to TestFilter::in_init_basic handler
applied FilterHasInitHandler(\&suicide_init) attribute to TestFilter::in_init_basic handler
applied FilterRequestHandler attribute to TestFilter::in_bbs_body handler
applied FilterConnectionHandler attribute to TestFilter::in_bbs_msg handler
applied FilterConnectionHandler attribute to TestFilter::in_str_msg handler
[Sat Sep 20 23:33:24 2003] [info] mod_perl: using Perl HASH_SEED: 2559340283
[Sat Sep 20 23:33:24 2003] [notice] Child 1900: Child process is running
[Sat Sep 20 23:33:24 2003] [notice] Child 1900: Acquired the start mutex.
[Sat Sep 20 23:33:24 2003] [notice] Child 1900: Starting 20 worker threads.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 0 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 1 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 2 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 3 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 4 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 5 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 6 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 7 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 8 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 9 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 10 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 11 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 12 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 13 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 14 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 15 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 16 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 17 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 18 starting.
[Sat Sep 20 23:33:24 2003] [debug] child.c(695): Child 1900: Worker thread 19 starting.
[ ... ]
TestFilter::both_str_con_add::in_filter
new: request input filter (0x24fc700)
TestFilter::both_str_con_add::in_filter::read
TestFilter::both_str_con_add::in_filter
retrieving bb: 0x24fe758
TestFilter::both_str_con_add::in_filter
wanted: 1024 bytes
TestFilter::both_str_con_add::in_filter
read in: HEAP bucket with 8 bytes (0x24dfdd0)
TestFilter::both_str_con_add::in_filter
return: 8 bytes from 1 bucket (0 bytes leftover)
TestFilter::both_str_con_add::in_filter::print
TestFilter::both_str_con_add::in_filter
write out: 8 bytes:
TestFilter::both_str_con_add::in_filter::read
TestFilter::both_str_con_add::in_filter
wanted: 1024 bytes
TestFilter::both_str_con_add::in_filter
read in: bucket brigade is empty
TestFilter::both_str_con_add::in_filter
return: 0 bytes from 0 buckets (0 bytes leftover)
TestFilter::both_str_con_add::in_filter
return: 0
TestFilter::both_str_con_add::out_filter
new: request output filter (0x253c3a8)
TestFilter::both_str_con_add::out_filter::read
TestFilter::both_str_con_add::out_filter
wanted: 1024 bytes
TestFilter::both_str_con_add::out_filter
read in: TRANSIENT bucket with 8 bytes (0x24dfdd0)
TestFilter::both_str_con_add::out_filter
read in: FLUSH bucket
TestFilter::both_str_con_add::out_filter
return: 8 bytes from 1 bucket (0 bytes leftover)
TestFilter::both_str_con_add::out_filter::print
TestFilter::both_str_con_add::out_filter::read
TestFilter::both_str_con_add::out_filter
wanted: 1024 bytes
TestFilter::both_str_con_add::out_filter
return: 0 bytes from 0 buckets (0 bytes leftover)
write out: 9 bytes
from current filter handler
to core filter handler
TestFilter::both_str_con_add::out_filter
return: 0
TestFilter::both_str_con_add::in_filter
new: request input filter (0x253c3a8)
TestFilter::both_str_con_add::in_filter::read
TestFilter::both_str_con_add::in_filter
retrieving bb: 0x253e400
TestFilter::both_str_con_add::in_filter
wanted: 1024 bytes
TestFilter::both_str_con_add::in_filter
read in: HEAP bucket with 4 bytes (0x24dfe90)
TestFilter::both_str_con_add::in_filter
return: 4 bytes from 1 bucket (0 bytes leftover)
TestFilter::both_str_con_add::in_filter::print
TestFilter::both_str_con_add::in_filter
write out: 4 bytes:
TestFilter::both_str_con_add::in_filter::read
TestFilter::both_str_con_add::in_filter
wanted: 1024 bytes
TestFilter::both_str_con_add::in_filter
read in: bucket brigade is empty
TestFilter::both_str_con_add::in_filter
return: 0 bytes from 0 buckets (0 bytes leftover)
TestFilter::both_str_con_add::in_filter
return: 0
====================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
>>Also it'd be interesting to see the trace =f, if you can get it.
>
> ^^^^
> I'm not quite sure what that is - the apache filter f?
Sorry,
env MOD_PERL_TRACE=f t/TEST ...
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 19 Sep 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > Here are some results for running the t/filter tests
[ .. ]
> Interesting. So the problem happens in the output filter.
>
> So we have a sequence of:
>
> 1) input filter
> 2) output filter
> 3) input filter
> 4) output filter
>
> What strikes me odd is that 'filter' is already pointing
> to some memory block but only in the output filter (2, 4),
> it's null in the input filter (1, 3).
>
> Does the problem disappear if you remove the input filter:
>
> - $c->add_input_filter(\&in_filter);
> + #$c->add_input_filter(\&in_filter);
>
> if you put it back and remove the output filter?
>
> - $c->add_output_filter(\&in_filter);
> + #$c->add_output_filter(\&in_filter);
>
> each should be invoked 3 times.
No, the same thing occurs in both cases - passing into
modperl_filter_new() 4 times, and on the 4th, f->c and
friends are all set to null.
> Now have you tried descending into apr_pcalloc and seeing
> when the address stored in f->c->pool is returned as the
> allocated memory's address, sounds like a bug in
> apr_pcalloc on win32.
I'll look into that.
> Also it'd be interesting to see the trace =f, if you can get it.
^^^^
I'm not quite sure what that is - the apache filter f?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> Here are some results for running the t/filter tests
> with modperl_filter_new as
>
> modperl_filter_new(*f, *bb, mode, input_mode, block, readbytes)
> {
> apr_pool_t *p;
> modperl_filter_t *filter;
> p = f->r ? f->r->pool : f->c->pool;
> filter = (modperl_filter_t *)
> apr_pcalloc(p, sizeof(modperl_filter_t));
> ...
> }
>
> with inserting a breakpoint just before and just after
> the apr_pcalloc() call. It consistently fails on the
> 4th pass through modperl_filter_new:
>
> 1.
>
> Before:
> f: 0x0142f7e8
> f->c: 0x0142f2f0
> f->c->pool: 0x0142f1f0
> bb: 0x0142f9e0
> mode: 0
> input_mode: 1
> block: 0
> readbytes: 8192
> p: 0x0142f1f0 (= f->c->pool)
> filter: null
>
> After:
> filter: 0x024f7ed8
> the rest unchanged
>
> 2.
>
> Before:
> f: 0x0142f908
> f->c: 0x0142f2f0
> f->c->pool: 0x0142f1f0
> bb: 0x0142f9e0
> mode: 1
> input_mode: 0
> block: 0
> readbytes: 0
> p: 0x0142f1f0 (= f->c->pool)
> filter: 0x0258f730
>
> After:
> filter: 0x025217c0
> the rest unchanged
>
> 3.
>
> Before:
> f: 0x0142f7e8
> f->c: 0x0142f2f0
> f->c->pool: 0x0142f1f0
> bb: 0x0142f9e0
> mode: 0
> input_mode: 1
> block: 0
> readbytes: 8192
> p: 0x0142f1f0 (= f->c->pool)
> filter: null
>
> After:
> filter: 0x025217c0
> the rest unchanged
>
> 4.
>
> Before:
> f: 0x0142f908
> f->c: 0x0142f2f0
> f->c->pool: 0x0142f1f0
> bb: 0x0142f9e0
> mode: 1
> input_mode: 0
> block: 0
> readbytes: 0
> p: 0x0142f1f0 (= f->c->pool)
> filter: 0x0258f6d0
>
> After:
> filter: 0x0142f1f0 (= p = f->c->pool before apr_pcalloc)
> f: 0x0142f908
> f->c: null
> f->c->pool: null
>
> Does anything jump out as being wrong, leading up to
> f->c becoming null?
Interesting. So the problem happens in the output filter.
So we have a sequence of:
1) input filter
2) output filter
3) input filter
4) output filter
What strikes me odd is that 'filter' is already pointing to some memory block
but only in the output filter (2, 4), it's null in the input filter (1, 3).
Does the problem disappear if you remove the input filter:
- $c->add_input_filter(\&in_filter);
+ #$c->add_input_filter(\&in_filter);
if you put it back and remove the output filter?
- $c->add_output_filter(\&in_filter);
+ #$c->add_output_filter(\&in_filter);
each should be invoked 3 times.
Now have you tried descending into apr_pcalloc and seeing when the address
stored in f->c->pool is returned as the allocated memory's address, sounds
like a bug in apr_pcalloc on win32.
Also it'd be interesting to see the trace =f, if you can get 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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
Here are some results for running the t/filter tests
with modperl_filter_new as
modperl_filter_new(*f, *bb, mode, input_mode, block, readbytes)
{
apr_pool_t *p;
modperl_filter_t *filter;
p = f->r ? f->r->pool : f->c->pool;
filter = (modperl_filter_t *)
apr_pcalloc(p, sizeof(modperl_filter_t));
...
}
with inserting a breakpoint just before and just after
the apr_pcalloc() call. It consistently fails on the
4th pass through modperl_filter_new:
1.
Before:
f: 0x0142f7e8
f->c: 0x0142f2f0
f->c->pool: 0x0142f1f0
bb: 0x0142f9e0
mode: 0
input_mode: 1
block: 0
readbytes: 8192
p: 0x0142f1f0 (= f->c->pool)
filter: null
After:
filter: 0x024f7ed8
the rest unchanged
2.
Before:
f: 0x0142f908
f->c: 0x0142f2f0
f->c->pool: 0x0142f1f0
bb: 0x0142f9e0
mode: 1
input_mode: 0
block: 0
readbytes: 0
p: 0x0142f1f0 (= f->c->pool)
filter: 0x0258f730
After:
filter: 0x025217c0
the rest unchanged
3.
Before:
f: 0x0142f7e8
f->c: 0x0142f2f0
f->c->pool: 0x0142f1f0
bb: 0x0142f9e0
mode: 0
input_mode: 1
block: 0
readbytes: 8192
p: 0x0142f1f0 (= f->c->pool)
filter: null
After:
filter: 0x025217c0
the rest unchanged
4.
Before:
f: 0x0142f908
f->c: 0x0142f2f0
f->c->pool: 0x0142f1f0
bb: 0x0142f9e0
mode: 1
input_mode: 0
block: 0
readbytes: 0
p: 0x0142f1f0 (= f->c->pool)
filter: 0x0258f6d0
After:
filter: 0x0142f1f0 (= p = f->c->pool before apr_pcalloc)
f: 0x0142f908
f->c: null
f->c->pool: null
Does anything jump out as being wrong, leading up to
f->c becoming null?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Stas Bekman wrote:
>
>> Randy Kobes wrote:
>>
>>> For modperl_filter_new():
>>>
>>> apr_pool_t *p;
>>> modperl_filter_t *filter;
>>> p = f->r ? f->r->pool : f->c->pool;
>>> filter = (modperl_filter_t *)
>>> apr_pcalloc(p, sizeof(modperl_filter_t));
>>
>>
>> >
>>
>>> before the apr_pcalloc() call, f->c->pool is defined, and p
>>> is set equal to it (f->r is null). However, sometimes what
>>> happens right after the apr_pcalloc() call is that f->r,
>>> f->c, ... of f get set to null (including f->ctx, which
>>> causes the crash in modperl_run_filter), and filter gets set
>>> to the value of p.
>>
>>
>>
>> So it clobbers the previously allocated memory. It's possible that the
>> pool frees that memory and f still points to the old memory and it
>> works fine till the moment pool reallocs it for something else. But
>> that's the whole point of pools that there is no free(), the whole
>> pool is getting destroyed when its life is over and in the case of
>> f->c->pool that's the life of the whole connection. Only if the
>> connection object is destroyed the pool get destroyed as well.
>>
>> Can you step into apr_pcalloc and keep an eye on the values in p and f
>> and see what goes wrong inside of it?
>
>
> Not really - only p (i.e. f->c->pool) gets passed into apr_pcalloc(). f
> is not visible in apr_pcalloc(), so the debugger doesn't show it. I can
> watch what happens to p, but I don't really know what I'm looking for
> and it is a rather large structure.
Yes, but you can get the address contained in f before you dive into apr_pcalloc.
> When we return from apr_pcalloc() p
> itself (the pointer value) is unchanged, but f->c has gone NULL --
> that's the "parent" of p (aka f->c->pool). Does p contain any pointer
> to f->c through which apr_pcalloc() could NULL it?
Not specifically about f->c, but internally it knows all the allocations.
That's why I mentioned that everything else fails we need to move on to
enabling debug support in the pools.
>> What you didn't tell me I think is whether the problem comes on the
>> incoming or outgoing filter.
>
>
> How do I tell? I have no idea what's going on here!
just disable one in the test and see whether it's the incoming or outgoing on
that fails.
>> Another interesting temp workaround would be to cheat like so:
>>
>> apr_pool_t *p = MP_FILTER_POOL(f);
>> char *fake_data = (char*)apr_palloc(p, sizeof(ap_filter_rec_t)+
>> sizeof(ap_filter_rec_t)+sizeof(void)+sizeof(ap_filter_t)+
>> sizeof(request_rec)+sizeof(conn_rec));
>> modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
>>
>> notice that I allocate memory for the filter and its members but don't
>> zero them, so it won't clobber the real data. Only then I pcalloc the
>> real memory that I'm going to use.
>
>
> I tried this, and it makes no difference. Still get the same crash in
> the same place for the same reason.
OK, so it probably somewhere else.
One other explanation could be type sizes mismatch between perl and apr, but I
don't see anything like this happening in here. Though this is something that
needs to be checked. Usually this happens if apache and perl are not both
build with large_files or w/o. e.g. we have this problem in apr/perlio's seek
function. I was passing the value to seek to and the function would convert it
to zero. later with help of Nick S.I. from p5p I have learned that the problem
was in the type mismatch, perl was passing 64 bit int and apr was accepting 32
bit int, and voila some kind of truncation/alignment was happening.
In any case can you check whether you have both perl and apache built with
largefiles or both without? Just check whether you have
MP_LARGE_FILES_CONFLICT defined in src/modules/perl/mod_perl.h
Index: src/modules/perl/mod_perl.h
===================================================================
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.h,v
retrieving revision 1.60
diff -u -r1.60 mod_perl.h
--- src/modules/perl/mod_perl.h 20 Aug 2003 23:20:14 -0000 1.60
+++ src/modules/perl/mod_perl.h 19 Sep 2003 09:11:47 -0000
@@ -43,6 +43,10 @@
#define MP_LARGE_FILES_CONFLICT \
!(MP_LARGE_FILES_ENABLED || MP_LARGE_FILES_DISABLED)
+#ifdef MP_LARGE_FILES_CONFLICT
+#error "Large files conflict!"
+#endif
+
#ifdef MP_USE_GTOP
#include "modperl_gtop.h"
#endif
if it fails to compile you have this conflict.
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> For modperl_filter_new():
>>
>> apr_pool_t *p;
>> modperl_filter_t *filter;
>> p = f->r ? f->r->pool : f->c->pool;
>> filter = (modperl_filter_t *)
>> apr_pcalloc(p, sizeof(modperl_filter_t));
>
> >
>
>> before the apr_pcalloc() call, f->c->pool is defined, and p
>> is set equal to it (f->r is null). However, sometimes what
>> happens right after the apr_pcalloc() call is that f->r,
>> f->c, ... of f get set to null (including f->ctx, which
>> causes the crash in modperl_run_filter), and filter gets set
>> to the value of p.
>
>
> So it clobbers the previously allocated memory. It's possible that the
> pool frees that memory and f still points to the old memory and it
> works fine till the moment pool reallocs it for something else. But
> that's the whole point of pools that there is no free(), the whole
> pool is getting destroyed when its life is over and in the case of
> f->c->pool that's the life of the whole connection. Only if the
> connection object is destroyed the pool get destroyed as well.
>
> Can you step into apr_pcalloc and keep an eye on the values in p and f
> and see what goes wrong inside of it?
Not really - only p (i.e. f->c->pool) gets passed into apr_pcalloc(). f
is not visible in apr_pcalloc(), so the debugger doesn't show it. I can
watch what happens to p, but I don't really know what I'm looking for
and it is a rather large structure. When we return from apr_pcalloc() p
itself (the pointer value) is unchanged, but f->c has gone NULL --
that's the "parent" of p (aka f->c->pool). Does p contain any pointer
to f->c through which apr_pcalloc() could NULL it?
>
>
> What you didn't tell me I think is whether the problem comes on the
> incoming or outgoing filter.
How do I tell? I have no idea what's going on here!
>
>
> Another interesting temp workaround would be to cheat like so:
>
> apr_pool_t *p = MP_FILTER_POOL(f);
> char *fake_data = (char*)apr_palloc(p, sizeof(ap_filter_rec_t)+
> sizeof(ap_filter_rec_t)+sizeof(void)+sizeof(ap_filter_t)+
> sizeof(request_rec)+sizeof(conn_rec));
> modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
>
> notice that I allocate memory for the filter and its members but don't
> zero them, so it won't clobber the real data. Only then I pcalloc the
> real memory that I'm going to use.
I tried this, and it makes no difference. Still get the same crash in
the same place for the same reason.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Thu, 18 Sep 2003, Stas Bekman wrote:
> [ ... ]
>
>>so basically we always work with f->c->pool here. please
>>check that it's the same value at the beginning of the run
>>and continues to be the same as you go. It definitely
>>can't be null at any given point. to simplify debugging
>>you can even replace all places
>>
>>p = f->r ? f->r->pool : f->c->pool;
>>
>>with:
>>
>>p = f->c->pool;
>
>
> Of course, you're right that f->c->pool isn't null at
> the start of modperl_filter_new() - I was reading the
> table wrong. I think I got it now, though, and the
> problem does seem to be in the apr_pcalloc() call.
> For modperl_filter_new():
>
> apr_pool_t *p;
> modperl_filter_t *filter;
> p = f->r ? f->r->pool : f->c->pool;
> filter = (modperl_filter_t *)
> apr_pcalloc(p, sizeof(modperl_filter_t));
>
> before the apr_pcalloc() call, f->c->pool is defined, and p
> is set equal to it (f->r is null). However, sometimes what
> happens right after the apr_pcalloc() call is that f->r,
> f->c, ... of f get set to null (including f->ctx, which
> causes the crash in modperl_run_filter), and filter gets set
> to the value of p.
So it clobbers the previously allocated memory. It's possible that the pool
frees that memory and f still points to the old memory and it works fine till
the moment pool reallocs it for something else. But that's the whole point of
pools that there is no free(), the whole pool is getting destroyed when its
life is over and in the case of f->c->pool that's the life of the whole
connection. Only if the connection object is destroyed the pool get destroyed
as well.
Can you step into apr_pcalloc and keep an eye on the values in p and f and see
what goes wrong inside of it?
What you didn't tell me I think is whether the problem comes on the incoming
or outgoing filter.
Another interesting temp workaround would be to cheat like so:
apr_pool_t *p = MP_FILTER_POOL(f);
char *fake_data = (char*)apr_palloc(p, sizeof(ap_filter_rec_t)+
sizeof(ap_filter_rec_t)+sizeof(void)+sizeof(ap_filter_t)+
sizeof(request_rec)+sizeof(conn_rec));
modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
notice that I allocate memory for the filter and its members but don't zero
them, so it won't clobber the real data. Only then I pcalloc the real memory
that I'm going to use.
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 18 Sep 2003, Stas Bekman wrote:
[ ... ]
> so basically we always work with f->c->pool here. please
> check that it's the same value at the beginning of the run
> and continues to be the same as you go. It definitely
> can't be null at any given point. to simplify debugging
> you can even replace all places
>
> p = f->r ? f->r->pool : f->c->pool;
>
> with:
>
> p = f->c->pool;
Of course, you're right that f->c->pool isn't null at
the start of modperl_filter_new() - I was reading the
table wrong. I think I got it now, though, and the
problem does seem to be in the apr_pcalloc() call.
For modperl_filter_new():
apr_pool_t *p;
modperl_filter_t *filter;
p = f->r ? f->r->pool : f->c->pool;
filter = (modperl_filter_t *)
apr_pcalloc(p, sizeof(modperl_filter_t));
before the apr_pcalloc() call, f->c->pool is defined, and p
is set equal to it (f->r is null). However, sometimes what
happens right after the apr_pcalloc() call is that f->r,
f->c, ... of f get set to null (including f->ctx, which
causes the crash in modperl_run_filter), and filter gets set
to the value of p.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Thu, 18 Sep 2003, Stas Bekman wrote:
>
>
>>So did you look at the value of f->ctx before and after
>>the apr_pcalloc() call on line 228 and that's when it has
>>changed? are you sure that your compiler reports the line
>>number correctly? Sometimes with an optimized code it may
>>report wrong lines. e.g. I'd suggest to change:
>>modperl_filter_t *filter =
>>apr_pcalloc(p, sizeof(*filter));
>>
>>to:
>>
>>modperl_filter_t *filter;
>>filter = apr_pcalloc(p, sizeof(*filter));
>
>
> I find the same thing as Steve concerning this change:
> within modperl_run_filter(), filter->f->ctx is null.
>
> I hope I'm reading this right, but I tried the following.
> Within modperl_output_filter_handler(), I had
> ....
> else {
> p = f->r ? f->r->pool : f->c->pool;
> filter = modperl_filter_new(f, ....);
> status = modperl_run_filter();
> }
> Just after the
> p = f->r ? f->r->pool : f->c->pool;
> line, p has a value 0x0142de30, f is 0x0142e548, and
> f->ctx, f->r and f->c are all null.
That's is not quite possible. If f->c == NULL, how come f->c->pool didn't
segfault? f->r should be null since we are inside a connection, no r objects
there.
> It then calls
> modperl_filter_new(), within which I had
> apr_pool_t *p;
> modperl_filter_t *filter;
> p = f->r ? f->r->pool : f->c->pool;
> filter = (modperl_filter_t *)
> apr_pcalloc(p, sizeof(modperl_filter_t));
> At the line
> p = f->r ? f->r->pool : f->c->pool;
> p has a value 0x0142de30, f is 0x0142e548, and f->r and f->c
> are null, all as before. After the call
> filter = (modperl_filter_t *)
> apr_pcalloc(p, sizeof(modperl_filter_t));
> filter has a value 0x0142de30, which is the same as p
> of before, and indeed filter->pool is 0x0142de30.
>
>
>>>Does this help at all?
>>
>>Certainly. It is possible that the memory pool is messed
>>up. If you change apr_pcalloc with apr_palloc does it
>>still happen (if it doesn't it will crash elsewhere, since
>>that just proves that apr_pcalloc allocates the already
>>allocated memory). the next step would be to enable
>>apr_pool debug tracing :(
>
>
> I tried with apr_palloc, and, as you say, it crashes
> earlier.
right, because some code relies on apr_pcalloc to initialize the struct's
members to zero.
so basically we always work with f->c->pool here. please check that it's the
same value at the beginning of the run and continues to be the same as you go.
It definitely can't be null at any given point. to simplify debugging you can
even replace all places
p = f->r ? f->r->pool : f->c->pool;
with:
p = f->c->pool;
of course just for this test.
__________________________________________________________________
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] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 18 Sep 2003, Stas Bekman wrote:
> So did you look at the value of f->ctx before and after
> the apr_pcalloc() call on line 228 and that's when it has
> changed? are you sure that your compiler reports the line
> number correctly? Sometimes with an optimized code it may
> report wrong lines. e.g. I'd suggest to change:
> modperl_filter_t *filter =
> apr_pcalloc(p, sizeof(*filter));
>
> to:
>
> modperl_filter_t *filter;
> filter = apr_pcalloc(p, sizeof(*filter));
I find the same thing as Steve concerning this change:
within modperl_run_filter(), filter->f->ctx is null.
I hope I'm reading this right, but I tried the following.
Within modperl_output_filter_handler(), I had
....
else {
p = f->r ? f->r->pool : f->c->pool;
filter = modperl_filter_new(f, ....);
status = modperl_run_filter();
}
Just after the
p = f->r ? f->r->pool : f->c->pool;
line, p has a value 0x0142de30, f is 0x0142e548, and
f->ctx, f->r and f->c are all null. It then calls
modperl_filter_new(), within which I had
apr_pool_t *p;
modperl_filter_t *filter;
p = f->r ? f->r->pool : f->c->pool;
filter = (modperl_filter_t *)
apr_pcalloc(p, sizeof(modperl_filter_t));
At the line
p = f->r ? f->r->pool : f->c->pool;
p has a value 0x0142de30, f is 0x0142e548, and f->r and f->c
are null, all as before. After the call
filter = (modperl_filter_t *)
apr_pcalloc(p, sizeof(modperl_filter_t));
filter has a value 0x0142de30, which is the same as p
of before, and indeed filter->pool is 0x0142de30.
> > Does this help at all?
>
> Certainly. It is possible that the memory pool is messed
> up. If you change apr_pcalloc with apr_palloc does it
> still happen (if it doesn't it will crash elsewhere, since
> that just proves that apr_pcalloc allocates the already
> allocated memory). the next step would be to enable
> apr_pool debug tracing :(
I tried with apr_palloc, and, as you say, it crashes
earlier.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 22 Sep 2003, Steve Hay wrote:
> Concentrating on the shortest sequence that still fails (lookup_uri +
> pool + both_str_con_add), I find that the attached patch (which
> truncates the t/apr/pool tests from 13 to just 2) makes this test
> sequence succeed.
>
> Most interestingly, if you move the "return Apache::OK;" that I've
> inserted into pool.pm down one more line, to just *after* the
> "$p->destroy();", then the test sequence fails again.
>
> Perhaps there is a problem with APR::Pool->destroy()?
That's interesting .... There's also a comment in
xs/Apache/Filter/Apache__Filter.h:
========================================================
static MP_INLINE apr_size_t mpxs_Apache__Filter_print(pTHX_ I32 items,
SV **MARK, SV **SP)
{
modperl_filter_t *modperl_filter;
apr_size_t bytes = 0;
[ ... ]
/* XXX: ap_rflush if $| */
return bytes;
}
=======================================================
that may be relevant?
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> It looks like the problem is not so much that f->ctx et al gets
>> zeroed, as that apr_pcalloc() returns something "under" f (namely,
>> f->c->pool) as the zeroed memory, rather than a "new" area of memory.
>> The fact that f->ctx et al gets zeroed is just a consequence of that.
>>
>> Was it at all relevant that on the successful run filter->pool was
>> 0xffffffff to start with? That value wouldn't normally just crop up
>> by accident!
>
>
> nice work steve. I think that adds a lot.
>
> the implementation from apr_pcalloc (in apr_pools.h) says this
>
> * Allocate a block of memory from a pool and set all of the memory to 0
> #define apr_pcalloc(p, size) memset(apr_palloc(p, size), 0, size)
>
> the thing that I don't get, though, is that later on apr_pools.c does this
>
> #ifdef apr_pcalloc
> #undef apr_pcalloc
> #endif
>
> ...
> if ((mem = apr_palloc(pool, size)) != NULL) {
> memset(mem, 0, size);
> }
>
> and there is at least one case in apr_palloc where it officially returns
> NULL.
>
> my C isn't that strong, but is the #ifdef really undoing the first macro
> for everybody? my intuition tells me that it should be an #ifndef block
> instead...
It does the right thing, that macro is local to the .c file, all other .c
files will see the macro from .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: filter/both_str_con_add on win32
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> It looks like the problem is not so much that f->ctx et al gets zeroed,
> as that apr_pcalloc() returns something "under" f (namely, f->c->pool)
> as the zeroed memory, rather than a "new" area of memory. The fact that
> f->ctx et al gets zeroed is just a consequence of that.
>
> Was it at all relevant that on the successful run filter->pool was
> 0xffffffff to start with? That value wouldn't normally just crop up by
> accident!
nice work steve. I think that adds a lot.
the implementation from apr_pcalloc (in apr_pools.h) says this
* Allocate a block of memory from a pool and set all of the memory to 0
#define apr_pcalloc(p, size) memset(apr_palloc(p, size), 0, size)
the thing that I don't get, though, is that later on apr_pools.c does this
#ifdef apr_pcalloc
#undef apr_pcalloc
#endif
...
if ((mem = apr_palloc(pool, size)) != NULL) {
memset(mem, 0, size);
}
and there is at least one case in apr_palloc where it officially returns NULL.
my C isn't that strong, but is the #ifdef really undoing the first macro for
everybody? my intuition tells me that it should be an #ifndef block instead...
oh, and I'm only guessing this is the same implementation on win32, despite
apr_pools.c living in memory/unix?
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Wed, 24 Sep 2003, Stas Bekman wrote:
>> [ .. ]
>>
>>> Steve, can you please try replacing:
>>>
>>> $p->destroy;
>>>
>>> with:
>>>
>>> $subp->destroy;
>>> $p->destroy;
>>
>>
>>
>> I get the same failure (just making this change).
>
>
> I meant the change to the minimized working version that Steve has
> posted:
>
> my $p = APR::Pool->new;
> my $subp = $p->new;
> $subp->destroy;
> $p->destroy;
>
> scratching the rest.
Having first re-instated Geoff's patch to get things breaking again,
I've now tried running "perl t/TEST t/api/lookup_uri t/apr/pool
t/filter/both_str_con_add" as before, with pool.pm patched as attached.
It sill fails :-(
- Steve
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 24 Sep 2003, Stas Bekman wrote:
> [ .. ]
>
>>Steve, can you please try replacing:
>>
>>$p->destroy;
>>
>>with:
>>
>>$subp->destroy;
>>$p->destroy;
>
>
> I get the same failure (just making this change).
I meant the change to the minimized working version that Steve has posted:
my $p = APR::Pool->new;
my $subp = $p->new;
$subp->destroy;
$p->destroy;
scratching the rest.
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 24 Sep 2003, Stas Bekman wrote:
[ .. ]
> Steve, can you please try replacing:
>
> $p->destroy;
>
> with:
>
> $subp->destroy;
> $p->destroy;
I get the same failure (just making this change).
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>
>> Did you see my comment about removing the subpool part from
>> t/t/response/TestAPR/pool.pm "fixing" it?
>>
>> (http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106424373602910&w=2)
>>
>>
>> Basically, this broke:
>>
>> my $p = APR::Pool->new;
>> my $subp = $p->new;
>> $p->destroy;
>>
>> but this worked:
>>
>> my $p = APR::Pool->new;
>> $p->destroy;
>>
>> Dunno if there's anything in that.
Steve, can you please try replacing:
$p->destroy;
with:
$subp->destroy;
$p->destroy;
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> On Wed, 24 Sep 2003, Stas Bekman wrote:
>>
>>
>>> Sander says that this shouldn't be an issue, however try
>>> this patch. It assigns a unique key based on the pool
>>> address without hardcoding anything at all:
>>>
>>> Index: xs/APR/Pool/APR__Pool.h
>>> ===================================================================
>>> RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
>>> retrieving revision 1.6
>>> diff -u -r1.6 APR__Pool.h
>>> --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
>>> +++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:55:57 -0000
>>> @@ -9,12 +9,15 @@
>>> {
>>> apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
>>> apr_pool_t *newpool = NULL;
>>> + char *key;
>>> +
>>> (void)apr_pool_create(&newpool, parent);
>>>
>>> /* mark the pool as being created via APR::Pool->new()
>>> * see mpxs_apr_pool_DESTROY */
>>> - apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
>>> - apr_pool_cleanup_null, newpool);
>>> + key = apr_psprintf(newpool, "0x%lx", (unsigned long)newpool);
>>> + fprintf(stderr, "CREATE key: %s\n", key);
>>> + apr_pool_userdata_set((const void *)1, key, NULL, newpool);
>>>
>>> return newpool;
>>> }
>>> @@ -119,7 +122,8 @@
>>>
>>> void *flag;
>>> apr_pool_t *p;
>>> -
>>> + char *key;
>>> +
>>> /* APR::Pool::DESTROY
>>> * we only want to call DESTROY on objects created by
>>> * APR::Pool->new(), not objects representing native pools
>>> @@ -128,7 +132,9 @@
>>>
>>> p = mpxs_sv_object_deref(obj, apr_pool_t);
>>>
>>> - apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
>>> + key = apr_psprintf(p, "0x%lx", (unsigned long)p);
>>> + fprintf(stderr, "DESTROY key: %s\n", key);
>>> + apr_pool_userdata_get(&flag, key, p);
>>>
>>> if (flag) {
>>> apr_pool_destroy(p);
>>
>
> Do you get the printf reporting unique addresses, which are used as keys?
>
>> Unfortunately, I get back the t/filter/ crash with this
>> patch ...
>
>
> That just proves that the problem is unrelated to keys, but to the
> fact that subpools are destroyed. Both your previous patches weren't
> destroying either the parent or the child pools, hence you had a
> partial success I believe.
>
> We are adjusting the warning in userdata_set docco to disambiguate the
> note and tell that the uniqueness is needed only inside the same pool,
> not even a pool and its sub-pool. it's just that each pool uses its
> own apr_hash_t to store the keys and the data, that's why uniqueness
> is needed.
Stas, In the light of Randy's response I haven't tried out your patch
above. Do you still want me to or not?
>
>
> Back to the sketching board. It took me half a day of apr patching to
> just be able to debug with --enable-pool-debug=all, which didn't quite
> work out of box :( I wish I had the segfault like you do, it'd make my
> debugging so much easier, rather than looking at the addresses and
> trying to figure out what could go wrong when everything seems to be OK.
>
> BTW, does apr pool debugging work for you? Please try building apr as:
>
> cd httpd-2.0/srclib/apr>
> make distclean
> ./configure --enable-pool-debug=all --enable-maintainer-mode
> --prefix=/home/stas/httpd/prefork && make
> make install
>
> of course adjust the prefix ;)
I'm trying to turn on the apr pool debugging, but without much success.
The build process on Win32 is completely different. The httpd .tar.gz
file sources don't build at all on Win32 -- we have to use the
win32-src.zip file sources instead. This includes various windows
makefiles, including apr.mak and libapr.mak in the srclib/apr
directory. I've hacked both of them to add /DAPR_POOL_DEBUG=31 into the
CPP_PROJ macros; that seems to be what --enable-pool-debug=all would
have done. Is that all I need to do?
I then rebuilt Apache2 & mp2, but then couldn't even start the server.
(It emits mountains of crap into the console window when trying,
though! Lines like this:
POOL DEBUG: [2692/52] PCALLOC ( 429808/ 430630/ 436490)
0x00285A88 "pconf" <.\tables\apr_tables.c:101> (8694/8694/0)
hundreds of times over. But nothing to the error_log!)
>
>
> If it segfaults on start like it did for me, I have posted a
> workaround here:
> http://marc.theaimsgroup.com/?l=apr-dev&m=106447516910813&w=2
> not sure whether it will work for you, since it slashes a global
> pool's mutex.
I tried applying the patch you posted at the address above to fix the
startup failure that I now have. I hacked apr/misc/win32/start.c rather
than apr/misc/unix/start.c; that also involved copying apr_atomic_init()
from elsewhere too, otherwise it was undefined!
Sadly, all my hacking has got me nowhere - I still can't start Apache2.
A complete diff of what I did to try to enable apr pool debugging is
attached.
- Steve
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 24 Sep 2003, Stas Bekman wrote:
>
>
>>Sander says that this shouldn't be an issue, however try
>>this patch. It assigns a unique key based on the pool
>>address without hardcoding anything at all:
>>
>>Index: xs/APR/Pool/APR__Pool.h
>>===================================================================
>>RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
>>retrieving revision 1.6
>>diff -u -r1.6 APR__Pool.h
>>--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
>>+++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:55:57 -0000
>>@@ -9,12 +9,15 @@
>> {
>> apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
>> apr_pool_t *newpool = NULL;
>>+ char *key;
>>+
>> (void)apr_pool_create(&newpool, parent);
>>
>> /* mark the pool as being created via APR::Pool->new()
>> * see mpxs_apr_pool_DESTROY */
>>- apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
>>- apr_pool_cleanup_null, newpool);
>>+ key = apr_psprintf(newpool, "0x%lx", (unsigned long)newpool);
>>+ fprintf(stderr, "CREATE key: %s\n", key);
>>+ apr_pool_userdata_set((const void *)1, key, NULL, newpool);
>>
>> return newpool;
>> }
>>@@ -119,7 +122,8 @@
>>
>> void *flag;
>> apr_pool_t *p;
>>-
>>+ char *key;
>>+
>> /* APR::Pool::DESTROY
>> * we only want to call DESTROY on objects created by
>> * APR::Pool->new(), not objects representing native pools
>>@@ -128,7 +132,9 @@
>>
>> p = mpxs_sv_object_deref(obj, apr_pool_t);
>>
>>- apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
>>+ key = apr_psprintf(p, "0x%lx", (unsigned long)p);
>>+ fprintf(stderr, "DESTROY key: %s\n", key);
>>+ apr_pool_userdata_get(&flag, key, p);
>>
>> if (flag) {
>> apr_pool_destroy(p);
Do you get the printf reporting unique addresses, which are used as keys?
> Unfortunately, I get back the t/filter/ crash with this
> patch ...
That just proves that the problem is unrelated to keys, but to the fact that
subpools are destroyed. Both your previous patches weren't destroying either
the parent or the child pools, hence you had a partial success I believe.
We are adjusting the warning in userdata_set docco to disambiguate the note
and tell that the uniqueness is needed only inside the same pool, not even a
pool and its sub-pool. it's just that each pool uses its own apr_hash_t to
store the keys and the data, that's why uniqueness is needed.
Back to the sketching board. It took me half a day of apr patching to just be
able to debug with --enable-pool-debug=all, which didn't quite work out of box
:( I wish I had the segfault like you do, it'd make my debugging so much
easier, rather than looking at the addresses and trying to figure out what
could go wrong when everything seems to be OK.
BTW, does apr pool debugging work for you? Please try building apr as:
cd httpd-2.0/srclib/apr>
make distclean
./configure --enable-pool-debug=all --enable-maintainer-mode
--prefix=/home/stas/httpd/prefork && make
make install
of course adjust the prefix ;)
If it segfaults on start like it did for me, I have posted a workaround here:
http://marc.theaimsgroup.com/?l=apr-dev&m=106447516910813&w=2
not sure whether it will work for you, since it slashes a global pool's mutex.
now you need to patch the create function to tag the pool, so you can find the
relevant messages in the sea of other debug prints.
Index: xs/APR/Pool/APR__Pool.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
retrieving revision 1.6
diff -u -r1.6 APR__Pool.h
--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
+++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 08:00:32 -0000
@@ -11,6 +11,8 @@
apr_pool_t *newpool = NULL;
(void)apr_pool_create(&newpool, parent);
+ apr_pool_tag(newpool, MP_APR_POOL_NEW);
+
/* mark the pool as being created via APR::Pool->new()
* see mpxs_apr_pool_DESTROY */
apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
I then use the following tick to fish the messages relevant to the pools we
create:
tail -F t/logs/error_log | grep APR::
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 24 Sep 2003, Stas Bekman wrote:
> Sander says that this shouldn't be an issue, however try
> this patch. It assigns a unique key based on the pool
> address without hardcoding anything at all:
>
> Index: xs/APR/Pool/APR__Pool.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
> retrieving revision 1.6
> diff -u -r1.6 APR__Pool.h
> --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
> +++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:55:57 -0000
> @@ -9,12 +9,15 @@
> {
> apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
> apr_pool_t *newpool = NULL;
> + char *key;
> +
> (void)apr_pool_create(&newpool, parent);
>
> /* mark the pool as being created via APR::Pool->new()
> * see mpxs_apr_pool_DESTROY */
> - apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
> - apr_pool_cleanup_null, newpool);
> + key = apr_psprintf(newpool, "0x%lx", (unsigned long)newpool);
> + fprintf(stderr, "CREATE key: %s\n", key);
> + apr_pool_userdata_set((const void *)1, key, NULL, newpool);
>
> return newpool;
> }
> @@ -119,7 +122,8 @@
>
> void *flag;
> apr_pool_t *p;
> -
> + char *key;
> +
> /* APR::Pool::DESTROY
> * we only want to call DESTROY on objects created by
> * APR::Pool->new(), not objects representing native pools
> @@ -128,7 +132,9 @@
>
> p = mpxs_sv_object_deref(obj, apr_pool_t);
>
> - apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
> + key = apr_psprintf(p, "0x%lx", (unsigned long)p);
> + fprintf(stderr, "DESTROY key: %s\n", key);
> + apr_pool_userdata_get(&flag, key, p);
>
> if (flag) {
> apr_pool_destroy(p);
Unfortunately, I get back the t/filter/ crash with this
patch ...
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Wed, 24 Sep 2003, Stas Bekman wrote:
>
>
>>we disscussed this issue on the irc, we now enter the code
>>freeze stage where we no longer commit any code and
>>getting ready for a release candidate, the only
>>outstanding issue we want to resolve is the sub-pools. I'm
>>going to look at it now.
>
>
> Might this have something to do with the comment in
> apr_pools.h:
>
> /**
> * Set the data associated with the current pool
> * @param data The user data associated with the pool.
> * @param key The key to use for association
> * @param cleanup The cleanup program to use to cleanup the data (NULL if none)
> * @param pool The current pool
> * @warning The data to be attached to the pool should have a life span
> * at least as long as the pool it is being attached to.
> *
> * Users of APR must take EXTREME care when choosing a key to
> * use for their data. It is possible to accidentally overwrite
> * data by choosing a key that another part of the program is using
> * It is advised that steps are taken to ensure that a unique
> * key is used at all times.
> * @bug Specify how to ensure this uniqueness!
> */
> APR_DECLARE(apr_status_t) apr_pool_userdata_set(
> const void *data,
> const char *key,
> apr_status_t (*cleanup)(void *),
>
> in that the key must be unique for both pools and subpools?
> I tried the following:
> ===========================================================
> Index: xs/APR/Pool/APR__Pool.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
> retrieving revision 1.6
> diff -u -r1.6 APR__Pool.h
> --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
> +++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 04:56:59 -0000
> @@ -1,4 +1,5 @@
> #define MP_APR_POOL_NEW "APR::Pool::new"
> +#define MP_APR_SUBPOOL_NEW "APR::SubPool::new"
>
> /**
> * create a new pool or subpool
> @@ -9,11 +10,12 @@
> {
> apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
> apr_pool_t *newpool = NULL;
> + const char *key = parent ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
> (void)apr_pool_create(&newpool, parent);
>
> /* mark the pool as being created via APR::Pool->new()
> * see mpxs_apr_pool_DESTROY */
> - apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
> + apr_pool_userdata_set((const void *)1, key,
> apr_pool_cleanup_null, newpool);
>
> return newpool;
> @@ -119,6 +121,7 @@
>
> void *flag;
> apr_pool_t *p;
> + const char *key;
>
> /* APR::Pool::DESTROY
> * we only want to call DESTROY on objects created by
> @@ -127,8 +130,9 @@
> * apr_pool_destroy ($p->destroy) */
>
> p = mpxs_sv_object_deref(obj, apr_pool_t);
> + key = p ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
>
> - apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
> + apr_pool_userdata_get(&flag, key, p);
>
> if (flag) {
> apr_pool_destroy(p);
> ===============================================================
> which is intended to give a different key to a parent and
> to a subpool. Running
> perl -Mblib t/TEST t/api t/apr t/filter
> got some failures in apr/pool (subtests 6-13), but all
> the filter tests passed.
>
> I tried changing
> =================================================================
> Index: t/response/TestAPR/pool.pm
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/pool.pm,v
> retrieving revision 1.5
> diff -u -r1.5 pool.pm
> --- t/response/TestAPR/pool.pm 9 Sep 2003 17:22:39 -0000 1.5
> +++ t/response/TestAPR/pool.pm 25 Sep 2003 04:59:00 -0000
> @@ -44,6 +44,7 @@
> $subp->cleanup_register(\&set_cleanup, [$r, 'child']);
>
> # should destroy the subpool too
> + $subp->destroy;
> $p->destroy;
>
> my @notes = $r->notes->get('cleanup');
> ================================================================
> to see if it'd help with the apr/pool tests, but it didn't.
> But this is probably because what I did to APR__Pool.h
> wasn't the right thing in general; in particular, if this
> is on the right track that the keys should be unique, then
> one would want a unique key for all subpools.
Sander says that this shouldn't be an issue, however try this patch. It
assigns a unique key based on the pool address without hardcoding anything at all:
Index: xs/APR/Pool/APR__Pool.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
retrieving revision 1.6
diff -u -r1.6 APR__Pool.h
--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
+++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:55:57 -0000
@@ -9,12 +9,15 @@
{
apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
apr_pool_t *newpool = NULL;
+ char *key;
+
(void)apr_pool_create(&newpool, parent);
/* mark the pool as being created via APR::Pool->new()
* see mpxs_apr_pool_DESTROY */
- apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
- apr_pool_cleanup_null, newpool);
+ key = apr_psprintf(newpool, "0x%lx", (unsigned long)newpool);
+ fprintf(stderr, "CREATE key: %s\n", key);
+ apr_pool_userdata_set((const void *)1, key, NULL, newpool);
return newpool;
}
@@ -119,7 +122,8 @@
void *flag;
apr_pool_t *p;
-
+ char *key;
+
/* APR::Pool::DESTROY
* we only want to call DESTROY on objects created by
* APR::Pool->new(), not objects representing native pools
@@ -128,7 +132,9 @@
p = mpxs_sv_object_deref(obj, apr_pool_t);
- apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
+ key = apr_psprintf(p, "0x%lx", (unsigned long)p);
+ fprintf(stderr, "DESTROY key: %s\n", key);
+ apr_pool_userdata_get(&flag, key, p);
if (flag) {
apr_pool_destroy(p);
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
[...]
> I'm not sure if this helps, but I tried instead of the
> above the following:
> =============================================================
> Index: xs/APR/Pool/APR__Pool.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
> retrieving revision 1.6
> diff -u -r1.6 APR__Pool.h
> --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
> +++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:50:44 -0000
> @@ -1,4 +1,5 @@
> #define MP_APR_POOL_NEW "APR::Pool::new"
> +#define MP_APR_SUBPOOL_NEW "APR::SubPool::new"
>
> /**
> * create a new pool or subpool
> @@ -9,11 +10,12 @@
> {
> apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
> apr_pool_t *newpool = NULL;
> + const char *key = parent ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
> (void)apr_pool_create(&newpool, parent);
>
> /* mark the pool as being created via APR::Pool->new()
> * see mpxs_apr_pool_DESTROY */
> - apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
> + apr_pool_userdata_set((const void *)1, key,
> apr_pool_cleanup_null, newpool);
>
> return newpool;
> ==================================================================
> (ie, leave the original key in mpxs_apr_pool_DESTROY as
> MP_APR_POOL_NEW alone) - in this case, the apr/pool tests
> pass, as did all the filter tests. However, running the
> tests all together resulted in a problem with the
> modules/include test crashing (but these passed
> if run just by themselves).
Heh, ok so you are cheating here, the above code won't destroy a sub-pool,
unless its parent pool is destroyed ;)
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Thu, 25 Sep 2003, Randy Kobes wrote:
> Might this have something to do with the comment in
> apr_pools.h:
[ ... ]
> in that the key must be unique for both pools and subpools?
> I tried the following:
> ===========================================================
> Index: xs/APR/Pool/APR__Pool.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
> retrieving revision 1.6
> diff -u -r1.6 APR__Pool.h
> --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
> +++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 04:56:59 -0000
> @@ -1,4 +1,5 @@
> #define MP_APR_POOL_NEW "APR::Pool::new"
> +#define MP_APR_SUBPOOL_NEW "APR::SubPool::new"
>
> /**
> * create a new pool or subpool
> @@ -9,11 +10,12 @@
> {
> apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
> apr_pool_t *newpool = NULL;
> + const char *key = parent ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
> (void)apr_pool_create(&newpool, parent);
>
> /* mark the pool as being created via APR::Pool->new()
> * see mpxs_apr_pool_DESTROY */
> - apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
> + apr_pool_userdata_set((const void *)1, key,
> apr_pool_cleanup_null, newpool);
>
> return newpool;
> @@ -119,6 +121,7 @@
>
> void *flag;
> apr_pool_t *p;
> + const char *key;
>
> /* APR::Pool::DESTROY
> * we only want to call DESTROY on objects created by
> @@ -127,8 +130,9 @@
> * apr_pool_destroy ($p->destroy) */
>
> p = mpxs_sv_object_deref(obj, apr_pool_t);
> + key = p ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
>
> - apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
> + apr_pool_userdata_get(&flag, key, p);
>
> if (flag) {
> apr_pool_destroy(p);
> ===============================================================
> which is intended to give a different key to a parent and
> to a subpool. Running
> perl -Mblib t/TEST t/api t/apr t/filter
> got some failures in apr/pool (subtests 6-13), but all
> the filter tests passed.
I'm not sure if this helps, but I tried instead of the
above the following:
=============================================================
Index: xs/APR/Pool/APR__Pool.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
retrieving revision 1.6
diff -u -r1.6 APR__Pool.h
--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
+++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 06:50:44 -0000
@@ -1,4 +1,5 @@
#define MP_APR_POOL_NEW "APR::Pool::new"
+#define MP_APR_SUBPOOL_NEW "APR::SubPool::new"
/**
* create a new pool or subpool
@@ -9,11 +10,12 @@
{
apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
apr_pool_t *newpool = NULL;
+ const char *key = parent ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
(void)apr_pool_create(&newpool, parent);
/* mark the pool as being created via APR::Pool->new()
* see mpxs_apr_pool_DESTROY */
- apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
+ apr_pool_userdata_set((const void *)1, key,
apr_pool_cleanup_null, newpool);
return newpool;
==================================================================
(ie, leave the original key in mpxs_apr_pool_DESTROY as
MP_APR_POOL_NEW alone) - in this case, the apr/pool tests
pass, as did all the filter tests. However, running the
tests all together resulted in a problem with the
modules/include test crashing (but these passed
if run just by themselves).
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Wed, 24 Sep 2003, Stas Bekman wrote:
> we disscussed this issue on the irc, we now enter the code
> freeze stage where we no longer commit any code and
> getting ready for a release candidate, the only
> outstanding issue we want to resolve is the sub-pools. I'm
> going to look at it now.
Might this have something to do with the comment in
apr_pools.h:
/**
* Set the data associated with the current pool
* @param data The user data associated with the pool.
* @param key The key to use for association
* @param cleanup The cleanup program to use to cleanup the data (NULL if none)
* @param pool The current pool
* @warning The data to be attached to the pool should have a life span
* at least as long as the pool it is being attached to.
*
* Users of APR must take EXTREME care when choosing a key to
* use for their data. It is possible to accidentally overwrite
* data by choosing a key that another part of the program is using
* It is advised that steps are taken to ensure that a unique
* key is used at all times.
* @bug Specify how to ensure this uniqueness!
*/
APR_DECLARE(apr_status_t) apr_pool_userdata_set(
const void *data,
const char *key,
apr_status_t (*cleanup)(void *),
in that the key must be unique for both pools and subpools?
I tried the following:
===========================================================
Index: xs/APR/Pool/APR__Pool.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
retrieving revision 1.6
diff -u -r1.6 APR__Pool.h
--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
+++ xs/APR/Pool/APR__Pool.h 25 Sep 2003 04:56:59 -0000
@@ -1,4 +1,5 @@
#define MP_APR_POOL_NEW "APR::Pool::new"
+#define MP_APR_SUBPOOL_NEW "APR::SubPool::new"
/**
* create a new pool or subpool
@@ -9,11 +10,12 @@
{
apr_pool_t *parent = mpxs_sv_object_deref(obj, apr_pool_t);
apr_pool_t *newpool = NULL;
+ const char *key = parent ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
(void)apr_pool_create(&newpool, parent);
/* mark the pool as being created via APR::Pool->new()
* see mpxs_apr_pool_DESTROY */
- apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
+ apr_pool_userdata_set((const void *)1, key,
apr_pool_cleanup_null, newpool);
return newpool;
@@ -119,6 +121,7 @@
void *flag;
apr_pool_t *p;
+ const char *key;
/* APR::Pool::DESTROY
* we only want to call DESTROY on objects created by
@@ -127,8 +130,9 @@
* apr_pool_destroy ($p->destroy) */
p = mpxs_sv_object_deref(obj, apr_pool_t);
+ key = p ? MP_APR_SUBPOOL_NEW : MP_APR_POOL_NEW;
- apr_pool_userdata_get(&flag, MP_APR_POOL_NEW, p);
+ apr_pool_userdata_get(&flag, key, p);
if (flag) {
apr_pool_destroy(p);
===============================================================
which is intended to give a different key to a parent and
to a subpool. Running
perl -Mblib t/TEST t/api t/apr t/filter
got some failures in apr/pool (subtests 6-13), but all
the filter tests passed.
I tried changing
=================================================================
Index: t/response/TestAPR/pool.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/response/TestAPR/pool.pm,v
retrieving revision 1.5
diff -u -r1.5 pool.pm
--- t/response/TestAPR/pool.pm 9 Sep 2003 17:22:39 -0000 1.5
+++ t/response/TestAPR/pool.pm 25 Sep 2003 04:59:00 -0000
@@ -44,6 +44,7 @@
$subp->cleanup_register(\&set_cleanup, [$r, 'child']);
# should destroy the subpool too
+ $subp->destroy;
$p->destroy;
my @notes = $r->notes->get('cleanup');
================================================================
to see if it'd help with the apr/pool tests, but it didn't.
But this is probably because what I did to APR__Pool.h
wasn't the right thing in general; in particular, if this
is on the right track that the keys should be unique, then
one would want a unique key for all subpools.
Steve, you reported earlier that there were some further
crashes in some of the other tests (modules/include, I
think). The above diff to APR__Pool.h also seems to help
there.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
we disscussed this issue on the irc, we now enter the code freeze stage where
we no longer commit any code and getting ready for a release candidate, the
only outstanding issue we want to resolve is the sub-pools. I'm going to look
at it 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: filter/both_str_con_add on win32
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Remember, release is not about the tests, it's about releasing good
> stuff.
agreed. see below.
> If you skip the tests but people start using this broken
> functionality they will report bugs. Why wasting time on that.
maybe somebody will produce a patch and fix it for us ;)
>
> Let's get the stable code out, and then fix that new thing and get it
> out in the next release.
I disagree with your assessment. if you can prove that removing only the
DESTROY logic but _keeping_ the existing tests (and replacing implicit
DESTROY calls with $p->destroy) passes, then I would agree with you.
from steve's recent email:
> Basically, this broke:
>
> my $p = APR::Pool->new;
> my $subp = $p->new;
> $p->destroy;
>
> but this worked:
>
> my $p = APR::Pool->new;
> $p->destroy;
if removing the DESTROY implementation causes the first example to pass,
then I've obviously done something wrong and the code should get nixed (or
fixed if we can figure it out). if it still fails, though, then what you
have is a bug elsewhere - removing the subpool tests only mask a deeper
problem, and don't keep users from using the existing API to generate segfaults.
so, let's figure out whether it is really the DESTROY logic or a problem
with pools in and of themselves before we remove functionality. and the
tests ought to stay in either case - otherwise you're just hiding problems
that users will stumble upon anyway through normal excercise of the API.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
[...]
> personally, I'd rather not remove anything in the test suite - the tests
> show exactly how it _ought_ to behave, and it seems to to the right
> thing for non Win32 systems.
>
> I would prefer just to skip the tests on Win32 and keep the test (and
> underlying implementation) around.
I was running SMOKE and I was getting random segfaults with that patch in the
pool and *other* tests as well. Since I couldn't reproduce those at will, I
wasn't posting about it. Now with that patch reverted SMOKE is clean, so
skipping in only win32 is not the solution, as I had problems on linux too.
Remember, release is not about the tests, it's about releasing good stuff. If
you skip the tests but people start using this broken functionality they will
report bugs. Why wasting time on that.
Let's get the stable code out, and then fix that new thing and get it out in
the next 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: filter/both_str_con_add on win32
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> Did you see my comment about removing the subpool part from
> t/t/response/TestAPR/pool.pm "fixing" it?
>
> (http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106424373602910&w=2)
>
> Basically, this broke:
>
> my $p = APR::Pool->new;
> my $subp = $p->new;
> $p->destroy;
>
> but this worked:
>
> my $p = APR::Pool->new;
> $p->destroy;
>
> Dunno if there's anything in that.
I'm really sorry I hadn't been following this thread more closely - I caught
the start and figured it was a Win32 thing that I couldn't help with...
at any rate, I noticed a few interesting things when I was implementing
DESTROY, namely that get_parent() and is_ancestor() did not report back as
expected. that is,
ok($p == $subp->get_parent)
and (more importantly)
ok($subp->is_ancestor($p))
both failed.
while the first I could chalk up as a perl oddity (same C pointer with a
different perl address?), the second lead me to believe that something is
amuck in the pool creation code. from the look of the mod_perl interface, I
suspect it's not specific to mod_perl.
personally, I'd rather not remove anything in the test suite - the tests
show exactly how it _ought_ to behave, and it seems to to the right thing
for non Win32 systems.
I would prefer just to skip the tests on Win32 and keep the test (and
underlying implementation) around.
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
>>> Presumably you don't really want to retract Geoff's patch, though?
>>> I'll be happy to test any ammended version of it that you can come up
>>> with if you like.
>>
>>
>>
>> Probably we will do that temporary if we go with the release shortly,
>> unless we figure that out soonish. The problem is that it's really
>> hard to debug virtually, I wish I could reproduce the problem on my
>> side. It'd make my life much easier ;)
>
>
> Did you see my comment about removing the subpool part from
> t/t/response/TestAPR/pool.pm "fixing" it?
>
> (http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106424373602910&w=2)
>
> Basically, this broke:
>
> my $p = APR::Pool->new;
> my $subp = $p->new;
> $p->destroy;
>
> but this worked:
>
> my $p = APR::Pool->new;
> $p->destroy;
>
> Dunno if there's anything in that.
Sure I did, I just didn't start looking at it, as I didn't have a reproducable
test case, besides random segfaults :( I will try to debug this shortly, but I
want to get the release candidate out first.
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
> [...]
>
>>> If not, does reverting this patch makes the problem go away?
>>> http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=106312839005459&w=2
>>>
>>>
>>> If so, does it go away completely, or only when this test is run?
>>
>>
>>
>> Yes - that fixes it completely!
>
>
> Perfect.
>
>> All four of the short test sequences in my previous mail now pass,
>> and, in fact with your patch for filter/in_str_consume.t in place as
>> well, I now have the *entire* testsuite running successfully!
>
>
> including ModPerl-Registry?
Yes.
>
>
>> Presumably you don't really want to retract Geoff's patch, though?
>> I'll be happy to test any ammended version of it that you can come up
>> with if you like.
>
>
> Probably we will do that temporary if we go with the release shortly,
> unless we figure that out soonish. The problem is that it's really
> hard to debug virtually, I wish I could reproduce the problem on my
> side. It'd make my life much easier ;)
Did you see my comment about removing the subpool part from
t/t/response/TestAPR/pool.pm "fixing" it?
(http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106424373602910&w=2)
Basically, this broke:
my $p = APR::Pool->new;
my $subp = $p->new;
$p->destroy;
but this worked:
my $p = APR::Pool->new;
$p->destroy;
Dunno if there's anything in that.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
[...]
>> If not, does reverting this patch makes the problem go away?
>> http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=106312839005459&w=2
>>
>> If so, does it go away completely, or only when this test is run?
>
>
> Yes - that fixes it completely!
Perfect.
> All four of the short test sequences in my previous mail now pass, and,
> in fact with your patch for filter/in_str_consume.t in place as well, I
> now have the *entire* testsuite running successfully!
including ModPerl-Registry?
> Presumably you don't really want to retract Geoff's patch, though? I'll
> be happy to test any ammended version of it that you can come up with if
> you like.
Probably we will do that temporary if we go with the release shortly, unless
we figure that out soonish. The problem is that it's really hard to debug
virtually, I wish I could reproduce the problem on my side. It'd make my life
much easier ;)
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
> Let's first look at the apr/pool issue, since it's a new stuff
> recently added by Geoff.
>
> Does this make any difference?
>
> Index: xs/APR/Pool/APR__Pool.h
> ===================================================================
> RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
> retrieving revision 1.6
> diff -u -r1.6 APR__Pool.h
> --- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
> +++ xs/APR/Pool/APR__Pool.h 23 Sep 2003 08:53:57 -0000
> @@ -14,7 +14,7 @@
> /* mark the pool as being created via APR::Pool->new()
> * see mpxs_apr_pool_DESTROY */
> apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
> - apr_pool_cleanup_null, newpool);
> + NULL, newpool);
>
> return newpool;
> }
No - even the shortest failing test sequence still fails with that.
>
>
> If not, does reverting this patch makes the problem go away?
> http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=106312839005459&w=2
>
> If so, does it go away completely, or only when this test is run?
Yes - that fixes it completely!
All four of the short test sequences in my previous mail now pass, and,
in fact with your patch for filter/in_str_consume.t in place as well, I
now have the *entire* testsuite running successfully!
Presumably you don't really want to retract Geoff's patch, though? I'll
be happy to test any ammended version of it that you can come up with if
you like.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
Let's first look at the apr/pool issue, since it's a new stuff recently added
by Geoff.
Does this make any difference?
Index: xs/APR/Pool/APR__Pool.h
===================================================================
RCS file: /home/cvs/modperl-2.0/xs/APR/Pool/APR__Pool.h,v
retrieving revision 1.6
diff -u -r1.6 APR__Pool.h
--- xs/APR/Pool/APR__Pool.h 9 Sep 2003 17:22:39 -0000 1.6
+++ xs/APR/Pool/APR__Pool.h 23 Sep 2003 08:53:57 -0000
@@ -14,7 +14,7 @@
/* mark the pool as being created via APR::Pool->new()
* see mpxs_apr_pool_DESTROY */
apr_pool_userdata_set((const void *)1, MP_APR_POOL_NEW,
- apr_pool_cleanup_null, newpool);
+ NULL, newpool);
return newpool;
}
If not, does reverting this patch makes the problem go away?
http://marc.theaimsgroup.com/?l=apache-modperl-cvs&m=106312839005459&w=2
If so, does it go away completely, or only when this test is run?
__________________________________________________________________
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: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Closer still:
>
> - perl t/TEST t/api/lookup_uri t/api/rflush t/apr/pool
> t/filter/both_str_con_add
> fails
>
> - perl t/TEST t/api/lookup_uri t/api/rflush t/filter/both_str_con_add
> passes
>
> - perl t/TEST t/api/lookup_uri t/apr/pool t/filter/both_str_con_add
> fails
>
> - perl t/TEST t/api/rflush t/apr/pool t/filter/both_str_con_add
> passes
>
> Concentrating on the shortest sequence that still fails (lookup_uri +
> pool + both_str_con_add), I find that the attached patch (which
> truncates the t/apr/pool tests from 13 to just 2) makes this test
> sequence succeed.
>
> Most interestingly, if you move the "return Apache::OK;" that I've
> inserted into pool.pm down one more line, to just *after* the
> "$p->destroy();", then the test sequence fails again.
>
> Perhaps there is a problem with APR::Pool->destroy()?
More tidbits that might help someone sort this out:
1. If I further hack pool.pm to remove all reference to $subp, i.e.
delete these lines:
my $subp = $p->new;
ok $subp->isa('APR::Pool');
$subp->cleanup_register(\&set_cleanup, [$r, 'child']);
(so now there is only 1 test left!) then it works *with* the
$p->destroy() call left in. That call is commented "# should destroy
the subpool too"; it seems that it destroys more than just the subpool ;-)
2. Having the ability to make the failing test sequence work allows me
to compare what's going on in modperl_filter_new() in a run that fails
with a run that works. Here's what I find:
On the failed run (with the destroy() call) I have these values before
and after the apr_pcalloc() call:
VARIABLE BEFORE AFTER
f 0x008e23c8 unchanged
f->ctx 0x008e23b8 NULL
f->r NULL unchanged - still NULL
f->c 0x008e1db8 NULL
f->c->pool 0x008e1cb8 N/A since f->c is NULL
filter 0x01d175dc 0x008e1cb8 (*)
filter->f 0x34302e00 NULL
filter->pool 0x016e484c NULL
p 0x008e1cb8 unchanged
The interesting thing there is marked (*): It seems that what
apr_pcalloc() has returned (which gets assigned to filter) is the
address held in p -- i.e. the address that was passed into it. I would
(naively) expect apr_pcalloc() to have zeroed the memory at the address
that it returns, and, indeed, everything "under" filter is NULL or 0.
However, p came from f->c->pool, so zeroing that could potentially
affect things "under" f, and sure enough f->ctx and f->c do get changed
to NULL (causing the crash).
By contrast, on the successful run (without the destroy() call) I have this:
VARIABLE BEFORE AFTER
f 0x008e23c8 unchanged
f->ctx 0x008e23b8 unchanged
f->r NULL unchanged
f->c 0x008e1db8 unchanged
f->c->pool 0x008e1cb8 unchanged
filter 0x01f0f704 0x033692e8 (*)
filter->f 0x34302e00 NULL
filter->pool 0xffffffff NULL
p 0x008e1cb8 unchanged
This time, the return value from apr_pcalloc(), assigned to filter, is
an address that we haven't seen before. Again, everything "under"
filter is NULL or 0, but this time nothing "under" f has been changed at
all.
It looks like the problem is not so much that f->ctx et al gets zeroed,
as that apr_pcalloc() returns something "under" f (namely, f->c->pool)
as the zeroed memory, rather than a "new" area of memory. The fact that
f->ctx et al gets zeroed is just a consequence of that.
Was it at all relevant that on the successful run filter->pool was
0xffffffff to start with? That value wouldn't normally just crop up by
accident!
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Homing in further:
>
> - perl t/TEST t/api t/apr t/filter/both_str_con_add
> causes filter/both_str_con_add to fail
>
> - the same, but skipping api/rflush
> allows filter/both_str_con_add to succeed
>
> - perl t/TEST t/api/rflush t/apr t/filter/both_str_con_add
> *doesn't* cause filter/both_str_con_add to fail again!
>
> - perl t/TEST t/api/lookup_uri t/api/rflush t/apr
> t/filter/both_str_con_add
> does now cause filter/both_str_con_add to fail again.
>
> So it is a combination of api/lookup_uri+api/rflush (with apr) that
> breaks filter/both_str_con_add. Skipping either one of those two api/
> tests allows filter/both_str_con_add to succeed.
Closer still:
- perl t/TEST t/api/lookup_uri t/api/rflush t/apr/pool
t/filter/both_str_con_add
fails
- perl t/TEST t/api/lookup_uri t/api/rflush t/filter/both_str_con_add
passes
- perl t/TEST t/api/lookup_uri t/apr/pool t/filter/both_str_con_add
fails
- perl t/TEST t/api/rflush t/apr/pool t/filter/both_str_con_add
passes
Concentrating on the shortest sequence that still fails (lookup_uri +
pool + both_str_con_add), I find that the attached patch (which
truncates the t/apr/pool tests from 13 to just 2) makes this test
sequence succeed.
Most interestingly, if you move the "return Apache::OK;" that I've
inserted into pool.pm down one more line, to just *after* the
"$p->destroy();", then the test sequence fails again.
Perhaps there is a problem with APR::Pool->destroy()?
- Steve
Re: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>On Fri, 19 Sep 2003, Steve Hay wrote:
>
>
>
>>Stas Bekman wrote:
>>
>>
>>
>>>Steve Hay wrote:
>>>
>>>
>>>
>>>>I have found this, though:
>>>>
>>>>Recall that running just the "filter" tests (as "perl t/TEST
>>>>t/filter") makes it work (except for the in_str_consume test that
>>>>sadly still fails).
>>>>
>>>>Well, running "perl t/TEST t/api t/filter" also succeeds, as does
>>>>"perl t/TEST t/apr t/filter" (except for apr/perlio, of course), but
>>>>"perl t/TEST t/api t/apr t/filter" makes the first filter test --
>>>>both_str_con_add.t -- crash Apache.
>>>>
>>>>
>
>I think the relevant test here is api/rflush.t - skipping
>it, and running all other api/ and apr/ tests, allows the
>filter tests to run and, except for the occasional failure
>of in_str_consume, all pass.
>
>
Homing in further:
- perl t/TEST t/api t/apr t/filter/both_str_con_add
causes filter/both_str_con_add to fail
- the same, but skipping api/rflush
allows filter/both_str_con_add to succeed
- perl t/TEST t/api/rflush t/apr t/filter/both_str_con_add
*doesn't* cause filter/both_str_con_add to fail again!
- perl t/TEST t/api/lookup_uri t/api/rflush t/apr t/filter/both_str_con_add
does now cause filter/both_str_con_add to fail again.
So it is a combination of api/lookup_uri+api/rflush (with apr) that
breaks filter/both_str_con_add. Skipping either one of those two api/
tests allows filter/both_str_con_add to succeed.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 19 Sep 2003, Steve Hay wrote:
> Stas Bekman wrote:
>
> > Steve Hay wrote:
> >
> >> I have found this, though:
> >>
> >> Recall that running just the "filter" tests (as "perl t/TEST
> >> t/filter") makes it work (except for the in_str_consume test that
> >> sadly still fails).
> >>
> >> Well, running "perl t/TEST t/api t/filter" also succeeds, as does
> >> "perl t/TEST t/apr t/filter" (except for apr/perlio, of course), but
> >> "perl t/TEST t/api t/apr t/filter" makes the first filter test --
> >> both_str_con_add.t -- crash Apache.
I think the relevant test here is api/rflush.t - skipping
it, and running all other api/ and apr/ tests, allows the
filter tests to run and, except for the occasional failure
of in_str_consume, all pass.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
>> I have found this, though:
>>
>> Recall that running just the "filter" tests (as "perl t/TEST
>> t/filter") makes it work (except for the in_str_consume test that
>> sadly still fails).
>>
>> Well, running "perl t/TEST t/api t/filter" also succeeds, as does
>> "perl t/TEST t/apr t/filter" (except for apr/perlio, of course), but
>> "perl t/TEST t/api t/apr t/filter" makes the first filter test --
>> both_str_con_add.t -- crash Apache.
>
>
> You need to get t/SMOKE to work which will help you to find the guilty
> test which when run before filter/both_str_con_add causes the latter
> to fail. It's designed exactly for this purpose, besides its side
> effects which are useful for normal smoking.
>
> It's much easier to debug when you have (hopefully) only 1 test to run
> before it fails (it's quite possible that there is a specific
> combination of running tests that lead to the problem). It'll also
> help me to understand what could be the cause, since even though you
> are very helpful at this remote debugging session, it's quite hard for
> me to be helpful to nail this problem down, without knowing where to
> look.
I'll look forward to Randy's Win32-savvy t/SMOKE, then...
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: filter/both_str_con_add on win32
Posted by Stas Bekman <st...@stason.org>.
[fixing the subject]
Steve Hay wrote:
>> Does the problem persist if you apply this patch (and re-run t/TEST
>> -conf)? Most likely it'll go away, but this is not the right solution,
>> just a sanity check.
>
>
> I tried your patch (and test reconfiguration) too, but it doesn't make
> any difference -- it still crashes in the same place for the same reason.
Good, that was an important check to remove the guilt potential from the
add_filter functions. So the cause is elsewhere.
> I have found this, though:
>
> Recall that running just the "filter" tests (as "perl t/TEST t/filter")
> makes it work (except for the in_str_consume test that sadly still fails).
>
> Well, running "perl t/TEST t/api t/filter" also succeeds, as does "perl
> t/TEST t/apr t/filter" (except for apr/perlio, of course), but "perl
> t/TEST t/api t/apr t/filter" makes the first filter test --
> both_str_con_add.t -- crash Apache.
You need to get t/SMOKE to work which will help you to find the guilty test
which when run before filter/both_str_con_add causes the latter to fail. It's
designed exactly for this purpose, besides its side effects which are useful
for normal smoking.
It's much easier to debug when you have (hopefully) only 1 test to run before
it fails (it's quite possible that there is a specific combination of running
tests that lead to the problem). It'll also help me to understand what could
be the cause, since even though you are very helpful at this remote debugging
session, it's quite hard for me to be helpful to nail this problem down,
without knowing where to look.
__________________________________________________________________
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] filter tests on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Steve Hay wrote:
>
> we are talking about segfault in filter/both_str_con_add on win32.
>
>>> The modperl_output_filter_handler in code goes:
>>>
>>> if (((modperl_filter_ctx_t *)f->ctx)->sent_eos) {
>>> MP_TRACE_f(MP_FUNC,
>>> MP_FILTER_NAME_FORMAT
>>> "write_out: EOS was already sent, "
>>> "passing through the brigade\n",
>>> MP_FILTER_NAME(f));
>>> return ap_pass_brigade(f->next, bb);
>>> }
>>> else {
>>> filter = modperl_filter_new(f, bb, MP_OUTPUT_FILTER_MODE,
>>> 0, 0, 0);
>>> status = modperl_run_filter(filter);
>>> }
>>>
>>> So ((modperl_filter_ctx_t *)f->ctx) is non-NULL, when it checks for
>>> sent_eos, right? Otherwise it'll segfault right there. Then it goes
>>> through modperl_filter_new which simply stashes f into filter->f.
>>> When it comes back (modperl_filter_ctx_t *)filter->f->ctx) should be
>>> non-null as well. Is it?
>>
>>
>>
>> I've put a breakpoint on line 763 (the modperl_filter_new() call) of
>> modperl_filter.c, and I attach to the Apache process when the
>> both_str_con_add.t test starts (I put a sleep 30; into it to give me
>> time to catch it.)
>>
>> When the debugger first stops on the breakpoint I have:
>>
>> f = 0x008e23c8
>> f->ctx = 0x008e23c8
>> filter = 0x0000000c [garbage]
>>
>> After the modperl_filter_new() call f and f->ctx are unchanged, but
>> filter is now 0x033552b0 and it has a new filter->f member which is
>> 0x008e23c8.
>>
>> So far so good, and sure enough the modperl_run_filter() call goes
>> OK: filter->f->ctx is 0x008e23b8, handler gets set to 0x008e23a0, and
>> the function returns 14716076.
>
Oops. A little slip there - it actually returns 0 on this first run.
That garbage number was the value before the call.
>>
>>
>> I then let the debugger continue and it soon stops again on the
>> breakpoint. Initially the values are all as before:
>>
>> f = 0x008e23c8
>> f->ctx = 0x008e23c8
>> filter = 0x0000000c [garbage]
>>
>> But now after the modperl_filter_new() call only f is unchanged:
>> f->ctx is changed to 0x00000000 this time, and filter to 0x008e1cb8
>> (with a filter->f member of 0x008e23c8).
>>
>> So this time, of course, modperl_run_filter() fails when trying to
>> set handler because filter->f->ctx is NULL.
>>
>> I re-ran everything and this time stepped into modperl_filter_new()
>> on the second call to it. It seems that the apr_pcalloc() call on
>> line 228 of modperl_filter.c is what changes f->ctx from 0x008e23c8
>> to 0x00000000.
>
>
> So did you look at the value of f->ctx before and after the
> apr_pcalloc() call on line 228 and that's when it has changed?
Correct.
> are you sure that your compiler reports the line number correctly?
> Sometimes with an optimized code it may report wrong lines. e.g. I'd
> suggest to change:
> modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
>
> to:
>
> modperl_filter_t *filter;
> filter = apr_pcalloc(p, sizeof(*filter));
I don't get the feeling that I'm on the "wrong line", but who knows for
sure? I split the apr_pcalloc() call into two lines as you suggested,
and the debugger shows that it is the second of those two lines, i.e.
the apr_pcalloc() call, that sets f->ctx to NULL.
>
>
>> Does this help at all?
>
>
> Certainly. It is possible that the memory pool is messed up. If you
> change apr_pcalloc with apr_palloc does it still happen (if it
> doesn't it will crash elsewhere, since that just proves that
> apr_pcalloc allocates the already allocated memory). the next step
> would be to enable apr_pool debug tracing :(
I tried apr_palloc() instead, but I can hardly get anything running like
that! It all just seems to lock up.
>
>
> Does the problem persist if you apply this patch (and re-run t/TEST
> -conf)? Most likely it'll go away, but this is not the right solution,
> just a sanity check.
I tried your patch (and test reconfiguration) too, but it doesn't make
any difference -- it still crashes in the same place for the same reason.
I have found this, though:
Recall that running just the "filter" tests (as "perl t/TEST t/filter")
makes it work (except for the in_str_consume test that sadly still fails).
Well, running "perl t/TEST t/api t/filter" also succeeds, as does "perl
t/TEST t/apr t/filter" (except for apr/perlio, of course), but "perl
t/TEST t/api t/apr t/filter" makes the first filter test --
both_str_con_add.t -- crash Apache.
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
we are talking about segfault in filter/both_str_con_add on win32.
>> The modperl_output_filter_handler in code goes:
>>
>> if (((modperl_filter_ctx_t *)f->ctx)->sent_eos) {
>> MP_TRACE_f(MP_FUNC,
>> MP_FILTER_NAME_FORMAT
>> "write_out: EOS was already sent, "
>> "passing through the brigade\n",
>> MP_FILTER_NAME(f));
>> return ap_pass_brigade(f->next, bb);
>> }
>> else {
>> filter = modperl_filter_new(f, bb, MP_OUTPUT_FILTER_MODE,
>> 0, 0, 0);
>> status = modperl_run_filter(filter);
>> }
>>
>> So ((modperl_filter_ctx_t *)f->ctx) is non-NULL, when it checks for
>> sent_eos, right? Otherwise it'll segfault right there. Then it goes
>> through modperl_filter_new which simply stashes f into filter->f. When
>> it comes back (modperl_filter_ctx_t *)filter->f->ctx) should be
>> non-null as well. Is it?
>
>
> I've put a breakpoint on line 763 (the modperl_filter_new() call) of
> modperl_filter.c, and I attach to the Apache process when the
> both_str_con_add.t test starts (I put a sleep 30; into it to give me
> time to catch it.)
>
> When the debugger first stops on the breakpoint I have:
>
> f = 0x008e23c8
> f->ctx = 0x008e23c8
> filter = 0x0000000c [garbage]
>
> After the modperl_filter_new() call f and f->ctx are unchanged, but
> filter is now 0x033552b0 and it has a new filter->f member which is
> 0x008e23c8.
>
> So far so good, and sure enough the modperl_run_filter() call goes OK:
> filter->f->ctx is 0x008e23b8, handler gets set to 0x008e23a0, and the
> function returns 14716076.
>
> I then let the debugger continue and it soon stops again on the
> breakpoint. Initially the values are all as before:
>
> f = 0x008e23c8
> f->ctx = 0x008e23c8
> filter = 0x0000000c [garbage]
>
> But now after the modperl_filter_new() call only f is unchanged: f->ctx
> is changed to 0x00000000 this time, and filter to 0x008e1cb8 (with a
> filter->f member of 0x008e23c8).
>
> So this time, of course, modperl_run_filter() fails when trying to set
> handler because filter->f->ctx is NULL.
>
> I re-ran everything and this time stepped into modperl_filter_new() on
> the second call to it. It seems that the apr_pcalloc() call on line 228
> of modperl_filter.c is what changes f->ctx from 0x008e23c8 to 0x00000000.
So did you look at the value of f->ctx before and after the apr_pcalloc() call
on line 228 and that's when it has changed? are you sure that your compiler
reports the line number correctly? Sometimes with an optimized code it may
report wrong lines. e.g. I'd suggest to change:
modperl_filter_t *filter = apr_pcalloc(p, sizeof(*filter));
to:
modperl_filter_t *filter;
filter = apr_pcalloc(p, sizeof(*filter));
> Does this help at all?
Certainly. It is possible that the memory pool is messed up. If you change
apr_pcalloc with apr_palloc does it still happen (if it doesn't it will crash
elsewhere, since that just proves that apr_pcalloc allocates the already
allocated memory). the next step would be to enable apr_pool debug tracing :(
Does the problem persist if you apply this patch (and re-run t/TEST -conf)?
Most likely it'll go away, but this is not the right solution, just a sanity
check.
Index: t/filter/TestFilter/both_str_con_add.pm
===================================================================
RCS file: /home/cvs/modperl-2.0/t/filter/TestFilter/both_str_con_add.pm,v
retrieving revision 1.6
diff -u -r1.6 both_str_con_add.pm
--- t/filter/TestFilter/both_str_con_add.pm 11 May 2003 23:51:11 -0000
1.6
+++ t/filter/TestFilter/both_str_con_add.pm 18 Sep 2003 09:28:38 -0000
@@ -7,11 +7,12 @@
use warnings FATAL => 'all';
use Apache::Connection ();
-use Apache::Filter ();
use APR::Bucket ();
use APR::Brigade ();
use APR::Util ();
+use base qw(Apache::Filter);
+
use APR::Const -compile => qw(SUCCESS EOF);
use Apache::Const -compile => qw(OK MODE_GETLINE);
@@ -20,12 +21,12 @@
sub pre_connection {
my Apache::Connection $c = shift;
- $c->add_input_filter(\&in_filter);
- $c->add_output_filter(\&out_filter);
+# $c->add_input_filter(\&in_filter);
+# $c->add_output_filter(\&out_filter);
return Apache::OK;
}
-sub in_filter {
+sub in_filter : FilterConnectionHandler {
my $filter = shift;
while ($filter->read(my $buffer, 1024)) {
@@ -38,7 +39,7 @@
Apache::OK;
}
-sub out_filter {
+sub out_filter : FilterConnectionHandler {
my $filter = shift;
while ($filter->read(my $buffer, 1024)) {
@@ -81,6 +82,8 @@
<VirtualHost TestFilter::both_str_con_add>
PerlModule TestFilter::both_str_con_add
PerlPreConnectionHandler TestFilter::both_str_con_add::pre_connection
+ PerlInputFilterHandler TestFilter::both_str_con_add::in_filter
+ PerlOutputFilterHandler TestFilter::both_str_con_add::out_filter
PerlProcessConnectionHandler TestFilter::both_str_con_add
</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] filter tests on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Stas Bekman wrote:
> Randy Kobes wrote:
>
>> Unfortunately, I still get the same crash when run this way.
>
Me too.
>>
>> The trace is the same as what I posted earlier - what seems
>> to happen is that, within src/modules/perl/modperl_filter.c,
>>
>> - in modperl_output_filter_handler,
>> filter = modperl_filter_new(...);
>> is called, and the debugger reports some non-null value
>> for "filter".
>> - this then this gets passed to
>> status = modperl_run_filter(filter);
>> - within modperl_run_filter a handler is created via
>> handler = ((modperl_filter_ctx_t *)filter->f->ctx)->handler;
>> but the debugger reports that filter->f->ctx is null.
>
>
> The modperl_output_filter_handler in code goes:
>
> if (((modperl_filter_ctx_t *)f->ctx)->sent_eos) {
> MP_TRACE_f(MP_FUNC,
> MP_FILTER_NAME_FORMAT
> "write_out: EOS was already sent, "
> "passing through the brigade\n",
> MP_FILTER_NAME(f));
> return ap_pass_brigade(f->next, bb);
> }
> else {
> filter = modperl_filter_new(f, bb, MP_OUTPUT_FILTER_MODE,
> 0, 0, 0);
> status = modperl_run_filter(filter);
> }
>
> So ((modperl_filter_ctx_t *)f->ctx) is non-NULL, when it checks for
> sent_eos, right? Otherwise it'll segfault right there. Then it goes
> through modperl_filter_new which simply stashes f into filter->f. When
> it comes back (modperl_filter_ctx_t *)filter->f->ctx) should be
> non-null as well. Is it?
I've put a breakpoint on line 763 (the modperl_filter_new() call) of
modperl_filter.c, and I attach to the Apache process when the
both_str_con_add.t test starts (I put a sleep 30; into it to give me
time to catch it.)
When the debugger first stops on the breakpoint I have:
f = 0x008e23c8
f->ctx = 0x008e23c8
filter = 0x0000000c [garbage]
After the modperl_filter_new() call f and f->ctx are unchanged, but
filter is now 0x033552b0 and it has a new filter->f member which is
0x008e23c8.
So far so good, and sure enough the modperl_run_filter() call goes OK:
filter->f->ctx is 0x008e23b8, handler gets set to 0x008e23a0, and the
function returns 14716076.
I then let the debugger continue and it soon stops again on the
breakpoint. Initially the values are all as before:
f = 0x008e23c8
f->ctx = 0x008e23c8
filter = 0x0000000c [garbage]
But now after the modperl_filter_new() call only f is unchanged: f->ctx
is changed to 0x00000000 this time, and filter to 0x008e1cb8 (with a
filter->f member of 0x008e23c8).
So this time, of course, modperl_run_filter() fails when trying to set
handler because filter->f->ctx is NULL.
I re-ran everything and this time stepped into modperl_filter_new() on
the second call to it. It seems that the apr_pcalloc() call on line 228
of modperl_filter.c is what changes f->ctx from 0x008e23c8 to 0x00000000.
Does this help at all?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> Unfortunately, I still get the same crash when run this way.
> The trace is the same as what I posted earlier - what seems
> to happen is that, within src/modules/perl/modperl_filter.c,
>
> - in modperl_output_filter_handler,
> filter = modperl_filter_new(...);
> is called, and the debugger reports some non-null value
> for "filter".
> - this then this gets passed to
> status = modperl_run_filter(filter);
> - within modperl_run_filter a handler is created via
> handler = ((modperl_filter_ctx_t *)filter->f->ctx)->handler;
> but the debugger reports that filter->f->ctx is null.
The modperl_output_filter_handler in code goes:
if (((modperl_filter_ctx_t *)f->ctx)->sent_eos) {
MP_TRACE_f(MP_FUNC,
MP_FILTER_NAME_FORMAT
"write_out: EOS was already sent, "
"passing through the brigade\n",
MP_FILTER_NAME(f));
return ap_pass_brigade(f->next, bb);
}
else {
filter = modperl_filter_new(f, bb, MP_OUTPUT_FILTER_MODE,
0, 0, 0);
status = modperl_run_filter(filter);
}
So ((modperl_filter_ctx_t *)f->ctx) is non-NULL, when it checks for sent_eos,
right? Otherwise it'll segfault right there. Then it goes through
modperl_filter_new which simply stashes f into filter->f. When it comes back
(modperl_filter_ctx_t *)filter->f->ctx) should be non-null as well. Is 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: [mp2] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 16 Sep 2003, Stas Bekman wrote:
> Steve Hay wrote:
> > Re-running the tests as "perl t/TEST -verbose t/filter" fixes everything
> > except for filter/in_str_consume.t test 1, which still fails for me
> > (even with perl-5.8.1).
>
> that means that some previous tests affect the filter
> tests. t/SMOKE is good at finding the shortest sequence of
> tests that lead to the failure.
>
> But I'm a bit lost in the amount of mixed reports. Can you
> please report the filter/in_str_consume.t in a separate
> email/thread? Thanks.
>
> > What's that all about, then?
> >
> > Stas: In a previous mail you said, "I suspect that the problem has
> > surfaced after I have changed the number of running servers from one to
> > two to allow the proxy work. What happens if you make the proxy filter
> > skip and run the tests with only one server available? I bet they will
> > all work." Could I have that again in English please? What do you want
> > me to try?
>
> Sorry, that means, making that test skip as in the patch
> below. And then run:
>
> t/TEST -conf -maxclients 1
> t/TEST
Unfortunately, I still get the same crash when run this way.
The trace is the same as what I posted earlier - what seems
to happen is that, within src/modules/perl/modperl_filter.c,
- in modperl_output_filter_handler,
filter = modperl_filter_new(...);
is called, and the debugger reports some non-null value
for "filter".
- this then this gets passed to
status = modperl_run_filter(filter);
- within modperl_run_filter a handler is created via
handler = ((modperl_filter_ctx_t *)filter->f->ctx)->handler;
but the debugger reports that filter->f->ctx is null.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Randy Kobes wrote:
>
>>> produce, but not in all cases.
>>>
>>>
>>>
>>>> Anyway, here's a trace, this time with the Perl symbols:
>>>>
>>>
>>> does it mean that you get a segfault?
>>>
>>
>>
>> The Windows equivalent, yes ... The message that comes up
>> is an access violation in mod_perl.so.
>>
>>
> Now that I've got ap2+mp2 running with perl-5.8.1, I get the same result
> as Randy running the test suite: It gets as far as:
>
> filter\both_str_con_add........ok 2/4
>
> and then crashes.
>
> Then line it crashed at was this:
>
> modperl_handler_t *handler =
> ((modperl_filter_ctx_t *)filter->f->ctx)->handler;
>
> and I notice that "filter->f->ctx" has the value 0x00000000 at this
> point, hence the access violation -- you can't access the "handler"
> member of a struct pointed to by "filter->f->ctx" when that pointer is
> NULL.
>
> Don't know if that helps anyone at all.
Most likely something else has corrupted the memory.
> Re-running the tests as "perl t/TEST -verbose t/filter" fixes everything
> except for filter/in_str_consume.t test 1, which still fails for me
> (even with perl-5.8.1).
that means that some previous tests affect the filter tests. t/SMOKE is good
at finding the shortest sequence of tests that lead to the failure.
But I'm a bit lost in the amount of mixed reports. Can you please report the
filter/in_str_consume.t in a separate email/thread? Thanks.
> What's that all about, then?
>
> Stas: In a previous mail you said, "I suspect that the problem has
> surfaced after I have changed the number of running servers from one to
> two to allow the proxy work. What happens if you make the proxy filter
> skip and run the tests with only one server available? I bet they will
> all work." Could I have that again in English please? What do you want
> me to try?
Sorry, that means, making that test skip as in the patch below. And then run:
t/TEST -conf -maxclients 1
t/TEST
Index: t/modules/proxy.t
===================================================================
RCS file: /home/cvs/modperl-2.0/t/modules/proxy.t,v
retrieving revision 1.1
diff -u -r1.1 proxy.t
--- t/modules/proxy.t 26 Aug 2003 23:28:04 -0000 1.1
+++ t/modules/proxy.t 16 Sep 2003 18:52:21 -0000
@@ -8,7 +8,7 @@
my $location = "/TestModules__proxy";
-plan tests => 1, [qw(proxy access)];
+plan tests => 1, 0;
my $expected = "ok";
my $received = GET_BODY_ASSERT $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: [mp2] filter tests on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
>>produce, but not in all cases.
>>
>>
>>
>>>Anyway, here's a trace, this time with the Perl symbols:
>>>
>>>
>>does it mean that you get a segfault?
>>
>>
>
>The Windows equivalent, yes ... The message that comes up
>is an access violation in mod_perl.so.
>
>
Now that I've got ap2+mp2 running with perl-5.8.1, I get the same result
as Randy running the test suite: It gets as far as:
filter\both_str_con_add........ok 2/4
and then crashes.
Then line it crashed at was this:
modperl_handler_t *handler =
((modperl_filter_ctx_t *)filter->f->ctx)->handler;
and I notice that "filter->f->ctx" has the value 0x00000000 at this
point, hence the access violation -- you can't access the "handler"
member of a struct pointed to by "filter->f->ctx" when that pointer is NULL.
Don't know if that helps anyone at all.
Re-running the tests as "perl t/TEST -verbose t/filter" fixes everything
except for filter/in_str_consume.t test 1, which still fails for me
(even with perl-5.8.1).
I tried running "perl t/SMOKE" but I just get this:
=====
C:\Temp\modperl-2.0>perl t/SMOKE
*** Using random number seed: 1012582729 (autogenerated)
***
------------------------------------------------------------
*** [001-00-00] trying all tests 10 times
!!! failed to start server
'.' is not recognized as an internal or external command,
operable program or batch file.
=====
What's that all about, then?
Stas: In a previous mail you said, "I suspect that the problem has
surfaced after I have changed the number of running servers from one to
two to allow the proxy work. What happens if you make the proxy filter
skip and run the tests with only one server available? I bet they will
all work." Could I have that again in English please? What do you want
me to try?
- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 14 Sep 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > On Sun, 14 Sep 2003, Randy Kobes wrote:
> >
> >
> >>On Sun, 14 Sep 2003, Stas Bekman wrote:
> >>
> >>
> >>>Randy Kobes wrote:
> >>>
> >>>>With the current cvs mod_perl 2 on Win32, I'm having a
> >>>>problem running the filter tests from 'nmake test':
> >>>>the following occurs in subtest 3 (I think) of
> >>>>t/filter/both_str_con_add:
> >>>
> >>>could it be that it has something to do with geoff's recent patch:
> >>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106346593832576&w=2
> >>>does the problem disappear if you revert it?
> >>
> >>No, the same problem arises with and without that patch
> >>(actually, I held off reporting this, in case that patch
> >>fixed it).
>
> Cool.
>
> > I've just tried this with perl-5.8.1, but the same problem
> > arises (for this, I had to undefine MP_NEED_HASH_SEED_FIXUP
> > in src/modules/perl/mod_perl.c, as otherwise the server
> > won't start).
>
> What is the problem with it? It won't quite work without
> this fixup on the latest 5.8.1.
Leaving in MP_NEED_HASH_SEED_FIXUP as defined won't allow
the server to even start (with perl-5.8.1 on Win32). Just to
see, I tried undefining it, and the server did start, and
the tests started running, but then bombed out when it got
to the filter tests. This is the same behaviour (and at the
same place) as with perl-5.8.0 on Win32, where
MP_NEED_HASH_SEED_FIXUP is undefined.
As was mentioned on another message, the problem with
MP_NEED_HASH_SEED_FIXUP seems to be in the safemalloc()
call in src/modules/perl/mod_perl.c, in the
modperl_hash_seed_init() function. Just as an experiment, I
tried changing this to call malloc() instead - with this,
the server did start, and the tests started running, but
then crashed later, before the filter tests. I know using
malloc() isn't the right thing to do, so I didn't look
further.
> > And again, the problem arises with 'nmake
> > test', but using 'perl t/TEST t/filter' allows all filter
> > tests to pass (including one that failed with perl-5.8.0 on
> > Win32).
>
> You mean things fails when you run all tests and succeed
> only if you run t/filter tests, is that right? If that's
> the case, some previously run tests affect the latter
> tests. t/SMOKE is written especially for the purpose to
> figure out which minimal sequence of tests triggers the
> problem.
That's right - if one runs t/filter alone, all the filter
tests pass; the problem arises in running all the tests.
I'll look at t/SMOKE.
> I suspect that the problem has surfaced after I have
> changed the number of running servers from one to two to
> allow the proxy work. What happens if you make the proxy
> filter skip and run the tests with only one server
> available? I bet they will all work.
I'll try that ....
> That recent change in the number of running servers has
> revealed several other problems, which I'm trying to debug
> now. Unfortunately they happen at random and therefore
> hard to debug. Re-using the same HASH_SEED makes it easier
> to reproduce, but not in all cases.
>
> > Anyway, here's a trace, this time with the Perl symbols:
>
> does it mean that you get a segfault?
The Windows equivalent, yes ... The message that comes up
is an access violation in mod_perl.so.
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> On Sun, 14 Sep 2003, Randy Kobes wrote:
>
>
>>On Sun, 14 Sep 2003, Stas Bekman wrote:
>>
>>
>>>Randy Kobes wrote:
>>>
>>>>With the current cvs mod_perl 2 on Win32, I'm having a
>>>>problem running the filter tests from 'nmake test':
>>>>the following occurs in subtest 3 (I think) of
>>>>t/filter/both_str_con_add:
>>>
>>>could it be that it has something to do with geoff's recent patch:
>>>http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106346593832576&w=2
>>>does the problem disappear if you revert it?
>>
>>No, the same problem arises with and without that patch
>>(actually, I held off reporting this, in case that patch
>>fixed it).
Cool.
> I've just tried this with perl-5.8.1, but the same problem
> arises (for this, I had to undefine MP_NEED_HASH_SEED_FIXUP
> in src/modules/perl/mod_perl.c, as otherwise the server
> won't start).
What is the problem with it? It won't quite work without this fixup on the
latest 5.8.1.
> And again, the problem arises with 'nmake
> test', but using 'perl t/TEST t/filter' allows all filter
> tests to pass (including one that failed with perl-5.8.0 on
> Win32).
You mean things fails when you run all tests and succeed only if you run
t/filter tests, is that right? If that's the case, some previously run tests
affect the latter tests. t/SMOKE is written especially for the purpose to
figure out which minimal sequence of tests triggers the problem.
I suspect that the problem has surfaced after I have changed the number of
running servers from one to two to allow the proxy work. What happens if you
make the proxy filter skip and run the tests with only one server available? I
bet they will all work.
That recent change in the number of running servers has revealed several other
problems, which I'm trying to debug now. Unfortunately they happen at random
and therefore hard to debug. Re-using the same HASH_SEED makes it easier to
reproduce, but not in all cases.
> Anyway, here's a trace, this time with the Perl symbols:
does it mean that you get a segfault?
> ===============================================================
> modperl_run_filter(modperl_filter_t * 0x0142f0d0) line 376 + 9 bytes
> : modperl-2.0/src/modules/perl/modperl_filter.c
>
> modperl_output_filter_handler(ap_filter_t * 0x0142f7e8,
> apr_bucket_brigade * 0x0142f8c0) line 765 + 9 bytes
> : modperl-2.0/src/modules/perl/modperl_filter.c
>
> ap_pass_brigade(ap_filter_t * 0x0142f7e8, apr_bucket_brigade * 0x0142f8c0)
> line 550 + 7 bytes
> : httpd-2.0.47/server/util_filter.c
>
> XS_Apache__Filter_pass_brigade(interpreter * 0x00e3f194, cv * 0x019f9f18)
> line 197 + 14 bytes
> : WrapXS/Apache/Filter/Filter.c
>
> Perl_pp_entersub(interpreter * 0x01e3f194) line 2821
> : perl-5.8.1/pp_hot.c
>
> Perl_runops_standard(interpreter * 0x00e3f194) line 23 + 12 bytes
> : perl-5.8.1/run.c
>
> S_call_body(interpreter * 0x00e3f194, op * 0x02a0fdf8, int 0x00000000)
> line 2193 + 7 bytes
> : perl-5.8.1/perl.c
>
> Perl_call_sv(interpreter * 0x00e3f194, sv * 0x01921ab4, long 0x00000004)
> line 2132 + 13 bytes
> : perl-5.8.1/perl.c
>
> modperl_callback(interpreter * 0x00e3f194, modperl_handler_t * 0x008967e0,
> apr_pool_t * 0x0142f0d0,
> request_rec * 0x00000000,
> server_rec * 0x008958f8,
> av * 0x0283d66c) line 53 + 17 bytes
> : src/modules/perl/modperl_callback.c
>
> modperl_callback_run_handlers(int 0x00000000, int 0x00000001,
> request_rec * 0x00000000,
> conn_rec * 0x0142f1d0,
> server_rec * 0x008958f8,
> apr_pool_t * 0x00000000,
> apr_pool_t * 0x00000000,
> apr_pool_t * 0x00000000,
> int 0x00000001) line 188 + 35 bytes
> : src/modules/perl/modperl_callback.c
>
> modperl_callback_connection(int 0x00000000, conn_rec * 0x0142f1d0,
> int 0x00000001) line 279 + 34 bytes
> : src/modules/perl/modperl_callback.c
>
> modperl_process_connection_handler(conn_rec * 0x0142f1d0)
> line 17 + 13 bytes
> : src/modules/perl/modperl_hooks.c
>
> ap_run_process_connection(conn_rec * 0x0142f1d0) line 85 + 31 bytes
> : httpd-2.0.47/server/connection.c
>
> ap_process_connection(conn_rec * 0x0142f1d0,
> void * 0x0142f108) line 211 + 6 bytes
> : httpd-2.0.47/server/connection.c
>
> worker_main(long 0x77c37fb8) line 731
> : httpd-2.0.47/server/mpm/winnt/child.c
>
> MSVCRT! 77c37fb8()
> 08d40016()
>
> =====================================================================
>
--
__________________________________________________________________
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] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 14 Sep 2003, Randy Kobes wrote:
> On Sun, 14 Sep 2003, Stas Bekman wrote:
>
> > Randy Kobes wrote:
> > > With the current cvs mod_perl 2 on Win32, I'm having a
> > > problem running the filter tests from 'nmake test':
> > > the following occurs in subtest 3 (I think) of
> > > t/filter/both_str_con_add:
> >
> > could it be that it has something to do with geoff's recent patch:
> > http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106346593832576&w=2
> > does the problem disappear if you revert it?
>
> No, the same problem arises with and without that patch
> (actually, I held off reporting this, in case that patch
> fixed it).
I've just tried this with perl-5.8.1, but the same problem
arises (for this, I had to undefine MP_NEED_HASH_SEED_FIXUP
in src/modules/perl/mod_perl.c, as otherwise the server
won't start). And again, the problem arises with 'nmake
test', but using 'perl t/TEST t/filter' allows all filter
tests to pass (including one that failed with perl-5.8.0 on
Win32). Anyway, here's a trace, this time with the Perl symbols:
===============================================================
modperl_run_filter(modperl_filter_t * 0x0142f0d0) line 376 + 9 bytes
: modperl-2.0/src/modules/perl/modperl_filter.c
modperl_output_filter_handler(ap_filter_t * 0x0142f7e8,
apr_bucket_brigade * 0x0142f8c0) line 765 + 9 bytes
: modperl-2.0/src/modules/perl/modperl_filter.c
ap_pass_brigade(ap_filter_t * 0x0142f7e8, apr_bucket_brigade * 0x0142f8c0)
line 550 + 7 bytes
: httpd-2.0.47/server/util_filter.c
XS_Apache__Filter_pass_brigade(interpreter * 0x00e3f194, cv * 0x019f9f18)
line 197 + 14 bytes
: WrapXS/Apache/Filter/Filter.c
Perl_pp_entersub(interpreter * 0x01e3f194) line 2821
: perl-5.8.1/pp_hot.c
Perl_runops_standard(interpreter * 0x00e3f194) line 23 + 12 bytes
: perl-5.8.1/run.c
S_call_body(interpreter * 0x00e3f194, op * 0x02a0fdf8, int 0x00000000)
line 2193 + 7 bytes
: perl-5.8.1/perl.c
Perl_call_sv(interpreter * 0x00e3f194, sv * 0x01921ab4, long 0x00000004)
line 2132 + 13 bytes
: perl-5.8.1/perl.c
modperl_callback(interpreter * 0x00e3f194, modperl_handler_t * 0x008967e0,
apr_pool_t * 0x0142f0d0,
request_rec * 0x00000000,
server_rec * 0x008958f8,
av * 0x0283d66c) line 53 + 17 bytes
: src/modules/perl/modperl_callback.c
modperl_callback_run_handlers(int 0x00000000, int 0x00000001,
request_rec * 0x00000000,
conn_rec * 0x0142f1d0,
server_rec * 0x008958f8,
apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000,
apr_pool_t * 0x00000000,
int 0x00000001) line 188 + 35 bytes
: src/modules/perl/modperl_callback.c
modperl_callback_connection(int 0x00000000, conn_rec * 0x0142f1d0,
int 0x00000001) line 279 + 34 bytes
: src/modules/perl/modperl_callback.c
modperl_process_connection_handler(conn_rec * 0x0142f1d0)
line 17 + 13 bytes
: src/modules/perl/modperl_hooks.c
ap_run_process_connection(conn_rec * 0x0142f1d0) line 85 + 31 bytes
: httpd-2.0.47/server/connection.c
ap_process_connection(conn_rec * 0x0142f1d0,
void * 0x0142f108) line 211 + 6 bytes
: httpd-2.0.47/server/connection.c
worker_main(long 0x77c37fb8) line 731
: httpd-2.0.47/server/mpm/winnt/child.c
MSVCRT! 77c37fb8()
08d40016()
=====================================================================
--
best regards,
randy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Sun, 14 Sep 2003, Stas Bekman wrote:
> Randy Kobes wrote:
> > With the current cvs mod_perl 2 on Win32, I'm having a
> > problem running the filter tests from 'nmake test':
> > the following occurs in subtest 3 (I think) of
> > t/filter/both_str_con_add:
>
> could it be that it has something to do with geoff's recent patch:
> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106346593832576&w=2
> does the problem disappear if you revert it?
No, the same problem arises with and without that patch
(actually, I held off reporting this, in case that patch
fixed it).
--
best regards,
randy kobes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] filter tests on Win32
Posted by Stas Bekman <st...@stason.org>.
Randy Kobes wrote:
> With the current cvs mod_perl 2 on Win32, I'm having a
> problem running the filter tests from 'nmake test':
> the following occurs in subtest 3 (I think) of
> t/filter/both_str_con_add:
could it be that it has something to do with geoff's recent patch:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=106346593832576&w=2
does the problem disappear if you revert it?
> ======================================================
> modperl_run_filter(modperl_filter_t * 0x014bbd30) line 376 + 9 bytes
> : src/modules/perl/modperl_filter.c
>
> modperl_output_filter_handler(ap_filter_t * 0x014bc448,
> apr_bucket_brigade * 0x014bc520) line 765 + 9 bytes
> : src/modules/perl/modperl_filter.c
>
> ap_pass_brigade(ap_filter_t * 0x014bc448,
> apr_bucket_brigade * 0x014bc520) line 550 + 7 bytes
>
> XS_Apache__Filter_pass_brigade(interpreter * 0x013eb3d4, cv * 0x01025f48)
> line 180 + 14 bytes
> : WrapXS/Apache/Filter/Filter.c
>
> PERL58! 2803f772()
>
> PERL58! 2805d77f()
>
> modperl_callback(interpreter * 0x013eb3d4,
> modperl_handler_t * 0x00898918, apr_pool_t * 0x014bbd30,
> request_rec * 0x00000000, server_rec * 0x00895aa0, av * 0x034f802c)
> line 53 + 17 bytes
> : src/modules/perl/modperl_callback.c
>
> modperl_callback_run_handlers(int 0x00000000,
> int 0x00000001, request_rec * 0x00000000, conn_rec * 0x014bbe30,
> server_rec * 0x00895aa0, apr_pool_t * 0x00000000,
> apr_pool_t * 0x00000000, apr_pool_t * 0x00000000, int 0x00000001)
> line 188 + 35 bytes
> : src/modules/perl/modperl_callback.c
>
> modperl_callback_connection(int 0x00000000,
> conn_rec * 0x014bbe30, int 0x00000001) line 279 + 34 bytes
> : src/modules/perl/modperl_callback.c
>
> modperl_process_connection_handler(conn_rec * 0x014bbe30) line 17 + 13 bytes
> : src/modules/perl/modperl_hooks.c
>
> ap_run_process_connection(conn_rec * 0x014bbe30) line 85 + 31 bytes
> ap_process_connection(conn_rec * 0x014bbe30, void * 0x014bbd68)
> line 211 + 6 bytes
> worker_main(long 0x77c37fb8) line 731
> MSVCRT! 77c37fb8()
> 08cf0016()
> ================================================================
>
> However, if I install things, and run the tests as
> perl t/TEST -verbose t/filter
> they're all fine (save for a failure of
> t/filter/in_str_consume.t, where it receives nothing, but
> this also occurred before). Does this trigger something?
>
--
__________________________________________________________________
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