httpd-apreq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Hay <steve....@uk.radan.com>
Subject [PATCH] Re: It's time to get 2.03-dev out
Date Mon, 07 Jun 2004 12:11:08 GMT
Joe Schaefer wrote:

>Please test current cvs and report/fix any build problems;
>
I have the Perl glue apreq/request.t tests 2-3 failing on Win32.  Here's 
the output under "t/TEST -v" after changing the $value to just "my 
$value = 'DataUpload';":

# testing : basic upload
# expected: DataUpload
# Failed test 2 in t\apreq\request.t at line 27
# Failed test 3 in t\apreq\request.t at line 33
# received: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
# <html><head>
# <title>500 Internal Server Error</title>
# </head><body>
# <h1>Internal Server Error</h1>
# <p>The server encountered an internal error or
# misconfiguration and was unable to complete
# your request.</p>
# <p>Please contact the server administrator,
#  you@example.com and inform them of the time the error occurred,
# and anything you might have done that may have
# caused the error.</p>
# <p>More information about this error may be available
# in the server error log.</p>
# </body></html>
not ok 2
# testing : basic upload length
# expected: 10
# received: 0
not ok 3

All I have in the error log (after the server startup messages) is this:

[Mon Jun 07 12:41:24 2004] [debug] mod_apreq.c(258): [client 127.0.0.1] 
prefetching 65536 bytes
[Mon Jun 07 12:41:24 2004] [error] [client 127.0.0.1] Use of 
uninitialized value in subroutine entry at 
C:\\Temp\\httpd-apreq-2\\glue\\perl\\t\\response/TestApReq/request.pm 
line 29.\n

The "use warnings FATAL => 'all';" line turns that warning into the 500 
Server Error seen above.  However, simply commenting out that FATAL 
warnings line (in the hope that the warning is harmless) doesn't fix 
it.  Evidently the warning is not harmless; the output is now:

# Failed test 2 in t\apreq\request.t at line 27
# Failed test 3 in t\apreq\request.t at line 33
# testing : basic upload
# expected: DataUpload
# received:
not ok 2
# testing : basic upload length
# expected: 10
# received: 0
not ok 3

Line 29 of glue/perl/t/response/TestApReq/request.pm (where the warning 
came from) is:

            $b->read(my $buffer);

I tried initialising my $buffer to an empty string before the read() 
call, like this:

            my $buffer = '';
            $b->read($buffer);

but now it complains:

[Mon Jun 07 12:47:37 2004] [error] [client 127.0.0.1] Argument "" isn't 
numeric in subroutine entry at 
C:\\Temp\\httpd-apreq-2\\glue\\perl\\t\\response/TestApReq/request.pm 
line 30.\n

I'm struggling to find the necessary docs to look at.  I think $b here 
is an APR::Brigade, but where does that get its read() method from?  
Maybe APR::Bucket?  That has a read() which takes an optional "mode" 
parameter (numeric?), and /returns/ the data read, so I tried this:

            my $buffer = $b->read();

and now it's all OK.

So the following patch fixes this for me, but I'm very confused how 
nobody else could have noticed this?

Index: glue/perl/t/response/TestApReq/request.pm
===================================================================
RCS file: 
/home/cvspublic/httpd-apreq-2/glue/perl/t/response/TestApReq/request.pm,v
retrieving revision 1.7
diff -u -r1.7 request.pm
--- glue/perl/t/response/TestApReq/request.pm   28 Feb 2004 05:16:11 
-00001.7
+++ glue/perl/t/response/TestApReq/request.pm   7 Jun 2004 12:03:46 -0000
@@ -26,7 +26,7 @@
 #        unlink("/home/joe/tmp/foo");
         my $bb = $upload->bb;
         while (my $b = $bb->first) {
-            $b->read(my $buffer);
+            my $buffer = $b->read();
             $r->print($buffer);
             $b->remove;
         }
End of Patch.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential
and intended for the addressee(s) only.  If you have received this message in error or there
are any problems, please notify the sender immediately.  The unauthorized use, disclosure,
copying or alteration of this message is strictly forbidden.  Note that any views or opinions
presented in this email are solely those of the author and do not necessarily represent those
of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached
files for viruses: Radan Computational will accept no liability for any damage caused by any
virus transmitted by this email.


Mime
View raw message