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
--- pool.pm.orig 2003-09-09 18:22:40.000000000 +0100
+++ pool.pm 2003-09-22 14:36:23.977260300 +0100
@@ -26,7 +26,7 @@
sub handler {
my $r = shift;
- plan $r, tests => 13;
+ plan $r, tests => 2;
my $p = APR::Pool->new;
@@ -43,6 +43,8 @@
$p->cleanup_register(\&add_cleanup, [$r, 'parent']);
$subp->cleanup_register(\&set_cleanup, [$r, 'child']);
+ return Apache::OK;
+
# should destroy the subpool too
$p->destroy;
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
