Bug #60536 [Opn]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1
ID: 60536
Updated by: scott...@php.net
Reported by:scott...@php.net
Summary:Traits Segfault
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: ubuntu 11.11
PHP Version:5.4SVN-2011-12-15 (SVN)
Block user comment: N
Private report: N
New Comment:
backtrace:
#0 0x000100289c71 in zend_mm_check_ptr (heap=0x10100, ptr=0x100c4f730,
silent=1, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:1380
#1 0x00010028c1ad in _zend_mm_free_int (heap=0x10100, p=0x100c4f730,
__zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2064
#2 0x00010028de9d in _efree (ptr=0x100c4f730, __zend_filename=0x1005476a8
"/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_vm_execute.h",
__zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2436
#3 0x0001003742c8 in i_zval_ptr_dtor [inlined] () at
/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_execute.h:88
#4 0x0001003742c8 in ZEND_RETURN_SPEC_VAR_HANDLER
(execute_data=0x1009802f8)
at zend_execute.h:10833
#5 0x00010032a882 in execute (op_array=0x1009bad50) at
zend_vm_execute.h:410
#6 0x0001002d733b in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:1272
#7 0x000100219973 in php_execute_script (primary_file=0x7fff5fbff170) at
main.c:2476
Previous Comments:
[2011-12-15 20:37:07] scott...@php.net
Description:
Following code crashes.
Test script:
---
x; }
}
class Z extends Y {
function z() { return ++$this->x; }
}
$a = new Z();
$a->x();
--
Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #61124 [Asn->Csd]: Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=61124&edit=1
ID: 61124
Updated by: scott...@php.net
Reported by:mangirdas at impresspages dot org
Summary:Segmentation fault
-Status: Assigned
+Status: Closed
Type: Bug
Package:OpenSSL related
Operating System: CentOS release 5.7 (Final)
PHP Version:5.3.10
Assigned To:scottmac
Block user comment: N
Private report: N
New Comment:
Thanks, Fixed in 5.3, 5.4 and trunk.
Previous Comments:
[2012-02-23 01:26:43] scott...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=323440
Log: Fixed bug #61124 (Crash when decoding an invalid base64 encoded string).
[2012-02-22 18:55:26] johan...@php.net
Scott said he'd look into it :-)
[2012-02-18 04:39:27] me at ktamura dot com
I think I know why. Basically, when the input data is malformed but $raw_input
is set to false, we get a null pointer. Here is a suggested patch (Also
available at https://gist.github.com/1857431)
Index: ext/openssl/openssl.c
===
--- ext/openssl/openssl.c (revision 323312)
+++ ext/openssl/openssl.c (working copy)
@@ -4801,6 +4801,11 @@
base64_str = (char*)php_base64_decode((unsigned char*)data, data_len,
&base64_str_len);
data_len = base64_str_len;
data = base64_str;
+
+if (data == NULL) {
+php_error_docref(NULL TSRMLS_CC, E_WARNING, "Failed to decode the
base64 input");
+RETURN_FALSE;
+}
}
keylen = EVP_CIPHER_key_length(cipher_type);
[2012-02-18 01:02:48] me at ktamura dot com
I feel that the real issue is that there is no input check on the first
argument of
openssl_decrypt. Looking at http://linux.die.net/man/3/evp_decryptupdate it is
unclear what the expected behavior is if you feed invalid input into
EVP_DecryptUpdate. Perhaps we can do input validation?
[2012-02-18 00:53:01] me at ktamura dot com
FYI...the said "hacky" patch of adding 16 as opposed to 1 bytes do not solve
the
problem for PHP 5.3.8 built with --enable-debug and --with-openssl
--without-iconv
options on snow leopard.
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
https://bugs.php.net/bug.php?id=61124
--
Edit this bug report at https://bugs.php.net/bug.php?id=61124&edit=1
#47695 [Bgs->Csd]: --with-iconv configure option always fails in Leopard
ID: 47695
Updated by: scott...@php.net
Reported By: p2409 at hotmail dot com
-Status: Bogus
+Status: Closed
Bug Type: Compile Failure
Operating System: Mac OS X 10.5.5
PHP Version: 5.2.9
Assigned To: scottmac
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.
--with-iconv=/opt/local not --with-iconv-dir this is only for xmlrpc
and not for the regular iconv.
Previous Comments:
[2009-03-17 23:49:46] scott...@php.net
AC_MSG_CHECKING([if iconv supports errno])
it's intentionally checking to see if iconv sets errno as well as
returning -1.
This has nothing to do with iconv not building on leopard.
[2009-03-17 18:02:24] p2409 at hotmail dot com
Description:
Many people report problems compiling PHP on Leopard due to a libiconv
issue.
This may be due to the small C test programme in ./configure.
It calls open_conv with two const * char arguments (correct), but these
are NOT valid charsets to iconv (incorrect). This then breaks
./configure.
AFAIK from the libiconv documentation, the PHP ./configure call is
incorrect: this function expects two valid charset arguments. (You can
see a list of valid arguments by running iconv -l).
Changing the call to eg.:
cd = open_conv("UTF-8","ISO-8859-1")
returns a valid iconv_t number (non-negative), and configure can then
continue setting up for Makefile compile.
Reproduce code:
---
In ./configure, search for open_iconv:
cd = open_iconv("*** blah blah ***","*** blah blah ***")
Expected result:
This call fails ie. cd return value is negative. ./configure considers
this a libiconv fail, and does not continue.
The expected result is correct ie. -1, however this test should return
a positive number and allow ./configure to continue.
Changing the two parameters in the call to open_iconv to valid charsets
(see list with ./iconv -l) returns a valid translaction number (type
iconv_t). This would then allow ./configure to continue.
--
Edit this bug report at http://bugs.php.net/?id=47695&edit=1
#43189 [NoF->Csd]: Fails to link iconv
ID: 43189 Updated by: scott...@php.net Reported By: meh at mailinator dot com -Status: No Feedback +Status: Closed Bug Type: ICONV related Operating System: Mac OS X 10.5 PHP Version: 5.3CVS-2007-11-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. Previous Comments: [2009-04-24 17:38:06] richard dot sentino at mindginative dot com This configure option worked for me: --with-iconv=/opt/local (Mac OS 10.5.6, PHP 5.2.9, iconv installed in /opt/local using macports) but it doesn't work with this configure option : --with-iconv=shared,/opt/local the configure passed and make passed but iconv won't show up when I do php -m [2009-04-03 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-03-27 06:26:43] senz at senz dot su Changing --with-iconv-dir to --with-iconv=shared,/opt/local solve it on my system. /opt/local = macports with iconv [2009-03-27 06:10:22] senz at senz dot su To scott...@php.net: here's my config.log from compilation with error. iconv compiled by macports. --with-iconv-dir=shared,/opt/local and static both failed. http://rapidshare.com/files/214033749/config.log.html i also send a copy on your email. [2009-03-26 23:21:14] scott...@php.net I need the config.log for the static build to try and work out whats happening. 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/43189 -- Edit this bug report at http://bugs.php.net/?id=43189&edit=1
#47695 [Csd->Bgs]: --with-iconv configure option always fails in Leopard
ID: 47695 Updated by: scott...@php.net Reported By: p2409 at hotmail dot com -Status: Closed +Status: Bogus Bug Type: Compile Failure Operating System: Mac OS X 10.5.5 PHP Version: 5.2.9 Assigned To: scottmac New Comment: Whoops, this was the wrong bug report. Was another iconv issue on leopard. bug #43189 Previous Comments: [2009-04-30 09:28:08] p2409 at hotmail dot com "[17 Mar 11:49pm UTC] scott...@php.net AC_MSG_CHECKING([if iconv supports errno]) it's intentionally checking to see if iconv sets errno as well as returning -1. This has nothing to do with iconv not building on leopard." So what got fixed then? [2009-04-27 18:42:15] j...@php.net Fixed in all branches now, thanks Scott. [2009-04-27 18:35:33] j...@php.net Not fixed in PHP_5_2 -> re-opened and assigned. [2009-04-27 17:49:59] scott...@php.net 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. --with-iconv=/opt/local not --with-iconv-dir this is only for xmlrpc and not for the regular iconv. [2009-03-17 23:49:46] scott...@php.net AC_MSG_CHECKING([if iconv supports errno]) it's intentionally checking to see if iconv sets errno as well as returning -1. This has nothing to do with iconv not building on leopard. 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/47695 -- Edit this bug report at http://bugs.php.net/?id=47695&edit=1
#48137 [Bgs]: assigning array element reference appears to modify array
ID: 48137
Updated by: scott...@php.net
Reported By: mike at clove dot com
Status: Bogus
Bug Type: Arrays related
Operating System: Mac OS X 10.5.6
PHP Version: 5.2.9
New Comment:
References aren't pointers, all they say is that the two values should
point to the same content. This is still the case even if the array was
changed.
http://www.php.net/manual/en/language.references.whatare.php
Previous Comments:
[2009-05-03 17:04:57] der...@php.net
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
Nah, this is fine. It doesn\'t modify the array. The & just shows that
the is_ref bit on the zval container that contains the int(1) value is
set.
[2009-05-03 17:01:04] mike at clove dot com
Description:
Assigning reference to an array element appears to modify the
array element rather than simply creating a reference to it.
This is surprising, to say the least.
At least I think this is a bug and couldn't find anything with the same
behavior and such minimal code.
Reproduce code:
---
$a = array(1,2);
$r =& $a[0];
var_dump($a);
Expected result:
array(2) {
[0]=>
int(1)
[1]=>
int(2)
}
Actual result:
--
array(2) {
[0]=>
&int(1)
[1]=>
int(2)
}
--
Edit this bug report at http://bugs.php.net/?id=48137&edit=1
#48135 [Opn->Fbk]: Isset doesn't function as expected
ID: 48135
Updated by: scott...@php.net
Reported By: wizanda at yahoo dot co dot uk
-Status: Open
+Status: Feedback
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.9
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.
We need a self contained script that we can run, though it sounds like
you just need.
!isset($handler, $handler[$name])
To check both the array and the key.
Previous Comments:
[2009-05-03 12:33:15] wizanda at yahoo dot co dot uk
Description:
Since PHP 5 most PHP systems will be storing masses of data, due to
isset and empty no longer assessing the full variable, yet running code
once for each item within it.
Reproduce code:
---
---
>From manual page: function.isset
---
function &loadHandler($name){static $handler;
if(!isset($handler[$name])){$FileName = "core/core.".$name.".php";
require_once $FileName;
$ClassName = "SmartyCore_".$name;
$handler[$name] = new $ClassName();}
$classes = $handler[$name];
return $classes;}
Expected result:
This should check $handler, see if it's empty the first time; check
$name and see this is an empty array, attempt to fill it and thus
setting the $handler as being a container for the array and then check
for each $name as a separate array within it.
Actual result:
--
What this appears to be doing is checking $handler and running it, then
checking $name and running it... So when you var_dump the $handler it
has multiple copies of the variable set.
This can be slightly resolved by making the array set the original
$handler variable, which reduces the copies made.
$handler = array($name => new $ClassName());}
...Yet there should be only one copy set.
--
Edit this bug report at http://bugs.php.net/?id=48135&edit=1
#48142 [Opn->Bgs]: Confusing behavior
ID: 48142 Updated by: scott...@php.net Reported By: smh at wannafind dot dk -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Linux 2.6.24.3-50.fc8 PHP Version: 5.2.9 New Comment: Adding new errors would result in breaking backwards compatibility so it isn't really practical to change. You could add an array typehint to parameters to add extra checking. Previous Comments: [2009-05-04 09:46:44] smh at wannafind dot dk Description: Requesting a string index on a string type using the string as an array always returns first character position in string. Reproduce code: --- Expected result: PHP should generate an error when this occurs, because this situation occurs when you think a method/function returns a string indexed array but really just returns a string. In this situation you get some data, but the data is incorrect and this can be very confusing to debug. Actual result: -- PHP casts the string index to an integer with the value: 0 and returns the first character in the string. -- Edit this bug report at http://bugs.php.net/?id=48142&edit=1
#48135 [Opn->Bgs]: Isset doesn't function as expected
ID: 48135
Updated by: scott...@php.net
Reported By: wizanda at yahoo dot co dot uk
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.9
New Comment:
I can't reproduce this, the output I get is as follows:
scott-mbp:tmp scott$ /usr/bin/php test.php
countarray(1) {
["Funky"]=>
object(Funky)#1 (0) {
}
}
Previous Comments:
[2009-05-04 11:12:27] wizanda at yahoo dot co dot uk
Found that if you return it first when it's set, it won't multiple fill
the static var, yet this is also the same as a singleton pattern, so it
looks as if those are also mass storing information.
';}
var_dump($handlers);
$handle = $handlers[$name];
return $handle;}
collectClass('Funky');
collectClass('Funky');
collectClass('Funky');
?>
[2009-05-04 09:45:34] wizanda at yahoo dot co dot uk
Thank you for the reply, here is a better example and a rephrase of the
problem...
';}
var_dump($handlers);
$handle = $handlers[$name];
return $handle;}
collectClass('Funky');
collectClass('Funky');
collectClass('Funky');
?>
On doing this i realized its not so much isset is broken sorry, as if
we test the occurrences of the count, we find it runs once...Yet if we
var_dump() the static var, it has 3 copies of something that it has only
collected once and so shouldn't it only be stored once? Else its
amassing tons of data in a large system?
[2009-05-04 00:42:28] scott...@php.net
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.
We need a self contained script that we can run, though it sounds like
you just need.
!isset($handler, $handler[$name])
To check both the array and the key.
[2009-05-03 12:33:15] wizanda at yahoo dot co dot uk
Description:
Since PHP 5 most PHP systems will be storing masses of data, due to
isset and empty no longer assessing the full variable, yet running code
once for each item within it.
Reproduce code:
---
---
>From manual page: function.isset
---
function &loadHandler($name){static $handler;
if(!isset($handler[$name])){$FileName = "core/core.".$name.".php";
require_once $FileName;
$ClassName = "SmartyCore_".$name;
$handler[$name] = new $ClassName();}
$classes = $handler[$name];
return $classes;}
Expected result:
This should check $handler, see if it's empty the first time; check
$name and see this is an empty array, attempt to fill it and thus
setting the $handler as being a container for the array and then check
for each $name as a separate array within it.
Actual result:
--
What this appears to be doing is checking $handler and running it, then
checking $name and running it... So when you var_dump the $handler it
has multiple copies of the variable set.
This can be slightly resolved by making the array set the original
$handler variable, which reduces the copies made.
$handler = array($name => new $ClassName());}
...Yet there should be only one copy set.
--
Edit this bug report at http://bugs.php.net/?id=48135&edit=1
#48134 [Bgs->Fbk]: php crash after a few days (backtrace attached)
ID: 48134 Updated by: scott...@php.net Reported By: jimbobpalmer at gmail dot com -Status: Bogus +Status: Feedback Bug Type: Reproducible crash Operating System: Gentoo PHP Version: 5.2.9 Previous Comments: [2009-05-05 13:54:51] jimbobpalmer at gmail dot com I've rebuilt php with the debug flag so that the next backtrace is more useful. Please can you change the status of this bug to open. Thanks. [2009-05-05 13:33:19] jimbobpalmer at gmail dot com backtrace from coredump: #0 0xb7612052 in apply_config () from /usr/lib/apache2/modules/libphp5.so #1 0xb76114af in ?? () from /usr/lib/apache2/modules/libphp5.so #2 0x08987108 in ?? () #3 0x0ad8b230 in ?? () #4 0xb76107c0 in ?? () from /usr/lib/apache2/modules/libphp5.so #5 0x08063c00 in __ctype_toupper_...@plt () #6 0x0aa8b098 in ?? () #7 0x0aa8b060 in ?? () #8 0xa42b8188 in ?? () #9 0xb7d0dff4 in ?? () from /usr/lib/libapr-1.so.0 #10 0x08987108 in ?? () #11 0x0ad8b180 in ?? () #12 0x0ad8b198 in ?? () #13 0xb7cf7c1f in apr_table_setn () from /usr/lib/libapr-1.so.0 #14 0x0807a127 in ap_run_handler () #15 0x0807d4b1 in ap_invoke_handler () #16 0x080887e6 in ap_process_request () #17 0x080857d8 in ?? () #18 0x0aa89428 in ?? () #19 0x0004 in ?? () #20 0x0aa89428 in ?? () #21 0x in ?? () I can't supply the coredump due to policy reasons, but I can run more commands if you need me to with gdb. [2009-05-05 13:31:15] jimbobpalmer at gmail dot com With 5.2.9: [Tue May 5 15:03:32 2009] pid 27627 mod_backtrace backtrace for sig 11 (thread "pid" 27627) [Tue May 5 15:03:32 2009] pid 27627 mod_backtrace main() is at 8066050 /usr/lib/apache2/modules/mod_backtrace.so[0xb7ae2a9a] /usr/sbin/apache2(ap_run_fatal_exception+0x3f)[0x80827ef] /usr/sbin/apache2[0x8082be8] [0xb7ef8400] /usr/lib/apache2/modules/libphp5.so[0xb76114af] /usr/sbin/apache2(ap_run_handler+0x57)[0x807a127] /usr/sbin/apache2(ap_invoke_handler+0x91)[0x807d4b1] /usr/sbin/apache2(ap_process_request+0x196)[0x80887e6] /usr/sbin/apache2[0x80857d8] /usr/sbin/apache2(ap_run_process_connection+0x57)[0x80814b7] /usr/sbin/apache2[0x808e6ac] /usr/lib/libapr-1.so.0[0xb7d08e8e] /lib/libpthread.so.0[0xb7c9519b] /lib/libc.so.6(clone+0x5e)[0xb7c1986e] [Tue May 5 15:03:32 2009] pid 27627 mod_backtrace end of backtrace [2009-05-03 12:33:59] j...@php.net Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. [2009-05-03 11:03:52] jimbobpalmer at gmail dot com Description: 5.2.8-pl2-gentoo, I can't upgrade atm. No crashes for a few days, then logs, like this one: Backtrace: pid 19488 mod_backtrace main() is at 8066050 /usr/lib/apache2/modules/mod_backtrace.so[0xb7b7aa9a] /usr/sbin/apache2(ap_run_fatal_exception+0x3f)[0x80827ef] /usr/sbin/apache2[0x8082be8] [0xb7f67400] /usr/lib/apache2/modules/libphp5.so[0xb78407cf] /usr/sbin/apache2(ap_run_handler+0x57)[0x807a127] /usr/sbin/apache2(ap_invoke_handler+0x91)[0x807d4b1] /usr/sbin/apache2(ap_process_request+0x196)[0x80887e6] /usr/sbin/apache2[0x80857d8] /usr/sbin/apache2(ap_run_process_connection+0x57)[0x80814b7] /usr/sbin/apache2[0x808e6ac] /usr/lib/libapr-1.so.0[0xb7d77e8e] /lib/libpthread.so.0[0xb7d0419b] /lib/libc.so.6(clone+0x5e)[0xb7c8886e] I have to restart Apache. -- Edit this bug report at http://bugs.php.net/?id=48134&edit=1
#48163 [Csd->Bgs]: FILTER_CALLBACK generates strange results
ID: 48163 Updated by: scott...@php.net Reported By: redaction at nuxwin dot com -Status: Closed +Status: Bogus Bug Type: Filter related Operating System: debian PHP Version: 5.2.0 Previous Comments: [2009-05-06 13:53:04] redaction at nuxwin dot com ok, close it ! [2009-05-06 13:52:02] redaction at nuxwin dot com changed version [2009-05-06 13:48:17] redaction at nuxwin dot com Hi; sorry, my version is PHP Version 5.2.0. I go to try with later. If you want, you can close it. [2009-05-06 13:42:48] f...@php.net works fine for me with 5.2.9 release and CLI [2009-05-06 13:40:06] j...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Works fine for me.. 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/48163 -- Edit this bug report at http://bugs.php.net/?id=48163&edit=1
#48167 [Opn->Fbk]: undefined function checkdnsrr()
ID: 48167 Updated by: scott...@php.net Reported By: frew dot robert at gmail dot com -Status: Open +Status: Feedback Bug Type: *Network Functions Operating System: Linux PHP Version: 5.3.0RC1 New Comment: This function is only available if the configure script can find bind on your system. If you look at your config.log you'll probably find that its missing. Previous Comments: [2009-05-06 16:32:48] frew dot robert at gmail dot com Description: When using function checkdnsrr(), I get a Fatal error: Call to undefined function checkdnsrr() in test.php. You can view this error live at http://www.mxxm.com/test.php. Reproduce code: --- Expected result: True or false. Actual result: -- Fatal error: Call to undefined function checkdnsrr() -- Edit this bug report at http://bugs.php.net/?id=48167&edit=1
#48153 [Bgs]: preg_replace() crashes in function "match"
ID: 48153
Updated by: scott...@php.net
Reported By: raul dot gigea at directmedia dot de
Status: Bogus
Bug Type: PCRE related
Operating System: FreeBSD 7.1-RELEASE-p4
PHP Version: 5.2CVS-2009-05-06 (snap)
New Comment:
The mhash library is gone in 5.3 and replaced with a wrapper around the
hash library.
Can you try a 5.3 snapshot and see if you get the issue?
I should say I can't reproduce this on 5.2 on OSX with the same
configure like Jani used.
Previous Comments:
[2009-05-06 22:18:19] raul dot gigea at directmedia dot de
By the way, the mhash lib version is 0.9.9.
[2009-05-06 22:09:55] raul dot gigea at directmedia dot de
I already described this in my original bug report, but I'll try to be
more explicit:
As I described before, if I tune pcre.recursion_limit and
pcre.backtrack_limit, than I get no segfault, but neither do I get the
correct output. As an example, this code:
$contents = 'sud' . str_repeat('a', 1900) . 'bccess';
$contents = preg_replace('/d(a)+b/', '', $contents);
echo $contents
Segfaults if recursion_limit/backtrack_limit is too high. Prints
"success" if everything went well, and prints nothing if
recursion_limit is too low.
I can only get it to print nothing tuning those two parameters. ( over
backtrack_limit 2458 it crashes, below 2457 it doesn't print anything
). So it's a workaround the segfault, but you get another problem -
you don't get the wanted result.
I suspect the problem could be in the mhash library, and the way php
uses it, because it prints 'success' if I disable the mhash extension.
[2009-05-06 21:20:01] j...@php.net
You either have to increase the stack size or tune pcre.recursion_limit
and pcre.backtrack_limit properly.
[2009-05-06 21:11:12] raul dot gigea at directmedia dot de
I already wrote that my stacksize was 64 MB. ulimit -s 1024 would
reduce it to only 1 MB. 64MB is the upper limit without recompiling
the kernel. And i don't think that this specific regex should eat up
64 MB of stack size ...
Anyway, here's the result:
% ulimit -s 1024
% ulimit -s
1024
% ./sapi/cli/php ~/test.php
zsh: segmentation fault (core dumped) ./sapi/cli/php ~/test.php
% ulimit -s 65535
% ulimit -s
65535
% ./sapi/cli/php ~/test.php
zsh: segmentation fault (core dumped) ./sapi/cli/php ~/test.php
% ulimit -s 65537
ulimit: value exceeds hard limit
[2009-05-06 20:53:44] j...@php.net
You need to increase the stack size. I tried with 'ulimit -s 1024' and
that does not crash..
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/48153
--
Edit this bug report at http://bugs.php.net/?id=48153&edit=1
#48206 [Ver->Csd]: Segfault in RecursiveIteratorIterator::current()
ID: 48206 Updated by: scott...@php.net Reported By: matt at raines dot me dot uk -Status: Verified +Status: Closed Bug Type: SPL related Operating System: * PHP Version: 5.*, 6CVS (2009-05-09) 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: [2009-05-09 14:01:27] matt at raines dot me dot uk Description: If you wrap a RecursiveArrayIterator in a RecursiveIteratorIterator and iterate past the end of the array, PHP crashes. Reproduce code: --- next(); var_dump($i->current()); ?> Expected result: NULL Actual result: -- Segmentation fault (core dumped) -- Edit this bug report at http://bugs.php.net/?id=48206&edit=1
#48195 [Fbk->Asn]: iconv link failure
ID: 48195 Updated by: scott...@php.net Reported By: rickdunn at chez dot com -Status: Feedback +Status: Assigned Bug Type: Compile Failure Operating System: OS X 10.5.6 PHP Version: 5.3.0RC2 -Assigned To: +Assigned To: scottmac New Comment: The bug you linked to was fixed for 5.3.0RC2, its possible that this is what caused your issues. Did you checkout to a fresh directory? If not you might need to run ./buildconf and ./configure again. Previous Comments: [2009-05-09 21:00:21] j...@php.net Drop all this first: CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" [2009-05-09 11:53:24] rickdunn at chez dot com Up until the release of 5.3.0 RC2, I could successfully compile PHP on OS X 10.5.6. Now, 'Make' always fails with this message: Undefined symbols: "_libiconv", referenced from: __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_strpos in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 [2009-05-08 21:47:15] j...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2009-05-08 19:50:44] rickdunn at chez dot com Description: Bug #43189 has returned in 5.3 RC2. Make fails with 'undefined symbols' related to iconv. Reproduce code: --- CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/sbin/apxs --with-config-file-scan-dir=/usr/local/php5/php.d --with-ldap=/usr --with-bz2=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-soap --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets --with-iodbc=/usr --with-curl=shared,/usr --sysconfdir=/private/etc --with-mysqli=mysqlnd --with-mysql=mysqlnd --with-pdo-mysql=mysqlnd --with-openssl --with-xmlrpc --with-xsl=/usr --with-gd --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6 --enable-gd-native-ttf --with-mcrypt=shared --enable-calendar --enable-bcmath Expected result: Successful installation. Actual result: -- Make fails. -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48195 [Asn->Fbk]: iconv link failure
ID: 48195 Updated by: scott...@php.net Reported By: rickdunn at chez dot com -Status: Assigned +Status: Feedback Bug Type: Compile Failure Operating System: OS X 10.5.6 PHP Version: 5.3.0RC2 Assigned To: scottmac Previous Comments: [2009-05-09 22:45:38] scott...@php.net The bug you linked to was fixed for 5.3.0RC2, its possible that this is what caused your issues. Did you checkout to a fresh directory? If not you might need to run ./buildconf and ./configure again. [2009-05-09 21:00:21] j...@php.net Drop all this first: CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" [2009-05-09 11:53:24] rickdunn at chez dot com Up until the release of 5.3.0 RC2, I could successfully compile PHP on OS X 10.5.6. Now, 'Make' always fails with this message: Undefined symbols: "_libiconv", referenced from: __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_strpos in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 [2009-05-08 21:47:15] j...@php.net Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2009-05-08 19:50:44] rickdunn at chez dot com Description: Bug #43189 has returned in 5.3 RC2. Make fails with 'undefined symbols' related to iconv. Reproduce code: --- CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" ./configure --prefix=/usr/local/php5 --with-apxs2=/usr/sbin/apxs --with-config-file-scan-dir=/usr/local/php5/php.d --with-ldap=/usr --with-bz2=/usr --with-kerberos=/usr --enable-cli --with-zlib-dir=/usr --enable-exif --enable-soap --enable-ftp --enable-mbstring --enable-mbregex --enable-sockets --with-iodbc=/usr --with-curl=shared,/usr --sysconfdir=/private/etc --with-mysqli=mysqlnd --with-mysql=mysqlnd --with-pdo-mysql=mysqlnd --with-openssl --with-xmlrpc --with-xsl=/usr --with-gd --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/X11R6 --with-freetype-dir=/usr/X11R6 --with-xpm-dir=/usr/X11R6 --enable-gd-native-ttf --with-mcrypt=shared --enable-calendar --enable-bcmath Expected result: Successful installation. Actual result: -- Make fails. -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48195 [Fbk]: iconv link failure
ID: 48195 Updated by: scott...@php.net Reported By: rickdunn at chez dot com Status: Feedback Bug Type: Compile Failure Operating System: OS X 10.5.6 PHP Version: 5.3.0RC2 Assigned To: scottmac New Comment: Can you try with ./configure --disable-all --with-xmlrpc --enable-libxml The above configures file for me on 10.5.6. Previous Comments: [2009-05-10 17:05:53] j...@php.net Does this happen with current PHP_5_2 snapshot? (please try..) http://snaps.php.net/ [2009-05-10 12:03:51] rickdunn at chez dot com No luck. I tried running ./buildconf before ./configure and the same error occurs. I tried stripping out all of the compiler flags except for " -arch x86_64 -m64" and still get the same error. Again, this problem showed up with 5.3.0RC2. I did not have any problems with 5.3.0RC1. [2009-05-09 22:45:38] scott...@php.net The bug you linked to was fixed for 5.3.0RC2, its possible that this is what caused your issues. Did you checkout to a fresh directory? If not you might need to run ./buildconf and ./configure again. [2009-05-09 21:00:21] j...@php.net Drop all this first: CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer -arch x86_64 -m64" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti -arch x86_64 -m64" [2009-05-09 11:53:24] rickdunn at chez dot com Up until the release of 5.3.0 RC2, I could successfully compile PHP on OS X 10.5.6. Now, 'Make' always fails with this message: Undefined symbols: "_libiconv", referenced from: __php_iconv_appendl in iconv.o __php_iconv_appendl in iconv.o _php_iconv_string in iconv.o _php_iconv_string in iconv.o __php_iconv_strlen in iconv.o __php_iconv_strpos in iconv.o _zif_iconv_substr in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _zif_iconv_mime_encode in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o _php_iconv_stream_filter_append_bucket in iconv.o ld: symbol(s) not found collect2: ld returned 1 exit status make: *** [libs/libphp5.bundle] Error 1 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/48195 -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48195 [Asn]: iconv link failure
ID: 48195 Updated by: scott...@php.net Reported By: rickdunn at chez dot com Status: Assigned Bug Type: Compile Failure Operating System: OS X 10.5.6 PHP Version: 5.3.0RC2 Assigned To: scottmac New Comment: Can you apply http://whisky.macvicar.net/patches/apache2handler.patch.txt Run ./buildconf and then configure again. This should fix the issue you're having. Previous Comments: [2009-05-11 21:32:48] ajmiller at engr dot psu dot edu I had the same problem with iconv on a Mac OS X Server 10.5.6 on an iMac G5. Using compiler and linker flags CFLAGS="-arch ppc64" CCFLAGS="-arch ppc64" CXXFLAGS="-arch ppc64" LDFLAGS="-arch ppc64" export CFLAGS CXXFLAGS LDFLAGS CCFLAGS to force 64 bit and then the following configure options did produce a functioning version of the php module. ./configure '--prefix=/usr/local' '--mandir=/usr/share/man' '-- disable-all' '--with-xmlrpc' '--enable-libxml' '-- infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs' '--with- ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib- dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-exif' '--enable- ftp' '--enable-mbstring' '--enable-mbregex' '--enable-dbx' '--enable- sockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file- path=/etc' '--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql' '--with-mysqli=mysqlnd' '--with-mysql=mysqlnd' '--with-openssl' '-- with-xmlrpc' '--enable-dom' '--with-xsl=/usr' '--enable-xml' '--with- pear' I've never used --disable-all before. Does it disable everything that is not explicitly enabled? Does this exclude something that caused the link problems with iconv? Also, for mysqlnd to build, I had to edit the mysqlnd_portability.h file like I described in the bug #48198 report I submitted previously. [2009-05-11 20:57:48] rickdunn at chez dot com The problem seems to be that the 5.3 RC2 build has a problem with the "- arch x86_64" compiler flag. If I run a stripped-down configure... ./configure --disable-all --with-iconv --with-apxs2 ...I don't get any errors, but I'll end up with a 32-bit PHP module and I'm running 64-bit Apache. Compiling for 64-bit was not a problem with 5.2.x or 5.3 RC1. [2009-05-11 18:35:07] rickdunn at chez dot com I tried the 5.3-dev build at http://snaps.php.net/ and received the same error. [2009-05-10 18:38:58] scott...@php.net Can you try with ./configure --disable-all --with-xmlrpc --enable-libxml The above configures file for me on 10.5.6. [2009-05-10 17:05:53] j...@php.net Does this happen with current PHP_5_2 snapshot? (please try..) http://snaps.php.net/ 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/48195 -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48195 [Asn]: iconv link failure
ID: 48195 Updated by: scott...@php.net Reported By: rickdunn at chez dot com Status: Assigned Bug Type: Compile Failure Operating System: OS X 10.5.6 PHP Version: 5.3.0RC2 Assigned To: scottmac New Comment: Can you show me the last command it tried to run from linking? Usually you have -L/usr/lib and -L/opt/local/lib or similar. Previous Comments: [2009-05-12 15:55:11] rickdunn at chez dot com Unfortunately, no luck. I applied the patch, ran ./buildconf and then ran the following: CFLAGS="-arch x86_64" CXXFLAGS="-arch x86_64" LDFLAGS="-arch x86_64" CCFLAGS="-arch x86_64" ./configure --disable-all --with-iconv --with- apxs2 'Make' still fails with the same error. For what it's worth, I compiled 5.2.9 successfully today, so nothing seems to have changed on my computer that would cause this. [2009-05-12 02:19:30] scott...@php.net Can you apply http://whisky.macvicar.net/patches/apache2handler.patch.txt Run ./buildconf and then configure again. This should fix the issue you're having. [2009-05-11 21:32:48] ajmiller at engr dot psu dot edu I had the same problem with iconv on a Mac OS X Server 10.5.6 on an iMac G5. Using compiler and linker flags CFLAGS="-arch ppc64" CCFLAGS="-arch ppc64" CXXFLAGS="-arch ppc64" LDFLAGS="-arch ppc64" export CFLAGS CXXFLAGS LDFLAGS CCFLAGS to force 64 bit and then the following configure options did produce a functioning version of the php module. ./configure '--prefix=/usr/local' '--mandir=/usr/share/man' '-- disable-all' '--with-xmlrpc' '--enable-libxml' '-- infodir=/usr/share/info' '--with-apxs2=/usr/sbin/apxs' '--with- ldap=/usr' '--with-kerberos=/usr' '--enable-cli' '--with-zlib- dir=/usr' '--enable-trans-sid' '--with-xml' '--enable-exif' '--enable- ftp' '--enable-mbstring' '--enable-mbregex' '--enable-dbx' '--enable- sockets' '--with-iodbc=/usr' '--with-curl=/usr' '--with-config-file- path=/etc' '--sysconfdir=/private/etc' '--with-mysql-sock=/var/mysql' '--with-mysqli=mysqlnd' '--with-mysql=mysqlnd' '--with-openssl' '-- with-xmlrpc' '--enable-dom' '--with-xsl=/usr' '--enable-xml' '--with- pear' I've never used --disable-all before. Does it disable everything that is not explicitly enabled? Does this exclude something that caused the link problems with iconv? Also, for mysqlnd to build, I had to edit the mysqlnd_portability.h file like I described in the bug #48198 report I submitted previously. [2009-05-11 20:57:48] rickdunn at chez dot com The problem seems to be that the 5.3 RC2 build has a problem with the "- arch x86_64" compiler flag. If I run a stripped-down configure... ./configure --disable-all --with-iconv --with-apxs2 ...I don't get any errors, but I'll end up with a 32-bit PHP module and I'm running 64-bit Apache. Compiling for 64-bit was not a problem with 5.2.x or 5.3 RC1. [2009-05-11 18:35:07] rickdunn at chez dot com I tried the 5.3-dev build at http://snaps.php.net/ and received the same error. 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/48195 -- Edit this bug report at http://bugs.php.net/?id=48195&edit=1
#48278 [Opn->Bgs]: $ variable prefix is unneeded in most cases
ID: 48278 Updated by: scott...@php.net Reported By: zyss at mail dot zp dot ua -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Irrelevant PHP Version: 5.2.9 New Comment: Fork away, it is open source after all. Previous Comments: [2009-05-14 09:04:20] zyss at mail dot zp dot ua Description: $ character is one of the most widely used in PHP code, in most cases its use is unreasonable. I understand its historical roots, it came from Unix shell scripts (such as bash) where it was required to make interpreters "life" easier. But today's most powerful languages do not require use of variable prefix to distinguish between variable and other identifiers. There are some cases where use of $ if reasonable, for example inside strings and when calling function by name stored in a variable. In all other cases programmers are dazzled by it. I do not propose to remove $ prefix, it would be a major improvement to make it OPTIONAL (this change will not break any existing code but many people will breathe a sigh of relief). P.S. If you will continue to prefer PHP-interpreter developers' convenience over PHP-code developers' we will start our own fork of PHP to be able to add required functionality to it. -- Edit this bug report at http://bugs.php.net/?id=48278&edit=1
#48284 [Opn->Asn]: hash "adler32" byte order is reversed
ID: 48284
Updated by: scott...@php.net
Reported By: tyler dot reese at taqua dot com
-Status: Open
+Status: Assigned
Bug Type: hash related
Operating System: Windows and Linux
PHP Version: 5.2.9
-Assigned To:
+Assigned To: scottmac
Previous Comments:
[2009-05-14 16:20:44] tyler dot reese at taqua dot com
Description:
I'm using the "adler32" algorithm of the PHP hash() function. The
result that I get has the byte-order reversed from the result I get when
doing the same hash on Python.
>From the Python interpreter:
>>> import zlib
>>> hex(zlib.adler32('abc',1))
'0x24d0127'
I saw that a bug addressed this same thing for the crc32 algorithm, but
what about adler32?
Reproduce code:
---
Expected result:
24d0127
Actual result:
--
27014d02
--
Edit this bug report at http://bugs.php.net/?id=48284&edit=1
#48300 [Opn->Fbk]: crash in zif_file_put_contents
ID: 48300 Updated by: scott...@php.net Reported By: kenorb at gmail dot com -Status: Open +Status: Feedback Bug Type: *General Issues Operating System: Linux PHP Version: 5.2.9 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. The backtrace helps but the code that caused it is needed to. Previous Comments: [2009-05-16 02:03:04] kenorb at gmail dot com Description: See backtrace above. Reproduce code: --- .(gdb) backtrace #0 0x08202f0b in zif_file_put_contents (ht=147657200, return_value=0x20, return_value_ptr=0x0, this_ptr=0xafe2f6fc, return_value_used=4) at /home/redmine/php5/php-5.2.9/ext/standard/file.c:697 #1 0x0820368a in zif_tempnam (ht=32, return_value=0x4, return_value_ptr=0x0, this_ptr=0x8202ebc, return_value_used=147657200) at /home/redmine/php5/php-5.2.9/Zend/zend_variables.h:45 #2 0x08203884 in zif_popen (ht=8, return_value=0x4, return_value_ptr=0x0, this_ptr=0xafe2f6e4, return_value_used=- 1084251860) at /home/redmine/php5/php-5.2.9/ext/standard/file.c:1011 #3 0x0821d9f7 in zif_strtolower (ht=-1344080132, return_value=0xb5a74b40, return_value_ptr=0x0, this_ptr=0x820ca70, return_value_used=0) at /home/redmine/php5/php-5.2.9/ext/standard/string.c:1349 #4 0x0822aa0a in zif_is_callable (ht=-1344080156, return_value=0x8d88788, return_value_ptr=0xbf5fa128, this_ptr=0x8202ebc, return_value_used=147657200) at /home/redmine/php5/php-5.2.9/ext/standard/type.c:380 #5 0x0809de50 in is_counted_repeat (p=0x20 ) at /home/redmine/php5/php- 5.2.9/ext/pcre/pcrelib/pcre_compile.c:887 #6 0x0809bb2d in verify_callback (preverify_ok=-1084251808, ctx=0xafe2f6e4) at /home/redmine/php5/php- 5.2.9/ext/openssl/openssl.c:3759 Expected result: working Actual result: -- crashing (gdb) backtrace #0 0x08202f0b in zif_file_put_contents (ht=147657200, return_value=0x20, return_value_ptr=0x0, this_ptr=0xafe2f6fc, return_value_used=4) at /home/redmine/php5/php-5.2.9/ext/standard/file.c:697 #1 0x0820368a in zif_tempnam (ht=32, return_value=0x4, return_value_ptr=0x0, this_ptr=0x8202ebc, return_value_used=147657200) at /home/redmine/php5/php-5.2.9/Zend/zend_variables.h:45 #2 0x08203884 in zif_popen (ht=8, return_value=0x4, return_value_ptr=0x0, this_ptr=0xafe2f6e4, return_value_used=- 1084251860) at /home/redmine/php5/php-5.2.9/ext/standard/file.c:1011 #3 0x0821d9f7 in zif_strtolower (ht=-1344080132, return_value=0xb5a74b40, return_value_ptr=0x0, this_ptr=0x820ca70, return_value_used=0) at /home/redmine/php5/php-5.2.9/ext/standard/string.c:1349 #4 0x0822aa0a in zif_is_callable (ht=-1344080156, return_value=0x8d88788, return_value_ptr=0xbf5fa128, this_ptr=0x8202ebc, return_value_used=147657200) at /home/redmine/php5/php-5.2.9/ext/standard/type.c:380 #5 0x0809de50 in is_counted_repeat (p=0x20 ) at /home/redmine/php5/php- 5.2.9/ext/pcre/pcrelib/pcre_compile.c:887 #6 0x0809bb2d in verify_callback (preverify_ok=-1084251808, ctx=0xafe2f6e4) at /home/redmine/php5/php- 5.2.9/ext/openssl/openssl.c:3759 #7 0x08d88788 in ?? () #8 0xbf5fa12c in ?? () #9 0xb5a74b20 in ?? () #10 0xb5b21ddc in ?? () #11 0xafe2f6a4 in ?? () #12 0xb5b09044 in ?? () #13 0xafe2f6e4 in ?? () #14 0x08cd11f0 in ?? () #15 0x0010 in ?? () #16 0x0009 in ?? () #17 0xafe2f6cc in ?? () #18 0xb5b21ddc in ?? () #19 0xb5a74b40 in ?? () #20 0xbf5fa178 in ?? () -- Edit this bug report at http://bugs.php.net/?id=48300&edit=1
#48361 [Opn->Ver]: SplFileInfo::getPathinfo no returning info of path
ID: 48361 Updated by: scott...@php.net Reported By: petercowburn at gmail dot com -Status: Open +Status: Verified Bug Type: SPL related Operating System: OS X PHP Version: 5.3.0RC2 -Assigned To: +Assigned To: colder Previous Comments: [2009-05-22 10:30:21] petercowburn at gmail dot com Description: It appears that using PHP5.3.0RC2-dev the SplFileInfo::getPathinfo method just returns the SplFileInfo object on which it was called rather than an SplFileInfo object for its path. Reproduce code: --- getPathInfo(); var_dump($parent_info->getRealPath()); ?> Expected result: string(8) "/usr/bin" Actual result: -- string(12) "/usr/bin/php" -- Edit this bug report at http://bugs.php.net/?id=48361&edit=1
#48380 [Opn->Bgs]: Class is passed as reference in array?
ID: 48380
Updated by: scott...@php.net
Reported By: catalint at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 5.2.9
New Comment:
Objects are always passed by reference.
Previous Comments:
[2009-05-25 08:27:01] catalint at gmail dot com
Description:
Class is passed as reference in array ?
Reproduce code:
---
$a= new stdClass();
$test=array();
for ($i=0;$i<5;$i++){
$a->i=$i;
$test[]=$a;
}
print_r($test);
Expected result:
Array
(
[0] => stdClass Object
(
[i] => 0
)
[1] => stdClass Object
(
[i] => 1
)
[2] => stdClass Object
(
[i] => 2
)
[3] => stdClass Object
(
[i] => 3
)
[4] => stdClass Object
(
[i] => 4
)
)
Actual result:
--
Array
(
[0] => stdClass Object
(
[i] => 4
)
[1] => stdClass Object
(
[i] => 4
)
[2] => stdClass Object
(
[i] => 4
)
[3] => stdClass Object
(
[i] => 4
)
[4] => stdClass Object
(
[i] => 4
)
)
--
Edit this bug report at http://bugs.php.net/?id=48380&edit=1
#48378 [Opn]: exif_read_data() segfaults on certain corrupted .jpeg files
ID: 48378 Updated by: scott...@php.net Reported By: phpbug dot exif at sub dot noloop dot net Status: Open Bug Type: EXIF related Operating System: Linux PHP Version: 5.2CVS-2009-05-24 (snap) New Comment: I can confirm here on OSX. #0 0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:1088 1088return (((uchar *)value)[1] << 8) | ((uchar *)value)[0]; (gdb) bt #0 0x00033397 in php_ifd_get16u (value=0x7100b1, motorola_intel=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:1088 #1 0x00037a01 in exif_process_IFD_in_JPEG (ImageInfo=0xbfffef8c, dir_start=0x7100b1 , offset_base=0x3100a8 "II*", IFDlength=126, displacement=12, section_index=3) at /Users/scott/dev/php5_2/ext/exif/exif.c:3140 #2 0x00037d92 in exif_process_TIFF_in_JPEG (ImageInfo=0xbfffef8c, CharBuf=0x3100a8 "II*", length=126, displacement=12) at /Users/scott/dev/php5_2/ext/exif/exif.c:3221 #3 0x00037e92 in exif_process_APP1 (ImageInfo=0xbfffef8c, CharBuf=0x3100a0 "", length=134, displacement=4) at /Users/scott/dev/php5_2/ext/exif/exif.c:3246 #4 0x000384d2 in exif_scan_JPEG_header (ImageInfo=0xbfffef8c) at /Users/scott/dev/php5_2/ext/exif/exif.c:3385 #5 0x000393c4 in exif_scan_FILE_header (ImageInfo=0xbfffef8c) at /Users/scott/dev/php5_2/ext/exif/exif.c:3757 #6 0x0003a073 in exif_read_file (ImageInfo=0xbfffef8c, FileName=0x30d2d4 "hello-s148.jpeg", read_thumbnail=0, read_all=0) at /Users/scott/dev/php5_2/ext/exif/exif.c:3902 Previous Comments: [2009-05-25 20:49:59] phpbug dot exif at sub dot noloop dot net That's odd. I'm getting 100% reproducible crash on both the latest 5.2 cvs snapshot, as well as the php build included in Debian Linux 5.0.1 (stable) (which is 5.2.6+some debian patches) I'm using Linux 2.6.29.4, Debian 5.0.1, gcc version 4.3.2 (Debian 4.3.2-1.1) on an i686 (32bit) machine with 3gb ram. To compile, I did: './configure' '--prefix=/home/frode/temp/z/zinst3' '--disable-all' '--enable-exif' make cli Are you running on 64bit, or perhaps some other distro with a different version of gcc etc? [2009-05-25 19:59:23] il...@php.net I am getting the following error messages, but no crash: Warning: exif_read_data(hello-s148.jpeg): Illegal IFD size: x4B + 2 + x*12 = x4B > x007E in exif.php on line 2 Warning: exif_read_data(hello-s148.jpeg): Error reading from file: got=x08B4(=2228) != itemlen-2=x1FFE(=8190) in exif.php on line 2 Warning: exif_read_data(hello-s148.jpeg): Invalid JPEG file in exif.php on line 2 [2009-05-24 20:58:14] phpbug dot exif at sub dot noloop dot net Description: There seems to be a problem in exif_read_data(), where some fields representing offsets(?) are taken directly from the file without being validated, resulting in a segmentation fault. I originally found this issue by fooling around with the "zzuf" fuzzer, and reported a very similar bug in the "jhead" exif utility at http://bugs.debian.org/530401 Original image can be found at: http://www.noloop.net/bugs/php/001-exif/hello.jpeg Corrupted image can be found at: http://www.noloop.net/bugs/php/001-exif/hello-s148.jpeg Reproduce code: --- , offset_base=0x8ef76b8 "II*", IFDlength=15055, displacement=30, section_index=3) at /home/frode/temp/z/z3/php5.2-200905241830/ext/exif/exif.c:1088 1088return (((uchar *)value)[1] << 8) | ((uchar *)value)[0]; (gdb) up #1 0x0808e6ca in exif_read_file (ImageInfo=0xbfc893b8, FileName=, read_thumbnail=, read_all=0) at /home/frode/temp/z/z3/php5.2-200905241830/ext/exif/exif.c:3221 3221exif_process_IFD_in_JPEG(ImageInfo, CharBuf+offset_of_ifd, CharBuf, length/*-14*/, displacement, SECTION_IFD0 TSRMLS_CC); Note the "dir_start" address being out of bounds, which causes the "((uchar *)value)[1]" to segfault. (The function names are a bit confusing, maybe it's because of method inlining?) -- Edit this bug report at http://bugs.php.net/?id=48378&edit=1
#48276 [Opn]: date('Y') returns 0000
ID: 48276
Updated by: scott...@php.net
Reported By: info at programmiernutte dot net
Status: Open
Bug Type: Date/time related
Operating System: Mac OS X 10.4 PPC
PHP Version: 5.3.0RC2
New Comment:
We have a PPC test machine, Derick has access and I can set up other
accounts if needed.
Previous Comments:
[2009-05-28 00:45:05] ras...@php.net
So there is an endian issue somewhere. How are you with gdb? Could
you set a breakpoint on the function and work your way through it and
figure out where it goes south?
[2009-05-28 00:40:27] info at programmiernutte dot net
I just verified the issue unter Linux PPC, Debian Lenny PPC to be
specific.
[2009-05-27 23:07:35] info at programmiernutte dot net
PPC or Intel? I tested this on 10.4 and 10.5 on PPC with the same
results.
[2009-05-27 22:00:56] j at teamonetickets dot com
I cannot reproduce this on OS X 10.5.7 with PHP 5.3.0RC2.
$oDateTime = new DateTime();
print_r($oDateTime);
Result:
DateTime Object
(
[date] => 2009-05-27 14:57:33
[timezone_type] => 3
[timezone] => America/Phoenix
)
echo date('y');
Result:
09
echo date('Y');
Result:
2009
[2009-05-25 05:37:39] der...@php.net
I still can't reproduce this, and I still don't have access to this
platform.
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/48276
--
Edit this bug report at http://bugs.php.net/?id=48276&edit=1
#48416 [Opn->Fbk]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr -Status: Open +Status: Feedback Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. Previous Comments: [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48416 [Fbk->Csd]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr -Status: Feedback +Status: Closed Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 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. Added a LRU and a cache limit to the ereg code for 5.3. Give it a few hours and grab another 5.3 snapshot, not sure about fixing this in 5.2. Will check with ilia. Previous Comments: [2009-05-28 18:17:49] bmorel at ssi dot fr Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev : php5.3-200905281630). The cache seems to be a good explanation, but it this a good idea ? I have millions of ereg()s done when I parse huge XML files (several GB), and my memory usage goes too high. I had to replace all my ereg()s with preg_match()s. Thanks, Ben [2009-05-28 17:30:21] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48416 [Csd]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr Status: Closed Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: Fixed in 5.2 as well now. Previous Comments: [2009-05-28 21:58:10] scott...@php.net 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. Added a LRU and a cache limit to the ereg code for 5.3. Give it a few hours and grab another 5.3 snapshot, not sure about fixing this in 5.2. Will check with ilia. [2009-05-28 18:17:49] bmorel at ssi dot fr Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev : php5.3-200905281630). The cache seems to be a good explanation, but it this a good idea ? I have millions of ereg()s done when I parse huge XML files (several GB), and my memory usage goes too high. I had to replace all my ereg()s with preg_match()s. Thanks, Ben [2009-05-28 17:30:21] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. [2009-05-28 16:57:59] bmorel at ssi dot fr Description: When repeating an ereg() or eregi() on different patterns, the memory usage of httpd (or php if executed from the command-line) gets huge (about 1GB for the example below) for the time the script executes, then the memory is freed. During this time, the memory_get_usage() stays normal, and php's memory limit doesn't trigger. When repeating the ereg() with the same pattern each time, the memory usage stays normal; this happens only when repeating with a different pattern each time. Verified on CentOS with PHP 5.2.6 & 5.2.9 Verified on Windows XP with PHP 5.2.8 Reproduce code: --- Expected result: Memory usage staying low. Actual result: -- Memory usage as shown by "top -d 1" gets huge. -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48427 [Opn->Bgs]: Make install libphp5.so error
ID: 48427 Updated by: scott...@php.net Reported By: AzureusPT at gmail dot com -Status: Open +Status: Bogus Bug Type: *Compile Issues Operating System: AIX 5.3 PHP Version: 5.2.9 New Comment: See bug #39197 Previous Comments: [2009-05-29 08:13:13] AzureusPT at gmail dot com Description: I've been trying to compile and install PHP5 (using 5.2.9 as well as latest CVS) with Apache 2.2.11, but I'm getting an error upon make install. ERROR: Installing PHP SAPI module: apache2handler /opt/jakarta/apache2.2/build/instdso.sh SH_LIBTOOL='/opt/jakarta/apache2.2/build/libtool' libphp5.la /opt/jakarta/apache2.2/modules rm -f /opt/jakarta/apache2.2/modules/libphp5.so /opt/jakarta/apache2.2/build/libtool --mode=install cp libphp5.la /opt/jakarta/apache2.2/modules/ cp .libs/libphp5.a /opt/jakarta/apache2.2/modules/libphp5.a cp .libs/libphp5.lai /opt/jakarta/apache2.2/modules/libphp5.la libtool: install: warning: remember to run `libtool --finish /soflib00/user/tomcat/php5.2-200905290630/libs' chmod 755 /opt/jakarta/apache2.2/modules/libphp5.so chmod: /opt/jakarta/apache2.2/modules/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 . make: 1254-004 The error code from the last command is 1. It seems it deletes libphp5.so but doesnt copy the new lib, so it exits when trying to chmod an unexistent file. CONFIGURE OPTIONS: ./configure --with-apxs2=/opt/jakarta/apache2.2/bin/apxs --prefix=/opt/jakarta/php5.2.9 --with-libxml-dir=/usr/lib CVS SNAPSHOT: php5.2-200905290630 OS: AIX 5.3 LIBTOOL VERSION libtool --version ltmain.sh (GNU libtool) 1.5.20 (1.1220.2.287 2005/08/31 18:54:15) APACHE VERSION: httpd-2.2.11 GCC VERSION: gcc --version gcc (GCC) 4.2.0 Checked other similar bugs, but the solutions of them doesnt seem to work for me. Reproduce code: --- ./configure --with-apxs2=/opt/jakarta/apache2.2/bin/apxs --prefix=/opt/jakarta/php5.2.9 --with-libxml-dir=/usr/lib ; make ; make install Expected result: PHP 5 should be installed Actual result: -- chmod 755 /opt/jakarta/apache2.2/modules/libphp5.so chmod: /opt/jakarta/apache2.2/modules/libphp5.so: A file or directory in the path name does not exist. apxs:Error: Command failed with rc=65536 -- Edit this bug report at http://bugs.php.net/?id=48427&edit=1
#48416 [Opn->Csd]: Memleak in ereg() and eregi() functions
ID: 48416 Updated by: scott...@php.net Reported By: bmorel at ssi dot fr -Status: Open +Status: Closed Bug Type: Regexps related Operating System: CentOS 5.3 PHP Version: 5.2.9 New Comment: I just downloaded a snapshot of 5.2 to check and its definitely fixed. Memory peaks at 4mb, you must be doing something wrong. Previous Comments: [2009-05-29 21:39:03] bmorel at ssi dot fr Thanks, but the problem is still there in the latest snapshots. Just verified it on : php5.2-200905292030 php5.3-200905292030 php6.0-200905292030 Memory usage still gets so high ! Ben [2009-05-29 00:06:16] scott...@php.net Fixed in 5.2 as well now. [2009-05-28 21:58:10] scott...@php.net 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. Added a LRU and a cache limit to the ereg code for 5.3. Give it a few hours and grab another 5.3 snapshot, not sure about fixing this in 5.2. Will check with ilia. [2009-05-28 18:17:49] bmorel at ssi dot fr Sorry, same problem with this snapshot (PHP 5.3.0RC3-dev : php5.3-200905281630). The cache seems to be a good explanation, but it this a good idea ? I have millions of ereg()s done when I parse huge XML files (several GB), and my memory usage goes too high. I had to replace all my ereg()s with preg_match()s. Thanks, Ben [2009-05-28 17:30:21] scott...@php.net Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ Pretty sure this is due to the regular expression cache we have, each unique regular expression is cached so we don't keep compiling it but there is no cap on the number we store. Can you try a 5.3 snapshot, I think we switched from using ereg to pcre with 5.3. 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/48416 -- Edit this bug report at http://bugs.php.net/?id=48416&edit=1
#48432 [Opn->Bgs]: (?{CODE}) pattern not recognized, won't compile expression
ID: 48432
Updated by: scott...@php.net
Reported By: webmaster at adurosolutions dot com
-Status: Open
+Status: Bogus
Bug Type: PCRE related
Operating System: CentOs
PHP Version: 5.2.9
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
The manual clearly states we don't support this.
Fairly obviously, PCRE does not support the (?{code}) and (??{code})
construction. However, there is support for recursive patterns.
Previous Comments:
[2009-05-30 07:56:15] webmaster at adurosolutions dot com
Description:
The (?{CODE}) regular expression has been in Perl since <= 5.005, and
the PHP documentation for PCRE says that it's current as of 5.005. This
functionality does not appear to be functional in PHP 5.2.9.
Reproduce code:
---
[^()]*))*(?(?{$d!=0})(?!))$/';
$pattern_simple = '/^(?{$d=0})\(/';
$subject = '((I)(like(pie))!)';
echo "result: ".preg_match($pattern, $subject)."";
echo "result_simple: ".preg_match($pattern_simple, $subject)."";
?>
Expected result:
I'm not claiming that the regular expressions should produce a match,
but they should compile and be evaluated, and thus return either a 0 or
a 1.
Actual result:
--
Warning: preg_match() [function.preg-match]: Compilation failed:
unrecognized character after (? or (?- at offset 2 in __FILE__ on line
__LINE__
--
Edit this bug report at http://bugs.php.net/?id=48432&edit=1
#48434 [Opn->Bgs]: memory function
ID: 48434 Updated by: scott...@php.net Reported By: busia at tiscali dot it -Status: Open +Status: Bogus Bug Type:Feature/Change Request PHP Version: 5.3.0RC2 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. It's already there. memory_get_usage() and memory_get_usage(true) Previous Comments: [2009-05-30 09:33:08] busia at tiscali dot it Description: You said me (#48368) that unset != free. The memory can remain occupied also after I unset an array, that memory is reused when I set a new variable and, for this reason, it's not a leak. Ok, now it's clear but a problem remains: how can I optimize my code when I cannot see the php internal memory use? I need a function like: memory_get_usage() - memory_allocated_but_usable_for_newly_created_variables(); Setting a variable and seeing that memory use don't change make scripts impossible to optimize. Thanks -- Edit this bug report at http://bugs.php.net/?id=48434&edit=1
#48434 [Bgs]: memory function
ID: 48434 Updated by: scott...@php.net Reported By: busia at tiscali dot it Status: Bogus Bug Type:Feature/Change Request PHP Version: 5.3.0RC2 New Comment: memory_get_usage(true) is the memory allocated from the system. memory_get_usage() is the memory currently in use by PHP. 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. It's already there. memory_get_usage() and memory_get_usage(true) [2009-05-30 09:33:08] busia at tiscali dot it Description: You said me (#48368) that unset != free. The memory can remain occupied also after I unset an array, that memory is reused when I set a new variable and, for this reason, it's not a leak. Ok, now it's clear but a problem remains: how can I optimize my code when I cannot see the php internal memory use? I need a function like: memory_get_usage() - memory_allocated_but_usable_for_newly_created_variables(); Setting a variable and seeing that memory use don't change make scripts impossible to optimize. Thanks -- Edit this bug report at http://bugs.php.net/?id=48434&edit=1
#48435 [Opn->Bgs]: convertion of filename.eps to filename.jpg is not clear
ID: 48435
Updated by: scott...@php.net
Reported By: guru dot indian at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: GD related
Operating System: windows xp
PHP Version: 5.2.9
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.
This is ImageMagick you are using, nothing to do with PHP here.
Previous Comments:
[2009-05-30 11:25:35] guru dot indian at gmail dot com
Description:
Dear sir/madam,
I did a image processing project using PHP GD library, in which i need
to convert a image file with extension filename.eps to jpg, I used
exec(convert path/to/sourcefile.eps path/to/dest.jpg) command. This
process converts RGB color format successfully but the eps file is in
CMYK color format which doesnt converts good. The output file is in
different color (seems to be inverted color). I think this is a bug.
please take necessary action to correct this problem in future versions
of php. Hence first i converted the eps file to pdf, and then i
converted the pdf to jpg. this somehow gave a little relevant output.
Regards
Guru
Reproduce code:
---
---
>From manual page: function.convert
---
exec("convert filename.eps -colorspace CMYK -quality 100
filename.jpg");
The image is in CMYK color format
Expected result:
The color of the eps file is magenta but the output is with green
colored image.
Actual result:
--
Need same color of image during conversion.
--
Edit this bug report at http://bugs.php.net/?id=48435&edit=1
#48434 [Bgs]: memory function
ID: 48434
Updated by: scott...@php.net
Reported By: busia at tiscali dot it
Status: Bogus
Bug Type:Feature/Change Request
PHP Version: 5.3.0RC2
New Comment:
What aren't you understanding?
memory_get_usage(true) = memory allocated to process from system
memory_get_usage() = memory actually in use for PHP
Therefore
memory_get_usage(true) - memory_get_usage()
That's the memory that has been allocated from the system but isn't
used for variables yet.
Previous Comments:
[2009-05-30 13:00:52] busia at tiscali dot it
I unsderstand what you say but my request is different: when I posted
bug #48368, j...@php.net answered me:
unset != free. The memory is freed once the process shuts down. Until
that, it's available inside the process. This is not a leak.
I need a function that tell me the amount of this memory "available
inside the process" or even better the difference between
memory_get_usage() and this memory "available inside the process".
I don't think this is bogus, i think this must be an "open" feature
request.
Thanks
[2009-05-30 12:23:24] lbarn...@php.net
scott you are right, however it seems the behavior differs a bit when
unset()ing small-enough variables.
memory_get_usage(false) does not takes into account the "small blocks
cache" used by the allocator (not the same as the malloc()ed blocks
cache).
This causes the reported memory usage to not always decrease when
unset()ing a variable:
int(91448) <-- first call
int(91696) <-- before unset
int(91696) <-- after unset (== before unset)
This patch may fix this:
Index: Zend/zend_alloc.c
===
RCS file: /repository/ZendEngine2/zend_alloc.c,v
retrieving revision 1.144.2.3.2.43.2.23
diff -u -p -r1.144.2.3.2.43.2.23 zend_alloc.c
--- Zend/zend_alloc.c 1 Apr 2009 16:55:47 - 1.144.2.3.2.43.2.23
+++ Zend/zend_alloc.c 30 May 2009 12:12:48 -
@@ -2496,7 +2496,11 @@ ZEND_API size_t zend_memory_usage(int re
if (real_usage) {
return AG(mm_heap)->real_size;
} else {
- return AG(mm_heap)->size;
+ size_t usage = AG(mm_heap)->size;
+#if ZEND_MM_CACHE
+ usage -= AG(mm_heap)->cached;
+#endif
+ return usage;
}
}
[2009-05-30 11:42:31] scott...@php.net
memory_get_usage(true) is the memory allocated from the system.
memory_get_usage() is the memory currently in use by PHP.
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.
It's already there.
memory_get_usage() and memory_get_usage(true)
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/48434
--
Edit this bug report at http://bugs.php.net/?id=48434&edit=1
#48464 [Ver->Opn]: No regexp match in utf8 mode
ID: 48464
Updated by: scott...@php.net
Reported By: daniel at poradnik-webmastera dot com
-Status: Verified
+Status: Open
Bug Type: PCRE related
-Operating System: *
+Operating System: windows xp
-PHP Version: 5.* (2009-06-01)
+PHP Version: 5.2.9
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.
Check preg_last_error() it will return PREG_BAD_UTF8_ERROR
\xab isn't valid UTF-8, however \xc2\xab is. It should be 2 bytes.
Previous Comments:
[2009-06-03 20:49:19] j...@php.net
Works in HEAD.
[2009-06-03 20:48:44] nlop...@php.net
$str is not a valid UTF-8 string, and thus the pcre engine rejects it.
no bug here.
[2009-06-03 17:50:59] daniel at poradnik-webmastera dot com
Description:
preg_match() doesn't match string when utf-8 mode is enabled and 0xAB
char ("«") is present in input. Everything works correctly when
utf-8 mode is disabled.
Reproduce code:
---
Expected result:
'Match' printed
Actual result:
--
'No match' printed
--
Edit this bug report at http://bugs.php.net/?id=48464&edit=1
#48464 [Asn->Bgs]: No regexp match in utf8 mode
ID: 48464 Updated by: scott...@php.net Reported By: daniel at poradnik-webmastera dot com -Status: Assigned +Status: Bogus Bug Type: PCRE related Operating System: windows xp PHP Version: 5.2.9 Assigned To: nlopess New Comment: In PHP6 \xab is a codepoint, in anything below its binary. Previous Comments: [2009-06-03 21:14:51] nlop...@php.net I don't have PHP 6 compiled at hand, but I assume that PHP 6 is replacing the bad char before sending the string to pcre. Can you check if it's the case by printing $str? [2009-06-03 21:00:20] j...@php.net Nuno, how come the script says "match" with HEAD? [2009-06-03 20:49:50] scott...@php.net 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. Check preg_last_error() it will return PREG_BAD_UTF8_ERROR \xab isn't valid UTF-8, however \xc2\xab is. It should be 2 bytes. [2009-06-03 20:49:19] j...@php.net Works in HEAD. [2009-06-03 20:48:44] nlop...@php.net $str is not a valid UTF-8 string, and thus the pcre engine rejects it. no bug here. 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/48464 -- Edit this bug report at http://bugs.php.net/?id=48464&edit=1
#48501 [Opn->Csd]: Crash with preg_replace_callback
ID: 48501
Updated by: scott...@php.net
Reported By: cobexer at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PCRE related
Operating System: Linux/openSuSE 11.1
PHP Version: 5.2.9
New Comment:
This was only fixed in 5.3, I've now backported it to 5.2.
Previous Comments:
[2009-06-08 21:38:04] cobexer at gmail dot com
after submitting I found a similar bug ... #44214
but that one is closed and seems to be "fixed" since one year now...
[2009-06-08 21:33:44] cobexer at gmail dot com
Description:
when i tried to match nested patterns my apache2 with php crashed -
however for similar inputs a very similar regular expression is in use
and causes no problems... (but the crash seems to be related to the
number of nesting levels)
Reproduce code:
---
crash
$match=
"{IF(a)}if{IF(a)}fi{IF(a)}if{ELSE}else{/IF}{ELSE}else{IF(a)}if{ELSE}else{/IF}{/IF}{ELSE}else{IF(a)}if{ELSE}else{IF(a)}if{ELSE}else{/IF}{/IF}{/IF}";
//shorter test string -> still crash, but if 1 remove the first nested
{IF... it doesnt crash any more
$match=
"{IF(a)}if{IF(a)}fi{ELSE}else{/IF}{ELSE}else{IF(a)}if{ELSE}else{/IF}{/IF}";
$reg= '/\{IF\((.*)\)\}([^\{]+?)(\{ELSE\})?([^\{]*?)(\{\/IF\})/Us';
$matches= array();
function cback($t) { global $matches; $matches[]= $t; return '';}
preg_replace_callback($reg, 'cback', $match);
var_dump($matches);
?>
Expected result:
array with the mathes of the regExp correctly nested... but i was in
the stage of designing the regular expression itself - at least i did
not expect a crash...
Actual result:
--
Apache/2.2.10 (php loaded as module) error_log:
without 3rd party extensions:
[notice] child pid 11335 exit signal Segmentation fault (11)
with XDebug enabled:
[error] [client 127.0.0.1] ALERT - possible memory corruption detected
- unknown Hashtable destructor (attacker '127.0.0.1', file
'/path/file.php')
when running php from the command line (no crash -> no backtrace):
$ php reproduce.php #same content as the code posted above!
array(2) {
[0]=>
*RECURSION*
[1]=>
*RECURSION*
}
ALERT - possible memory corruption detected - unknown Hashtable
destructor (attacker 'REMOTE_ADDR not set', file 'unknown')
--
Edit this bug report at http://bugs.php.net/?id=48501&edit=1
#48500 [Asn->Csd]: mysqli::init() memory leaks
ID: 48500 Updated by: scott...@php.net Reported By: fel...@php.net -Status: Assigned +Status: Closed Bug Type: MySQLi related Operating System: Linux PHP Version: 5.2CVS-2009-06-08 (CVS) Assigned To: mysql New Comment: It's related to bug #46019 I've backported this to 5.2. Previous Comments: [2009-06-08 20:04:03] fel...@php.net It's just reproduceable in 5.2. [2009-06-08 20:03:19] fel...@php.net Description: See below: Reproduce code: --- $x = new mysqli; $x->init();$x->init(); Expected result: No mem. leaks Actual result: -- [Mon Jun 8 16:59:13 2009] Script: '../bug.php' /home/felipe/dev/php5_2/ext/mysqli/mysqli_api.c(1102) : Freeing 0x09CAA2A0 (16 bytes), script=../bug.php /home/felipe/dev/php5_2/Zend/zend_alloc.c(2391) : Actual location (location was relayed) [Mon Jun 8 16:59:13 2009] Script: '../bug.php' /home/felipe/dev/php5_2/ext/mysqli/mysqli_api.c(1109) : Freeing 0x09CAB160 (12 bytes), script=../bug.php /home/felipe/dev/php5_2/Zend/zend_alloc.c(2391) : Actual location (location was relayed) === Total 2 memory leaks detected === -- Edit this bug report at http://bugs.php.net/?id=48500&edit=1
#48500 [Csd]: mysqli::init() memory leaks
ID: 48500 Updated by: scott...@php.net Reported By: fel...@php.net Status: Closed Bug Type: MySQLi related Operating System: Linux PHP Version: 5.2CVS-2009-06-08 (CVS) New Comment: I meant bug #46109, the commit message is wrong for the original fix. Previous Comments: [2009-06-09 01:01:17] scott...@php.net It's related to bug #46019 I've backported this to 5.2. [2009-06-08 20:04:03] fel...@php.net It's just reproduceable in 5.2. [2009-06-08 20:03:19] fel...@php.net Description: See below: Reproduce code: --- $x = new mysqli; $x->init();$x->init(); Expected result: No mem. leaks Actual result: -- [Mon Jun 8 16:59:13 2009] Script: '../bug.php' /home/felipe/dev/php5_2/ext/mysqli/mysqli_api.c(1102) : Freeing 0x09CAA2A0 (16 bytes), script=../bug.php /home/felipe/dev/php5_2/Zend/zend_alloc.c(2391) : Actual location (location was relayed) [Mon Jun 8 16:59:13 2009] Script: '../bug.php' /home/felipe/dev/php5_2/ext/mysqli/mysqli_api.c(1109) : Freeing 0x09CAB160 (12 bytes), script=../bug.php /home/felipe/dev/php5_2/Zend/zend_alloc.c(2391) : Actual location (location was relayed) === Total 2 memory leaks detected === -- Edit this bug report at http://bugs.php.net/?id=48500&edit=1
#48493 [Opn->Csd]: spl_autoload_unregister() removes all autoloaded methods when prepending
ID: 48493
Updated by: scott...@php.net
Reported By: craig dot marvelley at boxuk dot com
-Status: Open
+Status: Closed
Bug Type: SPL related
Operating System: Windows XP
PHP Version: 5.3.0RC2
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:
[2009-06-08 08:20:05] craig dot marvelley at boxuk dot com
Description:
The spl_autoload_register function was recently modified (I don't think
it's documented, though) to allow the pre-pending of functions to the
stack (see bug #42823).
I'm using pre-pending and am later trying to remove a registered
function from the end of the stack. This removes ALL methods, not just
the method I'd intended.
Reproduce code:
---
function autoload1() {}
function autoload2() {}
spl_autoload_register('autoload2');
// register autoload1 at the bottom of the stack
spl_autoload_register('autoload1', true, true);
// Output: Array ( [0] => autoload1 [1] => autoload2 )
print_r(spl_autoload_functions());
// unregister autoload2 - autoload1 _should_ be left behind
spl_autoload_unregister('autoload2');
Expected result:
When running spl_autoload_functions(), I'd expect a single entry to be
left: array([0] => 'autoload1');
Actual result:
--
The array is empty: array();
--
Edit this bug report at http://bugs.php.net/?id=48493&edit=1
#48483 [Opn->Bgs]: this pointer is not passed by reference correctly
ID: 48483
Updated by: scott...@php.net
Reported By: chase at circleofmoms dot com
-Status: Open
+Status: Bogus
Bug Type: Class/Object related
Operating System: ubuntu 8.04
PHP Version: 5.2.9
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You can't re-assign $this, ever. It prints an error normally but when
references are used it can't be properly detected.
Try the following and see the error.
data = "foo";
$thing->updateData("bar");
Previous Comments:
[2009-06-06 00:39:04] chase at circleofmoms dot com
Description:
When you pass the $this pointer by reference and change data for the
object it points to, that data is not correctly updated.
Reproduce code:
---
function changeAddress(&$oldThing) {
$oldThing = new Thing();
}
class Thing {
var $data;
public function updateData($newData) {
ThingChanger::changeData($this,$newData);
var_dump($this);
var_dump($this->data);
}
}
class ThingChanger {
public static function changeData(&$thingToChange,$newData) {
changeAddress($thingToChange);
$thingToChange->data = $newData;
}
}
$thing = new Thing();
$thing->data = "foo";
$thing->updateData("bar");
Expected result:
object(Thing)#2 (1) {
["data"]=>
string(3) "bar"
}
string(3) "bar"
Actual result:
--
object(Thing)#2 (1) {
["data"]=>
string(3) "bar"
}
string(3) "foo"
--
Edit this bug report at http://bugs.php.net/?id=48483&edit=1
#48484 [Opn->Ver]: array_product(array()) returns 0 instead of 1
ID: 48484
Updated by: scott...@php.net
Reported By: zhalassy at loginet dot hu
-Status: Open
+Status: Verified
Bug Type: Math related
Operating System: *
PHP Version: 5.2.9
New Comment:
The current behavior was set in bug #35014, pretty sure we should
change it as you suggest.
Confirming for now.
Previous Comments:
[2009-06-06 11:34:20] zhalassy at loginet dot hu
http://en.wikipedia.org/wiki/Identity_element
An identity with respect to addition is called an additive identity
(often denoted as 0) and an identity with respect to multiplication is
called a multiplicative identity (often denoted as 1). The distinction
is used most often for sets that support both binary operations, such as
rings. The multiplicative identity is often called the unit [...]
http://en.wikipedia.org/wiki/Unital
In mathematics, an algebra is unital (some authors say unitary) if it
contains a multiplicative identity element (or unit), i.e. an element 1
with the property 1x = x1 = x for all elements x of the algebra.
http://en.wikipedia.org/wiki/Empty_product
[2009-06-06 11:22:13] zhalassy at loginet dot hu
Description:
array_product(array()) returns 0 instead of 1. Empty product is 1
(hence "1" is neutral in multiplication) in mathematics.
Example:
array_product(array(1,2)) * array_product(array(3,4)) === /* should be
*/ array_product(array()) * array_product(array(1,2,3,4));
example implementation:
function array_product($array){
$product = 1;
foreach($array as $element) $product *= $element;
return $product;
}
Reproduce code:
---
echo product_array(array());
Expected result:
It should return 1.
Actual result:
--
It returns 0.
--
Edit this bug report at http://bugs.php.net/?id=48484&edit=1
#48479 [Opn->Bgs]: enable-zend-multibyte breaks compilation
ID: 48479 Updated by: scott...@php.net Reported By: gabriel at e-radical dot ro -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Centos 5.3 PHP Version: 5.3.0RC2 New Comment: Duplicate of bug #48200 Previous Comments: [2009-06-05 11:30:47] gabriel at e-radical dot ro Description: If you use --enable-zend-multibyte the compiles exists. Reproduce code: --- ./configure --cache-file=../php-5.3.0RC2.cache --with-apxs2 \ --with-gd --enable-gd-native-ttf --with-gettext --enable-ftp \ --enable-soap --with-curl --with-zlib --enable-mod-charset \ --disable-short-tags --with-openssl --with-kerberos --with-pcre-regex \ --without-sqlite3 --enable-bcmath --with-bz2 --enable-calendar \ --enable-ctype --with-curl --disable-dba --enable-dom --enable-exif \ --enable-fileinfo --enable-filter --enable-ftp --enable-gd-jis-conv \ --with-gmp --with-mhash --enable-hash --with-iconv --with-imap \ --with-imap-ssl --enable-intl --enable-json --with-ldap \ --with-ldap-sasl --enable-mbstring --enable-mbregex \ --enable-mbregex-backtrack --with-libmbfl --with-onig --with-mcrypt \ --with-mysql=mysqlnd --with-mysqli=mysqlnd --enable-pcntl \ --enable-pdo --with-pdo-mysql=mysqlnd --without-pdo-sqlite \ --enable-phar --enable-posix --without-libedit --without-readline \ --without-recode --enable-session --without-mm --enable-shmop \ --enable-simplexml --with-snmp --with-openssl-dir --enable-soap \ --enable-ucd-snmp-hack --enable-sockets --without-sqlite \ --enable-sysvmsg --enable-sysvsem --enable-sysvshm --with-tidy \ --enable-wddx --enable-xml --enable-xmlreader --with-xmlrpc \ --enable-xmlwriter --with-xsl --enable-zip --with-pcre-dir \ --enable-mysqlnd-threading --with-pear --enable-zend-multibyte Actual result: -- /bin/sh /root/installed/php-5.3.0RC2/libtool --silent --preserve-dup-deps --mode=compile /root/installed/php-5.3.0RC2/meta_ccld -Iext/mbstring/ -I/root/installed/php-5.3.0RC2/ext/mbstring/ -DPHP_ATOM_INC -I/root/installed/php-5.3.0RC2/include -I/root/installed/php-5.3.0RC2/main -I/root/installed/php-5.3.0RC2 -I/root/installed/php-5.3.0RC2/ext/ereg/regex -I/usr/include/libxml2 -I/usr/kerberos/include -I/root/installed/php-5.3.0RC2/ext/date/lib -I/usr/include/imap -I/root/installed/php-5.3.0RC2/ext/mbstring/oniguruma -I/root/installed/php-5.3.0RC2/ext/mbstring/libmbfl -I/root/installed/php-5.3.0RC2/ext/mbstring/libmbfl/mbfl -I/root/installed/php-5.3.0RC2/TSRM -I/root/installed/php-5.3.0RC2/Zend -I/usr/include -g -O2 -fvisibility=hidden -DZTS -c /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c -o ext/mbstring/mbstring.lo /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:4726: error: static declaration of 'php_mb_set_zend_encoding' follows non-static declaration /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:1451: error: previous implicit declaration of 'php_mb_set_zend_encoding' was here /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c: In function 'php_mb_set_zend_encoding': /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:4757: error: 'php_mb_encoding_detector' undeclared (first use in this function) /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:4757: error: (Each undeclared identifier is reported only once /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:4757: error: for each function it appears in.) /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:4758: error: 'php_mb_encoding_converter' undeclared (first use in this function) /root/installed/php-5.3.0RC2/ext/mbstring/mbstring.c:4759: error: 'php_mb_oddlen' undeclared (first use in this function) make: *** [ext/mbstring/mbstring.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=48479&edit=1
#48506 [Opn->Ver]: upcoming apr closes descriptors by default
ID: 48506
Updated by: scott...@php.net
Reported By: arekm at maven dot pl
-Status: Open
+Status: Verified
Bug Type:Feature/Change Request
PHP Version: 5.2.9
-Assigned To:
+Assigned To: scottmac
New Comment:
The details are here
https://issues.apache.org/bugzilla/show_bug.cgi?id=46425
Previous Comments:
[2009-06-09 13:47:52] arekm at maven dot pl
Description:
Upcoming apr 2.0.0 (or 1.3 with backported patch) uses O_CLOEXEC for
own descriptors by default.
This means that when using shell_exec() the run script/binary has no
stdin/stdout/stderr due to O_CLOEXEC. This also means that if any output
is produced then script ends with EPIPE.
Tested with apache + apr 1.3 with backported patch.
http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?r1=747357&r2=748988
Reproduce code:
---
Run from apache + php + apr 1.3 + backported O_CLOEXEC patch like this
one
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/apr/apr-bug-46425.patch?rev=1.8
Expected result:
run "ls -l" and produce some output about file not existing
Actual result:
--
30120 lstat("/notexistingfile", 0x18f55f0) = -1 ENOENT (No such file or
directory)
30120 write(2, "ls: ", 4) = -1 EBADF (Bad file
descriptor)
30120 write(2, "cannot access /notexistingfile", 30) = -1 EBADF (Bad
file descriptor)
30120 write(2, ": No such file or directory", 27) = -1 EBADF (Bad file
descriptor)
30120 write(2, "\n", 1) = -1 EBADF (Bad file
descriptor)
30120 close(1) = 0
30120 close(2) = -1 EBADF (Bad file
descriptor)
30120 exit_group(2)
As you can see there is no file descriptor 2 and this means that ls
output is lost.
Probably the best for php is to always provide own descriptors without
relying on apache provided one.
--
Edit this bug report at http://bugs.php.net/?id=48506&edit=1
#47384 [Opn->Bgs]: static references resolved incorrectly with class inheritance
ID: 47384
Updated by: scott...@php.net
Reported By: alreece45 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux/Windows
PHP Version: PHP5/PHP6
New Comment:
You can use static:: in PHP 5.3+ this is Late Static Binding.
Previous Comments:
[2009-06-14 13:51:01] alreece45 at gmail dot com
Perhaps this is not a Documentation Problem, but a scripting problem? I
set it as documentation because I wasn't sure if this behavior was
intentional or not. If it was intentional, the documentation needed to
be updated because it currently says:
"Static references to the current class like self:: or __CLASS__ are
resolved using the class in which the function belongs, as in where it
was defined"
I'd appreciate it to know, at the very least, if this behavior is
intentional or not for two reasons:
1) Avoid using the "feature" in PHP projects.
2) So I know if I take the time to try make a patch: I know I didn't
just waste my time (even if I fail).
also: updating the summary to be more clear (hopefully)
[2009-02-13 22:55:01] alreece45 at gmail dot com
Description:
When defining properties using constants with parent or self, they are
resolved using computed classes instead of defined classes.
This behavior appears to have existed since PHP 5.0.5 and still exists
in PHP 5.3beta3, a 5.3 CVS snapshot (200902122000), and 5.2 CVS snapshot
(200902121200).
Someone has brought this up before in php-internals:
http://marc.info/?l=php-internals&m=118839969729862&w=2
Reproduce code:
---
name}\n";
echo "{$older->daddy}\n";
?>
Expected result:
Father
Father
Actual result:
--
Grandchild
Son
--
Edit this bug report at http://bugs.php.net/?id=47384&edit=1
#48553 [Opn->Fbk]: ReflectionFunction of class_exists() return no parameters
ID: 48553 Updated by: scott...@php.net Reported By: fhardy at noparking dot net -Status: Open +Status: Feedback Bug Type: Reflection related Operating System: FreeBSD 7.1 PHP Version: 5.2.9 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.3-latest.tar.gz For Windows: http://windows.php.net/snapshots/ This is fixed in 5.3.0+ Previous Comments: [2009-06-15 09:27:00] fhardy at noparking dot net Description: Using reflectionFunction class on PHP function class_exists() to have its parameters failed. Reproduce code: --- getParameters(); echo sizeof($parameters) == 2 ? 'OK, class_exists() take 2 arguments' : 'KO, class_exists() take ' . sizeof($parameters) . ' arguments'; ?> Expected result: OK, class_exists() take 2 arguments Actual result: -- KO, class_exists() take 0 arguments -- Edit this bug report at http://bugs.php.net/?id=48553&edit=1
#47384 [Bgs->Opn]: static references resolved incorrectly with class inheritance
ID: 47384
Updated by: scott...@php.net
Reported By: alreece45 at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux/Windows
PHP Version: PHP5/PHP6
Previous Comments:
[2009-06-15 14:57:35] alreece45 at gmail dot com
In the example self is behaving as static does. It should not be doing
that. It contradicts the documentation.
In the father class: $name is set as self::my_name, which is "Father".
In the child classes, even though $name is not set, it goes to
Son::my_name and GrandSon::my_name.
[2009-06-14 23:09:24] scott...@php.net
You can use static:: in PHP 5.3+ this is Late Static Binding.
[2009-06-14 13:51:01] alreece45 at gmail dot com
Perhaps this is not a Documentation Problem, but a scripting problem? I
set it as documentation because I wasn't sure if this behavior was
intentional or not. If it was intentional, the documentation needed to
be updated because it currently says:
"Static references to the current class like self:: or __CLASS__ are
resolved using the class in which the function belongs, as in where it
was defined"
I'd appreciate it to know, at the very least, if this behavior is
intentional or not for two reasons:
1) Avoid using the "feature" in PHP projects.
2) So I know if I take the time to try make a patch: I know I didn't
just waste my time (even if I fail).
also: updating the summary to be more clear (hopefully)
[2009-02-13 22:55:01] alreece45 at gmail dot com
Description:
When defining properties using constants with parent or self, they are
resolved using computed classes instead of defined classes.
This behavior appears to have existed since PHP 5.0.5 and still exists
in PHP 5.3beta3, a 5.3 CVS snapshot (200902122000), and 5.2 CVS snapshot
(200902121200).
Someone has brought this up before in php-internals:
http://marc.info/?l=php-internals&m=118839969729862&w=2
Reproduce code:
---
name}\n";
echo "{$older->daddy}\n";
?>
Expected result:
Father
Father
Actual result:
--
Grandchild
Son
--
Edit this bug report at http://bugs.php.net/?id=47384&edit=1
#48568 [Opn->Csd]: Query to SQLite fails through PDO, works otherwise
ID: 48568
Updated by: scott...@php.net
Reported By: karsten at typo3 dot org
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: OSX 10.5.7
PHP Version: 5.3.0RC3
New Comment:
This was a bug in libsqlite 3.6.14.2, we've updated to 3.6.15 already
in CVS so it should be fixed.
Previous Comments:
[2009-06-16 09:48:41] karsten at typo3 dot org
Description:
After updating to 5.3.0RC3 two unit tests started to fail which worked
before. The same tests continue to succeed on MySQL and PostgreSQL, the
failure only occurs with SQLite.
Reproduce code:
---
setAttribute(\PDO::ATTR_ERRMODE,
\PDO::ERRMODE_EXCEPTION);
$databaseHandle->prepare($sql);
?>
Expected result:
simply nothing
Actual result:
--
[note the doubled exception - wtf?]
kmac:~ karsten$ php test.php
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 1 cannot join using column parent -
column not present in both tables' in /Users/karsten/test.php:6
Stack trace:
#0 /Users/karsten/test.php(6): PDO->prepare('SELECT "propert...')
#1 {main}
thrown in /Users/karsten/test.php on line 6
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: 1 cannot join using column parent -
column not present in both tables' in /Users/karsten/test.php:6
Stack trace:
#0 /Users/karsten/test.php(6): PDO->prepare('SELECT "propert...')
#1 {main}
thrown in /Users/karsten/test.php on line 6
--
Edit this bug report at http://bugs.php.net/?id=48568&edit=1
#48575 [Opn->Fbk]: Darwin / OS X should use dlopen() et al
ID: 48575 Updated by: scott...@php.net Reported By: php at group dot apple dot com -Status: Open +Status: Feedback Bug Type: *Compile Issues Operating System: Mac OS X PHP Version: 5.3.0RC3 New Comment: Do you have any details about what the older versions of OSX are that required the use of the dyld API? On a sidenote, are you testing this on Snow Leopard? We don't currently have an install of this available to test on, things might be broken there. Previous Comments: [2009-06-17 00:53:32] php at group dot apple dot com Description: There is a flaw in the logic in the low-level Zend pieces regarding Mac OS X's ability to use dlopen() and its cousins. When available, those standard APIs should _always_ be used in lieu of the deprecated dyld functions. In effect, the #ifdef logic in zend.h should be reversed to use HAVE_MACH_O_DYLD_H only if HAVE_DLFCN_H is undefined. However, that change caused confusion elsewhere, so the patch below is a skanky workaround without applying broader modifications to the Zend core. Ideally, Zend should do the right thing and preferably drop support for those old versions of OS X which needed the dyld APIs; that would obviate the need for this patch. I am writing the bug here because zend.com doesn't have a similar facility and this appears to be an embedded use of their toolkit. Reproduce code: --- --- php-5.3.0/acconfig.h2009-06-10 11:23:33.0 -0700 +++ php/acconfig.h 2009-06-16 17:10:25.0 -0700 @@ -120,6 +120,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 --- php-5.3.0RC3/main/php_config.h.in 2009-06-10 11:23:36.0 -0700 +++ php/main/php_config.h.in2009-06-16 17:10:25.0 -0700 @@ -2948,6 +2948,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 -- Edit this bug report at http://bugs.php.net/?id=48575&edit=1
#48215 [Ver->Asn]: Child calling parent::func calls constructor instead of method (BC break!)
ID: 48215
Updated by: scott...@php.net
Reported By: mark at everytruckjob dot com
-Status: Verified
+Status: Assigned
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.3, 6CVS (2009-05-09)
-Assigned To:
+Assigned To: scottmac
Previous Comments:
[2009-05-10 18:10:53] j...@php.net
Not sure if this is actually intentional change in PHP_5.3 (and HEAD)
but this is different from PHP_5_2:
[j...@linux5 ~]$ /usr/src/build/php_5_2CVS_FCGI/sapi/cli/php -n -d
error_reporting="E_ALL | E_STRICT" t.php
Strict Standards: Redefining already defined constructor for class
search in /home/jani/t.php on line 9
search2::__construct()
search::__construct()
search2::search()
search::search()
[j...@linux5 ~]$ /usr/src/build/php_5_3CVS_FCGI/sapi/cli/php -n -d
error_reporting="E_ALL | E_STRICT" t.php
Strict Standards: Redefining already defined constructor for class
search in /home/jani/t.php on line 9
search2::__construct()
search::__construct()
search2::search()
search::__construct()
[2009-05-09 21:59:42] mark at everytruckjob dot com
Description:
Child class calling parent::function calls parent's php4 style
constructor of same name instead of parent's public method named the
same as the class.
Reproduce code:
---
".__METHOD__;
}
protected function search()
{
echo "".__METHOD__;
}
}
class search2 extends search
{
public function __construct()
{
echo "".__METHOD__;
parent::__construct();
}
public function search()
{
echo "".__METHOD__;
parent::search();
}
}
$search2 = new search2();
$search2->search();
?>
Expected result:
search2::__construct
search::__construct
search2::search
search::__search
Actual result:
--
search2::__construct
search::__construct
search2::search
search::__construct
--
Edit this bug report at http://bugs.php.net/?id=48215&edit=1
#48575 [Fbk->Asn]: Darwin / OS X should use dlopen() et al
ID: 48575 Updated by: scott...@php.net Reported By: php at group dot apple dot com -Status: Feedback +Status: Assigned Bug Type: *Compile Issues Operating System: Mac OS X PHP Version: 5.3.0RC3 -Assigned To: +Assigned To: scottmac New Comment: We've got a patch now, will go into PHP 6 and we'll check for Is there a technical contact at Apple available for some of our other questions? We've tried contacting Apple before for help without success and the result was blogged about http://www.macvicar.net/blog/2009/02/apples-relationship-with-php.html Previous Comments: [2009-06-17 07:13:07] php at group dot apple dot com Quoting from: http://developer.apple.com/documentation/DeveloperTools/Reference/Mach OReference /Reference/reference.html "These [dlopen() et al] are the recommended functions to use to interact with the dynamic loader. These functions work in Mac OS X v10.3 and v10.4. However, in Mac OS X v10.4 they are more efficient than other image-loading functions. These functions are declared in /usr/include/dlfcn.h." 10.3 was released on 24 October 2003; 10.2 was released on 24 August 2002, so dropping support entirely means no longer supporting seven year old software. This applies to both Leopard and Snow Leopard. And it builds just fine on Snow Leopard. :-) [2009-06-17 01:58:52] scott...@php.net Do you have any details about what the older versions of OSX are that required the use of the dyld API? On a sidenote, are you testing this on Snow Leopard? We don't currently have an install of this available to test on, things might be broken there. [2009-06-17 00:53:32] php at group dot apple dot com Description: There is a flaw in the logic in the low-level Zend pieces regarding Mac OS X's ability to use dlopen() and its cousins. When available, those standard APIs should _always_ be used in lieu of the deprecated dyld functions. In effect, the #ifdef logic in zend.h should be reversed to use HAVE_MACH_O_DYLD_H only if HAVE_DLFCN_H is undefined. However, that change caused confusion elsewhere, so the patch below is a skanky workaround without applying broader modifications to the Zend core. Ideally, Zend should do the right thing and preferably drop support for those old versions of OS X which needed the dyld APIs; that would obviate the need for this patch. I am writing the bug here because zend.com doesn't have a similar facility and this appears to be an embedded use of their toolkit. Reproduce code: --- --- php-5.3.0/acconfig.h2009-06-10 11:23:33.0 -0700 +++ php/acconfig.h 2009-06-16 17:10:25.0 -0700 @@ -120,6 +120,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 --- php-5.3.0RC3/main/php_config.h.in 2009-06-10 11:23:36.0 -0700 +++ php/main/php_config.h.in2009-06-16 17:10:25.0 -0700 @@ -2948,6 +2948,15 @@ #endif /* + * Don't use on Mac OS X / Darwin if dl*() functions are available. + * Because this header is processed multiple times during compilation (thanks to lack of + * #ifdef protectors), this logic had to move here. + */ +#if defined(HAVE_DLFCN_H) && defined(HAVE_MACH_O_DYLD_H) +#/* This symbol must be allowed to be cleared. */ undef HAVE_MACH_O_DYLD_H +#endif + +/* * Local variables: * tab-width: 4 * c-basic-offset: 4 -- Edit this bug report at http://bugs.php.net/?id=48575&edit=1
#48611 [Opn->Fbk]: strtotime very slow with large values
ID: 48611
Updated by: scott...@php.net
Reported By: evert at rooftopsolutions dot nl
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: Debian
PHP Version: 5.2.10
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Pretty sure this is fixed in 5.3
Previous Comments:
[2009-06-19 19:13:39] evert at rooftopsolutions dot nl
Description:
strtotime is very slow with very large values.
Reproduce code:
---
php -r "echo strtotime('-500 days');"
also, to clearly see this function has O(n) instead of O(1)
complexity.
for x in {1..40}; do php -r "echo $x, \"\t\", pow ( 2, $x ), \"\t\",
strtotime ( ( -1 * pow ( 2, $x ) ) . ' days' ), \"\n\";" 2> /dev/null;
done;
Regardless of the fact you won't often work with dates 130 million
years ago, this could be used to trigger a dos-like attack.
Expected result:
Quick results
Actual result:
--
veryyy slow results :)
--
Edit this bug report at http://bugs.php.net/?id=48611&edit=1
#48614 [Opn]: Crash when loading "pdo_sqlite.so"
ID: 48614 Updated by: scott...@php.net Reported By: kaspernj at gmail dot com Status: Open Bug Type: PDO related Operating System: Ubuntu Jaunty PHP Version: 5.3.0RC4 New Comment: If you load sqlite3.so first does it work? Previous Comments: [2009-06-20 13:19:49] kaspernj at gmail dot com Thank you for responding. I used the following configure-line: ./configure --with-mysql=shared --with-gd=shared --with-pgsql=shared --enable-pcntl=shared --with-gettext=shared --with-mysqli=shared --with-imap=shared --with-mcrypt=shared --with-kerberos --with-imap-ssl --with-sqlite=shared --enable-sockets=shared --with-pdo-mysql=shared --with-pdo-sqlite=shared --enable-ftp=shared --enable-pdo=shared --with-pdo-pgsql=shared --enable-sockets=shared --enable-cli --disable-cgi --prefix=/opt/php53 --with-ldap=shared --with-pear=shared --disable-debug --with-bz2=shared --with-iconv=shared --with-regex=shared --enable-xml=shared --enable-dom=shared --with-xmlrpc=shared --with-mhash=shared --with-unixODBC=shared,/usr --enable-mbstring=shared --enable-xmlreader=shared --with-sqlite3=shared [2009-06-20 12:20:20] paj...@php.net Which configure line did you use? [2009-06-20 09:58:11] kaspernj at gmail dot com Description: After succesfully compiling PHP 5.3 RC4 with PDO and PDO-SQLite, I ran a test-script to test all the shared extensions. When trying to load the PDO-SQLite extension, I get the following error: Warning: dl(): Unable to load dynamic library '.../pdo_sqlite.so' - .../pdo_sqlite.so: undefined symbol: sqlite3_libversion in ../test.php on line 5 Everything was compiled as shared extensions and loaded through a CLI script with dl(). Reproduce code: --- #!/opt/php53/bin/php Expected result: Hejsa Actual result: -- Warning: dl(): Unable to load dynamic library '.../pdo_sqlite.so' - .../pdo_sqlite.so: undefined symbol: sqlite3_libversion in ../test.php on line 5 -- Edit this bug report at http://bugs.php.net/?id=48614&edit=1
#48276 [Asn->Csd]: date('Y') returns 0000
ID: 48276
Updated by: scott...@php.net
Reported By: info at programmiernutte dot net
-Status: Assigned
+Status: Closed
Bug Type: Date/time related
Operating System: Mac OS X 10.4 PPC
PHP Version: 5.3.0RC2
-Assigned To: derick
+Assigned To: scottmac
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.
The year was a long long, but we were printing it like a long. Since
sparc and ppc are big endian it was grabbing the wrong bits so to speak
:)
Previous Comments:
[2009-06-21 11:17:49] rleeden at gmail dot com
Also, seeing this after upgrading from 5.2.9 to 5.2.10.
On Solaris Sparc version 9.
returns on 5.2.10
and returns 2009 as expected on 5.2.9
[2009-06-20 15:15:41] xserve at web dot de
This bug still exits in the same way with PHP 5.2.10.
Found after upgrade from 5.2.9 to 5.2.10 on a Mac OS X 10.4.11 Server
PPC.
With 5.2.9
works as expected.
[2009-05-28 10:07:22] der...@php.net
Seems like it's an issue in slprintf:
1017switch (format[i]) {
(gdb)
1043timelib_sll year = PHP_LLABS(t->y);
(gdb) print year
$1 = 1230768000
(gdb) next
1044length = slprintf(buffer, 32,
"%s%04ld", t->y < 0 ? "-" : "",
year); break;
(gdb) print year
$2 = 2009
(gdb) next
1124smart_str_appendl(&string, buffer, length);
(gdb) print buffer
$3 =
"\000\000\004\202\000\000\000\000\000\000\000\000I\\\a\200\000\000\000\000\000\000\0006\000\000\000\000"
(gdb) next
1015for (i = 0; i < format_len; i++) {
(gdb) print &string
$4 = (smart_str *) 0xffa1cde0
(gdb) print string
$5 = {c = 0x1071f060 "\020q�X\020c\003�", len = 4, a = 78}
[2009-05-28 08:42:28] der...@php.net
Oh, I had forgotten about that PPC machine. I'll have a look.
[2009-05-28 03:56:41] scott...@php.net
We have a PPC test machine, Derick has access and I can set up other
accounts if needed.
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/48276
--
Edit this bug report at http://bugs.php.net/?id=48276&edit=1
#48651 [Fbk->Bgs]: date('Y') does not return the correct year
ID: 48651
Updated by: scott...@php.net
Reported By: dietmar dot rieder at tugraz dot at
-Status: Feedback
+Status: Bogus
Bug Type: Date/time related
Operating System: Solaris 9 (sparc)
PHP Version: 5.2.10
New Comment:
Duplicate of http://bugs.php.net/bug.php?id=48276
Fixed in CVS.
Previous Comments:
[2009-06-22 20:58:09] der...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-06-22 20:02:33] dietmar dot rieder at tugraz dot at
Description:
On Sparc Solaris 9 date('Y') does not return the correct date.
#uname -a
SunOS webmail02 5.9 Generic_118558-11 sun4u sparc SUNW,Sun-Fire-480R
# date +'%Y'
2009
# php -v -n
PHP 5.2.10 (cli) (built: Jun 19 2009 14:42:42)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
# php -n
In php-5.2.9 the problem did not exist, it is also not existing in
php-5.2.10 on Solaris 10 (x86)
Reproduce code:
---
Expected result:
2009
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=48651&edit=1
#48668 [Opn]: foreach with array will coredump php
ID: 48668
Updated by: scott...@php.net
Reported By: dmda at yandex dot ru
Status: Open
Bug Type: Reproducible crash
Operating System: solaris 8
PHP Version: 5.3.0RC4
New Comment:
Don't think its endian specific, PPC chip works.
Will test with another sparc box shortly.
Previous Comments:
[2009-06-23 22:16:22] dmda at yandex dot ru
Description:
$uname -a
SunOS qu1 5.8 Generic_108528-11 sun4u sparc
SUNW,UltraSPARC-IIi-cEngine
$ sapi/cli/php ./1.php
Bus Error (core dumped)
$gdb --core core sapi/cli/php
Core was generated by `./php 1.php'.
Program terminated with signal 10, Bus error.
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
5371INIT_PZVAL_COPY(tmp, array_ptr);
(gdb) bt
#0 0x002e7d80 in ZEND_FE_RESET_SPEC_TMP_HANDLER
(execute_data=0x861cc0)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:5371
#1 0x002d92a0 in execute (op_array=0x70bd90)
at
/export/home/jvlad/php/php5.3-200906221030/Zend/zend_vm_execute.h:104
#2 0x002b8d48 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /export/home/jvlad/php/php5.3-200906221030/Zend/zend.c:1188
#3 0x00266444 in php_execute_script (primary_file=0xffbefbf0)
at /export/home/jvlad/php/php5.3-200906221030/main/main.c:2196
#4 0x003447d4 in main (argc=2, argv=0xffbefcac)
at
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/php_cli.c:1188
(gdb) p array_ptr
$1 = (zval *) 0x861d14
(gdb) p *array_ptr
$2 = {value = {lval = 7458416, dval = 1.5848218932638939e-306, str =
{val =
0x71ce70 "",
len = 0}, ht = 0x71ce70, obj = {handle = 7458416, handlers =
0x0}},
refcount__gc = 0,
type = 4 '\004', is_ref__gc = 0 '\0'}
(gdb) p tmp
Cannot access memory at address 0xfff0
(gdb) dump_bt executor_globals.current_execute_data
[0x00861cc0] ???
/export/home/jvlad/php/php5.3-200906221030/sapi/cli/1.php:2
Reproduce code:
---
$cat 1.php
--
Edit this bug report at http://bugs.php.net/?id=48668&edit=1
#48679 [Opn->Csd]: SQLiteUnbuffered::count() SIGSEGV
ID: 48679
Updated by: scott...@php.net
Reported By: fel...@php.net
-Status: Open
+Status: Closed
Bug Type: SQLite related
Operating System: Linux
PHP Version: 5.3CVS-2009-06-24 (CVS)
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.
Is in HEAD and 5.2, will go in 5.3 once it thaws...
Previous Comments:
[2009-06-24 18:43:51] fel...@php.net
Description:
See below:
Reproduce code:
---
$x = new sqliteunbuffered;
count($x);
Expected result:
No SIGSEGV.
Actual result:
--
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7c696c0 (LWP 30884)]
0x082783ca in sqlite_count_elements (object=0x9a31940, count=0x9a325e0,
tsrm_ls=0x98f1050) at /home/felipe/dev/php5/ext/sqlite/sqlite.c:2822
2822if (obj->u.res->buffered) {
(gdb) bt
#0 0x082783ca in sqlite_count_elements (object=0x9a31940,
count=0x9a325e0, tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/ext/sqlite/sqlite.c:2822
#1 0x082ca6ab in zif_count (ht=1, return_value=0x9a325e0,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=0,
tsrm_ls=0x98f1050)
at /home/felipe/dev/php5/ext/standard/array.c:323
#2 0x08436a24 in zend_do_fcall_common_helper_SPEC
(execute_data=0x9a60a94, tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:313
#3 0x0843cb8b in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x9a60a94, tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:1601
#4 0x084357eb in execute (op_array=0x9a31fc8, tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/Zend/zend_vm_execute.h:104
#5 0x083f4ef4 in zend_eval_stringl (str=0xbfef97f4 "$x = new
sqliteunbuffered; count($x);", str_len=37, retval_ptr=0x0,
string_name=0x87a08b4 "Command line code", tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/Zend/zend_execute_API.c:1159
#6 0x083f517b in zend_eval_stringl_ex (str=0xbfef97f4 "$x = new
sqliteunbuffered; count($x);", str_len=37, retval_ptr=0x0,
string_name=0x87a08b4 "Command line code", handle_exceptions=1,
tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/Zend/zend_execute_API.c:1200
#7 0x083f522f in zend_eval_string_ex (str=0xbfef97f4 "$x = new
sqliteunbuffered; count($x);", retval_ptr=0x0, string_name=0x87a08b4
"Command line code",
handle_exceptions=1, tsrm_ls=0x98f1050) at
/home/felipe/dev/php5/Zend/zend_execute_API.c:1211
#8 0x084e6ca2 in main (argc=3, argv=0xbfef7d94) at
/home/felipe/dev/php5/sapi/cli/php_cli.c:1227
--
Edit this bug report at http://bugs.php.net/?id=48679&edit=1
#48698 [Csd->Bgs]: strtotime and mktime
ID: 48698 Updated by: scott...@php.net Reported By: hlegius at gmail dot com -Status: Closed +Status: Bogus Bug Type: Date/time related Operating System: Linux PHP Version: 5.2.10 New Comment: Not a bug -> Bogus Previous Comments: [2009-06-26 11:47:41] hlegius at gmail dot com was my fault ! [2009-06-26 10:47:39] hlegius at gmail dot com Description: I expected the last day of given timestamp, but when mktime is the second argument of strtotime this do not happens. So, I need save mktime's result in a variable to use it later in strtotime Reproduce code: --- Expected result: string '30/06/2009' (length=10) string '31/07/2009' (length=10) string '31/08/2009' (length=10) string '30/09/2009' (length=10) string '31/10/2009' (length=10) string '30/11/2009' (length=10) string '31/12/2009' (length=10) string '31/01/2009' (length=10) string '28/02/2009' (length=10) string '31/03/2009' (length=10) Actual result: -- Output of first Code: string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) string '30/06/2009' (length=10) Output of second code: string '30/06/2009' (length=10) string '31/07/2009' (length=10) string '31/08/2009' (length=10) string '30/09/2009' (length=10) string '31/10/2009' (length=10) string '30/11/2009' (length=10) string '31/12/2009' (length=10) string '31/01/2009' (length=10) string '28/02/2009' (length=10) string '31/03/2009' (length=10) -- Edit this bug report at http://bugs.php.net/?id=48698&edit=1
#48602 [Csd->Bgs]: curl doesn't correct proxy authentication header
ID: 48602 Updated by: scott...@php.net Reported By: garakkio at gmail dot com -Status: Closed +Status: Bogus Bug Type: cURL related Operating System: Debian Lenny PHP Version: 5.2.10 Previous Comments: [2009-06-26 07:22:11] garakkio at gmail dot com Well, the key was exactly CURLOPT_PROXYUSERPWD option. Using CURLOPT_PROXYUSERPWD, one header is sent differently (the difference between actual and expected result is the Authorization/Proxy-Authorization header (I mistakenly set "Authorization" in expected result). I'm sorry for this. I close the ticket. [2009-06-25 11:44:28] sjoerd-php at linuxonly dot nl Thank you for your bug report. Do you try to authenticate to the proxy (example.org) or to the destination server (php.net)? Have you looked at the CURLOPT_PROXYUSERPWD option? In your bug report, the expected result and actual result appear to be the same text. Could you clarify this? [2009-06-19 11:04:41] garakkio at gmail dot com Description: If you try to get an url via a proxy with authentication, curl sends a "Server auth" header instead of "Proxy Auth", making authentication impossible. If you try to get the same page using curl binary, the result is the expected one. The curl command corresponding to php reproduce code is: curl -v -xexample.org:80 -Ufoo:bar -o /dev/null http://www.google.com Reproduce code: --- http://php.net'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_PROXY, 'http://example.org:80'); curl_setopt($ch, CURLOPT_PROXYAUTH, CURLAUTH_BASIC); curl_setopt($ch, CURLOPT_USERPWD, 'foo:bar'); curl_setopt($ch, CURLOPT_VERBOSE, true); curl_exec($ch); Expected result: * About to connect() to proxy example.org port 80 (#0) * Trying 208.77.188.166... * connected * Connected to example.org (208.77.188.166) port 80 (#0) * Proxy auth using Basic with user 'foo' > GET http://php.net HTTP/1.1 Authorization: Basic Zm9vOmJhcg== Host: php.net Pragma: no-cache Accept: */* Proxy-Connection: Keep-Alive [...] Actual result: -- * About to connect() to proxy example.org port 80 (#0) * Trying 208.77.188.166... * connected * Connected to example.org (208.77.188.166) port 80 (#0) * Server auth using Basic with user 'foo' > GET http://php.net HTTP/1.1 Authorization: Basic Zm9vOmJhcg== Host: php.net Pragma: no-cache Accept: */* Proxy-Connection: Keep-Alive [...] -- Edit this bug report at http://bugs.php.net/?id=48602&edit=1
#48708 [Opn->Fbk]: Year can't be displayed on big endian system
ID: 48708
Updated by: scott...@php.net
Reported By: l_faillie at yahoo dot com
-Status: Open
+Status: Feedback
Bug Type: Date/time related
Operating System: All
PHP Version: 5.2.10
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Derick linked to the wrong snapshot.
I've fixed this already.
Previous Comments:
[2009-06-28 20:00:25] l_faillie at yahoo dot com
Unfortunately, I'm not able to compile latest 5.3 due to GCC bug this
time :
gcc: Internal error: Killed (program cc1)
Please submit a full bug report.
See http://www.netbsd.org/Misc/send-pr.html> for instructions.
gmake: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1
I'm planing to upgrade my system in coming weeks (during my holidays)
implying a new GCC but it's not before at least 1 month.
As a workaround of this bug, I'm suggesting doing year display as
integer as it was on 5.2.9.
Bye
Laurent
[2009-06-27 20:59:45] der...@php.net
Please try using this CVS snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2009-06-27 16:04:36] l_faillie at yahoo dot com
In ext/date/php_date.c, t->y (years) are stored as wide_int which is
'long long int' 64 bits but vararg or main/snprintf.c retrieve it as
'long int' (32 bits).
As consequence, on big endian system, only upper part is take in
account and contains only 0.
Tested on NetBSD / Sparc system but I guess reproducible on all big
endian system (IBM, sparc, 68000, ...).
Bye the way, what is the need having 64b years which as been introduced
w/ 5.2.10 ?
Bye
Laurent
[2009-06-27 15:58:02] l_faillie at yahoo dot com
Description:
In ext/date/php_date.c, years are stored as 64b integers but displayed
using "%04ld" (32b integers). Only work on little endian system
Reproduce code:
---
echo date('Y y o');
" 09 2009".
Expected result:
"2009 09 2009"
Actual result:
--
" 09 2009"
--
Edit this bug report at http://bugs.php.net/?id=48708&edit=1
#48720 [Opn->WFx]: php4 does not compile, ming error
ID: 48720 Updated by: scott...@php.net Reported By: yilanbin at 163 dot com -Status: Open +Status: Wont fix Bug Type: Compile Failure Operating System: redhat as 4.3 PHP Version: 5.2.10 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: [2009-06-29 14:40:07] yilanbin at 163 dot com Description: Latest php-4.4.9 does not compile with ming-0.4.0.beta5 ,update php from 4.4.0 to 4.4.9¡£ Reproduce code: --- ./configure '--with-apxs=/usr/local/apache/bin/apxs' '--enable-track-vars' '--with-ttf' '--with-freetype-dir=/usr/local/lib' '--enable-gd-native-ttf' '--enable-ftp' '--with-zlib' '--with-gd' '--with-freetype' '--with-sockets' '--enable-sockets' '--with-sysvshm' '--with-sysvsem' '--disable-debug' '--with-pdflib-dir=/usr/local/lib' '--with-tiff-dir=/usr/local/lib' '--with-jpeg-dir=/usr/local/lib' '--with-png-dir=/usr/local/lib' '--with-zlib-dir=/usr/local/lib' '--with-mysql' '--with-xml' '--with-iconv' '--with-ming' Expected result: /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfaction_init': /usr/local/src/php-4.4.9/ext/ming/ming.c:248: warning: `compileSWFActionCode' is deprecated (declared at /usr/local/include/ming.h:611) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfbitmap_init': /usr/local/src/php-4.4.9/ext/ming/ming.c:323: warning: assignment from incompati ble pointer type /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfbutton_setHit': /usr/local/src/php-4.4.9/ext/ming/ming.c:429: warning: `SWFButton_addShape' is d eprecated (declared at /usr/local/include/ming.h:663) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfbutton_setOver': /usr/local/src/php-4.4.9/ext/ming/ming.c:447: warning: `SWFButton_addShape' is d eprecated (declared at /usr/local/include/ming.h:663) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfbutton_setUp': /usr/local/src/php-4.4.9/ext/ming/ming.c:465: warning: `SWFButton_addShape' is d eprecated (declared at /usr/local/include/ming.h:663) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfbutton_setDown': /usr/local/src/php-4.4.9/ext/ming/ming.c:483: warning: `SWFButton_addShape' is d eprecated (declared at /usr/local/include/ming.h:663) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfbutton_addShape': /usr/local/src/php-4.4.9/ext/ming/ming.c:502: warning: `SWFButton_addShape' is d eprecated (declared at /usr/local/include/ming.h:663) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swffont_init': /usr/local/src/php-4.4.9/ext/ming/ming.c:1091: warning: `loadSWFFontFromFile' is deprecated (declared at /usr/local/include/ming.h:418) /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfmovie_init': /usr/local/src/php-4.4.9/ext/ming/ming.c:1328: error: too many arguments to func tion `newSWFMovie' /usr/local/src/php-4.4.9/ext/ming/ming.c:1330: error: too many arguments to func tion `newSWFMovie' /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfmovie_output': /usr/local/src/php-4.4.9/ext/ming/ming.c:1467: error: too many arguments to func tion `SWFMovie_output' /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfmovie_saveToFile': /usr/local/src/php-4.4.9/ext/ming/ming.c:1516: error: too many arguments to func tion `SWFMovie_output' /usr/local/src/php-4.4.9/ext/ming/ming.c: In function `zif_swfmovie_save': /usr/local/src/php-4.4.9/ext/ming/ming.c:1561: error: too many arguments to func tion `SWFMovie_output' /usr/local/src/php-4.4.9/ext/ming/ming.c:1575: error: too many arguments to func tion `SWFMovie_output' /usr/local/src/ph
#48284 [Asn]: hash "adler32" byte order is reversed
ID: 48284
Updated by: scott...@php.net
Reported By: tyler dot reese at taqua dot com
Status: Assigned
Bug Type: hash related
Operating System: *
PHP Version: 5.2.9
Assigned To: scottmac
New Comment:
Fixed in trunk and for 5.3.1, will do 5.2 shortly.
Previous Comments:
[2009-05-14 16:20:44] tyler dot reese at taqua dot com
Description:
I'm using the "adler32" algorithm of the PHP hash() function. The
result that I get has the byte-order reversed from the result I get when
doing the same hash on Python.
>From the Python interpreter:
>>> import zlib
>>> hex(zlib.adler32('abc',1))
'0x24d0127'
I saw that a bug addressed this same thing for the crc32 algorithm, but
what about adler32?
Reproduce code:
---
Expected result:
24d0127
Actual result:
--
27014d02
--
Edit this bug report at http://bugs.php.net/?id=48284&edit=1
#48506 [Ver->Asn]: upcoming apr closes descriptors by default
ID: 48506
Updated by: scott...@php.net
Reported By: arekm at maven dot pl
-Status: Verified
+Status: Assigned
Bug Type:Feature/Change Request
PHP Version: 5.2.9
Assigned To: scottmac
Previous Comments:
[2009-06-09 14:09:23] scott...@php.net
The details are here
https://issues.apache.org/bugzilla/show_bug.cgi?id=46425
[2009-06-09 13:47:52] arekm at maven dot pl
Description:
Upcoming apr 2.0.0 (or 1.3 with backported patch) uses O_CLOEXEC for
own descriptors by default.
This means that when using shell_exec() the run script/binary has no
stdin/stdout/stderr due to O_CLOEXEC. This also means that if any output
is produced then script ends with EPIPE.
Tested with apache + apr 1.3 with backported patch.
http://svn.apache.org/viewvc/apr/apr/trunk/CHANGES?r1=747357&r2=748988
Reproduce code:
---
Run from apache + php + apr 1.3 + backported O_CLOEXEC patch like this
one
http://cvs.pld-linux.org/cgi-bin/cvsweb/packages/apr/apr-bug-46425.patch?rev=1.8
Expected result:
run "ls -l" and produce some output about file not existing
Actual result:
--
30120 lstat("/notexistingfile", 0x18f55f0) = -1 ENOENT (No such file or
directory)
30120 write(2, "ls: ", 4) = -1 EBADF (Bad file
descriptor)
30120 write(2, "cannot access /notexistingfile", 30) = -1 EBADF (Bad
file descriptor)
30120 write(2, ": No such file or directory", 27) = -1 EBADF (Bad file
descriptor)
30120 write(2, "\n", 1) = -1 EBADF (Bad file
descriptor)
30120 close(1) = 0
30120 close(2) = -1 EBADF (Bad file
descriptor)
30120 exit_group(2)
As you can see there is no file descriptor 2 and this means that ls
output is lost.
Probably the best for php is to always provide own descriptors without
relying on apache provided one.
--
Edit this bug report at http://bugs.php.net/?id=48506&edit=1
#48768 [Opn]: parse_ini_file() crash with INI_SCANNER_RAW
ID: 48768
Updated by: scott...@php.net
Reported By: ahar...@php.net
Status: Open
Bug Type: Reproducible crash
Operating System: Linux x86
PHP Version: 5.3CVS-2009-07-02 (CVS)
New Comment:
I can reproduce this though I'm curious why re2c isn't picking this
up.
We have
{RAW_VALUE_CHARS}+ {
And RAW_VALUE_CHARS is
RAW_VALUE_CHARS [^=\n\r;]
So that code shouldn't even be executing, i'll need to look at it some
more.
Previous Comments:
[2009-07-02 21:57:39] j...@php.net
Thanks for not reporting this before release..
[2009-07-02 07:04:35] ahar...@php.net
Description:
parse_ini_file() crashes in INI_SCANNER_RAW mode if a configuration
item consists solely of an equals sign.
Reproduce code:
---
INI file contents:
equal = "="
PHP script:
$ini = parse_ini_file('equals.ini', false, INI_SCANNER_NORMAL);
var_dump($ini);
$ini = parse_ini_file('equals.ini', false, INI_SCANNER_RAW);
var_dump($ini);
Expected result:
array(1) {
["equal"]=>
string(1) "="
}
array(1) {
["equal"]=>
string(1) "="
}
Actual result:
--
array(1) {
["equal"]=>
string(1) "="
}
Segmentation fault (core dumped)
gdb backtrace:
#0 0xb75f58b1 in memcpy () from /lib/tls/i686/cmov/libc.so.6
#1 0x083d5e5b in zend_strndup (s=0xb7f14009 , length=3086171320) at /usr/include/bits/string3.h:52
#2 0x083d1b21 in ini_lex (ini_lval=0xbf9321d8) at
Zend/zend_ini_scanner.l:343
#3 0x083cf9fe in ini_parse () at
/h/aharvey/trees/php5/Zend/zend_ini_parser.c:1557
#4 0x083cfe91 in zend_parse_ini_file (fh=0xbf9322d0,
unbuffered_errors=0 '\0', scanner_mode=1, ini_parser_cb=0x8320f20
, arg=0xa29d148) at
/h/aharvey/trees/php5/Zend/zend_ini_parser.y:206
#5 0x0831f829 in zif_parse_ini_file (ht=3, return_value=0xa29d148,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/h/aharvey/trees/php5/ext/standard/basic_functions.c:5937
#6 0x08412a12 in execute_internal (execute_data_ptr=0xa2cddd8,
return_value_used=1) at /h/aharvey/trees/php5/Zend/zend_execute.c:1256
#7 0xb728dab0 in xdebug_execute_internal
(current_execute_data=0xa2cddd8, return_value_used=1) at
/tmp/pear/temp/xdebug/xdebug.c:1630
#8 0x0843c9af in zend_do_fcall_common_helper_SPEC
(execute_data=0xa2cddd8) at
/h/aharvey/trees/php5/Zend/zend_vm_execute.h:315
#9 0x0841a08e in execute (op_array=0xa29c554) at
/h/aharvey/trees/php5/Zend/zend_vm_execute.h:104
#10 0xb728d734 in xdebug_execute (op_array=0xa29c554) at
/tmp/pear/temp/xdebug/xdebug.c:1561
#11 0x083f12f6 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /h/aharvey/trees/php5/Zend/zend.c:1188
#12 0x0839f610 in php_execute_script (primary_file=0xbf9348f4) at
/h/aharvey/trees/php5/main/main.c:2196
#13 0x08476002 in main (argc=2, argv=0xbf934a54) at
/h/aharvey/trees/php5/sapi/cli/php_cli.c:1188
--
Edit this bug report at http://bugs.php.net/?id=48768&edit=1
#48785 [Opn]: PHP -i segfaults
ID: 48785 Updated by: scott...@php.net Reported By: gerwin at digitalus dot nl Status: Open Bug Type: Reproducible crash Operating System: RHEL 5 PHP Version: 5.3.0 New Comment: What was the configure line you used? Previous Comments: [2009-07-03 08:33:48] gerwin at digitalus dot nl Extra note: a build created an ran on RHEL 4 will NOT segfault when using -i Debug Build => yes First output: Program received signal SIGSEGV, Segmentation fault. 0x00b14820 in ?? () from /usr/lib/php/modules/pdo_sqlite.so Backtrace: (gdb) bt #0 0x00b14820 in ?? () from /usr/lib/php/modules/pdo_sqlite.so #1 0x65646e75 in ?? () #2 0x656e6966 in ?? () . . . . #67 0x6576206b in ?? () #68 0x6f697372 in ?? () #69 0x0060206e in ?? () from /usr/lib/libxml2.so.2 Backtrace stopped: previous frame inner to this frame (corrupt stack?) [2009-07-03 07:55:53] j...@php.net 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. [2009-07-03 07:15:27] gerwin at digitalus dot nl Some things I noticed: - Disabling the sqlite.so module will "solve" the problem. - when using phpinfo() on a website, there is NO segfault on from the command line [2009-07-03 07:09:36] gerwin at digitalus dot nl Description: When executing php -i (php information) it shows some output but then it will segfault. Reproduce code: --- On commandline: php -i Expected result: Probably missing entries Actual result: -- Segmentation faul. Strace: write(1, "PDO Driver for SQLite 3.x", 25PDO Driver for SQLite 3.x) = 25 write(1, " => ", 4 => ) = 4 write(1, "enabled", 7enabled) = 7 write(1, "\n", 1 ) = 1 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ -- Edit this bug report at http://bugs.php.net/?id=48785&edit=1
#48809 [WFx]: "virtual memory exhausted: Cannot allocate memory" with libmagic/apprentice.c
ID: 48809 Updated by: scott...@php.net Reported By: ibboard at gmail dot com Status: Wont fix Bug Type: Compile Failure Operating System: CentOS 4 PHP Version: 5.3.0 New Comment: What version of gcc were you using? It would be nice to track this where possible. Previous Comments: [2009-07-05 21:48:32] ras...@php.net It is probably up in the 600-700M range. If you are using an older toolchain in a severely memory-starved environment, you shouldn't expect to be able to compile everything there. Why not simply cross-compile from a real dev box somewhere and copy the binaries over? You can install your production OS in a vm slice on whatever home machine you have and compile there. [2009-07-05 19:24:35] ibboard at gmail dot com "Quite a bit" of memory? That seems like a bit of an understatement when it will quite happily consume over 350MB of memory on a single file and previous versions of PHP could be compiled in ~150MB or less (albeit without that extension) :D Maybe libmagic needs disabling as a default module if it was in PECL before and is known to causes problems with older compilers? How much memory am I expected to need to compile it if it fails with 350MB? I've just watched 'top' while the compile continued and it maxed out at ~120MB without libmagic, which is far more reasonable. [2009-07-05 19:08:30] ras...@php.net We know that file takes quite a bit of memory to compile on older versions of gcc. It should be better in newer versions though. Not much we can do about this. We aren't going to change perfectly valid code just because some older compilers have trouble with it. [2009-07-05 19:05:08] ibboard at gmail dot com Description: I'm trying to compile PHP 5.3 on a VPS with 256MB of memory, but I keep getting "out of memory" errors before 'make' completes. I've compiled 5.2.x on the VPS before and I've freed up over 170MB of my 256MB of memory, but still I get the following error (always the same file): virtual memory exhausted: Cannot allocate memory make: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1 My host temporarily bumped my account up to 512MB of memory, but it still took all of the free memory before failing (350MB+). Disabling the extension that the file is from with "--disable-fileinfo" gets me beyond the error and continues without running out of memory (until it hits a different error in libgd, which I'm looking in to). May be similar to http://bugs.php.net/bug.php?id=48593, but crashes out with insufficient memory rather than hanging indefinitely. Reproduce code: --- $ wget http://uk2.php.net/get/php-5.3.0.tar.bz2/from/this/mirror $ tar -xjvf php-5.3.0.tar.bz2 $ cd php-5.3.0 $ ./configure --prefix=/usr/local/php5-fcgi --with-kerberos=/opt --with-layout=GNU --with-regex=php --with-gettext --enable-mbstring --enable-libxml --with-pcre-regex=/opt --with-imap=shared --with-imap-ssl --with-mysql=shared,/opt --with-mysqli=shared,/usr/bin/mysql_config --with-mysql-sock=/var/lib/mysql/mysql.sock --with-libxml-dir=/opt --enable-gd-native-ttf --with-gd=/opt --with-jpeg-dir=/opt --with-freetype-dir=/opt --with-mcrypt --with-zlib-dir=/opt --with-png-dir=/opt --with-config-file-scan-dir=/usr/local/etc/php.d $ make Expected result: PHP compile to complete so that I can run "sudo make install". Actual result: -- [lots of compile output] ... /bin/sh /home/ibb_admin/temp/php-5.3.0/libtool --silent --preserve-dup-deps --mode=compile gcc -I/home/ibb_admin/temp/php-5.3.0/ext/fileinfo/libmagic -Iext/fileinfo/ -I/home/ibb_admin/temp/php-5.3.0/ext/fileinfo/ -DPHP_ATOM_INC -I/home/ibb_admin/temp/php-5.3.0/include -I/home/ibb_admin/temp/php-5.3.0/main -I/home/ibb_admin/temp/php-5.3.0 -I/home/ibb_admin/temp/php-5.3.0/ext/date/lib -I/home/ibb_admin/temp/php-5.3.0/ext/ereg/regex -I/usr/include/libxml2 -I/opt/include -I/opt/include/freetype2 -I/usr/include/imap -I/usr/kerberos/include -I/home/ibb_admin/temp/php-5.3.0/ext/mbstring/oniguruma -I/home/ibb_admin/temp/php-5.3.0/ext/mbstring/libmbfl -I/home/ibb_admin/temp/php-5.3.0/ext/mbstring/libmbfl/mbfl -I/opt/include/mysql -I/usr/include/mysql -I/home/ibb_admin/temp/php-5.3.0/ext/sqlite3/libsqlite -I/home/ibb_admin/temp/php-5.3.0/TSRM -I/home/ibb_admin/temp/php-5.3.0/Zend-I/usr/include -g -O2 -c /home/ibb_admin/temp/php-5.3.0/ext/fileinfo/libmagic/apprentice.c -o ext/fileinfo/libmagic/apprentice.lo virtual memory exhausted: Cannot allocate memory make: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1 -- Edit this bug report at http://bugs.php.net/?id=
#48809 [WFx]: "virtual memory exhausted: Cannot allocate memory" with libmagic/apprentice.c
ID: 48809 Updated by: scott...@php.net Reported By: ibboard at gmail dot com Status: Wont fix Bug Type: Compile Failure Operating System: CentOS 4 PHP Version: 5.3.0 New Comment: What version of gcc were you using? It would be nice to track this where possible. Previous Comments: [2009-07-05 22:46:07] scott...@php.net What version of gcc were you using? It would be nice to track this where possible. [2009-07-05 21:48:32] ras...@php.net It is probably up in the 600-700M range. If you are using an older toolchain in a severely memory-starved environment, you shouldn't expect to be able to compile everything there. Why not simply cross-compile from a real dev box somewhere and copy the binaries over? You can install your production OS in a vm slice on whatever home machine you have and compile there. [2009-07-05 19:24:35] ibboard at gmail dot com "Quite a bit" of memory? That seems like a bit of an understatement when it will quite happily consume over 350MB of memory on a single file and previous versions of PHP could be compiled in ~150MB or less (albeit without that extension) :D Maybe libmagic needs disabling as a default module if it was in PECL before and is known to causes problems with older compilers? How much memory am I expected to need to compile it if it fails with 350MB? I've just watched 'top' while the compile continued and it maxed out at ~120MB without libmagic, which is far more reasonable. [2009-07-05 19:08:30] ras...@php.net We know that file takes quite a bit of memory to compile on older versions of gcc. It should be better in newer versions though. Not much we can do about this. We aren't going to change perfectly valid code just because some older compilers have trouble with it. [2009-07-05 19:05:08] ibboard at gmail dot com Description: I'm trying to compile PHP 5.3 on a VPS with 256MB of memory, but I keep getting "out of memory" errors before 'make' completes. I've compiled 5.2.x on the VPS before and I've freed up over 170MB of my 256MB of memory, but still I get the following error (always the same file): virtual memory exhausted: Cannot allocate memory make: *** [ext/fileinfo/libmagic/apprentice.lo] Error 1 My host temporarily bumped my account up to 512MB of memory, but it still took all of the free memory before failing (350MB+). Disabling the extension that the file is from with "--disable-fileinfo" gets me beyond the error and continues without running out of memory (until it hits a different error in libgd, which I'm looking in to). May be similar to http://bugs.php.net/bug.php?id=48593, but crashes out with insufficient memory rather than hanging indefinitely. Reproduce code: --- $ wget http://uk2.php.net/get/php-5.3.0.tar.bz2/from/this/mirror $ tar -xjvf php-5.3.0.tar.bz2 $ cd php-5.3.0 $ ./configure --prefix=/usr/local/php5-fcgi --with-kerberos=/opt --with-layout=GNU --with-regex=php --with-gettext --enable-mbstring --enable-libxml --with-pcre-regex=/opt --with-imap=shared --with-imap-ssl --with-mysql=shared,/opt --with-mysqli=shared,/usr/bin/mysql_config --with-mysql-sock=/var/lib/mysql/mysql.sock --with-libxml-dir=/opt --enable-gd-native-ttf --with-gd=/opt --with-jpeg-dir=/opt --with-freetype-dir=/opt --with-mcrypt --with-zlib-dir=/opt --with-png-dir=/opt --with-config-file-scan-dir=/usr/local/etc/php.d $ make Expected result: PHP compile to complete so that I can run "sudo make install". Actual result: -- [lots of compile output] ... /bin/sh /home/ibb_admin/temp/php-5.3.0/libtool --silent --preserve-dup-deps --mode=compile gcc -I/home/ibb_admin/temp/php-5.3.0/ext/fileinfo/libmagic -Iext/fileinfo/ -I/home/ibb_admin/temp/php-5.3.0/ext/fileinfo/ -DPHP_ATOM_INC -I/home/ibb_admin/temp/php-5.3.0/include -I/home/ibb_admin/temp/php-5.3.0/main -I/home/ibb_admin/temp/php-5.3.0 -I/home/ibb_admin/temp/php-5.3.0/ext/date/lib -I/home/ibb_admin/temp/php-5.3.0/ext/ereg/regex -I/usr/include/libxml2 -I/opt/include -I/opt/include/freetype2 -I/usr/include/imap -I/usr/kerberos/include -I/home/ibb_admin/temp/php-5.3.0/ext/mbstring/oniguruma -I/home/ibb_admin/temp/php-5.3.0/ext/mbstring/libmbfl -I/home/ibb_admin/temp/php-5.3.0/ext/mbstring/libmbfl/mbfl -I/opt/include/mysql -I/usr/include/mysql -I/home/ibb_admin/temp/php-5.3.0/ext/sqlite3/libsqlite -I/home/ibb_admin/temp/php-5.3.0/TSRM -I/home/ibb_admin/temp/php-5.3.0/Zend-I/usr/include -g -O2 -c /home/ibb_admin/temp/php-5.3.0/ext/fileinfo/libmagic/apprentice.c -o ext/fileinfo/libmagic/apprentice.lo virtual memory exhausted: Cannot all
#48779 [Opn]: Use of HOST section cause 500 error
ID: 48779 Updated by: scott...@php.net Reported By: keithdavis at pridedallas dot com Status: Open Bug Type: Reproducible crash Operating System: Windows Vista Business x86 PHP Version: 5.3.0 New Comment: I tried to reproduce this on OSX and Linux without luck. The error looks like it's in main/php_ini.c from the backtrace, but I'm not sure whats up with the zval. Previous Comments: [2009-07-06 23:13:37] keithdavis at pridedallas dot com I didn't even see that. I tried to follow those directions. Hopefully, they can figure it out from yours. [2009-07-06 22:55:30] paj...@php.net I already provided one. But if you can provide one for your case, see http://bugs.php.net/bugs-generating-backtrace-win32.php Maybe you catched another issue than the one I used. [2009-07-06 22:42:19] keithdavis at pridedallas dot com I apologize, but I am unfamiliar with the backtrace process and I don't understand how to do this. If you can give me more specific instructions. I don't have VC (just VC express) and it doesn't appear that this can be used. I have tried with the Debug Diagnostics method, but either I am not doing it correctly, or this is a crash that is not being detected. [2009-07-06 22:15:16] keithdavis at pridedallas dot com It says to use MSVC6, but I am using the VC9 version of PHP, so shouldn't I use Visual C 2008 for this? Will Express work or do I need to do the without compiler method? [2009-07-03 07:59:05] paj...@php.net It does under certain circumstances, for example using [HOST=localhost:8080]. Trying to figure out hwow to debug the .y :) php5_debug.dll!php_ini_parser_cb(_zval_struct * arg1=0x00c2c47c, _zval_struct * arg2=0x, _zval_struct * arg3=0x, int callback_type=2, _hashtable * target_hash=0x105a5680) Line 279 + 0x8 bytes C > php5_debug.dll!ini_parse() Line 282 + 0x21 bytes C php5_debug.dll!zend_parse_ini_file(_zend_file_handle * fh=0x00c2d744, unsigned char unbuffered_errors='', int scanner_mode=0, void (_zval_struct *, _zval_struct *, _zval_struct *, int, void *)* ini_parser_cb=0x102ee580, void * arg=0x105a5680) Line 206 + 0x5 bytes C php5_debug.dll!php_init_config() Line 588 + 0x1a bytes C php5_debug.dll!php_module_startup(_sapi_module_struct * sf=0x00423008, _zend_module_entry * additional_modules=0x004230a0, unsigned int num_additional_modules=1) Line 1911 + 0x5 bytes C php-cgi.exe!php_cgi_startup(_sapi_module_struct * sapi_module=0x00423008) Line 859 + 0x13 bytes C php-cgi.exe!main(int argc=1, char * * argv=0x02ec3c10) Line 1602 + 0xd bytes C php-cgi.exe!__tmainCRTStartup() Line 586 + 0x19 bytes C php-cgi.exe!mainCRTStartup() Line 403 C 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/48779 -- Edit this bug report at http://bugs.php.net/?id=48779&edit=1
#48835 [Asn]: all test of 'make test' fail with old local php.ini
ID: 48835 Updated by: scott...@php.net Reported By: andreas dot rieber at 2e-systems dot com Status: Assigned Bug Type: Unknown/Other Function Operating System: opensuse PHP Version: 5.3.0 Assigned To: kalle New Comment: Makefile.global needs to change to remove these settings when it's building the tmp-php.ini. At the moment the grep is ^(zend_)?extension(_debug)?(_ts)?[\t\ ]*= I knew about this but never got around to fixing it for 5.3.0. Previous Comments: [2009-07-07 14:16:55] bj...@php.net :( [2009-07-07 13:17:47] andreas dot rieber at 2e-systems dot com Description: 'make test' uses the systems /usr/local/lib/php.ini with 5.2.10 configuration and so all test failed. After i unkommented some lines, the tests passed: > ;magic_quotes_gpc = On > ;magic_quotes_runtime = Off > ;magic_quotes_sybase = Off > ;define_syslog_variables = On -- Edit this bug report at http://bugs.php.net/?id=48835&edit=1
#48885 [Opn->Bgs]: finfo returns mime type + charset when FILEINFO_MIME is used
ID: 48885
Updated by: scott...@php.net
Reported By: majkl578 at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: Linux Debian
PHP Version: 5.3.0
New Comment:
This is correct, rfc2045 requires the character set to be there for
mime type.
Previous Comments:
[2009-07-11 12:46:42] majkl578 at gmail dot com
Description:
When finfo is used with FILEINFO_MIME flag for a file, it returns mime
type + charset (in this format: mime/type; charset=foo
Configure Command:
'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql'
'--with-mysqli' '--with-curl' '--with-sqlite' '--with-gd'
'--enable-mbstring' '--with-openssl' '--disable-short-tags'
'--with-mcrypt' '--with-bz2' '--with-zlib' '--enable-zip'
Reproduce code:
---
$obj = new \finfo(FILEINFO_MIME);
echo $obj->file('/tmp/phpbug'); //in file is plain text
Expected result:
text/plain
Actual result:
--
text/plain; charset=us-ascii
--
Edit this bug report at http://bugs.php.net/?id=48885&edit=1
#48885 [Tbd]: finfo returns mime type + charset when FILEINFO_MIME is used
ID: 48885 Updated by: scott...@php.net Reported By: majkl578 at gmail dot com Status: To be documented Bug Type: Filesystem function related Operating System: Linux Debian PHP Version: 5.3.0 New Comment: As Pierre has said already this is the way libmagic works and it matches the RFC for mime type. The charset on non text documents is also valid, even if it just says binary. So there isn't a BC break here unless you were using the mime type for something else. Previous Comments: [2009-07-12 13:33:48] paj...@php.net The fileinfo extension has been bundled in PHP (5.3 and later). The development takes place only in PHP, not anymore in PECL. Old releases may have issues or may not be compliant with the RFC. Like it or not, that's a fact. For the binary data, the charset will obviously be set to binary: image/gif; charset=binary It is a documentation, not a bug neither a BC break. [2009-07-12 12:32:34] majkl578 at gmail dot com Look: I tested the code mentioned in bug report on php 5.2.10, i used a JPEG image: On php 5.3.0 returns 'image/jpeg; charset=binary' On php 5.2.10 returns 'image/jpeg' only. So, my question is: is it a bug or a feature in 5.3? If it's a feature: 1. it is NOT backward compatible. 2. it does not have any meaning for files like images etc, only for text files. So? [2009-07-11 22:45:11] paj...@php.net pls update this example [2009-07-11 21:15:18] majkl578 at gmail dot com ok sorry for this. but if it is correct, informations here: http://php.net/manual/en/function.finfo-file.php are misleading (see Example #1), because there is not mentioned anything about this, just about mime type. [2009-07-11 20:44:07] scott...@php.net This is correct, rfc2045 requires the character set to be there for mime type. 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/48885 -- Edit this bug report at http://bugs.php.net/?id=48885&edit=1
#48940 [Opn->Bgs]: date('Y') generates 0000 while date('y') generates 09
ID: 48940
Updated by: scott...@php.net
Reported By: trizt at iname dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux PPC 32bit
PHP Version: 5.2.10
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.
Fixed in CVS already, you can use a CVS copy or wait until 5.2.11 is
out or use 5.3.0 which has it fixed.
Previous Comments:
[2009-07-16 06:16:05] trizt at iname dot com
Description:
On Linux PPC 32bit (Gentoo with following options: apache2 bcmath
berkdb bzip2 cjk cli crypt ctype curl curlwrappers exif ftp gd gdbm
iconv imap json ldap mhash mysql mysqli ncurses nls pcntl pcre posix
readline reflection session simplexml snmp soap sockets spl ssl suhosin
tidy tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter xpm
xsl yaz zip zlib), the date('Y') don't generate the current year, but
.
A simple but not that nice work around is to make
'20'.date('y')
Using the date('Y') works on my x86_64, so I think the bug may be in
just big endian machines (haven't tested this on my sparc yet).
Reproduce code:
---
Expected result:
2009
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=48940&edit=1
#48939 [Csd->Bgs]: ceil error
ID: 48939 Updated by: scott...@php.net Reported By: louis at frenzoo dot com -Status: Closed +Status: Bogus Bug Type: Math related Operating System: Linux PHP Version: 5.2.10 Previous Comments: [2009-07-16 06:38:59] louis at frenzoo dot com Sorry to disturb. Got the idea that it is the definition from IEEE, the limitation of float in binary representation. Thanks for concern! [2009-07-16 06:36:47] ka...@php.net Please try with PHP 5.3.0 where the rounding was revised per this RFC: http://wiki.php.net/rfc/rounding [2009-07-16 05:11:52] louis at frenzoo dot com Description: ceil() does not give an correct expected result. I have read some bug reports before. I understand that there is floating point error, but it happens in just a simple math calculation, which is unacceptable in the below case. It created inaccurate result on simple math, it will also create chaos in more complicated ones. Reproduce code: --- $n = 100.0*1.1; print $n.'='.ceil($n); Expected result: 110 = 110 Actual result: -- 110 = 111 -- Edit this bug report at http://bugs.php.net/?id=48939&edit=1
#48938 [Opn->Bgs]: Feels like .*? and /s is problematic, no output generated!
ID: 48938 Updated by: scott...@php.net Reported By: alexis at m2osw dot com -Status: Open +Status: Bogus Bug Type: PCRE related Operating System: Linux PHP Version: 5.2.10 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. Check out preg_last_error(), you've reached a limit we set in PCRE to prevent segfaults due to inefficient regular expressions. Previous Comments: [2009-07-16 04:50:14] alexis at m2osw dot com Description: I have a pregex that starts looks like this: /(?:)?\[.../s (The last ... is to be interpreted as an ellipsis) Removing the /s or the tag before the \[ fixes the problem. Otherwise the preg_replace_callback() returns an empty string and never calls the callback. This is the case with several pages of data we have, although it is not easy for me to determine what triggers the problem. P.S. If the callback does not exist, the function has a shortcut and the input is immediately returned as is. Reproduce code: --- 1740 lines of code found as an attachment to that page: http://linux.m2osw.com/pcre_php_s_modifier_bug The main reason for the length is the HTML code, the failing code is just 1 line at the bottom. Expected result: ($s == preg_replace_callback(...)) === TRUE since the callback should not be called with that HTML. Actual result: -- preg_replace_callback() returns NULL -- Edit this bug report at http://bugs.php.net/?id=48938&edit=1
#48940 [Bgs]: date('Y') generates 0000 while date('y') generates 09
ID: 48940
Updated by: scott...@php.net
Reported By: trizt at iname dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Linux PPC 32bit
PHP Version: 5.2.10
New Comment:
Bug #48276
It's been reported a handful of times now, searching for date and
shows it.
Previous Comments:
[2009-07-16 08:36:50] trizt at iname dot com
Didn't find any results on similar bugs when I made the search before
writing this one.
Had been nice if you could have made this a duplicate of original bug,
or at least give the bug id.
[2009-07-16 07:07:58] scott...@php.net
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.
Fixed in CVS already, you can use a CVS copy or wait until 5.2.11 is
out or use 5.3.0 which has it fixed.
[2009-07-16 06:16:05] trizt at iname dot com
Description:
On Linux PPC 32bit (Gentoo with following options: apache2 bcmath
berkdb bzip2 cjk cli crypt ctype curl curlwrappers exif ftp gd gdbm
iconv imap json ldap mhash mysql mysqli ncurses nls pcntl pcre posix
readline reflection session simplexml snmp soap sockets spl ssl suhosin
tidy tokenizer truetype unicode wddx xml xmlreader xmlrpc xmlwriter xpm
xsl yaz zip zlib), the date('Y') don't generate the current year, but
.
A simple but not that nice work around is to make
'20'.date('y')
Using the date('Y') works on my x86_64, so I think the bug may be in
just big endian machines (haven't tested this on my sparc yet).
Reproduce code:
---
Expected result:
2009
Actual result:
--
--
Edit this bug report at http://bugs.php.net/?id=48940&edit=1
#48973 [Opn->Bgs]: gmdate("Y") returns "0000"
ID: 48973
Updated by: scott...@php.net
Reported By: Michael dot Forman at Colorado dot EDU
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Mac OS 10.5.7
PHP Version: 5.2.10
New Comment:
Duplicate of bug #48276
Previous Comments:
[2009-07-18 23:21:31] Michael dot Forman at Colorado dot EDU
Description:
Within Joomla, called from the "libraries/joomla/utilities/data.php"
library, the function gmdate("Y") returns "", whereas gmdate("y")
correctly returns "09". If functions correctly on the command line.
Reproduce code:
---
$date = strtotime(gmdate("M d Y H:i:s", time()));
echo $date;
// This returns "Jul 18 23:05:58".
Expected result:
It should return "Jul 18 2009 23:05:58".
--
Edit this bug report at http://bugs.php.net/?id=48973&edit=1
#49036 [Opn->Fbk]: preg_replace error when using \W
ID: 49036
Updated by: scott...@php.net
Reported By: gvdefence-ncr at yahoo dot it
-Status: Open
+Status: Feedback
Bug Type: PCRE related
Operating System: WXP
PHP Version: 5.2.10
New Comment:
pcre is locale aware so there are some exceptions. What locale are you
using?
Also we use PCRE which is not the Microsoft regexp syntax, I suggest
you read the PHP manual instead.
Previous Comments:
[2009-07-23 17:34:25] gvdefence-ncr at yahoo dot it
Description:
According to regexp sintax [\W] is identical to [^A-Za-z0-9_] (can see:
http://msdn.microsoft.com/en-us/library/1400241x(VS.85).aspx)
But preg_replace does not seem to work the same way.
Reproduce code:
---
http://msdn.microsoft.com/en-us/library/1400241x(VS.85).aspx)
$result1 = preg_replace('/[^A-Za-z0-9_]*/', '', "test àèìòù test");
$result2 = preg_replace('/[\W]*/', '', "test àèìòù test");
echo "" . $result1 . ""; //ok, it shows: "testtest"
echo "" . $result2 . "" //wrong it shows:
"testàèìòùtest"
?>
Expected result:
testtest
testtest
Actual result:
--
testtest
testàèìòùtest
--
Edit this bug report at http://bugs.php.net/?id=49036&edit=1
#49036 [Bgs]: preg_replace error when using \W
ID: 49036
Updated by: scott...@php.net
Reported By: gvdefence-ncr at yahoo dot it
Status: Bogus
Bug Type: PCRE related
Operating System: WXP
PHP Version: 5.2.10
New Comment:
We have Perl Compatible Regular Expressions *NOT* POSIX regular
expressions.
Previous Comments:
[2009-07-23 18:54:58] gvdefence-ncr at yahoo dot it
To me this only means that also the PHP documentation is wrong.
1st) there is a paradox:
if [\w] (I tested same issue of \W) does the matching depending on
local setting then also [A-Za-z_] (which is the same of [\w] should
behave in the same way and match also accented character like àèìòù
depending on local setting, since it does not happen this last one would
be the bug.
2nd) I wonder how to acknowledge all websites on the internet
(including Wikipedia) that PHP reg expression sintax is different from
the common sense standard of the rest of the world!
PS
I adore PHP, just trying to help. Bye!)
[2009-07-23 18:14:04] der...@php.net
http://uk.php.net/manual/en/regexp.reference.backslash.php clearly
explains it:
\w
any "word" character
\W
any "non-word" character
Each pair of escape sequences partitions the complete set of characters
into two disjoint sets. Any given character matches one, and only one,
of each pair.
A "word" character is any letter or digit or the underscore character,
that is, any character which can be part of a Perl "word". The
definition of letters and digits is controlled by PCRE's character
tables, and may vary if locale-specific matching is taking place. For
example, in the "fr" (French) locale, some character codes greater than
128 are used for accented letters, and these are matched by \w.
[2009-07-23 17:59:28] gvdefence-ncr at yahoo dot it
What's locale?
[\W] is identical to [^A-Za-z0-9_] is not only Microsoft idea.
\W means matching any nonword character is the same of [^\w] which is
the same of [^A-Za-z0-9_]
[http://en.wikipedia.org/wiki/Regular_expression#POSIX_character_classes]
Also many other website that talks about reg exp say the same thing of
Microsoft and wikipedia, you can search in Google.
Sorry, but this is a bug!
BTW: php manual is completly useless regarding regular expression
sintax, it does not help in any way, that's why I added the Microsoft
documentation link.
[2009-07-23 17:41:11] scott...@php.net
pcre is locale aware so there are some exceptions. What locale are you
using?
Also we use PCRE which is not the Microsoft regexp syntax, I suggest
you read the PHP manual instead.
[2009-07-23 17:34:25] gvdefence-ncr at yahoo dot it
Description:
According to regexp sintax [\W] is identical to [^A-Za-z0-9_] (can see:
http://msdn.microsoft.com/en-us/library/1400241x(VS.85).aspx)
But preg_replace does not seem to work the same way.
Reproduce code:
---
http://msdn.microsoft.com/en-us/library/1400241x(VS.85).aspx)
$result1 = preg_replace('/[^A-Za-z0-9_]*/', '', "test àèìòù test");
$result2 = preg_replace('/[\W]*/', '', "test àèìòù test");
echo "" . $result1 . ""; //ok, it shows: "testtest"
echo "" . $result2 . "" //wrong it shows:
"testàèìòùtest"
?>
Expected result:
testtest
testtest
Actual result:
--
testtest
testàèìòùtest
--
Edit this bug report at http://bugs.php.net/?id=49036&edit=1
#48885 [Tbd]: finfo returns mime type + charset when FILEINFO_MIME is used
ID: 48885
Updated by: scott...@php.net
Reported By: majkl578 at gmail dot com
Status: To be documented
Bug Type: Filesystem function related
Operating System: Linux Debian
PHP Version: 5.3.0
New Comment:
Matthew, you can get the behavior with PHP 5.2 if you link against a
newer version of libmagic. This wasn't a change to any of the PHP
wrapper code in this case.
So yes it might be a BC break for you, but in reality its a bug fix.
Previous Comments:
[2009-07-26 21:48:21] paj...@php.net
Matthew,
That's exactly why the status of this report is set to "to be
documented".
[2009-07-26 21:43:19] matthew at zend dot com
I beg to differ a bit here with the assertion that the change is not a
BC break.
Consider this: in versions prior to 5.3.0, one could do a match like
this:
$finfo = new finfo(FILEINFO_MIME);
$type = $finfo->file($filename);
if (!in_array($type, array('image/jpeg', 'image/jpg'))) {
echo "Invalid image type.";
} else {
echo "JPEG found."
}
Now, with 5.3.0, this changes; the same assertion no longer works. This
is in fact exactly an issue we had with Zend_Validate_File_MimeType when
testing against PHP 5.3.0 -- matching that worked in 5.2.x now no longer
works in 5.3.0. We have altered our library to handle the strings
returned by both versions, but that exactly disproves your point: if the
new behavior were BC, we wouldn't *need* to update our code.
I feel at the very least, the fact that the MIME type returned also
includes encoding information, and the format of this encoding
information, needs to be documented in the manual, and likely the
UPGRADING guide.
[2009-07-12 23:16:53] scott...@php.net
As Pierre has said already this is the way libmagic works and it
matches the RFC for mime type.
The charset on non text documents is also valid, even if it just says
binary.
So there isn't a BC break here unless you were using the mime type for
something else.
[2009-07-12 13:33:48] paj...@php.net
The fileinfo extension has been bundled in PHP (5.3 and later). The
development takes place only in PHP, not anymore in PECL.
Old releases may have issues or may not be compliant with the RFC. Like
it or not, that's a fact.
For the binary data, the charset will obviously be set to binary:
image/gif; charset=binary
It is a documentation, not a bug neither a BC break.
[2009-07-12 12:32:34] majkl578 at gmail dot com
Look:
I tested the code mentioned in bug report on php 5.2.10, i used a JPEG
image:
On php 5.3.0 returns 'image/jpeg; charset=binary'
On php 5.2.10 returns 'image/jpeg' only.
So, my question is: is it a bug or a feature in 5.3?
If it's a feature:
1. it is NOT backward compatible.
2. it does not have any meaning for files like images etc, only for
text files.
So?
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/48885
--
Edit this bug report at http://bugs.php.net/?id=48885&edit=1
#48885 [Tbd]: finfo returns mime type + charset when FILEINFO_MIME is used
ID: 48885
Updated by: scott...@php.net
Reported By: majkl578 at gmail dot com
Status: To be documented
Bug Type: Filesystem function related
Operating System: Linux Debian
PHP Version: 5.3.0
New Comment:
Looked into this tonight again and from 5.3+ there are two new
constants available, FILEINFO_MIME_TYPE provides the old behavior.
I'll add them both to the documentation tonight.
Previous Comments:
[2009-07-26 22:31:17] scott...@php.net
Matthew, you can get the behavior with PHP 5.2 if you link against a
newer version of libmagic. This wasn't a change to any of the PHP
wrapper code in this case.
So yes it might be a BC break for you, but in reality its a bug fix.
[2009-07-26 21:48:21] paj...@php.net
Matthew,
That's exactly why the status of this report is set to "to be
documented".
[2009-07-26 21:43:19] matthew at zend dot com
I beg to differ a bit here with the assertion that the change is not a
BC break.
Consider this: in versions prior to 5.3.0, one could do a match like
this:
$finfo = new finfo(FILEINFO_MIME);
$type = $finfo->file($filename);
if (!in_array($type, array('image/jpeg', 'image/jpg'))) {
echo "Invalid image type.";
} else {
echo "JPEG found."
}
Now, with 5.3.0, this changes; the same assertion no longer works. This
is in fact exactly an issue we had with Zend_Validate_File_MimeType when
testing against PHP 5.3.0 -- matching that worked in 5.2.x now no longer
works in 5.3.0. We have altered our library to handle the strings
returned by both versions, but that exactly disproves your point: if the
new behavior were BC, we wouldn't *need* to update our code.
I feel at the very least, the fact that the MIME type returned also
includes encoding information, and the format of this encoding
information, needs to be documented in the manual, and likely the
UPGRADING guide.
[2009-07-12 23:16:53] scott...@php.net
As Pierre has said already this is the way libmagic works and it
matches the RFC for mime type.
The charset on non text documents is also valid, even if it just says
binary.
So there isn't a BC break here unless you were using the mime type for
something else.
[2009-07-12 13:33:48] paj...@php.net
The fileinfo extension has been bundled in PHP (5.3 and later). The
development takes place only in PHP, not anymore in PECL.
Old releases may have issues or may not be compliant with the RFC. Like
it or not, that's a fact.
For the binary data, the charset will obviously be set to binary:
image/gif; charset=binary
It is a documentation, not a bug neither a BC break.
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/48885
--
Edit this bug report at http://bugs.php.net/?id=48885&edit=1
#48885 [Tbd->Csd]: finfo returns mime type + charset when FILEINFO_MIME is used
ID: 48885
Updated by: scott...@php.net
Reported By: majkl578 at gmail dot com
-Status: To be documented
+Status: Closed
Bug Type: Filesystem function related
Operating System: Linux Debian
PHP Version: 5.3.0
Previous Comments:
[2009-07-27 03:16:33] s...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=286383
Log: Update documentation to reflect change with the internal libmagic
updates. See bug #48885
[2009-07-27 02:55:44] scott...@php.net
Looked into this tonight again and from 5.3+ there are two new
constants available, FILEINFO_MIME_TYPE provides the old behavior.
I'll add them both to the documentation tonight.
[2009-07-26 22:31:17] scott...@php.net
Matthew, you can get the behavior with PHP 5.2 if you link against a
newer version of libmagic. This wasn't a change to any of the PHP
wrapper code in this case.
So yes it might be a BC break for you, but in reality its a bug fix.
[2009-07-26 21:48:21] paj...@php.net
Matthew,
That's exactly why the status of this report is set to "to be
documented".
[2009-07-26 21:43:19] matthew at zend dot com
I beg to differ a bit here with the assertion that the change is not a
BC break.
Consider this: in versions prior to 5.3.0, one could do a match like
this:
$finfo = new finfo(FILEINFO_MIME);
$type = $finfo->file($filename);
if (!in_array($type, array('image/jpeg', 'image/jpg'))) {
echo "Invalid image type.";
} else {
echo "JPEG found."
}
Now, with 5.3.0, this changes; the same assertion no longer works. This
is in fact exactly an issue we had with Zend_Validate_File_MimeType when
testing against PHP 5.3.0 -- matching that worked in 5.2.x now no longer
works in 5.3.0. We have altered our library to handle the strings
returned by both versions, but that exactly disproves your point: if the
new behavior were BC, we wouldn't *need* to update our code.
I feel at the very least, the fact that the MIME type returned also
includes encoding information, and the format of this encoding
information, needs to be documented in the manual, and likely the
UPGRADING guide.
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/48885
--
Edit this bug report at http://bugs.php.net/?id=48885&edit=1
#45989 [Tbd]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: scott...@php.net
Reported By: steven at acko dot net
Status: To be documented
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
New Comment:
This is in 5.3 now, you can use json_last_error() to check if a syntax
error occurred rather than reading the return value.
Previous Comments:
[2008-12-23 11:24:10] bruno dot p dot reis at gmail dot com
I agree with kevin at metalaxe dot com,
throwing an exception (may be even a InvalidArgumentException) on
malformed json would be a much more decent way to say the json is
invalid and would clarify a lot the behaviour.
Other good thing would be another function just to check if a json is
valid or not.
[2008-12-12 23:21:57] scott...@php.net
Applied the patch provided by magicaltux
[2008-12-12 07:51:16] kevin at metalaxe dot com
The JSON spec states:
"
A JSON text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names.
A JSON text is a serialized object or array.
"
So, in order to maintain compliance, PHP must also support
non-objects/arrays as input properly.
If I understand your patch correctly:
If the input is json_decode("null"); the output would be NULL (I saw no
test case for null input in the patch itself). We would have no way of
knowing a problem exists if one were to have an input of
json_decode('[');.
Can't this function throw an exception on failure? Failing that,could
we at least get a PHP warning? Otherwise it will be impossible to full
rely on this function in the case where null is the actual input...
[2008-12-03 22:29:58] magical...@php.net
And here are patches against PHP_5_3 and HEAD:
http://ookoo.org/svn/snip/php_5_3-json-returntype-final-fix.patch
http://ookoo.org/svn/snip/php_head-json-returntype-final-fix.patch
Some tests now work on json on HEAD (less failure than what's currently
displayed on gcov.php.net) but still two fails. As those failures are
not within the scope of this bug (and are specific to HEAD) they be
fixed in different patches.
I believe that once this is commited to the CVS, this bug should be
marked as "To be documented". I also believe till wants to submit some
additional tests for those this issue...
[2008-12-03 21:17:33] magical...@php.net
Just a note for documentation:
http://docs.php.net/json_decode
Right now the documentation says the function returns an object, OR an
array. This is not strictly true as it may return a string, a boolean,
an integer, a double... depending on the input.
Also, the fact json_decode() may return NULL on error isn't explicitly
documented either, instead some examples which happens to return NULL
with the current implementation are provided. I think it would be a good
idea to explicitly document this behavior, if the change I'm proposing
here is accepted.
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/45989
--
Edit this bug report at http://bugs.php.net/?id=45989&edit=1
#45989 [Tbd->Csd]: json_decode() passes through certain invalid JSON strings
ID: 45989
Updated by: scott...@php.net
Reported By: steven at acko dot net
-Status: To be documented
+Status: Closed
Bug Type: JSON related
Operating System: Mac OS X
PHP Version: 5.2.6
Previous Comments:
[2009-07-27 03:44:38] scott...@php.net
This is in 5.3 now, you can use json_last_error() to check if a syntax
error occurred rather than reading the return value.
[2008-12-23 11:24:10] bruno dot p dot reis at gmail dot com
I agree with kevin at metalaxe dot com,
throwing an exception (may be even a InvalidArgumentException) on
malformed json would be a much more decent way to say the json is
invalid and would clarify a lot the behaviour.
Other good thing would be another function just to check if a json is
valid or not.
[2008-12-12 23:21:57] scott...@php.net
Applied the patch provided by magicaltux
[2008-12-12 07:51:16] kevin at metalaxe dot com
The JSON spec states:
"
A JSON text is a sequence of tokens. The set of tokens includes six
structural characters, strings, numbers, and three literal names.
A JSON text is a serialized object or array.
"
So, in order to maintain compliance, PHP must also support
non-objects/arrays as input properly.
If I understand your patch correctly:
If the input is json_decode("null"); the output would be NULL (I saw no
test case for null input in the patch itself). We would have no way of
knowing a problem exists if one were to have an input of
json_decode('[');.
Can't this function throw an exception on failure? Failing that,could
we at least get a PHP warning? Otherwise it will be impossible to full
rely on this function in the case where null is the actual input...
[2008-12-03 22:29:58] magical...@php.net
And here are patches against PHP_5_3 and HEAD:
http://ookoo.org/svn/snip/php_5_3-json-returntype-final-fix.patch
http://ookoo.org/svn/snip/php_head-json-returntype-final-fix.patch
Some tests now work on json on HEAD (less failure than what's currently
displayed on gcov.php.net) but still two fails. As those failures are
not within the scope of this bug (and are specific to HEAD) they be
fixed in different patches.
I believe that once this is commited to the CVS, this bug should be
marked as "To be documented". I also believe till wants to submit some
additional tests for those this 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/45989
--
Edit this bug report at http://bugs.php.net/?id=45989&edit=1
#49075 [Opn->Bgs]: $_POST
ID: 49075
Updated by: scott...@php.net
Reported By: DALamberty at hotmail dot com
-Status: Open
+Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows XP
PHP Version: 5.3.0
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.
.
Previous Comments:
[2009-07-27 13:45:03] DALamberty at hotmail dot com
Description:
I am trying to pass data from a text field thru $_POST to a varialbe
while the text field is blank because it hasn't been filled in I get a
undefined index warning from the names assigned to the text fields.
I have tryed assigning a starting value to the text fields, but I still
get the undefined index. I have tryed the ISSET() and EMPTY()
on the variable thru $_POST but it doesn't allow the fields to be
populated when its time to populate.
Reproduce code:
---
$var = $_POST['var']; $edit = isset($_POST['edit']); $editto =
isset($_POST['editto']);
print "
";
if ($edit) {
print "
SSN:
";
}
if ($editto) {
print "$var"
}
Actual result:
--
before information is input:
Notice: undefined index: var in C:\wamp\www\folder\form.php on line ##
after text is entered into text field the notice goes away.
I have tryed ISSET and EMPTY on the varialbe that is suppose to recieve
the text but it then doesn't transfer any text.
--
Edit this bug report at http://bugs.php.net/?id=49075&edit=1
#49079 [Opn->Bgs]: date calls for year (Y) returns 0000
ID: 49079 Updated by: scott...@php.net Reported By: hennessy at thoughtcrime dot com -Status: Open +Status: Bogus Bug Type: Date/time related Operating System: Solaris 10 PHP Version: 5.2.10 New Comment: It's already been reported in bug #48276 The patch that we used is available http://svn.php.net/viewvc/php/php-src/trunk/ext/date/php_date.c?r1=282532&r2=282538&view=patch Previous Comments: [2009-07-27 22:32:18] hennessy at thoughtcrime dot com Much obliged, though local corporate policy demands the use of the latest stable version.. When the next stable point release (assume 5.2.11) goes live I'll probably pull that but for now the patch will probably work OK... (and no, I didn't write the policy, I just suffer under it :p)) [2009-07-27 22:29:47] der...@php.net Please try using this snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2009-07-27 21:59:10] hennessy at thoughtcrime dot com Description: When referencing a 4-digit year on a Solaris 10 host with php 5.2.10, one of my developers was getting '' . Bug 48276 relates to this but was submitted for php5.3 . I put a patch in the 'Reproduce code' section that 'fixes' it.. Reproduce code: --- --- php-5.2.10/ext/date/php_date.c 2009-07-27 17:55:06.192343000 -0400 +++ php-5.2.10.1/ext/date/php_date.c2009-07-27 16:44:23.297327000 -0400 @@ -798,7 +798,8 @@ /* year */ case 'L': length = slprintf(buffer, 32, "%d", timelib_is_leap((int) t->y)); break; case 'y': length = slprintf(buffer, 32, "%02d", (int) t->y % 100); break; - case 'Y': length = slprintf(buffer, 32, "%s%04ld", t->y < 0 ? "-" : "", llabs(t->y)); break; + /* case 'Y': length = slprintf(buffer, 32, "%s%04ld", t->y < 0 ? "-" : "", llabs(t->y)); break; */ + case 'Y': length = slprintf(buffer, 32, "%d", (int) t->y); break; /* time */ case 'a': length = slprintf(buffer, 32, "%s", t->h >= 12 ? "pm" : "am"); break; -- Edit this bug report at http://bugs.php.net/?id=49079&edit=1
#49096 [Opn->Fbk]: json_encode has side effect
ID: 49096
Updated by: scott...@php.net
Reported By: xiezhenye at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: JSON related
Operating System: *
PHP Version: 5.2.10
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.
Output from what you've given is:
Test Object
(
[data:protected] => Array
(
[a] => 1
[b] => 2
)
)
Test Object
(
[data:protected] => Array
(
[a] => 1
[b] => 2
)
)
Previous Comments:
[2009-07-29 09:33:28] xiezhenye at gmail dot com
addition:
it will apears when the properties are protected or private.
[2009-07-29 09:28:00] xiezhenye at gmail dot com
Description:
json_encode has side effect and may affect array propterty and cause
RECURSION.
Reproduce code:
---
class Test {
protected $data;
function __construct($data) {
$this->data = $data;
}
}
$t = new Test(array('a'=>1, 'b'=>2));
print_r($t);
json_encode($t);
print_r($t);
Expected result:
Test Object
(
[data:protected] => Array
(
[a] => 1
[b] => 2
)
)
Test Object
(
[data:protected] => Array
(
[a] => 1
[b] => 2
)
)
Actual result:
--
Test Object
(
[data:protected] => Array
(
[a] => 1
[b] => 2
)
)
Test Object
(
[data:protected] => Array
*RECURSION*
)
--
Edit this bug report at http://bugs.php.net/?id=49096&edit=1
#49097 [Opn->Bgs]: Boolean type casting print problem
ID: 49097 Updated by: scott...@php.net Reported By: mkrasuski at infico dot pl -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Windows 7/XP PHP Version: 5.3.0 New Comment: All works here, the cast of a bool to string is "". '; echo (string) !$b; echo ''; echo (bool) !$b; echo ''; echo (int) !$b; echo ''; echo 'Should be true: ' . ((bool) $b); echo ''; var_dump(!$b); ?> Expected result: Should be false: false false // or 0? false 0 Should be true: true bool(false) Actual result: -- Should be false: 0 Should be true: 1 bool(false) -- Edit this bug report at http://bugs.php.net/?id=49097&edit=1
#49097 [Bgs]: Boolean type casting print problem
ID: 49097
Updated by: scott...@php.net
Reported By: mkrasuski at infico dot pl
Status: Bogus
Bug Type: Output Control
Operating System: Windows 7/XP
PHP Version: 5.3.0
New Comment:
You need to be able to get consistent behavior regardless of the cast,
not everyone is just printing the output.
$false = false;
if ((string)$false)) { die("oops"); }
If the typecast made it return "false" then you'd see the oops here.
Previous Comments:
[2009-07-29 12:33:19] mkrasuski at infico dot pl
One more thing.
> false has to be an empty string to correctly evaluate to false.
> No bug here.
May I ask, why? When casting '153 foo' to int you get 153. Why, when
casting 'false' (or 'FALSE', whatever) you get 1 (true), not 0 (false)?
PHP is a script language, it should the difference, IMO.)
[2009-07-29 12:24:15] mkrasuski at infico dot pl
Ok about string. But what about casting to bool (same problem).)
[2009-07-29 11:56:20] ras...@php.net
false has to be an empty string to correctly evaluate to false. No bug
here.
[2009-07-29 11:51:24] mkrasuski at infico dot pl
You missunderstood me. The cast of a bool(false) is "" but cast of a
bool(true) is "1". IMO it should be "false" and "true", or, at least "0"
and "1".)
[2009-07-29 11:38:31] scott...@php.net
All works here, the cast of a bool to string is "".
http://bugs.php.net/49097
--
Edit this bug report at http://bugs.php.net/?id=49097&edit=1
#48880 [NoF->Opn]: Random Appearing open_basedir problem
ID: 48880 Updated by: scott...@php.net Reported By: brwarner at rogers dot com -Status: No Feedback +Status: Open Bug Type: Safe Mode/open_basedir Operating System: * PHP Version: 5.3.0 Previous Comments: [2009-07-29 12:19:41] lukas dot starecek at qcm dot cz Problem persists and ticket was suspended and no body except author or php developers can't change status to open. Realy annoying... [2009-07-29 01:00:00] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2009-07-26 07:17:07] duchesne7 at gmail dot com I confirm this bug under Fedora 11 x64 with Apache 2.2.10 and PHP 5.3.0 (also tryed last SVN with no luck). Seems to be some sort of memory corruption since I sometimes see HTTP headers in the allowed paths, like: File(/home/cpanel/index.php) is not within the allowed path(s): (ww\tX-Powered-By: P) in Unknown on line 0 It happens whenever open_basedir is modified at runtime (either with php_admin_value in httpd.conf or with an extension that I use which reset open_basedir according to regex rules before script execution.) [2009-07-25 16:06:26] server at grow-werbeagentur dot de Confirm this Bug. Still persists with 200907251430 went back to 5.2.10 now, cause this is very anyoing.. The weird thing though is, that I tested the 5.3.0 release on our dev server first with no errors at all but when installing it on our production servers, which are configured exactly the same as our dev, I get this random open_basedir error.. weird.. [2009-07-22 16:19:47] hristozov at gmail dot com The problem persists with 200907221430. 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/48880 -- Edit this bug report at http://bugs.php.net/?id=48880&edit=1
#49099 [Opn->Bgs]: open_basedir defined in httpd.conf/vhost strange behaviour (memory leakage ?)
ID: 49099 Updated by: scott...@php.net Reported By: lukas dot starecek at qcm dot cz -Status: Open +Status: Bogus Bug Type: Safe Mode/open_basedir Operating System: Linux RedHat PHP Version: 5.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. We can open bug reports if you just email any php.net address who participated in the bug report. Previous Comments: [2009-07-29 12:44:20] lukas dot starecek at qcm dot cz Description: I aplogize, but I would like to notice you about bug explained here: http://bugs.php.net/bug.php?id=48744 and here http://bugs.php.net/bug.php?id=48880 These bugs persist in CVS 200907251430 and tickets are suspended, original posters didn't reopen them and others are not allowed to reopen. Problem still persist and behavior is well explained by peoples there so I will not repeat it here. I know you probably mark this ticket as bogus or duplicate and it realy is, but I don't know any other way how to reopen ticket of somebody else or how to notice you about another suspended ticket. My apologies Lukas Starecek -- Edit this bug report at http://bugs.php.net/?id=49099&edit=1
#49087 [Csd->Bgs]: Session: PHP cannot serialize strings in an object that contain apostrophes
ID: 49087 Updated by: scott...@php.net Reported By: anis at boubaker dot ca -Status: Closed +Status: Bogus Bug Type: Session related Operating System: Linux Ubuntu PHP Version: 5.3.0 Previous Comments: [2009-07-28 19:30:10] anis at boubaker dot ca It was not related to session management but PDO throwing an exception because of an SQL error) [2009-07-28 15:51:35] j...@php.net Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for some invalid SQL.. [2009-07-28 15:51:19] j...@php.net Can your reproduce this without PDO? Please try simplify the code to bare minimum and to not contain such requirements. Now it might be anything throwing exception, most likely PDO for inv [2009-07-28 13:40:13] anis at boubaker dot ca Description: When we use session-set-save-handler to save session data in database and we want to save an object that encapsulates strings, we get the following exception if the string(s) contains an apostrophe. The exception raised is: Fatal error: Exception thrown without a stack frame in Unknown on line 0 Reproduce code: --- --- >From manual page: function.session-set-save-handler --- Please find the source code (slightly more than 20 lines) at this URL: http://www.cibaxion.com/php/PHPBug-AnisBoubaker.txt Expected result: No exception raised, session's data saved into database. Actual result: -- Fatal error: Exception thrown without a stack frame in Unknown on line 0 -- Edit this bug report at http://bugs.php.net/?id=49087&edit=1
#48930 [Asn->Ana]: __COMPILER_HALT_OFFSET__ incorrect in PHP>=5.3
ID: 48930 Updated by: scott...@php.net Reported By: adam-phpbugs at adam dot gs -Status: Assigned +Status: Analyzed Bug Type: Scripting Engine problem Operating System: * PHP Version: 5.3.0 Assigned To: scottmac New Comment: The sapi/cli/php_cli.c code will read forward when it see's a shebang to the next line. The file is already seeked by the time the scanner gets a change to look at it. The zend_get_scanned_file_offset() doesn't know about this because by the time the scanner is started the bytes are already long gone. Short of a global variable I'm not seeing a clean way to fix this. Previous Comments: [2009-08-02 23:47:35] adam-phpbugs at adam dot gs anyone? [2009-07-16 00:23:45] ka...@php.net Scott, you worked on the re2c switch, any chance you can clarrify this one? [2009-07-15 17:40:49] adam-phpbugs at adam dot gs Description: Starting in PHP 5.3.0, php no longer includes the shebang when calculating the __COMPILER_HALT_OFFSET__. Reproduce code: --- #!/usr/bin/php http://bugs.php.net/?id=48930&edit=1
#49138 [Opn->Bgs]: Extension dbase missing
ID: 49138 Updated by: scott...@php.net Reported By: sander at procurios dot nl -Status: Open +Status: Bogus Bug Type: dBase related Operating System: * PHP Version: 5.3.0 New Comment: There is no maintainer for the package, it's been moved to PECL but someone is required to do a release to make it appear on the website. You can do a SVN checkout from http://svn.php.net/repository/pecl/dbase/ Previous Comments: [2009-08-03 10:12:39] sander at procurios dot nl Description: According to the PHP 5.3.0 changelog of "30-June-2009" the ext/dbase has been moved to PECL. However, when searching for this package on the PECL website no results can be found. Seeing that dbase is not a PECL package yet, a bug report on their website is a bit "useless". Someone already mentioned something about this on the PEAR forums apparently ( see: http://www.pear-forum.org/post-5098.html ), but seeing that this was mentioned in the 5.3.0 changelog I thought it better to file a bug report here. -- Edit this bug report at http://bugs.php.net/?id=49138&edit=1
#49146 [Opn->Bgs]: strtr cuts char from the end
ID: 49146 Updated by: scott...@php.net Reported By: juho dot karvilainen at bmf dot wz dot cz -Status: Open +Status: Bogus Bug Type: Output Control Operating System: Win XP PHP Version: 5.2.10 New Comment: Closing PHP tags always eat the newline after it. Previous Comments: [2009-08-04 01:36:45] juho dot karvilainen at bmf dot wz dot cz Description: looks like the strtr() function (when used with array as 2nd argument) nibbles a character from the end when it has nothing to replace. (on UTF-8 page) Reproduce code: --- '\"',"'">'\'','/'=>'\/')); } ?> line1... line2... Expected result: line1...480 line2 Actual result: -- line1...48line2 -- Edit this bug report at http://bugs.php.net/?id=49146&edit=1
#49146 [Bgs]: strtr cuts char from the end
ID: 49146
Updated by: scott...@php.net
Reported By: juho dot karvilainen at bmf dot wz dot cz
Status: Bogus
Bug Type: Output Control
Operating System: Win XP
PHP Version: 5.2.10
New Comment:
Your array is also malformed.
array('"'=>'\"',"'">'\'','/'=>'\/')
array(3) {
["""]=>
string(2) "\""
[0]=>
bool(false)
["/"]=>
string(2) "\/"
}
Previous Comments:
[2009-08-04 01:38:13] scott...@php.net
Closing PHP tags always eat the newline after it.
[2009-08-04 01:36:45] juho dot karvilainen at bmf dot wz dot cz
Description:
looks like the strtr() function (when used with array as 2nd argument)
nibbles a character from the end when it has nothing to replace. (on
UTF-8 page)
Reproduce code:
---
'\"',"'">'\'','/'=>'\/'));
}
?>
line1...
line2...
Expected result:
line1...480
line2
Actual result:
--
line1...48line2
--
Edit this bug report at http://bugs.php.net/?id=49146&edit=1
#49152 [Opn->Bgs]: Additional value $_SERVER
ID: 49152 Updated by: scott...@php.net Reported By: ruediger dot severit at de dot bertrandt dot com -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: XP PHP Version: 5.3.0 New Comment: See the __LINE__ constant and you'll also find __FILE__ and __DIR__ Previous Comments: [2009-08-04 13:13:24] ruediger dot severit at de dot bertrandt dot com Description: It would be nice to have an additional element in the $_SERVER variable which shows the actual line within the script where the command is placed: e.g: SOURCE: print "Debug line $_SERVER['script_line']: $to_be_debugged"; OUTPUT: Debug line 53: Hello Reproduce code: --- see description Expected result: see description Actual result: -- see description -- Edit this bug report at http://bugs.php.net/?id=49152&edit=1
#49163 [Csd->Bgs]: Exception Bug?
ID: 49163
Updated by: scott...@php.net
Reported By: coolgk at gmail dot com
-Status: Closed
+Status: Bogus
Bug Type: *General Issues
Operating System: ubuntu5.6
PHP Version: 6SVN-2009-08-05 (SVN)
Previous Comments:
[2009-08-05 03:55:51] coolgk at gmail dot com
found answer, exception cannot get caught in autoload
[2009-08-05 02:53:37] coolgk at gmail dot com
Description:
the script displays a fatal error, but the exception should have
stopped the script before the error happened, also the line number in
error message is wrong.
Reproduce code:
---
---
>From manual page: function.set-exception-handler
---
function test($e){
echo $e->getMessage();
}
set_exception_handler('test');
$x = new c();
function __autoload($className){
echo "Autoload";
throw new Exception(' Failed');
}
Expected result:
Autoload Failed
Actual result:
--
Autoload
Fatal error: Class 'c2' not found in
/home/coolgk/public_html/misc/Framework/public/test3.php on line 16
--
Edit this bug report at http://bugs.php.net/?id=49163&edit=1
#49166 [Opn->Bgs]: called to undefined function socket_create
ID: 49166 Updated by: scott...@php.net Reported By: s dot daudell at boldwebservices dot com -Status: Open +Status: Bogus Bug Type: Sockets related Operating System: Windows XP Pro PHP Version: 5.3.0 New Comment: You probably have a different php.ini being loaded for the CLI. Regardless this isn't a bug and a support issue. Previous Comments: [2009-08-05 22:48:50] s dot daudell at boldwebservices dot com ok here is something i found. when i run this script in a web browser, it validates to bool(true), which explains why it is loaded in phpinfo() yet when i run this script in the command prompt, it returns bool(false) what would be causing the cmd to not access that extension? [2009-08-05 21:47:00] j...@php.net It's not really loaded if the function doesn't exist, try this: [2009-08-05 15:29:05] s dot daudell at boldwebservices dot com i commented out all of my other code and inserted only the script you provided. it still results in a fatal error. I check the phpinfo() output once again, still says sockets support enabled. [2009-08-05 14:32:29] j...@php.net It's quite impossible for this function not exist if the sockets extensions is really loaded. Please check again. And this time with this script: [2009-08-05 08:05:48] s dot daudell at boldwebservices dot com As i mentioned, sockets are enabled, the extension shows up as loaded, in the WAMP interface, in phpinfo(), and in php.ini However when the function is called, it results in a fatal error. This same script worked fine in 5.2.6 I was installing my software on a new machine with the newer version of PHP, following my same setup procedures that worked before, and now it doesnt 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/49166 -- Edit this bug report at http://bugs.php.net/?id=49166&edit=1
