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

On Tue, Feb 15, 2000 at 12:36:04AM +0200, Zeev Suraski wrote: > 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. the patch can be reviewed on: http://bonsai.php.net/bonsai/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/local/repository&subdir=php4&command=DIFF_FRAMESET&root=/local/repository&file=rfc1867.c&rev1=1.24&rev2=1.25 it was only for the boudaries between the mime elements - i don't think it is related to the reported problem. > > As for why it crashed, I can't say really. It worked fine here. > > Zeev > -- > Zeev Suraski <zeev@zend.com> http://www.zend.com/ > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, e-mail: php-dev-unsubscribe@lists.php.net > For additional commands, e-mail: php-dev-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > -- Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany