#45418 [Opn->WFx]: configure script fails with --with-ldap enabled
ID: 45418 Updated by: [EMAIL PROTECTED] Reported By: mccullj at email dot uah dot edu -Status: Open +Status: Wont fix Bug Type: LDAP related Operating System: Solaris 10 PHP Version: 4.4.8 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-07-02 15:03:07] mccullj at email dot uah dot edu Description: The following configure script works: ./configure --prefix=/usr/local/php4.4.8 --with-config-file-path=/usr/local/h p4.4.8 --with-apxs2=/usr/local/apache-test/bin/apxs --with-gettext --with-mcrypt --with-iconv=/usr/local --enable-mbstring=all --enable-mbregex --with-gd --with -png-dir=/usr/local --with-jpeg-dir=/usr/local --with-mysql=/usr/local/mysql --w ith-imap=/usr/local/imap2007b/ --with-openssl=/usr/local/ssl --with-libxml-dir=/ usr/local --with-zlib=/usr/local --with-dom but when I add --with-ldap to the end it fails. Here are the last two lines of config.log: configure:48597: checking for Java support configure:49434: checking for LDAP support The output of the configure command is: checking for LDAP support... yes configure: error: Cannot find ldap libraries in /usr/lib. In the configure script, where that message is located (line 51702), it appears to be looking for an Oracle LDAP library libclntsh rather than Solaris LDAP libraries. -- Edit this bug report at http://bugs.php.net/?id=45418&edit=1
#45136 [Opn->WFx]: Setting expose_php = Off in php.ini returns X-Powered-By header for subdomains
ID: 45136 Updated by: [EMAIL PROTECTED] Reported By: Ashok dot 893 at gmail dot com -Status: Open +Status: Wont fix Bug Type: Apache related Operating System: Linux PHP Version: 4.4.8 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-05-30 08:55:35] Ashok dot 893 at gmail dot com Description: I set the expose_php = Off in php.ini file and restarted the apache server. When I check the response headers for my site, server doesn't return the 'X-Powered-By' header. But when I check the response headers for subdomains, it returns the 'X-Powered-By' header. Reproduce code: --- I've kept only html codes in both index.php files(my domain and subdomain home page) Expected result: Response Headers DateFri, 30 May 2008 07:26:52 GMT Server Apache/1.3.39 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.30 OpenSSL/0.9.7a Last-Modified Sat, 29 Dec 2007 07:36:29 GMT Etag"44c015-1d89-4775f8fd" Accept-Ranges bytes Content-Length 7561 Keep-Alive timeout=8, max=100 Connection Keep-Alive Content-Typetext/html Actual result: -- Response Headers DateFri, 30 May 2008 07:25:12 GMT Server Apache/1.3.39 (Unix) mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_ssl/2.8.30 OpenSSL/0.9.7a Cache-Control no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Expires Thu, 19 Nov 1981 08:52:00 GMT Pragma no-cache X-Powered-ByPHP/4.4.8 Keep-Alive timeout=8, max=100 Connection Keep-Alive Transfer-Encoding chunked Content-Typetext/html -- Edit this bug report at http://bugs.php.net/?id=45136&edit=1
#45013 [Opn->Fbk]: Semaphore cannot be released under certain circumstances.
ID: 45013 Updated by: [EMAIL PROTECTED] Reported By: andre at koethur dot de -Status: Open +Status: Feedback Bug Type: Semaphore related Operating System: Linux PHP Version: 4.4.8 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi If you can reproduce this problem using latest PHP 5.2 snapshot, update the version string to contain: 5.2CVS-2008mmdd Previous Comments: [2008-05-15 20:47:33] andre at koethur dot de Description: If I acqure a semaphore in one script, then it is not possible to release it in another script, even if I set "auto_release" to false. As I have found out, it has something to do with the "count" attribute of the "sysvsem_sem"-structure. This value is really only needed by the "auto_release"-functionality, so it should be safe to ignore it in php_sysvsem_semop()-function. The current cvs-version of sysvsem.c says on line 290: if (!acquire && sem_ptr->count == 0) I suggest to change it to: if (!acquire && sem_ptr->count == 0 && sem_ptr->auto_release) Reproduce code: --- First script, acquire semaphore: Second script, release semaphore: Expected result: The second script should run without errors/warnings and the semaphore should be released. Actual result: -- Warning: sem_release() [function.sem-release]: SysV semaphore 2 (key 0x965) is not currently acquired -- Edit this bug report at http://bugs.php.net/?id=45013&edit=1
#42228 [Opn->WFx]: feof() fails to detect the eof flag for a file with a newline only.
ID: 42228
Updated by: [EMAIL PROTECTED]
Reported By: nikhil dot gupta at in dot ibm dot com
-Status: Open
+Status: Wont fix
Bug Type: Filesystem function related
Operating System: Linux, Win32-xp
PHP Version: 4CVS-2007-08-07 (CVS)
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2008-02-11 14:38:34] sb1304 at hotmail dot com
Gives:
int(0)
array(1) {
[0]=>
string(0) ""
}
int(1)
bool(false)
int(0)
int(1)
bool(false)
bool(true)
And a feof of true. Same result as in 42175?
S
[2007-08-07 05:40:24] nikhil dot gupta at in dot ibm dot com
Description:
feof() is failing to detect the end of file for a file containing a
blank file ("\n" character only).
This behaviour is seen on php5 and php6 both.
Reproduce code:
---
Expected result:
int(0)
array(1) {
[0]=>
string(0) ""
}
int(1)
bool(true)
int(0)
int(1)
bool(true)
Actual result:
--
int(0)
array(1) {
[0]=>
string(0) ""
}
int(1)
bool(false)
int(0)
int(1)
bool(false)
--
Edit this bug report at http://bugs.php.net/?id=42228&edit=1
#44374 [Opn->WFx]: MD5_file HASH problem
ID: 44374
Updated by: [EMAIL PROTECTED]
Reported By: palo654 at hotmail dot com
-Status: Open
+Status: Wont fix
Bug Type: *Encryption and hash functions
Operating System: Linux Fedora
PHP Version: 4.4.8
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2008-03-08 14:20:54] palo654 at hotmail dot com
Description:
I've noticed a really confusing fact.
MD5_file and shell md5sum gives different checksums in some cases.
I've written a complete file integrity check in php.
O was using md5sum from shell to calcullate md5 checksums. After
switching to md5_file i've got allerts in some files.
So I made some test, and found, that in some cases md5sum and md5_file
gives different output !!!
on my /usr/lib directory I've got 6 differences.
Reproduce code:
---
shell_exec("/usr/bin/md5sum $currentfile");
md5_file($currentfile);
--
Edit this bug report at http://bugs.php.net/?id=44374&edit=1
#42165 [Opn->WFx]: fsockopen ssl Operation now in progress (115)
ID: 42165
Updated by: [EMAIL PROTECTED]
Reported By: ebalaskas at ebalaskas dot gr
-Status: Open
+Status: Wont fix
Bug Type: OpenSSL related
Operating System: Linux Ubuntu 7.04
PHP Version: 4.4.7
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2007-08-20 09:36:24] ebalaskas at ebalaskas dot gr
isn't there any solution for v4 ?
i know all about for the v4 end of life,
but isn't there somehow a fix for this ?
[2007-08-20 09:17:26] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-08-01 11:52:17] ebalaskas at ebalaskas dot gr
Description:
Linux Ubuntu 7.04
Apache/2.0.59
Php/4.4.7
Openssl/0.9.8e
All http (tcp 80) are ok,
All ssl (tcp 443) produce the below msg.
The Resource_id is null
Reproduce code:
---
\n";
if (!$fp) {
echo "$errstr ($errno)\n";
echo $fp;
} else {
$out = "GET / HTTP/1.1\r\n";
$out .= "Host: ".$host."\r\n";
$out .= "Connection: Close\r\n\r\n";
fwrite($fp, $out);
while (!feof($fp)) {
echo fgets($fp, 128);
}
fclose($fp);
}
?>
Expected result:
The page of www.example.com
Actual result:
--
Warning: fsockopen() [function.fsockopen]:
php_stream_sock_ssl_activate_with_method: failed to create an SSL
context in /usr/local/apache2/htdocs/test.php on line 6
Warning: fsockopen() [function.fsockopen]: failed to activate SSL mode
1 in /usr/local/apache2/htdocs/test.php on line 6
Operation now in progress (115)
--
Edit this bug report at http://bugs.php.net/?id=42165&edit=1
#45011 [WFx->Csd]: [libphp4.so+0x149852] zend_hash_copy+0x12
ID: 45011 Updated by: [EMAIL PROTECTED] Reported By: fgaudreault at iweb dot com -Status: Wont fix +Status: Closed Bug Type: Servlet related Operating System: Fedora core 7 PHP Version: 4.4.8 Previous Comments: [2008-07-11 21:42:08] [EMAIL PROTECTED] We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. [2008-05-16 20:18:37] fgaudreault at iweb dot com You can close the BUG. It was fixed by changing mod_proxy to mod_jk. [2008-05-15 17:52:47] fgaudreault at iweb dot com Description: PHP Servlet having problem with some Zend related stuff : ###sortAdd:1 ## getRed5Stats ###sortAdd:2 ## getRed5Stats # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x8978b852, pid=27920, tid=2317327248 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_15-b04 mixed mode) # Problematic frame: # C [libphp4.so+0x149852] zend_hash_copy+0x12 # # An error report file with more information is saved as hs_err_pid27920.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The error is quite weird since there is no indication of which php script was currently working. php.ini is the default one. no changes. -- Edit this bug report at http://bugs.php.net/?id=45011&edit=1
#45011 [Opn->WFx]: [libphp4.so+0x149852] zend_hash_copy+0x12
ID: 45011 Updated by: [EMAIL PROTECTED] Reported By: fgaudreault at iweb dot com -Status: Open +Status: Wont fix Bug Type: Servlet related Operating System: Fedora core 7 PHP Version: 4.4.8 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-05-16 20:18:37] fgaudreault at iweb dot com You can close the BUG. It was fixed by changing mod_proxy to mod_jk. [2008-05-15 17:52:47] fgaudreault at iweb dot com Description: PHP Servlet having problem with some Zend related stuff : ###sortAdd:1 ## getRed5Stats ###sortAdd:2 ## getRed5Stats # # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0x8978b852, pid=27920, tid=2317327248 # # Java VM: Java HotSpot(TM) Server VM (1.5.0_15-b04 mixed mode) # Problematic frame: # C [libphp4.so+0x149852] zend_hash_copy+0x12 # # An error report file with more information is saved as hs_err_pid27920.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # The error is quite weird since there is no indication of which php script was currently working. php.ini is the default one. no changes. -- Edit this bug report at http://bugs.php.net/?id=45011&edit=1
#45157 [Opn->WFx]: Php runtime timeout
ID: 45157
Updated by: [EMAIL PROTECTED]
Reported By: arno at dotcontent dot net
-Status: Open
+Status: Wont fix
-Bug Type: Unknown/Other Function
+Bug Type: Scripting Engine problem
Operating System: Windows 2000
PHP Version: 4.4.8
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2008-06-03 12:38:32] arno at dotcontent dot net
BTW to exclude any possibility this is a browser-related timeout, I ran
the same test successfully with $t=500 seconds on a different machine
running php 4.3.4, everything else the same as the original test pc.
[2008-06-03 10:44:54] arno at dotcontent dot net
Description:
Problem with page timing out.
I changed max_execution_time from 30 to 600 in php.ini for debug
purposes. This has always worked for me for the past few years. However
after upgrading to 4.4.8 I find my php page times out after approx. 60
seconds. As a result php times out while I'm stepping through the code.
I also tried setting max_execution_time to 6000 with same result. Tested
on localhost in both IE6 and Mozilla 2. Using Apache Release 10324100.
Reproduce code:
---
change max_execution_time from 30 to 600 in php.ini and restart server
- phpinfo confirms max_execution_time=600
I used the following to test (adapted from the manual):
test timeout";
echo "Test timeout - sleep for $t seconds";
echo "sleeping ".date('h:i:s')."";
sleep($t);
echo "stop sleeping ".date('h:i:s');
echo "";
?>
$t=59 works fine, but $t=70 times out.
Expected result:
Expected to see an output page
Actual result:
--
The page cannot be displayed
The page you are looking for is currently unavailable. The Web site
might be experiencing technical difficulties, or you may need to adjust
your browser settings.
--
Edit this bug report at http://bugs.php.net/?id=45157&edit=1
#44745 [Opn->WFx]: child pid 913624 exit signal Segmentation fault (11)
ID: 44745 Updated by: [EMAIL PROTECTED] Reported By: mssanch2002 at yahoo dot com -Status: Open +Status: Wont fix -Bug Type: Unknown/Other Function +Bug Type: Reproducible crash Operating System: aix 5.3 PHP Version: 4.4.8 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-04-18 21:18:41] mssanch2002 at yahoo dot com I found out that the problem was compiling using oracle 10.2.0.3.0 libraries. When I use oracle 9.2.0, I do not get the segmentation faults. Does anyone know about this problem? [2008-04-17 12:33:39] mssanch2002 at yahoo dot com I'm also getting these warning when I run the make. /macs/php-4.4.8/ext/standard/info.c: In function 'php_info_write_wrapper': /macs/php-4.4.8/ext/standard/info.c:69: warning: pointer targets in passing argu ment 1 of 'php_escape_html_entities' differ in signedness /macs/php-4.4.8/ext/standard/info.c: In function 'php_info_html_esc': /macs/php-4.4.8/ext/standard/info.c:216: warning: pointer targets in passing arg ument 1 of 'php_escape_html_entities' differ in signedness /macs/php-4.4.8/ext/standard/info.c: In function 'php_print_info': /macs/php-4.4.8/ext/standard/info.c:506: warning: pointer targets in passing arg ument 3 of 'zend_hash_get_current_key_ex' differ in signedness /macs/php-4.4.8/ext/standard/info.c: At top level: /macs/php-4.4.8/TSRM/tsrm_virtual_cwd.h:166: warning: 'php_realpath_hack' define d but not used [2008-04-16 18:26:40] mssanch2002 at yahoo dot com PHP was configured with the following: ./configure --with-oci8 --without-mysql --with-apache=../apache --enable-debug [2008-04-16 17:21:10] mssanch2002 at yahoo dot com Description: I configure apache 1.4.41 with the following config: /configure --with-layout=Apache --prefix=/macs/apache --activate-module=src/modules/php4/libphp4.a I receive the following message in apache error_log when I use the browser: child pid 913624 exit signal Segmentation fault (11) Actual result: -- GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "powerpc-ibm-aix5.1.0.0"... (no debugging symbols found)... (gdb) run -X Starting program: /macs/apache_1.3.41/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1] 0x1007de4c in ?? () (gdb) bt #0 0x1007de4c in ?? () (gdb) -- Edit this bug report at http://bugs.php.net/?id=44745&edit=1
#44338 [Opn->WFx]: shared openssl.so
ID: 44338 Updated by: [EMAIL PROTECTED] Reported By: akbsol at yahoo dot co dot in -Status: Open +Status: Wont fix Bug Type: OpenSSL related Operating System: Debian 3.1 PHP Version: 4.4.8 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-03-05 16:26:48] akbsol at yahoo dot co dot in Wanna add that when I compile the support directly in php using: ./configure --enable-fastcgi --with-openssl without the "shared" the streams are available. Why are they not available while building it shared? [2008-03-05 16:22:59] akbsol at yahoo dot co dot in Description: I am trying to compile a php binary which supports https:// and ftps:// streams by compiling openssl as a shared extension. Although a openssl.so ext. file gets created successfully, loads well through ini/dl() and openssl functions listed here: http://in.php.net/manual/en/ref.openssl.php are available but streams https:// and ftps:// are not available. Reproduce code: --- ./configure --enable-fastcgi --with-openssl=shared -- Edit this bug report at http://bugs.php.net/?id=44338&edit=1
#42297 [Opn->WFx]: mysql_fetch functions return ? instead of utf8 chars other than latin1
ID: 42297 Updated by: [EMAIL PROTECTED] Reported By: bmilosavljevic at gmail dot com -Status: Open +Status: Wont fix Bug Type:MySQL related PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-03-25 22:59:59] bmilosavljevic at gmail dot com I have not encountered the problem in PHP 5.x.x, but I think it also should be fixed in the manner described above... [2008-03-25 19:28:31] [EMAIL PROTECTED] Do you experience the problem with PHP5? PHP4 is no more fixed except for security updates. [2007-09-25 20:12:24] bmilosavljevic at gmail dot com I had the same problem with php 4.4.4 and MySQL server version of 4.1.22 standard on Linux server! Exactly, it is solved by this fix for utf8 char set when database char set is utf8. What is your MySQl server version? Maybe that's what matters. Actually, by querying SET CHARACTER SET latin1 you did exactly the same fix! It seems we should apply the same char set in this SQL statement as in the database queried. "Thus, is it possible that PHP tries to convert any mysql results to utf8, even when neither the database/tables, nor the PHP files are in utf8 ?" -> I think that is exactly what MySQL tries to do. Only I am not sure why it can not perform this conversion (according to this article at http://www.bluetwanger.de/blog/2006/11/20/mysql-and-utf-8-no-more-question-marks/ -> I think you should see it) I 'll test this on php 5.x.x and post the results... [2007-09-25 18:05:58] dev at unleashedmind dot com The given fix works, if the database collation is utf8_* (f.e. utf8_general_ci). However, querying a database with collation latin1_* still returns question marks instead of the actual characters. Thus, is it possible that PHP tries to convert any mysql results to utf8, even when neither the database/tables, nor the PHP files are in utf8 ? I encounter this bug with PHP 4.4.7 on Windows (Server 2003). I'm not able to reproduce it with PHP 4.4.7 on SuSE Linux. Also, this bug does not seem to exist in PHP 5. IIRC, my last installed version of PHP was 4.4.4, which did not have this bug. Strangely, if I add the rather senseless line immediately after the database connect, all mysql query read/write results are fine. [2007-09-24 20:18:05] bmilosavljevic at gmail dot com I think I 've found the solution! This bug is due to MySQL, I think. If the following sql query is executed: SET CHARACTER SET utf8 (without ; is recommended) immediately after establishing a connection, the problem is solved, at least for me! Even more suitable query would be SET NAMES utf8, because connection's query strings are also submitted to the server in utf8. and instead of ... any query executed should return proper utf8 characters. Check this please in your environment! 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/42297 -- Edit this bug report at http://bugs.php.net/?id=42297&edit=1
#43821 [Opn->WFx]: require_once is case sensitive
ID: 43821 Updated by: [EMAIL PROTECTED] Reported By: wxjasp02 at smumn dot edu -Status: Open +Status: Wont fix Bug Type: Streams related Operating System: Windows Server 2003 PHP Version: 4.4.8 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-01-11 15:59:02] wxjasp02 at smumn dot edu Description: Require_Once in PHP 4.4.7 appears to be case sensitive in checking files already included. This has triggered 'cannot redeclare class' in situations where a classfile may be already loaded, but require_once doesn't see it. In light testing, I have found that I have to force my code to switch any include or require calls to lower case to avoid this. I realize this is an old version of php, and 4 is officially 'dead'; but I am unaware if this has been fixed. (I wouldn't use 4, however the site where we host refuses to move to PHP5 or update php4 to the latest.) The bug was originally identified in Version 4.3.4, see: Bug# 26552; however I believe it has re-surfaced. System Configuration: Windows Server 2003 Apache 2.0.59 PHP 4.4.7 Reproduce code: --- Make a class and put it in a file which you will require_once. In the file you will run, call: Expected result: The expected result is to only load myclass.php ONCE. To confirm the problem, empty the file myclass.php, or put some non-class junk in it. After each require_once, add: print_r(get_included_files()); You should see myclass.php the first time it is called, and myclass.php, MyClass.php, the second. Actual result: -- Cannot Redeclare class MyClass in ... on line ... -- Edit this bug report at http://bugs.php.net/?id=43821&edit=1
#43227 [Opn->Asn]: eregi() mbregex compile err: premature end of regular expression in
ID: 43227
Updated by: [EMAIL PROTECTED]
Reported By: baco at infomaniak dot ch
-Status: Open
+Status: Assigned
Bug Type: mbstring related
Operating System: Linux Debian
PHP Version: 5.2.5
-Assigned To:
+Assigned To: hirokawa
New Comment:
Assigned to mbstring maintainer.
Previous Comments:
[2008-02-25 13:31:02] baco at infomaniak dot ch
As workaround try to force mbstring.func_overload = 0 in your php.ini
and use this patch.
PHP5
unix_mbstring_func_overload.patch
--- ext/mbstring/mbstring.c 2007-09-24 13:51:36.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:00:10.023564681 +0100
@@ -765,8 +765,8 @@
PHP_INI_ENTRY("mbstring.script_encoding", NULL, PHP_INI_ALL,
OnUpdate_mbstring_script_encoding)
#endif /* ZEND_MULTIBYTE */
PHP_INI_ENTRY("mbstring.substitute_character", NULL,
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateLong, func_overload,
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
+PHP_INI_SYSTEM, OnUpdateLong, func_overload,
zend_mbstring_globals, mbstring_globals)
STD_PHP_INI_BOOLEAN("mbstring.encoding_translation", "0",
PHP_INI_SYSTEM | PHP_INI_PERDIR,
OnUpdate_mbstring_encoding_translation,
PHP4
--- ext/mbstring/mbstring.c 2007-04-04 17:28:18.0 +0200
+++ ext/mbstring/mbstring.c 2007-12-04 18:05:29.363559316 +0100
@@ -815,8 +815,8 @@
PHP_INI_ENTRY("mbstring.script_encoding", NULL, PHP_INI_ALL,
OnUpdate_mbstring_script_encoding)
#endif /* ZEND_MULTIBYTE */
PHP_INI_ENTRY("mbstring.substitute_character", NULL,
PHP_INI_ALL, OnUpdate_mbstring_substitute_character)
-STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
PHP_INI_SYSTEM |
-PHP_INI_PERDIR, OnUpdateInt, func_overload,
zend_mbstring_globals, mbstring_globals)
+STD_PHP_INI_ENTRY("mbstring.func_overload", "0",
+PHP_INI_SYSTEM, OnUpdateInt, func_overload,
zend_mbstring_globals, mbstring_globals)
STD_PHP_INI_BOOLEAN("mbstring.encoding_translation", "0",
PHP_INI_SYSTEM | PHP_INI_PERDIR,
OnUpdate_mbstring_encoding_translation,
[2008-02-25 13:18:00] lip at lip dot net dot ua
I think these bugs are similar.
http://bugs.php.net/bug.php?id=44237
[2007-11-09 16:03:14] baco at infomaniak dot ch
Description:
eregi() produce random errors like "function.mb-eregi: mbregex compile
err: premature end of regular expression in" when used with special
chars like accents.
N.B. On the web you can found a lot of reports of this issue. Some post
suggests forcing mbstring.func_overload = 0 but it doesn't work for me.
If Apache1 is restarted the error doesn't come anymore before an amount
of time and request.
$ GET http://localhost/test.php
ok
$ GET http://localhost/test.php
ok
$ GET http://localhost/test.php
Warning: mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2
$ GET http://localhost/test.php
Warning: mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2
$ GET http://localhost/test.php
Warning: mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2
$ GET http://localhost/test.php
ok
$ GET http://localhost/test.php
ok
...
Reproduce code:
---
Expected result:
OK
Actual result:
--
Warning: mb_eregi() [function.mb-eregi]: mbregex compile err:
premature end of regular expression in
/home/www/ca8b72beb934995c1afb34e1a3ceb893/web/test.php on line
2
--
Edit this bug report at http://bugs.php.net/?id=43227&edit=1
#43571 [Opn->WFx]: php_admin* directive ignored
ID: 43571 Updated by: [EMAIL PROTECTED] Reported By: barbara at rfx dot it -Status: Open +Status: Wont fix Bug Type: Safe Mode/open_basedir Operating System: Linux PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-12-12 10:41:04] andretta at apf dot it Same problem here (using original Trustix src.rpm). Solved rebuilding the rpm without the Console_Getopt patch. Install php4 source rpm: rpm -ivh php4.4.7*.src.rpm edit the php4.spec (comments row referring the Console_Getopt patch) rebuild: rpmbuild -ba php4.spec Update: rpm -Fvh php4* Done. :-) Bye, Paolo Andretta [2007-12-11 23:35:58] barbara at rfx dot it Description: Basically the php_admin_value and php_admin_flag directive in VirtualHost httpd.conf (included) are ignored. Also in .htaccess tried with safe_mode, open_dir, sendmail_path parameters. Trustix 2.2 distro Kernel 2.4.34 php 4.4.7 Apache 2.0.59 Same compilation options. Until version 4.4.4 works, next version (now trying 4.4.7), not work. Restoring php 4.4.4 still work. Enabled/disabled Zend,mod_security, ... Regards, B. -- Edit this bug report at http://bugs.php.net/?id=43571&edit=1
#42534 [Opn->WFx]: Mail DATA sending too soon...i guess
ID: 42534 Updated by: [EMAIL PROTECTED] Reported By: jtaylor at jttechonline dot com -Status: Open +Status: Wont fix Bug Type: Mail related Operating System: Windows 2000 PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-09-03 17:37:05] jtaylor at jttechonline dot com Description: I don't know if this is a bug or not, but my PHP engine is sending data from the script before the e-mail server says "Enter mail, end with '.' on line by itself". It enters the script data before it says this line and then the webpage says Error 500 Internal server error about 30 seconds after submission. Needless to say the mail never makes it to the desired e-mail account. Do you know what the problem might be? I know the e-mail server is accepting mail from the PHP engine and the account it is sending it to exists. Expected result: Mail should be delivered to local e-mail account without problems. Actual result: -- Recipient and Sender 127.0.0.1 are accepted "DATA" command sent. 220 Comes back saying "Sender ok..., script info sent then the "Enter mail, end with '.' on line by itself" appears, then the data should be sent from what I understand. -- Edit this bug report at http://bugs.php.net/?id=42534&edit=1
#42347 [Opn->WFx]: Inconsistency of treatments of PHP_AUTH_PW and HTTP Authorization header
ID: 42347 Updated by: [EMAIL PROTECTED] Reported By: c dot i dot morris at durham dot ac dot uk -Status: Open +Status: Wont fix Bug Type: Safe Mode/open_basedir Operating System: Linux+Apache PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-08-20 10:48:59] c dot i dot morris at durham dot ac dot uk Description: In safe mode, the PHP_AUTH_PW variable is not available to users if the authorisation was handled by Apache rather than PHP (e.g. Apache's various mod_auth_*). This correctly prevents users from reading the passwords from a central user database simply by getting a logged-in user to view their page. However, the HTTP Authorization header is not similarly filtered out in safe_mode, allowing a malicious user to use the code below to read other users' passwords. This definitely affects apache_request_headers() - if there are any other functions also allowing reading of HTTP request headers, they should also be checked. Reproduce code: --- Expected result: Should not print anything. Actual result: -- Prints username and password of authenticated user -- Edit this bug report at http://bugs.php.net/?id=42347&edit=1
#42332 [Opn->WFx]: imap_mail_compose() does not work correctly for multiparts e-mails
ID: 42332 Updated by: [EMAIL PROTECTED] Reported By: carsten_sttgt at gmx dot de -Status: Open +Status: Wont fix Bug Type: IMAP related Operating System: Windows_NT PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-08-17 23:09:34] carsten_sttgt at gmx dot de Description: Just see Bug #40854. In PHP_5_2 (5.2.2) the problem is solved. But in PHP_4_4 (4.4.7) this bug is still alive. -- Edit this bug report at http://bugs.php.net/?id=42332&edit=1
#42180 [Opn->WFx]: php in fastcgi environment periodicaly get 90% of CPU
ID: 42180 Updated by: [EMAIL PROTECTED] Reported By: a dot simonov at favoritbet dot com -Status: Open +Status: Wont fix Bug Type: CGI related Operating System: Linux PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-10-04 05:09:54] madcamel at gmail dot com I've ran into this too. PHP can behave very badly under FastCGI, especially 4.x. Some scripts just do not exit, and hang in a tight loop consuming massive amounts of resources. I know this isn't a real fix, but when I became more careful with my coding style and changed some timeouts the problem went away. Take a good close look at what you are running(xdebug helps), and try lowering some of the timeout values in php. Make sure database handles are closed properly and if applicable, make sure you are using the latest version of the mysql libraries. I've had them leak pretty badly at times. [2007-08-02 13:52:40] a dot simonov at favoritbet dot com Description: php in fastcgi environment periodicaly get >90% of CPU and >1.5g of memory fast-cgi environment: SPAWNFCGI="/usr/local/bin/spawn-fcgi" FCGIPROGRAM="/usr/local/bin/php" FCGIPORT="" PHP_FCGI_CHILDREN=200 PHP_FCGI_MAX_REQUESTS=2000 FCGI_WEB_SERVER_ADDRS="127.0.0.1" ALLOWED_ENV="PATH USER" ALLOWED_ENV="$ALLOWED_ENV PHP_FCGI_MAX_REQUESTS FCGI_WEB_SERVER_ADDRS" periodicaly i have in top: 4968 www-data 19 0 1964m 1.4g 149m R 59.0 17.7 1:46.77 php 4856 www-data 17 0 2054m 1.6g 148m R 31.9 17.5 1:59.90 php 4846 www-data 18 0 1316m 1.1g 148m R 26.1 14.8 1:16.63 php 4866 www-data 15 0 153m 14m 149m S 5.5 0.2 0:15.51 php 4788 www-data 15 0 155m 16m 152m S 4.5 0.2 0:11.37 php 4809 www-data 16 0 154m 15m 149m S 4.5 0.2 0:11.07 php 4890 www-data 15 0 153m 13m 148m R 3.5 0.2 0:11.96 php 4870 www-data 16 0 153m 15m 148m S 2.6 0.2 0:12.22 php 7126 www-data 15 0 153m 14m 148m S 2.3 0.2 0:10.43 php 4945 www-data 15 0 152m 13m 148m S 1.9 0.2 0:13.35 php 4986 www-data 15 0 153m 14m 149m S 1.6 0.2 0:14.95 php 4823 www-data 15 0 152m 13m 148m S 1.3 0.2 0:14.64 php 4829 www-data 15 0 153m 13m 149m S 1.3 0.2 0:13.09 php 4879 www-data 15 0 153m 14m 148m S 1.3 0.2 0:17.27 php strace -p pid shows only next: mremap(0x2a9f3fa000, 1812733952, 1812733952, MREMAP_MAYMOVE) = 0x2a9f3fa000 -- Edit this bug report at http://bugs.php.net/?id=42180&edit=1
#41824 [Opn->WFx]: move_uploaded_file open_basedir problem
ID: 41824 Updated by: [EMAIL PROTECTED] Reported By: mueller at intertrend dot de -Status: Open +Status: Wont fix Bug Type: Safe Mode/open_basedir Operating System: SUSE LINUX 10.0 PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-04-05 21:44:26] carsten at bleicker dot de vhost.conf: php_admin_value open_basedir /home/pumatertion/public_html php_admin_value upload_tmp_dir /home/pumatertion/public_html/.temp_uploads works on my server .temp_uploads has to be writeable for apache. otherwise it seems that php uses the default /tmp folder [2007-10-10 01:31:29] mueller at intertrend dot de ./. [2007-10-08 12:18:05] gkieffer at evolutive dot org Hi, After some investigation, here's what I've found. move_uploaded_file() makes use of the internal PHP function php_copy_file() when source file and destination file are not on the same filesystem (rename() works only on a single FS). php_copy_file() changed from version 4.4.2 to 4.4.3: # diff -u php-4.4.2/ext/standard/file.c php-4.4.3/ext/standard/file.c [ ... discarded some stuff ...] @@ -2196,7 +2201,7 @@ safe_to_copy: srcstream = php_stream_open_wrapper(src, "rb", - STREAM_DISABLE_OPEN_BASEDIR | REPORT_ERRORS, + ENFORCE_SAFE_MODE | REPORT_ERRORS, NULL); if (!srcstream) I guess the STREAM_DISABLE_OPEN_BASEDIR flag meant "bypass open_basedir". And as that flag is gone... Anyway, even with PHP 4.4.3 and above, if 'upload_tmp_dir' and the destination of move_uploaded_file() are on the same FS, everything works fine as as "rename()" is used (which is not affected by open_basedir restrictions). I "solved" the issue by moving my upload_tmp_dir to the same FS where my websites are stored. Bye, G. [2007-10-08 09:45:00] gkieffer at evolutive dot org Hi, I have the same behavior (that contradicts the documentation): source argument of move_uploaded_file() is checked against open_basedir. As requested by '[EMAIL PROTECTED]', I've tried the latest PHP4 snapshot (php4-STABLE-200710080830) and the open_basedir restriction is still enforced on the source parameter of move_uploaded_file. 4.4.8-dev (snapshot): KO 4.4.7 : KO 4.4.6 : KO 4.4.5 : KO 4.4.3 : KO 4.4.2 : OK 4.4.1 : (I assume, I haven't tested it) 4.4.0 : OK Here's some extra info about my environment: Linux Debian Sarge Apache 2.0.59 (compiled, not a Debian pkg) PHP 4.4.x compiled as a module for Apache 2.0.59 upload_tmp_dir = /var/run/php-file-uploads open_basedir = /wrk1/htdocssds/site.fqdn/ /var and /wrk1 are different (ext3) filesystems. destination dir of move_uploaded_file() is /wrk1/htdocssds/site.fqdn/backoffice/photo_gest/ If I add '/var/run/php-file-uploads/' to open_basedir everything works fine but this is not the expected behavior. Hope it helps ! Bye, G. [2007-06-27 15:49:08] [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/41824 -- Edit this bug report at http://bugs.php.net/?id=41824&edit=1
#39883 [Opn->WFx]: ftp_get - coredump
ID: 39883 Updated by: [EMAIL PROTECTED] Reported By: youza at post dot cz -Status: Open +Status: Wont fix Bug Type: FTP related Operating System: Fedora Core 4 PHP Version: 4.4.4 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-07-18 10:03:35] youza at post dot cz This problem relate to system call select() and max size of structure fd_set - relate to __FD_SETSIZE __FD_SETSIZE increase to 65536 in files: /usr/include/bits/typesizes.h /usr/include/linuxthreads/bits/typesizes.h /usr/include/linux/posix_types.h recompile PHP and the core dump there's not again. [2007-01-11 09:57:13] [EMAIL PROTECTED] I don't get it either. If there is no way to reproduce it NOT on your server, then I'd suspect that the problem is somewhere else on your server and not in PHP. [2007-01-08 10:26:55] youza at post dot cz No, the PHP CLI command is ok and file is transferred. I use the ftp_nb_get - this function ok (no problem). What's the difference between ftp_get and ftp_nb_get in the source code ? Hmm, our server is very mass hosting system - the number of virtual servers is cca 1800 (not all very active). The config contains : ( example for one virtual) DocumentRoot /path/to/home/ ServerName www.xxx.xx TransferLog /var/log/httpd/XXX/home/access php_admin_value include_path .:/path/to/home/ php_admin_value doc_root /path/to/home/ php_admin_value open_basedir /path/to/home/ i reduce the number of virtulas to 950 and ftp_get work ok ( 20 times test). The next tests is very interesting 1. Virtual hosts 1205 - error ( segmentation fault) 2. Virtual hosts 1204 - different error - www page in the Firefox show error and the same error messages were saved to file name "0" - zero !!! FTP file not transferred. -rw-rw-r-- 1 apache webuser 445 Jan 8 10:06 0 The "0" file contains: [08-Jan-2007 10:00:17] PHP Warning: ftp_login() expects parameter 1 to be resource, boolean given in /path/to/home/test.php on line 37 [08-Jan-2007 10:00:17] PHP Warning: ftp_get() expects parameter 1 to be resource, boolean given in /path/to/home/test.php on line 43 [08-Jan-2007 10:00:17] PHP Warning: ftp_close() expects parameter 1 to be resource, boolean given in /path/to/home/test.php on line 51 3. Virtual hosts 1203 - error Segmentation fault ftp file not transferred buf the directory contains the empty destination file: -rw-rw-r-- 1 apache webuser0 Jan 8 10:16 test_l.dat 4. Virtual hosts 1202 the same like 3. 5. Virtual hosts 1201 the same like 2. but error message in web browser and "0" file is: [08-Jan-2007 10:17:47] PHP Warning: ftp_get(): Opening BINARY mode data connection for welcome.msg (241 bytes). in /path/to/home/test.php on line 43 6. Virtual hosts <= 1200 - work OK, file transferred ( 20 tests) Apache and php not produce any error message with file or system limits problem. The system limits: ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited pending signals (-i) 32765 max locked memory (kbytes, -l) 32 max memory size (kbytes, -m) unlimited open files (-n) 4096 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 32765 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited /proc/sys/fs/file-max 206037 /proc/sys/fs/file-nr 4096 0 206037 The system: Linux version 2.6.17-1.2142_FC4smp FC4 glibc-2.3.6, httpd-2.0.54 httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c The apache working model: prefork. I don't get it . [2007-01-03 15:30:30] [EMAIL PROTECTED] Are you able to replicate it using PHP CLI? Or is it reproducible only with Apache2? For the record, I don't see any problems with fetching the "welcome.msg" from the server you mentioned using the reproduce code of yours with _both_ Apache2/worker and PHP CLI. [2007-01-03 15:10:16] youza at post dot cz Yes I reproduce it in the public FTP server: URL: ftp://atrey.karlin.mff.cuni.cz/welcome.msg Result: Warning: ftp_get(): Opening BINARY mode data connection for welcome.msg (241 bytes). in /web/docs/tester/youza/ftp/t
#32494 [Ver->WFx]: crash when using expat in a class (Works with PHP 5.1)
ID: 32494
Updated by: [EMAIL PROTECTED]
Reported By: evert at rooftopsolutions dot nl
-Status: Verified
+Status: Wont fix
Bug Type: XML related
Operating System: Linux glibc 2.3.4
PHP Version: 4CVS-2005-07-30
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2007-06-08 16:21:26] nick at prioritycolo dot com
Still seeing this same issue in PHP 4.4.7 (two years later?!) with the
CPanel build of Apache and PHP on Centos "4.5". Seeing core dumps with
vBulletin's cron job, upgrading to PHP 5.x not a short-term option on
the shared box in question.
Back trace from the vBulletin cron.php throws me:
#0 0xe410 in __kernel_vsyscall ()
#1 0x4a2137a5 in raise () from /lib/tls/libc.so.6
#2 0x4a215209 in abort () from /lib/tls/libc.so.6
#3 0x4a247a1a in __libc_message () from /lib/tls/libc.so.6
#4 0x4a24e2bf in _int_free () from /lib/tls/libc.so.6
#5 0x4a24e63a in free () from /lib/tls/libc.so.6
#6 0x08148414 in poolDestroy (pool=0x4a315840)
at
/home/cpapachebuild/buildapache/php-4.4.7/ext/xml/expat/xmlparse.c:5425
#7 0x0814a38b in php_XML_ParserFree (parser=0x86844d0)
at
/home/cpapachebuild/buildapache/php-4.4.7/ext/xml/expat/xmlparse.c:1055
etc etc etc
Instant "*** glibc detected *** double free or corruption" occurs:
class test {
function test() {
// initialize parser
$this->parser = xml_parser_create();
xml_set_element_handler( $this->parser,
array( & $this, "startTag" ),
array( & $this, "endTag" )
);
}
}
$parser = new test();
Sigh, I'm guessing we may be SoL on this one...
[2005-10-31 11:22:04] troels at kyberfabrikken dot dk
Does anybody know for how long this problem have existed ? Will it be
fixed with next release for php4 ?
xml_set_object does btw. not have the same problem.
[2005-08-18 10:54:43] [EMAIL PROTECTED]
See also bug #34150
[2005-05-17 10:46:57] [EMAIL PROTECTED]
Does NOT happen with PHP 5 (using libxml instead of expat)
[2005-05-05 01:01:03] evert at rooftopsolutions dot nl
Thank you rmartins!!!
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/32494
--
Edit this bug report at http://bugs.php.net/?id=32494&edit=1
#39046 [Asn->WFx]: double free on circular references (PHP 4 only!)
ID: 39046
Updated by: [EMAIL PROTECTED]
Reported By: checat at yandex dot ru
-Status: Assigned
+Status: Wont fix
Bug Type: Reproducible crash
Operating System: RHEL4
PHP Version: 4.4.4
Assigned To: derick
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2006-10-05 11:31:13] [EMAIL PROTECTED]
We still need to address segfaults in 4.4.
[2006-10-05 11:15:50] [EMAIL PROTECTED]
Circular references is the easiest way one can shoot his own leg.
Upgrade to PHP5, which doesn't segfault.
[2006-10-05 11:13:09] checat at yandex dot ru
To have "double free" bug, one needs to wrap my test case into a
function.
[2006-10-05 11:07:47] checat at yandex dot ru
Description:
When freeing array variables with multiple references, variables which
should still be accessible via other reference may be unexpectedly
freed.
Depending of the code it may produce data corruption, glibc-detected
memory corruption or segfault.
Reproduce code:
---
'1', 'parent_id'=>NULL);
$child1 = array('id'=>'2', 'parent_id'=>'1');
// build tree with references up and down
$root['childs'] = array();
$child1['parent'] = & $root;
$child1['parent']['childs'][] = & $child1;
$child1['childs'] = array();
print_r($root['childs'][0]['childs']);
unset($child1);
print_r($root['childs'][0]['childs']);
?>
Expected result:
Array
(
)
Array
(
)
Actual result:
--
CGI:
Array
(
)
Array
(
)
Segmentation fault
Apache2/prefork/mod_php: no output, Segmentation fault in log
--
Edit this bug report at http://bugs.php.net/?id=39046&edit=1
#39323 [Opn->WFx]: ifx_fetch_row returns shortened values (PHP 4 only! informix is in PECL now)
ID: 39323 Updated by: [EMAIL PROTECTED] Reported By: tobin dot lloyd at cognitomobile dot co dot uk -Status: Open +Status: Wont fix Bug Type: Informix related Operating System: Unix PHP Version: 4.4.4 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2008-06-19 15:05:38] [EMAIL PROTECTED] Please report it here: http://pecl.php.net/bugs/report.php?package=informix And please note that this extension is not maintained anymore and is looking for new maintainers. [2006-10-31 16:23:12] tobin dot lloyd at cognitomobile dot co dot uk Description: I'm running an ifx_query/ifx_fetch row on a table containing an lvarchar(1000) field. When the field contains more than 255 characters the element of the array returned only contains the first 255 characters. I've verified the contents of the field and it does indeed contain 268 characters. -- Edit this bug report at http://bugs.php.net/?id=39323&edit=1
#39254 [Opn->WFx]: Refcount error with static variables and object references (PHP4 only)
ID: 39254 Updated by: [EMAIL PROTECTED] Reported By: benoit dot heinrich at swisscom dot com -Status: Open +Status: Wont fix Bug Type: Class/Object related Operating System: Linux PHP Version: 4.4.4 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-06-19 23:51:29] helping at hotmail dot com not sure if you still need it, there is a workaround here: http://www.phphacks.com/content/view/40/33/ [2006-10-25 22:32:10] judas dot iscariote at gmail dot com benoit: is very likely you are on your own now, PHP5 is out since years and certainly solve your problem, PHP4 active development has ceased permanently, it is only open to security fixes or severe regresions that affects large part of the user base. [2006-10-25 14:49:05] [EMAIL PROTECTED] I really doubt there will be any active development in 4.x branch, for we're mostly working on 5.x and 6.x at the moment. [2006-10-25 14:42:31] benoit dot heinrich at swisscom dot com I tried to find a workaround, and when I tried to use the 'global' keyword instead of the 'static' then it gives exactly the same problem. I'm still searching for a workaround but for now I have nothing. Cheers, /Benoit [2006-10-25 14:11:12] benoit dot heinrich at swisscom dot com I'm sorry but I'm using php 4.4 and I can't use PHP 5 for a lot of reasons. Do you have any fix for php 4.4 ? Cheers, /Benoit 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/39254 -- Edit this bug report at http://bugs.php.net/?id=39254&edit=1
#40746 [Asn->WFx]: PHP <= 4.4.6 mssql_connect() & mssql_pconnect() local buffer overflow
ID: 40746 Updated by: [EMAIL PROTECTED] Reported By: youza at post dot cz -Status: Assigned +Status: Wont fix Bug Type: MSSQL related Operating System: Windows PHP Version: 4.4.6 Assigned To: fmk New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-03-07 17:37:40] [EMAIL PROTECTED] This is a problem with the dbopen() function in Microsofts ntdblib library, and not a problem within the PHP extension. I'll add some length checks to the host parameter for mssql_connect() and mssql_pconnect() to prevent this from happening. The problem does not exists in php_dblib.dll (the same extension compiled with FreeTDS version of the dblib library). [2007-03-07 09:45:54] youza at post dot cz Description: PHP <= 4.4.6 mssql_connect() & mssql_pconnect() local buffer overflow and safe_mode bypass Reproduce code: --- See http://www.securityfocus.com/archive/1/462010/30/0/threaded or original url: http://retrogod.altervista.org/php_446_mssql_connect_bof.html -- Edit this bug report at http://bugs.php.net/?id=40746&edit=1
#40938 [Asn->WFx]: BUG #38263 (Binary data corrupted on multipart form-data) still exists (4.4.x)
ID: 40938 Updated by: [EMAIL PROTECTED] Reported By: ass3mbler at gmail dot com -Status: Assigned +Status: Wont fix Bug Type: HTTP related Operating System: Linux Gentoo 2.6.x PHP Version: 4.4.6 Assigned To: iliaa New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-09-13 14:15:13] eugene dot ware at nextharbour dot com This bug seems to be present with PHP 4.4.7 even though it looks like these patches have been applied to it. In particular, posting a multipart form containing a file as one of the parts that has 0 or NULL characters in it stuffs up and the $_FILES array is not populated, and reading from php://input seems to truncate the data (losing a large part of the start of the data). Is this bug still open? [2007-03-28 17:51:35] ass3mbler at gmail dot com Description: The BUG #38236(http://bugs.php.net/bug.php?id=38236),correctly addressed and fixed in the PHP 5.x codebase, is still present in the PHP 4.4.x codebase. I've tested and reproduced the same problem with many installations ranging from PHP 4.4.0 to PHP 4.4.6 included. I've used the relevant patches from iliaa for the files: /main/php_variables.c (http://cvs.php.net/viewvc.cgi/php-src/main/php_variables.c?r1=1.127&r2=1.128 /main/rfc1867.c (http://cvs.php.net/viewvc.cgi/php-src/main/rfc1867.c?r1=1.186&r2=1.187) adapting them for the 4.4.x codebase, and they seems to work correctly. The patches are available here: patch for php_variables.c => http://www.box.net/shared/akyjqyq55s patch for rfc1867.c => http://www.box.net/shared/2ime21vb4j Reproduce code: --- Same as BUG #38236(http://bugs.php.net/bug.php?id=38236) Expected result: BUG #38236(http://bugs.php.net/bug.php?id=38236) Actual result: -- BUG #38236(http://bugs.php.net/bug.php?id=38236). Seems fixed applying the attached patches -- Edit this bug report at http://bugs.php.net/?id=40938&edit=1
#41862 [Opn->WFx]: Errorhandler doesn't work (PHP4 only)
ID: 41862
Updated by: [EMAIL PROTECTED]
Reported By: thomas at thoftware dot de
-Status: Open
+Status: Wont fix
Bug Type: Scripting Engine problem
Operating System: Windows XP
PHP Version: 4.4.7
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2007-07-18 08:40:50] thomas at thoftware dot de
So someone may change status to "Wont fix"? And maybe add something
like "Don't use functions as argument for require() when setting an
errorhandler." to the documentation of set_error_handler()?
[2007-07-10 21:55:09] [EMAIL PROTECTED]
right, there's a problem with PHP 4 if foo does not exist, but I doubt
anybody is going to fix it.
Program received signal SIGSEGV, Segmentation fault.
php_strip_url_passwd (url=0x0) at
/home/johannes/src/php/PHP_4_4/main/fopen_wrappers.c:481
481 while (*p) {
(gdb) bt
#0 php_strip_url_passwd (url=0x0) at
/home/johannes/src/php/PHP_4_4/main/fopen_wrappers.c:481
#1 0x080b46d8 in php_message_handler_for_zend (message=2, data=0x0) at
/home/johannes/src/php/PHP_4_4/main/main.c:812
#2 0x080f22e1 in execute (op_array=0x8df088c) at
/home/johannes/src/php/PHP_4_4/Zend/zend_execute.c:2240
#3 0x080df3ab in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/johannes/src/php/PHP_4_4/Zend/zend.c:935
#4 0x080b3805 in php_execute_script (primary_file=0xbf88fed0) at
/home/johannes/src/php/PHP_4_4/main/main.c:1757
#5 0x080f9d39 in main (argc=1, argv=0xbf88ff94) at
/home/johannes/src/php/PHP_4_4/sapi/cli/php_cli.c:838
[2007-07-09 13:45:09] thomas at thoftware dot de
At 5 Jul 1:55pm UTC somebody changed the subject and added ' (PHP4
only)' with no additional comment. Since then no further action took
place. Can any of you developers out there tell me what this means?
[2007-07-03 08:30:22] thomas at thoftware dot de
I've checked the documentation another time and did not find anything
that explains or even discusses the above behaviour. As I'm not sure if
anyone is reading this while the status is "Bogus", I've decided to
reopen it.
Maybe someone can read my additional submissions - and if you are sure
it is bogus, than please give me a little more specific hint, where I
can find it in the documentation (as normally done when a submission is
answered with the "Thank you for taking the time"-Text).
Thank you in advance.
[2007-07-02 06:42:34] thomas at thoftware dot de
Something I found even earlier is: "The following error types cannot be
handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR,
E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT
raised in the file where set_error_handler() is called.". Is that what
you mean I should have read? Please note, that that isn't the problem.
I don't want these error types to be handled. I simply want the whole
construct to run and not to crash. The above script works fine in these
2 versions:
Reproduce code 2 (works):
---
function foo($foo) {
return($foo);
}
error_reporting(E_ALL);
require_once(foo('foo'));
Reproduce code 3 (works):
---
function ehandler($e,$t,$f,$l,$c) {
echo $t;
}
set_error_handler('ehandler');
error_reporting(E_ALL);
require_once('foo');
(Where 'fine' means, it shows the error an stops.)
Can you pleease explain to me, why the first version crashes
without any message?
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/41862
--
Edit this bug report at http://bugs.php.net/?id=41862&edit=1
#42080 [Opn->WFx]: PHP4isapi doesn't start when IIS is in x64 mode
ID: 42080 Updated by: [EMAIL PROTECTED] Reported By: jordymevissen at squaredms dot com -Status: Open +Status: Wont fix Bug Type: IIS related Operating System: Windows 2003 R2 SP2 x64 PHP Version: 4.4.7 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-07-23 11:46:37] jordymevissen at squaredms dot com Description: When installing PHP 4.4.7 on IIS 6 running on a Windows 2003 R2 SP2 x64 standard edition php doesn't run. Since I use Exchange 2007, which uses ONLY x64 it is no option to turn on the 32bits isolation modus. Our website developer doesn't support PHP 5. Please help us with a x64 compatible version! Expected result: PHP4isapi.dll working on Windows 2003 R2 SP2 x64 standard edition -- Edit this bug report at http://bugs.php.net/?id=42080&edit=1
#42286 [Opn->WFx]: php4isapi.dll registred on IIS block mine DLL correct work.
ID: 42286
Updated by: [EMAIL PROTECTED]
Reported By: bagulhus at gmail dot com
-Status: Open
+Status: Wont fix
Bug Type: IIS related
Operating System: Windows 2003
PHP Version: 4.4.7
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2007-08-13 15:26:22] bagulhus at gmail dot com
Description:
When php4isapi.dll is registred on my IIS, it's blocking mine DLL work
correctly.
A don't know why but while call a function from my dll it's return
empty.
I using IIS 6.0
Reproduce code:
---
The code bellow is ASP in VBS Script.
My Server Work within PHP and ASP files.
dllobj.Ativa("name1","zip code","license code","product key","checksum
code for activation")
Expected result:
Expected result is numbers with 7 digits, but when php4isapi.dll is
seted on IIS Filters ISAPI that code result emply.
Actual result:
--
emply string
--
Edit this bug report at http://bugs.php.net/?id=42286&edit=1
#45175 [Opn->Bgs]: -
ID: 45175 Updated by: [EMAIL PROTECTED] -Summary: Janis Dean weatherwoman FoxNews N.Y. hacked this website for storms in U.S. Reported By: costors at yahoo dot com -Status: Open +Status: Bogus -Bug Type: Streams related +Bug Type: Feature/Change Request Operating System: systemax PHP Version: 4.4.8 New Comment: . Previous Comments: [2008-06-04 13:27:24] costors at yahoo dot com Description: Janice Dean my suspect of snide slang remark towards my silver mind control report to this website.E-mail [EMAIL PROTECTED] Reproduce code: --- She's into devil worship from Wisconsin USA and a computer hacker. Expected result: Why hasn't this woman plus others who are connected to election swinging with squid and other devise used no correct spelling information word begins with d, been apprehended with other the illegal beagles in this country. You had better find a new Department of Defence head and dump Gates. Get him a U. of MASS. job. Actual result: -- Weather report from Janice Dean Fox television channel New York. Others who are reporters that are citizens of other countries. -- Edit this bug report at http://bugs.php.net/?id=45175&edit=1
#38670 [Opn->WFx]: Whole 4.4.x branch has problem with open_basedir option nested from Apache2
ID: 38670 Updated by: [EMAIL PROTECTED] Reported By: serokka at hrn dot ru -Status: Open +Status: Wont fix Bug Type: Apache2 related Operating System: FreeBSD 4.10 PHP Version: 4.4.4 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-07-13 21:14:52] lars at erhardsen dot dk I'm also experiencing this on Linux 2.4.27, Apache 2.0.59 and PHP 4.4.9. Sometimes, files cannot be found, either resulting in strange file-not-found errors in for instance WordPress or in the safe mode restriction error. I ran PHP 4.4.0 before, and experienced no problems at all. [2007-06-16 13:04:17] noc at smartterra dot de Update on my first submission on this bug: I can reproduce it now on FreeBSD 6.2, Apache 2.0.59 and PHP4.4.7. No .htaccess oder any other defined .html-Handler. Loading test.HTML produces this error: [Sat Jun 16 15:01:17 2007] [error] [client ] PHP Warning: Unknown(): SAFE MODE Restriction in effect. The script whose uid/gid is 1002/1002 is not allowed to access /usr/local/www/test owned by uid/gid 80/80 in Unknown on line 0 [2007-04-24 23:02:50] gbjbaanb at users dot sourceforge dot net I have Apache 2.0.59 with php 4.4.6 just installed and my sites, that worked fine with php_admin_value open_basedir /home/xxx/:/tmp/:xxx inside the vhost configuration now fail. This is on CentOS 4.4, x86_64. Quite serious? PHP has a reputation for insecure code, this is not good. [2007-04-03 16:10:16] marcel dot prisi at virtua dot ch I got the exact same problem on a FreeBSD-5.5 / Apache-2.0.59 / php-4.4.6 (all from ports) Adding a trailing slash to session.save_path didn't help, I had to comment it from the virtualhost config in order to have the error go away. Quite serious I think ... [2007-03-14 13:02:05] david dot guenault at gmail dot com update my precedent post : if you simply add a trailing slash to session.save_path this will discard the problem. here is why : in safe_mode.c in the function php_checkuid_ex when mode argument is CHECKUID_ALLOW_ONLY_DIR at line 119 s = strrchr(filename, DEFAULT_SLASH); returns a pointer to the last occurrence of the character / in the string filename. if your path is like this /data1sys/phpsession the pointer is on the second slash not at the end of the path. The uid/gid check is made on the parent folder (/data1sys) not the real folder (/data1sys/phpsession). So when /data1sys is owned by a user that is different from the user running apache, the test fail. 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/38670 -- Edit this bug report at http://bugs.php.net/?id=38670&edit=1
#38284 [Opn->WFx]: user_dir Does not work
ID: 38284 Updated by: [EMAIL PROTECTED] Reported By: egingell at sisna dot com -Status: Open +Status: Wont fix Bug Type: IIS related Operating System: Windows XP Pro PHP Version: 4.4.2 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2007-05-29 06:58:18] egingell at sisna dot com Ok, but just two questions: Why is there an option to set it up in php.ini? Why is there no comment that says it only works in Apache? I know it works in Apache, I have set it up many times. Also, if I change it in php.ini, Apache will override it and use its setting. Seems abit redundant to have that in PHP's settings when it doesn't even get used. As for Google searches, I did much searching with no useful results. [2007-05-28 22:23:48] xeo2001 at yahoo dot com Not to be a asshole, but a userdir is something your webserver (in this case IIS6) has to support. Php is just a parser of code to be executed on the server and _NOT_ a webserver it self. Ether install Apache 1.x or 2.x on your windows machine to support userdirs (read the docs about it) or use google on how to get userdir's on IIS6. [2006-08-01 15:06:40] egingell at sisna dot com Description: Setting the user_dir directive in php.ini has no affect. When attempting to go to http://localhost/~user/ a 404 Not Found error occurs. I can't find *any* documentation on what to set that directive to. I've tried "public_html", "C:\Documents and Settings", and "C:\Documents and Settings\*\public_html". None of which produced the desired results. I'm using IIS 6 to serve PHP 4.4.2 files. Expected result: A web page. Actual result: -- 404 File Not Found -- Edit this bug report at http://bugs.php.net/?id=38284&edit=1
#38408 [Ver->WFx]: shutdown_memory_manager crash (4_4 only)
ID: 38408 Updated by: [EMAIL PROTECTED] Reported By: gacek at intertele dot pl -Status: Verified +Status: Wont fix Bug Type: Reproducible crash Operating System: Linux FC4 x86_64 PHP Version: 4.4.3 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2006-08-10 09:24:45] gacek at intertele dot pl Description: Test tests/lang/bug35239.php causes segfault in php-4.4.3 4.4.2 version is also affected 5.1.4 is unaffected Reproduce code: --- x0 = new stdClass; $a->x0->y0 = 'a'; $a->x0->y1 =& $a->x0; $a->x0->y2 =& $a->x0; $a->x0->y0 = 'b'; var_dump($a); $a->x0->y1 = "ok\n"; echo $a->x0; ?> Expected result: No segfault Actual result: -- (gdb) where #0 0x2c8b2250 in raise () from /lib64/libc.so.6 #1 0x2c8b3720 in abort () from /lib64/libc.so.6 #2 0x2c8e804f in __libc_message () from /lib64/libc.so.6 #3 0x2c8ede4f in _int_free () from /lib64/libc.so.6 #4 0x2c8ee38e in free () from /lib64/libc.so.6 #5 0x0053b55a in shutdown_memory_manager (silent=0, clean_cache=0) at /usr/src/redhat/BUILD/php-4.4.3/Zend/zend_alloc.c:492 #6 0x00512b62 in php_request_shutdown (dummy=0x0) at /usr/src/redhat/BUILD/php-4.4.3/main/main.c:1010 #7 0x0056bf03 in main (argc=46, argv=0x7fff203128f8) at /usr/src/redhat/BUILD/php-4.4.3/sapi/cli/php_cli.c:883 -- Edit this bug report at http://bugs.php.net/?id=38408&edit=1
#37451 [Opn->WFx]: array_multisort fails to trigger by val copy of data (works in PHP >= 5.1)
ID: 37451 Updated by: [EMAIL PROTECTED] Reported By: pavlos at psychology dot gr -Status: Open +Status: Wont fix Bug Type: Arrays related Operating System: Linux PHP Version: 4.4.2 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2006-05-15 22:58:14] pavlos at psychology dot gr Thank you for your lightning fast reply! I have compiled the .tar.gz file. The problem is still here. [2006-05-15 22:14:39] [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 [2006-05-15 22:01:30] pavlos at psychology dot gr Description: This has been reported, filed as closed and in CVS, for more than a year ago. However, it is still alive in PHP 4.4.2. Reproduce code: --- $a = array(4, 3, 5, 2, 1); $b = array(4, 3, 5, 2, 1); $copy_a = $a; array_multisort($copy_a); print "\$a has changed as well: "; print_r($a); print "\$a should have been: "; print_r($b); Expected result: $a has changed as well: Array ( [0] => 1 [1] => 2 [2] => 3 [3] => 4 [4] => 5 ) $a should have been: Array ( [0] => 4 [1] => 3 [2] => 5 [3] => 2 [4] => 1 ) -- Edit this bug report at http://bugs.php.net/?id=37451&edit=1
#26838 [Opn->WFx]: signals make STDIN become EOF
ID: 26838
Updated by: [EMAIL PROTECTED]
Reported By: xuefer at 21cn dot com
-Status: Open
+Status: Wont fix
Bug Type: Filesystem function related
Operating System: linux
PHP Version: 4.3.4
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2008-07-05 21:41:44] dazjorz at dazjorz dot com
Hi [EMAIL PROTECTED],
Could you explain to me why this isn't a PHP bug? I don't observe this
behavior in any other language.
Please see the IEEE standard for alarm() at
http://www.opengroup.org/onlinepubs/95399/functions/alarm.html. They
don't speak about any behavior that STDOUT should be eof'd.
I consider this a bug in PHP, even if it is documented. (I couldn't
find any documentation, though.)
Sjors
$ perl -le '$SIG{ALRM} = sub { print "Alarm called!"; alarm(5); };
alarm(5); print while(<>)'
[2008-07-05 21:34:18] [EMAIL PROTECTED]
reopening on user request
[2004-01-08 20:35:02] [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
signals can and will interrupt readings from files &
sockets.
[2004-01-08 05:50:30] xuefer at 21cn dot com
Description:
code
shell> ./test.php
don't press CTRL+D to end input. but program exists in 3 seconds
because feof() return true
uncomment line 7 will works ok, exit only when i press CTRL+D
Reproduce code:
---
file ./test.php:
#!/usr/bin/php
--
Edit this bug report at http://bugs.php.net/?id=26838&edit=1
#35323 [Opn->WFx]: debug_backtrace() crash when assigned to global in error handler (works in 5.1)
ID: 35323
Updated by: [EMAIL PROTECTED]
Reported By: tcarter at noggin dot com dot au
-Status: Open
+Status: Wont fix
Bug Type: Scripting Engine problem
Operating System: Linux 2.4.31
PHP Version: 4.4.2RC1
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2006-08-15 00:42:19] tcarter at noggin dot com dot au
This crash seems to be related to the way that the
$errcontext (symbol table) argument passed to the error
handler is treated by debug_backtrace.
If you unset the $errcontext argument in the backtrace
(arg 5 of the final call) then the crash does not occur.
It appears to be specific to debug_backtrace() because
setting the global variable directly to $errcontext as a
named argument, or from func_get_args() does not trigger a
crash.
[2005-11-23 04:25:01] tcarter at noggin dot com dot au
PHP 4.3.11 does not crash
PHP 4.4.0 crashes
(Both versions tested on both Solars SPARC & Linux x86)
[2005-11-22 09:13:47] [EMAIL PROTECTED]
Does not happen with PHP 5.1 CVS.
[2005-11-22 08:33:53] tcarter at noggin dot com dot au
Description:
Calls to debug_backtrace() cause PHP to crash when
the result is assigned to a static or uninitialized global
variable inside a custom error handler when an error is
triggered from inside a (different) function.
Crash occurs with:
PHP 4.4.1
PHP 4.4.2RC2 (Snapshot 200511220601)
Does not occur with:
PHP 4.3.10
PHP 5.0.3
Reproduce code:
---
function err_h() {
global $backtrace;
$backtrace = debug_backtrace();
}
set_error_handler("err_h");
function crash_me() { trigger_error('Crash!'); }
crash_me();
Expected result:
PHP shouldn't crash
Actual result:
--
[EMAIL PROTECTED] php4-STABLE-200511220601]$ ./configure
--disable-all --enable-debug
...
[EMAIL PROTECTED] php4-STABLE-200511220601]$ gdb sapi/cli/php
...
This GDB was configured as "i386-redhat-linux-gnu"...
(gdb) set args -c ./php.ini-dist -f ~/crashme.php
(gdb) run
Starting
program: /home/users/trav/build/php4-STABLE-200511220601/sapi/cli/php
-c ./php.ini-dist -f ~/crashme.php
[Tue Nov 22 18:23:15 2005] Script:
'/home/users/trav/crashme.php'
---
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_opcode.c(152)
:
Block 0x0816F7E8 status:
Beginning: Overrun (magic=0x08170A78,
expected=0x7312F8DC)
End: Unknown
---
[Tue Nov 22 18:23:15 2005] Script:
'/home/users/trav/crashme.php'
---
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_opcode.c(159)
:
Block 0x0816A028 status:
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_variables.c(44)
:
Actual location (location was relayed)
Beginning: Overrun (magic=0x0816A060,
expected=0x7312F8DC)
End: Unknown
---
[Tue Nov 22 18:23:15 2005] Script:
'/home/users/trav/crashme.php'
---
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_opcode.c(159)
:
Block 0x08169FE8 status:
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_variables.c(44)
:
Actual location (location was relayed)
Beginning: Overrun (magic=0x0816A020,
expected=0x7312F8DC)
End: Unknown
---
[Tue Nov 22 18:23:15 2005] Script:
'/home/users/trav/crashme.php'
---
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_opcode.c(159)
:
Block 0x08170A40 status:
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_variables.c(44)
:
Actual location (location was relayed)
Beginning: Overrun (magic=0x0816FB68,
expected=0x7312F8DC)
End: Unknown
---
[Tue Nov 22 18:23:15 2005] Script:
'/home/users/trav/crashme.php'
---
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_opcode.c(159)
:
Block 0x08170938 status:
/home/users/trav/build/php4-STABLE-200511220601/Zend/zend_variables.c(44)
:
Actual location (location was relayed)
Beginning: Overrun (magic=0x08170A38,
expected=0x7312F8DC)
End: Unknown
---
[Tue Nov 22 18:23:15 2005] Script:
'/home/users/trav/crashme.php'
---
#36012 [Asn->WFx]: [PATCH] shell_exec leaks memory/pipe file descriptor on timeout (works in 5.1)
ID: 36012
Updated by: [EMAIL PROTECTED]
Reported By: anton dot php at titov dot net
-Status: Assigned
+Status: Wont fix
Bug Type: Program Execution
Operating System: Gentoo Linux
PHP Version: 4.4.2
Assigned To: pollita
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2006-04-11 17:25:19] [EMAIL PROTECTED]
Sara, this fall in your field of expertise.
[2006-01-14 20:49:47] anton dot php at titov dot net
It is a php4.x bug. It's not present in lates PHP5 snapshot, but in the
latest PHP4.4 snapshot it still exists.
[2006-01-14 20:22:03] anton dot php at titov dot net
Description:
shell_exec/backticks operator use popen to fork process, but do not
register this pipe with php_stream_fopen_from_pipe so in case of apache
timeout /I guess other APIs also have the same problem/.
I've fixed this problem by lookind at how other exec functions work, so
this fix should be fine.
patch follows:
--- php-4.4.2-orig/ext/standard/exec.c 2006-01-01 15:46:57.0
+0200
+++ php-4.4.2/ext/standard/exec.c 2006-01-14 20:53:18.059967960
+0200
@@ -552,6 +552,7 @@
int readbytes, total_readbytes=0, allocated_space;
pval **cmd;
char *ret;
+php_stream *stream;
if (ZEND_NUM_ARGS()!=1 || zend_get_parameters_ex(1,
&cmd)==FAILURE) {
WRONG_PARAM_COUNT;
@@ -571,10 +572,11 @@
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Unable to
execute '%s'", Z_STRVAL_PP(cmd));
RETURN_FALSE;
}
+stream = php_stream_fopen_from_pipe(in, "rb");
allocated_space = EXEC_INPUT_BUF;
ret = (char *) emalloc(allocated_space);
while (1) {
- readbytes = fread(ret+total_readbytes, 1,
EXEC_INPUT_BUF, in);
+ readbytes = php_stream_read(stream,
ret+total_readbytes, EXEC_INPUT_BUF);
if (readbytes<=0) {
break;
}
@@ -582,7 +584,7 @@
allocated_space = total_readbytes+EXEC_INPUT_BUF;
ret = (char *) erealloc(ret, allocated_space);
}
- pclose(in);
+ php_stream_close(stream);
RETVAL_STRINGL(ret, total_readbytes, 0);
Z_STRVAL_P(return_value)[total_readbytes] = '\0';
Reproduce code:
---
http://bugs.php.net/?id=36012&edit=1
#34811 [Asn->WFx]: fdf_get_value max size
ID: 34811
Updated by: [EMAIL PROTECTED]
Reported By: kc at netspirit dot ch
-Status: Assigned
+Status: Wont fix
Bug Type: FDF related
Operating System: Linux
PHP Version: 4.4.0
Assigned To: steinm
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2006-10-11 21:33:23] randyharden at utah dot gov
I have a pdf file with a text field (FooField) that can exceed 255
characters in length. I submit the form data using javascript command:
this.submitForm ("http://urlname/Submit_Form.php";);
In Submit_Form.php
$fdf = fdf_open_string(file_get_contents("php://input"));
$str = fdf_save_string($fdf);
//(the echo $str shows that all of the text string is their even if the
string length exceeds 255 characters)
echo $str;
but... if I try to extract the value using:
$FooField=fdf_get_value($fdf, "FooField");
I get the correct results for strings up to 255 characters
but I get NULL as a result for strings > 255 chaaracters.
[2005-10-11 14:09:29] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-10-10 15:55:30] kc at netspirit dot ch
code i used:
[2005-10-10 15:45:00] kc at netspirit dot ch
Description:
Problem getting value of PDF-Multiline-Fields if the value is loger
than 256 chars.
found "ASInt32 nr, size = 256;" in "PHP_FUNCTION(fdf_get_value)" in
"ext/fdf/fdf.c"
Reproduce code:
---
Reprodiction:
- go to: http://www.anyform.ch/test/132.pdf
- fill in the big field
- click on "Ausgabe-Optionen"
Expected result:
strText32 is of type string "hdsfj ... sdfhjsd"
Actual result:
--
strText32 is of type boolean ""
--
Edit this bug report at http://bugs.php.net/?id=34811&edit=1
#33802 [Asn->WFx]: crash in error handler (works with PHP 5.1)
ID: 33802
Updated by: [EMAIL PROTECTED]
Reported By: isitoya at wakhok dot ac dot jp
-Status: Assigned
+Status: Wont fix
Bug Type: Reproducible crash
Operating System: Suse9.2
PHP Version: 4CVS-2005-07-27
Assigned To: derick
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2005-07-22 09:44:21] [EMAIL PROTECTED]
I need to backport this to PHP 4.4.0, so I'm assigning it to myself -
note, it has nothing really to do with exceptions only.
http://news.php.net/php.zend-engine.cvs/3931
[2005-07-22 09:42:07] [EMAIL PROTECTED]
Fixed in CVS HEAD and PHP_5_0.
[2005-07-21 14:27:56] [EMAIL PROTECTED]
Dmitry, I can see some valgrind errors appearing only with
--disable-zend-memory-manager:
==7780== Invalid read of size 4
==7780==at 0x823AF65: _zend_is_inconsistent (zend_hash.c:53)
==7780==by 0x823C0F4: zend_hash_destroy (zend_hash.c:510)
==7780==by 0x82285B5: shutdown_executor (zend_execute_API.c:268)
==7780==by 0x8234722: zend_deactivate (zend.c:823)
==7780==by 0x81F416F: php_request_shutdown (main.c:1331)
==7780==by 0x829DB17: main (php_cli.c:1142)
==7780== Address 0x1BD72CC0 is 40 bytes inside a block of size 44
free'd
==7780==at 0x1B9057CD: free (in
/usr/lib/valgrind/vgpreload_memcheck.so)
==7780==by 0x82331EE: _zval_dtor_func (zend_variables.c:44)
==7780==by 0x822B0D0: _zval_dtor (zend_variables.h:35)
==7780==by 0x8228947: _zval_ptr_dtor (zend_execute_API.c:386)
==7780==by 0x8233450: _zval_ptr_dtor_wrapper
(zend_variables.c:175)
==7780==by 0x823C13B: zend_hash_destroy (zend_hash.c:519)
[2005-07-21 13:14:45] isitoya at wakhok dot ac dot jp
Description:
When I using Phing, My testcase with PEAR-SOAP and rdfapi-php had
stopped with segmentation fault.
And I Found that throwing exception in error_handler causes Seg fault.
Reproduce code:
---
-
no try and catch
Expected result:
nothing
Actual result:
--
*** glibc detected *** double free or corruption: 0x00af7970
***
*** glibc detected *** double free or corruption: 0x00af7a10
***
*** glibc detected *** double free or corruption: 0x00af07b0
***
--
no try and catch
Fatal error: Uncaught exception 'Exception' in
/usr/home/kent/tests/trigger_errorTest.php:11
Stack trace:
#0 [internal function]: errorHandler(256, 'error',
'/usr/home/kent/...', 7, Array)
#1 /usr/home/kent/tests/trigger_errorTest.php(7):
trigger_error('error', 256)
#2 /usr/home/kent/tests/trigger_errorTest.php(3): test()
#3 {main}
thrown in /usr/home/kent/tests/trigger_errorTest.php on line 11
*** glibc detected *** double free or corruption: 0x00af7870
***
*** glibc detected *** double free or corruption: 0x00af7910
***
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=33802&edit=1
#31451 [Asn->WFx]: __call can not work with __get (works in PHP 5.1)
ID: 31451
Updated by: [EMAIL PROTECTED]
Reported By: syre at citiz dot net
-Status: Assigned
+Status: Wont fix
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 4CVS-2005-01-18
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2005-01-11 04:08:44] syre at citiz dot net
_target=$target;
overload('ObjectShell');
}
function __get($name, &$value) {
return true;
}
function __set($name, $value) {
return true;
}
function __call($func, $args, &$return) {
$return=1;
return true;
}
function func1(){
echo "func1() called ";
return $this->_target->func1();
}
}
class Test {
function func1() {
return 2;
}
}
$t=new Test;
$p=new ObjectShell($t);
//this will work
echo $p->func1();
echo "\n";
//this will result "stack overflow" on php4.3.10
//if remove ObjectShell::__set,
//or ObjectShell::__func1()
//or replace ObjectShell::func1()
//with func1($a, $b){ return 1 }
//it will also ok
?>
[2005-01-08 12:18:49] syre at citiz dot net
Description:
//that will ok
echo $p->var1;
echo "\n";
echo $p->func1(9,7);
//that will cost script time out
//the same code will ok on 4.3.8 / 4.3.2
echo $p->func1(9,7);
echo "\n";
echo $p->var1;
Reproduce code:
---
http://community.csdn.net/Expert/topic/3707/3707113.xml?temp=.141308
Expected result:
1024
16
16
1024
Actual result:
--
script time out
--
Edit this bug report at http://bugs.php.net/?id=31451&edit=1
#31114 [Asn->WFx]: foreach modify array (works with PHP 5.1)
ID: 31114
Updated by: [EMAIL PROTECTED]
Reported By: clemens at gutweiler dot net
-Status: Assigned
+Status: Wont fix
Bug Type: Arrays related
Operating System: Linux 2.4.27
PHP Version: 4CVS
Assigned To: andi
New Comment:
We are sorry, but we can not support PHP 4 related problems anymore.
Momentum is gathering for PHP 6, and we think supporting PHP 4 will
lead to a waste of resources which we want to put into getting PHP 6
ready.
Previous Comments:
[2007-08-07 11:35:50] fedotov dot leon at gmail dot com
I stumbled across another werd behavior related to this bug:
[php]
$var = array(
"a" => array("foo"),
"b" => array("fox"),
"c" => "x"
);
foreach($var as $key => $val) {
echo "no matter what happends".$val;
}
/* $var is array(
"a" => array("foo"),
"b" => array("fox"),
"c" => "foo"
);
*/
[/php]
[2005-05-17 12:01:49] [EMAIL PROTECTED]
Works fine in PHP 5..
[2004-12-16 22:32:14] [EMAIL PROTECTED]
I just tested this on PHP 4.3.1 and 4.3.2 and it behaves in the same
way, making this a non-critical bug and not related to the foreach
speed-up patch. Assigning to Andi, as he might have a clue why this
happens. The new foreach code is definitely not the problem here.
[2004-12-16 13:07:17] [EMAIL PROTECTED]
(The only bug here is that it doesn't give a warning, using $k for both
key and value is not supposed to work!)
[2004-12-16 11:41:54] [EMAIL PROTECTED]
I don't think this was ever supposed to work.
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/31114
--
Edit this bug report at http://bugs.php.net/?id=31114&edit=1
#30302 [Opn->Asn]: SOAP: Implement Document/Literal with wrapped convention
ID: 30302
Updated by: [EMAIL PROTECTED]
-Summary: Implement Document/Literal with wrapped convention
Reported By: julien dot wajsberg at francetelecom dot com
-Status: Open
+Status: Assigned
-Bug Type: SOAP related
+Bug Type: Feature/Change Request
Operating System: Windows XP
-PHP Version: 5.0.2
+PHP Version: 5.2.6
-Assigned To:
+Assigned To: dmitry
Previous Comments:
[2008-07-03 15:33:12] carmi at avaya dot com
We are working with Zend and need to connect with Axis 2.0 which
doesn't support rpc/encoding so we need to support document/literal
wrapped.
As stated below, Zend 5.2 also doen't support for document/literal
wrapped WSDL generation.
[2008-07-03 14:52:04] julien dot wajsberg at francetelecom dot com
Although I've no more time to contriute to this but, someone requested
me to reopen the bug so that he could contribute.
[2007-12-09 01:58:26] brian dot nelson at chordiant dot com
I am also experiencing this problem. I don't think that it's even a
question that this isn't implemented.
I am running PHP 5.2.3 on Ubuntu (PHP 5.2.3-1ubuntu6.2) and trying to
use ClearSpace SOAP calls. It's dirty enough to get the authentication
working, but the calling of methods through __soapCall is pretty nasty.
.NET, Java, and C# all support wrapped methods. It's sad that PHP
doesn't.
I know that there is some work around PHP6 for SOAP connectivity, but
it would be really nice if we could work well with other systems in
PHP5.
Here's the CS soap doc:
http://www.jivesoftware.com/builds/docs/clearspace/latest/ClearspaceWebServicesDevGuide.html#ClearspaceWebServicesDevGuide-WebServiceStyle
[2007-09-21 01:16:02] php-bugs-0709 at nico dot edtinger dot at
(Sorry to comment on this old bug)
While it's possible to use doc/lit wrapped with SoapClient and
SoapServer it's a bit ugly because the child elements don't wrap
directly to the method parameters.
As doc/lit wrapped is used very often and sometimes the only
possibility it would still be nice to use it directly so you can write:
$client->add(2, 3);
on the client side and:
function add($arg1, $arg2) {
return $arg1 + $arg2;
}
on the server side. It would make SOAP transparent to handling class,
as it currently does with rpc/enc.
[2005-04-19 09:31:03] julien dot wajsberg at francetelecom dot com
Yes, the new location for the article is :
http://atmanes.blogspot.com/2005/03/wrapped-documentliteral-convention.html
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/30302
--
Edit this bug report at http://bugs.php.net/?id=30302&edit=1
#24485 [Opn->WFx]: $a = $b; become $a=&$b; when I use a function (PHP 4 only!)
ID: 24485 Updated by: [EMAIL PROTECTED] Reported By: bugs dot php dot net at public dot salagir dot com -Status: Open +Status: Wont fix Bug Type: Scripting Engine problem Operating System: * PHP Version: 4CVS-2005-08-23 New Comment: We are sorry, but we can not support PHP 4 related problems anymore. Momentum is gathering for PHP 6, and we think supporting PHP 4 will lead to a waste of resources which we want to put into getting PHP 6 ready. Previous Comments: [2006-07-19 14:29:30] [EMAIL PROTECTED] I've no idea what this is about. It is apparently not related to the reference fixes we did for PHP 4.4 although at that time I thought it was. [2006-07-19 14:06:55] [EMAIL PROTECTED] Derick: fixed, not fixed..? [2006-05-20 11:01:27] antonio dot caprio at gmail dot com To copy an array having object elements use unserialize(serialize(myarray)): test_var = 'this is set by $b instance'; print_r($a); print_r($b); $c = unserialize(serialize($a)); $c[0]->test_var = 'this is set by $c instance'; echo "-\n"; print_r($a); print_r($b); print_r($c); ?> Be careful! If you have __sleep AND __wakeup functions in your class you could have problem! [2006-05-10 15:45:33] php dot net at nanonanonano dot net CVS snapshot of PHP4 branch as of 2006-05-10 still shows this bug. And to reiterate a previously mentioned very polite note to the php developers... please actually run the trivially simple test case given in the bug report to see if it has been fixed. Also, please reference a specific CVS commit (ok, harder to do with cvs than svn, but still possible) that you think fixes this bug. That way, we have a fighting chance of seeing where you are looking in the code and might be able to help out; at present, we don't know where to start. (this is at least the fourth iteration of "try CVS"/"still broken" on this bug... it really is starting to make you look silly) [2005-03-24 21:48:33] [EMAIL PROTECTED] For Derick, see also bug #32261 (same issue?) 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/24485 -- Edit this bug report at http://bugs.php.net/?id=24485&edit=1
#45222 [Opn->Fbk]: Creating zipfiles with duplicate names segfaults
ID: 45222
Updated by: [EMAIL PROTECTED]
Reported By: crabbydata at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Zip Related
-Operating System: MS Vista
+Operating System: Windows Vista
PHP Version: 5.2.6
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
Previous Comments:
[2008-06-09 18:22:25] crabbydata at gmail dot com
Description:
When creating a new zip-file with the "ZipArchive::CREATE"-function,
and there already is a zipfile with the given filename Apache will crash
without any warning (just a Vista error popup saying it has already
stopped working).
Reproduce code:
---
open($zipfile, ZipArchive::CREATE) !== true) exit("Can't
create file ".$zipfile);
// Add stuff inside the zip-file
$zip->addFromString('tmp', 'bla'); // temporary file within zip
$zip->close();
// Same code as above so two identical files are (tried to be) created
if($zip->open($zipfile, ZipArchive::CREATE) !== true) exit("Can't
create file ".$zipfile);
// Add stuff inside the zip-file
$zip->addFromString('tmp', 'bla'); // temporary file within zip
$zip->close();
?>
Expected result:
When the second file is created, it should give out the exit-error:
"Can't create file myveryownzipfile.zip".
Or it should give a "fatal error!"-notice of PHP itself saying the
filename already exists or simply that the (second) file could not be
created (e.g. "duplicate filename").
Actual result:
--
When activating this script (only with the creation of a single
zipfile) through a form, and submitting it repeatingly (fast(!)), a
(Vista) error pops up saying "Apache.exe doesn't work any longer" and
Apache has been forced to shut down.
Screenshots (I've a Dutch-language Vista):
(1) http://img377.imageshack.us/img377/8170/06092008200500jp7.png
Translation: "Apache HTTP Server has stopped working
Searching for a solution..."
(2) http://img156.imageshack.us/img156/4051/06092008195928sd1.png
Translation: "Apache HTTP Server has stopped working
An error occured which made the program function incorrectly. The
program will now be closed and you'll get a notice when a solution is
available."
I installed/run PHP through the XAMPP-package
(http://www.apachefriends.org/en/xampp.html).
Zip-module information:
Extension Version: $Id: php_zip.c,v 1.1.2.38 2007/08/06 22:02:32 bjori
Exp $
Zip version: 2.0.0
Libzip version: 0.7.1
--
Edit this bug report at http://bugs.php.net/?id=45222&edit=1
#45489 [Opn->Bgs]: Additional .ini filre directory should not be a constant
ID: 45489 Updated by: [EMAIL PROTECTED] Reported By: edwin at cheatah dot nl -Status: Open +Status: Bogus Bug Type: *Configuration Issues Operating System: * PHP Version: 5.2CVS-2008-07-11 (snap) 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. See bug #45114 Previous Comments: [2008-07-11 20:16:45] edwin at cheatah dot nl Description: The directory for reading additional ini files is hardcoded (declared as a constant). The base php.ini location is configurable, the additional ini file dir isn't. Compare: php_ini_opened_path PHP_CONFIG_FILE_SCAN_DIR Why they should BOTH be configurable: What if I want to have multiple HTTP services with just a single set of binaries? I may want to have serveral httpd.conf files, and have an Apache process started with different configuration files. In these files I could want to use the PHPINIDir directive. This works fine. The problem is that phpinfo() keeps whining about the "Scan this dir for additional .ini files" It's impossible to override this setting. Quite silly as we can easily have multiple php.ini files for different goals (cli, http, etc). So first of all this should be configurable (and why not in php.ini?) Systems must be able to have multiple "instances" of PHP running without actually having to compile separate binaries for different goals. Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit this bug report at http://bugs.php.net/?id=45489&edit=1
#45489 [NEW]: Additional .ini filre directory should not be a constant
From: edwin at cheatah dot nl Operating system: ALL PHP version: 5.2CVS-2008-07-11 (snap) PHP Bug Type: *Configuration Issues Bug description: Additional .ini filre directory should not be a constant Description: The directory for reading additional ini files is hardcoded (declared as a constant). The base php.ini location is configurable, the additional ini file dir isn't. Compare: php_ini_opened_path PHP_CONFIG_FILE_SCAN_DIR Why they should BOTH be configurable: What if I want to have multiple HTTP services with just a single set of binaries? I may want to have serveral httpd.conf files, and have an Apache process started with different configuration files. In these files I could want to use the PHPINIDir directive. This works fine. The problem is that phpinfo() keeps whining about the "Scan this dir for additional .ini files" It's impossible to override this setting. Quite silly as we can easily have multiple php.ini files for different goals (cli, http, etc). So first of all this should be configurable (and why not in php.ini?) Systems must be able to have multiple "instances" of PHP running without actually having to compile separate binaries for different goals. Reproduce code: --- n/a Expected result: n/a Actual result: -- n/a -- Edit bug report at http://bugs.php.net/?id=45489&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45489&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45489&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45489&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45489&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45489&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45489&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45489&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45489&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45489&r=support Expected behavior:http://bugs.php.net/fix.php?id=45489&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45489&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45489&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45489&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45489&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45489&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45489&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45489&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45489&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45489&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45489&r=mysqlcfg
#43008 [Com]: php://filter uris ignore url encoded filternames and can't handle slashes
ID: 43008 Comment by: php at benjaminschulz dot com Reported By: php at benjaminschulz dot com Status: Assigned Bug Type: Streams related Operating System: linux PHP Version: 5.3CVS-2007-10-17 (CVS) Assigned To: hholzgra New Comment: The patch works perfectly for me. Previous Comments: [2008-07-11 09:16:14] arnaud dot lb at gmail dot com A possible fix would be to urldecode() filter names in the php:// wrapper before passing them to the filter API: http://arnaud.lb.s3.amazonaws.com/url_encoded_filter-43008.patch [2008-03-17 23:42:28] php at benjaminschulz dot com This should work because otherwise there is no way to pass valid and existing filternames as URIs to PHP. (This bug is approved by hartmut btw.) [2008-03-17 20:53:31] [EMAIL PROTECTED] And this should work because..? (IMO, it's expected, you pass invalid data -> you get an error..simple.) [2008-03-10 14:55:17] php at benjaminschulz dot com If the filtername is not URL encoded than i get this: Warning: readfile(): unable to create or locate filter "convert.iconv.ISO-8859-15" in ... Warning: readfile(): Unable to create filter (convert.iconv.ISO-8859-15) in ... Warning: readfile(): unable to locate filter "UTF-8" in ... Warning: readfile(): Unable to create filter (UTF-8) in ... [2007-10-17 17:04:40] php at benjaminschulz dot com Description: because filternames can contain slashes (convert.iconv.from-enc/to-enc) it should be possible to pass URL-encodet filternames to php://filter Reproduce code: --- http://bugs.php.net/?id=43008&edit=1
#22741 [Com]: session.bug_compat_warn and session.bug_compat_42 are ignored in the ini file
ID: 22741 Comment by: webmaster at paramiliar dot com Reported By: bodgadle at yahoo dot co dot uk Status: No Feedback Bug Type: Session related Operating System: Windows 2000 SP3 PHP Version: 4.3.2-RC New Comment: The problem normally arises when you are using a SESSION variable and a standard variable with the same name i.e $_SESSION['amount'] and $amount one possible fix (untested) is to kill the session if you have finished with it or unset your variables I beleive you can also issue an ini_set call to fix this but most of the time I have fixed this by just renaming variables Previous Comments: [2008-06-11 12:05:09] faizalbs at gmail dot com I have same problem here and it give me a headeach because it involve my client website. Someone can advise some solutions? [2003-04-28 11:14:06] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-03-17 19:51:43] [EMAIL PROTECTED] And your php.ini is under C:\winnt\ ?? What are the settings set to in phpinfo() output? [2003-03-17 16:19:14] bodgadle at yahoo dot co dot uk Hi there, I already checked and there's only 1 PHP.INI on my system and I am running latest version here's phnfo output showing version & ini path PHP Version 4.3.2-RC System Windows NT NUSWEB1 5.0 build 2195 Build Date Mar 17 2003 10:15:18 Server API Apache Virtual Directory Support enabled Configuration File (php.ini) Path C:\WINNT\php.ini [2003-03-17 16:02:48] [EMAIL PROTECTED] Then you are editing the wrong php.ini file or perhaps not actually running 4.3. Check phpinfo() to see which version it is and where it is expecting to read your php.ini file from. 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/22741 -- Edit this bug report at http://bugs.php.net/?id=22741&edit=1
#45420 [Opn->Bgs]: array_search() finds non-existent element after array_slice()
ID: 45420
Updated by: [EMAIL PROTECTED]
Reported By: tomas at matfyz dot cz
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Linux
PHP Version: 5.2.6
New Comment:
Do use the third parameter.
http://docs.php.net/array-search
Previous Comments:
[2008-07-03 16:35:34] tomas at matfyz dot cz
> 0 == 'any non-numeric string'
Yeees, but how is this related to array_search()? In no way, I believe.
Or at least, shouldn't be.
[2008-07-03 12:50:16] florian dot ember at gmail dot com
> array(1) {
> [0]=>
> int(0)
> }
0 == 'any non-numeric string'
[2008-07-02 18:34:54] tomas at matfyz dot cz
Description:
array_search() function finds non-existent element after array_slice()
is used to slice the array.
tested on 5.2.0 and 5.2.5, don't have access to newer system.
Reproduce code:
---
$a["nazdar"] = "pozdrav";
$a["write"] = 1;
$a[2] = "ahoj";
$a = array_slice($a, 2);
$keys = array_keys($a);
echo "keys:\n"; var_dump($keys);
check_array_search("wrqwdite2", $keys);
function check_array_search($val, $keys)
{
$i = array_search($val, $keys);
if ($i === false) {
echo "OK\n";
return;
}
echo "BUG!!! Non-existent value \"$val\" found in keys at
position $i!!!\n";
}
Expected result:
keys:
array(1) {
[0]=>
int(0)
}
OK
Actual result:
--
keys:
array(1) {
[0]=>
int(0)
}
BUG!!! Non-existent value "wrqwdite2" found in keys at position 0!!!
--
Edit this bug report at http://bugs.php.net/?id=45420&edit=1
#45449 [Opn->Csd]: filesize() regression using ftp wrapper
ID: 45449 Updated by: [EMAIL PROTECTED] Reported By: crrodriguez at suse dot de -Status: Open +Status: Closed Bug Type: FTP related Operating System: linux PHP Version: 5.2.6 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. Thanks for the patch. Previous Comments: [2008-07-08 06:59:26] crrodriguez at suse dot de Description: Unfortunately, my bugfix for bug #43498 introduced a regression that can be seen using filesize() and the FTP wrapper Reproduce code: --- ftp://ftp-1.gwdg.de/pub/locatedb')); ?> Expected result: int(143162194) Actual result: -- int(0) I have fixed it, though, oops, sorry ;-) there it goes: http://stuff.cristianrodriguez.net/patches/filesize-regression.patch -- Edit this bug report at http://bugs.php.net/?id=45449&edit=1
#45410 [Bgs]: Bad result in an expression evaluation
ID: 45410
User updated by: ensnnet at gmail dot com
Reported By: ensnnet at gmail dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: windows xp sp3
PHP Version: 5.2.6
New Comment:
Te answer on my machine for the previous code is:
Here l1 and l2 is: bool(false)
But here l1 and l2 is: bool(true)
And here l2 and l1 is: bool(false)
What happens?
... And I think it must be false in all the three cases !!
Thanks in advance for your attention,
jaz
Previous Comments:
[2008-07-11 17:55:55] ensnnet at gmail dot com
Sorry by I still I think something is wrong. Please take a while to
see the next code (or run it on your machine):
";
echo "Here l1 and l2 is: ";
var_dump($l1 and $l2);
echo "But here l1 and l2 is: ";
var_dump($l1_and_l2);
echo "And here l2 and l1 is: ";
var_dump($l2_and_l1);
echo "What happens?";
echo "";
?>
[2008-07-02 21:32:31] [EMAIL PROTECTED]
Please take a look at the examples on php.net/operators.logical
[2008-07-02 19:03:39] [EMAIL PROTECTED]
Please see the operator precedence table and explanation on the page I
ahve given, somewhere in the upper area are "&&", "||" and so on, then
"=" and in the bottom "and", "or", "xor" which means the assignment is
done before the "and" operator is executed. For further questions please
refer to other support forums, see http://php.net/support.php
[2008-07-02 17:12:16] ensnnet at gmail dot com
Thank for your answer [EMAIL PROTECTED] but still I think someone is not
correct, perhaps I am wrong.
I have read your link:
http://es2.php.net/manual/en/language.operators.logical.php:
And y read there:
$a and $b => TRUE if both $a and $b are TRUE.
I had writed another simple code that dont run as expected (I send you
at the end of this note). The result that show on my computer is:
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is FALSE
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is TRUE
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is FALSE
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is FALSE
I think the second line must be as the another lines. What is wrong?
Thanks for your attention,
jaz
This is the code:
\$l1 and
\$l2 is ".showAstxt($l1 and $l2)."";
echo "\$l1 = ".showAstxt($l1).", \$l2 = ".showAstxt($l2)." => \$l1 and
\$l2 is ".showAstxt($flag1)."";
echo "\$l1 = ".showAstxt($l1).", \$l2 = ".showAstxt($l2)." => \$l1 and
\$l2 is ".showAstxt($flag2)."";
echo "\$l1 = ".showAstxt($l1).", \$l2 = ".showAstxt($l2)." => \$l1 and
\$l2 is ".showAstxt($flag3)."";
//
function showAstxt($v)
{
return $v ? "TRUE" : "FALSE";
}
?>
[2008-07-01 23:08:37] [EMAIL PROTECTED]
sorry wrong URL, correct one: http://php.net/operators
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/45410
--
Edit this bug report at http://bugs.php.net/?id=45410&edit=1
#45488 [NEW]: str_replace failed when the $subject parameter length exceeds 100009
From: webez dot cn at gmail dot com Operating system: Windows 2003 PHP version: 5.2.6 PHP Bug Type: Regexps related Bug description: str_replace failed when the $subject parameter length exceeds 19 Description: if the $subject parameter's length exceeds 19, str_replace has no return value. This has been reproduced on windows 2003 with php 5.2.6 and Linux with php 5.2.5 PS: If there is backslash in the $subject parameter and $pattern parameter, the critical poiont will change, the maximum string length to reproduce this bug will increase. Reproduce code: --- "; } ?> Expected result: str_replace with length: 19 passed str_replace with length: 100010 passed Actual result: -- str_replace with length: 19 passed str_replace with length: 100010 failed -- Edit bug report at http://bugs.php.net/?id=45488&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45488&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45488&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45488&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45488&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45488&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45488&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45488&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45488&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45488&r=support Expected behavior:http://bugs.php.net/fix.php?id=45488&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45488&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45488&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45488&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45488&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45488&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45488&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45488&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45488&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45488&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45488&r=mysqlcfg
#45410 [Bgs]: Bad result in an expression evaluation
ID: 45410
User updated by: ensnnet at gmail dot com
Reported By: ensnnet at gmail dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: windows xp sp3
PHP Version: 5.2.6
New Comment:
Sorry by I still I think something is wrong. Please take a while to
see the next code (or run it on your machine):
";
echo "Here l1 and l2 is: ";
var_dump($l1 and $l2);
echo "But here l1 and l2 is: ";
var_dump($l1_and_l2);
echo "And here l2 and l1 is: ";
var_dump($l2_and_l1);
echo "What happens?";
echo "";
?>
Previous Comments:
[2008-07-02 21:32:31] [EMAIL PROTECTED]
Please take a look at the examples on php.net/operators.logical
[2008-07-02 19:03:39] [EMAIL PROTECTED]
Please see the operator precedence table and explanation on the page I
ahve given, somewhere in the upper area are "&&", "||" and so on, then
"=" and in the bottom "and", "or", "xor" which means the assignment is
done before the "and" operator is executed. For further questions please
refer to other support forums, see http://php.net/support.php
[2008-07-02 17:12:16] ensnnet at gmail dot com
Thank for your answer [EMAIL PROTECTED] but still I think someone is not
correct, perhaps I am wrong.
I have read your link:
http://es2.php.net/manual/en/language.operators.logical.php:
And y read there:
$a and $b => TRUE if both $a and $b are TRUE.
I had writed another simple code that dont run as expected (I send you
at the end of this note). The result that show on my computer is:
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is FALSE
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is TRUE
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is FALSE
$l1 = TRUE, $l2 = FALSE => $l1 and $l2 is FALSE
I think the second line must be as the another lines. What is wrong?
Thanks for your attention,
jaz
This is the code:
\$l1 and
\$l2 is ".showAstxt($l1 and $l2)."";
echo "\$l1 = ".showAstxt($l1).", \$l2 = ".showAstxt($l2)." => \$l1 and
\$l2 is ".showAstxt($flag1)."";
echo "\$l1 = ".showAstxt($l1).", \$l2 = ".showAstxt($l2)." => \$l1 and
\$l2 is ".showAstxt($flag2)."";
echo "\$l1 = ".showAstxt($l1).", \$l2 = ".showAstxt($l2)." => \$l1 and
\$l2 is ".showAstxt($flag3)."";
//
function showAstxt($v)
{
return $v ? "TRUE" : "FALSE";
}
?>
[2008-07-01 23:08:37] [EMAIL PROTECTED]
sorry wrong URL, correct one: http://php.net/operators
[2008-07-01 23:07: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
The assignment is executed before the "and" operator, see the
precedence table in the docs, http://php.net/operator
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/45410
--
Edit this bug report at http://bugs.php.net/?id=45410&edit=1
#45478 [Fbk->Opn]: Curl crash within a class
ID: 45478 User updated by: peterphp at mailinator dot com Reported By: peterphp at mailinator dot com -Status: Feedback +Status: Open Bug Type: cURL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: see above Previous Comments: [2008-07-11 17:15:25] peterphp at mailinator dot com My Apologies, I can't understand how I couldn't detect it before, you right, I finaly found that the problem is with CURLOPT_MAXCONNECTS option, try this: Thk U very much, Michael [2008-07-11 15:06:40] [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. I can't reproduce this.. [2008-07-10 14:52:59] peterphp at mailinator dot com Description: Hello, Well i have PHP 5.2.1 an exists the same problem, now i update to 5.2.6 but still exists, so, basicaly apache 2 crash when i try to execute this PHP class. The problem is with $this->handle = curl_init();, if i use $some = curl_init(); work great. Regards, Michael Reproduce code: --- handle = curl_init(); } } ?> Expected result: Assing the curl handle to a class variable. Actual result: -- Sorry, Apache crash, it said that can't read in a memory sector. -- Edit this bug report at http://bugs.php.net/?id=45478&edit=1
#45478 [Com]: Curl crash within a class
ID: 45478 Comment by: peterphp at mailinator dot com Reported By: peterphp at mailinator dot com Status: Feedback Bug Type: cURL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: My Apologies, I can't understand how I couldn't detect it before, you right, I finaly found that the problem is with CURLOPT_MAXCONNECTS option, try this: Thk U very much, Michael Previous Comments: [2008-07-11 15:06:40] [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. I can't reproduce this.. [2008-07-10 14:52:59] peterphp at mailinator dot com Description: Hello, Well i have PHP 5.2.1 an exists the same problem, now i update to 5.2.6 but still exists, so, basicaly apache 2 crash when i try to execute this PHP class. The problem is with $this->handle = curl_init();, if i use $some = curl_init(); work great. Regards, Michael Reproduce code: --- handle = curl_init(); } } ?> Expected result: Assing the curl handle to a class variable. Actual result: -- Sorry, Apache crash, it said that can't read in a memory sector. -- Edit this bug report at http://bugs.php.net/?id=45478&edit=1
#45151 [Opn->Asn]: Crash with URI/file..php (filename contains 2 dots)
ID: 45151 Updated by: [EMAIL PROTECTED] Reported By: giedrius at su dot lt -Status: Open +Status: Assigned Bug Type: CGI related Operating System: Linux 2.6 PHP Version: 5.2.6 -Assigned To: +Assigned To: dmitry New Comment: Dmitry, can you check this out please? Previous Comments: [2008-06-02 19:22:10] giedrius at su dot lt Fixed by replacing ".." to "../" in sapi/cgi/cgi_main.c for directory protection in url [2008-06-02 19:20:35] giedrius at su dot lt Description: PHP SEGfaults when opening file..php PHP(FastCGI SAPI) is invoked via suphp running php-cgi binary manually does NOT trigger segfault For the moment managed to fix this by replacing ".." directory protection to "../" Expected result: parse the file Actual result: -- segfaults -- Edit this bug report at http://bugs.php.net/?id=45151&edit=1
#45148 [Opn->WFx]: Configure should stop when endian is unknown
ID: 45148
Updated by: [EMAIL PROTECTED]
Reported By: ncoesel at dealogic dot nl
-Status: Open
+Status: Wont fix
Bug Type: Compile Failure
Operating System: Linux
PHP Version: 5.2.6
New Comment:
If you're cross-compiling PHP, you're on your own. We don't support nor
try to support cross-compiling in any way. There's enough problems with
"normal" compiling.
Previous Comments:
[2008-07-11 09:29:50] rsxin at hotmail dot com
I have the same error running folling script under mips-64 platform:
$this->time = date('H:i:s');
[2008-06-03 16:42:20] mike at w4g dot org
I just experienced a different result of the same problem on another
big-endian cross compiled platform. A floatval() conversion resulted in
the CPU being pegged until the script hit the 30s timeout. Doing some
ptrace(GETREGS) sampling of the program counter showed the processor in
pow5mult() and s2b(). Floating point constants were interpreted as -0
and floating point calculations would also wedge the CPU.
As a kludge setting 'ac_cv_c_bigendian_php=yes' in the environment
before running configure got it working.
Debugging PHP on a stripped down embedded platform is not fun.
Configuring bombing out would have saved a few hours.
[2008-06-02 11:52:14] ncoesel at dealogic dot nl
Description:
I had the error "Balloc() allocation exceeds list boundary" on a MIPS
big endian platform. It turns out configure cannot test for endiannes
and sets ac_cv_c_bigendian_php to "unknown" which presumably defaults to
little endian. IMHO configure should stop and produce a clear error to
enforce a proper build environment.
Reproduce code:
---
Expected result:
Php info output
Actual result:
--
"Balloc() allocation exceeds list boundary" when trying to print the
date.
--
Edit this bug report at http://bugs.php.net/?id=45148&edit=1
#45133 [Opn->Fbk]: too many open files
ID: 45133
Updated by: [EMAIL PROTECTED]
Reported By: mckinneyseller at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: Scripting Engine problem
Operating System: Centos
PHP Version: 5.2.6
New Comment:
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 ,
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.
Previous Comments:
[2008-05-30 17:10:53] mckinneyseller at yahoo dot com
I did another test. It is only the include that keeps the file handle
open. If I change to be include_once, it does not happen.
Unfortunately the magento ecommerce package uses include and there are
thousands of files that would have to be changed to use include_once
instead -- and it would probably break the ecommerce package.
This is a bug in PHP 5.2.6 and was in PHP 5.2.5 too.
[2008-05-30 16:57:47] mckinneyseller at yahoo dot com
Here is reproducible source code:
';
echo 'this is test1.php';
echo '';
echo 'now include include1.php';
include ('include1.php');
echo '';
require_once('require1.php');
?>
The lsof output is:
httpd 22255 apache 28r REG 0,211 63 81173388
/var/www/vhosts/bubbleyou.com/httpdocs/test2.php
httpd 22255 apache 29r REG 0,211 65 81173382
/var/www/vhosts/bubbleyou.com/httpdocs/include1.php
httpd 22255 apache 30r REG 0,211 169 81173386
/var/www/vhosts/bubbleyou.com/httpdocs/test1.php
httpd 22255 apache 31r REG 0,211 65 81173382
/var/www/vhosts/bubbleyou.com/httpdocs/include1.php
httpd 22255 apache 33r REG 0,211 63 81173388
/var/www/vhosts/bubbleyou.com/httpdocs/test2.php
httpd 22255 apache 34r REG 0,211 63 81173388
/var/www/vhosts/bubbleyou.com/httpdocs/test2.php
httpd 22255 apache 36r REG 0,211 65 81173382
/var/www/vhosts/bubbleyou.com/httpdocs/include1.php
And every time I rerun the above code I get more open file handles for
these same files.
When I run under PHP 5.2.0, I don't get this result.
[2008-05-30 02:09:04] mckinneyseller at yahoo dot com
Description:
'./configure' '--build=i686-redhat-linux-gnu'
'--host=i686-redhat-linux-gnu' '--target=i386-redhat-linux-gnu'
'--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--cache-file=../config.cache'
'--with-libdir=lib' '--with-config-file-path=/etc'
'--with-config-file-scan-dir=/etc/php.d' '--disable-debug' '--with-pic'
'--disable-rpath' '--without-pear' '--with-bz2' '--with-curl'
'--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--enable-gd-native-ttf' '--without-gdbm'
'--with-gettext' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr'
'--with-openssl' '--with-png' '--with-pspell' '--with-expat-dir=/usr'
'--with-pcre-regex' '--with-zlib' '--with-layout=GNU' '--enable-exif'
'--enable-ftp' '--enable-magic-quotes' '--enable-sockets'
'--enable-sysvsem' '--enable-sysvshm' '--enable-sysvmsg'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx'
'--with-kerberos' '--enable-ucd-snmp-hack' '--with-unixODBC=shared,/usr'
'--enable-memory-limit' '--enable-shmop' '--enable-calendar'
'--enable-dbx' '--enable-dio' '--without-mime-magic' '--without-sqlite'
'--with-libxml-dir=/usr' '--with-xml' '--with-apxs2=/usr/sbin/apxs'
'--without-mysql' '--without-gd' '--without-odbc' '--disable-dom'
'--disable-dba' '--without-unixODBC' '--disable-pdo'
'--disable-xmlreader' '--disable-xmlwriter' '--disable-json'
'--with-mcrypt=/usr/local' '--with-mhash=/usr/local'
PHP Version 5.2.6
Apache Version Apache/2.2.3 (CentOS)
Apache API Version 20051115
Reproduce code:
---
All includes leave the .php file open.
I am running the magento e-commerce package.
The includes are standard.
This bug was reported as bug #43105 and the change log says it was
fixed for php 5.2.6 and that is what I am running per above phpinfo.
Expected result:
When I run lsof -u apache | grep magento I do not expect to see any
open .php files.
Actual result:
--
I have 1900 open files. Many are multiple file handles for the same
file. I eve
#45160 [Opn->Fbk]: PHP has encountered an Access Violation at 01B849C7
ID: 45160
Updated by: [EMAIL PROTECTED]
Reported By: php at eklenet dot de
-Status: Open
+Status: Feedback
Bug Type: *General Issues
Operating System: Windows 2003 Server 32bit
PHP Version: 5.2.6
New Comment:
But is that external script running on the same webserver as the one
you're accessing?
Previous Comments:
[2008-07-09 08:37:47] php at eklenet dot de
hello,
i dont think its a internal problem from PHP.
Becouse i need to get my script work, i have made a externel script to
fetch data from the database.
Here is sample code:
--
public function run($sql)
{
echo " A";
$this->CONNECTION['lastsql']= rawurlencode(base64_encode($sql));
if(substr(strtoupper($sql),0,6)=="INSERT" OR
substr(strtoupper($sql),0,6)=="UPDATE")
{
$type="get_field";
$sql = ($this->CONNECTION['lastsql']);
$url =
"http://192.168.224.4/bluesheet/sql.php?type=$type&sql=$sql";;
$data = file_get_contents($url);
}
echo " B";
}
--
so you see here is no database connection.
The Output of the Script is just:
PHP has encountered an Access Violation at 01B849C7 A B A B A B A
As you see it ends with A and not B so there musst be an internal PHP
Problem not related to the Database !
[2008-07-08 07:24:21] php at eklenet dot de
now i have tried odbtp.
what i get is
PHP has encountered an Access Violation at 01B849C7
like with pdo
[2008-07-07 12:42:03] php at eklenet dot de
i have changed to odbc vom pdo_odbc and i got even a similar error:
PHP has encountered an Access Violation at 01CBFC71
mybe they use the same base code ?
[2008-07-07 08:55:45] php at eklenet dot de
Have you now all informations to fix this Problem ?
[2008-06-09 14:25:35] php at eklenet dot de
i have modified my script to work on cli.
here are the dumps:
http://space.eklenet.de/CrashHang_Memory_Report.mht
http://space.eklenet.de/CrashHang_Report.mht
hope that helps !
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/45160
--
Edit this bug report at http://bugs.php.net/?id=45160&edit=1
#45470 [Bgs]: IMAP with Exchange doesn't work
ID: 45470
User updated by: kevin at icscomp dot com
Reported By: kevin at icscomp dot com
Status: Bogus
Bug Type: IMAP related
Operating System: Windows 2003 Server
PHP Version: 5.2.6
New Comment:
Okay, well if the PHP component to check unread messages doesn't work
on Exchange, is their an alternate PHP solution for doing this?
Previous Comments:
[2008-07-11 15:09:37] [EMAIL PROTECTED]
It's just that Exhange + IMAP == not very good idea. It's not any PHP
bug anyway, we just wrap around the UW Imap c-client lib, so you should
complain to the author of it. But consider yourself warned: He'll say
about same what I said above. :)
[2008-07-10 13:22:22] kevin at icscomp dot com
I have tried using this as well:
imap_open("{mailserver:993/imap/ssl}/INBOX",
"domain/user","password",
OP_READONLY, 1) or die("can't connect: ".imap_last_error());
$imap_obj = imap_status($mbox, "{mail:993/imap/ssl}/INBOX",
SA_UNSEEN);
var_dump($imap_obj);
Same result. Any ideas?
[2008-07-10 08:18:38] [EMAIL PROTECTED]
Shouldn't you be using same server name in both imap_open() and
imap_status() ??
[2008-07-09 20:50:56] kevin at icscomp dot com
Description:
When I run the PHP commands to try to retrieve the unread messages
using
the imap_status command, I am finding that no data is being returned.
Additionally, the data that is being returned is random numbers each
time I push the refresh button. I would really like to see this issue
be fixed. Thanks.
My code is below:
Here is the output
Help!
Reproduce code:
---
$mbox = imap_open("{mailserver:993/imap/ssl}",
"domain/user","password",
OP_READONLY, 1) or die("can't connect: ".imap_last_error());
$imap_obj = imap_status($mbox, "{mail:993/imap/ssl}/INBOX",
SA_UNSEEN);
var_dump($imap_obj);
Expected result:
I assume something like:
object(stdClass)#19 (1) { ["Unread"]=> int(5) }
Actual result:
--
Output 1:
object(stdClass)#19 (1) { ["flags"]=> int(0) }
Output 2:
object(stdClass)#19 (2) { ["flags"]=> int(26571976) ["uidnext"]=>
int(26649488) }
back and forth no other data is listed.
--
Edit this bug report at http://bugs.php.net/?id=45470&edit=1
#45176 [Opn->Asn]: Create image from ttf file failed
ID: 45176 Updated by: [EMAIL PROTECTED] Reported By: heyond at yahoo dot com dot cn -Status: Open +Status: Assigned Bug Type: GD related Operating System: windows 2003 PHP Version: 5.2.6 Assigned To: pajoye Previous Comments: [2008-06-05 06:45:11] heyond at yahoo dot com dot cn The completed script is: http://www.guomo.com/data/fonts/1.ttf This file '1.ttf' is normal $fontfile = './data/fonts/174.ttf';//http://www.guomo.com/data/fonts/174.ttf This file '174.ttf' is abnormal $width = 30 $height = 40; $fontsize = 20; $x = 0; $y = $fontsize + 10; $im = imagecreate($wordnum * $width, $height); $bgcolor = imagecolorallocate($im, hexdec(substr(BG1, 0, 2)), hexdec(substr(BG1, 2, 2)), hexdec(substr(BG1, 4, 2))); $fgcolor = imagecolorallocate($im, 0, 0, 0); imagefill($im, 0, 0, $bgcolor); imagettftext($im, $fontsize, 0, $x, $y, $fgcolor, $fontfile, $word); imagejpeg($im); imagedestroy($im); exit; ?> [2008-06-05 06:38:14] heyond at yahoo dot com dot cn http://www.guomo.com/data/fonts/174.ttf [2008-06-04 16:23:40] [EMAIL PROTECTED] "Warning: imagettftext() [function.imagettftext]: Unable to find a CharMap that I can handle in D:\www\guomo.com\ttf.php on line 33" Is a pretty clear error message. Please provide a link to the font you are using a complete script to reproduce your problem. [2008-06-04 14:24:08] heyond at yahoo dot com dot cn Description: I try to create a font image from ttf file, but I encounted a error : Warning: imagettftext() [function.imagettftext]: Unable to find a CharMap that I can handle in D:\www\mvc\ttf2.php on line 49 only few ttf file like this, I guess the freetypes version too lower. Reproduce code: --- imagettftext($im, $fontsize, 0, $x, $y, $fgcolor, $fontfile, 'abc'); Expected result: a binary image. Actual result: -- Warning: imagettftext() [function.imagettftext]: Unable to find a CharMap that I can handle in D:\www\guomo.com\ttf.php on line 33 ÿ?JFIFÿ>CREATOR: gd-jpeg v1.0 (using IJG JPEG v62), default quality ÿC $.' ",# (7),01444 '9=82<.342ÿC 2! !22ÿ(J"ÿ ÿ?}!1AQa"q2?#B±ÁRÑð$3br? %&'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚáâãäåæçèéêñòóôõö÷øù? ÿ?w!1AQaq"2?B¡±Á #3R?br?$4??&'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz ¢£¤¥¦§¨©ª²³´µ¶·¸¹ºÂÃÄÅÆÇÈÉÊÒÓÔÕÖ×ØÙÚâãäåæçèéêòóôõö÷øùúÿ ?õJ(¢¸Íÿ -- Edit this bug report at http://bugs.php.net/?id=45176&edit=1
#45178 [Opn->Ctl]: garbage collector and cyclic references
ID: 45178
Updated by: [EMAIL PROTECTED]
Reported By: thomas dot jarosch at intra2net dot com
-Status: Open
+Status: Critical
Bug Type: Reproducible crash
Operating System: Linux
PHP Version: 5.3CVS-2008-06-04 (snap)
Previous Comments:
[2008-06-05 09:13:20] thomas dot jarosch at intra2net dot com
Actually, the reproduce code from #33595 also leaks memory.
The statement about Horde is not 100% correct as only some singleton
functions are affected. I mixed it up with another reference problem
I fixed a while ago. Nontheless memory is leaked :-)
[2008-06-04 16:57:45] thomas dot jarosch at intra2net dot com
Description:
Hello together,
I'm currently trying to find a heap corruption while using Horde and
noticed a rather odd behavior. The supplied code is the standard way
Horde does it singletons. We always used the syntax of "$object =
&new class" to make it work with PHP4 and PHP5.
If I change that to "$object = new class", everything works as
expected. I've found bug #32845 and noticed what we are doing seems
wrong, so Horde needs fixing.
The problem gets worse if the class object contains a variable of the
type "PEAR_Error", which contains cyclic references. Not only does
the constructor get called every time, the object leaks memory like
hell, even with PHP 5.3. I've searched through the bugtracker and
thought the garbage collector now handles cyclic references,
but maybe this is a side-effect of something else going wrong.
Is the memory consumption by design?
Thanks in advance for any comment,
Thomas
Reproduce code:
---
error = PEAR::raiseError("error");
echo "Memory usage: " . memory_get_usage() . "\n";
}
}
for (;;) {
$a = Horde_History::singleton();
}
Expected result:
Constant memory usage.
Actual result:
--
Increasing memory usage.
--
Edit this bug report at http://bugs.php.net/?id=45178&edit=1
#45346 [Opn->Fbk]: object to array cast indexing error
ID: 45346
Updated by: [EMAIL PROTECTED]
Reported By: xavier dot pinard at laposte dot net
-Status: Open
+Status: Feedback
Bug Type: Arrays related
Operating System: WIN XP
PHP Version: 5.2.6
New Comment:
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 ,
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.
Previous Comments:
[2008-06-24 10:30:06] xavier dot pinard at laposte dot net
Description:
object numeric's name properties are cast in string array's index.
created indexes becomes not accessible.
Reproduce code:
---
#5.2.7.-DEV on 2007-06-24
# WANTED => cast object to array and access first element with 0 index
#RESULT => the array key with the index '0' is nor accessible by 0 or
"0", uncool ...
#¿PROBLEM? => Shouldn't the array key needs to be numeric instead of a
string after object to array cast ?
$stdclass = neW StdcLaSs() ;
$stdclass->{0} = 'index0' ;
$stdclassElement = (arRaY)$stdclass ;
$var = array_keys( $stdclassElement ) ;
$key = $var [ 0 ] ;
Echo
'$stdclassElement[ $key ] :: ' , $stdclassElement[ $key ] ,
'$stdclassElement[0] :: ' , $stdclassElement[ 0 ] ,
'$stdclassElement["0"] :: ', $stdclassElement['0']
;
Expected result:
acess neither to array index '0' by [0] or ["0"]
Actual result:
--
the index is not accessible
--
Edit this bug report at http://bugs.php.net/?id=45346&edit=1
#45214 [Opn->WFx]: __autoload tries to load callback'ed self and parent (close to #37138; no dupe)
ID: 45214
Updated by: [EMAIL PROTECTED]
Reported By: webmaster at eiscp dot de
-Status: Open
+Status: Wont fix
Bug Type: Class/Object related
Operating System: Windows XP Professional SP 3
PHP Version: 5.2.6
New Comment:
Fixed in HEAD/5.3, wont fix elsewhere.
Previous Comments:
[2008-06-09 13:34:35] webmaster at eiscp dot de
Description:
Like #37138 __autoload tries to load callback'ed self and parent PHP
tries to __autoload if callcack is used with self or parent in method
name. Please note that this is not a dupe!
Reproduce code:
---
function __autoload($class) {
echo __METHOD__, '(', $class, ')', PHP_EOL;
}
class A {
function X() {
echo __METHOD__, PHP_EOL;
}
function Y() {
echo __METHOD__, PHP_EOL;
call_user_func(array($this, 'self::X'));
}
}
class B extends A {
function X() {
echo __METHOD__, PHP_EOL;
call_user_func(array($this, 'parent::X'));
}
function Y() {
echo __METHOD__, PHP_EOL;
call_user_func(array($this, 'parent::Y'));
}
}
// Test
$a = new A();
echo '--- Case 1 ---', PHP_EOL;
$a->X();
echo '--- Case 2 ---', PHP_EOL;
$a->Y();
$b = new B();
echo '--- Case 3 ---', PHP_EOL;
$b->X();
echo '--- Case 4 ---', PHP_EOL;
$b->Y();
Expected result:
--- Case 1 ---
A::X
--- Case 2 ---
A::Y
A::X
--- Case 3 ---
B::X
A::X
--- Case 4 ---
B::Y
A::Y
A::X
Actual result:
--
--- Case 1 ---
A::X
--- Case 2 ---
A::Y
__autoload(self)
A::X
--- Case 3 ---
B::X
__autoload(parent)
A::X
--- Case 4 ---
B::Y
__autoload(parent)
A::Y
__autoload(self)
A::X
--
Edit this bug report at http://bugs.php.net/?id=45214&edit=1
#45477 [Bgs]: ldap_mod_del() fails to remove attribute
ID: 45477
User updated by: alexis dot robert at gmail dot com
Reported By: alexis dot robert at gmail dot com
Status: Bogus
Bug Type: LDAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
I don't have any access to the LDAP server. I'll try to request them on
Tuesday (if I had them, it would be the first thing I would check).
Previous Comments:
[2008-07-11 15:17:02] [EMAIL PROTECTED]
Works -> Bogus.
[2008-07-11 15:16:34] [EMAIL PROTECTED]
Well, should you then check in the server logs WHY it doesn't want to
perform?
[2008-07-11 15:16:29] alexis dot robert at gmail dot com
Hmmm ... you are right. Sorry, it works like this. I thought I have
tested this case.
Now I have a LDAP issue :)
Apologies.
[2008-07-11 15:15:24] alexis dot robert at gmail dot com
It says :
REMOVE :
Warning: ldap_mod_del() [function.ldap-mod-del]: Modify: Server is
unwilling to perform in C:\wamp\www\bug.php on line 11
[2008-07-11 15:01:04] [EMAIL PROTECTED]
Have you tried this:
ldap_mod_del($cnx,$dn,array('userPassword' => array()));
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/45477
--
Edit this bug report at http://bugs.php.net/?id=45477&edit=1
#45380 [Opn]: Access multiple sessions in a request
ID: 45380
Updated by: [EMAIL PROTECTED]
Reported By: jerome dot auge at anakeen dot com
Status: Open
Bug Type: Session related
Operating System: Linux
PHP Version: 5.2.6
New Comment:
See also bug #45270
Previous Comments:
[2008-06-27 17:25:36] jerome dot auge at anakeen dot com
Description:
I want to access two distinct sessions content, but I only get access
to
the first session, and the second session_name/session_start does not
change the content of the $_SESSION variable which remains the same as
the first one.
After investigation, when switching session with a call to
session_name('another_session')+session_start(), the session ID from
the
first session_start() is re-used, and the sess ID from the new session
name 'another_session' is not used.
Reproduce code:
---
1) Call 'set_sess1.php' to set a session named 'sess1':
2) Call 'set_sess2.php' to set a session named 'sess2':
3) Try to access both session variables in 'get_sess.php':
$v) {
print "_COOKIE[$k] = $v\n";
}
print "sess1 = $sess1\n";
print "sess2 = $sess2\n";
?>
Expected result:
In 'get_sess.php', I expect to get access to the content of the 'sess2'
session by issuing a new session_name('sess2')+session_start(), but the
content of _SESSION remains the one from 'sess1'.
Expected output from 'get_sess.php':
_COOKIE[sess1] = n0f57lap2oabeqvfc6t6c0ap60
_COOKIE[sess2] = b4s2sr976f4qrbkimfh0i6kqm0
sess1 = session1:n0f57lap2oabeqvfc6t6c0ap60
sess2 = session2:b4s2sr976f4qrbkimfh0i6kqm0
Actual result:
--
Actuel output from 'get_sess.php':
_COOKIE[sess1] = 2ot2t22ccq0t9de2edhgcrh4h4
_COOKIE[sess2] = rt8jr3e6esvmp88id0e4o05091
sess1 = session1:2ot2t22ccq0t9de2edhgcrh4h4
sess2 =
The script also issue a "Set-Cookie: sess2=", and I
end up with the cookies 'sess1' and 'sess2' having the same ID.
I got around it by setting the session ID manually with
session_id($_COOKIE['new_session']), after calling
session_name('new_session') and before session_start()... but I was
expecting PHP to handle this automatically...
So here is a proposal patch to de-allocate PS(id) when calling
session_write_close(), in order to force session_start() to lookup the
session ID from the session name:
--8<--
--- php-5.2.6.orig/ext/session/session.c2008-04-29
16:42:38.0 +0200
+++ php-5.2.6/ext/session/session.c 2008-06-27 18:29:05.0
+0200
@@ -933,6 +933,11 @@
if (PS(mod_data))
PS(mod)->s_close(&PS(mod_data) TSRMLS_CC);
+
+ if (PS(id)) {
+ efree(PS(id));
+ PS(id) = NULL;
+ }
}
static char *month_names[] = {
-->8--
--
Edit this bug report at http://bugs.php.net/?id=45380&edit=1
#45270 [Opn->Bgs]: session_start() incorrectly tries to send a cookie
ID: 45270 Updated by: [EMAIL PROTECTED] Reported By: vesselin dot atanasov at gmail dot com -Status: Open +Status: Bogus Bug Type: Session related Operating System: Fedora Core 8 PHP Version: 5.2.6 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. See bug #45380 which has a bit more info. Previous Comments: [2008-07-08 15:16:45] vesselin dot atanasov at gmail dot com Hello Jani, Once a PHP process/thread starts a session, it acquires an exclusive lock of the session variables. This means that a different PHP process/thread cannot start a session while the first process is working. This turns out to be a problem for websites that provide some kind of API. Let's assume that our API has two kinds of calls: A) Ones that take more or less long time, e.g. 5-10 minutes. B) Ones that take a sort time, e.g. 1-2 seconds. So here is what a long web API call should look like: 1. Start the session (acquire an exclusive lock of the session data). 2. Read some session variables. 3. Close the session (release the exclusive lock). 4. Do some long processing for 5-10 minutes. 5. Write the processing result to standard output, effectively sending it to the client that called the API. 6. Start the session again (acquire the exclusive lock again). 7. Write some state variables back to the session data. 8. Terminate the PHP script. So from this sequence it is obvious that in step 4 many short API calls can be performed while the long processing takes place. If we cannot stop the session, releasing the lock and then start it again, we need to hold the lock for 5-10 minutes thus serializing access to the API, which is pretty inefficient. [2008-07-08 13:30:31] [EMAIL PROTECTED] Why would you stop and start a session in same request? It's by design like this.. [2008-06-14 14:05:09] vesselin dot atanasov at gmail dot com Description: session_start() incorrectly tries to send a cookie even when it has already been sent. This causes problems with sessions that are closed with session_write_close() some output has been sent and then the session is re-opened with session_start() The second time when session_start() is called it should avoid sending the cookie and cache headers, since they have already been sent by the first call to session_start(). It seems that the second time session_start() tries to send the same cookie value as the first time, so it should be possible to avoid sending that cookie a second time. Reproduce code: --- Expected result: No output at all. Actual result: -- Test Warning: session_start() [function.session-start]: Cannot send session cookie - headers already sent by (output started at /var/medical/htdocs/try.php:4) in /var/medical/htdocs/try.php on line 5 Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /var/medical/htdocs/try.php:4) in /var/medical/htdocs/try.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=45270&edit=1
#45378 [Opn->Bgs]: Returning weird overwritten data in array
ID: 45378 Updated by: [EMAIL PROTECTED] Reported By: pwd_manager at hotmail dot com -Status: Open +Status: Bogus Bug Type: Arrays related Operating System: Linux PHP Version: 5.2.6 New Comment: When you can provide a proper reproducing script, come back and report it. Previous Comments: [2008-06-27 15:33:13] pwd_manager at hotmail dot com Description: Php throwing weird data into an array. Reproduce code: --- The code is too large to post here. Since I currently do not have a hosting server and I am working on a clients website, I have no way of hosting the code. You can email me ([EMAIL PROTECTED]) and I can email you the test code. Expected result: The following code is supposed to loop through the massive array set the object type for each field. If you look at the original array, you will notice that all the types are clearly defined. There is no weird type called "Ant". However, if you look at the bottom of the test code, somewhere, the code returns a weird type of "Ant". There is no where that this information should be cropping up in the code. After hours of exhaustive debugging, I have learned that the error is reproduce-able on multiple OS's, that it seems to occur in the same place in this massive array of arrays, and that I am pretty sure it isn't a bug in my code. Actual result: -- See expected results. -- Edit this bug report at http://bugs.php.net/?id=45378&edit=1
#45384 [Opn->Ctl]: parse_ini_file will result in parse error with no trailing newline
ID: 45384
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Critical
Bug Type: Filesystem function related
Operating System: Ubuntu
PHP Version: 5.3CVS-2008-06-28 (CVS)
Previous Comments:
[2008-06-29 00:50:26] [EMAIL PROTECTED]
$ echo -n "foo.bar = baz " > test.ini
20:46 [EMAIL PROTECTED]:~
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'
array(1) {
["foo.bar"]=>
string(4) "baz "
}
so the answer is, yes, a trailing space does not cause the error...if
this needs to be marked as a duplicate, whatever it takes to get this
working the same as php<=5.2
[2008-06-28 11:22:11] [EMAIL PROTECTED]
This is probably also related to the re2c/YYFILL() scanner issues I
described in Bug #45372.
I assume it's because a variable length rule is matching ("baz" in your
example) when it hits EOF and YYFILL() causes a return/abort. This
(unexpected $end) is more likely to happen with ini parsing, etc. where
it doesn't usually happen with VALID code in a PHP script because the
last thing matched in a typical file is with a fixed length rule (e.g.
"?>" or ";"), and these things only happen with variable length matches
as I explained in the other bug, though they shouldn't with working
scanner code, IMO.
BTW, does putting a space or something other than a newline after baz
allow it to work? Any character that's not allowed in the rule matching
baz should also make it "magically" work. :-)
[2008-06-28 03:05:49] [EMAIL PROTECTED]
Description:
an ini file with no trailing newline will result in "Parse error",
php5.3 only, 5.2 parses the file fine
Reproduce code:
---
$ echo -n "foo.bar = baz" > test.ini
$ /opt/php53/bin/php -r 'var_dump(parse_ini_file("test.ini"));'
Expected result:
array(1) {
["foo.bar"]=>
string(3) "baz"
}
Actual result:
--
Warning: syntax error, unexpected $end in test.ini on line 1
in Command line code on line 1
Call Stack:
0.0003 312916 1. {main}() Command line code:0
0.0128 312936 2. parse_ini_file() Command line code:1
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=45384&edit=1
#45441 [Opn->Ver]: count_chars() crashes if both arguments are the same reference
ID: 45441 Updated by: [EMAIL PROTECTED] Reported By: victor dot stinner at haypocalc dot com -Status: Open +Status: Verified Bug Type: Reproducible crash -Operating System: Linux (Ubuntu Gutsy) +Operating System: * PHP Version: 5.2CVS-2008-07-06 (snap) Previous Comments: [2008-07-06 23:30:21] victor dot stinner at haypocalc dot com Description: count_chars() function converts the second argument ($mode) using convert_to_long_ex(). If $input and $mode are both a reference to the same variable, PHP crashs with a segfault. Reproduce code: --- -- Edit this bug report at http://bugs.php.net/?id=45441&edit=1
#45448 [Fbk]: PHP Cuts off documents after some point
ID: 45448 Updated by: [EMAIL PROTECTED] Reported By: jowie dot 1337+phpnet at gmail dot com Status: Feedback Bug Type: Apache2 related Operating System: Windows XP Service Pack 1 PHP Version: 5.2.6 New Comment: Also: What other filters/modules have you enabled in your apache config? Previous Comments: [2008-07-11 15:33:15] [EMAIL PROTECTED] You're actually using PHP 4..? The support for PHP 4 has ended, so if you could actually try with PHP 5 first.. [2008-07-08 16:01:35] jowie dot 1337+phpnet at gmail dot com This is a snippet of my httpd.conf related to php, this is the same as I used to test the scenario's in my opening post: AddType application/x-httpd-php .php LoadModule php4_module "C:/Program Files/PHP 4/php4apache2.dll" PHPIniDir "C:/Program Files/PHP 4/" #PHPIniDir "C:/Program Files/PHP 5/" #LoadModule php5_module "C:/Program Files/PHP 5/php5apache2_2.dll" [2008-07-08 13:13:04] [EMAIL PROTECTED] Which apache2 SAPI are you using? [2008-07-07 22:55:19] jowie dot 1337+phpnet at gmail dot com Description: All my php documents are cut off after exactly 8800 bytes. The content does not matter, it even happens on documents that have no php code at all. There are no errors (E_ALL) from php, nor from apache. Renaming .php to .txt shows the whole file in my browser. This also happends with an unmodified php.ini (php.ini-recommended, besides extension_dir) I have tried the following scenario's (restarted apache for each try): + Apache 2.2.9 PHP 4.4.8 as Module (bug appears) + Apache 2.2.9 PHP 5.2.6 as Module (bug appears) + Apache 2.2.9 PHP 5.2.6 under CGI (bug appears) + Apache 2.2.9 PHP 4.4.8 implicit_flush on (NO BUG) + Apache 2.2.9 PHP 5.2.6 Without ANY Extensions (bug appears) + Apache 2.2.9 PHP 5.2.6 implicit_flush on (bug appears) + Apache 2.2.9 PHP 5.2.6 output_buffering off (bug appears) + Apache 2.2.9 PHP 4.4.8 Super high memory_limit (bug appears) + Apache 2.2.9 PHP 5.2.6 Super high memory_limit (bug appears) As you can see, for some reason if I turn implicit_flush on in php 4, the bug disappears, i can see the whole document(s). I have seen a different site where this happened. However it did not appear on every document and at various cut-off lengths. This may be a different bug perhaps unrelated to php but it is worth mentioning. I only have the following limited info about that server: OS: Some Linux Flavor; Apache 2.0.54 (Fedora); PHP 5.0.4 as a module Reproduce code: --- A text document containing more then 8800 characters saved as test.php Expected result: The whole text document Actual result: -- A text document that is cut off at 8800 characters -- Edit this bug report at http://bugs.php.net/?id=45448&edit=1
#45448 [Opn->Fbk]: PHP Cuts off documents after some point
ID: 45448 Updated by: [EMAIL PROTECTED] Reported By: jowie dot 1337+phpnet at gmail dot com -Status: Open +Status: Feedback Bug Type: Apache2 related Operating System: Windows XP Service Pack 1 PHP Version: 5.2.6 New Comment: You're actually using PHP 4..? The support for PHP 4 has ended, so if you could actually try with PHP 5 first.. Previous Comments: [2008-07-08 16:01:35] jowie dot 1337+phpnet at gmail dot com This is a snippet of my httpd.conf related to php, this is the same as I used to test the scenario's in my opening post: AddType application/x-httpd-php .php LoadModule php4_module "C:/Program Files/PHP 4/php4apache2.dll" PHPIniDir "C:/Program Files/PHP 4/" #PHPIniDir "C:/Program Files/PHP 5/" #LoadModule php5_module "C:/Program Files/PHP 5/php5apache2_2.dll" [2008-07-08 13:13:04] [EMAIL PROTECTED] Which apache2 SAPI are you using? [2008-07-07 22:55:19] jowie dot 1337+phpnet at gmail dot com Description: All my php documents are cut off after exactly 8800 bytes. The content does not matter, it even happens on documents that have no php code at all. There are no errors (E_ALL) from php, nor from apache. Renaming .php to .txt shows the whole file in my browser. This also happends with an unmodified php.ini (php.ini-recommended, besides extension_dir) I have tried the following scenario's (restarted apache for each try): + Apache 2.2.9 PHP 4.4.8 as Module (bug appears) + Apache 2.2.9 PHP 5.2.6 as Module (bug appears) + Apache 2.2.9 PHP 5.2.6 under CGI (bug appears) + Apache 2.2.9 PHP 4.4.8 implicit_flush on (NO BUG) + Apache 2.2.9 PHP 5.2.6 Without ANY Extensions (bug appears) + Apache 2.2.9 PHP 5.2.6 implicit_flush on (bug appears) + Apache 2.2.9 PHP 5.2.6 output_buffering off (bug appears) + Apache 2.2.9 PHP 4.4.8 Super high memory_limit (bug appears) + Apache 2.2.9 PHP 5.2.6 Super high memory_limit (bug appears) As you can see, for some reason if I turn implicit_flush on in php 4, the bug disappears, i can see the whole document(s). I have seen a different site where this happened. However it did not appear on every document and at various cut-off lengths. This may be a different bug perhaps unrelated to php but it is worth mentioning. I only have the following limited info about that server: OS: Some Linux Flavor; Apache 2.0.54 (Fedora); PHP 5.0.4 as a module Reproduce code: --- A text document containing more then 8800 characters saved as test.php Expected result: The whole text document Actual result: -- A text document that is cut off at 8800 characters -- Edit this bug report at http://bugs.php.net/?id=45448&edit=1
#45487 [NEW]: imap_getsubscribed clobbers attributes
From: sblackstone at gmail dot com
Operating system: OSX Leopard
PHP version: 5.2.6
PHP Bug Type: *General Issues
Bug description: imap_getsubscribed clobbers attributes
Description:
The documentation for imap_getsubscribed notes the following:
Identical to imap_getmailboxes(), except that it only returns mailboxes
that the user is subscribed to.
However getsubscribed clobbers the attributes value and returns 0.
Reproduce code:
---
Expected result:
stdClass Object
(
[name] => {localhost:143/notls}SOMEMAILBOX
[attributes] => 64
[delimiter] => .
)
Actual result:
--
stdClass Object
(
[name] => {localhost:143/notls}SOMEMAILBOX
[attributes] => 0
[delimiter] => .
)
--
Edit bug report at http://bugs.php.net/?id=45487&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45487&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45487&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45487&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45487&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45487&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45487&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45487&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45487&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45487&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45487&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45487&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45487&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45487&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45487&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45487&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45487&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45487&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45487&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45487&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45487&r=mysqlcfg
#45464 [Fbk]: PHP Crashs when sending header('Content-type: application/rss+xml');
ID: 45464
Updated by: [EMAIL PROTECTED]
Reported By: ast dot markus at gmx dot net
Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows Vista x64
PHP Version: 5.3CVS-2008-07-09 (snap)
New Comment:
Also, I can not reproduce this with PHP 5.2.6, so is this specific for
PHP 5.3.0-dev ?
Previous Comments:
[2008-07-11 15:18:20] [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.
[2008-07-09 11:16:17] ast dot markus at gmx dot net
By the way:
header('Content-type: application/xml');
for example works without any problem
[2008-07-09 11:12:38] ast dot markus at gmx dot net
Description:
Sending this header:
header('Content-type: application/rss+xml');
will cause PHP to crash (on IIS7 with FastCgi).
Windows Log says:
Fehlerhafte Anwendung php-cgi.exe, Version 5.3.0.0, Zeitstempel
0x487474e8, fehlerhaftes Modul php-cgi.exe, Version 5.3.0.0, Zeitstempel
0x487474e8, Ausnahmecode 0xc005, Fehleroffset 0x55d4, Prozess-ID
0x11e0, Anwendungsstartzeit 01c8e1b3e4ba9d90.
or
Fehlerhafte Anwendung php-cgi.exe, Version 5.3.0.0, Zeitstempel
0x487474e8, fehlerhaftes Modul php5ts.dll, Version 5.3.0.0, Zeitstempel
0x487474d6, Ausnahmecode 0xc005, Fehleroffset 0xbae6, Prozess-ID
0x12d0, Anwendungsstartzeit 01c8e1b43b3e5210.
Reproduce code:
---
';
?>
Expected result:
IIS7 Error:
HTTP-Fehler 500.0 - Internal Server Error
Modul: FastCgiModule
Benachrichtigung: ExecuteRequestHandler
Handler PHP via FastCgi
Fehlercode: 0x800703e3
--
Edit this bug report at http://bugs.php.net/?id=45464&edit=1
#45464 [Opn->Fbk]: PHP Crashs when sending header('Content-type: application/rss+xml');
ID: 45464
Updated by: [EMAIL PROTECTED]
Reported By: ast dot markus at gmx dot net
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Windows Vista x64
PHP Version: 5.3CVS-2008-07-09 (snap)
New Comment:
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.
Previous Comments:
[2008-07-09 11:16:17] ast dot markus at gmx dot net
By the way:
header('Content-type: application/xml');
for example works without any problem
[2008-07-09 11:12:38] ast dot markus at gmx dot net
Description:
Sending this header:
header('Content-type: application/rss+xml');
will cause PHP to crash (on IIS7 with FastCgi).
Windows Log says:
Fehlerhafte Anwendung php-cgi.exe, Version 5.3.0.0, Zeitstempel
0x487474e8, fehlerhaftes Modul php-cgi.exe, Version 5.3.0.0, Zeitstempel
0x487474e8, Ausnahmecode 0xc005, Fehleroffset 0x55d4, Prozess-ID
0x11e0, Anwendungsstartzeit 01c8e1b3e4ba9d90.
or
Fehlerhafte Anwendung php-cgi.exe, Version 5.3.0.0, Zeitstempel
0x487474e8, fehlerhaftes Modul php5ts.dll, Version 5.3.0.0, Zeitstempel
0x487474d6, Ausnahmecode 0xc005, Fehleroffset 0xbae6, Prozess-ID
0x12d0, Anwendungsstartzeit 01c8e1b43b3e5210.
Reproduce code:
---
';
?>
Expected result:
IIS7 Error:
HTTP-Fehler 500.0 - Internal Server Error
Modul: FastCgiModule
Benachrichtigung: ExecuteRequestHandler
Handler PHP via FastCgi
Fehlercode: 0x800703e3
--
Edit this bug report at http://bugs.php.net/?id=45464&edit=1
#45477 [Fbk->Bgs]: ldap.so fails to remove attributes when masked by the LDAP server
ID: 45477
Updated by: [EMAIL PROTECTED]
Reported By: alexis dot robert at gmail dot com
-Status: Feedback
+Status: Bogus
Bug Type: LDAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
Works -> Bogus.
Previous Comments:
[2008-07-11 15:16:34] [EMAIL PROTECTED]
Well, should you then check in the server logs WHY it doesn't want to
perform?
[2008-07-11 15:16:29] alexis dot robert at gmail dot com
Hmmm ... you are right. Sorry, it works like this. I thought I have
tested this case.
Now I have a LDAP issue :)
Apologies.
[2008-07-11 15:15:24] alexis dot robert at gmail dot com
It says :
REMOVE :
Warning: ldap_mod_del() [function.ldap-mod-del]: Modify: Server is
unwilling to perform in C:\wamp\www\bug.php on line 11
[2008-07-11 15:01:04] [EMAIL PROTECTED]
Have you tried this:
ldap_mod_del($cnx,$dn,array('userPassword' => array()));
[2008-07-10 14:14:11] alexis dot robert at gmail dot com
Description:
Hi,
I currently work at Hachette-Livre (in Paris, France), and I rewrite
their authentification system. Their previous version didn't use
php_ldap to change password because it was said that the developer had
given up saying that it's impossible to do it with PHP (they used a
handwritten Java software called by PHP to change their password).
The fact is, that it's really impossible ! (or I'm really bad) In fact,
NDS (Novell Directory Server) masks the userPassword attribute if I
query it, but the doc says that users can delete/add it.
So, because this field doesn't appear in the LDAP query,
ldap_mod_delete fails, saying "Unknown attribute in the data", which is
pretty logic.
If I read the sourcecode, this issue doesn't seem to come from libldap,
but in the PHP module (approx. line 1428). I've tried to do a patch but
I'm not very keen on everything around LDAP (this is hmm the second time
I cross LDAP on my way -- btw I'm 18, that explains :D ), and I don't
know if it works (and so I have a server problem *with* a PHP problem)
or not.
I think that the main part is guessing ldap_mods[i]->mod_type from the
attribute name if we delete an attribute, but I've said that I'm not
very an LDAP expert.
If you want any further informations, don't mind asking me :)
Reproduce code:
---
ldap://ldap.example.org";);
$dn = "cn=user,ou=paris,o=example";
$pass = "php-developers-eat-kitties-and-bears";
ldap_bind($cnx,$dn,$pass);
print "REMOVE : ";
if (ldap_mod_del($cnx,$dn,array("userPassword"))) {
print "ADD : ";
ldap_mod_add($cnx, $dn, array("userPassword" =>
"php-developers-dont-eat-kitties-and-bears"));
}
?>
Expected result:
My coffee and no more "Unknown attribute in the data" (or other
annoying errors which make you want to hit your computer).
Actual result:
--
[EMAIL PROTECTED]:~$ php bug.php
REMOVE :
Warning: ldap_mod_del(): Unknown attribute in the data in
/home/alexis/bug.php on line 11
--
Edit this bug report at http://bugs.php.net/?id=45477&edit=1
#45477 [Opn->Fbk]: ldap.so fails to remove attributes when masked by the LDAP server
ID: 45477
Updated by: [EMAIL PROTECTED]
Reported By: alexis dot robert at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
Well, should you then check in the server logs WHY it doesn't want to
perform?
Previous Comments:
[2008-07-11 15:16:29] alexis dot robert at gmail dot com
Hmmm ... you are right. Sorry, it works like this. I thought I have
tested this case.
Now I have a LDAP issue :)
Apologies.
[2008-07-11 15:15:24] alexis dot robert at gmail dot com
It says :
REMOVE :
Warning: ldap_mod_del() [function.ldap-mod-del]: Modify: Server is
unwilling to perform in C:\wamp\www\bug.php on line 11
[2008-07-11 15:01:04] [EMAIL PROTECTED]
Have you tried this:
ldap_mod_del($cnx,$dn,array('userPassword' => array()));
[2008-07-10 14:14:11] alexis dot robert at gmail dot com
Description:
Hi,
I currently work at Hachette-Livre (in Paris, France), and I rewrite
their authentification system. Their previous version didn't use
php_ldap to change password because it was said that the developer had
given up saying that it's impossible to do it with PHP (they used a
handwritten Java software called by PHP to change their password).
The fact is, that it's really impossible ! (or I'm really bad) In fact,
NDS (Novell Directory Server) masks the userPassword attribute if I
query it, but the doc says that users can delete/add it.
So, because this field doesn't appear in the LDAP query,
ldap_mod_delete fails, saying "Unknown attribute in the data", which is
pretty logic.
If I read the sourcecode, this issue doesn't seem to come from libldap,
but in the PHP module (approx. line 1428). I've tried to do a patch but
I'm not very keen on everything around LDAP (this is hmm the second time
I cross LDAP on my way -- btw I'm 18, that explains :D ), and I don't
know if it works (and so I have a server problem *with* a PHP problem)
or not.
I think that the main part is guessing ldap_mods[i]->mod_type from the
attribute name if we delete an attribute, but I've said that I'm not
very an LDAP expert.
If you want any further informations, don't mind asking me :)
Reproduce code:
---
ldap://ldap.example.org";);
$dn = "cn=user,ou=paris,o=example";
$pass = "php-developers-eat-kitties-and-bears";
ldap_bind($cnx,$dn,$pass);
print "REMOVE : ";
if (ldap_mod_del($cnx,$dn,array("userPassword"))) {
print "ADD : ";
ldap_mod_add($cnx, $dn, array("userPassword" =>
"php-developers-dont-eat-kitties-and-bears"));
}
?>
Expected result:
My coffee and no more "Unknown attribute in the data" (or other
annoying errors which make you want to hit your computer).
Actual result:
--
[EMAIL PROTECTED]:~$ php bug.php
REMOVE :
Warning: ldap_mod_del(): Unknown attribute in the data in
/home/alexis/bug.php on line 11
--
Edit this bug report at http://bugs.php.net/?id=45477&edit=1
#45477 [Opn]: ldap.so fails to remove attributes when masked by the LDAP server
ID: 45477
User updated by: alexis dot robert at gmail dot com
Reported By: alexis dot robert at gmail dot com
Status: Open
Bug Type: LDAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
Hmmm ... you are right. Sorry, it works like this. I thought I have
tested this case.
Now I have a LDAP issue :)
Apologies.
Previous Comments:
[2008-07-11 15:15:24] alexis dot robert at gmail dot com
It says :
REMOVE :
Warning: ldap_mod_del() [function.ldap-mod-del]: Modify: Server is
unwilling to perform in C:\wamp\www\bug.php on line 11
[2008-07-11 15:01:04] [EMAIL PROTECTED]
Have you tried this:
ldap_mod_del($cnx,$dn,array('userPassword' => array()));
[2008-07-10 14:14:11] alexis dot robert at gmail dot com
Description:
Hi,
I currently work at Hachette-Livre (in Paris, France), and I rewrite
their authentification system. Their previous version didn't use
php_ldap to change password because it was said that the developer had
given up saying that it's impossible to do it with PHP (they used a
handwritten Java software called by PHP to change their password).
The fact is, that it's really impossible ! (or I'm really bad) In fact,
NDS (Novell Directory Server) masks the userPassword attribute if I
query it, but the doc says that users can delete/add it.
So, because this field doesn't appear in the LDAP query,
ldap_mod_delete fails, saying "Unknown attribute in the data", which is
pretty logic.
If I read the sourcecode, this issue doesn't seem to come from libldap,
but in the PHP module (approx. line 1428). I've tried to do a patch but
I'm not very keen on everything around LDAP (this is hmm the second time
I cross LDAP on my way -- btw I'm 18, that explains :D ), and I don't
know if it works (and so I have a server problem *with* a PHP problem)
or not.
I think that the main part is guessing ldap_mods[i]->mod_type from the
attribute name if we delete an attribute, but I've said that I'm not
very an LDAP expert.
If you want any further informations, don't mind asking me :)
Reproduce code:
---
ldap://ldap.example.org";);
$dn = "cn=user,ou=paris,o=example";
$pass = "php-developers-eat-kitties-and-bears";
ldap_bind($cnx,$dn,$pass);
print "REMOVE : ";
if (ldap_mod_del($cnx,$dn,array("userPassword"))) {
print "ADD : ";
ldap_mod_add($cnx, $dn, array("userPassword" =>
"php-developers-dont-eat-kitties-and-bears"));
}
?>
Expected result:
My coffee and no more "Unknown attribute in the data" (or other
annoying errors which make you want to hit your computer).
Actual result:
--
[EMAIL PROTECTED]:~$ php bug.php
REMOVE :
Warning: ldap_mod_del(): Unknown attribute in the data in
/home/alexis/bug.php on line 11
--
Edit this bug report at http://bugs.php.net/?id=45477&edit=1
#45477 [Fbk->Opn]: ldap.so fails to remove attributes when masked by the LDAP server
ID: 45477
User updated by: alexis dot robert at gmail dot com
Reported By: alexis dot robert at gmail dot com
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
It says :
REMOVE :
Warning: ldap_mod_del() [function.ldap-mod-del]: Modify: Server is
unwilling to perform in C:\wamp\www\bug.php on line 11
Previous Comments:
[2008-07-11 15:01:04] [EMAIL PROTECTED]
Have you tried this:
ldap_mod_del($cnx,$dn,array('userPassword' => array()));
[2008-07-10 14:14:11] alexis dot robert at gmail dot com
Description:
Hi,
I currently work at Hachette-Livre (in Paris, France), and I rewrite
their authentification system. Their previous version didn't use
php_ldap to change password because it was said that the developer had
given up saying that it's impossible to do it with PHP (they used a
handwritten Java software called by PHP to change their password).
The fact is, that it's really impossible ! (or I'm really bad) In fact,
NDS (Novell Directory Server) masks the userPassword attribute if I
query it, but the doc says that users can delete/add it.
So, because this field doesn't appear in the LDAP query,
ldap_mod_delete fails, saying "Unknown attribute in the data", which is
pretty logic.
If I read the sourcecode, this issue doesn't seem to come from libldap,
but in the PHP module (approx. line 1428). I've tried to do a patch but
I'm not very keen on everything around LDAP (this is hmm the second time
I cross LDAP on my way -- btw I'm 18, that explains :D ), and I don't
know if it works (and so I have a server problem *with* a PHP problem)
or not.
I think that the main part is guessing ldap_mods[i]->mod_type from the
attribute name if we delete an attribute, but I've said that I'm not
very an LDAP expert.
If you want any further informations, don't mind asking me :)
Reproduce code:
---
ldap://ldap.example.org";);
$dn = "cn=user,ou=paris,o=example";
$pass = "php-developers-eat-kitties-and-bears";
ldap_bind($cnx,$dn,$pass);
print "REMOVE : ";
if (ldap_mod_del($cnx,$dn,array("userPassword"))) {
print "ADD : ";
ldap_mod_add($cnx, $dn, array("userPassword" =>
"php-developers-dont-eat-kitties-and-bears"));
}
?>
Expected result:
My coffee and no more "Unknown attribute in the data" (or other
annoying errors which make you want to hit your computer).
Actual result:
--
[EMAIL PROTECTED]:~$ php bug.php
REMOVE :
Warning: ldap_mod_del(): Unknown attribute in the data in
/home/alexis/bug.php on line 11
--
Edit this bug report at http://bugs.php.net/?id=45477&edit=1
#45465 [Opn->Bgs]: XMLRPC crash with segmentation fault
ID: 45465 Updated by: [EMAIL PROTECTED] Reported By: zulcss at ubuntu dot com -Status: Open +Status: Bogus -Bug Type: XMLRPC-EPI related +Bug Type: Reproducible crash Operating System: Ubuntu intrepid PHP Version: 5.2.6 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. See bug #45226 Previous Comments: [2008-07-09 12:22:46] zulcss at ubuntu dot com Description: Hi, Running a test program causes a segmentation fault with a backtrace. For more information please see: http://bugs.launchpad.net/bugs/239513 If you have any questions plese let me know. Thanks chuck Reproduce code: --- format(DATE_ISO8601); xmlrpc_set_type($params[0], 'datetime'); ?> Expected result: not a crash Actual result: -- [EMAIL PROTECTED]:~/php$ php /tmp/p.php *** stack smashing detected ***: php terminated === Backtrace: = /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x48)[0xb7a73138] /lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x0)[0xb7a730f0] /usr/lib/php5/20060613+lfs/xmlrpc.so[0xb6a7d464] /usr/lib/php5/20060613+lfs/xmlrpc.so[0xb6a7abae] /usr/lib/php5/20060613+lfs/xmlrpc.so(XMLRPC_CreateValueDateTime_ISO8601+0x37)[0xb6a7b4e7] /usr/lib/php5/20060613+lfs/xmlrpc.so(set_zval_xmlrpc_type+0xbb)[0xb6a7232b] /usr/lib/php5/20060613+lfs/xmlrpc.so(zif_xmlrpc_set_type+0xf4)[0xb6a74034] php[0x82f35eb] php(execute+0x188)[0x82e4048] php(zend_execute_scripts+0x183)[0x82c2f13] php(php_execute_script+0x210)[0x8278d90] php(main+0x19da)[0x83553ea] /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe0)[0xb799c450] php[0x8097ec1] === Memory map: 08048000-0855e000 r-xp fe:00 4145214/usr/bin/php5 0855e000-08594000 rw-p 00516000 fe:00 4145214/usr/bin/php5 08594000-087c5000 rw-p 08594000 00:00 0 [heap] b6a17000-b6a2 r-xp fe:00 4407461 /lib/tls/i686/cmov/libnss_files-2.7.so b6a2-b6a22000 rw-p 8000 fe:00 4407461 /lib/tls/i686/cmov/libnss_files-2.7.so b6a22000-b6a55000 r-xp fe:00 4170028 /usr/lib/libxslt.so.1.1.22 b6a55000-b6a56000 rw-p 00033000 fe:00 4170028 /usr/lib/libxslt.so.1.1.22 b6a56000-b6a66000 r-xp fe:00 4170027 /usr/lib/libexslt.so.0.8.13 b6a66000-b6a67000 rw-p f000 fe:00 4170027 /usr/lib/libexslt.so.0.8.13 b6a6e000-b6a81000 r-xp fe:00 3260604 /usr/lib/php5/20060613+lfs/xmlrpc.so b6a81000-b6a82000 rw-p 00012000 fe:00 3260604 /usr/lib/php5/20060613+lfs/xmlrpc.so b6a82000-b6ac9000 r-xp fe:00 4170010 /usr/lib/libtidy-0.99.so.0.0.0 b6ac9000-b6ace000 rw-p 00046000 fe:00 4170010 /usr/lib/libtidy-0.99.so.0.0.0 b6ace000-b6ad7000 r-xp fe:00 3260603 /usr/lib/php5/20060613+lfs/tidy.so b6ad7000-b6ad8000 rw-p 9000 fe:00 3260603 /usr/lib/php5/20060613+lfs/tidy.so b6ad8000-b6b2d000 r-xp fe:00 4169989 /usr/lib/libsqlite.so.0.8.6 b6b2d000-b6b3 rw-p 00054000 fe:00 4169989 /usr/lib/libsqlite.so.0.8.6 b6b3-b6b3e000 r-xp fe:00 3260600 /usr/lib/php5/20060613+lfs/sqlite.so b6b3e000-b6b3f000 rw-p e000 fe:00 3260600 /usr/lib/php5/20060613+lfs/sqlite.so b6b3f000-b6bcc000 r-xp fe:00 4169957 /usr/lib/libnetsnmp.so.15.1.0 b6bcc000-b6bce000 rw-p 0008d000 fe:00 4169957 /usr/lib/libnetsnmp.so.15.1.0 b6bce000-b6bed000 rw-p b6bce000 00:00 0 b6bed000-b6bf3000 r-xp fe:00 3260605 /usr/lib/php5/20060613+lfs/xsl.so b6bf3000-b6bf4000 rw-p 5000 fe:00 3260605 /usr/lib/php5/20060613+lfs/xsl.so b6bf4000-b6d0 r-xp fe:00 4169945 /usr/lib/librecode.so.0.0.0 b6d0-b6d2e000 rw-p 0010b000 fe:00 4169945 /usr/lib/librecode.so.0.0.0 b6d2e000-b6d34000 r-xp fe:00 3260598 /usr/lib/php5/20060613+lfs/snmp.so b6d34000-b6d35000 rw-p 5000 fe:00 3260598 /usr/lib/php5/20060613+lfs/snmp.so b6d35000-b6d3f000 r-xp fe:00 4407312/lib/libgcc_s.so.1 b6d3f000-b6d4 rw-p a000 fe:00 4407312/lib/libgcc_s.so.1 b6d4-b6e28000 r-xp fe:00 3212212 /usr/lib/libstdc++.so.6.0.9 b6e28000-b6e2b000 r--p 000e8000 fe:00 3212212 /usr/lib/libstdc++.so.6.0.9 b6e2b000-b6e2d000 rw-p 000eb000 fe:00 3212212 /usr/lib/libstdc++.so.6.0.9 b6e2d000-b6e33000 rw-p b6e2d000 00:00 0 b6e33000-b6e34000 r-xp fe:00 4169838 /usr/lib/libpspell.so.15.1.4 b6e34000-b6e35000 rw-p fe:00 4169838 /usr/lib/libpspell.so.15.1.4 b6e35000-b6edf000 r-xp fe:00 4169837 /usr/lib/libaspell.so.15.1.4 b6edf000-b6ee4000 rw-p 000a9000 fe:00 4169837 /usr/lib/libaspell.so.15.1.4 b6ee4000-b6ee7000 rw-p b6ee4000 00:00 0 b6eeb000-b6eed000 r-xp fe:00 3260597 /usr/lib/php5/20060613+lfs/recode.so
#45470 [Opn->Bgs]: IMAP with Exchange doesn't work
ID: 45470
Updated by: [EMAIL PROTECTED]
Reported By: kevin at icscomp dot com
-Status: Open
+Status: Bogus
Bug Type: IMAP related
Operating System: Windows 2003 Server
PHP Version: 5.2.6
New Comment:
It's just that Exhange + IMAP == not very good idea. It's not any PHP
bug anyway, we just wrap around the UW Imap c-client lib, so you should
complain to the author of it. But consider yourself warned: He'll say
about same what I said above. :)
Previous Comments:
[2008-07-10 13:22:22] kevin at icscomp dot com
I have tried using this as well:
imap_open("{mailserver:993/imap/ssl}/INBOX",
"domain/user","password",
OP_READONLY, 1) or die("can't connect: ".imap_last_error());
$imap_obj = imap_status($mbox, "{mail:993/imap/ssl}/INBOX",
SA_UNSEEN);
var_dump($imap_obj);
Same result. Any ideas?
[2008-07-10 08:18:38] [EMAIL PROTECTED]
Shouldn't you be using same server name in both imap_open() and
imap_status() ??
[2008-07-09 20:50:56] kevin at icscomp dot com
Description:
When I run the PHP commands to try to retrieve the unread messages
using
the imap_status command, I am finding that no data is being returned.
Additionally, the data that is being returned is random numbers each
time I push the refresh button. I would really like to see this issue
be fixed. Thanks.
My code is below:
Here is the output
Help!
Reproduce code:
---
$mbox = imap_open("{mailserver:993/imap/ssl}",
"domain/user","password",
OP_READONLY, 1) or die("can't connect: ".imap_last_error());
$imap_obj = imap_status($mbox, "{mail:993/imap/ssl}/INBOX",
SA_UNSEEN);
var_dump($imap_obj);
Expected result:
I assume something like:
object(stdClass)#19 (1) { ["Unread"]=> int(5) }
Actual result:
--
Output 1:
object(stdClass)#19 (1) { ["flags"]=> int(0) }
Output 2:
object(stdClass)#19 (2) { ["flags"]=> int(26571976) ["uidnext"]=>
int(26649488) }
back and forth no other data is listed.
--
Edit this bug report at http://bugs.php.net/?id=45470&edit=1
#45478 [Opn->Fbk]: Curl crash within a class
ID: 45478 Updated by: [EMAIL PROTECTED] Reported By: peterphp at mailinator dot com -Status: Open +Status: Feedback Bug Type: cURL related Operating System: Windows XP PHP Version: 5.2.6 New Comment: 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. I can't reproduce this.. Previous Comments: [2008-07-10 14:52:59] peterphp at mailinator dot com Description: Hello, Well i have PHP 5.2.1 an exists the same problem, now i update to 5.2.6 but still exists, so, basicaly apache 2 crash when i try to execute this PHP class. The problem is with $this->handle = curl_init();, if i use $some = curl_init(); work great. Regards, Michael Reproduce code: --- handle = curl_init(); } } ?> Expected result: Assing the curl handle to a class variable. Actual result: -- Sorry, Apache crash, it said that can't read in a memory sector. -- Edit this bug report at http://bugs.php.net/?id=45478&edit=1
#45477 [Opn->Fbk]: ldap.so fails to remove attributes when masked by the LDAP server
ID: 45477
Updated by: [EMAIL PROTECTED]
Reported By: alexis dot robert at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: LDAP related
Operating System: *
PHP Version: 5.2.6
New Comment:
Have you tried this:
ldap_mod_del($cnx,$dn,array('userPassword' => array()));
Previous Comments:
[2008-07-10 14:14:11] alexis dot robert at gmail dot com
Description:
Hi,
I currently work at Hachette-Livre (in Paris, France), and I rewrite
their authentification system. Their previous version didn't use
php_ldap to change password because it was said that the developer had
given up saying that it's impossible to do it with PHP (they used a
handwritten Java software called by PHP to change their password).
The fact is, that it's really impossible ! (or I'm really bad) In fact,
NDS (Novell Directory Server) masks the userPassword attribute if I
query it, but the doc says that users can delete/add it.
So, because this field doesn't appear in the LDAP query,
ldap_mod_delete fails, saying "Unknown attribute in the data", which is
pretty logic.
If I read the sourcecode, this issue doesn't seem to come from libldap,
but in the PHP module (approx. line 1428). I've tried to do a patch but
I'm not very keen on everything around LDAP (this is hmm the second time
I cross LDAP on my way -- btw I'm 18, that explains :D ), and I don't
know if it works (and so I have a server problem *with* a PHP problem)
or not.
I think that the main part is guessing ldap_mods[i]->mod_type from the
attribute name if we delete an attribute, but I've said that I'm not
very an LDAP expert.
If you want any further informations, don't mind asking me :)
Reproduce code:
---
ldap://ldap.example.org";);
$dn = "cn=user,ou=paris,o=example";
$pass = "php-developers-eat-kitties-and-bears";
ldap_bind($cnx,$dn,$pass);
print "REMOVE : ";
if (ldap_mod_del($cnx,$dn,array("userPassword"))) {
print "ADD : ";
ldap_mod_add($cnx, $dn, array("userPassword" =>
"php-developers-dont-eat-kitties-and-bears"));
}
?>
Expected result:
My coffee and no more "Unknown attribute in the data" (or other
annoying errors which make you want to hit your computer).
Actual result:
--
[EMAIL PROTECTED]:~$ php bug.php
REMOVE :
Warning: ldap_mod_del(): Unknown attribute in the data in
/home/alexis/bug.php on line 11
--
Edit this bug report at http://bugs.php.net/?id=45477&edit=1
#45481 [Opn->Bgs]: the function PHP_MSHUTDOWN_FUNCTION was called by every process of apache but
ID: 45481
Updated by: [EMAIL PROTECTED]
Reported By: xufei_ok at 126 dot com
-Status: Open
+Status: Bogus
Bug Type: Apache2 related
Operating System: redhat linux 2.6.18-8.el5
PHP Version: 5.2.6
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
Ask such questions on the mailing lists. For example
[EMAIL PROTECTED]
Previous Comments:
[2008-07-11 07:59:18] xufei_ok at 126 dot com
Description:
In the php extension moduld the function PHP_MSHUTDOWN_FUNCTION was
called by every process of apache while PHP_MINIT_FUNCTION only was
called one time by the parent process of apache.
It cause the whold module only was initialized one times but was
finalized several times.
Reproduce code:
---
PHP_MINIT_FUNCTION(zraidapi)
{
/* If you have INI entries, uncomment these lines
REGISTER_INI_ENTRIES();
*/
ZA_DBG_Init( "" );
if( FALSE == zRaidApiInit() ) // 0 - SILENT_MODE, 1 -
BUZZER_MODE
{
zend_error( E_ERROR, "zRaidApiInit() failed!!" );
return FAILURE;
}
STORE_KEY(PHP_ZRAIDAPI, 1, 0, 0, 18);
return SUCCESS;
}
PHP_MSHUTDOWN_FUNCTION(zraidapi)
{
/* uncomment this line if you have INI entries
UNREGISTER_INI_ENTRIES();
*/
zRaidApiShutdown();
ZA_DBG_Shutdown();
return SUCCESS;
}
Expected result:
I want to get some explaination about when the PHP_MINIT_FUNCTION and
PHP_MSHUTDOWN_FUNCTION were called , and whether it is a bug of php or
apache2.
--
Edit this bug report at http://bugs.php.net/?id=45481&edit=1
#45482 [Opn->Fbk]: some big5 Chinese character lead to Parse error
ID: 45482 Updated by: [EMAIL PROTECTED] Reported By: yournana at gmail dot com -Status: Open +Status: Feedback Bug Type: mbstring related Operating System: windows/unix PHP Version: 5.2.6 New Comment: Did you enable multibyte support in your build? In *nix you need to use --enable-zend-multibyte in your configure line. I don't know what the option is in win32 configure though. :) Previous Comments: [2008-07-11 10:18:10] yournana at gmail dot com you must change the "江靜俞" back to real characters... [2008-07-11 10:08:24] yournana at gmail dot com Description: when I writting php script in big5 encoding , I find a strange thing , I simply type in big5 encoding,it show me a Parse error: syntax error, unexpected $end in D:\lab\bug\test.php on line 3 than I change encoding to utf-8, it works fine, the key cahracter is '俞',also the same as some other special characters, it's a bug ? Reproduce code: --- [big5 encoding] Expected result: just show the [江靜俞] Actual result: -- syntax error, unexpected $end in D:\lab\bug\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=45482&edit=1
#45486 [Opn->Csd]: mb_send_mail(); header 'Content-Type: text/plain; charset=' parsing incorrect
ID: 45486 Updated by: [EMAIL PROTECTED] Reported By: serovov at gmail dot com -Status: Open +Status: Closed Bug Type: mbstring related Operating System: * PHP Version: 5.2.6 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: [2008-07-11 11:33:22] serovov at gmail dot com Description: When executing mb_send_mail with headers Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" But when i pass charset=UTF-8 its works Okey... Reproduce code: --- Expected result: ignore quotes in Content-Type: text/plain; charset="UTF-8" Actual result: -- Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" -- Edit this bug report at http://bugs.php.net/?id=45486&edit=1
#45486 [Asn->Opn]: mb_send_mail(); header 'Content-Type: text/plain; charset=' parsing incorrect
ID: 45486 Updated by: [EMAIL PROTECTED] Reported By: serovov at gmail dot com -Status: Assigned +Status: Open -Bug Type: Unknown/Other Function +Bug Type: mbstring related Operating System: all PHP Version: 5.2.6 Assigned To: felipe Previous Comments: [2008-07-11 11:33:22] serovov at gmail dot com Description: When executing mb_send_mail with headers Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" But when i pass charset=UTF-8 its works Okey... Reproduce code: --- Expected result: ignore quotes in Content-Type: text/plain; charset="UTF-8" Actual result: -- Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" -- Edit this bug report at http://bugs.php.net/?id=45486&edit=1
#45486 [Opn->Asn]: mb_send_mail(); header 'Content-Type: text/plain; charset=' parsing incorrect
ID: 45486 Updated by: [EMAIL PROTECTED] Reported By: serovov at gmail dot com -Status: Open +Status: Assigned Bug Type: Unknown/Other Function Operating System: all PHP Version: 5.2.6 -Assigned To: +Assigned To: felipe Previous Comments: [2008-07-11 11:33:22] serovov at gmail dot com Description: When executing mb_send_mail with headers Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" But when i pass charset=UTF-8 its works Okey... Reproduce code: --- Expected result: ignore quotes in Content-Type: text/plain; charset="UTF-8" Actual result: -- Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" -- Edit this bug report at http://bugs.php.net/?id=45486&edit=1
#44039 [Opn->Csd]: Throwing an exception results in Access Violation on Win32 ISAPI.
ID: 44039
Updated by: [EMAIL PROTECTED]
Reported By: RQuadling at GMail dot com
-Status: Open
+Status: Closed
Bug Type: IIS related
Operating System: Windows XP SP2
PHP Version: 5.3CVS-2008-02-04 (snap)
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.
This was present in all threaded SAPIS for awhile, dup of #44226
Previous Comments:
[2008-03-24 08:32:54] slava at shabrov dot com
I have v 5.2.4 working for almost half a year - no problem. Had to
enable "magic_quotes_gpc" to simulate client's site and all hell broke
loose.
"PHP has encountered an Access Violation at 01B6AB92"
"Fatal error: Cannot redeclare pma_ifsetor() (previously declared in
C:\wwwroot\phpmyadmin\libraries\core.lib.php:38) in
C:\wwwroot\phpmyadmin\libraries\core.lib.php on line 45"
... and so on.
Turned it off and peace is restored.
Windows 2003 Server Standard x86 on Pentium IV. ISAPI configuration.
System disk E:; boot disk C: all NTFS.
Somehow installer put number of files on C:, creating "program
files/php" folder (maybe a bug in installer). php.ini file in e:\program
files\php
Hope this helps.
[2008-02-05 10:07:32] RQuadling at GMail dot com
Results in "PHP has encountered an Access Violation at ".
Nothing to do with the undefined variable.
Also, different output at the command line (this may be me not getting
something quite right).
php -n unk.php
[No output]
php -n -r "throw new exception('Broken exceptions', 0);"
Fatal error: Uncaught exception 'Exception' with message 'Broken
exceptions' in Command line code:1
Stack trace:
#0 {main}
thrown in Command line code on line 1
So, we have 3 different outputs for the same line of code.
Nothing if using PHP as CLI interpreter.
Fatal error when using PHP with STDIN (correct output).
Access Violation when using PHP via ISAPI interface (Sambar Server).
[2008-02-04 14:03:45] RQuadling at GMail dot com
Description:
The following code worked on a snapshot in January.
The code only seems to go wrong in ISAPI (Using Sambar Server).
Works fine in CLI mode.
php -n -derror_reporting=-1 -ddisplay_errors=1 -r "throw new
exception('foo' . $bar, 0);"
produces ...
Notice: Undefined variable: bar in Command line code on line 1
Fatal error: Uncaught exception 'Exception' with message 'foo' in
Command line code:1
Stack trace:
#0 {main}
thrown in Command line code on line 1
Reproduce code:
---
Expected result:
Notice: Undefined variable: unknown in C:\unk.php on line 4
Fatal error: Uncaught exception 'Exception' with message 'Missing
variable ' in C:\unk.php:4
Stack trace:
#0 {main}
thrown in C:\unk.php on line 4
Actual result:
--
PHP has encountered an Access Violation at
--
Edit this bug report at http://bugs.php.net/?id=44039&edit=1
#45485 [Asn->Csd]: strip_tags and
ID: 45485 Updated by: [EMAIL PROTECTED] Reported By: jlim at natsoft dot com -Status: Assigned +Status: Closed Bug Type: Strings related Operating System: Windows PHP Version: 5.2.6 Assigned To: felipe 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: [2008-07-11 11:12:30] jlim at natsoft dot com Description: This is related to bug #12860. The HTML tags are not stripped properly because of This Text disappears EOD; $s = strip_tags($s); echo htmlspecialchars($s),""; # WORKS $s =<<< EOD This text is shown This Text disappears EOD; $s = strip_tags($s); echo htmlspecialchars($s),""; ?> Expected result: This text is shown This Text disappears -- This text is shown This Text disappears Actual result: -- This text is shown -- This text is shown This Text disappears -- Edit this bug report at http://bugs.php.net/?id=45485&edit=1
#45485 [Opn->Asn]: strip_tags and
ID: 45485 Updated by: [EMAIL PROTECTED] Reported By: jlim at natsoft dot com -Status: Open +Status: Assigned Bug Type: Strings related Operating System: Windows PHP Version: 5.2.6 -Assigned To: +Assigned To: felipe Previous Comments: [2008-07-11 11:12:30] jlim at natsoft dot com Description: This is related to bug #12860. The HTML tags are not stripped properly because of This Text disappears EOD; $s = strip_tags($s); echo htmlspecialchars($s),""; # WORKS $s =<<< EOD This text is shown This Text disappears EOD; $s = strip_tags($s); echo htmlspecialchars($s),""; ?> Expected result: This text is shown This Text disappears -- This text is shown This Text disappears Actual result: -- This text is shown -- This text is shown This Text disappears -- Edit this bug report at http://bugs.php.net/?id=45485&edit=1
#45486 [NEW]: mb_send_mail(); header 'Content-Type: text/plain; charset=' parsing incorrect
From: serovov at gmail dot com Operating system: all PHP version: 5.2.6 PHP Bug Type: Unknown/Other Function Bug description: mb_send_mail(); header 'Content-Type: text/plain; charset=' parsing incorrect Description: When executing mb_send_mail with headers Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" But when i pass charset=UTF-8 its works Okey... Reproduce code: --- Expected result: ignore quotes in Content-Type: text/plain; charset="UTF-8" Actual result: -- Error: "Unsupported charset ""UTF-8"" - will be regarded as ascii" -- Edit bug report at http://bugs.php.net/?id=45486&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45486&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45486&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45486&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45486&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45486&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45486&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45486&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45486&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45486&r=support Expected behavior:http://bugs.php.net/fix.php?id=45486&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45486&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45486&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45486&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45486&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45486&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45486&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45486&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45486&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45486&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45486&r=mysqlcfg
#45485 [NEW]: strip_tags and
From: jlim at natsoft dot com Operating system: Windows PHP version: 5.2.6 PHP Bug Type: Strings related Bug description: strip_tags and This Text disappears EOD; $s = strip_tags($s); echo htmlspecialchars($s),""; # WORKS $s =<<< EOD This text is shown This Text disappears EOD; $s = strip_tags($s); echo htmlspecialchars($s),""; ?> Expected result: This text is shown This Text disappears -- This text is shown This Text disappears Actual result: -- This text is shown -- This text is shown This Text disappears -- Edit bug report at http://bugs.php.net/?id=45485&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45485&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45485&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45485&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45485&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45485&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45485&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45485&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45485&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45485&r=support Expected behavior:http://bugs.php.net/fix.php?id=45485&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45485&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45485&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45485&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45485&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45485&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45485&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45485&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45485&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45485&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45485&r=mysqlcfg
#45460 [Asn->Csd]: imap patch for fromlength fix in imap_headerinfo doesn't accept lengths of 1024
ID: 45460 Updated by: [EMAIL PROTECTED] Reported By: andrew at lifescale dot com -Status: Assigned +Status: Closed Bug Type: IMAP related Operating System: FreeBSD 6.1 PHP Version: 5.2.6 Assigned To: felipe New Comment: Opss, you are right. Fixed! Thanks. :) Previous Comments: [2008-07-10 19:08:17] [EMAIL PROTECTED] Felipe, please check that (sorry I'm too lazy to do it myself *g*) [2008-07-10 18:42:17] andrew at lifescale dot com I noticed the buffer size for the from / subject data wasn't increased. Does it not need to be: fulladdress[MAILTMPLEN + 1]; Since a subject of 1024 would fill fulladdress and not have room for a null byte at the end? [2008-07-10 17:49:45] [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. [2008-07-08 16:16:34] andrew at lifescale dot com Description: There was a patch on April 1 for imap.c that added a sanity check to the from and subject lengths when calling imap_headerinfo() http://cvs.php.net/viewvc.cgi/php-src/ext/imap/php_imap.c?r1=1.247&r2=1.248 The error message says that the from / subject lengths have to be between 1 and 1024. However it will not accept a fromlength of 1024 due to the >= operator. MAILTMPLEN is 1024 This causes a problem for the pear library IMAPv2 as it defaults the fromlength and subjectlength to 1024 Either the error message must be updated to MAILTMPLEN-1, or the operator and char array must be changed (this is preferred as to not bust IMAPv2) Reproduce code: --- I don't have a good example as I use IMAPv2. However, it seems like a simple problem just by looking at the code Expected result: imap_headerinfo should accept a fromlength of 1024 Actual result: -- A warning is given: Jul 8 00:01:49 php: PHP Warning: imap_headerinfo(): From length has to be between 1 and 1024 in /usr/local/lib/php/Mail/IMAPv2.php on line 1505 -- Edit this bug report at http://bugs.php.net/?id=45460&edit=1
#45484 [NEW]: PDOStatment set datatype to string
From: cbidon007 at hotmail dot com
Operating system: windows xp
PHP version: 5.2.6
PHP Bug Type: PDO related
Bug description: PDOStatment set datatype to string
Description:
Hy,
I use an oracle database and my locale setting for the decimal point is
",".
When I run a SELECT query with a float datatype column, the result is a
string datatype value and the decimal separator is ','.
And PHP don't recognize this as a number.
Why oracle column datatypes are not kept?
Reproduce code:
---
$oPDOStmt = $oConn->query("SELECT 12.34 AS NB FROM DUAL");
$arrResult = $oPDOStmt->fetch(PDO::FETCH_ASSOC);
print_r($arrResult);
print gettype($arrResult["NB"]);
Expected result:
Array
(
[NB] => 12.34
)
Actual result:
--
Array
(
[NB] => 12,34
)
--
Edit bug report at http://bugs.php.net/?id=45484&edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45484&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45484&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45484&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45484&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45484&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45484&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45484&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45484&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45484&r=support
Expected behavior:http://bugs.php.net/fix.php?id=45484&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45484&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45484&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45484&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45484&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45484&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45484&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45484&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45484&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45484&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45484&r=mysqlcfg
#45483 [Opn->Asn]: Add an era designater to DateTime methods when formatting or parsing dates
ID: 45483 Updated by: [EMAIL PROTECTED] Reported By: tj at systisoft dot com -Status: Open +Status: Assigned Bug Type: Feature/Change Request Operating System: All PHP Version: 5.3CVS-2008-07-11 (CVS) -Assigned To: +Assigned To: derick Previous Comments: [2008-07-11 10:18:11] tj at systisoft dot com Description: It is currently not possible to specify an era designator in a format when parsing or formatting dates with DateTime::createFromFormat or DateTime::format. An era designater would be BC or AD as in 1/1/0200 BC or 1/1/2004 AD. I don't know which format char would be good since 'G' which is used in some other format patterns as era designator seems to be already taken. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at http://bugs.php.net/?id=45483&edit=1
#45483 [NEW]: Add an era designater to DateTime methods when formatting or parsing dates
From: tj at systisoft dot com Operating system: All PHP version: 5.3CVS-2008-07-11 (CVS) PHP Bug Type: Feature/Change Request Bug description: Add an era designater to DateTime methods when formatting or parsing dates Description: It is currently not possible to specify an era designator in a format when parsing or formatting dates with DateTime::createFromFormat or DateTime::format. An era designater would be BC or AD as in 1/1/0200 BC or 1/1/2004 AD. I don't know which format char would be good since 'G' which is used in some other format patterns as era designator seems to be already taken. Reproduce code: --- N/A Expected result: N/A Actual result: -- N/A -- Edit bug report at http://bugs.php.net/?id=45483&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45483&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45483&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45483&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45483&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45483&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45483&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45483&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45483&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45483&r=support Expected behavior:http://bugs.php.net/fix.php?id=45483&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45483&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45483&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45483&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45483&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45483&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45483&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45483&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45483&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45483&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45483&r=mysqlcfg
#45482 [Com]: some big5 Chinese character lead to Parse error
ID: 45482 Comment by: yournana at gmail dot com Reported By: yournana at gmail dot com Status: Open Bug Type: Recode related Operating System: windows/unix PHP Version: 5.2.6 New Comment: you must change the "江靜俞" back to real characters... Previous Comments: [2008-07-11 10:08:24] yournana at gmail dot com Description: when I writting php script in big5 encoding , I find a strange thing , I simply type in big5 encoding,it show me a Parse error: syntax error, unexpected $end in D:\lab\bug\test.php on line 3 than I change encoding to utf-8, it works fine, the key cahracter is '俞',also the same as some other special characters, it's a bug ? Reproduce code: --- [big5 encoding] Expected result: just show the [江靜俞] Actual result: -- syntax error, unexpected $end in D:\lab\bug\test.php on line 3 -- Edit this bug report at http://bugs.php.net/?id=45482&edit=1
#45482 [NEW]: some big5 Chinese character lead to Parse error
From: yournana at gmail dot com Operating system: windows/unix PHP version: 5.2.6 PHP Bug Type: Recode related Bug description: some big5 Chinese character lead to Parse error Description: when I writting php script in big5 encoding , I find a strange thing , I simply type in big5 encoding,it show me a Parse error: syntax error, unexpected $end in D:\lab\bug\test.php on line 3 than I change encoding to utf-8, it works fine, the key cahracter is '俞',also the same as some other special characters, it's a bug ? Reproduce code: --- [big5 encoding] Expected result: just show the [江靜俞] Actual result: -- syntax error, unexpected $end in D:\lab\bug\test.php on line 3 -- Edit bug report at http://bugs.php.net/?id=45482&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=45482&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=45482&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=45482&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=45482&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=45482&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=45482&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=45482&r=needscript Try newer version:http://bugs.php.net/fix.php?id=45482&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=45482&r=support Expected behavior:http://bugs.php.net/fix.php?id=45482&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=45482&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=45482&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=45482&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45482&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=45482&r=dst IIS Stability:http://bugs.php.net/fix.php?id=45482&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=45482&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=45482&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=45482&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=45482&r=mysqlcfg
