#46167 [Bgs]: ispostback
ID: 46167 User updated by: freempp3 at hotmail dot com Reported By: freempp3 at hotmail dot com Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.6 New Comment: Dear, I know session handling is in the core of php, i ment the possibility of a postback method. Kind regards Previous Comments: [2008-09-24 23:39:48] [EMAIL PROTECTED] session is in core.. [2008-09-24 12:25:27] freempp3 at hotmail dot com Description: Request: ispostback functionality as in c-sharp. Possibility to check if a form is resent or recalled by the back-functionality of the browser. I know it's possible to do so by session. But i think many people will like the functionality in the core itself. -- Edit this bug report at http://bugs.php.net/?id=46167&edit=1
#45808 [NoF->Opn]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 User updated by: six at aegis-corp dot org Reported By: six at aegis-corp dot org -Status: No Feedback +Status: Open Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 New Comment: the bug is still present in php5.3-200809232030 Previous Comments: [2008-09-24 01:20:29] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-23 01:00:00] 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". [2008-09-15 07:22:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-08-13 17:41:01] six at aegis-corp dot org Description: The documentation says about stream_socket_enable_crypto : Returns TRUE on success, FALSE if negotiation has failed or 0 if there isn't enough data and you should try again (only for non-blocking sockets). In practice, if you feed a non blocking server socket to it, it will block and consume lots of CPU until the SSL/TLS handshake is done or the client connection is dropped. Reproduce code: --- then just "telnet localhost " from another term Expected result: script should print "int(0)" and exit Actual result: -- script blocks at the stream_socket_enable_crypto() call and is stuck in a CPU consuming loop until the client connection is either handshaked or dropped. -- Edit this bug report at http://bugs.php.net/?id=45808&edit=1
#46171 [NEW]: stream_bucket_new don't work with write streams
From: Keisial at gmail dot com
Operating system:
PHP version: 5.3CVS-2008-09-25 (snap)
PHP Bug Type: Streams related
Bug description: stream_bucket_new don't work with write streams
Description:
Calling stream_bucket_new on a write stream doesn't work (the same code
fopening for reading works).
Reproduce code:
---
http://php.net/manual/function.stream-filter-register.php **/
/* Define our filter class */
class strtoupper_filter extends php_user_filter {
function filter($in, $out, &$consumed, $closing)
{
$new_bucket = stream_bucket_new($this->stream, "Uppercase text: ");
if ($new_bucket === false) throw new Exception("stream_bucket_new
should have returned a bucket");
stream_bucket_append($out, $new_bucket);
while ($bucket = stream_bucket_make_writeable($in)) {
$bucket->data = strtoupper($bucket->data);
$consumed += $bucket->datalen;
stream_bucket_append($out, $bucket);
}
return PSFS_PASS_ON;
}
}
/* Register our filter with PHP */
stream_filter_register("strtoupper", "strtoupper_filter")
or die("Failed to register filter");
$fp = fopen("foo-bar.txt", "w");
/* Attach the registered filter to the stream just opened */
stream_filter_append($fp, "strtoupper");
fwrite($fp, "Line1\n");
fwrite($fp, "Word - 2\n");
fwrite($fp, "Easy As 123\n");
fclose($fp);
// Read the contents back out
readfile("foo-bar.txt");
?>
Actual result:
--
Warning: stream_bucket_new(): 5 is not a valid stream resource in
bucket_new_testcase.php on line 7
Fatal error: Uncaught exception 'Exception' with message
'stream_bucket_new should have returned a bucket'
Stack trace:
#0 [internal function]: strtoupper_filter->filter(Resource id #20,
Resource id #21, 0, true)
#1 bucket_new_testcase.php(36): fclose(Resource id #5)
#2 {main}
thrown in bucket_new_testcase.php on line 8
--
Edit bug report at http://bugs.php.net/?id=46171&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46171&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46171&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46171&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46171&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46171&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46171&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46171&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46171&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46171&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46171&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46171&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46171&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46171&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46171&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46171&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46171&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46171&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46171&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46171&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46171&r=mysqlcfg
#46172 [NEW]: fwrite refuses to write more then 32k to non-blocking socket
From: php at 3r1c dot eu Operating system: FreeBSD PHP version: 5.2.6 PHP Bug Type: Streams related Bug description: fwrite refuses to write more then 32k to non-blocking socket Description: fwrite refuses to write more then 32k to non-blocking socket. removing the stream_set_blocking line in my sample code will make the program work properly. It seems to get higher amount written on a localhost socket, about 120kb. Reproduce code: --- #!/usr/local/bin/php -q Expected result: Wrote 10 bytes Actual result: -- Wrote 32768 bytes -- Edit bug report at http://bugs.php.net/?id=46172&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46172&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46172&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46172&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46172&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46172&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46172&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46172&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46172&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46172&r=support Expected behavior:http://bugs.php.net/fix.php?id=46172&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46172&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46172&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46172&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46172&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46172&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46172&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46172&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46172&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46172&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46172&r=mysqlcfg
#46172 [Opn->Bgs]: fwrite refuses to write more then 32k to non-blocking socket
ID: 46172 Updated by: [EMAIL PROTECTED] Reported By: php at 3r1c dot eu -Status: Open +Status: Bogus Bug Type: Streams related Operating System: FreeBSD PHP Version: 5.2.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. The default tcp socket send buffer on FreeBSD is 32k, you need to change net.inet.tcp.sendspace to a higher value if you want to write more. Previous Comments: [2008-09-25 11:34:58] php at 3r1c dot eu Description: fwrite refuses to write more then 32k to non-blocking socket. removing the stream_set_blocking line in my sample code will make the program work properly. It seems to get higher amount written on a localhost socket, about 120kb. Reproduce code: --- #!/usr/local/bin/php -q Expected result: Wrote 10 bytes Actual result: -- Wrote 32768 bytes -- Edit this bug report at http://bugs.php.net/?id=46172&edit=1
#46091 [Opn]: php.ini not found in C:\windows
ID: 46091 User updated by: linda_petty at shelter dot org dot uk Reported By: linda_petty at shelter dot org dot uk Status: Open Bug Type: Windows Installer Operating System: windows 2003 SP2 PHP Version: 5.2.6 New Comment: on the 1st line of description I said windows 2003 (SP4) I meant (SP2) Previous Comments: [2008-09-16 09:07:34] linda_petty at shelter dot org dot uk Description: Installing AMP on windows 2003 (SP4). I found a BUG in this version of the windows PHP, apparently in the installer: PHP Version 5.2.6 (5.2 build 3790). We found the installation went fine on XP with this installer. BUT on windows 2003 (SP2)I found these values on the PHPINFO page after install: Configuration File (php.ini) Path: C:\WINDOWS Loaded Configuration File: (none) PHP had IGNORED my PHP.ini file which, as instructed by the install documentation, I had carefully placed in C:\WINDOWS I found it would only load my php.ini file if I placed it in C:\PHP5 (which is the default install directory). Once the php.ini file was in C:\PHP5, after restarting Apache, at last I see:- Loaded Configuration FileC:\PHP5\php.ini quite a timewaster! :0) Reproduce code: --- install with Zip installer on windows 2003 (SP2) using install directory C:\PHP to reproduce the problem Expected result: I would have expected Loaded Configuration FileC:\WINDOWS\php.ini Actual result: -- Loaded Configuration File: (none) -- Edit this bug report at http://bugs.php.net/?id=46091&edit=1
#46173 [NEW]: session used in a frameset produces wrong files in reply
From: pmioni at hce dot it Operating system: SOLARIS 10 PHP version: 5.2.6 PHP Bug Type: Session related Bug description: session used in a frameset produces wrong files in reply Description: This bug is (apparently) specific to Solaris. It cannot be replicated on our test CentOS machine. This is not the usual variation of "somebody not understanding how sessions work in a frameset" We have an e-learning application, called Dokeos (www.dokeos.com), which has a tool using framesets containing a set of frames, each pointing to a separate php file. All php files share the same session (which is rather large in terms of saved content) across the frames. The application behaves unpredictably: some frames load correctly, some load the content of other frames, some remain white. On refresh of the main frameset page, every frame misbehaves in a different way, so contents move around. Even refreshing individual frames keeps failing miserably. Basically, let's say that the frameset frameset.php calls files 1.php through file 6.php. The frame containing 2.php, upon first opening of the frameset and upon refresh, can contain the output of anything from 1.php to 6.php to the frameset.php itself, and even other pages which were browsed earlier on the same server. The problem is cross-browser, is not caused by Javascript (it happens when JS is blocked at browser level), and cannot be caused by wrong header() calls in the PHP code, since at least some of the files do not have any header() call anywhere, and still the system returns another file in their place. The same application (the same files, the same database, the same content) works just fine on our CentOS server, with the same version of PHP but Apache 1.3.41. Any help? Any suggestions? Here's the top of our phpinfo(): PHP Version 5.2.6 System SunOS rpol-c 5.10 Generic_127127-11 sun4v Build Date Jun 5 2008 19:14:30 Configure Command './configure' '--prefix=/opt/coolstack/php5' '--disable-debug' '--disable-dmalloc' '--disable-inline-optimization' '--disable-libgcc' '--disable-libtool-lock' '--disable-static' '--enable-calendar' '--enable-ctype' '--enable-cli' '--enable-cgi' '--enable-fastcgi' '--enable-dba=shared' '--enable-dbase' '--enable-dom' '--enable-exif' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-gd-jis-conv' '--enable-gd-native-ttf' '--enable-ipv6' '--enable-libxml' '--enable-magic-quotes' '--enable-mbregex' '--enable-mbstring' '--enable-pcntl' '--enable-pdo' '--enable-posix' '--enable-reflection' '--enable-safe-mode' '--enable-session' '--enable-shared' '--enable-shmop' '--enable-short-tags' '--enable-soap' '--enable-spl' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-ucd-snmp-hack' '--enable-wddx' '--enable-xmlreader' '--enable-zend-multibyte' '--with-bz2=shared,/usr' '--with-cdb' '--with-curl=shared,/opt/coolstack' '--with-curlwrappers' '--enable-flatfile' '--with-freetype-dir=/opt/coolstack' '--with-gd=shared,/opt/coolstack' '--with-gdbm=/opt/coolstack' '--with-gettext=shared,/opt/coolstack' '--with-gmp=shared,/opt/coolstack' '--with-iconv=shared,/opt/coolstack' '--with-imap-ssl=shared,/opt/coolstack/imap' '--with-imap=shared,/opt/coolstack/imap' '--enable-inifile' '--with-jpeg-dir=/usr' '--with-layout=PHP' '--with-ldap=shared,/opt/coolstack' '--with-ldap-sasl=yes' '--with-libexpat-dir=/opt/coolstack/apache2' '--with-libmbfl' '--with-libxml-dir=/opt/coolstack' '--enable-mod-charset' '--with-mssql=shared,/opt/coolstack' '--with-mysql-sock' '--with-mysql=shared,/opt/coolstack/mysql_32bit' '--with-mysqli=shared,/opt/coolstack/mysql_32bit/bin/mysql_config' '--with-ncurses=shared,/opt/coolstack' '--with-ndbm=/usr' '--with-openssl=shared,/opt/coolstack' '--with-pcre-dir=/opt/coolstack' '--with-pdo-dblib=shared,/opt/coolstack' '--with-pdo-mysql=shared,/opt/coolstack/mysql_32bit' '--with-pdo-odbc=shared,unixODBC,/opt/coolstack' '--with-pdo-pgsql=shared,/usr' '--with-pear' '--with-pgsql=shared,/usr' '--with-pic' '--with-png-dir=/usr' '--with-readline=shared,/opt/coolstack' '--with-pspell=shared,/usr' '--with-snmp=shared,/opt/coolstack' '--with-tidy=shared,/opt/coolstack' '--with-tsrm-pthreads' '--with-unixODBC=shared,/opt/coolstack' '--with-xmlrpc' '--with-xpm-dir=/usr/openwin' '--with-xsl=shared,/opt/coolstack' '--with-zend-vm=CALL' '--with-zlib=shared,/usr' '--without-dbm' '--without-ndbm' '--without-t1lib' '--x-includes=/usr/openwin/include' '--x-libraries=/usr/openwin/lib' '--with-apxs2=/opt/coolstack/apache2/bin/apxs' Server API Apache 2.0 Handler Virtual Directory Support disabled Configuration File (php.ini) Path /opt/coolstack/php5/lib Loaded Configuration File /opt/coolstack/php5/lib/php.ini Reproduce code: --- This would require login to a machine, and navigation in a site. Please contact me to reproduce the error. -- Edit bug report at http://bugs.php.net/?id=46173&edit=1 -- Try a CVS snapshot (PH
#46091 [Opn->Bgs]: php.ini not found in C:\windows
ID: 46091 Updated by: [EMAIL PROTECTED] Reported By: linda_petty at shelter dot org dot uk -Status: Open +Status: Bogus Bug Type: Windows Installer Operating System: windows 2003 SP2 PHP Version: 5.2.6 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. Please read the manual: http://www.php.net/manual/en/configuration.php Previous Comments: [2008-09-25 13:54:54] linda_petty at shelter dot org dot uk on the 1st line of description I said windows 2003 (SP4) I meant (SP2) [2008-09-16 09:07:34] linda_petty at shelter dot org dot uk Description: Installing AMP on windows 2003 (SP4). I found a BUG in this version of the windows PHP, apparently in the installer: PHP Version 5.2.6 (5.2 build 3790). We found the installation went fine on XP with this installer. BUT on windows 2003 (SP2)I found these values on the PHPINFO page after install: Configuration File (php.ini) Path: C:\WINDOWS Loaded Configuration File: (none) PHP had IGNORED my PHP.ini file which, as instructed by the install documentation, I had carefully placed in C:\WINDOWS I found it would only load my php.ini file if I placed it in C:\PHP5 (which is the default install directory). Once the php.ini file was in C:\PHP5, after restarting Apache, at last I see:- Loaded Configuration FileC:\PHP5\php.ini quite a timewaster! :0) Reproduce code: --- install with Zip installer on windows 2003 (SP2) using install directory C:\PHP to reproduce the problem Expected result: I would have expected Loaded Configuration FileC:\WINDOWS\php.ini Actual result: -- Loaded Configuration File: (none) -- Edit this bug report at http://bugs.php.net/?id=46091&edit=1
#46173 [Opn]: session used in a frameset produces wrong files in reply
ID: 46173 User updated by: pmioni at hce dot it Reported By: pmioni at hce dot it Status: Open Bug Type: Session related Operating System: SOLARIS 10 PHP Version: 5.2.6 New Comment: Please note that I'm just installing the application, as it has been created by a separate firm. My original text might have given the impression that we wrote it. Previous Comments: [2008-09-25 15:08:06] pmioni at hce dot it Description: This bug is (apparently) specific to Solaris. It cannot be replicated on our test CentOS machine. This is not the usual variation of "somebody not understanding how sessions work in a frameset" We have an e-learning application, called Dokeos (www.dokeos.com), which has a tool using framesets containing a set of frames, each pointing to a separate php file. All php files share the same session (which is rather large in terms of saved content) across the frames. The application behaves unpredictably: some frames load correctly, some load the content of other frames, some remain white. On refresh of the main frameset page, every frame misbehaves in a different way, so contents move around. Even refreshing individual frames keeps failing miserably. Basically, let's say that the frameset frameset.php calls files 1.php through file 6.php. The frame containing 2.php, upon first opening of the frameset and upon refresh, can contain the output of anything from 1.php to 6.php to the frameset.php itself, and even other pages which were browsed earlier on the same server. The problem is cross-browser, is not caused by Javascript (it happens when JS is blocked at browser level), and cannot be caused by wrong header() calls in the PHP code, since at least some of the files do not have any header() call anywhere, and still the system returns another file in their place. The same application (the same files, the same database, the same content) works just fine on our CentOS server, with the same version of PHP but Apache 1.3.41. Any help? Any suggestions? Here's the top of our phpinfo(): PHP Version 5.2.6 System SunOS rpol-c 5.10 Generic_127127-11 sun4v Build Date Jun 5 2008 19:14:30 Configure Command './configure' '--prefix=/opt/coolstack/php5' '--disable-debug' '--disable-dmalloc' '--disable-inline-optimization' '--disable-libgcc' '--disable-libtool-lock' '--disable-static' '--enable-calendar' '--enable-ctype' '--enable-cli' '--enable-cgi' '--enable-fastcgi' '--enable-dba=shared' '--enable-dbase' '--enable-dom' '--enable-exif' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-gd-jis-conv' '--enable-gd-native-ttf' '--enable-ipv6' '--enable-libxml' '--enable-magic-quotes' '--enable-mbregex' '--enable-mbstring' '--enable-pcntl' '--enable-pdo' '--enable-posix' '--enable-reflection' '--enable-safe-mode' '--enable-session' '--enable-shared' '--enable-shmop' '--enable-short-tags' '--enable-soap' '--enable-spl' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-ucd-snmp-hack' '--enable-wddx' '--enable-xmlreader' '--enable-zend-multibyte' '--with-bz2=shared,/usr' '--with-cdb' '--with-curl=shared,/opt/coolstack' '--with-curlwrappers' '--enable-flatfile' '--with-freetype-dir=/opt/coolstack' '--with-gd=shared,/opt/coolstack' '--with-gdbm=/opt/coolstack' '--with-gettext=shared,/opt/coolstack' '--with-gmp=shared,/opt/coolstack' '--with-iconv=shared,/opt/coolstack' '--with-imap-ssl=shared,/opt/coolstack/imap' '--with-imap=shared,/opt/coolstack/imap' '--enable-inifile' '--with-jpeg-dir=/usr' '--with-layout=PHP' '--with-ldap=shared,/opt/coolstack' '--with-ldap-sasl=yes' '--with-libexpat-dir=/opt/coolstack/apache2' '--with-libmbfl' '--with-libxml-dir=/opt/coolstack' '--enable-mod-charset' '--with-mssql=shared,/opt/coolstack' '--with-mysql-sock' '--with-mysql=shared,/opt/coolstack/mysql_32bit' '--with-mysqli=shared,/opt/coolstack/mysql_32bit/bin/mysql_config' '--with-ncurses=shared,/opt/coolstack' '--with-ndbm=/usr' '--with-openssl=shared,/opt/coolstack' '--with-pcre-dir=/opt/coolstack' '--with-pdo-dblib=shared,/opt/coolstack' '--with-pdo-mysql=shared,/opt/coolstack/mysql_32bit' '--with-pdo-odbc=shared,unixODBC,/opt/coolstack' '--with-pdo-pgsql=shared,/usr' '--with-pear' '--with-pgsql=shared,/usr' '--with-pic' '--with-png-dir=/usr' '--with-readline=shared,/opt/coolstack' '--with-pspell=shared,/usr' '--with-snmp=shared,/opt/coolstack' '--with-tidy=shared,/opt/coolstack' '--with-tsrm-pthreads' '--with-unixODBC=shared,/opt/coolstack' '--with-xmlrpc' '--with-xpm-dir=/usr/openwin' '--with-xsl=shared,/opt/coolstack' '--with-zend-vm=CALL' '--with-zlib=shared,/usr' '--without-dbm' '--without-ndbm' '--without-t1lib' '--x-includes=/usr/openwin/include' '--x-libraries=/usr/openwin/lib' '--with-apxs2=/opt/coolstack/apache2/bin/apxs' Server API Apache 2.0 Handler Virtual Directory Support disabled Configuration File (php
#45808 [Com]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 Comment by: nasam at mailvault dot com Reported By: six at aegis-corp dot org Status: Open Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 New Comment: Bug is in ext/openssl/xp_ssl.c Function handle_ssl_error: (line 107) case SSL_ERROR_WANT_READ: case SSL_ERROR_WANT_WRITE: /* re-negotiation, or perhaps the SSL layer needs more * packets: retry in next iteration */ errno = EAGAIN; retry = is_init ? 1 : sslsock->s.is_blocked; //BUG break; it sets retry to 1 in php_openssl_enable_crypto no matter if socket is blocking or not. Previous Comments: [2008-09-25 10:06:09] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-24 01:20:29] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-23 01:00:00] 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". [2008-09-15 07:22:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi [2008-08-13 17:41:01] six at aegis-corp dot org Description: The documentation says about stream_socket_enable_crypto : Returns TRUE on success, FALSE if negotiation has failed or 0 if there isn't enough data and you should try again (only for non-blocking sockets). In practice, if you feed a non blocking server socket to it, it will block and consume lots of CPU until the SSL/TLS handshake is done or the client connection is dropped. Reproduce code: --- then just "telnet localhost " from another term Expected result: script should print "int(0)" and exit Actual result: -- script blocks at the stream_socket_enable_crypto() call and is stuck in a CPU consuming loop until the client connection is either handshaked or dropped. -- Edit this bug report at http://bugs.php.net/?id=45808&edit=1
#46174 [NEW]: _pcre_utt_names is overridden from libpcre.so and results in \p match failure
From: pageexec at freemail dot hu
Operating system: linux
PHP version: 5.2.6
PHP Bug Type: PCRE related
Bug description: _pcre_utt_names is overridden from libpcre.so and results in
\p match failure
Description:
the pcre extension contains a copy of some specific version of libpcre,
with most of the names prefixed with php_ except for _pcre_utt_names which
is not prefixed. this means that if a libphp user such as apache2 also
happens to load libpcre (mine's directly linked against it so it loads
before libphp), the symbols from the latter may override _pcre_utt_names
and libphp will use the wrong names table when analyzing \p and \P (the
indices would come from php__pcre_utt which is specific for the
_pcre_utt_names table contained in the pcre extension).
Reproduce code:
---
preg_match_all("/\pL/u", "php", $matches);
print_r($matches);
Expected result:
Array
(
[0] => Array
(
[0] => p
[1] => h
[2] => p
)
)
Actual result:
--
Warning: preg_match_all() [function.preg-match-all]: Compilation failed:
unknown property name after \P or \p at offset 3 in on line
--
Edit bug report at http://bugs.php.net/?id=46174&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46174&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46174&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46174&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46174&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46174&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46174&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46174&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46174&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46174&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46174&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46174&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46174&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46174&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46174&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46174&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46174&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46174&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46174&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46174&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46174&r=mysqlcfg
#46174 [Com]: _pcre_utt_names is overridden from libpcre.so and results in \p match failure
ID: 46174
Comment by: pageexec at freemail dot hu
Reported By: pageexec at freemail dot hu
Status: Open
Bug Type: PCRE related
Operating System: linux
PHP Version: 5.2.6
New Comment:
i guess the simple fix is to add
#define _pcre_utt_names php__pcre_utt_names
to main/php_compat.h.
Previous Comments:
[2008-09-25 16:13:04] pageexec at freemail dot hu
Description:
the pcre extension contains a copy of some specific version of libpcre,
with most of the names prefixed with php_ except for _pcre_utt_names
which is not prefixed. this means that if a libphp user such as apache2
also happens to load libpcre (mine's directly linked against it so it
loads before libphp), the symbols from the latter may override
_pcre_utt_names and libphp will use the wrong names table when analyzing
\p and \P (the indices would come from php__pcre_utt which is specific
for the _pcre_utt_names table contained in the pcre extension).
Reproduce code:
---
preg_match_all("/\pL/u", "php", $matches);
print_r($matches);
Expected result:
Array
(
[0] => Array
(
[0] => p
[1] => h
[2] => p
)
)
Actual result:
--
Warning: preg_match_all() [function.preg-match-all]: Compilation
failed: unknown property name after \P or \p at offset 3 in
on line
--
Edit this bug report at http://bugs.php.net/?id=46174&edit=1
#46174 [Opn->Fbk]: _pcre_utt_names is overridden from libpcre.so and results in \p match failure
ID: 46174
Updated by: [EMAIL PROTECTED]
Reported By: pageexec at freemail dot hu
-Status: Open
+Status: Feedback
Bug Type: PCRE related
Operating System: linux
PHP Version: 5.2.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.3-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.3-win32-installer-latest.msi
I believe this is fixed in latest cvs.
Previous Comments:
[2008-09-25 16:18:02] pageexec at freemail dot hu
i guess the simple fix is to add
#define _pcre_utt_names php__pcre_utt_names
to main/php_compat.h.
[2008-09-25 16:13:04] pageexec at freemail dot hu
Description:
the pcre extension contains a copy of some specific version of libpcre,
with most of the names prefixed with php_ except for _pcre_utt_names
which is not prefixed. this means that if a libphp user such as apache2
also happens to load libpcre (mine's directly linked against it so it
loads before libphp), the symbols from the latter may override
_pcre_utt_names and libphp will use the wrong names table when analyzing
\p and \P (the indices would come from php__pcre_utt which is specific
for the _pcre_utt_names table contained in the pcre extension).
Reproduce code:
---
preg_match_all("/\pL/u", "php", $matches);
print_r($matches);
Expected result:
Array
(
[0] => Array
(
[0] => p
[1] => h
[2] => p
)
)
Actual result:
--
Warning: preg_match_all() [function.preg-match-all]: Compilation
failed: unknown property name after \P or \p at offset 3 in
on line
--
Edit this bug report at http://bugs.php.net/?id=46174&edit=1
#45808 [Com]: stream_socket_enable_crypto() blocks and eats CPU
ID: 45808 Comment by: singularity_control at rcpt dot at Reported By: six at aegis-corp dot org Status: Open Bug Type: Streams related Operating System: Linux 2.6 PHP Version: 5.3.0alpha1 New Comment: This makes a serious security issue. It is a very effective DoS on all single process PHP servers with SSL and a slightly less bad DoS on multi-process PHP servers. Previous Comments: [2008-09-25 16:07:31] nasam at mailvault dot com Bug is in ext/openssl/xp_ssl.c Function handle_ssl_error: (line 107) case SSL_ERROR_WANT_READ: case SSL_ERROR_WANT_WRITE: /* re-negotiation, or perhaps the SSL layer needs more * packets: retry in next iteration */ errno = EAGAIN; retry = is_init ? 1 : sslsock->s.is_blocked; //BUG break; it sets retry to 1 in php_openssl_enable_crypto no matter if socket is blocking or not. [2008-09-25 10:06:09] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-24 01:20:29] six at aegis-corp dot org the bug is still present in php5.3-200809232030 [2008-09-23 01:00:00] 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". [2008-09-15 07:22:44] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.3-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.3-win32-installer-latest.msi 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/45808 -- Edit this bug report at http://bugs.php.net/?id=45808&edit=1
#43639 [Com]: php-5.2.5-win32-installer.msi stops before it is finished.
ID: 43639
Comment by: jim dot keller at contextsolutions dot net
Reported By: erik dot kullberg at telia dot com
Status: Assigned
Bug Type: Windows Installer
Operating System: Windows Vista
PHP Version: 5.2.5
Assigned To: jmertic
New Comment:
Turning off User Account Control in Vista fixes this problem. Start >
Control Panel > (Classic View) > User Accounts > Turn User Account
Control Off
My guess is that even though the installer is running as administrator,
the scripts that run in the background are separate processes, and are
therefore subject to "user account control". If you like the User
Account Control feature, just re-enable it after install.
Previous Comments:
[2008-09-23 22:40:31] thomas dot j dot owens at gmail dot com
I believe this might be related to a bug I file last night at
http://bugs.php.net/bug.php?id=46155
[2008-09-21 06:35:53] cfaribault at presencenet dot ca
Hi all,
Tried 5.2.6 MSI installer from PHP's site as well as the one from "kfou
at free dot fr" and both still give me the error. Trying to setup PHP as
Apache 2.2.x Module. I'm on XP !SP3 English.
Also worth noting, I don't get any error in System Event Viewer.
I also want to note that everytime I run the installer (because I've
also tried to set it up as Apache CGI as well), it adds the following
block of text in httpd.conf:
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
ScriptAlias /php/ "D:/Program Files/PHP/"
Action application/x-httpd-php "D:/Program Files/PHP/php-cgi.exe"
PHPIniDir "D:/Program Files/PHP/"
LoadModule php5_module "D:/Program Files/PHP/php5apache2_2.dll"
PHPIniDir "D:/Program Files/PHP/"
LoadModule php5_module "D:/Program Files/PHP/php5apache2.dll"
PHPIniDir "D:/Program Files/PHP/"
LoadModule php5_module "D:/Program Files/PHP/php5apache.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
Over time, I ended up with 4-5 such blocks, all commented but one. Not
a problem but still annoying. But there is one problem... Apache won't
start unless I comment all "PHPIniDir..." lines but one.
Finally, I'd like to point out that the changes made to httpd.conf
don't include an association to .php files for application/x-httpd-php
("AddType application/x-httpd-php .php"). Once the installer is done
(past the error message) and Apache restarted, I'm prompted for a file
download when I try to access a php file. That may be what the script
fails to do because of the error, I don't know... But in my present
situation, it's something that it's not doing.
I guess that'll be enough for now! :)
Chris
[2008-09-18 01:52:29] kfou at free dot fr
I've generated a fixed installer that you can download from
http://kfou.free.fr/php/php-5.2.6-win32-installer.msi.
Or you can download the original installer from php.net and modify it
using Orca to extract the (faulty) script PHPInstallerScripts.vbs, patch
it (using http://kfou.free.fr/php/PHPInstallerScripts.patch) and
re-import it again using Orca.
Kamel.
[2008-09-11 11:59:36] llucenic at inmail dot sk
My Win XP SP2 with Slovak locales - the same installer problem. After I
changed the locales (regional settings) to English (United States), the
installation worked fine even w/o the need to run as administrator.
Thank you Tamas for your insight. Helped a lot.
Ludo Lucenic
[2008-09-10 11:33:47] [EMAIL PROTECTED]
Having this bug assigned to the installer maintainer will help to
actually get it solved. Especially when so many different problems are
discussed within the same bug.
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/43639
--
Edit this bug report at http://bugs.php.net/?id=43639&edit=1
#46139 [Opn->Asn]: PDOStatement->setFetchMode() forgets FETCH_PROPS_LATE
ID: 46139
Updated by: [EMAIL PROTECTED]
Reported By: chsc at peytz dot dk
-Status: Open
+Status: Assigned
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.3.0alpha2
-Assigned To:
+Assigned To: johannes
New Comment:
Patch looks fine on first sight, I'll test it and apply then.
Previous Comments:
[2008-09-22 12:03:07] matt at mattfarina dot com
I've found this same problem in PHP 5.2.6.
[2008-09-20 19:46:57] chsc at peytz dot dk
Suggested fix:
Index: ext/pdo/pdo_stmt.c
===
RCS file: /repository/php-src/ext/pdo/pdo_stmt.c,v
retrieving revision 1.118.2.38.2.24.2.22
diff -u -8 -p -r1.118.2.38.2.24.2.22 pdo_stmt.c
--- ext/pdo/pdo_stmt.c 12 Aug 2008 17:20:25 -
1.118.2.38.2.24.2.22
+++ ext/pdo/pdo_stmt.c 20 Sep 2008 19:44:43 -
@@ -902,24 +902,25 @@ static int do_fetch_opt_finish(pdo_stmt_
}
/* }}} */
/* perform a fetch. If do_bind is true, update any bound columns.
* If return_value is not null, store values into it according to HOW.
*/
static int do_fetch(pdo_stmt_t *stmt, int do_bind, zval
*return_value,
enum pdo_fetch_type how, enum pdo_fetch_orientation ori, long
offset, zval *return_all TSRMLS_DC) /* {{{ */
{
- int flags = how & PDO_FETCH_FLAGS, idx, old_arg_count = 0;
+ int flags, idx, old_arg_count = 0;
zend_class_entry *ce = NULL, *old_ce = NULL;
zval grp_val, *grp, **pgrp, *retval, *old_ctor_args = NULL;
int colno;
if (how == PDO_FETCH_USE_DEFAULT) {
how = stmt->default_fetch_type;
}
+ flags = how & PDO_FETCH_FLAGS;
how = how & ~PDO_FETCH_FLAGS;
if (!do_fetch_common(stmt, ori, offset, do_bind TSRMLS_CC)) {
return 0;
}
if (how == PDO_FETCH_BOUND) {
RETVAL_TRUE;
Inspired by the fix for bug 41971:
http://cvs.php.net/viewvc.cgi/php-src/ext/pdo/pdo_stmt.c?r1=1.118.2.38.2.21&r2=1.118.2.38.2.22
[2008-09-20 19:43:53] chsc at peytz dot dk
Description:
PDO::FETCH_PROPS_LATE only works if it specified in both the
$stmt->setFetchMode() call and in the following $stmt->fetch().
Calling
$stmt->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'MyClass');
$obj = $stmt->fetch();
yields the same result as
$stmt->setFetchMode(PDO::FETCH_CLASS, 'MyClass');
$obj$stmt->fetch();
In order to make it work you should specify FETCH_PROPS_LATE in both
calls, i.e.
$stmt->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'MyClass');
$obj = $stmt->fetch(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE);
Reproduce code:
---
class Person {
public $name = NULL;
public function __construct() {
var_dump($this->name);
}
}
$db = new PDO("mysql:dbname=foo", "foo", "secret");
$db->exec("CREATE TABLE person (id INTEGER NOT NULL, name
VARCHAR(100))");
$db->exec("INSERT INTO person (id, name) VALUES (1, 'Sven')");
$stmt1 = $db->query('SELECT * FROM person');
$stmt1->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'Person');
$obj1 = $stmt1->fetch(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE);
var_dump($obj1->name);
$stmt1 = NULL;
$stmt2 = $db->query('SELECT * FROM person');
$stmt2->setFetchMode(PDO::FETCH_CLASS | PDO::FETCH_PROPS_LATE,
'Person');
$obj2 = $stmt2->fetch();
var_dump($obj2->name);
Expected result:
NULL
string(4) "Sven"
NULL
string(4) "Sven"
Actual result:
--
NULL
string(4) "Sven"
string(4) "Sven"
string(4) "Sven"
--
Edit this bug report at http://bugs.php.net/?id=46139&edit=1
#46175 [NEW]: SOAP headers containing a "-" can't be handled
From: volwol at yahoo dot com
Operating system: Windows
PHP version: 5.2.6
PHP Bug Type: SOAP related
Bug description: SOAP headers containing a "-" can't be handled
Description:
Using the SoapServer it is possible to parse the SOAP headers. The way it
goes is to use the element name as a function name. However, if the WSDL
includes a dash ("-") in the header name, it isn't possible to write a
function whose name includes a "-" character. Thus, the soap header can't
be retrieved directly.
Reproduce code:
---
public function item-list($msg)
{
$myFile = "c:\tmp.txt";
$fh = fopen($myFile, 'w') ;
fwrite($fh, var_export($msg, true)) ;
}
$server = new SoapServer("Receive Message Service.wsdl") ;
$server->addFunction("item-list");
$server->handle();
/* relevant WSDL parts
*/
Expected result:
The header should be printed to c:\tmp.txt but of course an error is
thrown.
Actual result:
--
An error about the following line is thrown:
public function item-list
expected "(" where as "-"
--
Edit bug report at http://bugs.php.net/?id=46175&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46175&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46175&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46175&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46175&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46175&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46175&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46175&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46175&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46175&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46175&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46175&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46175&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46175&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46175&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46175&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46175&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46175&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46175&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46175&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46175&r=mysqlcfg
#46173 [Opn->Bgs]: session used in a frameset produces wrong files in reply
ID: 46173 Updated by: [EMAIL PROTECTED] Reported By: pmioni at hce dot it -Status: Open +Status: Bogus Bug Type: Session related Operating System: SOLARIS 10 PHP Version: 5.2.6 New Comment: The application is propably not handling sessions correctly. f.e. not using session_write_close() at the right time, etc. Not a PHP bug. Previous Comments: [2008-09-25 15:20:54] pmioni at hce dot it Please note that I'm just installing the application, as it has been created by a separate firm. My original text might have given the impression that we wrote it. [2008-09-25 15:08:06] pmioni at hce dot it Description: This bug is (apparently) specific to Solaris. It cannot be replicated on our test CentOS machine. This is not the usual variation of "somebody not understanding how sessions work in a frameset" We have an e-learning application, called Dokeos (www.dokeos.com), which has a tool using framesets containing a set of frames, each pointing to a separate php file. All php files share the same session (which is rather large in terms of saved content) across the frames. The application behaves unpredictably: some frames load correctly, some load the content of other frames, some remain white. On refresh of the main frameset page, every frame misbehaves in a different way, so contents move around. Even refreshing individual frames keeps failing miserably. Basically, let's say that the frameset frameset.php calls files 1.php through file 6.php. The frame containing 2.php, upon first opening of the frameset and upon refresh, can contain the output of anything from 1.php to 6.php to the frameset.php itself, and even other pages which were browsed earlier on the same server. The problem is cross-browser, is not caused by Javascript (it happens when JS is blocked at browser level), and cannot be caused by wrong header() calls in the PHP code, since at least some of the files do not have any header() call anywhere, and still the system returns another file in their place. The same application (the same files, the same database, the same content) works just fine on our CentOS server, with the same version of PHP but Apache 1.3.41. Any help? Any suggestions? Here's the top of our phpinfo(): PHP Version 5.2.6 System SunOS rpol-c 5.10 Generic_127127-11 sun4v Build Date Jun 5 2008 19:14:30 Configure Command './configure' '--prefix=/opt/coolstack/php5' '--disable-debug' '--disable-dmalloc' '--disable-inline-optimization' '--disable-libgcc' '--disable-libtool-lock' '--disable-static' '--enable-calendar' '--enable-ctype' '--enable-cli' '--enable-cgi' '--enable-fastcgi' '--enable-dba=shared' '--enable-dbase' '--enable-dom' '--enable-exif' '--enable-force-cgi-redirect' '--enable-ftp' '--enable-gd-jis-conv' '--enable-gd-native-ttf' '--enable-ipv6' '--enable-libxml' '--enable-magic-quotes' '--enable-mbregex' '--enable-mbstring' '--enable-pcntl' '--enable-pdo' '--enable-posix' '--enable-reflection' '--enable-safe-mode' '--enable-session' '--enable-shared' '--enable-shmop' '--enable-short-tags' '--enable-soap' '--enable-spl' '--enable-sqlite-utf8' '--enable-sysvmsg' '--enable-sysvsem' '--enable-sysvshm' '--enable-ucd-snmp-hack' '--enable-wddx' '--enable-xmlreader' '--enable-zend-multibyte' '--with-bz2=shared,/usr' '--with-cdb' '--with-curl=shared,/opt/coolstack' '--with-curlwrappers' '--enable-flatfile' '--with-freetype-dir=/opt/coolstack' '--with-gd=shared,/opt/coolstack' '--with-gdbm=/opt/coolstack' '--with-gettext=shared,/opt/coolstack' '--with-gmp=shared,/opt/coolstack' '--with-iconv=shared,/opt/coolstack' '--with-imap-ssl=shared,/opt/coolstack/imap' '--with-imap=shared,/opt/coolstack/imap' '--enable-inifile' '--with-jpeg-dir=/usr' '--with-layout=PHP' '--with-ldap=shared,/opt/coolstack' '--with-ldap-sasl=yes' '--with-libexpat-dir=/opt/coolstack/apache2' '--with-libmbfl' '--with-libxml-dir=/opt/coolstack' '--enable-mod-charset' '--with-mssql=shared,/opt/coolstack' '--with-mysql-sock' '--with-mysql=shared,/opt/coolstack/mysql_32bit' '--with-mysqli=shared,/opt/coolstack/mysql_32bit/bin/mysql_config' '--with-ncurses=shared,/opt/coolstack' '--with-ndbm=/usr' '--with-openssl=shared,/opt/coolstack' '--with-pcre-dir=/opt/coolstack' '--with-pdo-dblib=shared,/opt/coolstack' '--with-pdo-mysql=shared,/opt/coolstack/mysql_32bit' '--with-pdo-odbc=shared,unixODBC,/opt/coolstack' '--with-pdo-pgsql=shared,/usr' '--with-pear' '--with-pgsql=shared,/usr' '--with-pic' '--with-png-dir=/usr' '--with-readline=shared,/opt/coolstack' '--with-pspell=shared,/usr' '--with-snmp=shared,/opt/coolstack' '--with-tidy=shared,/opt/coolstack' '--with-tsrm-pthreads' '--with-unixODBC=shared,/opt/coolstack' '--with-xmlrpc' '--with-xpm-dir=/usr/openwin' '--with-xsl=shared,/opt/coolstack' '--with-zend-vm=CALL' '--with-zlib=
#46176 [NEW]: Making POST requests do not always return correct Mime Type
From: dhendric at adobe dot com Operating system: Mac OS X Leopard PHP version: 5.2.6 PHP Bug Type: *URL Functions Bug description: Making POST requests do not always return correct Mime Type Description: When using the curl class or the HTTP Request class (Pear) that sends a POST request, some instances return the wrong mime type in the header data. Using linux commands POST and wget return correct mime type in header for the same request. curl via Mac OS X command line: deirdra-hendrickss-macbook-pro:~ dhendric$ curl --url "http://s7d4.scene7.com/is/image/sample"; -d "fmt=png&req=catalogprops,text" -i HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Last-Modified: Thu, 25 Sep 2008 23:05:41 GMT ETag: "6d16a6640f1e7e88731e9688556b6596" Content-Type: text/plain Content-Length: 466 Expires: Thu, 25 Sep 2008 23:05:43 GMT Date: Thu, 25 Sep 2008 23:05:43 GMT Connection: keep-alive Reproduce code: --- $URL = "http://s7d4.scene7.com/is/image/sample?fmt=png&req=catalogprops,text";; $c = curl_init(); curl_setopt($c, CURLOPT_RETURNTRANSFER, 1); curl_setopt($c, CURLOPT_POST, true); curl_setopt($c, CURLOPT_URL, $URL); curl_exec($c); echo curl_getinfo($c, CURLINFO_CONTENT_TYPE); curl_close($c); Expected result: should echo "text/plain" Actual result: -- echos "image/jpeg" -- Edit bug report at http://bugs.php.net/?id=46176&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46176&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46176&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46176&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46176&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46176&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46176&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46176&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46176&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46176&r=support Expected behavior:http://bugs.php.net/fix.php?id=46176&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46176&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46176&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46176&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46176&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46176&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46176&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46176&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46176&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46176&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46176&r=mysqlcfg
#46177 [NEW]: Require is triggering autoload function
From: Antoniocs at gmail dot com
Operating system: windows XP sp3
PHP version: 5.2.6
PHP Bug Type: Dynamic loading
Bug description: Require is triggering autoload function
Description:
Require triggers __autoload
Reproduce code:
---
File teste.php
File other.php
require("teste.php");
This will trigger my autoload function (which is declared and included,
but not shown here), which will try to load the file where the
acs_activerecord is
Expected result:
I would expect it not to trigger the autoload function.
The autoload function should be triggered when I instantiate the class
teste
Actual result:
--
I have xdedub and the cachegrind shows the autoload function being called
when the file teste.php is required
http://img142.imageshack.us/img142/2047/loadproblemug6.jpg
Here is a link to the image of the cachegrind file.I have placed a little
arrow indicating the file
--
Edit bug report at http://bugs.php.net/?id=46177&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=46177&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=46177&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=46177&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=46177&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=46177&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=46177&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=46177&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=46177&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=46177&r=support
Expected behavior:http://bugs.php.net/fix.php?id=46177&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=46177&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=46177&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=46177&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46177&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=46177&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=46177&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=46177&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=46177&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=46177&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=46177&r=mysqlcfg
#46178 [NEW]: memory leak in ext/phar
From: [EMAIL PROTECTED] Operating system: Mac OS X PHP version: 5.3CVS-2008-09-26 (CVS) PHP Bug Type: PHAR related Bug description: memory leak in ext/phar Description: When running http://svn.pear.php.net/PEAR2/Pyrus/trunk/src/Pyrus/makepackage.php I get Greg-Beavers-monster:Pyrus Greg$ php -d phar.readonly=0 makepackage.php [Thu Sep 25 20:38:04 2008] Script: 'makepackage.php' /Users/Greg/Documents/php/php5/ext/phar/util.c(1524) : Freeing 0x00E41CD0 (54 bytes), script=makepackage.php Last leak repeated 5 times [Thu Sep 25 20:38:04 2008] Script: 'makepackage.php' /Users/Greg/Documents/php/php5/ext/phar/util.c(1521) : Freeing 0x00E2FCF8 (104 bytes), script=makepackage.php /Users/Greg/Documents/php/php5/Zend/zend_alloc.c(2391) : Actual location (location was relayed) Last leak repeated 5 times === Total 12 memory leaks detected === not sure why yet -- Edit bug report at http://bugs.php.net/?id=46178&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46178&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46178&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46178&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46178&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46178&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46178&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46178&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46178&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46178&r=support Expected behavior:http://bugs.php.net/fix.php?id=46178&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46178&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46178&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46178&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46178&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46178&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46178&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46178&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46178&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46178&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46178&r=mysqlcfg
