#19292 [Com]: random error: open_basedir restriction in effect. File is in wrong directory
ID: 19292 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: linux PHP Version: 4.3.0-dev,4.2.3 New Comment: Is somebody working on this critical bug in php 4.3.0?? Bug was opened 8 sep and now it isn't even the same year... This is a severe problem for all hosting companies since they have to turn of open_basedir to get things going without errors. Previous Comments: [2003-01-09 12:42:13] [EMAIL PROTECTED] I have just tried to EXPLICITLY set "php_admin_flag safe_mode off" to ALL virtual hosts, which should not be restricted with safe mode and it seems to help. So the problem is here only when I rely on the default setting in php.ini file (where I have safe mode off by default) and when there is AT LEAST one virtual host with safe_mode enabled. [2003-01-09 12:36:48] [EMAIL PROTECTED] If a have one virt. host with safe_mode turned on and the other one with safe_mode off, the SECOND one (with safe_mode off from default ini setting) sometimes seems to have safe_mode turned on, until next reload. When I tried to replace safe_mode with open_basedir restrictions, this problem was the same one, which is described above. [2003-01-09 04:36:33] [EMAIL PROTECTED] I wrote regression tests for safe mode recently which trigger this bug reliably when upgrading to 4.3.0 from 4.2.2 on Apache 2.0.40. In the Apache config I use: (erring on the side of verbosity) php_admin_value safe_mode 1 php_admin_value safe_mode_exec_dir /bin php_admin_value open_basedir / php_admin_value display_errors 0 php_admin_value log_errors 1 php_admin_value safe_mode_allowed_env_vars FOO_ php_admin_value safe_mode_protected_env_vars FOO_FEE Then: /local/qa/perl-framework/t/htdocs/php/safemode/readfile.php contains: The server error log gets this output for the script: PHP Warning: Unknown(): open_basedir restriction in effect. File(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php) is not within the allowed path(s): (/) in Unknown on line 0 PHP Warning: Unknown(/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php): failed to create stream: Operation not permitted in Unknown on line 0 PHP Warning: Unknown(): Failed opening '/local/qa/perl-framework/t/htdocs/php/safemode/readfile.php' for inclusion (include_path='.:/usr/share/pear') in Unknown on line 0 [2003-01-06 11:29:06] [EMAIL PROTECTED] Getting totally wrong dir in the output of the error mess open_basedir restriction in effect. File(index.php) is not within the allowed path(s): (/home/userB) Getting this error when surfing to userA which has open_basedir set to /home/userA in apache virthost, one gets that access to userB home isn't granted. This might not be a fault in the open_basedir code, but for some reason it get's the wrong open_basedir dir from the calling function. If someone could take a deeper look at this it would be nice, hard to explain to all customers that this problem is out of our hands to fix. [2003-01-06 10:33:12] [EMAIL PROTECTED] Bug confirmed on FreeBSD 4.6 with php 4.3.0. Totally random it seems. 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/19292 -- Edit this bug report at http://bugs.php.net/?id=19292&edit=1
#21564 [NEW]: corrupted paths coming to open_basedir
From: [EMAIL PROTECTED] Operating system: freebsd 4.6 PHP version: 4.3.0 PHP Bug Type: Apache related Bug description: corrupted paths coming to open_basedir If one is having open_basedir on in one virtualhost, that open_basedir is sometimes applied to another virtualhost without open_basedir restriction. This is NOT a bug in the open_basedir code, but the open_basedir function is feed with the wrong path, and triggers on that one. Looks like some mem corruption or init problem that doesn't clean the variables correctly before serving a new request. Problem occours when a apache child that has served a open_basedir restriced virtualhost, and the next request doesn't have open_basedir on or does have a different open_basedir path. Looks like this only applies to newly started apache childs also. This is critical. './configure' '--with-apxs=/usr/local/sbin/apxs' '--with-config-file-path=/usr/local/etc' '--enable-versioning' '--with-regex=system' '--without-gd' '--without-mysql' '--with-gd=/usr/local' '--enable-gd-native-ttf' '--with-freetype-dir=/usr/local' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib' '--with-mysql=/usr/local' '--with-pspell=/usr/local' '--prefix=/usr/local' 'i386-portbld-freebsd4.6' -- Edit bug report at http://bugs.php.net/?id=21564&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21564&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21564&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21564&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21564&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21564&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21564&r=support Expected behavior: http://bugs.php.net/fix.php?id=21564&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=21564&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21564&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21564&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21564&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21564&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21564&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21564&r=gnused
#20190 [Com]: Random mem corruption: zend_get_executed_filename() mismatch
ID: 20190 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating System: FreeBSD PHP Version: 4.3.0-dev New Comment: Have this problem on 4.3.0 RELEASE! and 4.2.3 upgrade Version on this bug please. Previous Comments: [2003-01-16 17:22:32] [EMAIL PROTECTED] I upgraded to 4.3 the other day and ran into this problem big time. Today I went back to 4.2.3 and am still running into the error(s) occasionally... I've made sure that PHP 4.2.3 is installed and running and (according to phpinfo()) it is. Apache 1.3.27 FreeeBSD 4.7p-1 PHP 4.2.3 and PHP 4.3.0 Ack! [2002-11-14 15:45:26] [EMAIL PROTECTED] Hi, >when this bug occurs, to confirm the wrong ini values? Ok, i'll do that. >1) there are 2 vhosts, where vhost A has open_basedir >restriction in effect, via php_admin_value in > context and vhost B >doesn't Nope. Both virtal servers have a open basedir restriction turned on here. >2) vhost B includes a file and subsequently vhost A >includes one. That's correct. For some strange reason, the bug does not happen on a test setup with the same apache config. Of course I was not able to copy all web-stuff over and simulate true load. So it is very difficult to reproduce. Martin [2002-11-14 11:39:16] [EMAIL PROTECTED] Could you test the values: registered_zend_ini_directives and EG(ini_directives) when this bug occurs, to confirm the wrong ini values? I'm trying to reproduce this, can you confirm, that this bug happens when: 1) there are 2 vhosts, where vhost A has open_basedir restriction in effect, via php_admin_value in context and vhost B doesn't 2) vhost B includes a file and subsequently vhost A includes one. So in order to increase the chances of hitting this bug, one could: set Max and MinSpareServers to 1 and request the different vhosts? [2002-11-14 03:09:27] [EMAIL PROTECTED] I can confirm that it still happens with the latest cvs 4.3 snapshot from yesterday (2002-11-13). If I get some pointers, I could add some debug code. Funny thing is that the webserver runs about 30min to 2 hours ok, and then I hit begin to hit the bug. Always after the same files: It's always the same, you can see it because the filename has two slashes /www/doc/customer2/html/visions/php// This path really exists. The thing that does not exist, is the file wrapper.php. It exists in the customer1 path so we really really should not end here. Nov 14 05:37:24 server-bsl1 httpd: open_basedir: Used openbasedir /www/doc/custermer1, file /www/doc/customer2/html/visions/php//wrapper.php executed_filename (/www/doc/customer1/index.php) It looks to me that this case only happens after the apache child has processed a include as last thing and then preceeds again a different webserver. Anyone knows more ? Martin [2002-11-02 14:27:04] [EMAIL PROTECTED] I'd like to jump this upto a critical standing. Mainly because it will get someone else to review the patch. Hopefully that someone else will be a bit more intimately knowledgable with the whole Zend memory system than I. 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/20190 -- Edit this bug report at http://bugs.php.net/?id=20190&edit=1
#22101 [Com]: Wrong behaviour of open_basedir restriction
ID: 22101 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: Debian linux 2.4.19 PHP Version: 4.3.0 New Comment: I had the same problem and I was just about to submit a bug because upgrading from 4.2.3 to 4.3.0 breaks any vhosts that have open_basedir "/". Maybe it's an idea to update the documentation to reflect that 'none' can be used to override a restrictive default? -- raphidae <[EMAIL PROTECTED]> Previous Comments: [2003-02-13 13:18:26] [EMAIL PROTECTED] Hm. It's not only the root-dir (/). It doesn't work in other directories, either. e.g. my customer has a www-dir with hundrets of subdirectories. No Problem in 4.1.2! I had only to 'php_admin_flag open_basedir "/home/customer/www"'. Now with PHP 4.3.0 I have to include each subdir and its subdirs which brings me a lot of work. Sorry for bad engl. Greets Stefan [2003-02-13 00:51:38] [EMAIL PROTECTED] Sometimes there is... I only use open_basedir / (formerly though, now it's none) in apache configuration, since phpSysInfo needs to access few places outside the normal basedir /www. But *shrug* none seems to work, which it didn't do on the prev. version I had, 4.1.2 [2003-02-13 00:48:50] [EMAIL PROTECTED] There's no point in putting / as basedir, like Rasmus said. [2003-02-13 00:44:59] [EMAIL PROTECTED] it seems that you can't use '/' as the open_basedir (as you could do in php 4.1.2). Dunno, maybe it's a good 'sanity' restriction, since the bug with defining 'none' as open_basedir has been fixed. Well... it seems that this was perhaps a bug in the user end [2003-02-09 14:20:51] [EMAIL PROTECTED] I have the same Problem under RedHat 7.1 with PSA (Plesk Server Administrator) 5.x. It seems that PHP 4.3.0 doesn't set the Open_Basedir recursively to Subdirectories. This is really mean because I have to include each Subdirectory which I would have out of the SaveMode, in my httpd.conf. 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/22101 -- Edit this bug report at http://bugs.php.net/?id=22101&edit=1
#21337 [Fbk->Opn]: php crashes on ldap_sort
ID: 21337
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: Windows XP
PHP Version: 4.3.0
New Comment:
PHP crashed running from command line, using both CLI and CGI.
Previous Comments:
[2003-01-15 15:59:51] [EMAIL PROTECTED]
Does the same happen within command line, using PHP CLI ?
[2003-01-03 01:52:57] [EMAIL PROTECTED]
script used:
$ds = ldap_connect("mailservername")
if ($ds)
{
$ldapbind = ldap_bind($ds, $ldaprdn, $ldappass);
$sr=ldap_search($ds,"o=my org, c=NL", "cn=*");
ldap_sort($ds,$sr,"cn");
$info = ldap_get_entries($ds,$sr);
//what follows is retrieval of entries
}
script works ok if i leave ldap_sort out
it also crashes when i replace
ldap_sort($ds,$sr,"cn");
with
$sr = ldap_sort($ds,$sr,"cn");
or replacing cn with givenname.
I used the precompiled version of php 4.3 from php.net
[2003-01-02 14:06:44] [EMAIL PROTECTED]
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.
Could you please provide the smallest possible test script that could
be replicate the problem.
[2003-01-02 08:31:55] [EMAIL PROTECTED]
Im using apache 2.0.43 as my webserver.
My ldap server is MS Exchange 5.5.
on ldap_sort my PHP Script Interpreter crashes and gives out this
signature:
szAppName : php.exe szAppVer : 4.3.0.0 szModName : php4ts.dll
szModVer : 4.3.0.0 offset : 000ad517
--
Edit this bug report at http://bugs.php.net/?id=21337&edit=1
#18648 [Com]: Single entry form POST gives incorrect variable content
ID: 18648
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Apache2 related
Operating System: All
PHP Version: 5CVS-2003-01-29 (dev) / 4CVS-20020121 (stable)
New Comment:
Tested in RH8.0 + PHP 4.2.2 + Apache 2.
- Is ok when you add the 'enctype="multipart/form-data"' propety to the
form tag.
- Is ok when you send using GET method instead POST.
- Is ok when you send more than one field: if you have a text and a
button, if you send it pressing enter only the text send and the
problem occurs. When you press the button, text and button are send and
the problem not occur.
ciao.
Previous Comments:
[2003-02-03 12:36:09] [EMAIL PROTECTED]
I can _NOT_ reproduce this with Apache 2.0.44 and PHP 4.3.1-dev..
[2003-02-03 11:55:47] [EMAIL PROTECTED]
array(4) {
[0]=>
string(1) "1"
[1]=>
string(1) "2"
[2]=>
string(1) "1"
[3]=>
string(1) "2"
}
>From the latest snap's (php4-STABLE, php5). cvs commit (?) :)
[2003-01-31 19:52:37] [EMAIL PROTECTED]
Have Apache/2.0.44 (RedHat8.0 (LastUpdates) mod_ssl/2.0.44
OpenSSL/0.9.6b PHP/4.3.0
Starting Apache answers -
[root@delta bin]# httpd -DSSL
httpd: module "/usr/src/php-4.3.0/sapi/apache2filter/sapi_apache2.c" is
not comp
atible with this version of Apache.
Please contact the vendor for the correct version.
Where troubles ?
[2003-01-30 03:52:45] [EMAIL PROTECTED]
[EMAIL PROTECTED], Thank you for the info!
Okay, updating version.
[2003-01-30 03:46:38] [EMAIL PROTECTED]
Not a single 'BUG' entry on the logs, grep'ed all of them.
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/18648
--
Edit this bug report at http://bugs.php.net/?id=18648&edit=1
#20685 [NEW]: UTF-8 encoding as ISO-8859-15
From: [EMAIL PROTECTED] Operating system: Windows XP PHP version: 4.2.1 PHP Bug Type: Feature/Change Request Bug description: UTF-8 encoding as ISO-8859-15 How can I UTF-8 encode the euro symbol? New symbols like the Euro are not correctly encoded by the current utf8_encode function. ISO has issued a new standard: ISO-8859-15, which is mostly like ISO-8859-1 except that it removes some rarely used characters (the old currency sign) and replaced it with the Euro sign. The feature request: a function to utf-8 encode a string, that also encodes the euro symbol correctly. -- Edit bug report at http://bugs.php.net/?id=20685&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20685&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20685&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20685&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20685&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20685&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20685&r=support Expected behavior: http://bugs.php.net/fix.php?id=20685&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20685&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20685&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20685&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20685&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20685&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20685&r=isapi
#20820 [NEW]: Session Variables are not passed using URL refresh
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.2.2 PHP Bug Type: Session related Bug description: Session Variables are not passed using URL refresh Hello, I recognized the following problem on the server of my provider using PHP 4.2.2: I register session varibles in my script and use URL-refresh to link to the next php-script. URL refresh in html: http://www.test.com/test.php";> The same error occurs using "onLoad" and link via JavaScript. What happened? The session was not passed to the next script, but it works fine with normal hyperreferences. I haven't seen this problem before! I run PHP 4.2.1 in the office on Win and IIS with the same session configurations in PHP and it works fine. Is this a problem of PHP 4.2.2 in general? Thank you! Best regards, Rudolf -- Edit bug report at http://bugs.php.net/?id=20820&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=20820&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=20820&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=20820&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=20820&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=20820&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=20820&r=support Expected behavior: http://bugs.php.net/fix.php?id=20820&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=20820&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=20820&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=20820&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=20820&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=20820&r=dst IIS Stability: http://bugs.php.net/fix.php?id=20820&r=isapi
#21265 [NEW]: unexpected low color depth
From: [EMAIL PROTECTED]
Operating system: Linux
PHP version: 4.3.0
PHP Bug Type: GD related
Bug description: unexpected low color depth
Hi!
Before switching to PHP 4.3.0 we could create a "nice" colored thumbnail
from an image via PHP and GD (1.8.x) with the following code:
$thumb = imagecreate($twidth, $theight);
$orig = @imagecreatefromjpeg($file);
if (!$orig) {
echo "Couldn't load JPEG image '$file'.";
exit();
}
imagecopyresized($thumb, $orig, 0, 0, 0, 0, $twidth,
$theight, $width, $height);
mkdir(dirname($thumbnail),0777);
imagejpeg($thumb,$thumbnail,65);
We had a switch statement for any supported image type (JPEG, GIF and
PNG). The created image is of course smaller but has the same color depth
as the original.
After using PHP 4.3.0 and its bundled GD2 library the image is also
created but the result has very less colors (maybe 16). I've put an
example here:
http://thoralf.log-out.net/tmp/php4.3.0.html
I'm not sure, if I did a mistake or if there is something missing now -
but it works with PHP4.2.2 very well.
The PHPInfo from the server can be found here:
http://m84.de/phpinfo.php
bye
Thoralf
--
Edit bug report at http://bugs.php.net/?id=21265&edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21265&r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21265&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21265&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21265&r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21265&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21265&r=support
Expected behavior: http://bugs.php.net/fix.php?id=21265&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21265&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21265&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21265&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21265&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21265&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21265&r=isapi
#21337 [Fbk->Opn]: php crashes on ldap_sort
ID: 21337
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: LDAP related
Operating System: Windows XP
PHP Version: 4.3.0
New Comment:
script used:
$ds = ldap_connect("mailservername")
if ($ds)
{
$ldapbind = ldap_bind($ds, $ldaprdn, $ldappass);
$sr=ldap_search($ds,"o=my org, c=NL", "cn=*");
ldap_sort($ds,$sr,"cn");
$info = ldap_get_entries($ds,$sr);
//what follows is retrieval of entries
}
script works ok if i leave ldap_sort out
it also crashes when i replace
ldap_sort($ds,$sr,"cn");
with
$sr = ldap_sort($ds,$sr,"cn");
or replacing cn with givenname.
I used the precompiled version of php 4.3 from php.net
Previous Comments:
[2003-01-02 14:06:44] [EMAIL PROTECTED]
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.
Could you please provide the smallest possible test script that could
be replicate the problem.
[2003-01-02 08:31:55] [EMAIL PROTECTED]
Im using apache 2.0.43 as my webserver.
My ldap server is MS Exchange 5.5.
on ldap_sort my PHP Script Interpreter crashes and gives out this
signature:
szAppName : php.exe szAppVer : 4.3.0.0 szModName : php4ts.dll
szModVer : 4.3.0.0 offset : 000ad517
--
Edit this bug report at http://bugs.php.net/?id=21337&edit=1
Bug #16637: Environnement variables collision
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.1.2 PHP Bug Type: *General Issues Bug description: Environnement variables collision Hello, After updating to MDK 8.2 - PHP 4.1.2. I encoutered serious troubles with my php website. I managed to solve it and relate it to an environnemental variable problem. This script : "; $c=1; $out[$c]=153.2; echo $out[$c].""; $den[$c]=153.2; echo $den[$c].""; phpinfo(); ?> Gives the following output : /dev/vc/ 1 153.2 This may be a problem, since a lot of new variables have been defined which have lower case names and are quite common ( examples : $out,$res, ...). Furthermore, the content of an array having the same name as predefined variables seems to be seriously affected. We found that defining the array with $out=array(); helps fixing the problem. I thought you might be interested. Best wishes, Raphael -- Edit bug report at http://bugs.php.net/?id=16637&edit=1 -- Fixed in CVS:http://bugs.php.net/fix.php?id=16637&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=16637&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=16637&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=16637&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=16637&r=support Expected behavior: http://bugs.php.net/fix.php?id=16637&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=16637&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=16637&r=submittedtwice
Bug #65499 [Com]: json_decode reports invalid literal as valid JSON
Edit report at https://bugs.php.net/bug.php?id=65499&edit=1 ID: 65499 Comment by: r...@php.net Reported by:m dot kurzyna at crystalpoint dot pl Summary:json_decode reports invalid literal as valid JSON Status: Closed Type: Bug Package:JSON related Operating System: Linux PHP Version:5.5.2 Block user comment: N Private report: N New Comment: As Fedora, Ubuntu and some other Linux distributions have switch to JSONC extension, you can report this strictness change in https://github.com/remicollet/pecl-json-c/issues?state=open Previous Comments: [2013-08-22 15:16:32] m dot kurzyna at crystalpoint dot pl I'm at Ubuntu. I've built current master (from git) and also didn't reproduce this behaviour so just as you suggest - it seems to be packagers problem. I will report to Ubuntu maintainers. [2013-08-22 11:34:15] yohg...@php.net It seems my fedora 19 x86_64 does this, while my PHP-5.5 branch don't on the same machine. It seems packager's issue. $ php https://bugs.php.net/bug.php?id=65499 -- Edit this bug report at https://bugs.php.net/bug.php?id=65499&edit=1
Bug #65446 [Com]: disk_total_space doesn't work with LVM
Edit report at https://bugs.php.net/bug.php?id=65446&edit=1 ID: 65446 Comment by: r...@php.net Reported by:puciek at gmail dot com Summary:disk_total_space doesn't work with LVM Status: Feedback Type: Bug Package:Filesystem function related Operating System: Centos, Gentoo, Ubuntu PHP Version:5.4.17 Block user comment: N Private report: N New Comment: I means which "exact" value for directory option. If you use "/dev/mapper/batty-root" which is only a file (ok, a special one) it will report about space in /dev (so 4G) If you use "/" it will report about space in / Previous Comments: [2013-08-27 10:29:08] puciek at gmail dot com Director inside LVM share which we want to measure ---- [2013-08-27 09:30:06] r...@php.net I was asking for the option given to the disk_total_space call. [2013-08-27 08:29:57] puciek at gmail dot com df with parameter "-h" changes the output data from bytes to more human readable format -h, --human-readable print sizes in human readable format (e.g., 1K 234M 2G) ---- [2013-08-27 08:26:32] r...@php.net I cannot reproduce, tested with PHP 5.4.19 / RHEL-6 PHP 5.5.3 / Fedora 19 As this function is a simple wrapper other the statvfs (or statfs), I don't think of a PHP bug. What is the option used in the test call ? [2013-08-13 21:21:13] puciek at gmail dot com Description: Running disk_total_space on a system that is using LVM it will return completely incorrect data. For example on a machine with result of "df -h" as follows: Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg-vg_root99G 47G 47G 50% / tmpfs 32G 0 32G 0% /dev/shm /dev/sda1194M 65M 120M 36% /boot /dev/mapper/vg-vg_backup 400G 33M 400G 1% /var/tmp /dev/mapper/vg-vg_mysql 950G 81G 870G 9% /data on this setup it will always return 32G. We get similar result on second machine with "df -h": Filesystem Size Used Avail Use% Mounted on /dev/mapper/batty-root 258G 217G 29G 89% / none4.0G 208K 4.0G 1% /dev none4.0G 0 4.0G 0% /dev/shm none4.0G 88K 4.0G 1% /var/run none4.0G 0 4.0G 0% /var/lock none4.0G 0 4.0G 0% /lib/init/rw none258G 217G 29G 89% /var/lib/ureadahead/debugfs where it will always return 4G. At first that it was because of outdated version of PHP, original tests were with PHP version 5.3.27 and 5.3.6, but then I was able to reproduce it on my testing box with Gentoo and PHP 5.4.17. -- Edit this bug report at https://bugs.php.net/bug.php?id=65446&edit=1
Bug #65564 [Com]: stack-buffer-overflow in DateTimeZone stuff caught by AddressSanitizer
Edit report at https://bugs.php.net/bug.php?id=65564&edit=1
ID: 65564
Comment by: r...@php.net
Reported by:dhiru dot kholia at gmail dot com
Summary:stack-buffer-overflow in DateTimeZone stuff caught
by AddressSanitizer
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Fedora 19
PHP Version:5.5.3
Block user comment: N
Private report: N
New Comment:
Reproduced php5.5-201308300430 snapshot.
This issue make 62 failed tests, all in date extension.
=
FAILED TEST SUMMARY
-
date_isodate_set() tests [ext/date/tests/012.phpt]
date_date_set() tests [ext/date/tests/013.phpt]
timezone_offset_get() tests [ext/date/tests/014.phpt]
Test clone on DateTimeZone objects
[ext/date/tests/DateTimeZone_clone_basic1.phpt]
Testing clone on objects whoose class derived from DateTimeZone class
[ext/date/tests/DateTimeZone_clone_basic2.phpt]
Test clone of DateTimeZOne objects
[ext/date/tests/DateTimeZone_clone_basic3.phpt]
Test new DateTimeZone() : basic functionality
[ext/date/tests/DateTimeZone_construct_basic.phpt]
Test serialization of DateTimeZone objects
[ext/date/tests/DateTimeZone_serialize_type_1.phpt]
Test serialization of DateTimeZone objects
[ext/date/tests/DateTimeZone_serialize_type_2.phpt]
Test serialization of DateTimeZone objects
[ext/date/tests/DateTimeZone_serialize_type_3.phpt]
Test clone of objects whoose class derived from DateTime class
[ext/date/tests/DateTime_clone_basic2.phpt]
Test clone of DateTime objects [ext/date/tests/DateTime_clone_basic3.phpt]
Test new DateTime() : basic functionality
[ext/date/tests/DateTime_construct_basic1.phpt]
Test new DateTime() function : usage variation - Passing unexpected values to
first argument $time. [ext/date/tests/DateTime_construct_variation1.phpt]
Test new DateTime() function : usage variation - Passing unexpected values to
second argument $timezone. [ext/date/tests/DateTime_construct_variation2.phpt]
Test DateTime::modify() function : usage variation - Passing unexpected values
to first argument $modify. [ext/date/tests/DateTime_modify_variation1.phpt]
Test serialization of DateTime objects [ext/date/tests/DateTime_serialize.phpt]
Test DateTime::setDate() function : usage variation - Passing unexpected values
to first argument $year. [ext/date/tests/DateTime_setDate_variation1.phpt]
Test DateTime::setDate() function : usage variation - Passing unexpected values
to second argument $month. [ext/date/tests/DateTime_setDate_variation2.phpt]
Test DateTime::setDate() function : usage variation - Passing unexpected values
to third argument $day. [ext/date/tests/DateTime_setDate_variation3.phpt]
Test DateTime::setISODate() function : usage variation - Passing unexpected
values to first argument $year.
[ext/date/tests/DateTime_setISODate_variation1.phpt]
Test DateTime::setISODate() function : usage variation - Passing unexpected
values to second argument $week.
[ext/date/tests/DateTime_setISODate_variation2.phpt]
Test DateTime::setISODate() function : usage variation - Passing unexpected
values to third argument $day.
[ext/date/tests/DateTime_setISODate_variation3.phpt]
Test DateTime::setTime() function : usage variation - Passing unexpected values
to first argument $hour. [ext/date/tests/DateTime_setTime_variation1.phpt]
Test DateTime::setTime() function : usage variation - Passing unexpected values
to second argument $minute. [ext/date/tests/DateTime_setTime_variation2.phpt]
Test DateTime::setTime() function : usage variation - Passing unexpected values
to third argument $second. [ext/date/tests/DateTime_setTime_variation3.phpt]
Bug #41523 (strtotime('-00-00 00:00:00') is parsed as 1999-11-30) (64 bit)
[ext/date/tests/bug41523-64bit.phpt]
Bug #45682 (Unable to var_dump(DateInterval)) [ext/date/tests/bug45682.phpt]
Bug #46108 (DateTime - Memory leak when unserializing)
[ext/date/tests/bug46108.phpt]
Bug #48097 (date_timezone_set function produces wrong datetime result)
[ext/date/tests/bug48097.phpt]
Bug #48678 (DateInterval segfaults when unserialising)
[ext/date/tests/bug48678.phpt]
Bug #49081 (DateTime::diff() mistake if start in January and interval > 28
days) [ext/date/tests/bug49081.phpt]
Bug #49778 (DateInterval::format("%a") is always zero when an interval is
created from an ISO string) [ext/date/tests/bug49778.phpt]
Bug #51866 (Lenient parsing with parseFromFormat) [ext/date/tests/bug51866.phpt]
Bug #52113 (Seg fault while creating (by unserialization) DatePeriod)
[ext/date/tests/bug52113.phpt]
Bug #52738 (Can't use new properties in class extended from DateInterval)
[ext/date/tests/bug52738.phpt]
Bug #52808 (Segfault when specifying interval as two dates)
[ext/date/tests/bug52808.phpt]
Bug #53437 (Crash when using
Bug #60633 [Com]: build warning
Edit report at https://bugs.php.net/bug.php?id=60633&edit=1 ID: 60633 Comment by: r...@php.net Reported by:fedora at famillecollet dot com Summary:build warning Status: Open Type: Bug Package:BC math related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2012-01-01 (snap) Block user comment: N Private report: N New Comment: @Mike, I can't find upstream for this library... So I don't know if we can fix those "trivial" build warning in the php tree (the reason why I kept this bug open, while I can have commit the patch) Previous Comments: [2013-10-02 09:39:06] m...@php.net Nevermind the last comment. [2013-10-02 09:27:26] m...@php.net Do we already patch this lib, or is it untouched? [2012-01-01 08:32:23] fedora at famillecollet dot com Description: Build warning Test script: --- make Expected result: No warning Actual result: -- /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c: In function '_bc_rec_mul': /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:14: warning: variable 'v0len' set but not used [-Wunused-but-set-variable] /home/rpmbuild/BUILD/php5.4-201112300630/ext/bcmath/libbcmath/src/recmul.c:186:7: warning: variable 'u0len' set but not used [-Wunused-but-set-variable] -- Edit this bug report at https://bugs.php.net/bug.php?id=60633&edit=1
[PHP-BUG] Bug #61288 [NEW]: pdo_mysql___construct_options_libmysql.phpt test fails
From: remi Operating system: GNU/Linux (Fedora 16) PHP version: 5.4.0 Package: MySQL related Bug Type: Bug Bug description:pdo_mysql___construct_options_libmysql.phpt test fails Description: When no connexion is available, this test should not fails but be skipped (as the others) Please see trivial patch attached Sorry, I don't find a "pdo_mysql" in package list Test script: --- pear run-tests pdo_mysql___construct_options_libmysql.phpt Expected result: Running 1 tests SKIP MySQL PDO->__construct(), libmysql only options[pdo_mysql___construct_options_libmysql.phpt](reason: SQLSTATE[28000] [1045] Access denied for user 'root'@'localhost' (using password: NO)) TOTAL TIME: 00:00 0 PASSED TESTS 1 SKIPPED TESTS Actual result: -- Running 1 tests FAIL MySQL PDO->__construct(), libmysql only options[pdo_mysql___construct_options_libmysql.phpt] wrote log to "/dev/shm/php-5.4.0/ext/pdo_mysql/tests/run-tests.log" TOTAL TIME: 00:01 0 PASSED TESTS 0 SKIPPED TESTS 1 FAILED TESTS: -- Edit bug report at https://bugs.php.net/bug.php?id=61288&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61288&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61288&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61288&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61288&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61288&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61288&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61288&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61288&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61288&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61288&r=support Expected behavior: https://bugs.php.net/fix.php?id=61288&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61288&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61288&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61288&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61288&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61288&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61288&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61288&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61288&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61288&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61288&r=mysqlcfg
[PHP-BUG] Bug #61291 [NEW]: tiger is broken
From: remi
Operating system: GNU/Linux (Fedora 16)
PHP version: 5.4.0
Package: hash related
Bug Type: Bug
Bug description:tiger is broken
Description:
mhash_001 and mash_003 fails.
For mhash 001
025+ MHASH_TIGER: string(48)
"fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
026+ MHASH_TIGER: string(48)
"953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
Some tests
==== PHP 5.1.6
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
PHP 5.3.10
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
PHP 5.4.0
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
=== PHP 5.4.0 with patch
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
--
Edit bug report at https://bugs.php.net/bug.php?id=61291&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61291&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61291&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61291&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61291&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61291&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61291&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61291&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61291&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61291&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61291&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61291&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61291&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61291&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61291&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61291&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61291&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61291&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61291&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61291&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61291&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61291&r=mysqlcfg
Bug #61291 [Com]: tiger is broken
Edit report at https://bugs.php.net/bug.php?id=61291&edit=1
ID: 61291
Comment by: r...@php.net
Reported by: r...@php.net
Summary:tiger is broken
Status: Open
Type: Bug
Package:hash related
Operating System: GNU/Linux (Fedora 16)
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
Seems related to
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/hash/hash_tiger.c?r1=321634&r2=322437
(8 * (0%8)) != 56
The patch fixes this, and the "old" tests.
I think, this will break the "new" tests (added after the regression was
introduce)
Previous Comments:
----
[2012-03-05 16:29:36] r...@php.net
Description:
mhash_001 and mash_003 fails.
For mhash 001
025+ MHASH_TIGER: string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
026+ MHASH_TIGER: string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
Some tests
PHP 5.1.6
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
PHP 5.3.10
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
==== PHP 5.4.0
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
=== PHP 5.4.0 with patch
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61291&edit=1
Bug #61291 [Com]: tiger is broken
Edit report at https://bugs.php.net/bug.php?id=61291&edit=1
ID: 61291
Comment by: r...@php.net
Reported by: r...@php.net
Summary:tiger is broken
Status: Not a bug
Type: Bug
Package:hash related
Operating System: GNU/Linux (Fedora 16)
PHP Version:5.4.0
Assigned To:mike
Block user comment: N
Private report: N
New Comment:
So, to clarify the fix for bug #60221
The new result is ok.
So, mhash_001.phpt and mash_003.phpt tests need to be fixed
So, if I have store hash results somewhere with php < 5.4.0, I won't be able to
check this with php >= 5.4.0 ?
Previous Comments:
[2012-03-06 12:01:27] m...@php.net
To clarify the situation, it's just a matter of how to display the hash:
http://pastie.org/3532887
[2012-03-06 08:50:02] m...@php.net
Hi Remi,
this is not a bug, it's the result of a fix for bug #60221
See alos bug #32463
Thanks,
Mike
----
[2012-03-05 16:34:20] r...@php.net
Seems related to
http://svn.php.net/viewvc/php/php-src/branches/PHP_5_4/ext/hash/hash_tiger.c?r1=321634&r2=322437
(8 * (0%8)) != 56
The patch fixes this, and the "old" tests.
I think, this will break the "new" tests (added after the regression was
introduce)
----
[2012-03-05 16:29:36] r...@php.net
Description:
mhash_001 and mash_003 fails.
For mhash 001
025+ MHASH_TIGER: string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
026+ MHASH_TIGER: string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
Some tests
PHP 5.1.6
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
PHP 5.3.10
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
PHP 5.4.0
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "953ac3799a01b9fdeb91aeab97207e67395cbb54300be00d"
=== PHP 5.4.0 with patch
php -r 'var_dump(bin2hex(mhash(MHASH_TIGER,"This is the test of the mhash
extension...")));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
php -r 'var_dump(bin2hex(hash("tiger192,3","This is the test of the mhash
extension...",true)));'
string(48) "fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39"
--
Edit this bug report at https://bugs.php.net/bug.php?id=61291&edit=1
Bug #64258 [Com]: XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet)
Edit report at https://bugs.php.net/bug.php?id=64258&edit=1 ID: 64258 Comment by: r...@php.net Reported by:spamik at yum dot pl Summary:XMLReader not compatibile with new libxml2 (undefined symbol: xmlTextReaderSet) Status: Open Type: Bug Package:XML Reader PHP Version:5.4.11 Block user comment: N Private report: N New Comment: Cannot reproduce. php 5.4.11 and 5.4.12 build against libxml2 and work as expected. Previous Comments: [2013-02-21 00:01:56] spamik at yum dot pl Description: datadata'; $xml->XML($xmldata); ?> php 5.4.11 compiled with libxml2 2.9.0 /usr/bin/php: symbol lookup error: /usr/bin/php: undefined symbol: xmlTextReaderSetup It works when php is compiled against libxml2 2.6.26 XMLReader is not compatibile with new libxml2 version. -- Edit this bug report at https://bugs.php.net/bug.php?id=64258&edit=1
Bug #64461 [Com]: Zend/zend_language_parser.h error with --enable-maintainer-zts in tarballs
Edit report at https://bugs.php.net/bug.php?id=64461&edit=1 ID: 64461 Comment by: r...@php.net Reported by:kevin dot waterson at gmail dot com Summary:Zend/zend_language_parser.h error with --enable-maintainer-zts in tarballs Status: Re-Opened Type: Bug Package:Compile Failure Operating System: Centos 6.3 PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: 5.5.0beta1 parser is generated with bison 2.6.1 snapshot parser is generated with bison 2.4.1 And snapshot works. Previous Comments: [2013-03-22 00:32:05] ahar...@php.net The tarball version of Zend/zend_language_parser.h has the following extra declarations (at the end of the file, just before the last #endif) compared to the generated version in my git checkout: #ifdef YYPARSE_PARAM #if defined __STDC__ || defined __cplusplus int zendparse (void *YYPARSE_PARAM); #else int zendparse (); #endif #else /* ! YYPARSE_PARAM */ #if defined __STDC__ || defined __cplusplus int zendparse (void); #else int zendparse (); #endif #endif /* ! YYPARSE_PARAM */ [2013-03-22 00:29:58] ahar...@php.net Mea culpa; I should have dug into this a little more. I can now reproduce this with beta 1, after seeing another report on IRC. Short version: configuring tarball builds with --enable-maintainer-zts results in the error in the original report. I can't reproduce this if I run buildconf myself in a Git tree, so it's something peculiar to the distributed tarballs. [2013-03-20 23:16:46] s...@php.net Closing as per previous comment [2013-03-20 23:11:11] kevin dot waterson at gmail dot com OK! Fixed in latest snap. Thanks for looking Kev [2013-03-20 20:20:16] ahar...@php.net I don't seem to be able to reproduce this. So, a few questions for you: 1. How did you get PHP? Tarball, git checkout, something else? 2. Does the error still occur with a blank configure line (ie just ./configure)? 3. Does it still happen with the latest 5.5 snapshot from 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 https://bugs.php.net/bug.php?id=64461 -- Edit this bug report at https://bugs.php.net/bug.php?id=64461&edit=1
Bug #64503 [Com]: Compilation fails with error: conflicting types for 'zendparse'
Edit report at https://bugs.php.net/bug.php?id=64503&edit=1
ID: 64503
Comment by: r...@php.net
Reported by:stormbyte at gmail dot com
Summary:Compilation fails with error: conflicting types for
'zendparse'
Status: Assigned
Type: Bug
Package:Compile Failure
Operating System: Gentoo
PHP Version:5.5.0beta1
Assigned To:remi
Block user comment: N
Private report: N
New Comment:
Sorry for the delay.
Test done with 201303251230 snapshot, and, to ensure file being regenerated
rm Zend/zend_{language,ini}_parser.[ch]
Do you think this is enough ?
Fedora 18, bison 2.6.1: ok.
Fedora 17, bison 2.5.1: ok
RHEL 6.4, bison 2.4.1; HS
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c: In
function 'tokenizer_register_constants':
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:32:
error: 'T_REQUIRE_ONCE' undeclared (first use in this function)
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:32:
error: (Each undeclared identifier is reported only once
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:32:
error: for each function it appears in.)
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:33:
error: 'T_REQUIRE' undeclared (first use in this function)
...
But this seems a parallel build issue, as running a "make" after failue
succeed... need more tests.
Previous Comments:
[2013-03-25 10:59:11] larue...@php.net
Remi, could you please test with the patches? personally, I prefer the sencode
one. since it's simple
[2013-03-25 07:46:49] larue...@php.net
see: http://marc.info/?l=php-internals&m=136419054303602&w=2
[2013-03-25 05:46:20] larue...@php.net
The following patch has been added/updated:
Patch Name: bison_build_2.patch
Revision: 1364190380
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build_2.patch&revision=1364190380
[2013-03-25 05:16:46] larue...@php.net
The following patch has been added/updated:
Patch Name: bison_build.patch
Revision: 1364188606
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build.patch&revision=1364188606
[2013-03-24 15:40:54] stormbyte at gmail dot com
Description:
These are the last lines for compile log output:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for
'zendparse'
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer_data.c:26:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals_macros.h:35:5: note: previous declaration of
'zendparse' was here
distcc[20503] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1-
r2/work/sapis-build/cli/ext/tokenizer/tokenizer_data.c on localhost failed
make: *** [ext/tokenizer/tokenizer_data.lo] Error 1
make: *** Waiting for unfinished jobs
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/ext/tokenizer/tokenizer.c:33:0:
/var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_language_parser.h:331:5: error: conflicting types for
'zendparse'
In file included from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_globals.h:28:0,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_compile.h:418,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_modules.h:26,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/Zend/zend_API.h:26,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/work/sapis-
build/cli/main/php.h:38,
from /var/tmp/portage/dev-lang/php-5.5.0_beta1-r2/w
Bug #64503 [Com]: Compilation fails with error: conflicting types for 'zendparse'
Edit report at https://bugs.php.net/bug.php?id=64503&edit=1
ID: 64503
Comment by: r...@php.net
Reported by:stormbyte at gmail dot com
Summary:Compilation fails with error: conflicting types for
'zendparse'
Status: Assigned
Type: Bug
Package:Compile Failure
Operating System: Gentoo
PHP Version:5.5.0beta1
Assigned To:remi
Block user comment: N
Private report: N
New Comment:
Sorry for bad previous tests.
Adding, before the build to ensure correct generation
rm Zend/zend_{language,ini}_parser.[ch]
./genfiles
Fedora 18, bison 2.6.1, NTS: ok.
Fedora 18, bison 2.6.1, ZTS: ok.
Fedora 17, bison 2.5.1, NTS: ok
Fedora 17, bison 2.5.1, ZTS: ok
RHEL 6.4, bison 2.4.1, NTS: ok
RHEL 6.4, bison 2.4.1, ZTS: ok
So I think you can commit the bison_build_2.patch
Previous Comments:
[2013-03-25 14:43:09] r...@php.net
Sorry for the delay.
Test done with 201303251230 snapshot, and, to ensure file being regenerated
rm Zend/zend_{language,ini}_parser.[ch]
Do you think this is enough ?
Fedora 18, bison 2.6.1: ok.
Fedora 17, bison 2.5.1: ok
RHEL 6.4, bison 2.4.1; HS
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c: In
function 'tokenizer_register_constants':
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:32:
error: 'T_REQUIRE_ONCE' undeclared (first use in this function)
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:32:
error: (Each undeclared identifier is reported only once
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:32:
error: for each function it appears in.)
/builddir/build/BUILD/php5.5-201303251230/ext/tokenizer/tokenizer_data.c:33:
error: 'T_REQUIRE' undeclared (first use in this function)
...
But this seems a parallel build issue, as running a "make" after failue
succeed... need more tests.
[2013-03-25 10:59:11] larue...@php.net
Remi, could you please test with the patches? personally, I prefer the sencode
one. since it's simple
[2013-03-25 07:46:49] larue...@php.net
see: http://marc.info/?l=php-internals&m=136419054303602&w=2
[2013-03-25 05:46:20] larue...@php.net
The following patch has been added/updated:
Patch Name: bison_build_2.patch
Revision: 1364190380
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build_2.patch&revision=1364190380
[2013-03-25 05:16:46] larue...@php.net
The following patch has been added/updated:
Patch Name: bison_build.patch
Revision: 1364188606
URL:
https://bugs.php.net/patch-display.php?bug=64503&patch=bison_build.patch&revision=1364188606
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=64503
--
Edit this bug report at https://bugs.php.net/bug.php?id=64503&edit=1
[PHP-BUG] Bug #64565 [NEW]: copy doesn't report failure on partial copy
From: remi Operating system: GNU/Linux PHP version: 5.4.13 Package: Filesystem function related Bug Type: Bug Bug description:copy doesn't report failure on partial copy Description: When destination folder of a copy haven't enough place, copy reports success instead of failure. Test script: --- https://bugs.php.net/bug.php?id=64565&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64565&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64565&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64565&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64565&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64565&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64565&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64565&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64565&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=64565&r=support Expected behavior: https://bugs.php.net/fix.php?id=64565&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64565&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64565&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64565&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64565&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64565&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64565&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64565&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64565&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64565&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64565&r=mysqlcfg
Bug #63520 [Com]: JSON extension includes a problematic license statement
Edit report at https://bugs.php.net/bug.php?id=63520&edit=1 ID: 63520 Comment by: r...@php.net Reported by:kaplan at debian dot org Summary:JSON extension includes a problematic license statement Status: Assigned Type: Bug Package:JSON related PHP Version:Irrelevant Assigned To:remi Block user comment: N Private report: N New Comment: Yes, I'm still working on the new alternative extension. Previous Comments: [2013-04-22 22:24:39] pleasestand at live dot com Remi: any update? Is <https://github.com/remicollet/pecl-json-c> relevant? I'll note that as a [MediaWiki][1] developer, I recently removed our bundled copy of PEAR Services_JSON on the basis that the JSON extension is compiled in by default, and therefore users can be expected to have it installed. Unfortunately, I had to [revert the change][2] because I only found out about the licensing problem last week, and our next release is three weeks from now (2013-05-15). So I would like to know whether you are still working on this. [1]: https://www.mediawiki.org/ [2]: https://bugzilla.wikimedia.org/show_bug.cgi?id=47431 [2013-04-04 18:00:52] b dot eltzner at gmx dot de I am not a native speaker. This comment is not supposed to be rude or insult anybody. I would like to make the problem clearer: *The "json license" affecting /ext/json/JSON_parser.c and /ext/json/utf8_decode.c is regarded non-free by GNU/FSF, Debian, Fedora, Red Hat and Google and is not approved by OSI. This is not at all the same as "Free but incompatible with GPL", which is the category in which the FSF lists the php license. *The morality clause "The Software shall be used for Good, not Evil." violates software freedom 0 and point 6 of the open source definition and the license will therefore _never_ be free or open source by definition. This is not a license "some fanatics don't like", it is a manifestly proprietary license. *The original author of the license has purposely chosen this form of license to trick open source projects into mistaking it as an open source license. He did this to prove the point that "those open source guys are entitled kids" and plays the issue for amusement: http://www.youtube.com/watch?v=-hCimLnIsDA *With the non-free files, PHP cannot be distributed unmodified as free software by downstream projects. Note that I don't say "Throw that stuff out11" It goes without saying that you can distribute the result of your work under whatever licenses you like, open source or not. However, if you want PHP to be easily distributable as free and open source software by downstream projects, I am sure they would be enormously relieved, if you provided them with a simple way to exclude the non-free files without breaking too much functionality. ---- [2012-11-23 13:33:42] r...@php.net A patch proposed in https://bugs.php.net/63588 makes "json_encode" really free. [2012-11-15 18:09:30] ras...@php.net I am not saying it isn't a tricky license clause to deal with and it would be better if it wasn't there. However, I am also not keen on spending resources on rewriting code for this reason. If someone supplies a functionally equivalent replacement, we will have a look at it. But as far as I am concerned, license- wise the terms Good and Evil are not legal terms. These are more subjective self-describing terms and since I deem PHP's use of the code as "Good" then we comply with the license. Could others perhaps use PHP and thus the code for "Evil" and therefore not comply with the license? Sure, but there are many things people can do with our code that is either against the various licenses involved or even illegal criminally. It is something we cannot control. [2012-11-15 18:01:24] paj...@php.net More seriously, as soon as the license is changed upstream, we will merge it. But we won't be able to do anything before. 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=63520 -- Edit this bug report at https://bugs.php.net/bug.php?id=63520&edit=1
Bug #64785 [Com]: Compile fails using --with-gd
Edit report at https://bugs.php.net/bug.php?id=64785&edit=1 ID: 64785 Comment by: r...@php.net Reported by:s...@php.net Summary:Compile fails using --with-gd Status: Assigned Type: Bug Package:GD related Operating System: Linux PHP Version:5.5Git-2013-05-07 (Git) Assigned To:remi Block user comment: N Private report: N New Comment: I don't think it works in 5.4 libpng is mandatory and cannot be disabled. checking for GD support... yes checking for the location of libvpx... no checking for the location of libjpeg... no checking for the location of libpng... no checking for the location of libXpm... no checking for FreeType 2... no checking for T1lib support... no checking whether to enable truetype string function in GD... no checking whether to enable JIS-mapped Japanese font support in GD... no If configure fails try --with-vpx-dir= If configure fails try --with-jpeg-dir= configure: error: png.h not found. I will restore this behaviour in 5.5. Previous Comments: [2013-05-07 21:42:57] s...@php.net Description: In PHP 5.5, using "./configure --with-gd" causes compilation failure. It works in PHP 5.4. The compilation errors after doing "./configure --with-gd" are: ext/gd/libgd/.libs/gd_png.o: In function `php_gd_gdImagePngCtxEx': /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:482: undefined reference to `png_create_write_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:491: undefined reference to `png_create_info_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:502: undefined reference to `png_destroy_write_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:508: undefined reference to `png_set_write_fn' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:524: undefined reference to `png_set_compression_level' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:526: undefined reference to `png_set_filter' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:581: undefined reference to `png_set_IHDR' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:664: undefined reference to `png_write_info' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:667: undefined reference to `png_set_packing' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:720: undefined reference to `png_write_image' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:721: undefined reference to `png_write_end' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:754: undefined reference to `png_destroy_write_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:494: undefined reference to `png_destroy_write_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:577: undefined reference to `png_set_IHDR' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:590: undefined reference to `png_set_tRNS' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:637: undefined reference to `png_set_tRNS' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:660: undefined reference to `png_set_PLTE' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:739: undefined reference to `png_write_image' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:740: undefined reference to `png_write_end' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:574: undefined reference to `png_set_IHDR' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:748: undefined reference to `png_write_image' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:749: undefined reference to `png_write_end' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:720: undefined reference to `png_write_image' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:721: undefined reference to `png_write_end' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:739: undefined reference to `png_write_image' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:740: undefined reference to `png_write_end' ext/gd/libgd/.libs/gd_png.o: In function `gdPngWriteData': /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:86: undefined reference to `png_get_io_ptr' ext/gd/libgd/.libs/gd_png.o: In function `gdPngErrorHandler': /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:66: undefined reference to `png_get_error_ptr' ext/gd/libgd/.libs/gd_png.o: In function `php_gd_gdImageCreateFromPngCtx': /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:149: undefined reference to `png_sig_cmp' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:154: undefined reference to `png_create_read_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:163: undefined reference to `png_create_info_struct' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:188: undefined reference to `png_set_sig_bytes' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:190: undefined reference to `png_set_read_fn' /home/cjones/php-5.5/ext/gd/libgd/gd_png.c:191: undefined reference to `png_read_info' /home/cjones/php-5.
[PHP-BUG] Bug #64895 [NEW]: interger overflow in SndToJewish
From: remi Operating system: GNU/Linux 64bits PHP version: 5.3.25 Package: Calendar related Bug Type: Bug Bug description:interger overflow in SndToJewish Description: Interger overflow occurs in SndToJewish Last correct value is 324542846 With very large value (ex: 9223372036854746369), php hangs. Test script: --- https://bugs.php.net/bug.php?id=64895&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64895&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64895&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64895&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64895&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64895&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64895&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64895&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64895&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64895&r=support Expected behavior: https://bugs.php.net/fix.php?id=64895&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64895&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64895&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64895&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64895&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64895&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64895&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64895&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64895&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64895&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64895&r=mysqlcfg
[PHP-BUG] Bug #64915 [NEW]: error_log ignored when daemonize=0
From: remi Operating system: GNU/Linux PHP version: 5.4.15 Package: FPM related Bug Type: Bug Bug description:error_log ignored when daemonize=0 Description: error_log is only used when daemonize=1. This make sense to display message during an interactive / debug run. Launching php-fpm using systemd (with type=simple of new type=notify), --nodaemonize option is used. So error_log directive is ignored and all messages goes to stdout (catched by systemd and redirected to system log). Proposal : use error_log configured file if daemonize OR !interactive (using isatty test) -- Edit bug report at https://bugs.php.net/bug.php?id=64915&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64915&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64915&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64915&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64915&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64915&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64915&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64915&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64915&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64915&r=support Expected behavior: https://bugs.php.net/fix.php?id=64915&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64915&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64915&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64915&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64915&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64915&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64915&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64915&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64915&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64915&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64915&r=mysqlcfg
Bug #64915 [PATCH]: error_log ignored when daemonize=0
Edit report at https://bugs.php.net/bug.php?id=64915&edit=1 ID: 64915 Patch added by: r...@php.net Reported by: r...@php.net Summary:error_log ignored when daemonize=0 Status: Assigned Type: Bug Package:FPM related Operating System: GNU/Linux PHP Version:5.4.15 Assigned To:remi Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5.5.0-bug64915.patch Revision: 1369387402 URL: https://bugs.php.net/patch-display.php?bug=64915&patch=php-5.5.0-bug64915.patch&revision=1369387402 Previous Comments: [2013-05-24 08:41:31] r...@php.net Description: error_log is only used when daemonize=1. This make sense to display message during an interactive / debug run. Launching php-fpm using systemd (with type=simple of new type=notify), --nodaemonize option is used. So error_log directive is ignored and all messages goes to stdout (catched by systemd and redirected to system log). Proposal : use error_log configured file if daemonize OR !interactive (using isatty test) -- Edit this bug report at https://bugs.php.net/bug.php?id=64915&edit=1
Bug #64915 [PATCH]: error_log ignored when daemonize=0
Edit report at https://bugs.php.net/bug.php?id=64915&edit=1 ID: 64915 Patch added by: r...@php.net Reported by: r...@php.net Summary:error_log ignored when daemonize=0 Status: Assigned Type: Bug Package:FPM related Operating System: GNU/Linux PHP Version:5.4.15 Assigned To:remi Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5.5.0-bug64915.patch Revision: 1369389053 URL: https://bugs.php.net/patch-display.php?bug=64915&patch=php-5.5.0-bug64915.patch&revision=1369389053 Previous Comments: [2013-05-24 09:23:22] r...@php.net The following patch has been added/updated: Patch Name: php-5.5.0-bug64915.patch Revision: 1369387402 URL: https://bugs.php.net/patch-display.php?bug=64915&patch=php-5.5.0-bug64915.patch&revision=1369387402 [2013-05-24 08:41:31] r...@php.net Description: error_log is only used when daemonize=1. This make sense to display message during an interactive / debug run. Launching php-fpm using systemd (with type=simple of new type=notify), --nodaemonize option is used. So error_log directive is ignored and all messages goes to stdout (catched by systemd and redirected to system log). Proposal : use error_log configured file if daemonize OR !interactive (using isatty test) -- Edit this bug report at https://bugs.php.net/bug.php?id=64915&edit=1
[PHP-BUG] Bug #64949 [NEW]: Buffer overflow in _pdo_pgsql_error
p-5.5.0RC2/sapi/cli/php_cli.c:1377 A trivial fix will be to switch to strncpy to avoid this buffer overflow, but this doesn't explain why a run condition come with a sql_state = "Copy command failed" which is not a standard 5 char error code. -- Edit bug report at https://bugs.php.net/bug.php?id=64949&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64949&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64949&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64949&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64949&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64949&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64949&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64949&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64949&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64949&r=support Expected behavior: https://bugs.php.net/fix.php?id=64949&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64949&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64949&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64949&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64949&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64949&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64949&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64949&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64949&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64949&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64949&r=mysqlcfg
[PHP-BUG] Bug #64961 [NEW]: segfault in imagesetinterpolation
From: remi Operating system: GNU/Linux 64bits PHP version: 5.5.0RC2 Package: GD related Bug Type: Bug Bug description:segfault in imagesetinterpolation Description: (gdb) bt #0 0x55798494 in zend_fetch_resource (passed_id=passed_id@entry=0x7fffa448, default_id=default_id@entry=-1, resource_type_name=resource_type_name@entry= 0x7fffe366d3c0 "Image", found_resource_type=found_resource_type@entry=0x0, num_resource_types=num_resource_types@entry=1) at /usr/src/debug/php-5.5.0RC2/Zend/zend_list.c:126 #1 0x7fffe3664014 in zif_imagesetinterpolation (ht=, return_value=0x77fb9dc8, return_value_ptr=, this_ptr=, return_value_used=) at /dev/shm/BUILD/php5.5-201305271230/ext/gd/gd.c:5370 #2 0x55777e69 in dtrace_execute_internal (execute_data_ptr=, fci=, return_value_used=) at /usr/src/debug/php-5.5.0RC2/Zend/zend_dtrace.c:99 #3 0x7fffed6caafa in xdebug_execute_internal (current_execute_data=0x77f7f1a0, fci=0x0, return_value_used=0) at /usr/src/debug/php-pecl-xdebug-2.2.3/xdebug-2.2.3/xdebug.c:1551 #4 0x558369f3 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7f1a0) at /usr/src/debug/php-5.5.0RC2/Zend/zend_vm_execute.h:545 #5 0x557f6a98 in execute_ex (execute_data=0x77f7f1a0) at /usr/src/debug/php-5.5.0RC2/Zend/zend_vm_execute.h:356 #6 0x55777d2d in dtrace_execute_ex (execute_data=) at /usr/src/debug/php-5.5.0RC2/Zend/zend_dtrace.c:75 #7 0x7fffed6cb184 in xdebug_execute_ex (execute_data=0x77f7f1a0) at /usr/src/debug/php-pecl-xdebug-2.2.3/xdebug-2.2.3/xdebug.c:1437 #8 0x55789728 in zend_execute_scripts (type=type@entry=8, retval=retval@entry=0x0, file_count=file_count@entry=3) at /usr/src/debug/php-5.5.0RC2/Zend/zend.c:1316 #9 0x557274dc in php_execute_script (primary_file=primary_file@entry=0x7fffcbb0) at /usr/src/debug/php-5.5.0RC2/main/main.c:2481 #10 0x5583a106 in do_cli (argc=2, argv=0x55b7c3b0) at /usr/src/debug/php-5.5.0RC2/sapi/cli/php_cli.c:993 #11 0x5560f31a in main (argc=2, argv=0x55b7c3b0) at /usr/src/debug/php-5.5.0RC2/sapi/cli/php_cli.c:1377 enum type are not long ;) so cannot be used as zend_parse_parameters arg. -- Edit bug report at https://bugs.php.net/bug.php?id=64961&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64961&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64961&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64961&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64961&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64961&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64961&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64961&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64961&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=64961&r=support Expected behavior: https://bugs.php.net/fix.php?id=64961&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64961&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64961&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64961&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64961&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64961&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64961&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64961&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64961&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64961&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64961&r=mysqlcfg
[PHP-BUG] Bug #64962 [NEW]: imagerotate produce corrupted image
From: remi Operating system: GNU/Linux PHP version: 5.5.0RC2 Package: GD related Bug Type: Bug Bug description:imagerotate produce corrupted image Description: Upstream GD bug #67 https://bitbucket.org/libgd/gd-libgd/issue/67/problem-with-gdrotate -- Edit bug report at https://bugs.php.net/bug.php?id=64962&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64962&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64962&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64962&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64962&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64962&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64962&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64962&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64962&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64962&r=support Expected behavior: https://bugs.php.net/fix.php?id=64962&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64962&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64962&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64962&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64962&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64962&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64962&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64962&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64962&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64962&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64962&r=mysqlcfg
[PHP-BUG] Bug #65047 [NEW]: Test skip on client / server version
From: remi
Operating system: GNU/Linux
PHP version: 5.4.16
Package: PostgreSQL related
Bug Type: Bug
Bug description:Test skip on client / server version
Description:
Hi,
Running the php test suite, using a client library version 8.4.13 (RHEL-6)
against a server running version 9.2.4 (RHEL-6 + RHSCL 1.0beta) reports
some failures
/tmp/php-5.4.16/ext/pgsql/tests/08escape.phpt
/tmp/php-5.4.16/ext/pgsql/tests/10pg_convert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/12pg_insert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/14pg_update_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/18pg_escape_bytea.phpt
/tmp/php-5.4.16/ext/pgsql/tests/bug37100_85.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274_2.phpt
For example PQunescapeBytea function is a pure client side function. So
result depends on the client version, not on the server version.
Proposal, keep (or add where is missing):
skip_server_version('8.5dev', '<');
And add:
skip_client_version('8.5dev', '<');
I agree, using a 8.4 client to access a 9.2 server is something which
should be avoid...
What is your thoughts ?
(I prefer asking before committing something perhaps stupid)
--
Edit bug report at https://bugs.php.net/bug.php?id=65047&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65047&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65047&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65047&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65047&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65047&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65047&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65047&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65047&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65047&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65047&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65047&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65047&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65047&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65047&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65047&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65047&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=65047&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65047&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65047&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65047&r=mysqlcfg
Bug #65047 [Com]: Test skip on client / server version
Edit report at https://bugs.php.net/bug.php?id=65047&edit=1
ID: 65047
Comment by: r...@php.net
Reported by: r...@php.net
Summary:Test skip on client / server version
Status: Open
Type: Bug
Package:PostgreSQL related
Operating System: GNU/Linux
PHP Version:5.4.16
Block user comment: N
Private report: N
New Comment:
On a opposite side pgsql/tests/bug37100.phpt could use
skip_client_version('8.5dev', '>=');
It will be run and will succeed with client version 8.4
Previous Comments:
----
[2013-06-17 13:11:33] r...@php.net
Description:
Hi,
Running the php test suite, using a client library version 8.4.13 (RHEL-6)
against a server running version 9.2.4 (RHEL-6 + RHSCL 1.0beta) reports some
failures
/tmp/php-5.4.16/ext/pgsql/tests/08escape.phpt
/tmp/php-5.4.16/ext/pgsql/tests/10pg_convert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/12pg_insert_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/14pg_update_85.phpt
/tmp/php-5.4.16/ext/pgsql/tests/18pg_escape_bytea.phpt
/tmp/php-5.4.16/ext/pgsql/tests/bug37100_85.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274.phpt
/tmp/php-5.4.16/ext/pdo_pgsql/tests/bug46274_2.phpt
For example PQunescapeBytea function is a pure client side function. So result
depends on the client version, not on the server version.
Proposal, keep (or add where is missing):
skip_server_version('8.5dev', '<');
And add:
skip_client_version('8.5dev', '<');
I agree, using a 8.4 client to access a 9.2 server is something which should be
avoid...
What is your thoughts ?
(I prefer asking before committing something perhaps stupid)
--
Edit this bug report at https://bugs.php.net/bug.php?id=65047&edit=1
Bug #65093 [Com]: password_hash ignores salts with spaces
Edit report at https://bugs.php.net/bug.php?id=65093&edit=1
ID: 65093
Comment by: r...@php.net
Reported by:michael at squiloople dot com
Summary:password_hash ignores salts with spaces
Status: Open
Type: Bug
Package:hash related
Operating System: Windows Vista SP2
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
I think it's only a documentation problem which should explains which are the
allowed characters in the salt (from code: a-z A-Z 0-9 . /)
(notice: It is strongly recommended that you do not generate your own salt for
this function)
Previous Comments:
[2013-06-21 22:37:03] michael at squiloople dot com
Description:
When manually setting a salt which contains spaces the function ignores it and
automatically generates its own.
Test script:
---
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisisatest'));
echo '';
echo password_hash('this is a test', PASSWORD_DEFAULT, array('salt' =>
'thisisatestthisis test'));
Expected result:
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$thisisatestthisis tesOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
(with the part after the salt being whatever it would be)
Actual result:
--
$2y$10$thisisatestthisisateseLNFJ7M2ONUSijVBKli7sVFN6rQm7o36
$2y$10$dGhpc2lzYXRlc3R0aGlzaOZPioeRNSLNeG3cuJW56OSusfQ5SjKdO
--
Edit this bug report at https://bugs.php.net/bug.php?id=65093&edit=1
Bug #65142 [PATCH]: Missing phar man page
Edit report at https://bugs.php.net/bug.php?id=65142&edit=1 ID: 65142 Patch added by: r...@php.net Reported by: r...@php.net Summary:Missing phar man page Status: Open Type: Bug Package:PHAR related Operating System: GNU/Linux PHP Version:5.4.16 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: phar.1.in Revision: 1372317222 URL: https://bugs.php.net/patch-display.php?bug=65142&patch=phar.1.in&revision=1372317222 Previous Comments: [2013-06-27 07:13:15] r...@php.net Description: There is no man page for the phar command. I will provide one (from pear help output) -- Edit this bug report at https://bugs.php.net/bug.php?id=65142&edit=1
[PHP-BUG] Bug #65143 [NEW]: Missing php-cgi man page
From: remi Operating system: GNU/Linux PHP version: 5.4.16 Package: CGI/CLI related Bug Type: Bug Bug description:Missing php-cgi man page Description: There is no man page for php-cgi command Simple proposal (as all options are described in php man page), a simple redirect: .so man1/php.1 -- Edit bug report at https://bugs.php.net/bug.php?id=65143&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65143&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65143&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65143&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65143&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65143&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65143&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65143&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65143&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65143&r=support Expected behavior: https://bugs.php.net/fix.php?id=65143&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65143&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65143&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65143&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65143&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65143&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65143&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65143&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65143&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65143&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65143&r=mysqlcfg
[PHP-BUG] Bug #65142 [NEW]: Missing phar man page
From: remi Operating system: GNU/Linux PHP version: 5.4.16 Package: PHAR related Bug Type: Bug Bug description:Missing phar man page Description: There is no man page for the phar command. I will provide one (from pear help output) -- Edit bug report at https://bugs.php.net/bug.php?id=65142&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=65142&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=65142&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=65142&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=65142&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=65142&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=65142&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=65142&r=needscript Try newer version: https://bugs.php.net/fix.php?id=65142&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=65142&r=support Expected behavior: https://bugs.php.net/fix.php?id=65142&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=65142&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=65142&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=65142&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65142&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=65142&r=dst IIS Stability: https://bugs.php.net/fix.php?id=65142&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=65142&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=65142&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=65142&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=65142&r=mysqlcfg
Req #65082 [Com]: json_encode's option for replacing ill-formd byte sequences with substitute cha
Edit report at https://bugs.php.net/bug.php?id=65082&edit=1
ID: 65082
Comment by: r...@php.net
Reported by:masakielastic at gmail dot com
Summary:json_encode's option for replacing ill-formd byte
sequences with substitute cha
Status: Open
Type: Feature/Change Request
Package:JSON related
Operating System: All
PHP Version:5.5.0
Block user comment: N
Private report: N
New Comment:
Here is a proposal fo this issue
https://github.com/remicollet/pecl-json-c/commit/5a499a4550d1f29f1f8eeb1b4ca0b01a33c64779
This add 2 new options to json_encode
- JSON_NOTUTF8_SUBSTITUTE (name seems better, at least to me), to replace
not-utf8 char with the replacement char.
- JSON_NOTUTF8_IGNORE to ignore not-utf8 char (remove in escaped mode, keep
without any check in unescaped mode)
Previous Comments:
[2013-06-21 07:26:33] ni...@php.net
It's currently possible to get a partial output using
JSON_PARTIAL_OUTPUT_ON_ERROR. This will replace invalid UTF8 strings with NULL
though. It probably would make sense to have an alternative option that inserts
the substitution character.
[2013-06-21 05:31:34] masakielastic at gmail dot com
Description:
json_encode returns false if the string contains ill-formed byte
sequences. It is hard to find the problem since a lot of web applications don't
expect the existence of ill-formed byte sequences. The one example is Symfony's
JsonResponse class.
https://github.com/symfony/symfony/blob/master/src/Symfony/Component/HttpFoundat
ion/JsonResponse.php#L83
Introducing json_encode's option for replacing ill-formd byte sequences with
substitute characters (such as U+FFFD) save writing the logic.
function json_encode2($value, $options, $depth)
{
if (is_scalar($value)) {
return json_encode($value, $options, $depth);
}
$value2 = [];
foreach ($value as $key => $elm) {
$value2[str_scrub($key)] = str_scrub($elm);
}
return json_encode($value2, $options, $depth);
}
// https://bugs.php.net/bug.php?id=65081
function str_scrub($str, $encoding = 'UTF-8')
{
return htmlspecialchars_decode(htmlspecialchars($str, ENT_SUBSTITUTE,
$encoding));
}
The precedent example is htmlspecialchars's ENT_SUBSTITUTE option which was
introduced
in PHP 5.4. json_encode shares the part of logic used such as
php_next_utf8_char
by htmlspecialchars since PHP 5.5.
https://github.com/php/php-src/blob/master/ext/json/json.c#L369
Another reason for introducing the option is existence of JsonSerializable
interface.
Accessing jsonSerialize method's values come from private properties is hard
or impossbile.
The one of names of candiates for the option is JSON_SUBSTITUTE similar to
htmlspecialchar's ENT_SUBSTITUTE option.
json_encode($object, JSON_SUBSTITUTE);
--
Edit this bug report at https://bugs.php.net/bug.php?id=65082&edit=1
Req #65082 [Com]: json_encode's option for replacing ill-formd byte sequences with substitute cha
Edit report at https://bugs.php.net/bug.php?id=65082&edit=1 ID: 65082 Comment by: r...@php.net Reported by:masakielastic at gmail dot com Summary:json_encode's option for replacing ill-formd byte sequences with substitute cha Status: Assigned Type: Feature/Change Request Package:JSON related Operating System: All PHP Version:5.5.0 Assigned To:remi Block user comment: N Private report: N New Comment: > Hi remi, could you test my patch for PHP_JSON_UNESCAPED_UNICODE option? > The patch adopts JSON_NOTUTF8_SUBSTITUTE and JSON_NOTUTF8_IGNORE options. The PHP_JSON_UNESCAPED_UNICODE + JSON_NOTUTF8_IGNORE already works with my patch. Yes, PHP_JSON_UNESCAPED_UNICODE + JSON_NOTUTF8_SUBSTITUTE doesn't work for now, but converting to utf16, then back to utf8 seems really... messy. Need something simpler. Notice: this bug is only for json_encode. Other issue have their own bug for tracking (especially the json_decode one, as I dont plan to alter it) Previous Comments: [2013-07-14 12:45:47] masakielastic at gmail dot com As for JSON_NOTUTF8_IGNORE, the description for security is needed in the manual like htmlspecialchars's ENT_IGNORE http://www.php.net/manual/en/function.htmlspecialchars.php That's why I didn't sugguest JSON_IGNORE in the draft and showed Escaping RFC's link as resource. UNICODE SECURITY CONSIDERATIONS http://www.unicode.org/reports/tr36/#Deletion_of_Noncharacters IDS11-J. Eliminate noncharacter code points before validation https://www.securecoding.cert.org/confluence/display/java/IDS11- J.+Eliminate+noncharacter+code+points+before+validation [2013-07-14 12:31:29] masakielastic at gmail dot com Hi, nikic, sorry, ignore my last comment. I added small change in json.c https://gist.github.com/masakielastic/5973095#file-02-small_refactaring-patch [2013-07-14 08:48:01] masakielastic at gmail dot com I nominate other names from the view of consistency with JSON_ERROR_UTF8. JSON_UTF8_SUBSTITUTE JSON_UTF8_IGNORE [2013-07-14 08:44:02] masakielastic at gmail dot com Hi, nikic, I posted a document request for the mission option and error codes. https://bugs.php.net/bug.php?id=65259 Your opinion about the consistency among JSON_PARTIAL_OUTPUT_ON_ERROR and JSON_NOTUTF8_SUBSTITUTE and JSON_NOTUTF8_IGNORE is needed. [2013-07-14 08:28:53] masakielastic at gmail dot com I created new feature request for preveting XSS attack and I withdraw my option about the change of default behavior. new function for preventing XSS attack https://bugs.php.net/bug.php?id=65257 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=65082 -- Edit this bug report at https://bugs.php.net/bug.php?id=65082&edit=1
Bug #65460 [Com]: PHP 5.4.18 fails to compile with Apache 2.4.6
Edit report at https://bugs.php.net/bug.php?id=65460&edit=1 ID: 65460 Comment by: r...@php.net Reported by:stu at coe dot uky dot edu Summary:PHP 5.4.18 fails to compile with Apache 2.4.6 Status: Assigned Type: Bug Package:Compile Failure Operating System: Slackware64 14.0 PHP Version:5.4.18 Assigned To:stas Block user comment: N Private report: N New Comment: I think this is the same issue than #64503, caused by the switch from Bison 2.3 to 2.7, used to generate the parser. Notice : the fix for this issue have only been applied in 5.5 tree. Previous Comments: [2013-08-19 07:37:04] m...@php.net Sorry for not being explicit enough! I can reproduce with $ ./configure --enable-maintainer-zts --disable-all --prefix=$(pwd)/usr so, enabling ZTS should cause the issue. [2013-08-19 07:10:26] s...@php.net Mike, so which options should I use to reproduce it? Because I used with-apxs2 and it worked fine. Should apache be built with some special options? IIRC, it usually does not build ZTS version, so what is the config for you that doesn't work? [2013-08-19 07:03:45] m...@php.net I also doubt that it's about Apache, but rather about ZTS. Looking at the tarball files I see: in zend_global_macros.h: /* Compiler */ #ifdef ZTS # define CG(v) TSRMG(compiler_globals_id, zend_compiler_globals *, v) int zendparse(void *compiler_globals); #else # define CG(v) (compiler_globals.v) extern ZEND_API struct _zend_compiler_globals compiler_globals; int zendparse(void); #endif Note the #ifdef ZTS zendparse declaration ...and in zend_language_parser.h: #ifdef YYPARSE_PARAM #if defined __STDC__ || defined __cplusplus int zendparse (void *YYPARSE_PARAM); #else int zendparse (); #endif #else /* ! YYPARSE_PARAM */ #if defined __STDC__ || defined __cplusplus int zendparse (void); #else int zendparse (); #endif #endif /* ! YYPARSE_PARAM */ ...where YYPARSE_PARAM is defined in the source (.c) file. [2013-08-19 00:28:49] s...@php.net 5.4 compiles fine for me on CentOS 6.3 and on Mac. Apache is older there but I don't think this should have any consequence for zendparse. [2013-08-18 19:11:35] m...@php.net Looks like something was wrongly or not completely merged into 5.4? 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=65460 -- Edit this bug report at https://bugs.php.net/bug.php?id=65460&edit=1
[PHP-BUG] Req #61949 [NEW]: Allow cgi test ti run out of build tree
From: remi Operating system: GNU/Linux (Fedora 16) PHP version: 5.4.2 Package: CGI/CLI related Bug Type: Feature/Change Request Bug description:Allow cgi test ti run out of build tree Description: Tests provided in sapi/cgi/tests need to detect path of php-cgi binary. This doesn't work when run (pear run-tests) in the source tree out of the build process The attached patch try to improve this detection. First change uses PHP_BINARY which requires PHP 5.4 The other change will work on PHP 5.3/5.4 (when TEST_PHP_EXECUTABLE=/usr/bin/php) Test script: --- $ cd sapi/cgi/tests $ pear run-tests 010.phpt Expected result: Running 1 tests PASS Bug #45860 (header() function fails to correctly replace all Status lines)[010.phpt] TOTAL TIME: 00:01 1 PASSED TESTS 0 SKIPPED TESTS Actual result: -- Running 1 tests SKIP Bug #45860 (header() function fails to correctly replace all Status lines)[010.phpt](reason: CGI not found) TOTAL TIME: 00:01 0 PASSED TESTS 1 SKIPPED TESTS -- Edit bug report at https://bugs.php.net/bug.php?id=61949&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61949&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61949&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61949&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61949&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61949&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61949&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61949&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61949&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61949&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61949&r=support Expected behavior: https://bugs.php.net/fix.php?id=61949&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61949&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61949&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61949&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61949&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61949&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61949&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61949&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61949&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61949&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61949&r=mysqlcfg
[PHP-BUG] Bug #61950 [NEW]: Failing tests
From: remi Operating system: GNU/Linux (Fedora 16) PHP version: 5.4.2 Package: CGI/CLI related Bug Type: Bug Bug description:Failing tests Description: Most of the tests provided in sapi/cgi/tests are failing. Failing tests (001 to 009) use var_dump(`$php ...`); which break expected output (CR/LF). Others working tests (010, 011) use echo(`$php ...`); The attached patch proposal use passthru, which seems another working solution. With this patch applied, all the 11 tests return "PASS". Test script: --- $ pear run-tests 001.phpt Expected result: Running 1 tests PASS version string[001.phpt] TOTAL TIME: 00:00 1 PASSED TESTS 0 SKIPPED TESTS Actual result: -- Running 1 tests FAIL version string[001.phpt] wrote log to "/dev/shm/php-5.4.2/sapi/cgi/tests/run-tests.log" TOTAL TIME: 00:01 0 PASSED TESTS 0 SKIPPED TESTS 1 FAILED TESTS: 001.phpt $ cat 001.out string(151) "PHP 5.4.2 (cgi-fcgi) (built: May 4 2012 14:44:54)\nCopyright (c) 1997-2012 The PHP Group\nZend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies\n" -- Edit bug report at https://bugs.php.net/bug.php?id=61950&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61950&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61950&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61950&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61950&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61950&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61950&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61950&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61950&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61950&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61950&r=support Expected behavior: https://bugs.php.net/fix.php?id=61950&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61950&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61950&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61950&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61950&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61950&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61950&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61950&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61950&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61950&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61950&r=mysqlcfg
Req #61949 [PATCH]: Allow cgi test ti run out of build tree
Edit report at https://bugs.php.net/bug.php?id=61949&edit=1 ID: 61949 Patch added by: r...@php.net Reported by: r...@php.net Summary:Allow cgi test ti run out of build tree Status: Open Type: Feature/Change Request Package:CGI/CLI related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4.2 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-cgi-path-detection.patch Revision: 1336204323 URL: https://bugs.php.net/patch-display.php?bug=61949&patch=php-cgi-path-detection.patch&revision=1336204323 Previous Comments: [2012-05-05 06:56:30] r...@php.net Description: Tests provided in sapi/cgi/tests need to detect path of php-cgi binary. This doesn't work when run (pear run-tests) in the source tree out of the build process The attached patch try to improve this detection. First change uses PHP_BINARY which requires PHP 5.4 The other change will work on PHP 5.3/5.4 (when TEST_PHP_EXECUTABLE=/usr/bin/php) Test script: --- $ cd sapi/cgi/tests $ pear run-tests 010.phpt Expected result: Running 1 tests PASS Bug #45860 (header() function fails to correctly replace all Status lines)[010.phpt] TOTAL TIME: 00:01 1 PASSED TESTS 0 SKIPPED TESTS Actual result: -- Running 1 tests SKIP Bug #45860 (header() function fails to correctly replace all Status lines)[010.phpt](reason: CGI not found) TOTAL TIME: 00:01 0 PASSED TESTS 1 SKIPPED TESTS -- Edit this bug report at https://bugs.php.net/bug.php?id=61949&edit=1
[PHP-BUG] Req #63085 [NEW]: Systemd integration and daemonize
From: remi Operating system: GNU/Linux (Fedora 17) PHP version: 5.4.7 Package: FPM related Bug Type: Feature/Change Request Bug description:Systemd integration and daemonize Description: Currently "daemonize" is a option taken from configuration file. I think is is quite ugly to have a starting script of systemd unit file to rely on a external configuration file. I think a command line option will be more robust. For ex, - in init script we could launch php-fpm --daemonize - in systemd unit, we could launch php-fpm --nodaemonize Without command line option, I propose to keep reading option from the config file (to not break existing configuration). We could also imagine another option (--debug) which run in foreground and log everything need thing to screen (for interactive run). What do you think ? I could propose a patch -- Edit bug report at https://bugs.php.net/bug.php?id=63085&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63085&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63085&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63085&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63085&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63085&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63085&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63085&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63085&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63085&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63085&r=support Expected behavior: https://bugs.php.net/fix.php?id=63085&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63085&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63085&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63085&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63085&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63085&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63085&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63085&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63085&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63085&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63085&r=mysqlcfg
Req #63085 [PATCH]: Systemd integration and daemonize
Edit report at https://bugs.php.net/bug.php?id=63085&edit=1 ID: 63085 Patch added by: r...@php.net Reported by: r...@php.net Summary:Systemd integration and daemonize Status: Open Type: Feature/Change Request Package:FPM related Operating System: GNU/Linux (Fedora 17) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-fpm.service Revision: 1347601268 URL: https://bugs.php.net/patch-display.php?bug=63085&patch=php-fpm.service&revision=1347601268 Previous Comments: [2012-09-14 05:40:12] r...@php.net Description: Currently "daemonize" is a option taken from configuration file. I think is is quite ugly to have a starting script of systemd unit file to rely on a external configuration file. I think a command line option will be more robust. For ex, - in init script we could launch php-fpm --daemonize - in systemd unit, we could launch php-fpm --nodaemonize Without command line option, I propose to keep reading option from the config file (to not break existing configuration). We could also imagine another option (--debug) which run in foreground and log everything need thing to screen (for interactive run). What do you think ? I could propose a patch -- Edit this bug report at https://bugs.php.net/bug.php?id=63085&edit=1
Req #63085 [Com]: Systemd integration and daemonize
Edit report at https://bugs.php.net/bug.php?id=63085&edit=1 ID: 63085 Comment by: r...@php.net Reported by: r...@php.net Summary:Systemd integration and daemonize Status: Open Type: Feature/Change Request Package:FPM related Operating System: GNU/Linux (Fedora 17) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: I have join the systemd unit file used in Fedora. Note : "type=Forking" is not present, so this rely on daemonize=no in config file. It could be great to have this unit file (made more generic if needed) provided in php distribution. Previous Comments: [2012-09-14 05:41:08] r...@php.net The following patch has been added/updated: Patch Name: php-fpm.service Revision: 1347601268 URL: https://bugs.php.net/patch-display.php?bug=63085&patch=php-fpm.service&revision=1347601268 [2012-09-14 05:40:12] r...@php.net Description: Currently "daemonize" is a option taken from configuration file. I think is is quite ugly to have a starting script of systemd unit file to rely on a external configuration file. I think a command line option will be more robust. For ex, - in init script we could launch php-fpm --daemonize - in systemd unit, we could launch php-fpm --nodaemonize Without command line option, I propose to keep reading option from the config file (to not break existing configuration). We could also imagine another option (--debug) which run in foreground and log everything need thing to screen (for interactive run). What do you think ? I could propose a patch -- Edit this bug report at https://bugs.php.net/bug.php?id=63085&edit=1
[PHP-BUG] Bug #52262 [NEW]: json_decode reports no error while returning NULL
From:
Operating system: Linux/Ubuntu
PHP version: 5.3.2
Package: JSON related
Bug Type: Bug
Bug description:json_decode reports no error while returning NULL
Description:
I'm attempting to use json_decode on a relatively long piece of JSON. The
JSON
is returned successfully by file_get_contents, and is valid according to
JSONLint.
What I expect to happen is for the JSON to be correctly decoded, or NULL to
be
returned and json_last_error to be populated with the reason. For some
reason
NULL is returned and json_last_error remains at 0.
I have a feeling that this could be to do with the length of the file
(containing a large array of objects).
I'm currently using:
r...@ross-laptop:/$ php -v
PHP 5.3.2-1ubuntu4.2 with Suhosin-Patch (cli) (built: May 13 2010 20:01:00)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
http://api.steampowered.com/ISteamUserStats/GetGlobalAchievementPercentagesForApp/v0001/?gameid=440";);
$decoded = json_decode($raw);
$errors = array(
JSON_ERROR_NONE => "No error has occurred",
JSON_ERROR_DEPTH => "The maximum stack depth has been exceeded",
JSON_ERROR_CTRL_CHAR => "Control character error, possibly incorrectly
encoded",
JSON_ERROR_SYNTAX => "Syntax error",
//JSON_ERROR_UTF8 => "Malformed UTF-8 characters, possibly incorrectly
encoded"
);
var_dump("Raw result:", $raw, "\n\n");
var_dump("Decoded result:", $decoded, "\n\n");
var_dump("JSON errors:", $errors[json_last_error()]);
Expected result:
Raw result: (long raw json)
Decoded result: object stdClass(1) { (data array) }
JSON errors: string "No error has occurred"
Actual result:
--
Raw result: (long raw json)
Decoded result: NULL
JSON errors: string "No error has occurred"
--
Edit bug report at http://bugs.php.net/bug.php?id=52262&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52262&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52262&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52262&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52262&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52262&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52262&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52262&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52262&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52262&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52262&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52262&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52262&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52262&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52262&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52262&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=52262&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52262&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52262&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52262&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52262&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52262&r=mysqlcfg
Bug #52262 [Com]: json_decode reports no error while returning NULL
Edit report at http://bugs.php.net/bug.php?id=52262&edit=1
ID: 52262
Comment by: r...@php.net
Reported by: r...@php.net
Summary: json_decode reports no error while returning NULL
Status: Closed
Type: Bug
Package: JSON related
Operating System: Linux/Ubuntu
PHP Version: 5.3.2
Assigned To: scottmac
New Comment:
Thanks for the fix, will talk to Steam.
Previous Comments:
[2010-07-06 19:08:47] scott...@php.net
It now correctly returns an error code to indicate an invalid UTF-8
error. The
issue is an incorrectly encoded character around number 21,190.
I suggest you speak to Steam and get them to produce a correctly valid
feed.
[2010-07-06 19:01:35] scott...@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=301028
Log: Fix bug #52262 - Invalid UTF-8 documents don't set an error code
when they fail to decode.
[2010-07-06 13:34:48] johan...@php.net
That codition in php_json_decode is hit as utf16_len == -2
utf16_len = utf8_to_utf16(utf16, str, str_len);
if (utf16_len <= 0) {
if (utf16) {
efree(utf16);
}
RETURN_NULL();
}
[2010-07-06 11:17:59] r...@php.net
Description:
I'm attempting to use json_decode on a relatively long piece of JSON.
The JSON
is returned successfully by file_get_contents, and is valid according to
JSONLint.
What I expect to happen is for the JSON to be correctly decoded, or NULL
to be
returned and json_last_error to be populated with the reason. For some
reason
NULL is returned and json_last_error remains at 0.
I have a feeling that this could be to do with the length of the file
(containing a large array of objects).
I'm currently using:
r...@ross-laptop:/$ php -v
PHP 5.3.2-1ubuntu4.2 with Suhosin-Patch (cli) (built: May 13 2010
20:01:00)
Copyright (c) 1997-2009 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
Test script:
---
http://api.steampowered.com/ISteamUserStats/GetGlobalAchievementPercentagesForApp/v0001/?gameid=440";);
$decoded = json_decode($raw);
$errors = array(
JSON_ERROR_NONE => "No error has occurred",
JSON_ERROR_DEPTH => "The maximum stack depth has been exceeded",
JSON_ERROR_CTRL_CHAR => "Control character error, possibly
incorrectly encoded",
JSON_ERROR_SYNTAX => "Syntax error",
//JSON_ERROR_UTF8 => "Malformed UTF-8 characters, possibly
incorrectly encoded"
);
var_dump("Raw result:", $raw, "\n\n");
var_dump("Decoded result:", $decoded, "\n\n");
var_dump("JSON errors:", $errors[json_last_error()]);
Expected result:
Raw result: (long raw json)
Decoded result: object stdClass(1) { (data array) }
JSON errors: string "No error has occurred"
Actual result:
--
Raw result: (long raw json)
Decoded result: NULL
JSON errors: string "No error has occurred"
--
Edit this bug report at http://bugs.php.net/bug.php?id=52262&edit=1
[DISCUSS] Spring Implicit Services Specs Vs Implementation
Hi All, This discussion is taken into account with reference to the JIRA, TUSCANY-2258. Lets see some background from the specs as well as with the current implementation on this issue. FROM THE SPECS: Each element used with should include the name of the Spring bean that is to be exposed as an SCA service in its name attribute. So, for Spring, the name attribute of a service plays two roles: it identifies a Spring bean, and it names the service for the component. Example-Spring Application Context: Example-SCA Composite using the above Spring Context: As per the specs, The service element above has a name of "X", so there should be a Spring bean with that name. CURRENT IMPLEMENTATION: When explicit service dled twice at the same time. The problem also ocours when I tried to use popen or proc_open(with and without bypass_shell option) [2008-06-10 14:59:10] aleaddict at yahoo dot com Windows Server 2003 R2 Service Pack 1 Apache 2.2.6 PHP 5.2.4 (upgraded to 5.2.6 with no success) Executing resource kit utility shortcut.exe via exec() with EXACTLY the same results... Random, no errors logged, hangs up all succeeding calls to exec(), requires restart. Keith [2008-05-14 07:56:17] inqualab1985 at gmail dot com Dear Jani There is no problem with 'sample.exe'. I have tested the same for different exe or even for dos command. It hangs when we are calling the page at regular interval of time (through Ajax). There is a problem in the definition of exec() function. For any further information , feel free to contact me. [2008-05-09 14:20:40] [EMAIL PROTECTED] What exactly does this "sample.exe" do? It's most likely not any PHP problem at all anyway, you just call some exe that "hangs" itself.. 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/44942 -- Edit this bug report at http://bugs.php.net/?id=44942&edit=1
[PHP-BUG] Bug #63117 [NEW]: Bad version libdb version use.
From: remi Operating system: GNU/Linux (Fedora 18) PHP version: 5.4.7 Package: DBM/DBA related Bug Type: Bug Bug description:Bad version libdb version use. Description: Hi, When various versiosn are installed, among 4.8, 5.2 or 5.3, configure doesn't detect the current one. config.m4 include 5.1 condition but none for 5.2 or 5.3. For headers, $i/include/db.h is probably the default/current version For library, libdb.so is also probably the default/current version Proposal: Test $y/include/db.h first and, in PHP_DBA_DB_CHECK, "db" first. RFE: It will be great to have libdb version reported in phpinfo(). -- Edit bug report at https://bugs.php.net/bug.php?id=63117&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63117&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63117&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63117&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63117&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63117&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63117&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63117&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63117&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63117&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63117&r=support Expected behavior: https://bugs.php.net/fix.php?id=63117&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63117&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63117&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63117&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63117&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63117&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63117&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63117&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63117&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63117&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63117&r=mysqlcfg
Bug #63117 [PATCH]: Bad version libdb version use.
Edit report at https://bugs.php.net/bug.php?id=63117&edit=1 ID: 63117 Patch added by: r...@php.net Reported by: r...@php.net Summary:Bad version libdb version use. Status: Open Type: Bug Package:DBM/DBA related Operating System: GNU/Linux (Fedora 18) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: dba-libdbinfo.patch Revision: 1348060204 URL: https://bugs.php.net/patch-display.php?bug=63117&patch=dba-libdbinfo.patch&revision=1348060204 Previous Comments: [2012-09-19 10:54:43] r...@php.net Description: Hi, When various versiosn are installed, among 4.8, 5.2 or 5.3, configure doesn't detect the current one. config.m4 include 5.1 condition but none for 5.2 or 5.3. For headers, $i/include/db.h is probably the default/current version For library, libdb.so is also probably the default/current version Proposal: Test $y/include/db.h first and, in PHP_DBA_DB_CHECK, "db" first. RFE: It will be great to have libdb version reported in phpinfo(). -- Edit this bug report at https://bugs.php.net/bug.php?id=63117&edit=1
Req #63085 [PATCH]: Systemd integration and daemonize
Edit report at https://bugs.php.net/bug.php?id=63085&edit=1 ID: 63085 Patch added by: r...@php.net Reported by: r...@php.net Summary:Systemd integration and daemonize Status: Open Type: Feature/Change Request Package:FPM related Operating System: GNU/Linux (Fedora 17) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-fpm-systemd.patch Revision: 1348066817 URL: https://bugs.php.net/patch-display.php?bug=63085&patch=php-fpm-systemd.patch&revision=1348066817 Previous Comments: [2012-09-14 05:43:02] r...@php.net I have join the systemd unit file used in Fedora. Note : "type=Forking" is not present, so this rely on daemonize=no in config file. It could be great to have this unit file (made more generic if needed) provided in php distribution. [2012-09-14 05:41:08] r...@php.net The following patch has been added/updated: Patch Name: php-fpm.service Revision: 1347601268 URL: https://bugs.php.net/patch-display.php?bug=63085&patch=php-fpm.service&revision=1347601268 ---- [2012-09-14 05:40:12] r...@php.net Description: Currently "daemonize" is a option taken from configuration file. I think is is quite ugly to have a starting script of systemd unit file to rely on a external configuration file. I think a command line option will be more robust. For ex, - in init script we could launch php-fpm --daemonize - in systemd unit, we could launch php-fpm --nodaemonize Without command line option, I propose to keep reading option from the config file (to not break existing configuration). We could also imagine another option (--debug) which run in foreground and log everything need thing to screen (for interactive run). What do you think ? I could propose a patch -- Edit this bug report at https://bugs.php.net/bug.php?id=63085&edit=1
Req #63085 [Com]: Systemd integration and daemonize
Edit report at https://bugs.php.net/bug.php?id=63085&edit=1 ID: 63085 Comment by: r...@php.net Reported by: r...@php.net Summary:Systemd integration and daemonize Status: Open Type: Feature/Change Request Package:FPM related Operating System: GNU/Linux (Fedora 17) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: In the proposed php-fpm-systemd.patch: - add --daemonize option, and update init.d to use it - add --nodaemonize option - update --help output - update man page for new options and systemd use - add systemd unit file, which use --nodaemonize Previous Comments: [2012-09-19 15:00:17] r...@php.net The following patch has been added/updated: Patch Name: php-fpm-systemd.patch Revision: 1348066817 URL: https://bugs.php.net/patch-display.php?bug=63085&patch=php-fpm-systemd.patch&revision=1348066817 [2012-09-14 05:43:02] r...@php.net I have join the systemd unit file used in Fedora. Note : "type=Forking" is not present, so this rely on daemonize=no in config file. It could be great to have this unit file (made more generic if needed) provided in php distribution. [2012-09-14 05:41:08] r...@php.net The following patch has been added/updated: Patch Name: php-fpm.service Revision: 1347601268 URL: https://bugs.php.net/patch-display.php?bug=63085&patch=php-fpm.service&revision=1347601268 ---- [2012-09-14 05:40:12] r...@php.net Description: Currently "daemonize" is a option taken from configuration file. I think is is quite ugly to have a starting script of systemd unit file to rely on a external configuration file. I think a command line option will be more robust. For ex, - in init script we could launch php-fpm --daemonize - in systemd unit, we could launch php-fpm --nodaemonize Without command line option, I propose to keep reading option from the config file (to not break existing configuration). We could also imagine another option (--debug) which run in foreground and log everything need thing to screen (for interactive run). What do you think ? I could propose a patch -- Edit this bug report at https://bugs.php.net/bug.php?id=63085&edit=1
[PHP-BUG] Bug #63126 [NEW]: DISABLE_AUTHENTICATOR ignores array
From: remi
Operating system: GNU/Linux (Fedora 18)
PHP version: 5.4.7
Package: IMAP related
Bug Type: Bug
Bug description:DISABLE_AUTHENTICATOR ignores array
Description:
According to source code, DISABLE_AUTHENTICATOR could be a string or an
array.
Works as expected:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>'GSSAPI');
Doesn't works:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>array('GSSAPI','NTLM'));
The trivial attached patch should fix this (but cannot test it)
--
Edit bug report at https://bugs.php.net/bug.php?id=63126&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63126&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63126&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63126&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63126&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63126&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63126&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63126&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63126&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63126&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63126&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63126&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63126&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63126&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63126&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63126&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63126&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63126&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63126&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63126&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63126&r=mysqlcfg
Bug #63126 [Com]: DISABLE_AUTHENTICATOR ignores array
Edit report at https://bugs.php.net/bug.php?id=63126&edit=1
ID: 63126
Comment by: r...@php.net
Reported by: r...@php.net
Summary:DISABLE_AUTHENTICATOR ignores array
Status: Open
Type: Bug
Package:IMAP related
Operating System: GNU/Linux (Fedora 18)
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
This also affects php 5.3
Previous Comments:
[2012-09-21 06:33:46] r...@php.net
Description:
According to source code, DISABLE_AUTHENTICATOR could be a string or an array.
Works as expected:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>'GSSAPI');
Doesn't works:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>array('GSSAPI','NTLM'));
The trivial attached patch should fix this (but cannot test it)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63126&edit=1
Bug #63126 [Com]: DISABLE_AUTHENTICATOR ignores array
Edit report at https://bugs.php.net/bug.php?id=63126&edit=1
ID: 63126
Comment by: r...@php.net
Reported by: r...@php.net
Summary:DISABLE_AUTHENTICATOR ignores array
Status: Open
Type: Bug
Package:IMAP related
Operating System: GNU/Linux (Fedora 18)
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
I can find a exchange server an test the fix.
Test script:
$inbox =
imap_open($server,$userlogin,$password,OP_HALFOPEN,1,array('DISABLE_AUTHENTICATOR'
=> array('GSSAPI','NTLM')));
var_dump(imap_errors());
Without the patch:
array(2) {
[0]=>
string(148) "Kerberos error: Credentials cache file
'/run/user/1000/krb5cc_ea1f24ead9d3199b715d4d57505d4335/t (try running kinit)
for exchange2007."
[1]=>
string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}
With the patch:
array(1) {
[0]=>
string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}
Previous Comments:
----
[2012-09-21 06:42:50] r...@php.net
This also affects php 5.3
----
[2012-09-21 06:33:46] r...@php.net
Description:
According to source code, DISABLE_AUTHENTICATOR could be a string or an array.
Works as expected:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>'GSSAPI');
Doesn't works:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>array('GSSAPI','NTLM'));
The trivial attached patch should fix this (but cannot test it)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63126&edit=1
Bug #63126 [Com]: DISABLE_AUTHENTICATOR ignores array
Edit report at https://bugs.php.net/bug.php?id=63126&edit=1
ID: 63126
Comment by: r...@php.net
Reported by: r...@php.net
Summary:DISABLE_AUTHENTICATOR ignores array
Status: Open
Type: Bug
Package:IMAP related
Operating System: GNU/Linux (Fedora 18)
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
I try to send my first pull request, I hope this is ok
https://github.com/php/php-src/pull/200
Previous Comments:
[2012-09-21 07:38:31] r...@php.net
I can find a exchange server an test the fix.
Test script:
$inbox =
imap_open($server,$userlogin,$password,OP_HALFOPEN,1,array('DISABLE_AUTHENTICATOR'
=> array('GSSAPI','NTLM')));
var_dump(imap_errors());
Without the patch:
array(2) {
[0]=>
string(148) "Kerberos error: Credentials cache file
'/run/user/1000/krb5cc_ea1f24ead9d3199b715d4d57505d4335/t (try running kinit)
for exchange2007."
[1]=>
string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}
With the patch:
array(1) {
[0]=>
string(55) "SECURITY PROBLEM: insecure server advertised AUTH=PLAIN"
}
----
[2012-09-21 06:42:50] r...@php.net
This also affects php 5.3
----
[2012-09-21 06:33:46] r...@php.net
Description:
According to source code, DISABLE_AUTHENTICATOR could be a string or an array.
Works as expected:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>'GSSAPI');
Doesn't works:
imap_open($srv,$user,$pass,OP_HALF_OPEN,1,
array('DISABLE_AUTHENTICATOR'=>array('GSSAPI','NTLM'));
The trivial attached patch should fix this (but cannot test it)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63126&edit=1
[PHP-BUG] Req #63147 [NEW]: Some tests fail because require internet connection
From: remi Operating system: GNU/Linux (Fedora 18) PHP version: 5.4.7 Package: Testing related Bug Type: Feature/Change Request Bug description:Some tests fail because require internet connection Description: Hi, Test which requires an internet connection (dns request, ...) fail if test are run offline. This is the case in some build environment. Proposal : add a SKIP_ONLINE_TESTS condition for such tests. I will submit a pull request. -- Edit bug report at https://bugs.php.net/bug.php?id=63147&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63147&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63147&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63147&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63147&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63147&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63147&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63147&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63147&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63147&r=support Expected behavior: https://bugs.php.net/fix.php?id=63147&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63147&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63147&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63147&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63147&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63147&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63147&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63147&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63147&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63147&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63147&r=mysqlcfg
Req #63147 [Com]: Some tests fail because require internet connection
Edit report at https://bugs.php.net/bug.php?id=63147&edit=1 ID: 63147 Comment by: r...@php.net Reported by: r...@php.net Summary:Some tests fail because require internet connection Status: Open Type: Feature/Change Request Package:Testing related Operating System: GNU/Linux (Fedora 18) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: See https://github.com/php/php-src/pull/201 Previous Comments: [2012-09-24 07:04:36] r...@php.net Description: Hi, Test which requires an internet connection (dns request, ...) fail if test are run offline. This is the case in some build environment. Proposal : add a SKIP_ONLINE_TESTS condition for such tests. I will submit a pull request. -- Edit this bug report at https://bugs.php.net/bug.php?id=63147&edit=1
[PHP-BUG] Bug #63149 [NEW]: Feature missing with system SQLite
From: remi Operating system: GNU/Linux (Fedora 18) PHP version: 5.4.7 Package: SQLite related Bug Type: Bug Bug description:Feature missing with system SQLite Description: When build against bundled SQLite, SQLITE_ENABLE_COLUMN_METADATA is defined, so sqlite3_column_table_name is know as available and used in pdo_sqlite (for getColumnMeta) When build against system SQlite, availability of sqlite3_column_table_name is not checked. This make bug_42589 fail. I will submit a pull request with the fix. -- Edit bug report at https://bugs.php.net/bug.php?id=63149&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63149&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63149&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63149&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63149&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63149&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63149&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63149&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63149&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63149&r=support Expected behavior: https://bugs.php.net/fix.php?id=63149&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63149&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63149&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63149&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63149&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63149&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63149&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63149&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63149&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63149&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63149&r=mysqlcfg
Bug #63149 [Com]: Feature missing with system SQLite
Edit report at https://bugs.php.net/bug.php?id=63149&edit=1 ID: 63149 Comment by: r...@php.net Reported by: r...@php.net Summary:Feature missing with system SQLite Status: Open Type: Bug Package:SQLite related Operating System: GNU/Linux (Fedora 18) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Please consider https://github.com/php/php-src/pull/203 Previous Comments: [2012-09-24 11:51:17] r...@php.net Description: When build against bundled SQLite, SQLITE_ENABLE_COLUMN_METADATA is defined, so sqlite3_column_table_name is know as available and used in pdo_sqlite (for getColumnMeta) When build against system SQlite, availability of sqlite3_column_table_name is not checked. This make bug_42589 fail. I will submit a pull request with the fix. -- Edit this bug report at https://bugs.php.net/bug.php?id=63149&edit=1
Req #63147 [Com]: Some tests fail because require internet connection
Edit report at https://bugs.php.net/bug.php?id=63147&edit=1 ID: 63147 Comment by: r...@php.net Reported by: r...@php.net Summary:Some tests fail because require internet connection Status: Open Type: Feature/Change Request Package:Testing related Operating System: GNU/Linux (Fedora 18) PHP Version:5.4.7 Block user comment: N Private report: N New Comment: There is a few tests concerned and probably a few people affected. But --offline option added (in the pull request) Note : if this "small" feature is accepted, I will also check the non-standard extension for such tests (currently, with run "make test", after build, only for static extension) Previous Comments: [2012-09-25 03:10:30] larue...@php.net remi, should there also be a corresponding option for run-test.php? ---- [2012-09-24 07:46:34] r...@php.net See https://github.com/php/php-src/pull/201 ---- [2012-09-24 07:04:36] r...@php.net Description: Hi, Test which requires an internet connection (dns request, ...) fail if test are run offline. This is the case in some build environment. Proposal : add a SKIP_ONLINE_TESTS condition for such tests. I will submit a pull request. -- Edit this bug report at https://bugs.php.net/bug.php?id=63147&edit=1
[PHP-BUG] Bug #63160 [NEW]: Lot of fstat call during include
From: remi Operating system: GNU/Linux PHP version: 5.4.7 Package: Performance problem Bug Type: Bug Bug description:Lot of fstat call during include Description: Hi, Each "include" statement call fstat 3 time, which can be "slow" in some cluster environment (usgin GFS2 p.e.) Already open as #49383 (but closed as "not a bug") The fstat cache is only available inside "plain_wrapper". A solution could be to expose a stream_cached_stat (in _php_stream_wrapper_ops) and use it during open process (or a additionnal parameter to stream_stat). But this will introduce a important bc break. Test script: --- Trivial test code: test1.php: https://bugs.php.net/bug.php?id=63160&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63160&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63160&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63160&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63160&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63160&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63160&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63160&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63160&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63160&r=support Expected behavior: https://bugs.php.net/fix.php?id=63160&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63160&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63160&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63160&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63160&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63160&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63160&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63160&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63160&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63160&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63160&r=mysqlcfg
Bug #63160 [Com]: Lot of fstat call during include
Edit report at https://bugs.php.net/bug.php?id=63160&edit=1
ID: 63160
Comment by: r...@php.net
Reported by: r...@php.net
Summary:Lot of fstat call during include
Status: Open
Type: Bug
Package:Performance problem
Operating System: GNU/Linux
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
Here is the backtrace for each fstat call
Breakpoint 1, do_fstat (d=d@entry=0x77fcbed0, force=force@entry=0) at
/usr/src/debug/php-5.4.7/main/streams/plain_wrapper.c:138
138 {
(gdb) bt
#0 do_fstat (d=d@entry=0x77fcbed0, force=force@entry=0) at
/usr/src/debug/php-5.4.7/main/streams/plain_wrapper.c:138
#1 0x00581d0b in _php_stream_fopen (filename=,
mode=0x6a3831 "rb", opened_path=0x7fffa7d0, options=) at
/usr/src/debug/php-5.4.7/main/streams/plain_wrapper.c:967
#2 0x0057d4f2 in _php_stream_open_wrapper_ex (path=0x77fcb238
"/home/rcollet/test/test2.php", path@entry=0x77eba2e0 "test2.php",
mode=mode@entry=0x6a3831 "rb", options=16520,
opened_path=opened_path@entry=0x7fffa7d0, context=context@entry=0x0) at
/usr/src/debug/php-5.4.7/main/streams/streams.c:2049
#3 0x00562a21 in php_stream_open_for_zend_ex (filename=0x77eba2e0
"test2.php", handle=0x7fffa7c0, mode=) at
/usr/src/debug/php-5.4.7/main/main.c:1303
#4 0x005d919c in zend_stream_fixup
(file_handle=file_handle@entry=0x7fffa7c0, buf=buf@entry=0x7fffa500,
len=len@entry=0x7fffa508) at /usr/src/debug/php-5.4.7/Zend/zend_stream.c:187
#5 0x0058de66 in open_file_for_scanning
(file_handle=file_handle@entry=0x7fffa7c0) at
Zend/zend_language_scanner.l:486
#6 0x0058e0f2 in compile_file (file_handle=0x7fffa7c0, type=2) at
Zend/zend_language_scanner.l:569
#7 0x701bbf5a in phar_compile_file (file_handle=0x7fffa7c0,
type=2) at /usr/src/debug/php-5.4.7/ext/phar/phar.c:3388
#8 0x0058e2e0 in compile_filename (type=type@entry=2,
filename=filename@entry=0x77fcc960) at Zend/zend_language_scanner.l:625
#9 0x006079fb in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER
(execute_data=0x77f97060) at
/usr/src/debug/php-5.4.7/Zend/zend_vm_execute.h:2592
#10 0x00623c47 in execute (op_array=0x77fcbaa8) at
/usr/src/debug/php-5.4.7/Zend/zend_vm_execute.h:410
#11 0x005c4a3c in zend_execute_scripts (type=type@entry=8,
retval=retval@entry=0x0, file_count=file_count@entry=3) at
/usr/src/debug/php-5.4.7/Zend/zend.c:1286
#12 0x005645bd in php_execute_script
(primary_file=primary_file@entry=0x7fffcd80) at
/usr/src/debug/php-5.4.7/main/main.c:2473
#13 0x0066c5c6 in do_cli (argc=2, argv=0x7fffe218) at
/usr/src/debug/php-5.4.7/sapi/cli/php_cli.c:988
#14 0x00425aaa in main (argc=2, argv=0x7fffe218) at
/usr/src/debug/php-5.4.7/sapi/cli/php_cli.c:1364
(gdb) c
Continuing.
Breakpoint 1, do_fstat (d=d@entry=0x77fcbed0, force=force@entry=1) at
/usr/src/debug/php-5.4.7/main/streams/plain_wrapper.c:138
138 {
(gdb) bt
#0 do_fstat (d=d@entry=0x77fcbed0, force=force@entry=1) at
/usr/src/debug/php-5.4.7/main/streams/plain_wrapper.c:138
#1 0x005807fa in php_stdiop_stat (stream=,
ssb=0x7fffa360) at /usr/src/debug/php-5.4.7/main/streams/plain_wrapper.c:546
#2 0x0056132f in php_zend_stream_fsizer
(handle=handle@entry=0x77fcbfa0) at
/usr/src/debug/php-5.4.7/main/main.c:1286
#3 0x00562aaf in php_stream_open_for_zend_ex (filename=0x77eba2e0
"test2.php", handle=0x7fffa7c0, mode=) at
/usr/src/debug/php-5.4.7/main/main.c:1318
#4 0x005d919c in zend_stream_fixup
(file_handle=file_handle@entry=0x7fffa7c0, buf=buf@entry=0x7fffa500,
len=len@entry=0x7fffa508) at /usr/src/debug/php-5.4.7/Zend/zend_stream.c:187
#5 0x0058de66 in open_file_for_scanning
(file_handle=file_handle@entry=0x7fffa7c0) at
Zend/zend_language_scanner.l:486
#6 0x0058e0f2 in compile_file (file_handle=0x7fffa7c0, type=2) at
Zend/zend_language_scanner.l:569
#7 0x701bbf5a in phar_compile_file (file_handle=0x7fffa7c0,
type=2) at /usr/src/debug/php-5.4.7/ext/phar/phar.c:3388
#8 0x0058e2e0 in compile_filename (type=type@entry=2,
filename=filename@entry=0x77fcc960) at Zend/zend_language_scanner.l:625
#9 0x006079fb in ZEND_INCLUDE_OR_EVAL_SPEC_CONST_HANDLER
(execute_data=0x77f97060) at
/usr/src/debug/php-5.4.7/Zend/zend_vm_execute.h:2592
#10 0x00623c47 in execute (op_array=0x77fcbaa8) at
/usr/src/debug/php-5.4.7/Zend/zend_vm_execute.h:410
#11 0x005c4a3c in zend_execute_scripts (type=type@entry=8,
retval=retval@entry=0x0, file_count=file_count@entry=3) at
/usr/src/debug/php-5.4.7/Zend/zend.c:1286
#12 0x005645bd in php_execute_script
(primary_file=primary_file@entry=0
[PHP-BUG] Bug #63171 [NEW]: Script hangs after max_execution_time
From: remi Operating system: GNU/Linux PHP version: 5.4.7 Package: ODBC related Bug Type: Bug Bug description:Script hangs after max_execution_time Description: As unixODBC functions are not async-signal-safe, nor safe to be longjmp'ed out, If a timeout occurs during an odbc calls, with a lock set, the PHP script will hangs. I have a patch proposal, will submit a pull request. Test script: --- https://bugs.php.net/bug.php?id=63171&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63171&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63171&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63171&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63171&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63171&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63171&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63171&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63171&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63171&r=support Expected behavior: https://bugs.php.net/fix.php?id=63171&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63171&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63171&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63171&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63171&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63171&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63171&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63171&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63171&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63171&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63171&r=mysqlcfg
Bug #63171 [Com]: Script hangs after max_execution_time
Edit report at https://bugs.php.net/bug.php?id=63171&edit=1 ID: 63171 Comment by: r...@php.net Reported by: r...@php.net Summary:Script hangs after max_execution_time Status: Open Type: Bug Package:ODBC related Operating System: GNU/Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Please, review https://github.com/php/php-src/pull/207 Pull request against 5.4, but could apply to all branches, 5.3, 5.4 and master. Previous Comments: [2012-09-27 11:36:19] r...@php.net Description: As unixODBC functions are not async-signal-safe, nor safe to be longjmp'ed out, If a timeout occurs during an odbc calls, with a lock set, the PHP script will hangs. I have a patch proposal, will submit a pull request. Test script: --- https://bugs.php.net/bug.php?id=63171&edit=1
[PHP-BUG] Bug #63172 [NEW]: Script hangs after max_execution_time (tzset)
From: remi Operating system: GNU/Linux PHP version: 5.4.7 Package: Unknown/Other Function Bug Type: Bug Bug description:Script hangs after max_execution_time (tzset) Description: As tzset functions is not async-signal-safe, nor safe to be longjmp'ed out, If a timeout occurs during soem glib call, with a lock set, the PHP script will hangs. tzset should not be called during timeout management. Attached patch solves this. Test script: --- https://bugs.php.net/bug.php?id=63172&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63172&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63172&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63172&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63172&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63172&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63172&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63172&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63172&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63172&r=support Expected behavior: https://bugs.php.net/fix.php?id=63172&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63172&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63172&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63172&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63172&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63172&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63172&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63172&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63172&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63172&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63172&r=mysqlcfg
[PHP-BUG] Bug #63235 [NEW]: buffer overflow in use of SQLGetDiagRec
From: remi Operating system: GNU/Linux PHP version: 5.4.7 Package: PDO related Bug Type: Bug Bug description:buffer overflow in use of SQLGetDiagRec Description: Already report on internals http://marc.info/?t=13426268866&r=1&w=2 Discard state is 5 char long, so buffer must be 6. Trivial fix attached. (could apply in all branches) -- Edit bug report at https://bugs.php.net/bug.php?id=63235&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63235&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63235&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63235&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63235&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63235&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63235&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63235&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63235&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63235&r=support Expected behavior: https://bugs.php.net/fix.php?id=63235&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63235&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63235&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63235&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63235&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63235&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63235&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63235&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63235&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63235&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63235&r=mysqlcfg
Bug #63235 [PATCH]: buffer overflow in use of SQLGetDiagRec
Edit report at https://bugs.php.net/bug.php?id=63235&edit=1 ID: 63235 Patch added by: r...@php.net Reported by: r...@php.net Summary:buffer overflow in use of SQLGetDiagRec Status: Open Type: Bug Package:PDO related Operating System: GNU/Linux PHP Version:5.4.7 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: php-5.3.3-pdo-overflow.patch Revision: 1349681821 URL: https://bugs.php.net/patch-display.php?bug=63235&patch=php-5.3.3-pdo-overflow.patch&revision=1349681821 Previous Comments: [2012-10-08 07:36:51] r...@php.net Description: Already report on internals http://marc.info/?t=13426268866&r=1&w=2 Discard state is 5 char long, so buffer must be 6. Trivial fix attached. (could apply in all branches) -- Edit this bug report at https://bugs.php.net/bug.php?id=63235&edit=1
[PHP-BUG] Bug #63236 [NEW]: Executable permission on various source files
From: remi Operating system: GNU/Linux PHP version: 5.4Git-2012-10-08 (Git) Package: *General Issues Bug Type: Bug Bug description:Executable permission on various source files Description: Not a big issue, but easy to fix one. This raises some warnings (rpmlint) for packaging on the "debuginfo" package. Test script: --- find . -name \*.[ch] -executable Expected result: empty result Actual result: -- ./Zend/zend_iterators.c ./Zend/zend_build.h ./Zend/zend_interfaces.h ./Zend/zend_interfaces.c ./Zend/zend_iterators.h ./ext/sqlite/libsqlite/src/config_static.w32.h ./ext/pcntl/pcntl.c ./ext/interbase/php_ibase_includes.h ./ext/com_dotnet/com_persist.c ./ext/enchant/enchant.c ./ext/pdo_oci/php_pdo_oci_int.h ./ext/pdo_oci/php_pdo_oci.h ./ext/pdo_oci/oci_statement.c ./ext/pdo_oci/oci_driver.c ./ext/pdo_oci/pdo_oci.c ./ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.h ./ext/mbstring/libmbfl/filters/mbfilter_iso8859_16.c ./ext/mbstring/libmbfl/mbfl/mbfl_defs.h ./ext/mbstring/oniguruma/enc/utf32_le.c ./ext/mbstring/oniguruma/enc/utf32_be.c ./ext/mbstring/oniguruma/enc/utf16_be.c ./ext/mbstring/oniguruma/enc/utf16_le.c ./ext/mbstring/oniguruma/regext.c ./ext/pdo_mysql/pdo_mysql.c ./ext/pdo_mysql/mysql_statement.c ./ext/pdo_mysql/mysql_driver.c ./ext/pdo_mysql/php_pdo_mysql.h ./ext/pdo_mysql/php_pdo_mysql_int.h ./ext/pdo/php_pdo.h ./ext/pdo/php_pdo_int.h ./ext/pdo/pdo_stmt.c ./ext/pdo/pdo.c ./ext/pdo/php_pdo_driver.h ./ext/pdo/pdo_dbh.c ./ext/spl/spl_exceptions.c ./ext/spl/spl_functions.h ./ext/spl/spl_exceptions.h ./ext/spl/spl_functions.c ./ext/spl/spl_array.h ./ext/spl/spl_observer.c ./ext/spl/spl_directory.h ./ext/spl/spl_directory.c ./ext/spl/spl_array.c ./ext/spl/php_spl.c ./ext/spl/spl_engine.h ./ext/spl/spl_iterators.c ./ext/spl/php_spl.h ./ext/spl/spl_iterators.h ./ext/spl/spl_observer.h ./ext/spl/spl_engine.c ./ext/simplexml/sxe.h ./ext/simplexml/php_simplexml_exports.h ./ext/simplexml/sxe.c ./ext/dba/php_db1.h ./ext/dba/dba_db1.c ./ext/dba/dba_qdbm.c ./ext/pdo_odbc/odbc_stmt.c ./ext/pdo_odbc/php_pdo_odbc_int.h ./ext/pdo_odbc/pdo_odbc.c ./ext/pdo_odbc/odbc_driver.c ./ext/standard/winver.h ./main/streams/glob_wrapper.c ./main/streams/php_stream_glob_wrapper.h ./main/streams/streams.c ./main/php_streams.h ./win32/globals.c ./win32/php_win32_globals.h -- Edit bug report at https://bugs.php.net/bug.php?id=63236&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63236&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63236&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63236&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63236&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63236&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63236&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63236&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63236&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63236&r=support Expected behavior: https://bugs.php.net/fix.php?id=63236&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63236&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63236&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63236&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63236&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63236&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63236&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63236&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63236&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63236&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63236&r=mysqlcfg
[PHP-BUG] Bug #63362 [NEW]: Not needed but installed headers.
From: remi Operating system: GNU/Linux (Fedora 18) PHP version: 5.4.8 Package: *General Issues Bug Type: Bug Bug description:Not needed but installed headers. Description: Various Windows specific headers are provided in the php sources (of course, this is absolutely not a problem). It will be great to not install them on other OS. Installed headers list: TSRM/tsrm_win32.h TSRM/tsrm_config.w32.h Zend/zend_config.w32.h ext/mysqlnd/config-win.h ext/standard/winver.h main/win32_internal_function_disabled.h main/win95nt.h -- Edit bug report at https://bugs.php.net/bug.php?id=63362&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63362&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63362&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63362&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63362&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63362&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63362&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63362&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63362&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63362&r=support Expected behavior: https://bugs.php.net/fix.php?id=63362&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63362&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63362&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63362&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63362&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63362&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63362&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63362&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63362&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63362&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63362&r=mysqlcfg
[PHP-BUG] Bug #63581 [NEW]: Possible null dereference and buffer overflow
From: remi Operating system: GNU/Linux (Fedora 18) PHP version: 5.4.8 Package: FPM related Bug Type: Bug Bug description:Possible null dereference and buffer overflow Description: 1. possible null dereference => fpm/fpm/fpm_events.c|435| I'm not familiar with the code, but it seems to be possible NULL dereference. Please, consider the situation (on line 425) when the 'q' item is the latest one on the list -- q->next does not exist (== NULL). Next, if the 'q' is also fpm_event_queue_timer (I'm not sure if this may occur?), program will crash on NULL dereference. 2. Same situation -> null dereference => fpm/fpm/fpm_events.c|191| Consider the queue length of 1. Than the condition (q == *queue) (line 189) must be true ~~> *queue = q->next (this is NULL) ~~> NULL->prev = NULL Again, I'm not sure if there may exist queue of single item. 3. off-by-one(two) (low prio) => fpm/fpm/fpm_log.c|459| The 'len' may be up to 1025 on this line. On line 149, consider 'len' to be equal to 1024 - program then continues down to line 453 where the 'len' is incremented. The problem could only occurs if, after increment (ligne 453), loop is not entered again. So when produced buffer is "exactly" 1024" or "1025". Test script: --- This issues where found from by static code analysis tool and, so, I can't provide any reproducer. -- Edit bug report at https://bugs.php.net/bug.php?id=63581&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63581&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63581&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63581&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63581&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63581&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63581&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63581&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63581&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63581&r=support Expected behavior: https://bugs.php.net/fix.php?id=63581&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63581&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63581&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63581&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63581&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63581&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63581&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63581&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63581&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63581&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63581&r=mysqlcfg
Bug #63581 [Com]: Possible null dereference and buffer overflow
Edit report at https://bugs.php.net/bug.php?id=63581&edit=1 ID: 63581 Comment by: r...@php.net Reported by: r...@php.net Summary:Possible null dereference and buffer overflow Status: Open Type: Bug Package:FPM related Operating System: GNU/Linux (Fedora 18) PHP Version:5.4.8 Block user comment: N Private report: N New Comment: See https://github.com/php/php-src/pull/234 Previous Comments: [2012-11-22 13:43:12] r...@php.net Description: 1. possible null dereference => fpm/fpm/fpm_events.c|435| I'm not familiar with the code, but it seems to be possible NULL dereference. Please, consider the situation (on line 425) when the 'q' item is the latest one on the list -- q->next does not exist (== NULL). Next, if the 'q' is also fpm_event_queue_timer (I'm not sure if this may occur?), program will crash on NULL dereference. 2. Same situation -> null dereference => fpm/fpm/fpm_events.c|191| Consider the queue length of 1. Than the condition (q == *queue) (line 189) must be true ~~> *queue = q->next (this is NULL) ~~> NULL->prev = NULL Again, I'm not sure if there may exist queue of single item. 3. off-by-one(two) (low prio) => fpm/fpm/fpm_log.c|459| The 'len' may be up to 1025 on this line. On line 149, consider 'len' to be equal to 1024 - program then continues down to line 453 where the 'len' is incremented. The problem could only occurs if, after increment (ligne 453), loop is not entered again. So when produced buffer is "exactly" 1024" or "1025". Test script: --- This issues where found from by static code analysis tool and, so, I can't provide any reproducer. -- Edit this bug report at https://bugs.php.net/bug.php?id=63581&edit=1
Bug #63581 [Com]: Possible null dereference and buffer overflow
Edit report at https://bugs.php.net/bug.php?id=63581&edit=1 ID: 63581 Comment by: r...@php.net Reported by: r...@php.net Summary:Possible null dereference and buffer overflow Status: Open Type: Bug Package:FPM related Operating System: GNU/Linux (Fedora 18) PHP Version:5.4.8 Block user comment: N Private report: N New Comment: I have forget, affected branches: 5.3, 5.4 and 5.5 Previous Comments: [2012-11-22 13:44:03] r...@php.net See https://github.com/php/php-src/pull/234 [2012-11-22 13:43:12] r...@php.net Description: 1. possible null dereference => fpm/fpm/fpm_events.c|435| I'm not familiar with the code, but it seems to be possible NULL dereference. Please, consider the situation (on line 425) when the 'q' item is the latest one on the list -- q->next does not exist (== NULL). Next, if the 'q' is also fpm_event_queue_timer (I'm not sure if this may occur?), program will crash on NULL dereference. 2. Same situation -> null dereference => fpm/fpm/fpm_events.c|191| Consider the queue length of 1. Than the condition (q == *queue) (line 189) must be true ~~> *queue = q->next (this is NULL) ~~> NULL->prev = NULL Again, I'm not sure if there may exist queue of single item. 3. off-by-one(two) (low prio) => fpm/fpm/fpm_log.c|459| The 'len' may be up to 1025 on this line. On line 149, consider 'len' to be equal to 1024 - program then continues down to line 453 where the 'len' is incremented. The problem could only occurs if, after increment (ligne 453), loop is not entered again. So when produced buffer is "exactly" 1024" or "1025". Test script: --- This issues where found from by static code analysis tool and, so, I can't provide any reproducer. -- Edit this bug report at https://bugs.php.net/bug.php?id=63581&edit=1
Bug #63520 [Com]: JSON extension includes a problematic license statement
Edit report at https://bugs.php.net/bug.php?id=63520&edit=1 ID: 63520 Comment by: r...@php.net Reported by:kaplan at debian dot org Summary:JSON extension includes a problematic license statement Status: Suspended Type: Bug Package:JSON related PHP Version:Irrelevant Block user comment: N Private report: N New Comment: A patch proposed in https://bugs.php.net/63588 makes "json_encode" really free. Previous Comments: [2012-11-15 18:09:30] ras...@php.net I am not saying it isn't a tricky license clause to deal with and it would be better if it wasn't there. However, I am also not keen on spending resources on rewriting code for this reason. If someone supplies a functionally equivalent replacement, we will have a look at it. But as far as I am concerned, license- wise the terms Good and Evil are not legal terms. These are more subjective self-describing terms and since I deem PHP's use of the code as "Good" then we comply with the license. Could others perhaps use PHP and thus the code for "Evil" and therefore not comply with the license? Sure, but there are many things people can do with our code that is either against the various licenses involved or even illegal criminally. It is something we cannot control. [2012-11-15 18:01:24] paj...@php.net More seriously, as soon as the license is changed upstream, we will merge it. But we won't be able to do anything before. [2012-11-15 18:00:52] paj...@php.net well, the FSF does not like the PHP license either. Nothing worries me here :) [2012-11-15 17:58:38] ansgar at debian dot org I just want to note that the FSF[1] and other distributions like Fedora also think this license is bad[2]. [1] <http://www.gnu.org/licenses/license-list.html#JSON> [2] <https://fedoraproject.org/wiki/Licensing:Main#Bad_Licenses>, look for "JSON License" So this is not a problem for just Debian. Ansgar [2012-11-15 07:39:35] ras...@php.net Sorry, I don't see us ripping out and rewriting the json code due to this. 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=63520 -- Edit this bug report at https://bugs.php.net/bug.php?id=63520&edit=1
[PHP-BUG] Bug #63635 [NEW]: Segfault in gc
From: remi
Operating system: GNU/Linux (Fedora 18)
PHP version: 5.4.9
Package: *General Issues
Bug Type: Bug
Bug description:Segfault in gc
Description:
When using huge object tree with circular reference,
With zend.enable_gc=0 : lot of memory consumed
With zend.enable_gc=1 : segfault
(gdb) bt
#0 0x005e23d9 in gc_zval_possible_root (zv=0x19e5500) at
/usr/src/debug/php-5.4.9/Zend/zend_gc.c:143
#1 0x005e40f7 in zend_object_std_dtor (object=0x7fffcf6f2020) at
/usr/src/debug/php-5.4.9/Zend/zend_objects.c:54
#2 0x005e4129 in zend_objects_free_object_storage
(object=0x7fffcf6f2020) at
/usr/src/debug/php-5.4.9/Zend/zend_objects.c:137
#3 0x005e9e53 in zend_objects_store_del_ref_by_handle_ex
(handle=3273, handlers=)
at /usr/src/debug/php-5.4.9/Zend/zend_objects_API.c:220
#4 0x005e220e in gc_collect_cycles () at
/usr/src/debug/php-5.4.9/Zend/zend_gc.c:832
#5 0x005e2303 in gc_zobj_possible_root (zv=0x19e5500,
zv@entry=0x1967560) at /usr/src/debug/php-5.4.9/Zend/zend_gc.c:221
#6 0x005e23ea in gc_zval_possible_root (zv=zv@entry=0x1967560) at
/usr/src/debug/php-5.4.9/Zend/zend_gc.c:143
#7 0x005f2ffd in gc_zval_check_possible_root (z=0x1967560) at
/usr/src/debug/php-5.4.9/Zend/zend_gc.h:183
#8 i_zval_ptr_dtor (zval_ptr=0x1967560) at
/usr/src/debug/php-5.4.9/Zend/zend_execute.h:97
#9 zend_leave_helper_SPEC (execute_data=0x77f855f8) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:468
#10 0x00624067 in execute (op_array=0x77fbfdf8) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:410
#11 0x717e0fd2 in xdebug_execute () from
/usr/lib64/php/modules/xdebug.so
#12 0x0066a529 in zend_do_fcall_common_helper_SPEC
(execute_data=0x77f85060) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:669
#13 0x00624067 in execute (op_array=0x77fbdab0) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:410
#14 0x717e0fd2 in xdebug_execute () from
/usr/lib64/php/modules/xdebug.so
#15 0x005c4dec in zend_execute_scripts (type=type@entry=8,
retval=retval@entry=0x0, file_count=file_count@entry=3)
at /usr/src/debug/php-5.4.9/Zend/zend.c:1309
#16 0x0056475d in php_execute_script
(primary_file=primary_file@entry=0x7fffcbb0) at
/usr/src/debug/php-5.4.9/main/main.c:2482
#17 0x0066ca66 in do_cli (argc=2, argv=0x7fffe048) at
/usr/src/debug/php-5.4.9/sapi/cli/php_cli.c:988
#18 0x00425b0a in main (argc=2, argv=0x7fffe048) at
/usr/src/debug/php-5.4.9/sapi/cli/php_cli.c:1364
Test script:
---
childs[] = $this;
}
$this->childs[] = $this;
}
function __destruct() {
$this->childs = NULL;
}
}
define("MAX", 16);
while (true) {
printf("Memory: %6.2fMB ->", memory_get_usage()/1024/1024);
$top = new Node();
for ($i=0 ; $i 5.62MB
Memory: 5.62MB -> 3.40MB
Memory: 3.40MB -> 5.62MB
Memory: 5.62MB -> 7.83MB
Memory: 7.83MB ->
Program received signal SIGSEGV, Segmentation fault.
--
Edit bug report at https://bugs.php.net/bug.php?id=63635&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63635&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63635&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63635&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63635&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63635&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63635&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63635&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63635&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63635&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63635&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63635&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63635&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63635&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63635&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63635&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63635&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63635&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63635&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63635&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63635&r=mysqlcfg
Bug #63635 [Com]: Segfault in gc_collect_cycles
Edit report at https://bugs.php.net/bug.php?id=63635&edit=1
ID: 63635
Comment by: r...@php.net
Reported by: r...@php.net
Summary:Segfault in gc_collect_cycles
Status: Open
Type: Bug
Package:*General Issues
Operating System: GNU/Linux (Fedora 18)
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
Note: without the circular reference, no segfault.
$this->childs[] = $this;
Previous Comments:
[2012-11-28 11:17:44] r...@php.net
Description:
When using huge object tree with circular reference,
With zend.enable_gc=0 : lot of memory consumed
With zend.enable_gc=1 : segfault
(gdb) bt
#0 0x005e23d9 in gc_zval_possible_root (zv=0x19e5500) at
/usr/src/debug/php-5.4.9/Zend/zend_gc.c:143
#1 0x005e40f7 in zend_object_std_dtor (object=0x7fffcf6f2020) at
/usr/src/debug/php-5.4.9/Zend/zend_objects.c:54
#2 0x005e4129 in zend_objects_free_object_storage
(object=0x7fffcf6f2020) at /usr/src/debug/php-5.4.9/Zend/zend_objects.c:137
#3 0x005e9e53 in zend_objects_store_del_ref_by_handle_ex (handle=3273,
handlers=)
at /usr/src/debug/php-5.4.9/Zend/zend_objects_API.c:220
#4 0x005e220e in gc_collect_cycles () at
/usr/src/debug/php-5.4.9/Zend/zend_gc.c:832
#5 0x005e2303 in gc_zobj_possible_root (zv=0x19e5500,
zv@entry=0x1967560) at /usr/src/debug/php-5.4.9/Zend/zend_gc.c:221
#6 0x005e23ea in gc_zval_possible_root (zv=zv@entry=0x1967560) at
/usr/src/debug/php-5.4.9/Zend/zend_gc.c:143
#7 0x005f2ffd in gc_zval_check_possible_root (z=0x1967560) at
/usr/src/debug/php-5.4.9/Zend/zend_gc.h:183
#8 i_zval_ptr_dtor (zval_ptr=0x1967560) at
/usr/src/debug/php-5.4.9/Zend/zend_execute.h:97
#9 zend_leave_helper_SPEC (execute_data=0x77f855f8) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:468
#10 0x00624067 in execute (op_array=0x77fbfdf8) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:410
#11 0x717e0fd2 in xdebug_execute () from
/usr/lib64/php/modules/xdebug.so
#12 0x0066a529 in zend_do_fcall_common_helper_SPEC
(execute_data=0x77f85060) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:669
#13 0x00624067 in execute (op_array=0x77fbdab0) at
/usr/src/debug/php-5.4.9/Zend/zend_vm_execute.h:410
#14 0x717e0fd2 in xdebug_execute () from
/usr/lib64/php/modules/xdebug.so
#15 0x005c4dec in zend_execute_scripts (type=type@entry=8,
retval=retval@entry=0x0, file_count=file_count@entry=3)
at /usr/src/debug/php-5.4.9/Zend/zend.c:1309
#16 0x0056475d in php_execute_script
(primary_file=primary_file@entry=0x7fffcbb0) at
/usr/src/debug/php-5.4.9/main/main.c:2482
#17 0x0066ca66 in do_cli (argc=2, argv=0x7fffe048) at
/usr/src/debug/php-5.4.9/sapi/cli/php_cli.c:988
#18 0x00425b0a in main (argc=2, argv=0x7fffe048) at
/usr/src/debug/php-5.4.9/sapi/cli/php_cli.c:1364
Test script:
---
childs[] = $this;
}
$this->childs[] = $this;
}
function __destruct() {
$this->childs = NULL;
}
}
define("MAX", 16);
while (true) {
printf("Memory: %6.2fMB ->", memory_get_usage()/1024/1024);
$top = new Node();
for ($i=0 ; $i 5.62MB
Memory: 5.62MB -> 3.40MB
Memory: 3.40MB -> 5.62MB
Memory: 5.62MB -> 7.83MB
Memory: 7.83MB ->
Program received signal SIGSEGV, Segmentation fault.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63635&edit=1
[PHP-BUG] Bug #63738 [NEW]: unpack string behavior change
From: remi
Operating system: GNU/Linux (Fedora 17)
PHP version: 5.5Git-2012-12-11 (snap)
Package: Unknown/Other Function
Bug Type: Bug
Bug description:unpack string behavior change
Description:
Seems a regression between 5.4.9 and 5.5.0-dev
This breaks Archive_Tar
Test script:
---
string(2) "AB"
}
Actual result:
--
With php 5.5.0-dev:
string(4) "AB^@^@"
array(1) {
["foo"]=>
string(4) "AB^@^@"
}
--
Edit bug report at https://bugs.php.net/bug.php?id=63738&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=63738&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=63738&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=63738&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=63738&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=63738&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=63738&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=63738&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=63738&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=63738&r=support
Expected behavior: https://bugs.php.net/fix.php?id=63738&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=63738&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=63738&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=63738&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63738&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=63738&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=63738&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=63738&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=63738&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=63738&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=63738&r=mysqlcfg
Req #63814 [Com]: angles parameters in imagefilledarc are integers, they should be float
Edit report at https://bugs.php.net/bug.php?id=63814&edit=1
ID: 63814
Comment by: r...@php.net
Reported by:webmaster at fxtop dot com
Summary:angles parameters in imagefilledarc are integers,
they should be float
Status: Open
Type: Feature/Change Request
Package:GD related
Operating System: Windows
PHP Version:5.4.9
Block user comment: N
Private report: N
New Comment:
the gd extension is mostly a wrapper for gd library.
As gd library doesn't accept float values for this comment, I think this is not
possible.
Previous Comments:
[2012-12-20 12:32:55] webmaster at fxtop dot com
Description:
see sample result at
http://mon-convertisseur.fr/php/imgangle.php?DEGRE=172.3
angles are truncated to nearest integer, in imagefilledarc function, they
shouldn't
you can change parameter if you like
---
>From manual page:
>http://www.php.net/function.imagefilledarc#refsect1-function.imagefilledarc-description
---
Test script:
---
header("Content-type: image/jpeg");
if (isset($_GET["DEGRE"])){ $lDegre=$_GET["DEGRE"];}
$lSizeX=916;
$lSizeY=945;
$image = imagecreatetruecolor($lSizeX, $lSizeY);
$colorGreen = imagecolorallocate($image, 0, 255, 0);
// background coming from
http://commons.wikimedia.org/wiki/File:Protractor_katomierz.jpg with some
little changes
$fond=imagecreatefromjpeg("Protractor_katomierz_tourne05b.jpg");
//HERE I ROUND DEGRE PARAMETER BECAUSE imagefilledarc only accept integers (I
prefer it rounded than truncated)
$lNumDegre=round($lDegre);
$lResult|=imagefilledarc ($image , 460 , 474 , 2*430 , 2*430 , -$lNumDegre ,
0, $colorGreen , IMG_ARC_PIE );
$lResult|=imagecopymerge($image, $fond, 0, 0, 0 , 0, $lSizeX,$lSizeY,75);
imagejpeg($image, "temp.jpg");
imagedestroy($image);
echo file_get_contents("temp.jpg");
Expected result:
imagefilledarc should accept float parameters for "start" and "end" parameters.
As you can see on sample at
http://mon-convertisseur.fr/php/imgangle.php?DEGRE=172.3 green backgound
allways fall on a degre graduation of the protactor.
--
Edit this bug report at https://bugs.php.net/bug.php?id=63814&edit=1
[PHP-BUG] Bug #64047 [NEW]: segfault in request shutdown (server_context is NULL)
From: remi
Operating system: GNU/Linux
PHP version: Irrelevant
Package: Apache2 related
Bug Type: Bug
Bug description:segfault in request shutdown (server_context is NULL)
Description:
We encounter, in specific race condition (seems http/500 error) a segfault
in php_request_shutdown.
According to backtrace, server_context is NULL.
This backtrace is from php 5.3.3, but as I don't see any change in git
history, I think it could occurs in latest php 5.3.
Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0 php_apache_sapi_header_handler (sapi_header=,
op=SAPI_HEADER_ADD, sapi_headers=)
at /usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:124
124 if (ctx->content_type) {
(gdb) bt
#0 php_apache_sapi_header_handler (sapi_header=,
op=SAPI_HEADER_ADD, sapi_headers=)
at /usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:124
#1 0x7fe16f2127ce in sapi_header_op (op=,
arg=) at /usr/src/debug/php-5.3.3/main/SAPI.c:756
#2 0x7fe16f212d98 in sapi_add_header_ex (header_line=0x7fe17ddff728
"Content-type: text/html", header_line_len=,
duplicate=0 '\000', replace=) at
/usr/src/debug/php-5.3.3/main/SAPI.c:515
#3 0x7fe16f2135e2 in sapi_send_headers () at
/usr/src/debug/php-5.3.3/main/SAPI.c:796
#4 0x7fe16f1bbdd9 in php_header () at
/usr/src/debug/php-5.3.3/ext/standard/head.c:69
#5 0x7fe16f21b3e3 in php_ub_body_write (str=0x7fe17f65b400 "",
str_length=0) at /usr/src/debug/php-5.3.3/main/output.c:719
#6 0x7fe16f21b998 in php_end_ob_buffer (send_buffer=1 '\001',
just_flush=0 '\000') at /usr/src/debug/php-5.3.3/main/output.c:298
#7 0x7fe16f21c249 in php_end_ob_buffers (send_buffer=1 '\001') at
/usr/src/debug/php-5.3.3/main/output.c:337
#8 0x7fe16f20873f in php_request_shutdown (dummy=) at /usr/src/debug/php-5.3.3/main/main.c:1598
#9 0x7fe16f2e2997 in php_apache_request_dtor (r=0x7fe17db8dd18) at
/usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:509
#10 php_handler (r=0x7fe17db8dd18) at
/usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:681
#11 0x7fe17c46ab00 in ap_run_handler (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/server/config.c:158
#12 0x7fe17c46e3be in ap_invoke_handler (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/server/config.c:376
#13 0x7fe17c479a30 in ap_process_request (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
#14 0x7fe17c4768f8 in ap_process_http_connection (c=0x7fe17da29518) at
/usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
#15 0x7fe17c472608 in ap_run_process_connection (c=0x7fe17da29518) at
/usr/src/debug/httpd-2.2.15/server/connection.c:43
#16 0x7fe17c47e807 in child_main (child_num_arg=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
#17 0x7fe17c47eb1a in make_child (s=0x7fe17d1d4860, slot=1) at
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:763
#18 0x7fe17c47f79c in perform_idle_server_maintenance (_pconf=, plog=, s=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:898
#19 ap_mpm_run (_pconf=, plog=,
s=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:1102
#20 0x7fe17c456900 in main (argc=1, argv=0x7fff82467b78) at
/usr/src/debug/httpd-2.2.15/server/main.c:760
(gdb) print sapi_globals
$1 = {server_context = 0x0, request_info = {request_method = 0x7fe17db8f638
"GET",
query_string = 0x7fe17d734d88
"option=###&view=main&article-id=",
post_data = 0x0,
raw_post_data = 0x0, cookie_data = 0x0, content_length = 0,
post_data_length = 0, raw_post_data_length = 0,
path_translated = 0x7fe17d734df8 "/var/www/html/index.php", request_uri
= 0x7fe17d734de8 "/index.php", content_type = 0x0,
headers_only = 0 '\000', no_headers = 0 '\000', headers_read = 0
'\000', post_entry = 0x0, content_type_dup = 0x0, auth_user = 0x0,
auth_password = 0x0, auth_digest = 0x0, argv0 = 0x0, current_user =
0x0, current_user_length = 0, argc = 0, argv = 0x0, proto_num = 1000},
sapi_headers = {headers = {head = 0x7fe17f0ecb70, tail = 0x7fe17e588a48,
count = 3, size = 16, dtor = 0x7fe16f212270 ,
persistent = 0 '\000', traverse_ptr = 0x0}, http_response_code = 500,
send_default_content_type = 0 '\000',
mimetype = 0x7fe17ddff980 "text/html", http_status_line =
0x7fe17ddfb750 "HTTP/1.0 500 Internal Server Error"}, read_post_bytes = 0,
headers_sent = 0 '\000', global_stat = {st_dev = 0, st_ino = 0, st_nlink
= 0, st_mode = 0, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0,
st_size = 0, st_blksize = 0, st_blocks = 0, st_atim = {tv_sec = 0,
tv_nsec = 0}, st_mtim = {t
Bug #64047 [PATCH]: segfault in request shutdown (server_context is NULL)
Edit report at https://bugs.php.net/bug.php?id=64047&edit=1
ID: 64047
Patch added by: r...@php.net
Reported by: r...@php.net
Summary:segfault in request shutdown (server_context is
NULL)
Status: Open
Type: Bug
Package:Apache2 related
Operating System: GNU/Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: temporary.patch
Revision: 1358863274
URL:
https://bugs.php.net/patch-display.php?bug=64047&patch=temporary.patch&revision=1358863274
Previous Comments:
[2013-01-22 14:00:33] r...@php.net
Description:
We encounter, in specific race condition (seems http/500 error) a segfault in
php_request_shutdown.
According to backtrace, server_context is NULL.
This backtrace is from php 5.3.3, but as I don't see any change in git history,
I think it could occurs in latest php 5.3.
Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0 php_apache_sapi_header_handler (sapi_header=,
op=SAPI_HEADER_ADD, sapi_headers=)
at /usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:124
124 if (ctx->content_type) {
(gdb) bt
#0 php_apache_sapi_header_handler (sapi_header=,
op=SAPI_HEADER_ADD, sapi_headers=)
at /usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:124
#1 0x7fe16f2127ce in sapi_header_op (op=, arg=) at /usr/src/debug/php-5.3.3/main/SAPI.c:756
#2 0x7fe16f212d98 in sapi_add_header_ex (header_line=0x7fe17ddff728
"Content-type: text/html", header_line_len=,
duplicate=0 '\000', replace=) at
/usr/src/debug/php-5.3.3/main/SAPI.c:515
#3 0x7fe16f2135e2 in sapi_send_headers () at
/usr/src/debug/php-5.3.3/main/SAPI.c:796
#4 0x7fe16f1bbdd9 in php_header () at
/usr/src/debug/php-5.3.3/ext/standard/head.c:69
#5 0x7fe16f21b3e3 in php_ub_body_write (str=0x7fe17f65b400 "",
str_length=0) at /usr/src/debug/php-5.3.3/main/output.c:719
#6 0x7fe16f21b998 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\000') at /usr/src/debug/php-5.3.3/main/output.c:298
#7 0x7fe16f21c249 in php_end_ob_buffers (send_buffer=1 '\001') at
/usr/src/debug/php-5.3.3/main/output.c:337
#8 0x7fe16f20873f in php_request_shutdown (dummy=) at
/usr/src/debug/php-5.3.3/main/main.c:1598
#9 0x7fe16f2e2997 in php_apache_request_dtor (r=0x7fe17db8dd18) at
/usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:509
#10 php_handler (r=0x7fe17db8dd18) at
/usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:681
#11 0x7fe17c46ab00 in ap_run_handler (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/server/config.c:158
#12 0x7fe17c46e3be in ap_invoke_handler (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/server/config.c:376
#13 0x7fe17c479a30 in ap_process_request (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
#14 0x7fe17c4768f8 in ap_process_http_connection (c=0x7fe17da29518) at
/usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
#15 0x7fe17c472608 in ap_run_process_connection (c=0x7fe17da29518) at
/usr/src/debug/httpd-2.2.15/server/connection.c:43
#16 0x7fe17c47e807 in child_main (child_num_arg=) at
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
#17 0x7fe17c47eb1a in make_child (s=0x7fe17d1d4860, slot=1) at
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:763
#18 0x7fe17c47f79c in perform_idle_server_maintenance (_pconf=, plog=, s=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:898
#19 ap_mpm_run (_pconf=, plog=,
s=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:1102
#20 0x7fe17c456900 in main (argc=1, argv=0x7fff82467b78) at
/usr/src/debug/httpd-2.2.15/server/main.c:760
(gdb) print sapi_globals
$1 = {server_context = 0x0, request_info = {request_method = 0x7fe17db8f638
"GET",
query_string = 0x7fe17d734d88
"option=###&view=main&article-id=",
post_data = 0x0,
raw_post_data = 0x0, cookie_data = 0x0, content_length = 0,
post_data_length = 0, raw_post_data_length = 0,
path_translated = 0x7fe17d734df8 "/var/www/html/index.php", request_uri =
0x7fe17d734de8 "/index.php", content_type = 0x0,
headers_only = 0 '\000', no_headers = 0 '\000', headers_read = 0 '\000',
post_entry = 0x0, content_type_dup = 0x0, auth_user = 0x0,
auth_password = 0x0, auth_digest = 0x0, argv0 = 0x0, current_user = 0x0,
current_user_length = 0, argc = 0, argv = 0x0, proto_num = 1000},
sapi_headers = {headers = {head
Bug #64047 [Com]: segfault in request shutdown (server_context is NULL)
Edit report at https://bugs.php.net/bug.php?id=64047&edit=1
ID: 64047
Comment by: r...@php.net
Reported by: r...@php.net
Summary:segfault in request shutdown (server_context is
NULL)
Status: Open
Type: Bug
Package:Apache2 related
Operating System: GNU/Linux
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
We are currently trying to run with the temporary patch applied to get more
information about the segfault context.
I will update this bug as soon as I will get more debug information.
Previous Comments:
[2013-01-22 14:01:14] r...@php.net
The following patch has been added/updated:
Patch Name: temporary.patch
Revision: 1358863274
URL:
https://bugs.php.net/patch-display.php?bug=64047&patch=temporary.patch&revision=1358863274
[2013-01-22 14:00:33] r...@php.net
Description:
We encounter, in specific race condition (seems http/500 error) a segfault in
php_request_shutdown.
According to backtrace, server_context is NULL.
This backtrace is from php 5.3.3, but as I don't see any change in git history,
I think it could occurs in latest php 5.3.
Core was generated by `/usr/sbin/httpd'.
Program terminated with signal 11, Segmentation fault.
#0 php_apache_sapi_header_handler (sapi_header=,
op=SAPI_HEADER_ADD, sapi_headers=)
at /usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:124
124 if (ctx->content_type) {
(gdb) bt
#0 php_apache_sapi_header_handler (sapi_header=,
op=SAPI_HEADER_ADD, sapi_headers=)
at /usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:124
#1 0x7fe16f2127ce in sapi_header_op (op=, arg=) at /usr/src/debug/php-5.3.3/main/SAPI.c:756
#2 0x7fe16f212d98 in sapi_add_header_ex (header_line=0x7fe17ddff728
"Content-type: text/html", header_line_len=,
duplicate=0 '\000', replace=) at
/usr/src/debug/php-5.3.3/main/SAPI.c:515
#3 0x7fe16f2135e2 in sapi_send_headers () at
/usr/src/debug/php-5.3.3/main/SAPI.c:796
#4 0x7fe16f1bbdd9 in php_header () at
/usr/src/debug/php-5.3.3/ext/standard/head.c:69
#5 0x7fe16f21b3e3 in php_ub_body_write (str=0x7fe17f65b400 "",
str_length=0) at /usr/src/debug/php-5.3.3/main/output.c:719
#6 0x7fe16f21b998 in php_end_ob_buffer (send_buffer=1 '\001', just_flush=0
'\000') at /usr/src/debug/php-5.3.3/main/output.c:298
#7 0x7fe16f21c249 in php_end_ob_buffers (send_buffer=1 '\001') at
/usr/src/debug/php-5.3.3/main/output.c:337
#8 0x7fe16f20873f in php_request_shutdown (dummy=) at
/usr/src/debug/php-5.3.3/main/main.c:1598
#9 0x7fe16f2e2997 in php_apache_request_dtor (r=0x7fe17db8dd18) at
/usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:509
#10 php_handler (r=0x7fe17db8dd18) at
/usr/src/debug/php-5.3.3/sapi/apache2handler/sapi_apache2.c:681
#11 0x7fe17c46ab00 in ap_run_handler (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/server/config.c:158
#12 0x7fe17c46e3be in ap_invoke_handler (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/server/config.c:376
#13 0x7fe17c479a30 in ap_process_request (r=0x7fe17db8dd18) at
/usr/src/debug/httpd-2.2.15/modules/http/http_request.c:282
#14 0x7fe17c4768f8 in ap_process_http_connection (c=0x7fe17da29518) at
/usr/src/debug/httpd-2.2.15/modules/http/http_core.c:190
#15 0x7fe17c472608 in ap_run_process_connection (c=0x7fe17da29518) at
/usr/src/debug/httpd-2.2.15/server/connection.c:43
#16 0x7fe17c47e807 in child_main (child_num_arg=) at
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:667
#17 0x7fe17c47eb1a in make_child (s=0x7fe17d1d4860, slot=1) at
/usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:763
#18 0x7fe17c47f79c in perform_idle_server_maintenance (_pconf=, plog=, s=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:898
#19 ap_mpm_run (_pconf=, plog=,
s=)
at /usr/src/debug/httpd-2.2.15/server/mpm/prefork/prefork.c:1102
#20 0x7fe17c456900 in main (argc=1, argv=0x7fff82467b78) at
/usr/src/debug/httpd-2.2.15/server/main.c:760
(gdb) print sapi_globals
$1 = {server_context = 0x0, request_info = {request_method = 0x7fe17db8f638
"GET",
query_string = 0x7fe17d734d88
"option=###&view=main&article-id=",
post_data = 0x0,
raw_post_data = 0x0, cookie_data = 0x0, content_length = 0,
post_data_length = 0, raw_post_data_length = 0,
path_translated = 0x7fe17d734df8 "/var/www/html/index.php", request_uri =
0x7fe17d734de8 "/index.php", content_type = 0x0,
headers_only = 0 '\000', no_headers = 0
[PHP-BUG] Bug #64111 [NEW]: Segfault in gc_zval_possible_root
From: remi Operating system: GNU/Linux (Fedora 18) PHP version: 5.4.11 Package: *General Issues Bug Type: Bug Bug description:Segfault in gc_zval_possible_root Description: Running a lot test suite (using phpunit) Truncated backtrace: Thread no. 1 (10 frames) #0 gc_zval_possible_root at /usr/src/debug/php-5.4.11/Zend/zend_gc.c:143 #1 zend_hash_destroy at /usr/src/debug/php-5.4.11/Zend/zend_hash.c:560 #2 _zval_dtor_func at /usr/src/debug/php-5.4.11/Zend/zend_variables.c:45 #3 _zval_dtor at /usr/src/debug/php-5.4.11/Zend/zend_variables.h:35 #4 _zval_ptr_dtor at /usr/src/debug/php-5.4.11/Zend/zend_execute_API.c:438 #6 destroy_zend_class at /usr/src/debug/php-5.4.11/Zend/zend_opcode.c:278 #7 zend_hash_apply_deleter at /usr/src/debug/php-5.4.11/Zend/zend_hash.c:650 #8 zend_hash_reverse_apply at /usr/src/debug/php-5.4.11/Zend/zend_hash.c:804 #9 shutdown_executor at /usr/src/debug/php-5.4.11/Zend/zend_execute_API.c:305 #10 zend_deactivate at /usr/src/debug/php-5.4.11/Zend/zend.c:938 At first look, I was thinking to a regression introduced by fix for #63635, but reverting the fix doesn't resolve the issue. Full traceback, php 5.4.10: https://bugzilla.redhat.com/attachment.cgi?id=684984 Full traceback, php 5.4.11: https://bugzilla.redhat.com/attachment.cgi?id=685073 Short traceback, php 5.4.11 with lot extension disable: https://bugzilla.redhat.com/attachment.cgi?id=686607 Sorry to not being able to produce a simple reproducer, but I could easily create a test build and ask the initial reporter to test it. -- Edit bug report at https://bugs.php.net/bug.php?id=64111&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64111&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64111&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64111&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64111&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64111&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64111&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64111&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64111&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=64111&r=support Expected behavior: https://bugs.php.net/fix.php?id=64111&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64111&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64111&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64111&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64111&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64111&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64111&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64111&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64111&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64111&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64111&r=mysqlcfg
[PHP-BUG] Bug #64123 [NEW]: Segfault in bug54268.phpt
bug/php5.5-201302010630/Zend/zend_objects_API.c:221 #68305 0x005c0e83 in zend_objects_store_del_ref (zobject=0x77fbaab8) at /usr/src/debug/php5.5-201302010630/Zend/zend_objects_API.c:173 #68306 0x00589520 in _zval_dtor (zvalue=0x77fbaab8) at /usr/src/debug/php5.5-201302010630/Zend/zend_variables.h:35 #68307 i_zval_ptr_dtor (zval_ptr=0x77fbaab8) at /usr/src/debug/php5.5-201302010630/Zend/zend_execute.h:81 #68308 _zval_ptr_dtor (zval_ptr=) at /usr/src/debug/php5.5-201302010630/Zend/zend_execute_API.c:428 #68309 0x0058e105 in cleanup_user_class_data (ce=0x77fba718) at /usr/src/debug/php5.5-201302010630/Zend/zend_opcode.c:169 #68310 zend_cleanup_user_class_data (pce=) at /usr/src/debug/php5.5-201302010630/Zend/zend_opcode.c:202 #68311 0x005a6a8c in zend_hash_reverse_apply (ht=0x988c40, apply_func=0x58e090 ) at /usr/src/debug/php5.5-201302010630/Zend/zend_hash.c:799 #68312 0x00589acf in shutdown_executor () at /usr/src/debug/php5.5-201302010630/Zend/zend_execute_API.c:289 #68313 0x00598a75 in zend_deactivate () at /usr/src/debug/php5.5-201302010630/Zend/zend.c:939 #68314 0x00537c2a in php_request_shutdown (dummy=dummy@entry=0x0) at /usr/src/debug/php5.5-201302010630/main/main.c:1800 #68315 0x00647f9d in do_cli (argc=5, argv=0x7fffe168) at /usr/src/debug/php5.5-201302010630/sapi/cli/php_cli.c:1171 #68316 0x00422a9a in main (argc=5, argv=0x7fffe168) at /usr/src/debug/php5.5-201302010630/sapi/cli/php_cli.c:1364 -- Edit bug report at https://bugs.php.net/bug.php?id=64123&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64123&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64123&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64123&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64123&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64123&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64123&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64123&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64123&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=64123&r=support Expected behavior: https://bugs.php.net/fix.php?id=64123&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64123&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64123&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64123&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64123&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64123&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64123&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64123&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64123&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64123&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64123&r=mysqlcfg
[PHP-BUG] Bug #64128 [NEW]: buit-in web server is broken on ppc64
From: remi Operating system: GNU/Linux PHP version: 5.4.11 Package: Built-in web server Bug Type: Bug Bug description:buit-in web server is broken on ppc64 Description: I think this bug also affects non x86 architecture built-in server don't answer to any request. Strace analysis show it enter an infinite loop of "select" but never accept any incoming connection. Source analysis show that fdset management using bit operator is broken. Switching to standard FD_ISSET method fix the problem. I have a patch ready to commit. Test script: --- This issue cause various test to fail: < Bug #61977 Test exit code for various errors [sapi/cli/tests/bug43177.phpt] < Bug #61679 (Error on non-standard HTTP methods) [sapi/cli/tests/bug61679.phpt] < Bug #61977 test CLI web-server support for Mime Type File extensions mapping [sapi/cli/tests/bug61977.phpt] < basic function [sapi/cli/tests/php_cli_server_001.phpt] < $_SERVER variable [sapi/cli/tests/php_cli_server_002.phpt] < Bug #55726 (Changing the working directory makes router script inaccessible) [sapi/cli/tests/php_cli_server_003.phpt] < Bug #55747 (request headers missed in $_SERVER) [sapi/cli/tests/php_cli_server_004.phpt] < Post a file [sapi/cli/tests/php_cli_server_005.phpt] < Bug #55755 (SegFault when outputting header WWW-Authenticate) [sapi/cli/tests/php_cli_server_006.phpt] < Bug #55758 (Digest Authenticate missed in 5.4) [sapi/cli/tests/php_cli_server_007.phpt] < SERVER_PROTOCOL header availability [sapi/cli/tests/php_cli_server_008.phpt] < PATH_INFO (relevant to #60112) [sapi/cli/tests/php_cli_server_009.phpt] < Bug #60180 ($_SERVER["PHP_SELF"] incorrect) [sapi/cli/tests/php_cli_server_010.phpt] < Bug #60180 ($_SERVER["PHP_SELF"] incorrect) [sapi/cli/tests/php_cli_server_011.phpt] < Bug #60159 (Router returns false, but POST is not passed to requested resource) [sapi/cli/tests/php_cli_server_012.phpt] < No router, no script [sapi/cli/tests/php_cli_server_013.phpt] < Bug #60477: Segfault after two multipart/form-data POST requestes [sapi/cli/tests/php_cli_server_014.phpt] < Bug #60523 (PHP Errors are not reported in browsers using built-in SAPI) [sapi/cli/tests/php_cli_server_015.phpt] < Bug #60591 (Memory leak when access a non-exists file) [sapi/cli/tests/php_cli_server_016.phpt] < Implement Req #60850 (Built in web server does not set $_SERVER['SCRIPT_FILENAME'] when using router) [sapi/cli/tests/php_cli_server_017.phpt] < Implement Req #61679 (Support HTTP PATCH method) [sapi/cli/tests/php_cli_server_018.phpt] -- Edit bug report at https://bugs.php.net/bug.php?id=64128&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64128&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64128&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64128&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64128&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64128&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64128&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64128&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64128&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64128&r=support Expected behavior: https://bugs.php.net/fix.php?id=64128&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64128&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64128&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64128&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64128&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64128&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64128&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64128&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64128&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64128&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64128&r=mysqlcfg
[PHP-BUG] Bug #64142 [NEW]: dval to lval different behavior on ppc64
From: remi
Operating system: GNU/Linux
PHP version: 5.4.11
Package: *General Issues
Bug Type: Bug
Bug description:dval to lval different behavior on ppc64
Description:
zend_dval_to_lval have different result on x86_64 and ppc64 (and probably
other arch)
This cause some test failure:
Test & operator : 64bit long tests
[tests/lang/operators/bitwiseAnd_basiclong_64bit.phpt]
Test ~N operator : 64bit long tests
[tests/lang/operators/bitwiseNot_basiclong_64bit.phpt]
Test | operator : 64bit long tests
[tests/lang/operators/bitwiseOr_basiclong_64bit.phpt]
Test ^ operator : 64bit long tests
[tests/lang/operators/bitwiseXor_basiclong_64bit.phpt]
Test % operator : 64bit long tests
[tests/lang/operators/modulus_basiclong_64bit.phpt]
Test decbin function : 64bit long tests
[ext/standard/tests/math/decbin_basiclong_64bit.phpt]
Test dechex function : 64bit long tests
[ext/standard/tests/math/dechex_basiclong_64bit.phpt]
Test decoct function : 64bit long tests
[ext/standard/tests/math/decoct_basiclong_64bit.phpt]
Test chunk_split() function : usage variations - unexpected values for
'chunklen' argument(Bug#42796)
[ext/standard/tests/strings/chunk_split_variation2.phpt]
Test script:
-------
php -r 'printf("%ld\n", 0x7fff);'
php -r 'printf("%ld\n", 0x7fff+1);'
Expected result:
9223372036854775807
-9223372036854775808
Actual result:
--
9223372036854775807
9223372036854775807
--
Edit bug report at https://bugs.php.net/bug.php?id=64142&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64142&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64142&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64142&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64142&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64142&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64142&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64142&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64142&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64142&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64142&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64142&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64142&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64142&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64142&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64142&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64142&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=64142&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64142&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64142&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64142&r=mysqlcfg
Bug #64142 [PATCH]: dval to lval different behavior on ppc64
Edit report at https://bugs.php.net/bug.php?id=64142&edit=1
ID: 64142
Patch added by: r...@php.net
Reported by: r...@php.net
Summary:dval to lval different behavior on ppc64
Status: Assigned
Type: Bug
Package:*General Issues
Operating System: GNU/Linux
PHP Version:5.4.11
Assigned To:remi
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: 0001-Fixed-bug-64142-dval-to-lval-different-behavior-on-p.patch
Revision: 1359988217
URL:
https://bugs.php.net/patch-display.php?bug=64142&patch=0001-Fixed-bug-64142-dval-to-lval-different-behavior-on-p.patch&revision=1359988217
Previous Comments:
[2013-02-04 14:15:11] r...@php.net
Description:
zend_dval_to_lval have different result on x86_64 and ppc64 (and probably other
arch)
This cause some test failure:
Test & operator : 64bit long tests
[tests/lang/operators/bitwiseAnd_basiclong_64bit.phpt]
Test ~N operator : 64bit long tests
[tests/lang/operators/bitwiseNot_basiclong_64bit.phpt]
Test | operator : 64bit long tests
[tests/lang/operators/bitwiseOr_basiclong_64bit.phpt]
Test ^ operator : 64bit long tests
[tests/lang/operators/bitwiseXor_basiclong_64bit.phpt]
Test % operator : 64bit long tests
[tests/lang/operators/modulus_basiclong_64bit.phpt]
Test decbin function : 64bit long tests
[ext/standard/tests/math/decbin_basiclong_64bit.phpt]
Test dechex function : 64bit long tests
[ext/standard/tests/math/dechex_basiclong_64bit.phpt]
Test decoct function : 64bit long tests
[ext/standard/tests/math/decoct_basiclong_64bit.phpt]
Test chunk_split() function : usage variations - unexpected values for
'chunklen' argument(Bug#42796)
[ext/standard/tests/strings/chunk_split_variation2.phpt]
Test script:
---
php -r 'printf("%ld\n", 0x7fff);'
php -r 'printf("%ld\n", 0x7fff+1);'
Expected result:
9223372036854775807
-9223372036854775808
Actual result:
--
9223372036854775807
9223372036854775807
--
Edit this bug report at https://bugs.php.net/bug.php?id=64142&edit=1
#21635 [NEW]: pg_escape_* want to allocate an insane amount of memory
From: [EMAIL PROTECTED] Operating system: FreeBSD/sparc64 5.0-RC3 PHP version: 4.2.3 PHP Bug Type: PostgreSQL related Bug description: pg_escape_* want to allocate an insane amount of memory Subject says it all. Working with PostgreSQL 7.3.1. Simple script to reproduce this behavior: FATAL: emalloc(): Unable to allocate 36514201601 bytes Webpages containing such code take a long time to be generated on the server but leave no error message in the Apache log. -- Edit bug report at http://bugs.php.net/?id=21635&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21635&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21635&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21635&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21635&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21635&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21635&r=support Expected behavior: http://bugs.php.net/fix.php?id=21635&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21635&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21635&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21635&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21635&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21635&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21635&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21635&r=gnused
#21635 [Bgs->Opn]: pg_escape_* want to allocate an insane amount of memory
ID: 21635 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: PostgreSQL related -Operating System: FreeBSD/sparc64 5.0-RC3 +Operating System: FreeBSD/sparc64 5.0-CURRENT -PHP Version: 4.2.3 +PHP Version: 4.3.0 New Comment: After having upgraded to 4.3.0, the problem persisted. In the meanwhile, I have also upgraded to PostgreSQL 7.3.2 but to no avail. Previous Comments: [2003-01-14 10:01:36] [EMAIL PROTECTED] 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. [2003-01-14 09:49:09] [EMAIL PROTECTED] Subject says it all. Working with PostgreSQL 7.3.1. Simple script to reproduce this behavior: FATAL: emalloc(): Unable to allocate 36514201601 bytes Webpages containing such code take a long time to be generated on the server but leave no error message in the Apache log. -- Edit this bug report at http://bugs.php.net/?id=21635&edit=1
#49357 [NEW]: MySQLi extension fails to recognize POINT (spatial) colums
From: phpbug at r-o-b-e-r-t dot de
Operating system: Debian/Ubuntu/Gentoo
PHP version: 5.2.10
PHP Bug Type: MySQLi related
Bug description: MySQLi extension fails to recognize POINT (spatial) colums
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT colums"
I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit bug report at http://bugs.php.net/?id=49357&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49357&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49357&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49357&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49357&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49357&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49357&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49357&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49357&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49357&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49357&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49357&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49357&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49357&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49357&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49357&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49357&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49357&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49357&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49357&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49357&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49357&r=mysqlcfg
#49358 [NEW]: MySQLi extension fails to recognize POINT (spatial) colums
From: phpbug at r-o-b-e-r-t dot de
Operating system: Debian/Ubuntu/Gentoo
PHP version: 5.2.10
PHP Bug Type: MySQLi related
Bug description: MySQLi extension fails to recognize POINT (spatial) colums
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT colums"
I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit bug report at http://bugs.php.net/?id=49358&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49358&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49358&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49358&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49358&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49358&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49358&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49358&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49358&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49358&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49358&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49358&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49358&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49358&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49358&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49358&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49358&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49358&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49358&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49358&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49358&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49358&r=mysqlcfg
#49359 [NEW]: MySQLi extension fails to recognize POINT (spatial) colums
From: bugs at r-o-b-e-r-t dot de
Operating system: Debian/Ubuntu/Gentoo
PHP version: 5.2.10
PHP Bug Type: MySQLi related
Bug description: MySQLi extension fails to recognize POINT (spatial) colums
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT colums"
I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit bug report at http://bugs.php.net/?id=49359&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49359&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49359&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49359&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49359&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49359&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49359&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49359&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49359&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49359&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49359&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49359&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49359&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49359&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49359&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49359&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49359&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49359&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49359&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49359&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49359&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49359&r=mysqlcfg
#49360 [NEW]: MySQLi extension fails to recognize POINT (spatial) colums
From: bugs at r-o-b-e-r-t dot de
Operating system: Debian/Ubuntu/Gentoo
PHP version: 5.2.10
PHP Bug Type: MySQLi related
Bug description: MySQLi extension fails to recognize POINT (spatial) colums
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT colums"
I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit bug report at http://bugs.php.net/?id=49360&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49360&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49360&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49360&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49360&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49360&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49360&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49360&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49360&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49360&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49360&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49360&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49360&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49360&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49360&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49360&r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=49360&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49360&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49360&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49360&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49360&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49360&r=mysqlcfg
#49357 [Com]: MySQLi extension fails to recognize POINT (spatial) colums
ID: 49357
Comment by: bugs at r-o-b-e-r-t dot de
Reported By: phpbug at r-o-b-e-r-t dot de
Status: Open
Bug Type: MySQLi related
Operating System: Debian/Ubuntu/Gentoo
PHP Version: 5.2.10
New Comment:
Sorry for my double-posting of the same bug.
But I got everytime an error, that the headers already was sent. So i
tried several times to submit my bug, and did not recognize, that it was
already submitted.
SORRY!!
regards
- Robert
Previous Comments:
[2009-08-25 14:55:11] phpbug at r-o-b-e-r-t dot de
Description:
As reported in Bug "#37671 MySQLi extension fails to recognize BIT
colums" I have the same problem with a Spatial Column.
The Column coord is a POINT Field.
Reproduce code:
---
Here is the Table-Definition:
CREATE TABLE `user` (
`coord` point default NULL,
) ENGINE=InnoDB
The Test Code:
// $mysqli is an existing db connection
$stmt = $mysqli->prepare("SELECT coord FROM user");
$stmt->execute();
$stmt->bind_result($res);
while ($stmt->fetch() === true ) {
debug_zval_dump($res);
var_dump($res);
}
$stmt->close();
Expected result:
The binary representation of the point
Actual result:
--
The Output is the same as the BIT-Field Problem (#37671)
Warning: mysqli_stmt::bind_result(): Server returned unknown type 255.
Probably your client library is incompatible with the server version you
use! in /home/robert/tmp/test.php on line 11
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
NULL refcount(1)
NULL
--
Edit this bug report at http://bugs.php.net/?id=49357&edit=1
Req #13756 [Com]: exponential ** operator
Edit report at https://bugs.php.net/bug.php?id=13756&edit=1 ID: 13756 Comment by: tom at r dot je Reported by:san...@php.net Summary:exponential ** operator Status: Closed Type: Feature/Change Request Package:Feature/Change Request Operating System: n/a PHP Version:4.0.6 Block user comment: N Private report: N New Comment: Indeed! Seems very despotic just to say "No. Deal with it" with no further discussion or explanation why. Previous Comments: [2012-07-08 23:31:23] hello at wesalvaro dot com le why not? [2002-04-27 16:17:03] j...@php.net not going to happen. just suck it up and use pow(). [2001-10-19 18:51:47] jer...@php.net I proposed that earlier (along with ^^) [ZendEnginge ML, june 27th & july 3rd]. Anyway, I think it should be added, there is simply no power operator now, and pow() is both a bit bugly and overloaded (both ^^ and ** at the same time). [2001-10-19 11:24:28] hholz...@php.net ** is Pascal, not C [2001-10-19 10:36:03] san...@php.net It would be nice to have an exponential operator. ** would be a logical choice, just like in C. Example: echo 2**3; // prints 8 I know we have pow(), but an operator for this would be nice... -- Edit this bug report at https://bugs.php.net/bug.php?id=13756&edit=1
Req #29812 [Com]: rename() don't overwrite existing files at windows (as at linux)
Edit report at https://bugs.php.net/bug.php?id=29812&edit=1 ID: 29812 Comment by: tom at r dot je Reported by:melker at kuh dot at Summary:rename() don't overwrite existing files at windows (as at linux) Status: Open Type: Feature/Change Request Package:Feature/Change Request Operating System: winxp PHP Version:4.3.8 Block user comment: N Private report: N New Comment: This isn't restricted to Windows XP but also affects other versions. I've tested Windows Vista and Windows Server 2008, both have this same problem. Previous Comments: [2004-08-24 12:36:20] melker at kuh dot at Description: Hi, rename ( 'file1', 'file2' ); behaviour at linux: If there is a 'file2', the file2 will be overwritten by file1. at windows xp: If there is a 'file2', a warning is given and the file2 isn't overwritten with file1. Reproduce code: --- rename ( 'file1', 'file2' ); Expected result: I would expect, that rename() works with the same behaviour at all operating systems. So, please overwrite existing files or give a warning at all os. Actual result: -- rename() at linux, existing files will be overwritten, at winxp, the rename-process fails, a php-warning is given. -- Edit this bug report at https://bugs.php.net/bug.php?id=29812&edit=1
#49100 [NEW]: Reference Native Function in variable (function pointers)
From: tom at r dot je
Operating system: Windows Vista
PHP version: 5.3.0
PHP Bug Type: Feature/Change Request
Bug description: Reference Native Function in variable (function pointers)
Description:
With the intorduction of closures it would be nice to be able to have some
control over native functions for example:
$foo = function() {
echo 'bar';
}
$foo();
Works fine.
It would be nice to be able to do something like
function foo() {
echo 'bar';
}
$foo = &foo;
$foo();
And ultimately, override the defined function:
function foo() {
echo 'bar';
}
$oldFoo = &foo;
foo = function() use ($oldFoo) {
$oldFoo();
echo 'bar';
}
foo(); // will print 'foobar';
There are several uses for this, just look at the way closures are
commonly used in javascript. It's really useful for debugging, as a
function can be substituted easily.
Though this probably isn't possible due to the clear distinction php makes
between functions and variables.
--
Edit bug report at http://bugs.php.net/?id=49100&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=49100&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=49100&r=trysnapshot53
Try a snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=49100&r=trysnapshot60
Fixed in SVN:
http://bugs.php.net/fix.php?id=49100&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=49100&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=49100&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=49100&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=49100&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=49100&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=49100&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=49100&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=49100&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=49100&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=49100&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49100&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=49100&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=49100&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=49100&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=49100&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=49100&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=49100&r=mysqlcfg
#40846 [Com]: pcre.backtrack_limit too restrictive
ID: 40846
Comment by: tom at r dot je
Reported By: crisp at xs4all dot nl
Status: Open
Bug Type: Feature/Change Request
Operating System: all
PHP Version: 5.2.1
New Comment:
This is still an issue in 5.3.
The low limit causes scripts which hit it to fail without a warning,
notice or error, creating hard to track down bugs For example, something
which works fine for one set of data stops working on another set
because the data is just longer.
This cannot be the expected behaviour, surely?
At minimum there needs to be a warning. Ideally though, the limit needs
to be put to the pcre defaults.
Previous Comments:
[2007-12-10 14:18:11] daan at react dot nl
This issue is still a problem, plus this low setting is also the cause
of segfaults.
(see http://bugs.php.net/bug.php?id=43031)
At the moment even this simple regexp segfaults 5.2.5:
preg_match('/(.)*/', str_repeat('x', 6000));
I hope that is not intended behavior, as is suggested in the reply in
bug report 43031.
[2007-08-16 19:00:13] drnick at physics dot byu dot edu
I just wanted to throw out that I completely agree with crisp. We
recently updated PHP on our webserver to 5.2.3 and had issues with our
template system on input sizes of a certain size (>100K).
The idea of allowing PHP to enforce limits on the PCRE library is fine,
but having the default action (when recursion_limit and backtrack_limit
are commented-out) be PHP overriding PCRE's internal limits is VERY
problematic. Aside from being incredibly anti backwards-compatible, I
believe PHP should not make arbitrary assumptions such as these.
I believe PHP should be changed so that the default action is to make
use of PCRE's internal limits, and if people want to enforce their own,
they can make that decision via the options. Perhaps modify
php.ini-recommended to explain the options and say why having external
limits can be good.
[2007-08-16 15:58:08] brandon at invisionpower dot com
Installations of 5.2 are causing this issue for us with relatively
simple regex. Users can submit an arbitrary amount of data (I work on a
bulletin board software) that is parsed out for bbcode tags. Even
simple expressions are causing problems.
$txt = preg_replace_callback(
"#\[code\](.+?)\[/code\]#is", array(
&$this, 'regex_code_tag' ), $txt );
var_dump( preg_last_error() );
The callback function is not being hit at all and the output is int(2)
(backtrack limit hit). Increasing backtrack limit to 1,000,000
"resolves" the issue, but with shared hosting plans it's unrealistic to
expect hosts to make php.ini changes to allow this.
I agree with crisp - the limit in PHP should bet set to the internal
PCRE options, with the php.ini settings allowing you to reduce them if
you wish. PHP should not arbitrarily reduce them.
[2007-05-20 11:22:00] crisp at xs4all dot nl
PHP 5.2.0 includes an update of the PCRE library (version 6.7), so some
problems may not be totally due to the restrictive limits of the PCRE
settings in PHP but could be a bug/regression in PCRE itself.
PCRE has always been very poor in internal optimisation of expressions
that contain look-aheads or look-behinds, especially when they are
combined with some OR'ed subexpression. It's backtracking mechanism is
quite simplistic and doesn't rule out execution paths that are sure not
to result in a match - in fact, it doesn't have any sort of execution
planner.
[2007-05-20 11:09:08] tigr at mail15 dot com
It is kinda strange: previous versions work pretty nice, swiftly
executing all patterns. And in some situations (as I mentioned before)
increasing recursion and backtrack limits just won't help. I suppose
it's wrong behaviour.
Also, note that examples are pretty short and simple. Increasing both
limits to 1 000 000 does not help - just why?
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/40846
--
Edit this bug report at http://bugs.php.net/?id=40846&edit=1
