Re: PHP 4.0 Bug #4317: POST on IIS5

I've been trying to track down the problem described in bug #4317 as it has been causing me grief for most of the year. When I first came across the problem, I found that it had already been posted as bug #3041 by Anton Kalmykov, and Anton had done some work and found that the pointer which was pointing to the buffer for the incoming post data was becoming corrupted and then php was blowing up when the buffer was next reallocated. Anton produced a workaround whereby he increased the initial size of the buffer such that it was big enough to receive all of the likely post data without recourse to a realloc. On April 1st this Year, Andi Gutmans closed the bug and reported it as fixed in the CVS. There's an entry in the changelog from Zeev reporting a change to SAPI.c and SAPI.h - 'Fix a problem when dealing with large POST blocks in CGI mode'. Sadly, throughout April I was heavily engaged in non-php programming and did not really get the chance to experiment again until last week. However, I find that the problem still seems to exist. Today, Martin Widmann posted what seems to be the same bug, but using IIS5 on Win2000. I have done tests setting implicit flush to on and echoing some output as the first line of the php file which is accepting the post data, however php dies before any output is generated. Sadly, I cannot get the problem to manifest itself on my own desktop NT box, but the problem persists on my production NT box (running identical versions of php, related dlls and ini file). When php crashes, I get an access violation 'Dr Watson' report on the production NT box. Since I was running a release version, the stack backtrace didn't really give any useful info. I've compiled up a debug version this morning (from yesterday evening's CVS) and put that on the production machine. I've included the dr watson log for the access violation below. I'm not a pc guru at all so maybe someone else can make some kind of diagnosis from the log - it looks to me like we blew up inside memchr, I guess because the string pointer was duff, but I can't determine the context from which memchr was called. I'm guessing that it's called from php_fopen_url_wrapper. If anyone can point me in the direction of further tests and experiments to do, I'm happy to put in the time to help pin down and fix the problem. Application exception occurred: App: (pid=226) When: 5/4/2000 @ 14:36:39.618 Exception number: c0000005 (access violation) *----> System Information <----* Computer Name: DUCRU User Name: geoffhoward Number of Processors: 1 Processor Type: x86 Family 6 Model 3 Stepping 4 Windows Version: 4.0 Current Build: 1381 Service Pack: 4 Current Type: Uniprocessor Free Registered Organization: dtonline Registered Owner: Phil Driscoll *----> Task List <----* 0 Idle.exe 2 System.exe 25 smss.exe 33 CSRSS.exe 39 WINLOGON.exe 47 SERVICES.exe 50 LSASS.exe 75 SPOOLSS.exe 81 RPCSS.exe 91 msdtc.exe 108 AWHOST32.exe 112 FTGateNT.exe 118 LLSSRV.exe 126 mysqld.exe 146 PSTORES.exe 163 inetinfo.exe 223 NDDEAGNT.exe 224 EXPLORER.exe 148 S3TRAY.exe 193 LOADWC.exe 157 EVENTVWR.exe 226 php.exe 194 DRWTSN32.exe 0 _Total.exe (00400000 - 00418000) (77f60000 - 77fbc000) dll\ntdll.dbg (10000000 - 10213000) (77f00000 - 77f5e000) dll\kernel32.dbg (776d0000 - 776d8000) dll\wsock32.dbg (776b0000 - 776c4000) dll\ws2_32.dbg (78000000 - 78000000) (77e70000 - 77ec4000) dll\user32.dbg (77ed0000 - 77efc000) dll\gdi32.dbg (77dc0000 - 77dff000) dll\advapi32.dbg (77e10000 - 77e67000) dll\rpcrt4.dbg (776a0000 - 776a7000) dll\ws2help.dbg (77b20000 - 77bd5000) dll\ole32.dbg (766f0000 - 76782000) oleaut32.dbg (6a980000 - 6a9b4000) odbc32.dbg (77aa0000 - 77b14000) COMCTL32.dbg (77c40000 - 77d7c000) dll\shell32.dbg (77d80000 - 77db2000) dll\comdlg32.dbg (77a90000 - 77a9b000) dll\version.dbg (779c0000 - 779c8000) dll\lz32.dbg (00240000 - 002a4000) (102a0000 - 102b7000) (04a00000 - 04a13000) ..\RES\US\ODBCLAN\\ndebug32\ODBCINT.dll State Dump for Thread Id 0xec eax=0002ba36 ebx=2d2d2d2d ecx=00000000 edx=0107f000 esi=0012fb7c edi=ac2c2c2c eip=00282cfa esp=0012fb64 ebp=0012fc3c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206 function: memchr 00282ce9 8a0a mov cl,[edx] ds:0107f000=?? 00282ceb 42 inc edx 00282cec 32cb xor cl,bl 00282cee 743e jz memchr+0x8e (00282d2e) 00282cf0 48 dec eax 00282cf1 75f6 jnz memchr+0x49 (00282ce9) 00282cf3 5b pop ebx 00282cf4 c3 ret 00282cf5 83e804 sub eax,0x4 00282cf8 72e9 jb memchr+0x43 (00282ce3) FAULT ->00282cfa 8b0a mov ecx,[edx] ds:0107f000=???????? 00282cfc 33cb xor ecx,ebx 00282cfe bffffefe7e mov edi,0x7efefeff 00282d03 03f9 add edi,ecx 00282d05 83f1ff xor ecx,0xff 00282d08 33cf xor ecx,edi 00282d0a 83c204 add edx,0x4 00282d0d 81e100010181 and ecx,0x81010100 00282d13 74e0 jz memchr+0x55 (00282cf5) 00282d15 8b4afc mov ecx,[edx-0x4] ds:024bda06=???????? 00282d18 32cb xor cl,bl 00282d1a 7423 jz memchr+0x9f (00282d3f) *----> Stack Back Trace <----* FramePtr ReturnAd Param#1 Param#2 Param#3 Param#4 Function Name 0012fc3c 100126ba 01050088 0002d4da 00f870d6 00f8e218 !memchr 0012fcac 100141fb 00f870b8 00f8e218 00f51360 0012fd88 !php_file_le_socket 0012fd0c 100102fc 00f8e218 00f51360 0012fe04 0012fda4 !php_file_le_socket 0012fd88 1000c5c5 00000000 00000000 00f52230 00f55f00 !php_file_le_socket 0012fe04 1000c1aa 00f52230 00f51360 00f55f00 68c1ef11 !php_file_le_socket 0012fe98 00401aae 0012ff4c 00f52950 00f52230 00f55f00 !php_file_le_socket 0012ff70 004027bf 00000002 00f517b0 00f50e40 68c1ef11 !<nosymbols> 0012ffc0 77f1ba3c 68c1ef11 00f3eaec 7ffdf000 c0000005 !<nosymbols> 0012fff0 00000000 004026c0 00000000 00000000 77fa5ab0 kernel32!GetProcessPriorityBoost 00000000 00000000 00000000 00000000 00000000 00000000 !<nosymbols> *----> Raw Stack Dump <----* 0012fb64 3c fc 12 00 00 f0 fd 7f - 4c 28 01 10 60 d5 07 01 <.......L(..`... 0012fb74 2d 00 00 00 da d4 02 00 - ac fc 12 00 54 fc 12 0 -...........T... 0012fb84 00 f0 fd 7f cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fb94 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fba4 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fbb4 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fbc4 cc cc cc cc 00 00 00 00 - cc cc cc cc cc cc cc cc ................ 0012fbd4 cc cc cc cc cc cc cc cc - 00 5f f5 00 30 22 f5 00 ........._..0".. 0012fbe4 a8 e0 f8 00 cc cc cc cc - cc cc cc cc 00 00 00 00 ................ 0012fbf4 00 00 00 00 00 00 00 00 - 00 00 00 00 cc cc cc cc ................ 0012fc04 cc cc cc cc cc cc cc cc - 02 00 00 00 00 00 00 00 ................ 0012fc14 00 00 00 00 71 00 00 00 - cc cc cc cc cc cc cc cc ....q........... 0012fc24 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fc34 5f d5 07 01 60 d5 07 01 - ac fc 12 00 ba 26 01 10 _...`........&.. 0012fc44 88 00 05 01 da d4 02 00 - d6 70 f8 00 18 e2 f8 00 .........p...... 0012fc54 0c fd 12 00 c0 fc 12 00 - 00 f0 fd 7f cc cc cc cc ................ 0012fc64 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fc74 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fc84 cc cc cc cc cc cc cc cc - cc cc cc cc cc cc cc cc ................ 0012fc94 cc cc cc cc cc cc cc cc - cc cc cc cc 18 e2 f8 00 ................ -- Phil Driscoll Dial Solutions +44 (0)113 294 5112 http://www.dialsolutions.com http://www.dtonline.org