Re: Win32 pre-Beta 4 NT version - important bug (at least I think so!)
| From: | Phil Driscoll | Date: | Mon, 14 Feb 2000 15:45:10 +0000 |
| Subject: | Re: Win32 pre-Beta 4 NT version - important bug (at least I think so!) | ||
| Groups: | php.dev | ||
| Request: | Send a blank email to php-dev+get-15520@lists.php.net to get a copy of this message | ||
Zeev
I've been doing various tests for the last eight hours trying to get some
sensible information for you. Things started well - my initial answers to
your questions were:
*******
>1. Are you using standard POST or multipart (file upload)? It actually
>uses the same read code, but I'd still like to know (if it crashes on both
>or just one of them).
My tests were done on enctype="multipart/form-data"
>2. Does it crash regardless of the script? If you post to an empty
>script, would it still crash?
I've just tried to post a form which sends a file upload of an 86K file to
an empty script (ie to a php file of 0 bytes length). The problem still
occurred.
>Do you have a debugger? Can you attach to inetinfo.exe and see exactly
>what's going on?
Yes - I have MSVC++6, but because of some unresolved symbols during linking
that I haven't yet been able to get to the bottom of, I have not been able
to build php from source on my machine. Consequently, if I attach the
debugger to inetinfo, the output I get is only assembler, and the stack
contexts whilst in php are just memory locations.
*******
Then something changed - I'm pretty sure I didn't do anything, but PHP
stopped crashing on file uploads. However, a couple of other problems came
to light.
Using this as a test form...
<form method="post" action="test.php"
enctype="multipart/form-data">
<input name="userfile" type="file">
<input type="submit" value="Submit" name="Go">
</form>
...I can now upload a long file without a crash, but with file corruption -
each 0x0A character in the jpeg file I am using for testing is being
replaced by an 0x0D 0x0A pair (looks like a binary mode problem - for info,
the problem disappears if I remove the enctype attribute). The second
problem may be a different manifestation of a memory corruption fault that
may have been the cause of the earlier crashes. This is my receiving page:
<?php
echo("The file you downloaded was called
$userfile_name<br>userfile=$userfile<br>");
unlink("C:\\testimage.jpg");
rename($userfile,"C:\\testimage.jpg");
?>
Sometimes, this works ok, but often, the $userfile_name variable is blank
and $userfile is being set to what $userfile_name should have been.
The same files test out perfectly if I use PHP3.
I realise that from my information it will be very hard to pin the problem
down. I understand that Anton Kalmykov has been in touch with you and has
hopefully been able to provide more stable information :-)
Cheers
--
Phil Driscoll
Dial Solutions
+44 (0)113 294 5112
http://www.dialsolutions.com
http://www.dtonline.org