Stas Bekman wrote:
Steve Hay wrote: [...]
OK, so you have t/filter/in_str_consume.t failing with and without LWP and it happens randomly and it's not affected by the PERL_HASH_SEED variable. You didn't tell me what's the error that you get. Or do you get that silent failure as before? If so try with -v and look for error message on the client side, not error_log. This test is special, since the server underreads data sent by the client, it's possible that neither LWP nor TestClient are good at handling that condition.
Here's what I (sometimes!) get running "perl t/TEST -verbose t/filter/in_str_consume.t":
=====
filter/in_str_consume....1..1
# Running under perl version 5.008001 for MSWin32
# Current time local: Mon Sep 22 11:23:46 2003
# Current time GMT: Mon Sep 22 10:23:46 2003
# Using Test.pm version 1.24
# sent 80000B, expecting 105B to make through
# Failed test 1 in filter/in_str_consume.t at line 21
# testing : input stream filter partial consume
# expected: 105
# received:
not ok 1
FAILED test 1
Failed 1/1 tests, 0.00% okay
Failed Test Stat Wstat Total Fail Failed List of Failed
-------------------------------------------------------------------------------
filter/in_str_consume.t 1 1 100.00% 1 =====
The error_log contains nothing of interest (only the stuff about the server starting up).
I've seen that with Apache::TestClient (when LWP is not available). The problem is that it may fail to deal with the broken pipe to the server.
Another thing that will help debuggiing is looking at the trace with MOD_PERL_TRACE=f and -trace=debug. I bet that it fails the moment the filter stops its reading:
env MOD_PERL_TRACE=f t/TEST -verbose -trace=debug t/filter/in_str_consume.t
This should tell you all the story.
It doesn't tell me anything, I'm afraid.
I've attached the complete error_log from a successful run (error_log_ok) and from an unsuccessful run (error_log_nok). I'm not sure it'll tell you much either, to be honest -- there's very little difference :-(
At least it tells me a lot ;) According to your logs (both), the handler side finishes just fine and the client side is the one that has a problem to deal with the server stopping to read the data a client is trying to send. You still have this problem with LWP and Apache::TestClient, right? Does the patch below help at all? I'm not quite sure whether localization works, so just trying it that way.
The only shred of interesting behaviour that I've noticed is that I don't seem to be able to make it fail if I use the "-trace=debug" option as you suggested above. I just ran it 24 times on the trot without a single failure! If I take the "-trace=debug" option out then it typically fails at least 2 or 3 times out of 6.
Besides the difference is the size of the first bucket brigades
- read in: HEAP bucket with 8000 bytes (0x91d9d8) <= ok + read in: HEAP bucket with 7831 bytes (0x91d870) <= nok
which could change from run to run I believe, the two logs are indentical.
Probably unrelated but for some reason the debug messages that -trace=debug is supposed to enable don't make it to, e.g. on my system it's:
+==> FILTER READ: [*************] +==> FILTER READ: 13 (0 more to go) +==> HANDLER READ: 105 bytes
unless both logs were created without -trace=debug.
Index: t/filter/in_str_consume.t =================================================================== RCS file: /home/cvs/modperl-2.0/t/filter/in_str_consume.t,v retrieving revision 1.3 diff -u -r1.3 in_str_consume.t --- t/filter/in_str_consume.t 27 Aug 2003 04:42:37 -0000 1.3 +++ t/filter/in_str_consume.t 23 Sep 2003 01:34:27 -0000 @@ -16,6 +16,9 @@
t_debug "sent " . length($data) . "B, expecting ${expected}B to make through";
+my $old_sigpipe = $SIG{PIPE};
+$SIG{PIPE} = sub { warn "That's right! I received SIGPIPE and ignored it\n" };
my $received = POST_BODY $location, content => $data;
+$SIG{PIPE} = $old_sigpipe if $old_sigpipe;ok t_cmp($expected, $received, "input stream filter partial consume")
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
