[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: WINNT SP4 PHP Version: 4.0.5 New Comment: I ported my site to W2K, and as your note indicates the bug does not appear there. I don't care if it is ever fixed for WINNT SP4. Previous Comments: [2001-07-27 12:26:49] [EMAIL PROTECTED] status: open [2001-07-23 10:12:00] [EMAIL PROTECTED] Yes. The little loop script still shows it. Other scripts may or may not show it, but it only appears with the second invocation. It is easy to think it is gone because the first time a script runs it usually doesn't happen. If you haven't backed up the browser and opened the script a second time, it could be hiding. Also, I am running WinNT 4 not w2k. If I can suppress the bug by upgrading to w2k, I might. I have been thinking I might have to move the server to Linux. I am currently running 4.0.4pl because I am not set up to link in the modules I need with 4.0.6. [2001-07-22 09:20:36] [EMAIL PROTECTED] can't repoduce this with the apache module or the cgi (4.0.6) under w2k. is this bug still existant for you? [2001-06-15 09:59:43] [EMAIL PROTECTED] I installed the snapshot from 6/14/2001. I know the installation was successful because PHP issued warnings about not being able to load modules such as GD. I ran it against the small script that demonstrates the defect, and, unfortunately, the defect is still there. [2001-06-14 22:20:21] [EMAIL PROTECTED] please try the latest snapshot from http://www.zend.com/snapshots The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=10904 Edit this bug report at http://bugs.php.net/?id=10904edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Reproducible crash Operating System: WINNT SP4 PHP Version: 4.0.5 New Comment: So we'll forget about it.. Previous Comments: [2001-09-05 09:57:39] [EMAIL PROTECTED] I ported my site to W2K, and as your note indicates the bug does not appear there. I don't care if it is ever fixed for WINNT SP4. [2001-07-27 12:26:49] [EMAIL PROTECTED] status: open [2001-07-23 10:12:00] [EMAIL PROTECTED] Yes. The little loop script still shows it. Other scripts may or may not show it, but it only appears with the second invocation. It is easy to think it is gone because the first time a script runs it usually doesn't happen. If you haven't backed up the browser and opened the script a second time, it could be hiding. Also, I am running WinNT 4 not w2k. If I can suppress the bug by upgrading to w2k, I might. I have been thinking I might have to move the server to Linux. I am currently running 4.0.4pl because I am not set up to link in the modules I need with 4.0.6. [2001-07-22 09:20:36] [EMAIL PROTECTED] can't repoduce this with the apache module or the cgi (4.0.6) under w2k. is this bug still existant for you? [2001-06-15 09:59:43] [EMAIL PROTECTED] I installed the snapshot from 6/14/2001. I know the installation was successful because PHP issued warnings about not being able to load modules such as GD. I ran it against the small script that demonstrates the defect, and, unfortunately, the defect is still there. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=10904 Edit this bug report at http://bugs.php.net/?id=10904edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Reproducible crash Operating System: WINNT SP4 PHP Version: 4.0.5 New Comment: status: open Previous Comments: [2001-07-23 10:12:00] [EMAIL PROTECTED] Yes. The little loop script still shows it. Other scripts may or may not show it, but it only appears with the second invocation. It is easy to think it is gone because the first time a script runs it usually doesn't happen. If you haven't backed up the browser and opened the script a second time, it could be hiding. Also, I am running WinNT 4 not w2k. If I can suppress the bug by upgrading to w2k, I might. I have been thinking I might have to move the server to Linux. I am currently running 4.0.4pl because I am not set up to link in the modules I need with 4.0.6. [2001-07-22 09:20:36] [EMAIL PROTECTED] can't repoduce this with the apache module or the cgi (4.0.6) under w2k. is this bug still existant for you? [2001-06-15 09:59:43] [EMAIL PROTECTED] I installed the snapshot from 6/14/2001. I know the installation was successful because PHP issued warnings about not being able to load modules such as GD. I ran it against the small script that demonstrates the defect, and, unfortunately, the defect is still there. [2001-06-14 22:20:21] [EMAIL PROTECTED] please try the latest snapshot from http://www.zend.com/snapshots [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 www.firepages.com.au. 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 php\dlls and php\extensions to my system32 directory (except I got he usual error with msvcrt.dll --- mine is 12/7/99 and the dist version is 12/10/99). Then I verified that my application still works and that the little demonstration app still shows the bug. Steve The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=10904 Edit this bug report at http://bugs.php.net/?id=10904edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
Updated by: dbeu
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating System: WINNT SP4
PHP Version: 4.0.5
New Comment:
can't repoduce this with the apache module or the cgi (4.0.6) under w2k.
is this bug still existant for you?
Previous Comments:
[2001-06-15 09:59:43] [EMAIL PROTECTED]
I installed the snapshot from 6/14/2001.
I know the installation was successful because PHP issued warnings about not being
able to load modules such as GD.
I ran it against the small script that demonstrates the
defect, and, unfortunately, the defect is still there.
[2001-06-14 22:20:21] [EMAIL PROTECTED]
please try the latest snapshot from http://www.zend.com/snapshots
[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 www.firepages.com.au.
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 php\dlls and php\extensions to my system32 directory (except
I got he usual error with msvcrt.dll --- mine is 12/7/99 and the dist version is
12/10/99).
Then I verified that my application still works and that the little demonstration app
still shows the bug.
Steve
[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:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 and the bug disappears.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/?id=10904
Edit this bug report at http://bugs.php.net/?id=10904edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating system: WINNT SP4
PHP Version: 4.0.5
Description: php.exe accesses unreadable memory and crashes
I installed the snapshot from 6/14/2001.
I know the installation was successful because PHP issued warnings about not being
able to load modules such as GD.
I ran it against the small script that demonstrates the
defect, and, unfortunately, the defect is still there.
Previous Comments:
---
[2001-06-14 22:20:21] [EMAIL PROTECTED]
please try the latest snapshot from http://www.zend.com/snapshots
---
[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 www.firepages.com.au.
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
12/10/99).
Then I verified that my application still works and that the little demonstration app
still shows the bug.
Steve
---
[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:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 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 0x.
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.
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproducible crash
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Can reproduce this.. what SAPI are you using (ISAPI or CGI?).
- James
Previous Comments:
---
[2001-05-16 11:44:25] [EMAIL PROTECTED]
This script reproduces the bug on my machine:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 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 0x.
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.
Steve
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10904edit=2
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproducible crash
Operating system: WINNT SP4
PHP Version: 4.0.5
Description: php.exe accesses unreadable memory and crashes
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 www.firepages.com.au.
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 php\dlls and php\extensions to my system32 directory (except
I got he usual error with msvcrt.dll --- mine is 12/7/99 and the dist version is
12/10/99).
Then I verified that my application still works and that the little demonstration app
still shows the bug.
Steve
Previous Comments:
---
[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:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 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 0x.
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.
Steve
---
Full Bug description available at: http://bugs.php.net/?id=10904
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating system: WINNT SP4
PHP Version: 4.0.5
Description: php.exe accesses unreadable memory and crashes
This script reproduces the bug on my machine:
?php
print html;
print head;
printtitlebug/title;
print /head;
print body;
for ($i=0; $i1000; $i++) {
print BRhello ;
}
print /body;
print /html;
?
Change 1000 to 333 and the bug disappears,
Change 1000 to 2 and the bug disappears.
Previous Comments:
---
[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 0x.
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.
Steve
---
Full Bug description available at: http://bugs.php.net/?id=10904
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
