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
From: remi Operating system: GNU/Linux PHP version: 5.3.25 Package: PostgreSQL related Bug Type: Bug Bug description:Buffer overflow in _pdo_pgsql_error Description: running the unit tests in ext/pdo_pgsql, 2 tests cause a segfault (with same backtrace) (gdb) run copy_from.php . Testing pgsqlCopyFromArray() with error *** buffer overflow detected ***: /usr/bin/php terminated ... (gdb) bt #0 0x74bfcba5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 #1 0x74bfe358 in __GI_abort () at abort.c:90 #2 0x74c3c59b in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x74d3f81f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:197 #3 0x74cd16b7 in __GI___fortify_fail (msg=msg@entry=0x74d3f7c5 "buffer overflow detected") at fortify_fail.c:31 #4 0x74ccf830 in __GI___chk_fail () at chk_fail.c:28 #5 0x7fffe67cdb61 in strcpy (__src=0x7fffe67d0c3a "Copy command failed", __dest=0x77fbf920 "Copy c") at /usr/include/bits/string3.h:104 #6 _pdo_pgsql_error (dbh=dbh@entry=0x77fbf8c8, stmt=stmt@entry=0x0, errcode=errcode@entry=7, sqlstate=0x7fffe67d0c3a "Copy command failed", file=, line=) at /usr/src/debug/php-5.5.0RC2/ext/pdo_pgsql/pgsql_driver.c:83 #7 0x7fffe67cee73 in zim_PDO_pgsqlCopyFromArray (ht=, return_value=0x77fbf9a8, return_value_ptr=, this_ptr=, return_value_used=) at /usr/src/debug/php-5.5.0RC2/ext/pdo_pgsql/pgsql_driver.c:611 #8 0x55778249 in dtrace_execute_internal (execute_data_ptr=, fci=, return_value_used=) at /usr/src/debug/php-5.5.0RC2/Zend/zend_dtrace.c:99 #9 0x55836dd3 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f83340) at /usr/src/debug/php-5.5.0RC2/Zend/zend_vm_execute.h:545 #10 0x557f6e78 in execute_ex (execute_data=0x77f83340) at /usr/src/debug/php-5.5.0RC2/Zend/zend_vm_execute.h:356 #11 0x5577810d in dtrace_execute_ex (execute_data=) at /usr/src/debug/php-5.5.0RC2/Zend/zend_dtrace.c:75 #12 0x55789b08 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 #13 0x557278dc in php_execute_script (primary_file=primary_file@entry=0x7fffcb80) at /usr/src/debug/php-5.5.0RC2/main/main.c:2481 #14 0x5583a4e6 in do_cli (argc=2, argv=0x55b7c3d0) at /usr/src/debug/php-5.5.0RC2/sapi/cli/php_cli.c:993 #15 0x5560f38a in main (argc=2, argv=0x55b7c3d0) at /usr/src/debug/php-5.5.0RC2/sapi/cli/php_cli.c:1377 (gdb) run copy_to.php ... Testing pgsqlCopyToArray() with error *** buffer overflow detected ***: /usr/bin/php terminated ... (gdb) bt #0 0x74bfcba5 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:63 #1 0x74bfe358 in __GI_abort () at abort.c:90 #2 0x74c3c59b in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x74d3f81f "*** %s ***: %s terminated\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:197 #3 0x74cd16b7 in __GI___fortify_fail (msg=msg@entry=0x74d3f7c5 "buffer overflow detected") at fortify_fail.c:31 #4 0x74ccf830 in __GI___chk_fail () at chk_fail.c:28 #5 0x7fffe67cdb61 in strcpy (__src=0x7fffe67d0c3a "Copy command failed", __dest=0x77fbbae8 "Copy c") at /usr/include/bits/string3.h:104 #6 _pdo_pgsql_error (dbh=dbh@entry=0x77fbba90, stmt=stmt@entry=0x0, errcode=errcode@entry=7, sqlstate=0x7fffe67d0c3a "Copy command failed", file=, line=) at /usr/src/debug/php-5.5.0RC2/ext/pdo_pgsql/pgsql_driver.c:83 #7 0x7fffe67ce68b in zim_PDO_pgsqlCopyToArray (ht=, return_value=0x77fbffe0, return_value_ptr=, this_ptr=, return_value_used=) at /usr/src/debug/php-5.5.0RC2/ext/pdo_pgsql/pgsql_driver.c:864 #8 0x55778249 in dtrace_execute_internal (execute_data_ptr=, fci=, return_value_used=) at /usr/src/debug/php-5.5.0RC2/Zend/zend_dtrace.c:99 #9 0x55836dd3 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f829c0) at /usr/src/debug/php-5.5.0RC2/Zend/zend_vm_execute.h:545 #10 0x557f6e78 in execute_ex (execute_data=0x77f829c0) at /usr/src/debug/php-5.5.0RC2/Zend/zend_vm_execute.h:356 #11 0x5577810d in dtrace_execute_ex (execute_data=) at /usr/src/debug/php-5.5.0RC2/Zend/zend_dtrace.c:75 #12 0x55789b08 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 #13 0x557278dc in php_execute_script (primary_file=primary_file@entry=0x7fffcb80) at /usr/src/debug/php-5.5.0RC2/main/main.c:2481 #14 0x5583a4e6 in do_cli (argc=2, argv=0x55b7c3d0) at /usr/src/debug/php-5.5.0RC2/sapi/cli/php_cli.c:993 #15 0x5560f38a in main (argc=2, argv=0x55b7c3d0) at /usr/src/debug/php-5.5.0RC2/sapi/cli/php_cli.c:1377 A trivial fix will be to switch to strncpy to avoid this buffer overflo
[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
[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 = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0,
tv_nsec = 0}, __unused = {0, 0, 0}}, default_mimetype =
0x7fe17d8be530 "text/html", default_charset = 0x7fe16f2ea939 "",
rfc1867_uploaded_files = 0x0
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
From: remi Operating system: GNU/Linux PHP version: 5.5.0alpha4 Package: *General Issues Bug Type: Bug Bug description:Segfault in bug54268.phpt Description: $ build-apache/sapi/cli/php -n -d memory_limit=8M Zend/tests/bug54268.php Erreur de segmentation (gdb) run -n -d memory_limit=8M Zend/tests/bug54268.php Starting program: /usr/bin/php -n -d memory_limit=8M Zend/tests/bug54268.php Program received signal SIGSEGV, Segmentation fault. zend_execute (op_array=0x77fbabb8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:377 (gdb) bt #0 zend_execute (op_array=0x77fbabb8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:377 #1 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3bc8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #2 0x00605d18 in execute_ex (execute_data=0x715e3bc8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #3 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #4 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3b00) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #5 0x00605d18 in execute_ex (execute_data=0x715e3b00) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #6 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #7 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3a38) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #8 0x00605d18 in execute_ex (execute_data=0x715e3a38) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #9 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #10 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3970) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #11 0x00605d18 in execute_ex (execute_data=0x715e3970) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #12 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #13 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e38a8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #14 0x00605d18 in execute_ex (execute_data=0x715e38a8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #15 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #16 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e37e0) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #17 0x00605d18 in execute_ex (execute_data=0x715e37e0) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #18 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #19 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3718) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #20 0x00605d18 in execute_ex (execute_data=0x715e3718) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #21 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #22 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3650) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #23 0x00605d18 in execute_ex (execute_data=0x715e3650) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #24 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #25 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e3588) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #26 0x00605d18 in execute_ex (execute_data=0x715e3588) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #27 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #28 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e34c0) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #29 0x00605d18 in execute_ex (execute_data=0x715e34c0) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:356 #30 0x005891cd in dtrace_execute_ex (execute_data=) at /usr/src/debug/php5.5-201302010630/Zend/zend_dtrace.c:75 #31 0x00645bb4 in zend_do_fcall_common_helper_SPEC (execute_data=0x715e33f8) at /usr/src/debug/php5.5-201302010630/Zend/zend_vm_execute.h:573 #32 0x00605d18 in execute_ex (execute_data=0x715e33f8) at /u
[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
