#36480 [NoF-Opn]: OpenSSL Memory Leaks
ID: 36480
User updated by: polone at townnews dot com
Reported By: polone at townnews dot com
-Status: No Feedback
+Status: Open
Bug Type: OpenSSL related
Operating System: RedHat FC4
PHP Version: 4.4.2
New Comment:
You didn't provide a snap of the latest 4.4.x branch - which is where
the bug was reported. I'm not using version 5.
Previous Comments:
[2006-04-18 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-04-11 00:27:24] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-21 18:07:38] polone at townnews dot com
Description:
The OpenSSL extension in PHP leaks memory. Using valgrind, I was able
to determine that there is a consistent leak of about 20K. There are
two leaks, one is the result of calling SSL_get_ex_new_index() during
MINIT which doesn't supply any mechanism for free_func (according to
the prototype). The other leak, which accounts for about 19K, is from
loading error strings but not calling the relevant free() function.
Another problem was noticed in network.c. There is a call to
SSL_CTX_new(), but no corresponding SSL_CTX_free() when the socket is
closed. Because the pointer for ctx is localized, the original pointer
is lost - using SSL_get_SSL_CTX() allows you to retrieve the context
and free it properly before call SSL_free() during socket close.
I've included a patch which corrects two of the issues:
diff -Naur php-4.4.2/ext/openssl/openssl.c
php-fixed/ext/openssl/openssl.c
--- php-4.4.2/ext/openssl/openssl.c 2006-01-01 07:46:55.0
-0600
+++ php-4.4.2/ext/openssl/openssl.c 2006-02-21 10:45:32.0
-0600
@@ -651,6 +651,7 @@
*/
PHP_MSHUTDOWN_FUNCTION(openssl)
{
+ ERR_free_strings();
EVP_cleanup();
return SUCCESS;
}
diff -Naur php-4.4.2/main/network.c php-fixed/main/network.c
--- php-4.4.2/main/network.c 2006-01-01 07:46:59.0 -0600
+++ php-4.4.2/main/network.c 2006-02-21 10:45:27.0 -0600
@@ -1091,11 +1091,14 @@
if (close_handle) {
#ifdef HAVE_OPENSSL_EXT
+
if (sock-ssl_active) {
SSL_shutdown(sock-ssl_handle);
sock-ssl_active = 0;
}
if (sock-ssl_handle) {
+ SSL_CTX *ctx = SSL_get_SSL_CTX(sock-ssl_handle);
+ SSL_CTX_free(ctx);
SSL_free(sock-ssl_handle);
sock-ssl_handle = NULL;
}
Reproduce code:
---
?php
readfile(https://secure.townnews.com/;);
?
Expected result:
No memory leaks.
Actual result:
--
==2610==
==2610== ERROR SUMMARY: 8076 errors from 411 contexts (suppressed: 0
from 0)
==2610== malloc/free: in use at exit: 25,224 bytes in 1,608 blocks.
==2610== malloc/free: 7,727 allocs, 6,119 frees, 555,906 bytes
allocated.
==2610== For counts of detected errors, rerun with: -v
==2610== searching for pointers to 1,608 not-freed blocks.
==2610== checked 607,512 bytes.
==2610==
==2610==
==2610== 28 bytes in 1 blocks are possibly lost in loss record 1 of 6
==2610==at 0x40211F9: malloc (vg_replace_malloc.c:149)
==2610==by 0x441DED4: strdup (in /lib/libc-2.3.5.so)
==2610==by 0x8153FD5: (within /usr/bin/php)
==2610==by 0x8155BB5: php_module_startup (in /usr/bin/php)
==2610==by 0x819F4A9: main (in /usr/bin/php)
==2610==
==2610==
==2610== 1,220 (248 direct, 972 indirect) bytes in 1 blocks are
definitely lost in loss record 2 of 6
==2610==at 0x40211F9: malloc (vg_replace_malloc.c:149)
==2610==by 0x4221B69: (within /lib/libcrypto.so.0.9.7f)
==2610==by 0x4222110: CRYPTO_malloc (in /lib/libcrypto.so.0.9.7f)
==2610==by 0x41DF1D9: SSL_CTX_new (in /lib/libssl.so.0.9.7f)
==2610==by 0x81668C3: php_stream_sock_ssl_activate_with_method (in
/usr/bin/php)
==2610==by 0x8119CDD: php_stream_url_wrap_http_ex (in
/usr/bin/php)
==2610==by 0x811B51F: php_stream_url_wrap_http (in /usr/bin/php)
==2610==by 0x81656FB: _php_stream_open_wrapper_ex (in
/usr/bin/php)
==2610==by 0x80E0FF0: zif_readfile (in /usr/bin/php)
==2610==by 0x8198E71: execute (in /usr/bin/php)
==2610==by 0x8186581: zend_execute_scripts (in /usr/bin/php)
==2610==by 0x8156BE1: php_execute_script (in /usr/bin/php)
==2610==
==2610==
==2610== 460 bytes in 12 blocks are indirectly lost in loss record 3 of
6
==2610==at 0x40211F9: malloc (vg_replace_malloc.c:149)
==2610==by 0x4221B69: (within /lib/libcrypto.so.0.9.7f)
==2610==by 0x4222110: CRYPTO_malloc (in /lib/libcrypto.so
#36480 [NEW]: OpenSSL Memory Leaks
From: polone at townnews dot com
Operating system: RedHat FC4
PHP version: 4.4.2
PHP Bug Type: OpenSSL related
Bug description: OpenSSL Memory Leaks
Description:
The OpenSSL extension in PHP leaks memory. Using valgrind, I was able to
determine that there is a consistent leak of about 20K. There are two
leaks, one is the result of calling SSL_get_ex_new_index() during MINIT
which doesn't supply any mechanism for free_func (according to the
prototype). The other leak, which accounts for about 19K, is from loading
error strings but not calling the relevant free() function.
Another problem was noticed in network.c. There is a call to
SSL_CTX_new(), but no corresponding SSL_CTX_free() when the socket is
closed. Because the pointer for ctx is localized, the original pointer is
lost - using SSL_get_SSL_CTX() allows you to retrieve the context and free
it properly before call SSL_free() during socket close.
I've included a patch which corrects two of the issues:
diff -Naur php-4.4.2/ext/openssl/openssl.c
php-fixed/ext/openssl/openssl.c
--- php-4.4.2/ext/openssl/openssl.c 2006-01-01 07:46:55.0
-0600
+++ php-4.4.2/ext/openssl/openssl.c 2006-02-21 10:45:32.0
-0600
@@ -651,6 +651,7 @@
*/
PHP_MSHUTDOWN_FUNCTION(openssl)
{
+ ERR_free_strings();
EVP_cleanup();
return SUCCESS;
}
diff -Naur php-4.4.2/main/network.c php-fixed/main/network.c
--- php-4.4.2/main/network.c 2006-01-01 07:46:59.0 -0600
+++ php-4.4.2/main/network.c 2006-02-21 10:45:27.0 -0600
@@ -1091,11 +1091,14 @@
if (close_handle) {
#ifdef HAVE_OPENSSL_EXT
+
if (sock-ssl_active) {
SSL_shutdown(sock-ssl_handle);
sock-ssl_active = 0;
}
if (sock-ssl_handle) {
+ SSL_CTX *ctx = SSL_get_SSL_CTX(sock-ssl_handle);
+ SSL_CTX_free(ctx);
SSL_free(sock-ssl_handle);
sock-ssl_handle = NULL;
}
Reproduce code:
---
?php
readfile(https://secure.townnews.com/;);
?
Expected result:
No memory leaks.
Actual result:
--
==2610==
==2610== ERROR SUMMARY: 8076 errors from 411 contexts (suppressed: 0 from
0)
==2610== malloc/free: in use at exit: 25,224 bytes in 1,608 blocks.
==2610== malloc/free: 7,727 allocs, 6,119 frees, 555,906 bytes allocated.
==2610== For counts of detected errors, rerun with: -v
==2610== searching for pointers to 1,608 not-freed blocks.
==2610== checked 607,512 bytes.
==2610==
==2610==
==2610== 28 bytes in 1 blocks are possibly lost in loss record 1 of 6
==2610==at 0x40211F9: malloc (vg_replace_malloc.c:149)
==2610==by 0x441DED4: strdup (in /lib/libc-2.3.5.so)
==2610==by 0x8153FD5: (within /usr/bin/php)
==2610==by 0x8155BB5: php_module_startup (in /usr/bin/php)
==2610==by 0x819F4A9: main (in /usr/bin/php)
==2610==
==2610==
==2610== 1,220 (248 direct, 972 indirect) bytes in 1 blocks are definitely
lost in loss record 2 of 6
==2610==at 0x40211F9: malloc (vg_replace_malloc.c:149)
==2610==by 0x4221B69: (within /lib/libcrypto.so.0.9.7f)
==2610==by 0x4222110: CRYPTO_malloc (in /lib/libcrypto.so.0.9.7f)
==2610==by 0x41DF1D9: SSL_CTX_new (in /lib/libssl.so.0.9.7f)
==2610==by 0x81668C3: php_stream_sock_ssl_activate_with_method (in
/usr/bin/php)
==2610==by 0x8119CDD: php_stream_url_wrap_http_ex (in /usr/bin/php)
==2610==by 0x811B51F: php_stream_url_wrap_http (in /usr/bin/php)
==2610==by 0x81656FB: _php_stream_open_wrapper_ex (in /usr/bin/php)
==2610==by 0x80E0FF0: zif_readfile (in /usr/bin/php)
==2610==by 0x8198E71: execute (in /usr/bin/php)
==2610==by 0x8186581: zend_execute_scripts (in /usr/bin/php)
==2610==by 0x8156BE1: php_execute_script (in /usr/bin/php)
==2610==
==2610==
==2610== 460 bytes in 12 blocks are indirectly lost in loss record 3 of 6
==2610==at 0x40211F9: malloc (vg_replace_malloc.c:149)
==2610==by 0x4221B69: (within /lib/libcrypto.so.0.9.7f)
==2610==by 0x4222110: CRYPTO_malloc (in /lib/libcrypto.so.0.9.7f)
==2610==by 0x41E0172: ssl_cert_new (in /lib/libssl.so.0.9.7f)
==2610==by 0x41DF2D0: SSL_CTX_new (in /lib/libssl.so.0.9.7f)
==2610==by 0x81668C3: php_stream_sock_ssl_activate_with_method (in
/usr/bin/php)
==2610==by 0x8119CDD: php_stream_url_wrap_http_ex (in /usr/bin/php)
==2610==by 0x811B51F: php_stream_url_wrap_http (in /usr/bin/php)
==2610==by 0x81656FB: _php_stream_open_wrapper_ex (in /usr/bin/php)
==2610==by 0x80E0FF0: zif_readfile (in /usr/bin/php)
==2610==by 0x8198E71: execute (in /usr/bin/php)
==2610==by 0x8186581: zend_execute_scripts (in /usr/bin/php)
==2610==
==2610==
==2610== 512 bytes in 2 blocks are indirectly lost in loss record 4 of 6
==2610==at 0x40212ED: realloc (vg_replace_malloc.c:306)
==2610==by 0x4221B94: (within /lib/libcrypto.so.0.9.7f)
==2610==by 0x42221E3: CRYPTO_realloc (in /lib/libcrypto.so.0.9.7f)
==2610==by 0x426C6AF: sk_insert (in /lib/libcrypto.so.0.9.7f)
==2610==by 0x426C7B9: sk_push
#33210 [Csd-Opn]: getimagesize() fails to detect width/height on certain JPEGs
ID: 33210
User updated by: polone at townnews dot com
Reported By: polone at townnews dot com
-Status: Closed
+Status: Open
Bug Type: GetImageSize related
Operating System: RedHat Linux 7.3
PHP Version: 4.3.11
New Comment:
This is NOT fixed. Raising the limit to 25 0xFF markers doesn't fix
this issue - it merely fixes certain JPEGs that have less than 25 0xFF
markers, but not all.
Previous Comments:
[2005-06-02 00:29:29] [EMAIL PROTECTED]
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
[2005-06-01 07:54:18] polone at townnews dot com
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records
that are found in sequential order. As far as I can tell ... the JPEG
file format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper
behavior in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing a in the marker's main loop around line 404:
if (++a 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the
reality is EOF will do that for us anyway. To fix the problem, just
switch that code hunk too:
a++;
Reproduce code:
---
?php
$sURL = http://www.townnews.com/contrib/premature.jpg;;
print_r(getimagesize($sURL));
?
Expected result:
Array
(
[0] = 350
[1] = 603
[2] = 2
[3] = width=350 height=603
[bits] = 8
[channels] = 3
[mime] = image/jpeg
)
--
Edit this bug report at http://bugs.php.net/?id=33210edit=1
#33210 [NEW]: getimagesize() fails to detect width/height on certain JPEGs
From: polone at townnews dot com
Operating system: RedHat Linux 7.3
PHP version: 4.3.11
PHP Bug Type: GetImageSize related
Bug description: getimagesize() fails to detect width/height on certain JPEGs
Description:
The getimagesize() function fails on specific JPEG files. The reason is
that php_next_marker() in:
ext/standard/image.c
has an artificial limit of 10 imposed on the number of 0xFF records that
are found in sequential order. As far as I can tell ... the JPEG file
format standards impose no such limit (see,
http://www.jpeg.org/public/jfif.pdf). The proper behaviour should be to
continue to read for the next marker until:
(1) M_SOS is found, in which case, image data has begun and no more
headers will occur
(2) M_EOI has occurred (End of Image header) - this is the proper behavior
in a properly encoded image
(3) EOF - something's wrong - but, at least it's not getimagesize()
I've provided an example of a JPEG file that will fail using
getimagesize() online at:
http://www.townnews.com/contrib/premature.jpg
A fix is easily added by removing the artificial limit and just
incrementing a in the marker's main loop around line 404:
if (++a 10)
{
/* who knows the maxim amount of 0xff? though 7 */
/* but found other implementations */
return M_EOI;
}
I realize this may be in place to prevent infinite loops, but the reality
is EOF will do that for us anyway. To fix the problem, just switch that
code hunk too:
a++;
Reproduce code:
---
?php
$sURL = http://www.townnews.com/contrib/premature.jpg;;
print_r(getimagesize($sURL));
?
Expected result:
Array
(
[0] = 350
[1] = 603
[2] = 2
[3] = width=350 height=603
[bits] = 8
[channels] = 3
[mime] = image/jpeg
)
--
Edit bug report at http://bugs.php.net/?id=33210edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=33210r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=33210r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=33210r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=33210r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=33210r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=33210r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=33210r=needscript
Try newer version: http://bugs.php.net/fix.php?id=33210r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=33210r=support
Expected behavior: http://bugs.php.net/fix.php?id=33210r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=33210r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=33210r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=33210r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=33210r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=33210r=dst
IIS Stability: http://bugs.php.net/fix.php?id=33210r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=33210r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=33210r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=33210r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=33210r=mysqlcfg
#31167 [NEW]: mail() is not RFC 822 compliant
From: polone at townnews dot com Operating system: RedHat Linux 7.3 PHP version: 4.3.10 PHP Bug Type: Mail related Bug description: mail() is not RFC 822 compliant Description: Please note, I have READ ticket #30226 - this person was right, but for the wrong reasons. The mail() function is not RFC822 compliant: BEGIN RFC822 SNIPPET 3.2. HEADER FIELD DEFINITIONS These rules show a field meta-syntax, without regard for the particular type or internal syntax. Their purpose is to permit detection of fields; also, they present to higher-level parsers an image of each field as fitting on one line. field = field-name : [ field-body ] CRLF END RFC822 SNIPPET All header fields inserted by PHP's mail() function are only separated with LF. Note that this causes issues with RFC822 compliant MTAs. The file where this is occuring is in ext/standard/mail.c, lines 228-233. As it turns out, probably anywhere you are doing LF you should be doing CRLF. References: RFC822 http://www.faqs.org/rfcs/rfc822.html Reproduce code: --- ?php mail([EMAIL PROTECTED], RFC822 problems, This message fails RFC822 compliance!); ? Expected result: The generated mail message should be: To: [EMAIL PROTECTED] Subject: RFC822 problems\r\n \r\n This message fails RFC822 compliance!\r\n Actual result: -- To: [EMAIL PROTECTED] Subject: RFC822 problems\n \n This message fails RFC822 compliance!\n -- Edit bug report at http://bugs.php.net/?id=31167edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31167r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=31167r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=31167r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=31167r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=31167r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=31167r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=31167r=needscript Try newer version: http://bugs.php.net/fix.php?id=31167r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=31167r=support Expected behavior: http://bugs.php.net/fix.php?id=31167r=notwrong Not enough info: http://bugs.php.net/fix.php?id=31167r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=31167r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=31167r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31167r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=31167r=dst IIS Stability: http://bugs.php.net/fix.php?id=31167r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=31167r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=31167r=float No Zend Extensions: http://bugs.php.net/fix.php?id=31167r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=31167r=mysqlcfg
#25316 [NEW]: _php_stream_write() gets stuck in infinite loop on any error to send()
From: polone at townnews dot com
Operating system: Any
PHP version: 4.3.3
PHP Bug Type: *PDF functions
Bug description: _php_stream_write() gets stuck in infinite loop on any error to
send()
Description:
(Please note, this looks like a similiar bug as #22753, but it is not -
it's in a function layer much more abstract than the main/network.c bug,
this one is in main/streams.c)
A problem that occurs quite often with PHP scripts when remote hosts
disconnect applications in PHP using the streams API is infinite looping
with SIGPIPE. It appears an early attempt to remedy the situation was to
ignore SIGPIPE, but this is not where the problem is. After reviewing the
_php_stream_write() code and testing the loop in an error condition of -1,
it became obvious why the looping occurs.
The while() loop will never exit if an error occurs in the underlying
send() call. This is because it returns a negative value (-1), but the
type assigned in _php_stream_write() is size_t for the variable justwrote.
For reference, size_t IS AN UNSIGNED INT, which means the condition:
if (justwrote 0) {
// Buffering code
} else {
break;
}
will never execute the else condition. To fix this, change the
following:
size_t didwrite = 0, towrite;
int justwrote;
This bug has been present (as far as I can tell) since PHP 4.3.0. In
addition, another change I've made is too main/network.c, in the
php_sockop_write() function. Instead of ignoring SIGPIPE as the default
handler, it would be better to set:
didwrite = send(sock-socket, buf, count, MSG_NOSIGNAL);
This will still work correctly when SIGPIPE would have been issued as
EPIPE is still returned.
Reproduce code:
---
?php
$fp = fsockopen (localhost, 80);
while(fwrite($fp, GET /doesntmatter HTTP/1.0\n\n)) {
sleep(1);
}
?
Expected result:
To end eventually. Instead, the script will eventually issue a SIGPIPE and
create an infinite loop.
Actual result:
--
It never ends.
--
Edit bug report at http://bugs.php.net/?id=25316edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25316r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25316r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=25316r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=25316r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=25316r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=25316r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=25316r=support
Expected behavior: http://bugs.php.net/fix.php?id=25316r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=25316r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=25316r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=25316r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25316r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=25316r=dst
IIS Stability: http://bugs.php.net/fix.php?id=25316r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=25316r=gnused
#25316 [Opn]: _php_stream_write() gets stuck in infinite loop on any error to send()
ID: 25316
User updated by: polone at townnews dot com
Reported By: polone at townnews dot com
Status: Open
-Bug Type: *PDF functions
+Bug Type: Reproducible crash
Operating System: Any
PHP Version: 4.3.3
New Comment:
Changing category to a reproducible crash, accidentally set it to *PDF
Functions.
Previous Comments:
[2003-08-29 13:49:54] polone at townnews dot com
Description:
(Please note, this looks like a similiar bug as #22753, but it is not -
it's in a function layer much more abstract than the main/network.c
bug, this one is in main/streams.c)
A problem that occurs quite often with PHP scripts when remote hosts
disconnect applications in PHP using the streams API is infinite
looping with SIGPIPE. It appears an early attempt to remedy the
situation was to ignore SIGPIPE, but this is not where the problem is.
After reviewing the _php_stream_write() code and testing the loop in an
error condition of -1, it became obvious why the looping occurs.
The while() loop will never exit if an error occurs in the underlying
send() call. This is because it returns a negative value (-1), but the
type assigned in _php_stream_write() is size_t for the variable
justwrote. For reference, size_t IS AN UNSIGNED INT, which means the
condition:
if (justwrote 0) {
// Buffering code
} else {
break;
}
will never execute the else condition. To fix this, change the
following:
size_t didwrite = 0, towrite;
int justwrote;
This bug has been present (as far as I can tell) since PHP 4.3.0. In
addition, another change I've made is too main/network.c, in the
php_sockop_write() function. Instead of ignoring SIGPIPE as the default
handler, it would be better to set:
didwrite = send(sock-socket, buf, count, MSG_NOSIGNAL);
This will still work correctly when SIGPIPE would have been issued as
EPIPE is still returned.
Reproduce code:
---
?php
$fp = fsockopen (localhost, 80);
while(fwrite($fp, GET /doesntmatter HTTP/1.0\n\n)) {
sleep(1);
}
?
Expected result:
To end eventually. Instead, the script will eventually issue a SIGPIPE
and create an infinite loop.
Actual result:
--
It never ends.
--
Edit this bug report at http://bugs.php.net/?id=25316edit=1
#22384 [NEW]: FNM_CASEFOLD is not available
From: polone at townnews dot com
Operating system: RedHat Linux 7.3
PHP version: 4.3.1
PHP Bug Type: Directory function related
Bug description: FNM_CASEFOLD is not available
The predefined constant FNM_CASEFOLD does not exist for the fnmatch()
function. The function call does work by calling the function using:
fnmatch('pattern*','match-this', 16);
At least, on RedHat Linux this will work because the flag is a left bit
shift 1 4. Probably just not defined in the PHP extension as a flag
(although I haven't checked).
The flag allows case-insensitive comparisons to the string being matched.
Using the integer constant directly shouldn't break anything if the
constant is later added, just an annoyance as far as looking at source is
concerned.
Regards,
Patrick O'Lone
--
Edit bug report at http://bugs.php.net/?id=22384edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=22384r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=22384r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=22384r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=22384r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=22384r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=22384r=support
Expected behavior: http://bugs.php.net/fix.php?id=22384r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=22384r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=22384r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=22384r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22384r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=22384r=dst
IIS Stability: http://bugs.php.net/fix.php?id=22384r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=22384r=gnused
#21497 [NEW]: include() of XML document fails
From: [EMAIL PROTECTED] Operating system: RedHat Linux 6.2 PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: include() of XML document fails When using the include(), include_once(), require(), or require_once() functions, documents beginning with: ?xml version=1.0? fail to be loaded. I'm guessing this might have to do with PHP trying to interpret the ?xml as ?php, causing a fatal error. Proper operation should check for the processing instruction (PI) value of ?, that is: ? or ?php maybe interpreted as PHP, but not, ?some_other_text at the very least, not: ?xml -- Edit bug report at http://bugs.php.net/?id=21497edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21497r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21497r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21497r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21497r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21497r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21497r=support Expected behavior: http://bugs.php.net/fix.php?id=21497r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21497r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21497r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21497r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21497r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21497r=dst IIS Stability: http://bugs.php.net/fix.php?id=21497r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21497r=gnused
#21497 [Bgs]: include() of XML document fails
ID: 21497 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat Linux 6.2 PHP Version: 4.3.0 New Comment: That does fix the problem, but enabling short open tags shouldn't invalidate properly formatted processing instructions for something other than PHP. In addition, this cannot be altered or disabled by ini_set() from a PHP script (perhaps a security risk?) at run-time. Previous Comments: [2003-01-07 13:17:31] [EMAIL PROTECTED] Disable short_open_tags in your php.ini and the problem will go away. [2003-01-07 13:15:12] [EMAIL PROTECTED] When using the include(), include_once(), require(), or require_once() functions, documents beginning with: ?xml version=1.0? fail to be loaded. I'm guessing this might have to do with PHP trying to interpret the ?xml as ?php, causing a fatal error. Proper operation should check for the processing instruction (PI) value of ?, that is: ? or ?php maybe interpreted as PHP, but not, ?some_other_text at the very least, not: ?xml -- Edit this bug report at http://bugs.php.net/?id=21497edit=1
#20420 [Com]: parse_url broken on partial URLs
ID: 20420
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: URL related
Operating System: Linux
PHP Version: 4.3.0-pre2
Assigned To: ilia
New Comment:
As a result of this bug, has the function been changed to now parse
file:///path/to/file as:
Array(2) (
[scheme] = 'file'
[host] = '/path/to/file'
)
That seems incorrect, as it use to:
Array(2) (
[scheme] = 'file'
[path] = '/path/to/file'
)
Which is correct, and how the function use to behave. If anything, the
[host] should state localhost. Needless to say, this should be now
documented in the function manual if this is going to be the way it
works.
Previous Comments:
[2002-11-14 07:46:28] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-11-14 03:13:06] [EMAIL PROTECTED]
Assinging to Ilia
[2002-11-14 02:56:30] [EMAIL PROTECTED]
In 4.2.x, parsing the partial URL /foo.php?a=bc=d
returned
array(2) {
[path]=
string(8) /foo.php
[query]=
string(7) a=bc=d
}
but in 4.3.0-pre2 the query part is not recognized an
parse_url() return
array(1) {
[path]=
string(16) /foo.php?a=bc=d
}
The parse_url() function also have problems with URLs like
file:///foo.txt, where the host is absent, and mailto:user@domain;.
Both URLs were handled properly in 4.2.x
--
Edit this bug report at http://bugs.php.net/?id=20420edit=1
#20420 [Com]: parse_url broken on partial URLs
ID: 20420
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: URL related
Operating System: Linux
PHP Version: 4.3.0-pre2
Assigned To: ilia
New Comment:
The aforementioned was found in PHP 4.3.0, production, on an RH 6.2
Linux box.
Previous Comments:
[2002-12-31 02:59:09] [EMAIL PROTECTED]
As a result of this bug, has the function been changed to now parse
file:///path/to/file as:
Array(2) (
[scheme] = 'file'
[host] = '/path/to/file'
)
That seems incorrect, as it use to:
Array(2) (
[scheme] = 'file'
[path] = '/path/to/file'
)
Which is correct, and how the function use to behave. If anything, the
[host] should state localhost. Needless to say, this should be now
documented in the function manual if this is going to be the way it
works.
[2002-11-14 07:46:28] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-11-14 03:13:06] [EMAIL PROTECTED]
Assinging to Ilia
[2002-11-14 02:56:30] [EMAIL PROTECTED]
In 4.2.x, parsing the partial URL /foo.php?a=bc=d
returned
array(2) {
[path]=
string(8) /foo.php
[query]=
string(7) a=bc=d
}
but in 4.3.0-pre2 the query part is not recognized an
parse_url() return
array(1) {
[path]=
string(16) /foo.php?a=bc=d
}
The parse_url() function also have problems with URLs like
file:///foo.txt, where the host is absent, and mailto:user@domain;.
Both URLs were handled properly in 4.2.x
--
Edit this bug report at http://bugs.php.net/?id=20420edit=1
#20745 [NEW]: socket_accept() in blocking mode doesn't handle signal interrupts
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.3
PHP Bug Type: Sockets related
Bug description: socket_accept() in blocking mode doesn't handle signal interrupts
The socket_accept() function doesn't appear to handle kernel level system
interrupts. This is a problem because PHP scripts written to use
pcntl_signal() won't be executed while socket_accept() is in blocking
mode. THAT is a problem because the script can't be killed with:
kill -s SIGUSR1 [pid]
and can't reap zombie processes when SIGCHLD is given (not that is much of
a problem on Linux, since you can use SIG_IGN).
A workaround I've made is to set a socket to non-blocking mode:
socket_set_nonblock($hSocket);
And then use a while loop like so:
while (($hClient = @socket_accept($hSocket)) === false) {
// If this is a real error, we need to handle it. Unfortunately, in
this
// event we just die() essentially.
if (!is_resource($hSocket)) {
error_log(socket_strerror(socket_last_error($hSocket)));
exit;
}
// We need to sleep for one second so that CPU isn't absorbed with
this
// process. This may seem clunky, but select() doesn't appear to
work
// correctly with accept() in PHP in blocking mode (that is EINTR
does
// not appear to work correctly), thus preventing signals from
being
// received. This, in effect, makes the process unkillable. This is
the
// workaround, for the moment.
sleep(1);
}
While this works, it would be much better if it just returned when a
system interrupt is given like the C-equivalent does. This works because
the system can't receive messages from the kernel because it isn't
blocking.
--
Edit bug report at http://bugs.php.net/?id=20745edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=20745r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=20745r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=20745r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=20745r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=20745r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=20745r=support
Expected behavior: http://bugs.php.net/fix.php?id=20745r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=20745r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=20745r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=20745r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20745r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=20745r=dst
IIS Stability: http://bugs.php.net/fix.php?id=20745r=isapi
Bug #17323: posix_isatty wants a long instead of resource
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.2.0
PHP Bug Type: POSIX related
Bug description: posix_isatty wants a long instead of resource
The bug seems rather simple. Using command-line PHP, the following fragment
should work:
#!/usr/bin/php -q
?php
$fd = fopen('php://stdout','w');
if (posix_isatty($fd))
print yes, it is a terminal\n;
else
print no, it is not a terminal\n;
?
However, it appears that the function definition requires a long passed,
instead of a resource. The error message reported is:
dns:root-/usr/bin ./test.php
PHP Warning: posix_isatty() expects parameter 1 to be long, resource
given in /usr/bin/test.php on line 4
br /
bWarning/b: posix_isatty() expects parameter 1 to be long, resource
given in b/usr/bin/test.php/b on line b4/b
br /
no, it is not a terminal
A workaround appears to be the following:
#!/usr/bin/php -q
?php
$fd = fopen('php://stdout','w');
settype($fd,'int');
if (posix_isatty($fd))
print yes, it is a terminal\n;
else
print no, it is not a terminal\n;
?
The explicit type-cast fixes the problem. Maybe I have settings in the
php.ini file wrong, but I don't think this function should behave like
this. Perhaps it requires just a change to the source. This is also broke
with posix_ttyname(). Am I suppose to acquire a file descriptor another
way?
Regards,
Patrick O'Lone
--
Edit bug report at http://bugs.php.net/?id=17323edit=1
--
Fixed in CVS:http://bugs.php.net/fix.php?id=17323r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=17323r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=17323r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=17323r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=17323r=support
Expected behavior: http://bugs.php.net/fix.php?id=17323r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=17323r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=17323r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=17323r=globals
