Re: Win32 pre-Beta 4 NT version - important bug (at least I think so!)

At 17:45 14/02/2000 , Phil Driscoll wrote:

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 :-)

As a matter of fact, this, very suspiciously, reminds me of a patch someone mentioned on one of the development mailing lists, about turning \n to \r\n or something of the sort (0x0A is \n and 0x0D is \r). I suspect that someone must have applied an invalid patch. As for why it crashed, I can't say really. It worked fine here. Zeev -- Zeev Suraski <zeev@zend.com> http://www.zend.com/