ID: 10904
Updated by: sniper
Old-Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating system: 
PHP Version: 4.0.5
Assigned To: 

please try the latest snapshot from

Previous Comments:

[2001-05-18 10:50:53] [EMAIL PROTECTED]
I believe it is CGI.  Httpd.conf contains

ScriptAlias /php/ "C:/phpdev3/php/"
ScriptAlias /php2/ "C:/phpdev3/php/"
ScriptAlias /php3/ "C:/phpdev3/php/"

AddType application/x-httpd-php4 .phtml .pwml .htm
AddType application/x-httpd-php4 .php4 .php .php3 .php2 .htm

Action application/x-httpd-php4 "/php/php.exe"

I just performed a complete reinstallation, but the bug is still there.

I downloaded and installed the phpdev3 installation package from

This package installs Apache 1.3.19 , PHP 4.0.4pl, and MySQL. My application talks to 
Oracle and I don't use the MySQL.

I completely removed my old installation.
I made these configurations to the fresh installation.
In PHP.INI (which I copied to c:winnt)
   - changed the memory limit to 16M
   - set the include path to "."
   - enabled the php_mhash extension
   - enabled the php_imap extension (can't recall if I actually use this)
in httpd.conf
   - changed the document root to "D:www"
I copied all the dlls for phpdlls and phpextensions to my system32 directory (except I 
got he usual error with msvcrt.dll --- mine is 12/7/99 and the dist version is 

Then I verified that my application still works and that the little demonstration app 
still shows the bug.



[2001-05-18 04:48:55] [EMAIL PROTECTED]
Can reproduce this.. what SAPI are you using (ISAPI or CGI?).

- James


[2001-05-16 11:44:25] [EMAIL PROTECTED]
This script reproduces the bug on my machine:

   print "<html>";
   print "<head>";
   print "   <title>bug</title>";
   print "</head>";
   print "<body>";
   for ($i=0; $i<1000; $i++) {
      print "<BR>hello" ;
   print "</body>";
   print "</html>";

Change 1000 to 333 and the bug disappears,
Change 1000 to 22222 and the bug disappears.


[2001-05-16 11:02:35] [EMAIL PROTECTED]
WINNT SP4, APACHE 1.3.14, PHP 4.0.4 and 4.0.5

I cannot make a gdb backtrace, but I can give you the following:

1) It is an access violation -- the instruction at 0x0dsd5973 referenced 0x00000000.  
the memory could not be read.

2) It always occurs near the end of a script and is not related to what HTML happens 
to be generated.  Most scripts do not show the error at all, but when one does only 
changing the size of the output (either very small or very large) will suppress it.  

3) After clearing the error (by clicking OK on the error message on the server), the 
full HTML is always produced correctly.  However, until OK is clicked, the client is 
left waiting for the last 1K or so of output).  

4) It is defintely related to the size of the output.  Scripts that make output 
smaller then 1K never show the error.  Larger scripts may or may not show the error, 
but when they do, the error can always be removed by making the script generate a very 
large output (~100K). I just repeated the same content x times. Once x is large 
enough, the bug goes away.

5) On my system, calling phpinfo causes it -- <?php phpinfo() ?> -- but only on the 
second and subsequent calls after rebooting the server.  Just starting and stopping 
Apache does not allow the first good call to succeed--the server must be rebooted.

6) changing imlicit_flush, output_buffering, and memory_limit in php.ini do not fix 
it, but might(???) alter the size of output that exhibts the problem.  flush() in the 
code does not fix it.

7) I theorize it is related to some final cleanup or garbage collection code.  

8) I first saw it in 4.0.4 and upgraded to 4.0.5 hoping to see it go away.  It did 
not, but again the size of output that shows the error might(???) have changed. One 
point about the upgrade, I could not copy msvcrt.dll to the system root because it was 
always locked by the OS, even after closing all closable services.  My msvcrt.dll is 
dated three days earlier than the one distributed with PHP 4.0.4 and 4.0.5.  There 
appears to be no way to change it.

--This bug could easily exist under another OS, but be invisible (and harmless) if the 
OS does not generate an error message for the address violation.  

Hope this is helpful.  Feel free to contact me.



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at

PHP Development Mailing List <>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to