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

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

« previous php.dev (#15520) next »