Bug #60598 [PATCH]: cli/apache sapi segfault on objects manipulation
Edit report at https://bugs.php.net/bug.php?id=60598&edit=1 ID: 60598 Patch added by: larue...@php.net Reported by:arekm at maven dot pl Summary:cli/apache sapi segfault on objects manipulation Status: Feedback Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.0RC3 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60598 Revision: 134584 URL: https://bugs.php.net/patch-display.php?bug=60598&patch=bug60598&revision=134584 Previous Comments: [2013-08-28 13:25:45] manuel-php at mausz dot at Still the same with 5.4.19 # php -n test.php If you see this, try to increase OBJECT_COUNT to 100,000Segmentation fault [2013-08-28 13:05:43] ras...@php.net Please try again with 5.4.19. There were some fixes related to this applied in 5.4.18. [2013-06-05 11:51:34] arjen at react dot com Problem still present in php-5.4.15 verified from php.net src. See https://gist.github.com/anonymous/5713352 for bt. [2012-11-25 15:07:30] manuel-php at mausz dot at Same on git master: [object_properties_init] name=Object addr=2e3b42b0 pt_addr=2e3b6270 pt[0]_addr=2e3b4dc8 pt[0].handle=#0 [zend_std_write_property] name=_guid (=pt[0]) old_addr=2e3b4dc8 new_addr=2e3b42f8 new.handle=#0 [object_properties_init] name=Object addr=2e3b6688 pt_addr=2e3b6a60 pt[0]_addr=2e3b4dc8 pt[0].handle=#0 [zend_std_write_property] name=_guid (=pt[0]) old_addr=2e3b4dc8 new_addr=2e3b66d0 new.handle=#1 [zval_collect_white] adding zval to zval_to_free-list zval: addr=2e3b42f8 refcnt=2 handle=#0 [gc_collect_cycles] freeing zval zval: addr=2e3b42f8 refcnt=2 handle=#0 ^^ - 1st zval free [zend_object_std_dtor] object=Object addr=2e3b42b0 pt_addr=2e3b6270 calling zval_ptr_dtor for pt[0]_addr=2e3b42f8 pt[0].refcnt=1515870810 ^^ - 2nd zval free pt[0].handle=#1515870810 [zend_object_std_dtor] object=Object addr=2e3b6688 pt_addr=2e3b6a60 calling zval_ptr_dtor for pt[0]_addr=2e3b66d0 pt[0].refcnt=1 pt[0].handle=#1 Patch for my debug output: https://gist.github.com/095e8dc10c3e18afb3e6 I recommend enabling ZEND_MM_HEAP_PROTECTION. This is why refcnt+handle is 0x5a5a5a5a on 2nd free. [2012-11-25 08:57:04] arekm at maven dot pl Tested http://snaps.php.net/php5.4-latest.tar.gz and still happens. [arekm@ixion-pld ~/test/php5.4-201211250630]$ export LC_ALL=C [arekm@ixion-pld ~/test/php5.4-201211250630]$ ./sapi/cli/php -n ./a.php If you see this, try to increase OBJECT_COUNT to 100,000 zsh: segmentation fault ./sapi/cli/php -n ./a.php [arekm@ixion-pld ~/test/php5.4-201211250630]$ ./sapi/cli/php -n --version PHP 5.5.0-dev (cli) (built: Nov 25 2012 09:37:34) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies [arekm@ixion-pld ~/test/php5.4-201211250630]$ gdb --args ./sapi/cli/php -n ./a.php GNU gdb (GDB) 7.4.50-0.20120120.2 (PLD Linux) Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pld-linux". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/users/arekm/test/php5.4- 201211250630/sapi/cli/php...done. (gdb) r Starting program: /home/users/arekm/test/php5.4-201211250630/sapi/cli/php -n ./a.php [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". If you see this, try to increase OBJECT_COUNT to 100,000 Program received signal SIGSEGV, Segmentation fault. 0x006810d2 in gc_zval_possible_root (zv=0x77fabe78) at /home/users/arekm/test/php5.4-201211250630/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006810d2 in gc_zval_possible_root (zv=0x77fabe78) at /home/users/arekm/test/php5.4-201211250630/Zend/zend_gc.c:143 #1 0x00682ce7 in zend_object_std_dtor (object=0x77fabe48) at /home/users/arekm/test/php5.4-201211250630/Zend/zend_objects.c:54 #2 0x00682d19 in zend_objects_free_object_storage (object=0x77fabe48) at /home/users/arekm/test/php5.4- 201211250630/Zend/zend_objects.c:137
[PHP-BUG] Bug #65447 [NEW]: Two tests start to fail in ext/dom
From: laruence
Operating system:
PHP version: 5.5.1
Package: Testing related
Bug Type: Bug
Bug description:Two tests start to fail in ext/dom
Description:
Test DOMDocument::loadXML() detects not-well formed XML
[ext/dom/tests/DOMDocument_loadXML_error4.phpt]
Test DOMDocument::load() detects not-well formed XML
[ext/dom/tests/DOMDocument_load_error4.phpt]
$ cat ext/dom/tests/DOMDocument_loadXML_error4.diff
001+ Notice: DOMDocument::loadXML(): Unsupported version '3.1' in Entity,
line: 1
in /home/huixinchen/opensource/php-
5.5/ext/dom/tests/DOMDocument_loadXML_error4.php on line 8
001- Warning: DOMDocument::load%r(XML){0,1}%r(): Unsupported version '3.1'
%s
002+
003+ Warning: assert(): Assertion "$result === $expectedResult" failed in
/home/huixinchen/opensource/php-5.5/ext/dom/tests/DOMDocument_loadXML_error4.php
on line 11
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit bug report at https://bugs.php.net/bug.php?id=65447&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=65447&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=65447&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=65447&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=65447&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=65447&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=65447&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=65447&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=65447&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=65447&r=support
Expected behavior: https://bugs.php.net/fix.php?id=65447&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=65447&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=65447&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=65447&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=65447&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=65447&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=65447&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=65447&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=65447&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=65447&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=65447&r=mysqlcfg
Bug #65431 [PATCH]: Discarded qualifiers from pointer target warnings when using --enable-dtrace
Edit report at https://bugs.php.net/bug.php?id=65431&edit=1 ID: 65431 Patch added by: larue...@php.net Reported by:s...@php.net Summary:Discarded qualifiers from pointer target warnings when using --enable-dtrace Status: Feedback Type: Bug Package:Compile Warning Operating System: Linux PHP Version:5.4Git-2013-08-09 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: dtrace_casts_2.patch Revision: 1376363806 URL: https://bugs.php.net/patch-display.php?bug=65431&patch=dtrace_casts_2.patch&revision=1376363806 Previous Comments: [2013-08-13 03:14:00] larue...@php.net I got merge conflicts when I was trying to merge this patch.. I made a new one, but I dont have dtrace in my box avaliable. so, could you please verify the patch? [2013-08-09 22:32:29] s...@php.net Description: Here are some patches to fix cast warnings when --enable-dtrace is used. The dtrace utility typically discards/discarded 'const' qualifiers. I don't have Zend karma to apply them myself. The patches should be applied to PHP 5.4+ and then 'php zend_vm_gen.php' run. (The patches are a diff from the PHP-5.5 branch) -- Edit this bug report at https://bugs.php.net/bug.php?id=65431&edit=1
Bug #65372 [PATCH]: Segfault in gc_zval_possible_root
Edit report at https://bugs.php.net/bug.php?id=65372&edit=1 ID: 65372 Patch added by: larue...@php.net Reported by:sreed at ontraport dot com Summary:Segfault in gc_zval_possible_root Status: Verified Type: Bug Package:Reproducible crash Operating System: Fedora PHP Version:5.4Git-2013-08-01 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug65372.patch Revision: 1375408763 URL: https://bugs.php.net/patch-display.php?bug=65372&patch=bug65372.patch&revision=1375408763 Previous Comments: [2013-08-01 19:18:26] sreed at ontraport dot com Description: PHP is segfaulting during shutdown in gc_zval_possible_root. This bug appears to have appeared in version 5.4: http://3v4l.org/qLqe3. Test script: --- https://gist.github.com/sreed-ontraport/6134324 Expected result: Script executes and PHP exits cleanly Actual result: -- 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4- 201308011830/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006a0032 in gc_zval_possible_root (zv=0x77fc5108) at /tmp/php5.4-201308011830/Zend/zend_gc.c:143 #1 0x006a1c47 in zend_object_std_dtor (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:54 #2 0x006a1c79 in zend_objects_free_object_storage (object=0x77fc8970) at /tmp/php5.4-201308011830/Zend/zend_objects.c:137 #3 0x006a74c8 in zend_objects_store_free_object_storage (objects=0xd8a0a0 ) at /tmp/php5.4- 201308011830/Zend/zend_objects_API.c:92 #4 0x0067396b in shutdown_executor () at /tmp/php5.4- 201308011830/Zend/zend_execute_API.c:295 #5 0x00681aa6 in zend_deactivate () at /tmp/php5.4- 201308011830/Zend/zend.c:938 #6 0x0062417d in php_request_shutdown (dummy=dummy@entry=0x0) at /tmp/php5.4-201308011830/main/main.c:1803 #7 0x00726094 in do_cli (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1172 #8 0x004255ca in main (argc=2, argv=0x7fffe148) at /tmp/php5.4- 201308011830/sapi/cli/php_cli.c:1365 -- Edit this bug report at https://bugs.php.net/bug.php?id=65372&edit=1
Bug #65304 [PATCH]: Use of max int in array_sum
Edit report at https://bugs.php.net/bug.php?id=65304&edit=1 ID: 65304 Patch added by: larue...@php.net Reported by:koushky at gmail dot com Summary:Use of max int in array_sum Status: Open Type: Bug Package:Arrays related Operating System: Ubuntu 13.04 64bit PHP Version:5.4.17 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug65304.patch Revision: 1374408685 URL: https://bugs.php.net/patch-display.php?bug=65304&patch=bug65304.patch&revision=1374408685 Previous Comments: [2013-07-21 09:47:33] koushky at gmail dot com update [2013-07-21 09:37:52] koushky at gmail dot com Description: If we add amount of max INT with number 1 in array_sum function , the result will be false. While if we add this two via plus (+) operator ,the result will be true. My operation system is 64 bit. Test script: --- /* max INT in 64bit = 9223372036854775807 */ var_dump(array_sum(array(9223372036854775807,1))); var_dump(9223372036854775807+1); Expected result: int(-9223372036854775808) float(9.2233720368548E+18) Actual result: -- float(9.2233720368548E+18) float(9.2233720368548E+18) -- Edit this bug report at https://bugs.php.net/bug.php?id=65304&edit=1
Bug #64997 [PATCH]: Segfault while using RecursiveIteratorIterator on 64-bits systems
Edit report at https://bugs.php.net/bug.php?id=64997&edit=1
ID: 64997
Patch added by: larue...@php.net
Reported by:cyrille dot faucheux+php at gmail dot com
Summary:Segfault while using RecursiveIteratorIterator on
64-bits systems
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Debian Jessie 64-bits
PHP Version:5.5Git-2013-06-08 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64997.patch
Revision: 1370774591
URL:
https://bugs.php.net/patch-display.php?bug=64997&patch=bug64997.patch&revision=1370774591
Previous Comments:
[2013-06-09 10:33:55] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64977.patch
Revision: 1370774035
URL:
https://bugs.php.net/patch-display.php?bug=64997&patch=bug64977.patch&revision=1370774035
[2013-06-08 23:22:17] cyrille dot faucheux+php at gmail dot com
Description:
I was playing with the Respect data validation library from [1], which makes
use of Recursive*Iterator to retrieve validation errors.
On my 64-bits Debian Jessie, retrieving the errors with the getFullMessage()
function causes a segfault. On a 32-bits one, everything works as expected. May
be related to bug #48206.
This bug is reproducible with the versions 5.4.4-15 (packaged by Debian) and
the 5.5Git from today (bccacb6).
How to reproduce:
- Clone from [1].
- Place the attached script at the root of the checkout.
- Run # php demo.php
[1]: https://github.com/Respect/Validation
Test script:
---
length(1,32))
->key('birthdate', v::date('Y-m-d')->minimumAge(18)->setName('age'));
try {
$userValidator->assert(array('name' => 'bob', 'birthdate' => "1996-07-18"));
} catch (\InvalidArgumentException $e) {
var_dump($e->getFullMessage());
}
Expected result:
Should display:
string(73) "\-These rules must pass for "Array"
\-The age must be 18 years or more."
Actual result:
--
#0 0x006f84d0 in gc_remove_from_buffer (root=0x5dfcbc
) at
/root/Dev/php/v5.5/Zend/zend_gc.h:189
#1 gc_remove_zval_from_buffer (zv=zv@entry=0x7fffce7c89f0) at
/root/Dev/php/v5.5/Zend/zend_gc.c:265
#2 0x006c9948 in i_zval_ptr_dtor (zval_ptr=0x7fffce7c89f0) at
/root/Dev/php/v5.5/Zend/zend_execute.h:80
#3 _zval_ptr_dtor (zval_ptr=) at
/root/Dev/php/v5.5/Zend/zend_execute_API.c:426
#4 0x006cb55d in zend_call_function (fci=fci@entry=0x7fffce7c8820,
fci_cache=0x7ffd74ba0960, fci_cache@entry=0x7fffce7c87f0)
at /root/Dev/php/v5.5/Zend/zend_execute_API.c:999
#5 0x006f0bf5 in zend_call_method
(object_pp=object_pp@entry=0x7fffce7c88d8, obj_ce=,
obj_ce@entry=0x7ffd766757c8,
fn_proxy=fn_proxy@entry=0x7ffd76675930,
function_name=function_name@entry=0xb7ff4f "__tostring",
function_name_len=function_name_len@entry=10,
retval_ptr_ptr=retval_ptr_ptr@entry=0x7fffce7c88e8,
param_count=param_count@entry=0, arg1=arg1@entry=0x0, arg2=arg2@entry=0x0)
at /root/Dev/php/v5.5/Zend/zend_interfaces.c:97
#6 0x006fcab4 in zend_std_cast_object_tostring
(readobj=0x7fffce7c89f0, writeobj=0x7fffce7c8930, type=)
at /root/Dev/php/v5.5/Zend/zend_object_handlers.c:1537
#7 0x006d0810 in _convert_to_string (op=op@entry=0x7fffce7c89f0) at
/root/Dev/php/v5.5/Zend/zend_operators.c:643
#8 0x005e31c8 in spl_recursive_tree_iterator_get_entry
(return_value=return_value@entry=0x7fffce7c89f0, object=0x7ffd74bb6c20,
object=0x7ffd74bb6c20)
at /root/Dev/php/v5.5/ext/spl/spl_iterators.c:1021
#9 0x005e3326 in zim_spl_RecursiveTreeIterator_current (ht=0,
return_value=0x7ffd74bb5dd0, return_value_ptr=,
this_ptr=,
return_value_used=) at
/root/Dev/php/v5.5/ext/spl/spl_iterators.c:1123
#10 0x006cb868 in zend_call_function (fci=fci@entry=0x7fffce7c8c10,
fci_cache=fci_cache@entry=0x7fffce7c8be0) at
/root/Dev/php/v5.5/Zend/zend_execute_API.c:957
#11 0x006f0bf5 in zend_call_method
(object_pp=object_pp@entry=0x7fffce7c8cc8, obj_ce=,
fn_proxy=0x2587488,
function_name=function_name@entry=0x7945d6 "current",
function_name_len=function_name_len@entry=7,
retval_ptr_ptr=retval_ptr_ptr@entry=0x7ffd74bb5aa8,
param_count=param_count@entry=0, arg1=arg1@entry=0x0, arg2=arg2@entry=0x0)
at /root/Dev/php/v5.5/Zend/zend_interfaces.c:97
#12 0x006f126e in zend_user_it_get_current_data (_iter=0x7ffd74bb5a88,
data=0x7fffce7c8d00) at /root/Dev/php/v5.5/Zend/zend_interfaces.c:181
#13 0x00725ebc in ZEND_FE_FETCH_SPEC_VAR_HANDLER
(execu
Bug #64997 [PATCH]: Segfault while using RecursiveIteratorIterator on 64-bits systems
Edit report at https://bugs.php.net/bug.php?id=64997&edit=1
ID: 64997
Patch added by: larue...@php.net
Reported by:cyrille dot faucheux+php at gmail dot com
Summary:Segfault while using RecursiveIteratorIterator on
64-bits systems
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: Debian Jessie 64-bits
PHP Version:5.5Git-2013-06-08 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64977.patch
Revision: 1370774035
URL:
https://bugs.php.net/patch-display.php?bug=64997&patch=bug64977.patch&revision=1370774035
Previous Comments:
[2013-06-08 23:22:17] cyrille dot faucheux+php at gmail dot com
Description:
I was playing with the Respect data validation library from [1], which makes
use of Recursive*Iterator to retrieve validation errors.
On my 64-bits Debian Jessie, retrieving the errors with the getFullMessage()
function causes a segfault. On a 32-bits one, everything works as expected. May
be related to bug #48206.
This bug is reproducible with the versions 5.4.4-15 (packaged by Debian) and
the 5.5Git from today (bccacb6).
How to reproduce:
- Clone from [1].
- Place the attached script at the root of the checkout.
- Run # php demo.php
[1]: https://github.com/Respect/Validation
Test script:
---
length(1,32))
->key('birthdate', v::date('Y-m-d')->minimumAge(18)->setName('age'));
try {
$userValidator->assert(array('name' => 'bob', 'birthdate' => "1996-07-18"));
} catch (\InvalidArgumentException $e) {
var_dump($e->getFullMessage());
}
Expected result:
Should display:
string(73) "\-These rules must pass for "Array"
\-The age must be 18 years or more."
Actual result:
--
#0 0x006f84d0 in gc_remove_from_buffer (root=0x5dfcbc
) at
/root/Dev/php/v5.5/Zend/zend_gc.h:189
#1 gc_remove_zval_from_buffer (zv=zv@entry=0x7fffce7c89f0) at
/root/Dev/php/v5.5/Zend/zend_gc.c:265
#2 0x006c9948 in i_zval_ptr_dtor (zval_ptr=0x7fffce7c89f0) at
/root/Dev/php/v5.5/Zend/zend_execute.h:80
#3 _zval_ptr_dtor (zval_ptr=) at
/root/Dev/php/v5.5/Zend/zend_execute_API.c:426
#4 0x006cb55d in zend_call_function (fci=fci@entry=0x7fffce7c8820,
fci_cache=0x7ffd74ba0960, fci_cache@entry=0x7fffce7c87f0)
at /root/Dev/php/v5.5/Zend/zend_execute_API.c:999
#5 0x006f0bf5 in zend_call_method
(object_pp=object_pp@entry=0x7fffce7c88d8, obj_ce=,
obj_ce@entry=0x7ffd766757c8,
fn_proxy=fn_proxy@entry=0x7ffd76675930,
function_name=function_name@entry=0xb7ff4f "__tostring",
function_name_len=function_name_len@entry=10,
retval_ptr_ptr=retval_ptr_ptr@entry=0x7fffce7c88e8,
param_count=param_count@entry=0, arg1=arg1@entry=0x0, arg2=arg2@entry=0x0)
at /root/Dev/php/v5.5/Zend/zend_interfaces.c:97
#6 0x006fcab4 in zend_std_cast_object_tostring
(readobj=0x7fffce7c89f0, writeobj=0x7fffce7c8930, type=)
at /root/Dev/php/v5.5/Zend/zend_object_handlers.c:1537
#7 0x006d0810 in _convert_to_string (op=op@entry=0x7fffce7c89f0) at
/root/Dev/php/v5.5/Zend/zend_operators.c:643
#8 0x005e31c8 in spl_recursive_tree_iterator_get_entry
(return_value=return_value@entry=0x7fffce7c89f0, object=0x7ffd74bb6c20,
object=0x7ffd74bb6c20)
at /root/Dev/php/v5.5/ext/spl/spl_iterators.c:1021
#9 0x005e3326 in zim_spl_RecursiveTreeIterator_current (ht=0,
return_value=0x7ffd74bb5dd0, return_value_ptr=,
this_ptr=,
return_value_used=) at
/root/Dev/php/v5.5/ext/spl/spl_iterators.c:1123
#10 0x006cb868 in zend_call_function (fci=fci@entry=0x7fffce7c8c10,
fci_cache=fci_cache@entry=0x7fffce7c8be0) at
/root/Dev/php/v5.5/Zend/zend_execute_API.c:957
#11 0x006f0bf5 in zend_call_method
(object_pp=object_pp@entry=0x7fffce7c8cc8, obj_ce=,
fn_proxy=0x2587488,
function_name=function_name@entry=0x7945d6 "current",
function_name_len=function_name_len@entry=7,
retval_ptr_ptr=retval_ptr_ptr@entry=0x7ffd74bb5aa8,
param_count=param_count@entry=0, arg1=arg1@entry=0x0, arg2=arg2@entry=0x0)
at /root/Dev/php/v5.5/Zend/zend_interfaces.c:97
#12 0x006f126e in zend_user_it_get_current_data (_iter=0x7ffd74bb5a88,
data=0x7fffce7c8d00) at /root/Dev/php/v5.5/Zend/zend_interfaces.c:181
#13 0x00725ebc in ZEND_FE_FETCH_SPEC_VAR_HANDLER
(execute_data=0x7ffd7668b578) at /root/Dev/php/v5.5/Zend/zend_vm_execute.h:13640
#14 0x00747de8 in execute_ex (execute_data=0x7ffd7668b578) at
/root/Dev/php/v5.5/Zend/zend_vm_execute.h:356
#15 0x006dae19 in zend_execute_scripts (type=type@entry=8,
retval=retval@entry=0x0, file_count=file_count@entry=3) at
/
Bug #64987 [PATCH]: unexpected result for call_user_func() in the debug_backtrace()
Edit report at https://bugs.php.net/bug.php?id=64987&edit=1
ID: 64987
Patch added by: larue...@php.net
Reported by:tyr...@php.net
Summary:unexpected result for call_user_func() in the
debug_backtrace()
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: irrelevant
PHP Version:5.3.26
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: add_call_proxy_flag.patch
Revision: 1370768408
URL:
https://bugs.php.net/patch-display.php?bug=64987&patch=add_call_proxy_flag.patch&revision=1370768408
Previous Comments:
[2013-06-07 17:15:45] larue...@php.net
hmm, I may find a solution, use tricky ZEND_CALL_VIA_HANDLER fn_flags, for
call_user_func, may like:
$ git diff
diff --git a/ext/standard/basic_functions.c b/ext/standard/basic_functions.c
index 9c91404..03f836e 100644
--- a/ext/standard/basic_functions.c
+++ b/ext/standard/basic_functions.c
@@ -2983,7 +2983,7 @@ const zend_function_entry basic_functions[] = { /* {{{ */
PHP_FE(error_log,
arginfo_error_log)
PHP_FE(error_get_last,
arginfo_error_get_last)
- PHP_FE(call_user_func,
arginfo_call_user_func)
+ ZEND_FENTRY(call_user_func, ZEND_FN(call_user_func),
arginfo_call_user_func, ZEND_ACC_CALL_VIA_HANDLER|ZEND_ACC_
PUBLIC)
PHP_FE(call_user_func_array,
arginfo_call_user_func_array)
PHP_DEP_FE(call_user_method,
arginfo_call_user_method)
PHP_DEP_FE(call_user_method_array,
arginfo_call_user_method_array)
[2013-06-07 17:08:16] larue...@php.net
I understood your point, I just don't know how to fix other related functions
once.
call_user_func, call_method, reflectionmethod->invoke,
reflectionFunction->invoke
etc.
[2013-06-07 14:05:34] tyr...@php.net
from the userland developer POV (=debug_backtrace() target audience) the foo
call
happens in the call_user_func line.
generating bogus entry because we unintentionally leak implementation details
to
the userland is a bad thing imo.
I agree that the fixing this via allowing all zend functions to fetch the info
from the previous frame would be a bad thing, but it wasn't my intention to
suggest that.
[2013-06-07 12:43:36] ni...@php.net
> When discussing this with Nikita on irc he said that we shouldn't have
> two entry in the result in the first place for call_user_func, but I think
> that removing one entry would have bigger impact on userland (there is a
> chance that some people already remove the entry manually and this change
> would make it remove o valid entry) compared to the change to fill out the
> information that was ommited before.
Misunderstanding ^^ I think having two entries is right (after all, both
functions *are* called, so they should both be in the trace). But I don't think
that the foo() call should copy the file&line info from the call_user_func()
call. It's a) redundant and b) inadequate, as the foo() call does *not* happen
in that line, but rather somewhere in the internals of call_user_func.
Now, for call_user_func in particular that distinction might be a bit fuzzy, as
call_user_func($foo) is roughly equivalent to $foo(), but what you say here
applies to all cases where a userland function is invoked from internal code.
If you just copied the file&line from the previous frame in those cases, then
they would point to some line that most likely does not even contain a
reference to the function (it just happens to be called from there, but can be
registered somewhere else).
Anyway, I don't really care much if it behaves one way or the other, but I do
think that the current behavior is the right one.
[2013-06-07 11:25:56] tyr...@php.net
it seems that the xdebug debug backtrace works the same way as it was proposed
here:
Call Stack:
0.0016 639496 1. {main}() test.php:0
0.0026 639624 2. call_user_func() test.php:9
0.0026 639624 3. foo() test.php:9
0.0026 639624 4. bar() test.php:3
0.0026 639800 5. trigger_error() test.php:7
notice that it lists both the call_user_func() and the foo() call, both of the
pointing to the same file:line
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/b
Bug #64966 [PATCH]: segfault in zend_do_fcall_common_helper_SPEC
Edit report at https://bugs.php.net/bug.php?id=64966&edit=1
ID: 64966
Patch added by: larue...@php.net
Reported by:bfra...@php.net
Summary:segfault in zend_do_fcall_common_helper_SPEC
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:Irrelevant
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64966.phpt
Revision: 1370683159
URL:
https://bugs.php.net/patch-display.php?bug=64966&patch=bug64966.phpt&revision=1370683159
Previous Comments:
[2013-06-08 09:19:01] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64966.patch
Revision: 1370683141
URL:
https://bugs.php.net/patch-display.php?bug=64966&patch=bug64966.patch&revision=1370683141
[2013-06-08 09:15:03] larue...@php.net
change summary, since not reflection specific bug
[2013-06-08 08:39:25] larue...@php.net
here is a small reproduce script, if no segfault, run with valgrind:
b();
[2013-06-08 06:37:10] larue...@php.net
A more simple fix might be like:
diff --git a/Zend/zend_vm_def.h b/Zend/zend_vm_def.h
index 02566f3..d471f39 100644
--- a/Zend/zend_vm_def.h
+++ b/Zend/zend_vm_def.h
@@ -2327,6 +2327,8 @@ ZEND_VM_HELPER(zend_do_fcall_common_helper, ANY, ANY)
if (!RETURN_VALUE_USED(opline)) {
zval_ptr_dtor(&EX_T(opline-
>result.u.var).var.ptr);
}
+ } else if (RETURN_VALUE_USED(opline)) {
+ EX_T(opline->result.u.var).var.ptr = NULL;
}
} else if (EX(function_state).function->type == ZEND_USER_FUNCTION) {
EX(original_return_value) = EG(return_value_ptr_ptr);
[2013-06-07 20:04:43] bfra...@php.net
I just added a patch that make 5.3.24+ not core dump, but I want somebody to
review it.
http://git.php.net/?p=php-src.git;a=blob;f=Zend/zend_vm_execute.h;h=f6220b0f5305924afd7f480f321cae8075b46ab2;hb=refs/heads/PHP-5.3#l303
The issue is allocate for EX_T(opline->result.u.var).var.ptr was moved to line
316 and inside the:
if (EXPECTED(EG(exception) == NULL)) {
}
block. The problem with this is that on line 417, it calls:
zval_ptr_dtor(&EX_T(opline->result.u.var).var.ptr);
but without allocating it.
May be the other option would be to add a else option at line 330 to either
null the value or set:
RETURN_VALUE_USED(opline)
to false instead of true (no idea how to do that), which it currently is.
Thoughts?
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=64966
--
Edit this bug report at https://bugs.php.net/bug.php?id=64966&edit=1
Bug #64966 [PATCH]: segfault in zend_do_fcall_common_helper_SPEC
Edit report at https://bugs.php.net/bug.php?id=64966&edit=1
ID: 64966
Patch added by: larue...@php.net
Reported by:bfra...@php.net
Summary:segfault in zend_do_fcall_common_helper_SPEC
Status: Assigned
Type: Bug
Package:Scripting Engine problem
PHP Version:Irrelevant
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64966.patch
Revision: 1370683141
URL:
https://bugs.php.net/patch-display.php?bug=64966&patch=bug64966.patch&revision=1370683141
Previous Comments:
[2013-06-08 09:15:03] larue...@php.net
change summary, since not reflection specific bug
[2013-06-08 08:39:25] larue...@php.net
here is a small reproduce script, if no segfault, run with valgrind:
b();
[2013-06-08 06:37:10] larue...@php.net
A more simple fix might be like:
diff --git a/Zend/zend_vm_def.h b/Zend/zend_vm_def.h
index 02566f3..d471f39 100644
--- a/Zend/zend_vm_def.h
+++ b/Zend/zend_vm_def.h
@@ -2327,6 +2327,8 @@ ZEND_VM_HELPER(zend_do_fcall_common_helper, ANY, ANY)
if (!RETURN_VALUE_USED(opline)) {
zval_ptr_dtor(&EX_T(opline-
>result.u.var).var.ptr);
}
+ } else if (RETURN_VALUE_USED(opline)) {
+ EX_T(opline->result.u.var).var.ptr = NULL;
}
} else if (EX(function_state).function->type == ZEND_USER_FUNCTION) {
EX(original_return_value) = EG(return_value_ptr_ptr);
[2013-06-07 20:04:43] bfra...@php.net
I just added a patch that make 5.3.24+ not core dump, but I want somebody to
review it.
http://git.php.net/?p=php-src.git;a=blob;f=Zend/zend_vm_execute.h;h=f6220b0f5305924afd7f480f321cae8075b46ab2;hb=refs/heads/PHP-5.3#l303
The issue is allocate for EX_T(opline->result.u.var).var.ptr was moved to line
316 and inside the:
if (EXPECTED(EG(exception) == NULL)) {
}
block. The problem with this is that on line 417, it calls:
zval_ptr_dtor(&EX_T(opline->result.u.var).var.ptr);
but without allocating it.
May be the other option would be to add a else option at line 330 to either
null the value or set:
RETURN_VALUE_USED(opline)
to false instead of true (no idea how to do that), which it currently is.
Thoughts?
[2013-06-07 19:53:45] bfra...@php.net
The following patch has been added/updated:
Patch Name: exception.diff
Revision: 1370634825
URL:
https://bugs.php.net/patch-display.php?bug=64966&patch=exception.diff&revision=1370634825
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=64966
--
Edit this bug report at https://bugs.php.net/bug.php?id=64966&edit=1
Req #64782 [PATCH]: SplFileObject constructor make $context optional / give it a default value
Edit report at https://bugs.php.net/bug.php?id=64782&edit=1
ID: 64782
Patch added by: larue...@php.net
Reported by:hanskrentel at yahoo dot de
Summary:SplFileObject constructor make $context optional /
give it a default value
Status: Open
Type: Feature/Change Request
Package:SPL related
PHP Version:5.4.14
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: accept_null_for_context.patch
Revision: 1368069103
URL:
https://bugs.php.net/patch-display.php?bug=64782&patch=accept_null_for_context.patch&revision=1368069103
Previous Comments:
[2013-05-09 03:10:59] larue...@php.net
all I got is:
PHP Fatal error: Uncaught exception 'RuntimeException' with message
'SplFileObject::__construct() expects parameter 4 to be resource, null given'
in
/tmp/1.php:6
Stack trace:
#0 /tmp/1.php(6): SplFileObject->__construct('/tmp/1.php', 'r', false, NULL)
#1 /tmp/1.php(10): Myfile->__construct('/tmp/1.php')
#2 {main}
thrown in /tmp/1.php on line 6
it you meant this err, yes, this could be improved. I will attach a patch
[2013-05-07 10:02:57] hanskrentel at yahoo dot de
Correction: The line "$this->levels = new Levels();" in the test-script above
needs to be removed.
Addendum: The following variant shows the boilerplate code this needs to get
away with the error:
levels = new Levels();
parent::__construct($file_name, $open_mode, $use_include_path,
$context);
}
}
$file = new MyFile(__FILE__);
Expected result:
It should not give any warning or error.
Actual result:
--
Warning: Missing argument 4 for Myfile::__construct(), called in [pointing to
the
line "$file = new MyFile(__FILE__);"] and defined in [pointing to the line
"public function __construct($file_name, $open_mode = "r", $use_include_path =
FALSE, $context = NULL) {"]
--
Edit this bug report at https://bugs.php.net/bug.php?id=64782&edit=1
Req #64730 [PATCH]: preg_replace_callback vs. preg_replace eval related
Edit report at https://bugs.php.net/bug.php?id=64730&edit=1
ID: 64730
Patch added by: larue...@php.net
Reported by:imbolk at gmail dot com
Summary:preg_replace_callback vs. preg_replace eval related
Status: Assigned
Type: Feature/Change Request
Package:Regexps related
Operating System: Mac OS X 10.8.3
PHP Version:5.5.0beta4
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: second_arg_rege_key.patch
Revision: 1367670928
URL:
https://bugs.php.net/patch-display.php?bug=64730&patch=second_arg_rege_key.patch&revision=1367670928
Previous Comments:
[2013-05-01 02:08:19] imbolk at gmail dot com
Yes, you are quite right.
[2013-04-30 21:09:35] ww dot galen at gmail dot com
Accepting an array of callbacks can lead to unreconcilable ambiguities. For
example:
class A {
function __toString() { ... }
function __invoke($a) { ... }
function foo($a) { ... }
}
function foo($a) { ... }
$a = new A;
preg_replace_callback([..., ...], [$a, 'foo'], $subject);
There are three different ways of interpreting the callback argument, all
equally valid:
1. `(string)$a` and `foo(...)`
2. `$a(...)` and `foo(...)`
3. `$a->foo(...)`
[2013-04-29 18:03:49] imbolk at gmail dot com
I think it would be better if prey_replace_callback function will accept array
of
callbacks as a 2nd argument.
----
[2013-04-29 16:49:45] larue...@php.net
a simple patch attached, please also see my proposal:
http://news.php.net/php.internals/67199
[2013-04-29 16:31:42] imbolk at gmail dot com
Oops⦠sorry. My mistake. Test script is:
$repl = [
'/(\d{2}|(? function($m) { return
$this->_op($m[3], $m[4], rtrim($this->_op($m[1], $m[2]), ";"))'; },
'/(\d{2}|)([MPmplrc])/e' => function ($m) { return
$this->_op($m[1],
$m[2]); },
];
$str = preg_replace_callback(array_keys($repl), array_values($repl), $str);
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=64730
--
Edit this bug report at https://bugs.php.net/bug.php?id=64730&edit=1
Req #64730 [PATCH]: preg_replace_callback vs. preg_replace eval related
Edit report at https://bugs.php.net/bug.php?id=64730&edit=1
ID: 64730
Patch added by: larue...@php.net
Reported by:imbolk at gmail dot com
Summary:preg_replace_callback vs. preg_replace eval related
Status: Open
Type: Feature/Change Request
Package:Regexps related
Operating System: Mac OS X 10.8.3
PHP Version:5.5.0beta4
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: sencode_argument.patch
Revision: 1367253036
URL:
https://bugs.php.net/patch-display.php?bug=64730&patch=sencode_argument.patch&revision=1367253036
Previous Comments:
[2013-04-29 15:52:38] larue...@php.net
or, add a third argument to callback, which is the "regex self" or the regex
index?
[2013-04-28 17:35:06] imbolk at gmail dot com
Description:
In PHP 5.5 'e' key preg_replace is deprecated:
https://wiki.php.net/rfc/remove_preg_replace_eval_modifier
But I don't know how to replace evaled preg_replace with preg_replace_callback
in
some case.
For example:
$repl = [
'/(\d{2}|(? '$this->_op("$3",
"$4",
rtrim($this->_op("$1", "$2"), ";"))',
'/(\d{2}|)([MPmplrc])/e' => '$this->_op("$1", "$2")',
];
$str = preg_replace(array_keys($repl), array_values($repl), $str);
Test script:
---
$repl = [
'/(\d{2}|(? function($m) { return
$this->_op($m[3], $m[4], rtrim($this->_op($m[1], $m[2]), ";"))'; },
'/(\d{2}|)([MPmplrc])/e' => function ($m) { return
$this->_op($m[1], $m[2]); },
];
$str = preg_replace(array_keys($repl), array_values($repl), $str);
Expected result:
It works.
Actual result:
--
Warning: preg_replace_callback(): Requires argument 2, 'Array', to be a valid
callback in my.php on line 359
--
Edit this bug report at https://bugs.php.net/bug.php?id=64730&edit=1
Bug #64677 [PATCH]: execution operator `` stealing surrounding arguments
Edit report at https://bugs.php.net/bug.php?id=64677&edit=1
ID: 64677
Patch added by: larue...@php.net
Reported by:knivey at botops dot net
Summary:execution operator `` stealing surrounding arguments
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Ubuntu 12.04LTS
PHP Version:5.5.0beta3
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64677.diff
Revision: 1366441202
URL:
https://bugs.php.net/patch-display.php?bug=64677&patch=bug64677.diff&revision=1366441202
Previous Comments:
[2013-04-20 04:41:18] knivey at botops dot net
Description:
When used the execution operator ` as an argument passed to a class method, you
will end up with a seg fault or invalid args to shell_exec error
Test script:
---
show_output('Files: ', trim(`ls`)); // this gives invalid args to
shell_exec
$cat->show_output('Files: ', `ls`); // this causes a segmentation fault
$cat->show_out(`ls`); // this causes a segmentation fault
function show_outputa($prepend, $output) {echo $prepend . $output;}
show_outputa('Files: ', `ls`); // this works as expected
--
Edit this bug report at https://bugs.php.net/bug.php?id=64677&edit=1
Bug #64346 [PATCH]: Function name resolution and eval
Edit report at https://bugs.php.net/bug.php?id=64346&edit=1 ID: 64346 Patch added by: larue...@php.net Reported by:gen dot work at gmail dot com Summary:Function name resolution and eval Status: Assigned Type: Bug Package:*General Issues Operating System: Ubuntu 12.10 PHP Version:5.4.12 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64346-2.diff Revision: 1365749451 URL: https://bugs.php.net/patch-display.php?bug=64346&patch=bug64346-2.diff&revision=1365749451 Previous Comments: [2013-03-04 15:59:54] dmi...@php.net I suppose the bug has to be fixed. The problem that the fix will slowdown each call to unqualified function from a namespace :( I'm not sure if we like to do it... [2013-03-04 14:53:34] gen dot work at gmail dot com '\Foo\bar' -> '\Foo\time' in my prev comment [2013-03-04 14:50:18] gen dot work at gmail dot com The main issue I see is that is_callabe() is lying. It says that '\Foo\bar' is callable, but in fact it's not. So just document this behavior is not enough imo, is_callabe should be tweaked to reflect actual status. And I don't quite understand suggested workaraund. Could you please give a simple example? In my usecase I try to mock time function to avoid sleep() calls: https://github.com/rybakit/phive-queue/blob/master/tests/Phive/Tests/Queue/AbstractQueueTest.php#L59 https://github.com/rybakit/phive-queue/blob/master/src/Phive/Queue/InMemoryQueue.php#L40 -------- [2013-03-04 13:50:20] larue...@php.net @gen the main brief is, when you first call to \Foo\Bar, the 'time' constant in the \Foo\Bar function, will bundle to "time function", in the first time , it obviously will be bundled to \time. then when you sencond call to it. PHP will use that cache instead of look up in function table again for "time" function, to increase performance.. so, if we disable the cache, then performance slowdown... what do you think? a workaround is define a Foo\Bar2, after you eval, you call to it, then it will bundled to \Foo\Time.. -------- [2013-03-04 13:43:29] larue...@php.net or maybe we should document this behavior, since disable it will bring performance issue The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=64346 -- Edit this bug report at https://bugs.php.net/bug.php?id=64346&edit=1
Bug #64592 [PATCH]: ReflectionClass::getMethods() returns methods out of scope
Edit report at https://bugs.php.net/bug.php?id=64592&edit=1
ID: 64592
Patch added by: larue...@php.net
Reported by:benjamin dot morel at gmail dot com
Summary:ReflectionClass::getMethods() returns methods out of
scope
Status: Open
Type: Bug
Package:Reflection related
Operating System: Linux
PHP Version:5.4.13
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64592.patch
Revision: 1365254381
URL:
https://bugs.php.net/patch-display.php?bug=64592&patch=bug64592.patch&revision=1365254381
Previous Comments:
[2013-04-06 11:54:57] benjamin dot morel at gmail dot com
But at least, getMethods() and getProperties() should behave in the same way,
shouldn't they?
[2013-04-06 02:08:02] larue...@php.net
for php, even the private inherited function is not "visible", but it exists in
the child function table.
[2013-04-05 16:14:30] benjamin dot morel at gmail dot com
Description:
As far as I understand it, ReflectionClass::getMethods() should return only the
methods that are in the scope of the reflected class, thus excluding private
methods from parent classes.
That's moreover the behaviour exposed by ReflectionClass::getProperties(),
making
the two methods behave in different manners.
Test script:
---
class Foo {
private $a;
private function a() {}
protected $b;
protected function b() {}
}
class Bar extends Foo {
private $c;
private function c() {}
}
$r = new ReflectionClass('Bar');
echo 'Properties in scope: ';
foreach ($r->getProperties() as $property) {
echo $property->getName() . ' ';
}
echo PHP_EOL, 'Methods in scope: ';
foreach ($r->getMethods() as $method) {
echo $method->getName() . ' ';
}
Expected result:
Properties in scope: c b
Methods in scope: c b
Actual result:
--
Properties in scope: c b
Methods in scope: c a b
--
Edit this bug report at https://bugs.php.net/bug.php?id=64592&edit=1
Bug #64578 [PATCH]: debug_backtrace in set_error_handler corrupts zend heap: segfault
Edit report at https://bugs.php.net/bug.php?id=64578&edit=1 ID: 64578 Patch added by: larue...@php.net Reported by:emiel dot mols at gmail dot com Summary:debug_backtrace in set_error_handler corrupts zend heap: segfault Status: Verified Type: Bug Package:Reproducible crash Operating System: Irrelevant PHP Version:5.5Git-2013-04-03 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64578.patch Revision: 1365053756 URL: https://bugs.php.net/patch-display.php?bug=64578&patch=bug64578.patch&revision=1365053756 Previous Comments: [2013-04-04 03:03:02] larue...@php.net confirmed, I can reproduce this. looking into it now.. [2013-04-03 19:44:37] emiel dot mols at gmail dot com Description: So I thought the other day it might be convenient to grab a stack trace in, you know, the place errors are handled. Apparently, PHP thinks this is a terrible idea. The exact cause is unclear, but I've managed to create a decently small test case that segfaults both on Debian PHP 5.4.4 and Darwin PHP 5.5 nightly. In the attached test script, the call to x() should generate an error, because accessing a string as associative array is forbidden. - the segfault occurs in native _zend_mm_free_int - only able to replicate when there's a function call on the PHP stack - it appears debug_backtrace is only corrupting the stack -- the call to print_r() initiates the segfault. - i've seen $y change every access (eg containing random other variables, or just random heap garbage). - in narrowing down the specific case, I've also often seen messages along the lines of "mm stack corrupt" Core dumps can be found at: - Debian: http://db.tt/aA5wAx7a (16MB) - Darwin: http://db.tt/gxZrP8Pa (400MB) Test script: --- https://bugs.php.net/bug.php?id=64578&edit=1
Bug #64544 [PATCH]: Valgrind warnings after using putenv (due to processtitle)
Edit report at https://bugs.php.net/bug.php?id=64544&edit=1 ID: 64544 Patch added by: larue...@php.net Reported by:ni...@php.net Summary:Valgrind warnings after using putenv (due to processtitle) Status: Open Type: Bug Package:CGI/CLI related PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64544.patch Revision: 1364529144 URL: https://bugs.php.net/patch-display.php?bug=64544&patch=bug64544.patch&revision=1364529144 Previous Comments: [2013-03-29 03:11:48] larue...@php.net The following patch has been added/updated: Patch Name: bug64544.patch Revision: 1364526708 URL: https://bugs.php.net/patch-display.php?bug=64544&patch=bug64544.patch&revision=1364526708 [2013-03-28 17:07:41] ni...@php.net Description: Due to the changes introduced by https://wiki.php.net/rfc/cli_process_title running https://bugs.php.net/bug.php?id=64544&edit=1
Bug #64544 [PATCH]: Valgrind warnings after using putenv (due to processtitle)
Edit report at https://bugs.php.net/bug.php?id=64544&edit=1 ID: 64544 Patch added by: larue...@php.net Reported by:ni...@php.net Summary:Valgrind warnings after using putenv (due to processtitle) Status: Open Type: Bug Package:CGI/CLI related PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64544.patch Revision: 1364526708 URL: https://bugs.php.net/patch-display.php?bug=64544&patch=bug64544.patch&revision=1364526708 Previous Comments: [2013-03-28 17:07:41] ni...@php.net Description: Due to the changes introduced by https://wiki.php.net/rfc/cli_process_title running https://bugs.php.net/bug.php?id=64544&edit=1
Bug #64515 [PATCH]: Memoryleak when using the same variablename 2times in function declaration
Edit report at https://bugs.php.net/bug.php?id=64515&edit=1 ID: 64515 Patch added by: larue...@php.net Reported by:hannes dot magnusson at gmail dot com Summary:Memoryleak when using the same variablename 2times in function declaration Status: Open Type: Bug Package:Scripting Engine problem Operating System: MacOSX PHP Version:5.4Git-2013-03-25 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64515.patch Revision: 1364267611 URL: https://bugs.php.net/patch-display.php?bug=64515&patch=bug64515.patch&revision=1364267611 Previous Comments: [2013-03-25 20:46:37] hannes dot magnusson at gmail dot com Description: There is a memory leak when the same argument name is used 2 times in a function declaration. Test script: --- https://bugs.php.net/bug.php?id=64515&edit=1
Bug #64503 [PATCH]: Compilation fails with error: conflicting types for 'zendparse'
Edit report at https://bugs.php.net/bug.php?id=64503&edit=1 ID: 64503 Patch added by: larue...@php.net Reported by:stormbyte at gmail dot com Summary:Compilation fails with error: conflicting types for 'zendparse' Status: Open Type: Bug Package:Compile Failure Operating System: Gentoo PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: 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 Previous Comments: [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/work/sapis- build/cli/ext/tokenizer/tokenizer.c:25: /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[20491] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1- r2/work/sapis-build/cli/ext/tokenizer/tokenizer.c on localhost failed make: *** [ext/tokenizer/tokenizer.lo] Error 1 Test script: --- In my case, just emerge php OR try to compile it Expected result: Compilation successful Actual result: -- Compile error -- Edit this bug report at https://bugs.php.net/bug.php?id=64503&edit=1
Bug #64503 [PATCH]: Compilation fails with error: conflicting types for 'zendparse'
Edit report at https://bugs.php.net/bug.php?id=64503&edit=1 ID: 64503 Patch added by: larue...@php.net Reported by:stormbyte at gmail dot com Summary:Compilation fails with error: conflicting types for 'zendparse' Status: Open Type: Bug Package:Compile Failure Operating System: Gentoo PHP Version:5.5.0beta1 Block user comment: N Private report: N New Comment: 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 Previous Comments: [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/work/sapis- build/cli/ext/tokenizer/tokenizer.c:25: /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[20491] ERROR: compile /var/tmp/portage/dev-lang/php-5.5.0_beta1- r2/work/sapis-build/cli/ext/tokenizer/tokenizer.c on localhost failed make: *** [ext/tokenizer/tokenizer.lo] Error 1 Test script: --- In my case, just emerge php OR try to compile it Expected result: Compilation successful Actual result: -- Compile error -- Edit this bug report at https://bugs.php.net/bug.php?id=64503&edit=1
Bug #64239 [Com]: Debug backtrace changed behavior since 5.4.10 or 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64239&edit=1 ID: 64239 Comment by: larue...@php.net Reported by:kusmierz at o2 dot pl Summary:Debug backtrace changed behavior since 5.4.10 or 5.4.11 Status: Assigned Type: Bug Package:*General Issues Operating System: Ubuntu,Debian,Windows PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: new patch attached, which fixed that issue you mentioned Previous Comments: [2013-03-21 08:18:28] larue...@php.net The following patch has been added/updated: Patch Name: bug64329.patch Revision: 1363853908 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64329.patch&revision=1363853908 [2013-03-21 08:01:08] dmi...@php.net I've added another patch (bug64239-2.patch), but it's incorrect anyway :( Test script: --- t2method(); $b->Bmethod(); Expected result: #0 B->t2method() called at [test.php:14] #0 B->Bmethod() called at [test.php:15] Actual result: -- #0 B->Bmethod() called at [test.php:14] #0 B->Bmethod() called at [test.php:15] ---- [2013-03-21 06:04:32] larue...@php.net The following patch has been added/updated: Patch Name: bug64239.patch Revision: 1363845872 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64239.patch&revision=1363845872 -------- [2013-03-20 07:00:33] larue...@php.net an idea is search the function in ce->function table to get the lowercase alias name, then search in ce->traits_aliases for the origin function name, patch will be attached, but it will definitely slowdown the debug_backtrace. [2013-02-19 10:05:27] dmi...@php.net Personally, I would remove traits at all :( Of course, it's not a case, but we hardly ever going to introduce new trait related magic in 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=64239 -- Edit this bug report at https://bugs.php.net/bug.php?id=64239&edit=1
Bug #64239 [PATCH]: Debug backtrace changed behavior since 5.4.10 or 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64239&edit=1 ID: 64239 Patch added by: larue...@php.net Reported by:kusmierz at o2 dot pl Summary:Debug backtrace changed behavior since 5.4.10 or 5.4.11 Status: Assigned Type: Bug Package:*General Issues Operating System: Ubuntu,Debian,Windows PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64329.patch Revision: 1363853908 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64329.patch&revision=1363853908 Previous Comments: [2013-03-21 08:01:08] dmi...@php.net I've added another patch (bug64239-2.patch), but it's incorrect anyway :( Test script: --- t2method(); $b->Bmethod(); Expected result: #0 B->t2method() called at [test.php:14] #0 B->Bmethod() called at [test.php:15] Actual result: -- #0 B->Bmethod() called at [test.php:14] #0 B->Bmethod() called at [test.php:15] ---- [2013-03-21 06:04:32] larue...@php.net The following patch has been added/updated: Patch Name: bug64239.patch Revision: 1363845872 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64239.patch&revision=1363845872 -------- [2013-03-20 07:00:33] larue...@php.net an idea is search the function in ce->function table to get the lowercase alias name, then search in ce->traits_aliases for the origin function name, patch will be attached, but it will definitely slowdown the debug_backtrace. [2013-02-19 10:05:27] dmi...@php.net Personally, I would remove traits at all :( Of course, it's not a case, but we hardly ever going to introduce new trait related magic in 5.4.* [2013-02-19 09:04:02] kusmierz at o2 dot pl Or please add magic constant, ie. __ALIASSED_METHOD__ or something (#61033)... The backtrace code is just workaround for me in this case. 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=64239 -- Edit this bug report at https://bugs.php.net/bug.php?id=64239&edit=1
Bug #64239 [PATCH]: Debug backtrace changed behavior since 5.4.10 or 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64239&edit=1 ID: 64239 Patch added by: larue...@php.net Reported by:kusmierz at o2 dot pl Summary:Debug backtrace changed behavior since 5.4.10 or 5.4.11 Status: Assigned Type: Bug Package:*General Issues Operating System: Ubuntu,Debian,Windows PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64239.patch Revision: 1363845872 URL: https://bugs.php.net/patch-display.php?bug=64239&patch=bug64239.patch&revision=1363845872 Previous Comments: [2013-03-20 07:00:33] larue...@php.net an idea is search the function in ce->function table to get the lowercase alias name, then search in ce->traits_aliases for the origin function name, patch will be attached, but it will definitely slowdown the debug_backtrace. [2013-02-19 10:05:27] dmi...@php.net Personally, I would remove traits at all :( Of course, it's not a case, but we hardly ever going to introduce new trait related magic in 5.4.* [2013-02-19 09:04:02] kusmierz at o2 dot pl Or please add magic constant, ie. __ALIASSED_METHOD__ or something (#61033)... The backtrace code is just workaround for me in this case. [2013-02-19 08:43:01] larue...@php.net yes, that alias name gave us too many pains :)... add a new alias_name is a easy and clear way. thanks [2013-02-19 07:11:45] dmi...@php.net Laruence, you are right. Reflection, debug_backtrace() and get_class_methods() are affected. It would be good to fix it, however, I don't see a good way to do it, and I don't like to introduce a new hack. (e.g. resolving alias name by looking into hash table key). Actually we have the same situation with class aliases. In general, we can fix it in 5.5 using some inefficient way (e.g. add op_array->alias_function_name) Any ideas are welcome. 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=64239 -- Edit this bug report at https://bugs.php.net/bug.php?id=64239&edit=1
Bug #64432 [Com]: more empty delimiter warning in strX methods
Edit report at https://bugs.php.net/bug.php?id=64432&edit=1 ID: 64432 Comment by: larue...@php.net Reported by:ian at trashmail dot ws Summary:more empty delimiter warning in strX methods Status: Open Type: Bug Package:*General Issues PHP Version:Irrelevant Block user comment: N Private report: N New Comment: seems only stristr and strstr need to be fixed. Previous Comments: [2013-03-15 16:27:19] ian at trashmail dot ws Description: stristr produces this 'empty delimiter' warning too. If strpos was fixed, please make sure to fix all other strXXX methods also see #63943 Bad warning text from strpos() on empty needle -- Edit this bug report at https://bugs.php.net/bug.php?id=64432&edit=1
Bug #64354 [PATCH]: Unserialize array of objects whose class can't be autoloaded fail
Edit report at https://bugs.php.net/bug.php?id=64354&edit=1 ID: 64354 Patch added by: larue...@php.net Reported by:alan at klestoff dot ru Summary:Unserialize array of objects whose class can't be autoloaded fail Status: Open Type: Bug Package:Scripting Engine problem Operating System: Debian PHP Version:5.3.22 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64354.patch Revision: 1362470827 URL: https://bugs.php.net/patch-display.php?bug=64354&patch=bug64354.patch&revision=1362470827 Previous Comments: [2013-03-05 08:06:37] larue...@php.net hmm, this is because one serializing triggered more than one exception. quick patch attached. [2013-03-05 07:27:04] alan at klestoff dot ru Description: We have serialized object of class A and array with 2 such objects Then we write autoload function which throws exception if can't find a file with class. And in first case - we have a normal behaviour (we can catch exception). In second we have uncaughted exception. Test script: --- https://bugs.php.net/bug.php?id=64354&edit=1
Bug #64325 [PATCH]: Issue in automatic $_POST array handling
Edit report at https://bugs.php.net/bug.php?id=64325&edit=1
ID: 64325
Patch added by: larue...@php.net
Reported by:php at sygmoral dot com
Summary:Issue in automatic $_POST array handling
Status: Feedback
Type: Bug
Package:Arrays related
Operating System: Debian
PHP Version:5.4.12
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64325.patch
Revision: 1362108583
URL:
https://bugs.php.net/patch-display.php?bug=64325&patch=bug64325.patch&revision=1362108583
Previous Comments:
[2013-03-01 03:29:02] larue...@php.net
PHP won't allow variables name to contains "[", "." etc , so I think this is
really a narrow usage.
but, however I do believe there is a bug.
a patch will be attached. but I need to ask someone else's opinion before
commit
it.
thanks
[2013-02-28 19:45:57] php at sygmoral dot com
Thank you for your reaction!
But no: I did in fact mean what I wrote. I realise it's a strange data
structure, so here's a short explanation for it: the 'save' array holds a
collection of html form elements that are not yet to be submitted, but should
be saved temporarily into some other set of memory, so that upon the next
visit, those temporary values can be easily inserted into the displayed form,
without having been submitted. In other words, it's for a form that remembers
its state throughout visits.
So I send an object containing the name-value pairs in the form, and send that
over POST. In the example used here, this results in one or more name-value
pairs that are saved into the save array, as save['line[]'] = value.
And that is the situation that triggers this bug, as in my original post. I'm
sure there are other ways to achieve what I want, but I figured I'd report it
since this does not look as if it's intended.
Note that the example is a simplification of my application, where multiple
'single' and 'array' values are saved.
[2013-02-28 18:22:57] re...@php.net
"post_data = {'save[line[]]':'A line with text'}â
do you mean post_data = {'save[line][]':'A line with text'} ?
^^
is this you intention?
array(
'save' =>
['line' =>
['A line with text', 'maybe more lines']
]
); ?
[2013-02-28 16:09:49] php at sygmoral dot com
Description:
Php automatically puts POSTed name-value pairs with names ending in [] into
arrays. Very handy feature! However, I notice issues when more of those square
brackets are encountered.
If I send a name like `save[line[]]`, then `save` will be an array and the
first key in it will be `line[`, instead of `line[]`. It's not that I expect a
second level of arrays - just that it doesn't strangely remove that last
bracket.
So suppose we have the tiny php script below, and I send this with e.g. jquery:
post_data = {'save[line[]]':'A line with text'}
Effectively, the raw POST data being sent is:
save%5Bline%5B%5D%5D=A+line+with+text
Test script:
---
print_r(
$_POST['save']
);
Expected result:
POST: Array
(
[line[]] => A line with text
)
Actual result:
--
POST: Array
(
[line[] => A line with text
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=64325&edit=1
[PHP-BUG] Bug #64290 [NEW]: ext/ereg/tests/split_variation_004.phpt failed
From: laruence
Operating system:
PHP version: master-Git-2013-02-24 (Git)
Package: *General Issues
Bug Type: Bug
Bug description:ext/ereg/tests/split_variation_004.phpt failed
Description:
ext/ereg/tests/split_variation_004.phpt failed (centOS 64 bits)
in 5.5 10E20 give the count of zif_split 0
but in master give the count 1864712049423024128
something changed to convert_to_long from 5.5 to master
Test script:
---
diff is:
013+ array(5) {
013- array(1) {
015+ string(1) "1"
016+ [1]=>
017+ string(1) "2"
018+ [2]=>
019+ string(1) "3"
020+ [3]=>
021+ string(1) "4"
022+ [4]=>
023+ string(1) "5"
015- string(9) "1 2 3 4 5"
--
Edit bug report at https://bugs.php.net/bug.php?id=64290&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=64290&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=64290&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=64290&r=trysnapshottrunk
Fixed in SVN: https://bugs.php.net/fix.php?id=64290&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=64290&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=64290&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=64290&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=64290&r=oldversion
Not developer issue:https://bugs.php.net/fix.php?id=64290&r=support
Expected behavior: https://bugs.php.net/fix.php?id=64290&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=64290&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=64290&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=64290&r=globals
PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64290&r=php4
Daylight Savings: https://bugs.php.net/fix.php?id=64290&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=64290&r=isapi
Install GNU Sed:https://bugs.php.net/fix.php?id=64290&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=64290&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=64290&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=64290&r=mysqlcfg
Bug #64264 [PATCH]: SPLFixedArray toArray problem
Edit report at https://bugs.php.net/bug.php?id=64264&edit=1
ID: 64264
Patch added by: larue...@php.net
Reported by:kwreczycki at gmail dot com
Summary:SPLFixedArray toArray problem
Status: Open
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64264.phpt
Revision: 1361621333
URL:
https://bugs.php.net/patch-display.php?bug=64264&patch=bug64264.phpt&revision=1361621333
Previous Comments:
[2013-02-23 12:08:23] larue...@php.net
The following patch has been added/updated:
Patch Name: bug64264.patch
Revision: 1361621303
URL:
https://bugs.php.net/patch-display.php?bug=64264&patch=bug64264.patch&revision=1361621303
[2013-02-21 13:09:41] kwreczycki at gmail dot com
Description:
Be aware if You extends SplFixedArray and use toArray method.
Test script:
---
class MyFixedArray extends \SplFixedArray {
protected $foo;
protected $bar;
}
$myFixedArr = new MyFixedArray(1);
$myFixedArray[] = 'foo';
Expected result:
array(1) {
[0]=>
NULL
}
Actual result:
--
array(3) {
["*foo"]=>
NULL
["*bar"]=>
NULL
[0]=>
NULL
}
*foo and *bar keys, can invoke troubles in some situations if You expects array
without properties from inherited class. Method toArray should return values
only
for elements which are added to collection without properties inherited from
class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64264&edit=1
Bug #64264 [PATCH]: SPLFixedArray toArray problem
Edit report at https://bugs.php.net/bug.php?id=64264&edit=1
ID: 64264
Patch added by: larue...@php.net
Reported by:kwreczycki at gmail dot com
Summary:SPLFixedArray toArray problem
Status: Open
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64264.patch
Revision: 1361621303
URL:
https://bugs.php.net/patch-display.php?bug=64264&patch=bug64264.patch&revision=1361621303
Previous Comments:
[2013-02-21 13:09:41] kwreczycki at gmail dot com
Description:
Be aware if You extends SplFixedArray and use toArray method.
Test script:
---
class MyFixedArray extends \SplFixedArray {
protected $foo;
protected $bar;
}
$myFixedArr = new MyFixedArray(1);
$myFixedArray[] = 'foo';
Expected result:
array(1) {
[0]=>
NULL
}
Actual result:
--
array(3) {
["*foo"]=>
NULL
["*bar"]=>
NULL
[0]=>
NULL
}
*foo and *bar keys, can invoke troubles in some situations if You expects array
without properties from inherited class. Method toArray should return values
only
for elements which are added to collection without properties inherited from
class.
--
Edit this bug report at https://bugs.php.net/bug.php?id=64264&edit=1
Bug #64235 [PATCH]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1
ID: 64235
Patch added by: larue...@php.net
Reported by:imenem at inox dot ru
Summary:Insteadof not work for class method in 5.4.11
Status: Feedback
Type: Bug
Package:Scripting Engine problem
Operating System: Debian GNU/Linux
PHP Version:5.4.11
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: deny_use_with_classes.patch
Revision: 1361437796
URL:
https://bugs.php.net/patch-display.php?bug=64235&patch=deny_use_with_classes.patch&revision=1361437796
Previous Comments:
[2013-02-20 19:33:35] dmi...@php.net
I agree with Stefan.
I think we have to allow only trait names in context of "as" and "insteadof"
statements. Stefan showed a simple workarounds for class names.
I don't think we should fix the behavior we had in early 5.4 versions by
mistake.
[2013-02-20 16:22:55] re...@php.net
currently using class in context of trait 'as' and 'inteadof'
didn't work most of the time (as the code below demonstrated, even after apply
the patch
larucence attached). Only the use case of this bug report, it HAPPENED to work.
To keep the BC of the problem reported, as I suggested in the previous patch we
could
mark it as deprecated in 5.4.
So forbid class in 'as' and 'insteadof' didn't break because most of them
didn't even work.
in the case of parent class insteadof usage, the REAL need is avoid trait's
method overwrite
the method inherited but not refer to parent class.
there is a really easy workaround: rename the conflict method as
a new one `Traits::method as _use_less` or something else,
if we really need the method from parent.
undefined
method
StandAlone::foo as bar; // Child::bar() -> undefined method
StandAlone::foo as foo; // Child::foo() -> "Trait"
GrandParent::foo as bar; // Child::bar() -> undefined method
/* insteadof */
Parent::foo insteadof T; // works by accident -> "Parent"
GrandParent::foo insteadof T; // -> "Parent" but not "Grand"
StandAlone::foo insteadof T; // ->"Parent"
}
}
[2013-02-20 14:40:32] larue...@php.net
@Stefan the current patch is allow use insteadof with classes (as the reporter
said, it used to works),
and forbid use "as" with classes (5.4.11 will result in an unexpected FATAL
error "undefined method", which is very confused message), the new solution is
trigger compiler ERROR
so, for the current patch, I think it is consistent with before, no need to be
RFCed again.
however, if we decide to forbind using both 'as' and 'insteadof' with classes,
that definitely need a RFC
[2013-02-20 13:20:15] g...@php.net
Hi:
The `insteadof` and `as` operators where not intended to be used with classes.
The syntax is intended to convey that the use operation is refined by
specifying how to
resolve conflicts __between__ traits.
That's the idea at least.
My solution for the initial problem presented would be to provide a method such
as follows in
the TestChildClass:
public function method() {
parent::method();
}
I understand that this is not ideal, and requires you to repeat yourself.
However, it is consistent in the sense that traits are traits and not classes,
and both get
mixed up as little as possible,
However, beside the academic notion of purity, I can see that
`TestParentClass::method
insteadof TestTrait;` is useful.
[I wonder whether `parent::method insteadof TestTrait;` should be supported as
well.]
Laruence's example with `TestParentClass::method as methodParent;` is however
problematic.
Traits are not supposed to conflict with classes, but with traits. So, allowing
the
introduction of aliases for method of the super class seems to me as something
that is
problematic, because it mixes up the concepts.
If you need an alias for the method of a parent class, the classic way would be:
public function foo() {
parent::bar();
}
No?
Well, that's my point of view.
So, from a practical point of view, referring to the parent (and only the
direct parent) class
in `insteadof` might be a useful/acceptable feature.
The use in conjunction with `as` seems to be something I would advocate against.
In either way, beside bugs that made this possible in the first pl
Bug #64235 [PATCH]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1 ID: 64235 Patch added by: larue...@php.net Reported by:imenem at inox dot ru Summary:Insteadof not work for class method in 5.4.11 Status: Feedback Type: Bug Package:Scripting Engine problem Operating System: Debian GNU/Linux PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64235.patch Revision: 1361347678 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.patch&revision=1361347678 Previous Comments: [2013-02-20 08:04:11] dmi...@php.net It's hard to say what is expected :) I thought only traits may be used in context of "insteadof", now I'm not sure. I sent the question to Stefan Marr. Lets wait for his opinion. [2013-02-20 08:00:02] re...@php.net insteadof and 'as' bother for traits, I thought after the trait refactor, it's works as expected. If we keep 'insteadof' could been used for class method as feature I'm fine:0 [2013-02-20 07:58:32] dmi...@php.net Yet another traits mess :( I suppose, it worked in 5.4.4 because of mistake. RFC and traits documentation don't say if class names may be used in context of "as" and "insteadof" operators. In my opinion, class names must not be used in contest of "as". However, their usage in context of "inseadof" may make sense (I'm not sure). Anyway, it has to be defined in documentation first. [2013-02-20 07:44:12] larue...@php.net fix attached, which fix this bug, and trigger fatal error in compile time for the test script I pasted before. [2013-02-20 07:41:23] larue...@php.net The following patch has been added/updated: Patch Name: bug64235.phpt Revision: 1361346083 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.phpt&revision=1361346083 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=64235 -- Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1
Bug #64235 [PATCH]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1 ID: 64235 Patch added by: larue...@php.net Reported by:imenem at inox dot ru Summary:Insteadof not work for class method in 5.4.11 Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Debian GNU/Linux PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64235.phpt Revision: 1361346083 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.phpt&revision=1361346083 Previous Comments: [2013-02-20 07:39:40] larue...@php.net The following patch has been added/updated: Patch Name: bug64235.patch Revision: 1361345980 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.patch&revision=1361345980 [2013-02-20 07:15:37] larue...@php.net actually, I was looking into this, I have thought the similar fix of you, but unfortunatly, it is wrong, thinking of this: methodParent(); ~ [2013-02-20 07:00:53] re...@php.net Hi dmitry, will you take a look please. [2013-02-18 11:58:23] imenem at inox dot ru Description: In PHP 5.4.4 test script works as expected, in 5.4.11 script caused fatal error. Test script: --- method(); (new TestChildClass)->methodAlias(); Expected result: Parent method Trait method Actual result: -- Fatal error: Trait TestParentClass is not used in test.php on line 28 -- Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1
Bug #64235 [PATCH]: Insteadof not work for class method in 5.4.11
Edit report at https://bugs.php.net/bug.php?id=64235&edit=1 ID: 64235 Patch added by: larue...@php.net Reported by:imenem at inox dot ru Summary:Insteadof not work for class method in 5.4.11 Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Debian GNU/Linux PHP Version:5.4.11 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug64235.patch Revision: 1361345980 URL: https://bugs.php.net/patch-display.php?bug=64235&patch=bug64235.patch&revision=1361345980 Previous Comments: [2013-02-20 07:15:37] larue...@php.net actually, I was looking into this, I have thought the similar fix of you, but unfortunatly, it is wrong, thinking of this: methodParent(); ~ [2013-02-20 07:00:53] re...@php.net Hi dmitry, will you take a look please. [2013-02-18 11:58:23] imenem at inox dot ru Description: In PHP 5.4.4 test script works as expected, in 5.4.11 script caused fatal error. Test script: --- method(); (new TestChildClass)->methodAlias(); Expected result: Parent method Trait method Actual result: -- Fatal error: Trait TestParentClass is not used in test.php on line 28 -- Edit this bug report at https://bugs.php.net/bug.php?id=64235&edit=1
[PHP-BUG] Bug #64231 [NEW]: msgpack_serialize interfere with serialize
From: laruence Operating system: PHP version: 5.4.11 Package: *General Issues Bug Type: Bug Bug description:msgpack_serialize interfere with serialize Description: see example below Test script: --- https://bugs.php.net/bug.php?id=64231&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=64231&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=64231&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=64231&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=64231&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=64231&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=64231&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=64231&r=needscript Try newer version: https://bugs.php.net/fix.php?id=64231&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=64231&r=support Expected behavior: https://bugs.php.net/fix.php?id=64231&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=64231&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=64231&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=64231&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=64231&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=64231&r=dst IIS Stability: https://bugs.php.net/fix.php?id=64231&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=64231&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=64231&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=64231&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=64231&r=mysqlcfg
Bug #64135 [PATCH]: Exceptions from set_error_handler are not always propagated
Edit report at https://bugs.php.net/bug.php?id=64135&edit=1
ID: 64135
Patch added by: larue...@php.net
Reported by:za_creature at yahoo dot com
Summary:Exceptions from set_error_handler are not always
propagated
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: WOW64, CentOS6.3
PHP Version:5.4.11
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug64135.patch
Revision: 1359960972
URL:
https://bugs.php.net/patch-display.php?bug=64135&patch=bug64135.patch&revision=1359960972
Previous Comments:
[2013-02-02 16:55:11] za_creature at yahoo dot com
Description:
echo $undefined works
$undefined++ works
$undefined->method() doesn't
Test script:
---
method();
}
catch(Exception $e) {
echo "Exception is thrown";
}
Expected result:
Exception is thrown
Actual result:
--
PHP Warning: Uncaught exception 'Exception' in /home/radu/bug.php:4
Stack trace:
#0 /home/radu/bug.php(9): exception_error_handler(8, 'Undefined varia...',
'/home/radu/bug', 9, Array)
#1 {main}
thrown in /home/radu/bug.php on line 4
Warning: Uncaught exception 'Exception' in /home/radu/bug.php:4
Stack trace:
#0 /home/radu/bug.php(9): exception_error_handler(8, 'Undefined varia...',
'/home/radu/bug', 9, Array)
#1 {main}
thrown in /home/radu/bug.php on line 4
PHP Fatal error: Call to a member function method() on a non-object in
/home/radu/bug.php on line 9
--
Edit this bug report at https://bugs.php.net/bug.php?id=64135&edit=1
[PHP-BUG] Bug #63988 [NEW]: Tow Data tests failes
From: laruence
Operating system:
PHP version: 5.5.0alpha2
Package: Date/time related
Bug Type: Bug
Bug description:Tow Data tests failes
Description:
Test DateTime::modify() function : usage variation - Passing unexpected
values to
first argument $modify. [ext/date/tests/DateTime_modify_variation1.phpt]
Test date_modify() function : usage variation - Passing unexpected values
to
second argument $format. [ext/date/tests/date_modify_variation2.phpt]
Test script:
---
$ cat ext/date/tests/DateTime_modify_variation1.diff
006+ object(DateTime)#3 (3) {
007+ ["date"]=>
008+ string(19) "2009-01-31 14:28:41"
009+ ["timezone_type"]=>
010+ int(3)
011+ ["timezone"]=>
012+ string(13) "Europe/London"
013+ }
006- bool(false)
011- bool(false)
016- bool(false)
018+ object(DateTime)#3 (3) {
019+ ["date"]=>
020+ string(19) "2009-01-31 14:28:41"
021+ ["timezone_type"]=>
022+ int(3)
023+ ["timezone"]=>
024+ string(13) "Europe/London"
025+ }
021- bool(false)
030+ object(DateTime)#3 (3) {
031+ ["date"]=>
032+ string(19) "2009-01-31 14:28:41"
033+ ["timezone_type"]=>
034+ int(3)
035+ ["timezone"]=>
036+ string(13) "Europe/London"
037+ }
036- bool(false)
042+ object(DateTime)#3 (3) {
043+ ["date"]=>
044+ string(19) "2009-01-31 14:28:41"
045+ ["timezone_type"]=>
046+ int(3)
047+ ["timezone"]=>
048+ string(13) "Europe/London"
049+ }
064+ object(DateTime)#3 (3) {
065+ ["date"]=>
066+ string(19) "2009-01-31 10:05:00"
067+ ["timezone_type"]=>
068+ int(3)
069+ ["timezone"]=>
070+ string(13) "Europe/London"
071+ }
071- bool(false)
076- bool(false)
081- bool(false)
086- bool(false)
091- bool(false)
096- bool(false)
101- bool(false)
106+ object(DateTime)#3 (3) {
107+ ["date"]=>
108+ string(19) "2009-01-31 00:05:00"
109+ ["timezone_type"]=>
110+ int(3)
111+ ["timezone"]=>
112+ string(13) "Europe/London"
113+ }
106- bool(false)
111- bool(false)
116- bool(false)
118+ object(DateTime)#3 (3) {
119+ ["date"]=>
120+ string(19) "2009-01-31 00:05:00"
121+ ["timezone_type"]=>
122+ int(3)
123+ ["timezone"]=>
124+ string(13) "Europe/London"
125+ }
121- bool(false)
126- bool(false)
130+ object(DateTime)#3 (3) {
131+ ["date"]=>
132+ string(19) "2009-01-31 00:05:00"
133+ ["timezone_type"]=>
134+ int(3)
135+ ["timezone"]=>
136+ string(13) "Europe/London"
137+ }
131- bool(false)
141- bool(false)
142+ object(DateTime)#3 (3) {
143+ ["date"]=>
144+ string(19) "2009-01-31 00:05:00"
145+ ["timezone_type"]=>
146+ int(3)
147+ ["timezone"]=>
148+ string(13) "Europe/London"
149+ }
146- bool(false)
154+ object(DateTime)#3 (3) {
155+ ["date"]=>
156+ string(19) "2009-01-31 00:05:00"
157+ ["timezone_type"]=>
158+ int(3)
159+ ["timezone"]=>
160+ string(13) "Europe/London"
161+ }
166+ object(DateTime)#3 (3) {
167+ ["date"]=>
168+ string(19) "2009-01-31 00:05:00"
169+ ["timezone_type"]=>
170+ int(3)
171+ ["timezone"]=>
172+ string(13) "Europe/London"
173+ }
178+ object(DateTime)#3 (3) {
179+ ["date"]=>
180+ string(19) "2009-01-31 00:05:00"
181+ ["timezone_type"]=>
182+ int(3)
183+ ["timezone"]=>
184+ string(13) "Europe/London"
185+ }
190+ object(DateTime)#3 (3) {
191+ ["date"]=>
192+ string(19) "2009-01-31 00:05:00"
193+ ["timezone_type"]=>
194+ int(3)
195+ ["timezone"]=>
196+ string(13) "Europe/London"
197+ }
202+ object(DateTime)#3 (3) {
203+ ["date"]=>
204+ string(19) "2009-01-31 00:05:00"
205+ ["timezone_type"]=>
206+ int(3)
207+ ["timezone"]=>
208+ string(13) "Europe/London"
209+ }
214+ object(DateTime)#3 (3) {
215+ ["date"]=>
216+ string(19) "2009-01-31 00:05:00"
217+ ["timezone_type"]=>
218+ int(3)
219+ ["timezone"]=>
220+ string(13) "Europe/London"
221+ }
226+ object(DateTime)#3 (3) {
227+ ["date"]=>
228+ string(19) "2009-01-31 00:05:00"
229+ ["timezone_type"]=>
230+ int(3)
231+ ["timezone"]=>
232+ string(13) "Europe/London"
233+ }
238+ object(DateTime)#3 (3) {
239+ ["date"]=>
240+ string(19) "2009-01-31 00:05:00"
241+ ["timezone_type"]=>
242+ int(3)
243+ ["timezone"]=>
244+ string(13) "Europe/London"
245+ }
250+ object(DateTime)#3 (3) {
251+ ["date"]=>
252+ string(19) "2009-01-31 00:05:00"
253+ ["timezone_type"]=>
254+ int(3)
255+ ["timezone"]=>
256+ string(13) "Europe/London"
257+ }
267+ object(DateTime)#3 (3) {
268+ ["date"]=>
269+ string(19) "2009-01-31 00:05:00"
270+ ["timezone_type"]=>
271+ int(3)
272+ ["timezone"]=>
273+ string(13) "Europe/London"
274+ }
279+ object(DateTime)#3 (3) {
280+ ["date"]=>
281+ string(19) "2009-01-31 00:05:00"
282+ ["timezone_type"]=>
283+ int(3)
284+ ["timezone"]=>
285+ string(13) "Europe/London"
286+ }
$ cat ext/date/tests/date_modify_variation2.diff
006+ object(DateTime)#3 (3) {
007+ ["date"]=>
008+ string(19) "2009-01-31 14:28:41"
009+ ["timezone_type"]=>
010+ int(3)
011+ ["timezone"]=>
012+ string(13) "Europe/
Bug #63980 [PATCH]: object members get trimmed by zero bytes
Edit report at https://bugs.php.net/bug.php?id=63980&edit=1
ID: 63980
Patch added by: larue...@php.net
Reported by:thbley at gmail dot com
Summary:object members get trimmed by zero bytes
Status: Open
Type: Bug
Package:*General Issues
Operating System: Win64
PHP Version:5.5.0alpha3-nts
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63980.patch
Revision: 1358135097
URL:
https://bugs.php.net/patch-display.php?bug=63980&patch=bug63980.patch&revision=1358135097
Previous Comments:
[2013-01-13 16:07:18] thbley at gmail dot com
Thanks, var_dump() works. But it would be great if get_object_vars() and
foreach() could be fixed.
Here is a more detailed test:
$arr = ["abc\0def" => "abc\0def"];
$obj = (object)$arr;
print_r($arr); // ok
echo "\n";
var_dump($obj); // ok
echo "\n";
echo serialize($obj); // ok
echo "\n";
echo (int)property_exists($obj, "abc"); // ok
echo "\n";
echo (int)isset($obj->{"abc"}); // ok
echo "\n";
echo json_encode($obj); // ok
echo "\n";
var_dump((array)$obj); // ok
echo "\n";
var_export($obj); // bug
echo "\n";
print_r($obj); // bug
echo "\n";
debug_zval_dump($obj); // bug
echo "\n";
var_dump(get_object_vars($obj)); // bug
echo "\n";
echo get_object_vars($obj)["abc"]; // bug
echo "\n";
foreach ($obj as $key=>$val) {
echo $key." : ".$val."\n"; // bug
}
[2013-01-13 12:55:01] larue...@php.net
it's due to print_r specific behavior for object's properties...
if you use var_dump instead, you will see it's not trimmed.
[2013-01-13 02:33:33] thbley at gmail dot com
Description:
Array keys are not trimmed by zero bytes. (ok)
Object member names are trimmed by zero bytes. (bug)
Test script:
---
$arr = ["abc\0def" => "abc\0def"];
print_r($arr);
print_r((object)$arr);
Expected result:
Array
(
[abc def] => abc def
)
stdClass Object
(
[abc def] => abc def
)
Actual result:
--
Array
(
[abc def] => abc def
)
stdClass Object
(
[abc] => abc def
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63980&edit=1
Bug #63835 [PATCH]: two cookie in request ,get comma in first cookie name
Edit report at https://bugs.php.net/bug.php?id=63835&edit=1
ID: 63835
Patch added by: larue...@php.net
Reported by:tom916 at qq dot com
Summary:two cookie in request ,get comma in first cookie
name
Status: Open
Type: Bug
Package:*General Issues
Operating System: linux
PHP Version:5.3Git-2012-12-22 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63835.patch
Revision: 1356242654
URL:
https://bugs.php.net/patch-display.php?bug=63835&patch=bug63835.patch&revision=1356242654
Previous Comments:
[2012-12-23 05:48:53] larue...@php.net
oh, ignore my previous comment, apache return a comma separated string if there
is
multi cookie headers
[2012-12-23 05:46:39] larue...@php.net
I don't think it's a php specific bug, php read the cookie via apache
apr_table_get
apr_table_get return ", a=1" in your case.
[2012-12-22 17:21:20] tom916 at qq dot com
Description:
When the browser client send 2 Cookie: in headerï¼the php get first cookie
name has a comma in the fist charãGod know know the browser send 2 Cookie in
header ?
Array
(
[,_a] => 1
)
Test script:
---
--show_cookie.php--
\n";
} else {
$out = "GET /show_cookie.php HTTP/1.1\r\n";
$out .= "Host: localhost:50080\r\n";
$out .= "Cookie:\r\n";
$out .= "Cookie: a=1\r\n";
$out .= "Connection: Close\r\n\r\n";
fwrite($fp, $out);
while (!feof($fp)) {
echo fgets($fp, 128);
}
fclose($fp);
}
php send_cookie.php
-result---
HTTP/1.1 200 OK
Date: Sat, 22 Dec 2012 17:11:59 GMT
Server: Apache/2.2.17 (Unix) PHP/5.3.3
X-Powered-By: PHP/5.3.3
Content-Length: 25
Connection: close
Content-Type: text/html
Array
(
[,_a] => 1
)
Expected result:
Array
(
[a] => 1
)
Actual result:
--
Array
(
[,_a] => 1
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63835&edit=1
[PHP-BUG] Bug #63826 [NEW]: Two tests failed
From: laruence Operating system: PHP version: 5.4.10 Package: Testing related Bug Type: Bug Bug description:Two tests failed Description: Bug #63363 (CURL silently accepts boolean value for SSL_VERIFYHOST) [ext/curl/tests/bug63363.phpt] Bug #52820 (writes to fopencookie FILE* not commited when seeking the stream) [ext/standard/tests/file/bug52820.phpt] Test script: --- Bug #63363 (CURL silently accepts boolean value for SSL_VERIFYHOST) [ext/curl/tests/bug63363.phpt] Bug #52820 (writes to fopencookie FILE* not commited when seeking the stream) [ext/standard/tests/file/bug52820.phpt] Expected result: test pass Actual result: -- failed with diff: $ cat ext/curl/tests/bug63363.diff 004+ bool(false) 006+ bool(false) 006- bool(true) 007- bool(true) $ cat ext/standard/tests/file/bug52820.diff 004+ * Trying 127.0.0.1... 005+ * Connection refused 006+ * couldn't connect to host at 127.0.0.1:37349 004- * Trying 127.0.0.1... * Connection refused 005- * couldn't connect to host 011- * Trying 127.0.0.1... * Connection refused 012- * couldn't connect to host 012+ * Trying 127.0.0.1... 013+ * Connection refused 014+ * couldn't connect to host at 127.0.0.1:37349 018- * Trying 127.0.0.1... * Connection refused 019- * couldn't connect to host 020+ * Trying 127.0.0.1... 021+ * Connection refused 022+ * couldn't connect to host at 127.0.0.1:37349 025- * Trying 127.0.0.1... * Connection refused 026- * couldn't connect to host 028+ * Trying 127.0.0.1... 029+ * Connection refused 030+ * couldn't connect to host at 127.0.0.1:37349 -- Edit bug report at https://bugs.php.net/bug.php?id=63826&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63826&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63826&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63826&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63826&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63826&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63826&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63826&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63826&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63826&r=support Expected behavior: https://bugs.php.net/fix.php?id=63826&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63826&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63826&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63826&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63826&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63826&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63826&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63826&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63826&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63826&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63826&r=mysqlcfg
Bug #61046 [PATCH]: Segfault when memory limit is hit while copying hash table
Edit report at https://bugs.php.net/bug.php?id=61046&edit=1
ID: 61046
Patch added by: larue...@php.net
Reported by:ni...@php.net
Summary:Segfault when memory limit is hit while copying hash
table
Status: Open
Type: Bug
Package:Reproducible crash
PHP Version:5.4.0RC7
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61046.patch
Revision: 1356016047
URL:
https://bugs.php.net/patch-display.php?bug=61046&patch=bug61046.patch&revision=1356016047
Previous Comments:
[2012-12-20 11:18:02] arrtedone at gmail dot com
Description:
Same here, reproducable, but with memory limit set to 128M (note that i am not
using the provided test script, it crached randomly)
Test script:
-
-
System information :
OS : Fedora 17 Linux nask0 3.6.10-2.fc17.x86_64 #1 SMP Tue Dec 11 18:07:34 UTC
2012 x86_64
PHP version 5.4.9 :
PHP API : 20100412
PHP Extension : 20100525
Zend Extension : 220100525
Zend Extension Build : API220100525,NTS
PHP Extension Build : API20100525,NTS
Thread Safety: disabled
Zend Signal Handling: disabled
Zend Memory Manager: enabled
Apache Version: Apache/2.2.22 (Fedora) DAV/2 PHP/5.4.9
Apache API Version : 20051115
GDB backtrace :
---
Program received signal SIGSEGV, Segmentation fault.
zend_mm_remove_from_free_list (heap=0x7f75283c10d0, mm_block=0x7f752a24b3f8) at
/usr/src/debug/php-5.4.9/Zend/zend_alloc.c:833
833 if (UNEXPECTED(prev->next_free_block != mm_block) ||
UNEXPECTED(next->prev_free_block != mm_block)) {
(gdb) continue
Continuing.
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
[2012-02-10 18:08:37] ras...@php.net
Same here. Reproducable on 64-bit Linux with memory_limit set to "512k".
The segfault is here:
zend_mm_remove_from_free_list (heap=0xf71730, mm_block=0x77fae1c8) at
/home/rasmus/php-src/branches/PHP_5_4/Zend/zend_alloc.c:805
805 ZEND_MM_CHECK_TREE(mm_block);
(gdb) p *mm_block
$2 = {info = {_size = 16400, _prev = 57}, prev_free_block = 0x77fae1c8,
next_free_block = 0x77fae1c8, parent = 0x0, child = {0x0, 0x0}}
Note that parent is NULL there and ZEND_MM_CHECK_TREE tries to dereference
*parent
[2012-02-10 17:46:09] jpa...@php.net
Notice that I only reproduce with memory_limit set to accurate 512k , not 500k
as
in bug text, nor even 511k
[2012-02-10 17:34:21] jpa...@php.net
What I can say :
- I dont reproduce on 5.3.10
- For 5.4, disabling ZendMM with USE_ZEND_ALLOC=0 makes the segfault disappear
- For 5.4, changing the ZendMM segment size with ZEND_MM_SEG_SIZE={val} makes
the
segfault disappear, I havent tested all the possible values for SEG_SIZE.
As a reminder, ZendMM default SEG_SIZE is set to 256k
[2012-02-10 17:31:28] ni...@php.net
GDB Stacktrace:
#0 zend_mm_remove_from_free_list (heap=0x88da8d8, mm_block=0xb7fc5308)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:805
#1 0x083ad608 in _zend_mm_free_int (heap=0x88da8d8, p=0xb7fc52f0)
at /home/nikic/dev/php-src-git/Zend/zend_alloc.c:2101
#2 0x083cd657 in destroy_op_array (op_array=0x8a5d4c8, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:380
#3 0x083cd777 in zend_function_dtor (function=0x8a5d4c8)
at /home/nikic/dev/php-src-git/Zend/zend_opcode.c:124
#4 0x083e49ae in zend_hash_apply_deleter (ht=0x88dae70, p=0x8a5d498)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:650
#5 0x083e63b1 in zend_hash_reverse_apply (ht=0x88dae70,
apply_func=0x83c7310 , tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_hash.c:804
#6 0x083c7ecb in shutdown_executor (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend_execute_API.c:304
#7 0x083d7c11 in zend_deactivate (tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/Zend/zend.c:934
#8 0x0836be33 in php_request_shutdown (dummy=0x0)
at /home/nikic/dev/php-src-git/main/main.c:1782
#9 0x0848d723 in do_cli (argc=4, argv=0xb3b4, tsrm_ls=0x88d9050)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1169
#10 0x0806eaa3 in main (argc=4, argv=0xb3b4)
at /home/nikic/dev/php-src-git/sapi/cli/php_cli.c:1356
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=61046
--
E
Bug #63741 [PATCH]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Patch added by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452419 URL: https://bugs.php.net/patch-display.php?bug=63741&patch=bug63741.patch&revision=1355452419 Previous Comments: [2012-12-13 08:19:16] larue...@php.net however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- >called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 -------- [2012-12-13 02:49:53] larue...@php.net unfortunately, I can not reproduce it. instead I got a FATAL ERROR: can not redeclare function main 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=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1
Bug #63741 [PATCH]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Patch added by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452420 URL: https://bugs.php.net/patch-display.php?bug=63741&patch=bug63741.patch&revision=1355452420 Previous Comments: [2012-12-14 02:33:39] larue...@php.net The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452419 URL: https://bugs.php.net/patch-display.php?bug=63741&patch=bug63741.patch&revision=1355452419 [2012-12-13 08:19:16] larue...@php.net however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- >called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 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=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1
Bug #63748 [PATCH]: error: 'struct fpm_scoreboard_s' has no member named 'lock'
Edit report at https://bugs.php.net/bug.php?id=63748&edit=1 ID: 63748 Patch added by: larue...@php.net Reported by:xuefer at gmail dot com Summary:error: 'struct fpm_scoreboard_s' has no member named 'lock' Status: Feedback Type: Bug Package:FPM related Operating System: linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63748.patch Revision: 1355295419 URL: https://bugs.php.net/patch-display.php?bug=63748&patch=bug63748.patch&revision=1355295419 Previous Comments: ---- [2012-12-12 06:55:45] larue...@php.net anyway, I think using anonymous union in struct is not very good idea, a patch attached. ---- [2012-12-12 06:54:50] larue...@php.net The following patch has been added/updated: Patch Name: bug63748.patch Revision: 1355295290 URL: https://bugs.php.net/patch-display.php?bug=63748&patch=bug63748.patch&revision=1355295290 -------- [2012-12-12 06:46:55] larue...@php.net according to : http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed- Fields I think you need "-fms-extensions" thanks [2012-12-12 03:40:21] xuefer at gmail dot com Description: CFLAGS='-pipe -Wall -std=c99 -D_GNU_SOURCE -pedantic' "CFLAGS=-pipe -Wall -std=c99 -D_GNU_SOURCE -pedantic -O0 -g" "CXXFLAGS=-pipe - Wall -std=c99 -D_GNU_SOURCE -pedantic -O0 -g" ../php5/configure --disable-pear -- enable-debug --enable-maintainer-zts --enable-experimental-zts --enable-fpm -- enable-cgi --enable-fastcgi --enable-fastcgi --enable-force-cgi-redirect --with- pcre-regex --with-zlib --with-jpeg-dir=/usr --with-png-dir=/usr --with-gd -- with- openssl --with-posix --with-iconv --enable-sockets --enable-inline-optimization -- disable-mbregex --enable-bcmath --enable-pcntl --enable-memory-limit --enable- ftp --enable-event --with-mysql=/usr --enable-mmap --enable-mbstring --with-readline - -with-xmlrpc --enable-soap --with-sqlite --enable-sqlite-utf8 --with- mysqli=/usr/bin/mysql_config --with-pdo-mysql=/usr --prefix=/home/moo/test/php5- debug-zts --cache-file=config.cache make Actual result: -- /home/moo/src/php/php5-debug-zts/meta_ccld -I/home/moo/src/php/php5/sapi/fpm - Isapi/fpm/ -I/home/moo/src/php/php5/sapi/fpm/ -DPHP_ATOM_INC - I/home/moo/src/php/php5-debug-zts/include -I/home/moo/src/php/php5-debug- zts/main -I/home/moo/src/php/php5 -I/home/moo/src/php/php5-debug- zts/ext/date/lib -I/home/moo/src/php/php5/ext/date/lib - I/home/moo/src/php/php5/ext/ereg/regex -I/usr/include/libxml2 - I/home/moo/src/php/php5/ext/mbstring/libmbfl -I/home/moo/src/php/php5-debug- zts/ext/mbstring/libmbfl -I/home/moo/src/php/php5/ext/mbstring/libmbfl/mbfl - I/home/moo/src/php/php5-debug-zts/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/home/moo/src/php/php5/ext/sqlite3/libsqlite -I/home/moo/src/php/php5-debug- zts/TSRM -I/home/moo/src/php/php5-debug-zts/Zend -I/home/moo/src/php/php5/main - I/home/moo/src/php/php5/Zend -I/home/moo/src/php/php5/TSRM - I/home/moo/src/php/php5-debug-zts/ -D_REENTRANT -I/usr/include -pipe -Wall - std=c99 -D_GNU_SOURCE -pedantic -g -fvisibility=hidden -pthread -O0 -Wall -DZTS -c /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c -o sapi/fpm/fpm/fpm_scoreboard.o In file included from /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:11:0: /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.h:24:3: warning: declaration does not declare anything /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.h:53:3: warning: declaration does not declare anything /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_update': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:87:26: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:146:12: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_acquire': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:187:22: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_release': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:199:12: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_pro
Bug #63748 [PATCH]: error: 'struct fpm_scoreboard_s' has no member named 'lock'
Edit report at https://bugs.php.net/bug.php?id=63748&edit=1 ID: 63748 Patch added by: larue...@php.net Reported by:xuefer at gmail dot com Summary:error: 'struct fpm_scoreboard_s' has no member named 'lock' Status: Feedback Type: Bug Package:FPM related Operating System: linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63748.patch Revision: 1355295290 URL: https://bugs.php.net/patch-display.php?bug=63748&patch=bug63748.patch&revision=1355295290 Previous Comments: ---- [2012-12-12 06:46:55] larue...@php.net according to : http://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html#Unnamed- Fields I think you need "-fms-extensions" thanks [2012-12-12 03:40:21] xuefer at gmail dot com Description: CFLAGS='-pipe -Wall -std=c99 -D_GNU_SOURCE -pedantic' "CFLAGS=-pipe -Wall -std=c99 -D_GNU_SOURCE -pedantic -O0 -g" "CXXFLAGS=-pipe - Wall -std=c99 -D_GNU_SOURCE -pedantic -O0 -g" ../php5/configure --disable-pear -- enable-debug --enable-maintainer-zts --enable-experimental-zts --enable-fpm -- enable-cgi --enable-fastcgi --enable-fastcgi --enable-force-cgi-redirect --with- pcre-regex --with-zlib --with-jpeg-dir=/usr --with-png-dir=/usr --with-gd -- with- openssl --with-posix --with-iconv --enable-sockets --enable-inline-optimization -- disable-mbregex --enable-bcmath --enable-pcntl --enable-memory-limit --enable- ftp --enable-event --with-mysql=/usr --enable-mmap --enable-mbstring --with-readline - -with-xmlrpc --enable-soap --with-sqlite --enable-sqlite-utf8 --with- mysqli=/usr/bin/mysql_config --with-pdo-mysql=/usr --prefix=/home/moo/test/php5- debug-zts --cache-file=config.cache make Actual result: -- /home/moo/src/php/php5-debug-zts/meta_ccld -I/home/moo/src/php/php5/sapi/fpm - Isapi/fpm/ -I/home/moo/src/php/php5/sapi/fpm/ -DPHP_ATOM_INC - I/home/moo/src/php/php5-debug-zts/include -I/home/moo/src/php/php5-debug- zts/main -I/home/moo/src/php/php5 -I/home/moo/src/php/php5-debug- zts/ext/date/lib -I/home/moo/src/php/php5/ext/date/lib - I/home/moo/src/php/php5/ext/ereg/regex -I/usr/include/libxml2 - I/home/moo/src/php/php5/ext/mbstring/libmbfl -I/home/moo/src/php/php5-debug- zts/ext/mbstring/libmbfl -I/home/moo/src/php/php5/ext/mbstring/libmbfl/mbfl - I/home/moo/src/php/php5-debug-zts/ext/mbstring/libmbfl/mbfl -I/usr/include/mysql -I/home/moo/src/php/php5/ext/sqlite3/libsqlite -I/home/moo/src/php/php5-debug- zts/TSRM -I/home/moo/src/php/php5-debug-zts/Zend -I/home/moo/src/php/php5/main - I/home/moo/src/php/php5/Zend -I/home/moo/src/php/php5/TSRM - I/home/moo/src/php/php5-debug-zts/ -D_REENTRANT -I/usr/include -pipe -Wall - std=c99 -D_GNU_SOURCE -pedantic -g -fvisibility=hidden -pthread -O0 -Wall -DZTS -c /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c -o sapi/fpm/fpm/fpm_scoreboard.o In file included from /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:11:0: /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.h:24:3: warning: declaration does not declare anything /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.h:53:3: warning: declaration does not declare anything /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_update': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:87:26: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:146:12: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_acquire': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:187:22: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_release': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:199:12: error: 'struct fpm_scoreboard_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_proc_acquire': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:211:25: error: 'struct fpm_scoreboard_proc_s' has no member named 'lock' /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c: In function 'fpm_scoreboard_proc_release': /home/moo/src/php/php5/sapi/fpm/fpm/fpm_scoreboard.c:225:6: error: 'struct fpm_scoreboard_proc_s' has no member named 'lock' -- Edit this bug report at https://bugs.php.net/bug.php?id=63748&edit=1
Bug #63726 [PATCH]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Patch added by: larue...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355139037 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355139037 Previous Comments: [2012-12-10 11:11:55] dmi...@php.net The patch looks good. Please commit it into 5.3 and above. [2012-12-10 10:58:05] m...@php.net Yes, this should be fine. But! :) There seems to be a similar problem with instance properties: //output int(0) int(0) [2012-12-09 13:20:05] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355059205 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355059205 [2012-12-09 13:08:38] larue...@php.net dmitry, could you review this patch please? thanks 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #63726 [PATCH]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Patch added by: larue...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Assigned Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355059205 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355059205 Previous Comments: [2012-12-09 13:08:38] larue...@php.net dmitry, could you review this patch please? thanks [2012-12-09 13:07:37] larue...@php.net The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355058457 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355058457 [2012-12-09 12:32:48] larue...@php.net compiled successfully, and reproduced this problem now :) thanks [2012-12-09 11:37:15] m...@php.net Could you please "svn up" and try again? There were some odd includes on the top of php_http_curl_client.c Thank you ---- [2012-12-09 11:31:29] larue...@php.net compile error: In file included from /home/huixinchen/local/php54- zts//include/php/main/php_ini.h:24, from /home/huixinchen/local/php54- zts//include/php/main/fopen_wrappers.h:26, from /home/huixinchen/local/php54- zts//include/php/main/php.h:398, from /home/huixinchen/opensource/pecl/http/branches/DEV_2/php_http_api.h:23, from /home/huixinchen/opensource/pecl/http/branches/DEV_2/php_http_curl_client.c:16: /home/huixinchen/local/php54-zts//include/php/Zend/zend_ini.h:81: error: expected â)â before â*â token /home/huixinchen/local/php54-zts//include/php/Zend/zend_ini.h:82: warning: no semicolon at end of struct or union /home/huixinchen/local/php54-zts//include/php/Zend/zend_ini.h:94: error: expected â;â, â,â or â)â before â*â token 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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #63726 [PATCH]: Memleak with static properties and internal/user classes
Edit report at https://bugs.php.net/bug.php?id=63726&edit=1 ID: 63726 Patch added by: larue...@php.net Reported by:m...@php.net Summary:Memleak with static properties and internal/user classes Status: Open Type: Bug Package:Scripting Engine problem Operating System: Arch Linux PHP Version:Irrelevant Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63726.patch Revision: 1355058457 URL: https://bugs.php.net/patch-display.php?bug=63726&patch=bug63726.patch&revision=1355058457 Previous Comments: [2012-12-09 12:32:48] larue...@php.net compiled successfully, and reproduced this problem now :) thanks [2012-12-09 11:37:15] m...@php.net Could you please "svn up" and try again? There were some odd includes on the top of php_http_curl_client.c Thank you [2012-12-09 11:31:29] larue...@php.net compile error: In file included from /home/huixinchen/local/php54- zts//include/php/main/php_ini.h:24, from /home/huixinchen/local/php54- zts//include/php/main/fopen_wrappers.h:26, from /home/huixinchen/local/php54- zts//include/php/main/php.h:398, from /home/huixinchen/opensource/pecl/http/branches/DEV_2/php_http_api.h:23, from /home/huixinchen/opensource/pecl/http/branches/DEV_2/php_http_curl_client.c:16: /home/huixinchen/local/php54-zts//include/php/Zend/zend_ini.h:81: error: expected â)â before â*â token /home/huixinchen/local/php54-zts//include/php/Zend/zend_ini.h:82: warning: no semicolon at end of struct or union /home/huixinchen/local/php54-zts//include/php/Zend/zend_ini.h:94: error: expected â;â, â,â or â)â before â*â token [2012-12-09 11:08:35] m...@php.net Strange... why? [2012-12-09 09:21:22] larue...@php.net I can not compile DEV_2 with php-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=63726 -- Edit this bug report at https://bugs.php.net/bug.php?id=63726&edit=1
Bug #63682 [PATCH]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63682&edit=1 ID: 63682 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties Status: Open Type: Bug Package:SimpleXML related PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63682.patch Revision: 1354601347 URL: https://bugs.php.net/patch-display.php?bug=63682&patch=bug63682.patch&revision=1354601347 Previous Comments: [2012-12-04 05:41:15] larue...@php.net The following patch has been added/updated: Patch Name: bug63682.patch Revision: 1354599675 URL: https://bugs.php.net/patch-display.php?bug=63682&patch=bug63682.patch&revision=1354599675 [2012-12-04 05:40:38] larue...@php.net Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63682&edit=1
Bug #63683 [PATCH]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63683&edit=1 ID: 63683 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties Status: Open Type: Bug Package:Date/time related PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63683.patch Revision: 1354600121 URL: https://bugs.php.net/patch-display.php?bug=63683&patch=bug63683.patch&revision=1354600121 Previous Comments: [2012-12-04 05:48:02] larue...@php.net Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63683&edit=1
[PHP-BUG] Bug #63683 [NEW]: Use get_gc instead of hack of get_properties
From: laruence Operating system: PHP version: 5.4.9 Package: Date/time related Bug Type: Bug Bug description:Use get_gc instead of hack of get_properties Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=63683&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63683&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63683&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63683&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63683&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63683&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63683&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63683&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63683&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63683&r=support Expected behavior: https://bugs.php.net/fix.php?id=63683&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63683&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63683&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63683&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63683&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63683&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63683&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63683&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63683&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63683&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63683&r=mysqlcfg
Bug #63682 [PATCH]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63682&edit=1 ID: 63682 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties Status: Open Type: Bug Package:SimpleXML related PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63682.patch Revision: 1354599675 URL: https://bugs.php.net/patch-display.php?bug=63682&patch=bug63682.patch&revision=1354599675 Previous Comments: [2012-12-04 05:40:38] larue...@php.net Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63682&edit=1
[PHP-BUG] Bug #63682 [NEW]: Use get_gc instead of hack of get_properties
From: laruence Operating system: PHP version: 5.4.9 Package: SimpleXML related Bug Type: Bug Bug description:Use get_gc instead of hack of get_properties Description: see summary Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=63682&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63682&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63682&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63682&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63682&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63682&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63682&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63682&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63682&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63682&r=support Expected behavior: https://bugs.php.net/fix.php?id=63682&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63682&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63682&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63682&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63682&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63682&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63682&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63682&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63682&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63682&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63682&r=mysqlcfg
Bug #63681 [PATCH]: Use get_gc instead of hack of get_properties
Edit report at https://bugs.php.net/bug.php?id=63681&edit=1 ID: 63681 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:Use get_gc instead of hack of get_properties Status: Open Type: Bug Package:SPL related PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63681.patch Revision: 1354599228 URL: https://bugs.php.net/patch-display.php?bug=63681&patch=bug63681.patch&revision=1354599228 Previous Comments: [2012-12-04 05:33:22] larue...@php.net Description: imporve the gc handler for spl_object Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63681&edit=1
[PHP-BUG] Bug #63681 [NEW]: Use get_gc instead of hack of get_properties
From: laruence Operating system: PHP version: 5.4.9 Package: SPL related Bug Type: Bug Bug description:Use get_gc instead of hack of get_properties Description: imporve the gc handler for spl_object Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=63681&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63681&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63681&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63681&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63681&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63681&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63681&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63681&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63681&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63681&r=support Expected behavior: https://bugs.php.net/fix.php?id=63681&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63681&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63681&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63681&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63681&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63681&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63681&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63681&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63681&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63681&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63681&r=mysqlcfg
Bug #63680 [PATCH]: Memleak in splfixedarray with cycle reference
Edit report at https://bugs.php.net/bug.php?id=63680&edit=1 ID: 63680 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:Memleak in splfixedarray with cycle reference Status: Open Type: Bug Package:SPL related PHP Version:5.4.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63680.patch Revision: 1354598600 URL: https://bugs.php.net/patch-display.php?bug=63680&patch=bug63680.patch&revision=1354598600 Previous Comments: [2012-12-04 05:22:46] larue...@php.net Description: dmitry introduced the new get_gc handler, but seems splfixedarray doesn't implement it. also there are some other extensions still using ugly implementation for gc, I will review them one by one. thanks Test script: --- https://bugs.php.net/bug.php?id=63680&edit=1
[PHP-BUG] Bug #63680 [NEW]: Memleak in splfixedarray with cycle reference
From: laruence Operating system: PHP version: 5.4.9 Package: SPL related Bug Type: Bug Bug description:Memleak in splfixedarray with cycle reference Description: dmitry introduced the new get_gc handler, but seems splfixedarray doesn't implement it. also there are some other extensions still using ugly implementation for gc, I will review them one by one. thanks Test script: --- https://bugs.php.net/bug.php?id=63680&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63680&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63680&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63680&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63680&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63680&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63680&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63680&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63680&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63680&r=support Expected behavior: https://bugs.php.net/fix.php?id=63680&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63680&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63680&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63680&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63680&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63680&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63680&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63680&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63680&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63680&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63680&r=mysqlcfg
Bug #63468 [PATCH]: wrong called method as callback with inheritance
Edit report at https://bugs.php.net/bug.php?id=63468&edit=1 ID: 63468 Patch added by: larue...@php.net Reported by:patrik at votocek dot cz Summary:wrong called method as callback with inheritance Status: Open Type: Bug Package:Scripting Engine problem Operating System: ArchLinux PHP Version:5.4.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63468.patch Revision: 1352387087 URL: https://bugs.php.net/patch-display.php?bug=63468&patch=bug63468.patch&revision=1352387087 Previous Comments: [2012-11-08 13:18:39] patrik at votocek dot cz Description: callback call private method (in parent class) instead of public method in current class Test script: --- run(); Expected result: 'Bar' Actual result: -- 'Foo' -- Edit this bug report at https://bugs.php.net/bug.php?id=63468&edit=1
Bug #63428 [PATCH]: The behavior of execute() changed
Edit report at https://bugs.php.net/bug.php?id=63428&edit=1 ID: 63428 Patch added by: larue...@php.net Reported by:re...@php.net Summary:The behavior of execute() changed Status: Assigned Type: Bug Package:*General Issues Operating System: ANY PHP Version:master-Git-2012-11-03 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63428.patch Revision: 1351959257 URL: https://bugs.php.net/patch-display.php?bug=63428&patch=bug63428.patch&revision=1351959257 Previous Comments: [2012-11-03 15:28:40] re...@php.net Hi Nikic, will you take a look? Thanks :) https://github.com/php/php-src/pull/227 [2012-11-03 15:25:32] re...@php.net Description: Test Zend/tests/bug35437.phpt failed because of this when dtrace enabled or any extension which override zend_execute function pointer, such as xdebug. Test script: --- Test: Zend/tests/bug35437.phpt with dtrace or xdebug enabled Expected result: test PASS Actual result: -- Test failed because of segfault. -- Edit this bug report at https://bugs.php.net/bug.php?id=63428&edit=1
Bug #63344 [PATCH]: pg_query_params() doesn't pass parts of strings past zero byte character
Edit report at https://bugs.php.net/bug.php?id=63344&edit=1 ID: 63344 Patch added by: larue...@php.net Reported by:peter dot kehl at gmail dot com Summary:pg_query_params() doesn't pass parts of strings past zero byte character Status: Open Type: Bug Package:PostgreSQL related Operating System: CentOS 6.2; possibly irrelevant PHP Version:5.4.8 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63344.patch Revision: 1351060504 URL: https://bugs.php.net/patch-display.php?bug=63344&patch=bug63344.patch&revision=1351060504 Previous Comments: [2012-10-24 06:34:33] larue...@php.net according to http://www.postgresql.org/docs/8.0/static/libpq-exec.html the current PHP's wrapper of PQexecParams doesn't support binary data. a simple fix is attached [2012-10-24 04:39:53] peter dot kehl at gmail dot com Description: This may not be a code problem, but a documentation problem. At the top, this is similar to https://bugs.php.net/bug.php?id=45491&edit=2, but not the same. If the current behaviour is intended, then it should be documented at www.php.net/pg_query_params - because current documentation doesn't mention that it doesn't support zero bytes. Summary If I call pg_query_params( $connection, $sql_query_with_dollar_placeholders, $params ) with all three parameters, and $params is an array with at least 1 value which is a string, which contains 1 or more zero bye characters (in PHP it's chr(0) or "\0"), then that zero byte character(s) and anything right from it (in the same string) won't be passed to Postgres server. I've checked Postgres server logs, and the values come truncated just before the first zero byte character. That is probably due to Postgres using/treating strings like C language does, ended with a zero byte character. However, in PHP a string can contain one or multiple zero byte characters. This happens when e.g. using output of PHP's function serialize(). Side note I'm curious whether there is any way to set a Postgres varchar/text column to contain one or more zero byte characters. Following fails in pgAdmin (which uses UTF-8): INSERT INTO null_character_test(value) VALUES( E'First\0Second'); Environment: -- PHP server: CentOS 6.3 Linux localhost.localdomain 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Compiled PHP 5.4.8 ./configure --prefix=/usr/local/php --with-pgsql --with-apxs2=/usr/sbin/apxs --enable-mbstring /usr/local/php/bin/php -v PHP 5.4.8 (cli) (built: Oct 24 2012 14:49:11) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies Postgres server (and also a PHP server, where the same problem applies) CentOS 6.2 Linux pkehlcentos.racpnet.localhost.local 2.6.32-220.el6.x86_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86_64 x86_64 x86_64 GNU/Linux PostgreSQL 8.4.11 on x86_64-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.4.6 20110731 (Red Hat 4.4.6-3), 64-bit. /usr/local/php/bin/php -v PHP 5.4.4 (cli) (built: Aug 15 2012 14:07:53) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethans Test script: --- CREATE TABLE null_character_test( value varchar(255) ); that should match 1 row Actual result: -- SELECT * FROM null_character_test WHERE value='Only the first part (this one) gets saved to DB.' --> that matches 1 row -- Edit this bug report at https://bugs.php.net/bug.php?id=63344&edit=1
Req #63253 [PATCH]: class member access using __invoke() in php5.4
Edit report at https://bugs.php.net/bug.php?id=63253&edit=1 ID: 63253 Patch added by: larue...@php.net Reported by:schicker03 at gmail dot com Summary:class member access using __invoke() in php5.4 Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem Operating System: MacOSX 10.8 PHP Version:5.4.7 Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: instance_invoke_003.phpt Revision: 1350015929 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=instance_invoke_003.phpt&revision=1350015929 Previous Comments: [2012-10-12 04:25:07] larue...@php.net The following patch has been added/updated: Patch Name: instance_invoke_002.phpt Revision: 1350015907 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=instance_invoke_002.phpt&revision=1350015907 [2012-10-12 04:24:46] larue...@php.net The following patch has been added/updated: Patch Name: instance_invoke_001.phpt Revision: 1350015886 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=instance_invoke_001.phpt&revision=1350015886 ---- [2012-10-12 04:15:17] larue...@php.net The following patch has been added/updated: Patch Name: bug63253.patch Revision: 1350015317 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350015317 ---- [2012-10-12 04:09:27] larue...@php.net An patch is attached, assign to me, will make a rfc later ---- [2012-10-12 04:08:53] larue...@php.net The following patch has been added/updated: Patch Name: bug63253.patch Revision: 1350014933 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350014933 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=63253 -- Edit this bug report at https://bugs.php.net/bug.php?id=63253&edit=1
Req #63253 [PATCH]: class member access using __invoke() in php5.4
Edit report at https://bugs.php.net/bug.php?id=63253&edit=1 ID: 63253 Patch added by: larue...@php.net Reported by:schicker03 at gmail dot com Summary:class member access using __invoke() in php5.4 Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem Operating System: MacOSX 10.8 PHP Version:5.4.7 Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: instance_invoke_002.phpt Revision: 1350015907 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=instance_invoke_002.phpt&revision=1350015907 Previous Comments: [2012-10-12 04:24:46] larue...@php.net The following patch has been added/updated: Patch Name: instance_invoke_001.phpt Revision: 1350015886 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=instance_invoke_001.phpt&revision=1350015886 [2012-10-12 04:15:17] larue...@php.net The following patch has been added/updated: Patch Name: bug63253.patch Revision: 1350015317 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350015317 ---- [2012-10-12 04:09:27] larue...@php.net An patch is attached, assign to me, will make a rfc later ---- [2012-10-12 04:08:53] larue...@php.net The following patch has been added/updated: Patch Name: bug63253.patch Revision: 1350014933 URL: https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350014933 [2012-10-11 16:25:46] fel...@php.net This is not a bug... but a feature request. 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=63253 -- Edit this bug report at https://bugs.php.net/bug.php?id=63253&edit=1
Req #63253 [PATCH]: class member access using __invoke() in php5.4
Edit report at https://bugs.php.net/bug.php?id=63253&edit=1
ID: 63253
Patch added by: larue...@php.net
Reported by:schicker03 at gmail dot com
Summary:class member access using __invoke() in php5.4
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: MacOSX 10.8
PHP Version:5.4.7
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: instance_invoke_001.phpt
Revision: 1350015886
URL:
https://bugs.php.net/patch-display.php?bug=63253&patch=instance_invoke_001.phpt&revision=1350015886
Previous Comments:
[2012-10-12 04:15:17] larue...@php.net
The following patch has been added/updated:
Patch Name: bug63253.patch
Revision: 1350015317
URL:
https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350015317
[2012-10-12 04:09:27] larue...@php.net
An patch is attached, assign to me, will make a rfc later
[2012-10-12 04:08:53] larue...@php.net
The following patch has been added/updated:
Patch Name: bug63253.patch
Revision: 1350014933
URL:
https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350014933
[2012-10-11 16:25:46] fel...@php.net
This is not a bug... but a feature request.
[2012-10-10 14:12:37] schicker03 at gmail dot com
Description:
As described in that link, class member access is available as of PHP 5.4
>>http://www.php.net/manual/en/migration54.new-features.php,
>>Class member access on instantiation has been added, e.g. (new Foo)->bar().
My PHP Version is 5.4.0 (not 5.4.7 like showing above, but there`s no choice
for
5.4.0 so I used 5.4.7)
See the sample script, why is that sample not working ?
(new Foo('bar'))();
I don´t know if this is really a bug, but i believe it should work.
best
schicker03
Test script:
---
bar = $bar;
}
/**
* @return null
*/
public function __invoke()
{
echo $this->bar;
}
}
//works as expected, using __invoke()
$foo = new Foo('bar');
$foo();
//works as expected, calling __invoke()
(new Foo('bar'))->__invoke();
//invalid, but why !? Should work from my point of view
(new Foo('bar'))();
Expected result:
Expected Result whould be the string bar 3 times:
barbarbar
--
Edit this bug report at https://bugs.php.net/bug.php?id=63253&edit=1
Req #63253 [PATCH]: class member access using __invoke() in php5.4
Edit report at https://bugs.php.net/bug.php?id=63253&edit=1
ID: 63253
Patch added by: larue...@php.net
Reported by:schicker03 at gmail dot com
Summary:class member access using __invoke() in php5.4
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: MacOSX 10.8
PHP Version:5.4.7
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63253.patch
Revision: 1350015317
URL:
https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350015317
Previous Comments:
[2012-10-12 04:09:27] larue...@php.net
An patch is attached, assign to me, will make a rfc later
[2012-10-12 04:08:53] larue...@php.net
The following patch has been added/updated:
Patch Name: bug63253.patch
Revision: 1350014933
URL:
https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350014933
[2012-10-11 16:25:46] fel...@php.net
This is not a bug... but a feature request.
[2012-10-10 14:12:37] schicker03 at gmail dot com
Description:
As described in that link, class member access is available as of PHP 5.4
>>http://www.php.net/manual/en/migration54.new-features.php,
>>Class member access on instantiation has been added, e.g. (new Foo)->bar().
My PHP Version is 5.4.0 (not 5.4.7 like showing above, but there`s no choice
for
5.4.0 so I used 5.4.7)
See the sample script, why is that sample not working ?
(new Foo('bar'))();
I don´t know if this is really a bug, but i believe it should work.
best
schicker03
Test script:
---
bar = $bar;
}
/**
* @return null
*/
public function __invoke()
{
echo $this->bar;
}
}
//works as expected, using __invoke()
$foo = new Foo('bar');
$foo();
//works as expected, calling __invoke()
(new Foo('bar'))->__invoke();
//invalid, but why !? Should work from my point of view
(new Foo('bar'))();
Expected result:
Expected Result whould be the string bar 3 times:
barbarbar
--
Edit this bug report at https://bugs.php.net/bug.php?id=63253&edit=1
Req #63253 [PATCH]: class member access using __invoke() in php5.4
Edit report at https://bugs.php.net/bug.php?id=63253&edit=1
ID: 63253
Patch added by: larue...@php.net
Reported by:schicker03 at gmail dot com
Summary:class member access using __invoke() in php5.4
Status: Open
Type: Feature/Change Request
Package:Scripting Engine problem
Operating System: MacOSX 10.8
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63253.patch
Revision: 1350014933
URL:
https://bugs.php.net/patch-display.php?bug=63253&patch=bug63253.patch&revision=1350014933
Previous Comments:
[2012-10-11 16:25:46] fel...@php.net
This is not a bug... but a feature request.
[2012-10-10 14:12:37] schicker03 at gmail dot com
Description:
As described in that link, class member access is available as of PHP 5.4
>>http://www.php.net/manual/en/migration54.new-features.php,
>>Class member access on instantiation has been added, e.g. (new Foo)->bar().
My PHP Version is 5.4.0 (not 5.4.7 like showing above, but there`s no choice
for
5.4.0 so I used 5.4.7)
See the sample script, why is that sample not working ?
(new Foo('bar'))();
I don´t know if this is really a bug, but i believe it should work.
best
schicker03
Test script:
---
bar = $bar;
}
/**
* @return null
*/
public function __invoke()
{
echo $this->bar;
}
}
//works as expected, using __invoke()
$foo = new Foo('bar');
$foo();
//works as expected, calling __invoke()
(new Foo('bar'))->__invoke();
//invalid, but why !? Should work from my point of view
(new Foo('bar'))();
Expected result:
Expected Result whould be the string bar 3 times:
barbarbar
--
Edit this bug report at https://bugs.php.net/bug.php?id=63253&edit=1
Bug #63219 [Com]: Segfault when aliasing trait method when autoloader throws excpetion
Edit report at https://bugs.php.net/bug.php?id=63219&edit=1
ID: 63219
Comment by: larue...@php.net
Reported by:maciej dot sz at gmail dot com
Summary:Segfault when aliasing trait method when autoloader
throws excpetion
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: 3.2.0-31-generic #50-Ubuntu
PHP Version:5.4Git-2012-10-04 (snap)
Block user comment: N
Private report: N
New Comment:
I think there is no need to call autoload in USE block, and it should check the
fetch result, I have attached a patch,
but I am not sure what the warning message should be...
Previous Comments:
[2012-10-05 01:56:09] larue...@php.net
The following patch has been added/updated:
Patch Name: bug63219.patch
Revision: 1349402169
URL:
https://bugs.php.net/patch-display.php?bug=63219&patch=bug63219.patch&revision=1349402169
[2012-10-04 18:43:59] maciej dot sz at gmail dot com
Description:
Class contains "use" statement of a trait. Method alias statement for that
trait contains a typo in the trait name. The autoloader throws exception and
then the segfault occurs.
(gdb) p zend_fetch_class(cur_method_ref->class_name, cur_method_ref->cname_len,
14)
$5 = (zend_class_entry *) 0x0
Test script:
---
---
file TFoo.php
inconsistent==HT_OK) {
(gdb) bt
#0 0x009863c8 in _zend_is_inconsistent (ht=0x28,
file=0xfb0948 "/home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c", line=969)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:54
#1 0x009890f5 in zend_hash_exists (ht=0x28, arKey=0x77fc5aa0
"foomethodd", nKeyLength=11)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:969
#2 0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4037
#3 0x00953a4a in zend_do_bind_traits (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4370
#4 0x009b79ee in ZEND_BIND_TRAITS_SPEC_HANDLER
(execute_data=0x77f88500)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1027
#5 0x009b42f6 in execute (op_array=0x77fc0da8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#6 0x009639b8 in zend_call_function (fci=0x7fffa1a0,
fci_cache=0x7fffa1f0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:958
#7 0x009956b5 in zend_call_method (object_pp=0x0, obj_ce=0x0,
fn_proxy=0x77fc41e0,
function_name=0x77fc17f8 "closure::__invoke\001", function_name_len=22,
retval_ptr_ptr=0x7fffa2e0, param_count=1, arg1=0x77fbf5d0, arg2=0x0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_interfaces.c:97
#8 0x007a087c in zif_spl_autoload_call (ht=1,
return_value=0x77fc40d8,
return_value_ptr=0x7fffa728, this_ptr=0x0, return_value_used=1)
at /home/maciek/Downloads/php-5.4.7/ext/spl/php_spl.c:436
#9 0x00963b92 in zend_call_function (fci=0x7fffa670,
fci_cache=0x7fffa6c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:980
#10 0x00964520 in zend_lookup_class_ex (name=0x77eb72f8 "bar\\C",
name_length=5,
key=0x77fc24d8, use_autoload=1, ce=0x7fffa7c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1127
#11 0x00965230 in zend_fetch_class_by_name (class_name=0x77eb72f8
"bar\\C",
class_name_len=5, key=0x77fc24d8, fetch_type=4)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1607
#12 0x009b8690 in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER
(execute_data=0x77f880e8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1173
#13 0x009b42f6 in execute (op_array=0x77fc04c8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#14 0x00976e13 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/maciek/Downloads/php-5.4.7/Zend/zend.c:1286
#15 0x008e9732 in php_execute_script (primary_file=0x7fffce40)
at /home/maciek/Downloads/php-5.4.7/main/main.c:2473
#16 0x00abfa95 in do_cli (argc=2, argv=0x7fffe228)
at /home/maciek/Downloads/php-5.4.7/sapi/cli/php_cli.c:988
#17 0x00ac0bce in main (argc=2, argv=0x7fffe228)
at /home/maciek/Downloads/php-5.4.7/sapi/cli/php_cli.c:1364
(gdb) f 2
#2 0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4037
4037method_exists =
zend_hash_exists(&cur_method_ref->ce->function_table,
(gd
Bug #63219 [PATCH]: Segfault when aliasing trait method when autoloader throws excpetion
Edit report at https://bugs.php.net/bug.php?id=63219&edit=1
ID: 63219
Patch added by: larue...@php.net
Reported by:maciej dot sz at gmail dot com
Summary:Segfault when aliasing trait method when autoloader
throws excpetion
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: 3.2.0-31-generic #50-Ubuntu
PHP Version:5.4Git-2012-10-04 (snap)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63219.patch
Revision: 1349402169
URL:
https://bugs.php.net/patch-display.php?bug=63219&patch=bug63219.patch&revision=1349402169
Previous Comments:
[2012-10-04 18:43:59] maciej dot sz at gmail dot com
Description:
Class contains "use" statement of a trait. Method alias statement for that
trait contains a typo in the trait name. The autoloader throws exception and
then the segfault occurs.
(gdb) p zend_fetch_class(cur_method_ref->class_name, cur_method_ref->cname_len,
14)
$5 = (zend_class_entry *) 0x0
Test script:
---
---
file TFoo.php
inconsistent==HT_OK) {
(gdb) bt
#0 0x009863c8 in _zend_is_inconsistent (ht=0x28,
file=0xfb0948 "/home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c", line=969)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:54
#1 0x009890f5 in zend_hash_exists (ht=0x28, arKey=0x77fc5aa0
"foomethodd", nKeyLength=11)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_hash.c:969
#2 0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4037
#3 0x00953a4a in zend_do_bind_traits (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4370
#4 0x009b79ee in ZEND_BIND_TRAITS_SPEC_HANDLER
(execute_data=0x77f88500)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1027
#5 0x009b42f6 in execute (op_array=0x77fc0da8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#6 0x009639b8 in zend_call_function (fci=0x7fffa1a0,
fci_cache=0x7fffa1f0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:958
#7 0x009956b5 in zend_call_method (object_pp=0x0, obj_ce=0x0,
fn_proxy=0x77fc41e0,
function_name=0x77fc17f8 "closure::__invoke\001", function_name_len=22,
retval_ptr_ptr=0x7fffa2e0, param_count=1, arg1=0x77fbf5d0, arg2=0x0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_interfaces.c:97
#8 0x007a087c in zif_spl_autoload_call (ht=1,
return_value=0x77fc40d8,
return_value_ptr=0x7fffa728, this_ptr=0x0, return_value_used=1)
at /home/maciek/Downloads/php-5.4.7/ext/spl/php_spl.c:436
#9 0x00963b92 in zend_call_function (fci=0x7fffa670,
fci_cache=0x7fffa6c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:980
#10 0x00964520 in zend_lookup_class_ex (name=0x77eb72f8 "bar\\C",
name_length=5,
key=0x77fc24d8, use_autoload=1, ce=0x7fffa7c0)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1127
#11 0x00965230 in zend_fetch_class_by_name (class_name=0x77eb72f8
"bar\\C",
class_name_len=5, key=0x77fc24d8, fetch_type=4)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_execute_API.c:1607
#12 0x009b8690 in ZEND_FETCH_CLASS_SPEC_CONST_HANDLER
(execute_data=0x77f880e8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:1173
#13 0x009b42f6 in execute (op_array=0x77fc04c8)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_vm_execute.h:410
#14 0x00976e13 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/maciek/Downloads/php-5.4.7/Zend/zend.c:1286
#15 0x008e9732 in php_execute_script (primary_file=0x7fffce40)
at /home/maciek/Downloads/php-5.4.7/main/main.c:2473
#16 0x00abfa95 in do_cli (argc=2, argv=0x7fffe228)
at /home/maciek/Downloads/php-5.4.7/sapi/cli/php_cli.c:988
#17 0x00ac0bce in main (argc=2, argv=0x7fffe228)
at /home/maciek/Downloads/php-5.4.7/sapi/cli/php_cli.c:1364
(gdb) f 2
#2 0x00952839 in zend_traits_init_trait_structures (ce=0x77fc5108)
at /home/maciek/Downloads/php-5.4.7/Zend/zend_compile.c:4037
4037method_exists =
zend_hash_exists(&cur_method_ref->ce->function_table,
(gdb) p *cur_method_ref
$1 = {method_name = 0x77fc1558 "fooMethod", mname_len = 10, ce = 0x0,
class_name = 0x77fc5798 "foo\\TFooo", cname_len = 9}
(gdb) p zend_fetch_class(cur_method_ref->class_name, cur_method_ref->cname_len,
14)
$2 = (zend_class_entr
[PHP-BUG] Bug #63184 [NEW]: test ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed
From: laruence Operating system: Linux PHP version: 5.4.7 Package: Testing related Bug Type: Bug Bug description:test ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed Description: test ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt failed Test script: --- ext/spl/tests/RecursiveDirectoryIterator_getSubPathname_basic.phpt Expected result: PASS Actual result: -- FAILED 002- . 003+ a0c967a6c2c34786e4802f59af9356f5 -- Edit bug report at https://bugs.php.net/bug.php?id=63184&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63184&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63184&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63184&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63184&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63184&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63184&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63184&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63184&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63184&r=support Expected behavior: https://bugs.php.net/fix.php?id=63184&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63184&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63184&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63184&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63184&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63184&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63184&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63184&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63184&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63184&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63184&r=mysqlcfg
Bug #63176 [PATCH]: Segmentation fault when instantiate 2 persistent PDO to the same db server
Edit report at https://bugs.php.net/bug.php?id=63176&edit=1
ID: 63176
Patch added by: larue...@php.net
Reported by:jrbasso at gmail dot com
Summary:Segmentation fault when instantiate 2 persistent PDO
to the same db server
Status: Open
Type: Bug
Package:PDO related
Operating System: Ubunt 12.04.1
PHP Version:5.4.7
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug63176.patch
Revision: 1348800472
URL:
https://bugs.php.net/patch-display.php?bug=63176&patch=bug63176.patch&revision=1348800472
Previous Comments:
[2012-09-28 02:10:28] jrbasso at gmail dot com
Description:
Download the PHP version 5.4.7, compiled with ./configure --enable-debug --with-
pdo-mysql --enable-pcntl
Run the test script and it gives a segmentation fault when the script finish.
If
I remove the attribute from PDO2 it works fine. If the persistent option is
disabled it works fine too.
gdb backtrace available on https://gist.github.com/3bda9d5253e7a86168e0
Test script:
---
db = new PDO2('mysql:host=localhost', 'root', 'root',
array(PDO::ATTR_PERSISTENT => true));
$this->db->query('SELECT 1')->fetchAll();
}
}
$a = new ModelA();
$b = new ModelA();
Expected result:
No segmentation fault
Actual result:
--
Segmentation fault (core dumped)
--
Edit this bug report at https://bugs.php.net/bug.php?id=63176&edit=1
[PHP-BUG] Req #63146 [NEW]: Use /dev/urandom as default random pool dev
From: laruence Operating system: Linux PHP version: 5.4.7 Package: mcrypt related Bug Type: Feature/Change Request Bug description:Use /dev/urandom as default random pool dev Description: Hey, mcrypt_create_iv use /dev/random as the default random dev, this will cause some unexpected issues for new users. see: " nils at nm dot cx 19-Jun-2012 12:26 If you use /dev/random you need a well filled entropy pool or the application will block until enough good entropy comes available " http://us.php.net/manual/en/function.mcrypt-create-iv.php Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=63146&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63146&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63146&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63146&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63146&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63146&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63146&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63146&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63146&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63146&r=support Expected behavior: https://bugs.php.net/fix.php?id=63146&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63146&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63146&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63146&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63146&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63146&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63146&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63146&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63146&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63146&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63146&r=mysqlcfg
Bug #60723 [PATCH]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723&edit=1 ID: 60723 Patch added by: larue...@php.net Reported by:olemarkus at gentoo dot org Summary:error_log error time has changed to UTC ignoring default timezo Status: Assigned Type: Bug Package:Date/time related Operating System: Gentoo Linux PHP Version:5.3.9 Assigned To:derick Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60723.patch Revision: 1348197432 URL: https://bugs.php.net/patch-display.php?bug=60723&patch=bug60723.patch&revision=1348197432 Previous Comments: [2012-09-21 03:01:45] larue...@php.net seems introduced after the fix of: https://bugs.php.net/bug.php?id=60373 [2012-09-20 12:47:26] wegan at americantextile dot com Also having this issue on 5.4.1 running on Windows 2008 R2. Very annoying! Wish I never upgraded us from 5.3.8!!! [2012-08-24 16:13:28] mike dot nicewarner at gmail dot com I'm using PHP 5.3.13 on Windows, and I'm also experiencing this annoying bug. Please, please fix it. I liked when it used the server timezone settings. [2012-08-24 14:31:35] martin dot marques at gmail dot com Is someone working on this? It's quite an annoying bug. [2012-07-20 03:06:13] ramsy at ramix dot jp Why is it neglected? The cause of this bug is specification change by the wrong bug fix method. 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=60723 -- Edit this bug report at https://bugs.php.net/bug.php?id=60723&edit=1
Bug #61442 [ReO->Csd]: exception threw in __autoload can not be catched
Edit report at https://bugs.php.net/bug.php?id=61442&edit=1
ID: 61442
User updated by:larue...@php.net
Reported by:larue...@php.net
Summary:exception threw in __autoload can not be catched
-Status: Re-Opened
+Status: Closed
Type: Bug
Package:SPL related
Operating System: Linux, FreeBSD
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=fd0b3ea663431b7adaedde11668fbc0b6ba07494
Log: Fixed bug #61442 (exception threw in __autoload can not be catched)
Previous Comments:
[2012-09-19 10:37:21] yks-uno at yandex dot ru
That is what it was all about.
Again sorry for resentment, thanks for clearing things up.
[2012-09-19 10:33:07] larue...@php.net
hmm, seems I thought wrongly,
try {
new ();
} catch () {
}
can be catched in 5.3
but
try {
AAA:xxx();
}
can not be catched in 5.3, but can be catched in 5.4.
[2012-09-19 10:09:14] larue...@php.net
and the 5.3.0+ seems should be 5.3+ (I mean 5.4 works fine).
[2012-09-19 10:03:24] larue...@php.net
http://us.php.net/autoload
"Note:
Prior to 5.3.0, exceptions thrown in the __autoload function could not be
caught
in the catch block and would result in a fatal error. From 5.3.0+ exceptions
thrown in the __autoload function can be caught in the catch block, with 1
provision. If throwing a custom exception, then the custom exception class must
be available. The __autoload function may be used recursively to autoload the
custom exception class."
[2012-09-19 08:54:26] yks-uno at yandex dot ru
And please would you mind to show the exact place in the PHP documentation
where it is stated that an autoload handler ALWAYS DIES regardless of
exceptions or substituting another class if it does not find the class it is
trying to load?
Or there is "no information available, might only be in SVN" ???
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=61442
--
Edit this bug report at https://bugs.php.net/bug.php?id=61442&edit=1
Bug #63093 [Opn->Csd]: Segfault while load extension failed in zts-build
Edit report at https://bugs.php.net/bug.php?id=63093&edit=1 ID: 63093 User updated by:larue...@php.net Reported by:larue...@php.net Summary:Segfault while load extension failed in zts-build -Status: Open +Status: Closed Type: Bug Package:*General Issues PHP Version:5.3.17 Block user comment: N Private report: N New Comment: Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=4c6678d6058fd740a9e186b49f9daa72d09ed300 Log: Fixed bug #63093 (Segfault while load extension failed in zts-build). Previous Comments: [2012-09-15 03:45:16] larue...@php.net Description: while a extension's deps is not meet, the extension will not be loaded successfully, and will try to unloaded it. then in ZTS build , segfault! [Sat Sep 15 11:44:44 2012] PHP Warning: Cannot load module 'mysql' because required module 'mysqlnd' is not loaded in Unknown on line 0 Warning: Cannot load module 'mysql' because required module 'mysqlnd' is not loaded in Unknown on line 0 Segmentation fault (core dumped) (gdb) bt #0 0x00305447270e in free () from /lib64/libc.so.6 #1 0x007fe964 in ts_free_id (id=0) at /home/huixinchen/opensource/php- 5.4/TSRM/TSRM.c:548 #2 0x008ce251 in module_destructor (module=0x3d9e280) at /home/huixinchen/opensource/php-5.4/Zend/zend_API.c:2268 #3 0x008d70b1 in zend_hash_apply_deleter (ht=0x11a7960, p=0x3d9e220) at /home/huixinchen/opensource/php-5.4/Zend/zend_hash.c:650 #4 0x008d7322 in zend_hash_apply (ht=0x11a7960, apply_func=0x8cb75b , tsrm_ls=0x3d1a500) at /home/huixinchen/opensource/php-5.4/Zend/zend_hash.c:719 #5 0x008cbf48 in zend_startup_modules (tsrm_ls=0x3d1a500) at /home/huixinchen/opensource/php-5.4/Zend/zend_API.c:1788 #6 0x008085ab in php_module_startup (sf=0x11900a0, additional_modules=0x118ffe0, num_additional_modules=1) at /home/huixinchen/opensource/php-5.4/main/main.c:2191 #7 0x00a4ade5 in sapi_cli_server_startup (sapi_module=0x11900a0) at /home/huixinchen/opensource/php-5.4/sapi/cli/php_cli_server.c:436 #8 0x00a45816 in main (argc=3, argv=0x7fff50b3d948) at /home/huixinchen/opensource/php-5.4/sapi/cli/php_cli.c:1344 Test script: --- none Expected result: none Actual result: -- none -- Edit this bug report at https://bugs.php.net/bug.php?id=63093&edit=1
[PHP-BUG] Bug #63093 [NEW]: Segfault while load extension failed in zts-build
From: laruence Operating system: PHP version: 5.3.17 Package: *General Issues Bug Type: Bug Bug description:Segfault while load extension failed in zts-build Description: while a extension's deps is not meet, the extension will not be loaded successfully, and will try to unloaded it. then in ZTS build , segfault! [Sat Sep 15 11:44:44 2012] PHP Warning: Cannot load module 'mysql' because required module 'mysqlnd' is not loaded in Unknown on line 0 Warning: Cannot load module 'mysql' because required module 'mysqlnd' is not loaded in Unknown on line 0 Segmentation fault (core dumped) (gdb) bt #0 0x00305447270e in free () from /lib64/libc.so.6 #1 0x007fe964 in ts_free_id (id=0) at /home/huixinchen/opensource/php- 5.4/TSRM/TSRM.c:548 #2 0x008ce251 in module_destructor (module=0x3d9e280) at /home/huixinchen/opensource/php-5.4/Zend/zend_API.c:2268 #3 0x008d70b1 in zend_hash_apply_deleter (ht=0x11a7960, p=0x3d9e220) at /home/huixinchen/opensource/php-5.4/Zend/zend_hash.c:650 #4 0x008d7322 in zend_hash_apply (ht=0x11a7960, apply_func=0x8cb75b , tsrm_ls=0x3d1a500) at /home/huixinchen/opensource/php-5.4/Zend/zend_hash.c:719 #5 0x008cbf48 in zend_startup_modules (tsrm_ls=0x3d1a500) at /home/huixinchen/opensource/php-5.4/Zend/zend_API.c:1788 #6 0x008085ab in php_module_startup (sf=0x11900a0, additional_modules=0x118ffe0, num_additional_modules=1) at /home/huixinchen/opensource/php-5.4/main/main.c:2191 #7 0x00a4ade5 in sapi_cli_server_startup (sapi_module=0x11900a0) at /home/huixinchen/opensource/php-5.4/sapi/cli/php_cli_server.c:436 #8 0x00a45816 in main (argc=3, argv=0x7fff50b3d948) at /home/huixinchen/opensource/php-5.4/sapi/cli/php_cli.c:1344 Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=63093&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63093&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63093&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63093&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63093&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63093&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63093&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63093&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63093&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63093&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63093&r=support Expected behavior: https://bugs.php.net/fix.php?id=63093&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63093&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63093&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63093&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63093&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63093&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63093&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63093&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63093&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63093&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63093&r=mysqlcfg
Bug #62901 [Com]: foreach unexpectedly advances the internal array pointer
Edit report at https://bugs.php.net/bug.php?id=62901&edit=1 ID: 62901 Comment by: larue...@php.net Reported by:david at grudl dot com Summary:foreach unexpectedly advances the internal array pointer Status: Not a bug Type: Bug Package:Variables related PHP Version:5.4.6 Block user comment: N Private report: N New Comment: s ,write on copy, copy on write, ;< Previous Comments: [2012-09-13 02:44:38] larue...@php.net the same, although it is *copy* of a array, but still the same zval, PHP using "write on copy". but the internalPointer's change is not considered as "write" here. [2012-09-13 01:51:19] david at grudl dot com The point is: the iteration is not started on $this->arr, but it is started on array returned from method getArr(). Foreach resets internal array pointer of completely different array. ---- [2012-08-24 02:51:39] larue...@php.net "When foreach first starts executing, the internal array pointer is automatically reset to the first element of the array. " that means foreach change the internal potinter of an array. http://us3.php.net/manual/en/control-structures.foreach.php [2012-08-24 01:27:07] david at grudl dot com Maybe this is not a bug, but i have read documentations carefully and there is nothing about this. Could you send a link? And one question: why function reset() uses reference, if there is no need to use reference to advance internal array pointer? -------- [2012-08-23 15:37:32] larue...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php please see the note at : http://us3.php.net/manual/en/control- structures.foreach.php 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=62901 -- Edit this bug report at https://bugs.php.net/bug.php?id=62901&edit=1
Bug #63066 [Com]: Calling an undefined method in a generator results in a seg fault
Edit report at https://bugs.php.net/bug.php?id=63066&edit=1 ID: 63066 Comment by: larue...@php.net Reported by:Jared dot Williams1 at ntlworld dot com Summary:Calling an undefined method in a generator results in a seg fault Status: Assigned Type: Bug Package:Class/Object related Operating System: Linux ubuntu 3.5.0-14-generic #1 PHP Version:master-Git-2012-09-11 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: a quick fix made, and attached, hope that will help. Previous Comments: [2012-09-11 15:27:58] larue...@php.net The following patch has been added/updated: Patch Name: bug63066.patch Revision: 1347377278 URL: https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278 [2012-09-11 15:12:54] larue...@php.net nikic, while method is not exists, then the EX(object)'s refcount will not be increased.. then this object will be dtor in genertor_close, and then the arguments of previous exeucte_data clean up.. nikic, please look at this. thanks [2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com Backtrace of the NON debug seg fault... jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done. (gdb) run fatalSegFault.php Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php foo PHP Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Program received signal SIGSEGV, Segmentation fault. 0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8) at /home/jared/Development/php-src/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8) at /home/jared/Development/php-src/Zend/zend_gc.c:143 #1 0x006f6246 in zend_generator_close (generator=generator@entry=0x77fce180, finished_execution=finished_execution@entry=0 '\000') at /home/jared/Development/php-src/Zend/zend_generators.c:148 #2 0x006f63cb in zend_generator_free_storage (generator=0x77fce180) at /home/jared/Development/php-src/Zend/zend_generators.c:181 #3 0x006fc0a8 in zend_objects_store_free_object_storage ( objects=0xdbae60 ) at /home/jared/Development/php-src/Zend/zend_objects_API.c:92 #4 0x006c7153 in shutdown_executor () at /home/jared/Development/php-src/Zend/zend_execute_API.c:298 #5 0x006d5646 in zend_deactivate () at /home/jared/Development/php-src/Zend/zend.c:938 #6 0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0) at /home/jared/Development/php-src/main/main.c:1780 #7 0x00781fe0 in do_cli (argc=2, argv=0x7fffe118) at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171 #8 0x0042d56b in main (argc=2, argv=0x7fffe118) at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364 [2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com It appears that the seg fault doesn't appear in debug builds. Recompiled without debug again, and the seg fault is still present jared@ubuntu:~$ php -v PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies jared@ubuntu:~$ php fatalSegFault.php foo PHP Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php foo PHP Fat
Bug #63066 [PATCH]: Calling an undefined method in a generator results in a seg fault
Edit report at https://bugs.php.net/bug.php?id=63066&edit=1 ID: 63066 Patch added by: larue...@php.net Reported by:Jared dot Williams1 at ntlworld dot com Summary:Calling an undefined method in a generator results in a seg fault Status: Assigned Type: Bug Package:Class/Object related Operating System: Linux ubuntu 3.5.0-14-generic #1 PHP Version:master-Git-2012-09-11 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63066.patch Revision: 1347377278 URL: https://bugs.php.net/patch-display.php?bug=63066&patch=bug63066.patch&revision=1347377278 Previous Comments: [2012-09-11 15:12:54] larue...@php.net nikic, while method is not exists, then the EX(object)'s refcount will not be increased.. then this object will be dtor in genertor_close, and then the arguments of previous exeucte_data clean up.. nikic, please look at this. thanks [2012-09-11 13:50:49] Jared dot Williams1 at ntlworld dot com Backtrace of the NON debug seg fault... jared@ubuntu:~$ gdb ./Development/php-src/sapi/cli/php GNU gdb (GDB) 7.5-ubuntu Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /home/jared/Development/php-src/sapi/cli/php...done. (gdb) run fatalSegFault.php Starting program: /home/jared/Development/php-src/sapi/cli/php fatalSegFault.php foo PHP Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Program received signal SIGSEGV, Segmentation fault. 0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8) at /home/jared/Development/php-src/Zend/zend_gc.c:143 143 GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv); (gdb) bt #0 0x006f36b2 in gc_zval_possible_root (zv=0x77fcafd8) at /home/jared/Development/php-src/Zend/zend_gc.c:143 #1 0x006f6246 in zend_generator_close (generator=generator@entry=0x77fce180, finished_execution=finished_execution@entry=0 '\000') at /home/jared/Development/php-src/Zend/zend_generators.c:148 #2 0x006f63cb in zend_generator_free_storage (generator=0x77fce180) at /home/jared/Development/php-src/Zend/zend_generators.c:181 #3 0x006fc0a8 in zend_objects_store_free_object_storage ( objects=0xdbae60 ) at /home/jared/Development/php-src/Zend/zend_objects_API.c:92 #4 0x006c7153 in shutdown_executor () at /home/jared/Development/php-src/Zend/zend_execute_API.c:298 #5 0x006d5646 in zend_deactivate () at /home/jared/Development/php-src/Zend/zend.c:938 #6 0x0067641d in php_request_shutdown (dummy=dummy@entry=0x0) at /home/jared/Development/php-src/main/main.c:1780 #7 0x00781fe0 in do_cli (argc=2, argv=0x7fffe118) at /home/jared/Development/php-src/sapi/cli/php_cli.c:1171 #8 0x0042d56b in main (argc=2, argv=0x7fffe118) at /home/jared/Development/php-src/sapi/cli/php_cli.c:1364 [2012-09-11 13:46:20] Jared dot Williams1 at ntlworld dot com It appears that the seg fault doesn't appear in debug builds. Recompiled without debug again, and the seg fault is still present jared@ubuntu:~$ php -v PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:25:38) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies jared@ubuntu:~$ php fatalSegFault.php foo PHP Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 jared@ubuntu:~$ ./Development/php-src/sapi/cli/php -v PHP 5.5.0-dev (cli) (built: Sep 11 2012 14:41:40) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.5.0-dev, Copyright (c) 1998-2012 Zend Technologies jared@ubuntu:~$ ./Development/php-src/sapi/cli/php fatalSegFault.php foo PHP Fatal error: Call to undefined method stdClass::fatalError() in /home/jared/fatalSegFault.php on line 6 Fatal error: Call to undefined method stdClass::f
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1
ID: 62991
Patch added by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62991.phpt
Revision: 1346586639
URL:
https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.phpt&revision=1346586639
Previous Comments:
[2012-09-02 11:46:56] larue...@php.net
a new patch has been attached, fixed the memleak issue, but the way is a little
tricky, used the op_array->reserved fields.
so I attached it here instead of ci it, wait for if we can find a better way
[2012-09-02 11:45:06] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346586306
URL:
https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346586306
[2012-09-02 11:24:00] larue...@php.net
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data->op_array->fn_flags & ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data->op_array);
+ efree(execute_data->op_array);
+ }
would be written as:
+ if (op_array->fn_flags & ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data->op_array, so it's
a bit shorter to use ;)
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1
ID: 62991
Patch added by: larue...@php.net
Reported by:softwareelves at gmail dot com
Summary:Segfault with generator and closure.
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: Mac OSx 10.8.1
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346586306
URL:
https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346586306
Previous Comments:
[2012-09-02 11:24:00] larue...@php.net
okey, but is there a way to find out that whether a generator has been run once?
leaks reporting if the closure didn't run.
[2012-09-02 10:26:03] ni...@php.net
Oh, and also, I think it would be a little bit nicer if this:
+ if (execute_data->op_array->fn_flags & ZEND_ACC_CLOSURE) {
+ destroy_op_array(execute_data->op_array);
+ efree(execute_data->op_array);
+ }
would be written as:
+ if (op_array->fn_flags & ZEND_ACC_CLOSURE) {
+ destroy_op_array(op_array);
+ efree(op_array);
+ }
There already is a local op_array variable for execute_data->op_array, so it's
a bit shorter to use ;)
[2012-09-02 10:23:04] ni...@php.net
@laruence: The patch looks fine for me.
The only thing that looks strange are these whitespace changes:
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bindto, 0, 0, 1)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
+ ZEND_BEGIN_ARG_INFO_EX(arginfo_closure_bind, 0, 0, 2)
ZEND_ARG_INFO(0, closure)
ZEND_ARG_INFO(0, newthis)
ZEND_ARG_INFO(0, newscope)
ZEND_END_ARG_INFO()
-static const zend_function_entry closure_functions[] = {
- ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
- ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
- ZEND_MALIAS(Closure, bindTo, bind, arginfo_closure_bindto,
ZEND_ACC_PUBLIC)
- {NULL, NULL, NULL}
-};
+ static const zend_function_entry closure_functions[] = {
+ ZEND_ME(Closure, __construct, NULL, ZEND_ACC_PRIVATE)
+ ZEND_ME(Closure, bind, arginfo_closure_bind,
ZEND_ACC_PUBLIC|ZEND_ACC_STATIC)
+ ZEND_MALIAS(Closure, bindTo, bind,
arginfo_closure_bindto, ZEND_ACC_PUBLIC)
+ {NULL, NULL, NULL}
+ };
Looks like the indentation is slightly off there :)
--------
[2012-09-02 09:58:39] larue...@php.net
update patch, fix tabs
--------
[2012-09-02 09:58:16] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62991.patch
Revision: 1346579896
URL:
https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579896
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=62991
--
Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Bug #62991 [Com]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1 ID: 62991 Comment by: larue...@php.net Reported by:softwareelves at gmail dot com Summary:Segfault with generator and closure. Status: Assigned Type: Bug Package:Reproducible crash Operating System: Mac OSx 10.8.1 PHP Version:master-Git-2012-09-02 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: update patch, fix tabs Previous Comments: [2012-09-02 09:58:16] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346579896 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579896 [2012-09-02 09:55:35] larue...@php.net I got a fix for this. nikic, could you please review this? thanks [2012-09-02 09:54:55] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346579695 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579695 [2012-09-02 08:25:57] larue...@php.net seems the closure has been released after it was executed while destruct the outter scope.. [2012-09-02 01:58:12] softwareelves at gmail dot com Description: If you create a generator-closure inside of a function and call that function before returning it, it'll cause memory corruption causing a segfault. Test script: --- int(1) [1]=> int(2) [2]=> int(3) } Actual result: -- Segmentation fault: 11 -- Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1 ID: 62991 Patch added by: larue...@php.net Reported by:softwareelves at gmail dot com Summary:Segfault with generator and closure. Status: Assigned Type: Bug Package:Reproducible crash Operating System: Mac OSx 10.8.1 PHP Version:master-Git-2012-09-02 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346579896 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579896 Previous Comments: [2012-09-02 09:55:35] larue...@php.net I got a fix for this. nikic, could you please review this? thanks [2012-09-02 09:54:55] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346579695 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579695 [2012-09-02 08:25:57] larue...@php.net seems the closure has been released after it was executed while destruct the outter scope.. [2012-09-02 01:58:12] softwareelves at gmail dot com Description: If you create a generator-closure inside of a function and call that function before returning it, it'll cause memory corruption causing a segfault. Test script: --- int(1) [1]=> int(2) [2]=> int(3) } Actual result: -- Segmentation fault: 11 -- Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Bug #62991 [Com]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1 ID: 62991 Comment by: larue...@php.net Reported by:softwareelves at gmail dot com Summary:Segfault with generator and closure. Status: Assigned Type: Bug Package:Reproducible crash Operating System: Mac OSx 10.8.1 PHP Version:master-Git-2012-09-02 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: I got a fix for this. nikic, could you please review this? thanks Previous Comments: [2012-09-02 09:54:55] larue...@php.net The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346579695 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579695 [2012-09-02 08:25:57] larue...@php.net seems the closure has been released after it was executed while destruct the outter scope.. [2012-09-02 01:58:12] softwareelves at gmail dot com Description: If you create a generator-closure inside of a function and call that function before returning it, it'll cause memory corruption causing a segfault. Test script: --- int(1) [1]=> int(2) [2]=> int(3) } Actual result: -- Segmentation fault: 11 -- Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Bug #62991 [PATCH]: Segfault with generator and closure.
Edit report at https://bugs.php.net/bug.php?id=62991&edit=1 ID: 62991 Patch added by: larue...@php.net Reported by:softwareelves at gmail dot com Summary:Segfault with generator and closure. Status: Assigned Type: Bug Package:Reproducible crash Operating System: Mac OSx 10.8.1 PHP Version:master-Git-2012-09-02 (Git) Assigned To:nikic Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug62991.patch Revision: 1346579695 URL: https://bugs.php.net/patch-display.php?bug=62991&patch=bug62991.patch&revision=1346579695 Previous Comments: [2012-09-02 08:25:57] larue...@php.net seems the closure has been released after it was executed while destruct the outter scope.. [2012-09-02 01:58:12] softwareelves at gmail dot com Description: If you create a generator-closure inside of a function and call that function before returning it, it'll cause memory corruption causing a segfault. Test script: --- int(1) [1]=> int(2) [2]=> int(3) } Actual result: -- Segmentation fault: 11 -- Edit this bug report at https://bugs.php.net/bug.php?id=62991&edit=1
Req #62994 [Com]: Disallow some magic methods been generators
Edit report at https://bugs.php.net/bug.php?id=62994&edit=1
ID: 62994
Comment by: larue...@php.net
Reported by:reeze dot xia at gmail dot com
Summary:Disallow some magic methods been generators
Status: Assigned
Type: Feature/Change Request
Package:Scripting Engine problem
PHP Version:master-Git-2012-09-02 (Git)
Assigned To:nikic
Block user comment: N
Private report: N
New Comment:
it's not about magic methods, it's about the calling to user function in
internal
should be changed properly.
I don't think disallow is a good solution.
nikic, cannot yield simply be considered as return in such situation ?
Previous Comments:
[2012-09-02 07:46:53] reeze dot xia at gmail dot com
Description:
magic method are called in a special way, if those methods
was defined as generator, most of them will not work as expected.
We could disallow them when compiling.
Test script:
---
class A {
public function __construct(array $data) {
$this->initData = $data;
// maybe more initialization...
var_dump($this->initData);
foreach$(this->initData as $v) {
yield $v;
}
}
}
$a = new A(array(1, 2)); // constructor didn't get called.
so does the that magic methods:
http://www.php.net/manual/en/language.oop5.magic.php
most of them are meanning less if they are generators.
*some of them* maybe useful if they return value but not void.
Those could be allowed: __call(), __callStatic(), __get(), __invoke()
but those seems meaningless to be generators
__construct(), __destruct(), __set(), __isset(), __unset(), __sleep(),
__wakeup(), __toString(), __set_state() and __clone(),
--
Edit this bug report at https://bugs.php.net/bug.php?id=62994&edit=1
Bug #62985 [PATCH]: set_exception_handler doesn't work from command line
Edit report at https://bugs.php.net/bug.php?id=62985&edit=1
ID: 62985
Patch added by: larue...@php.net
Reported by:lgandras at gmail dot com
Summary:set_exception_handler doesn't work from command line
Status: Open
Type: Bug
Package:*Configuration Issues
Operating System: CentoOS 6.2 x64
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62985.patch
Revision: 1346434197
URL:
https://bugs.php.net/patch-display.php?bug=62985&patch=bug62985.patch&revision=1346434197
Previous Comments:
[2012-08-31 17:28:35] larue...@php.net
a quick fix has been attached. but it is a change of zend API, so maybe someone
else will have objections
[2012-08-31 17:25:47] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62985.patch
Revision: 1346433947
URL:
https://bugs.php.net/patch-display.php?bug=62985&patch=bug62985.patch&revision=1346433947
[2012-08-31 16:40:05] lgandras at gmail dot com
Description:
This is the output of my console:
# /usr/local/bin/php -v
PHP 5.3.16 (cli) (built: Aug 30 2012 18:38:54)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
# /usr/local/bin/php -r 'set_exception_handler(function(){echo
"catched\n";});throw new Exception;'
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
root@vps:~#
Test script:
---
# /usr/local/bin/php -r 'set_exception_handler(function($e){echo
"catched!\n";});throw new Exception;'
Expected result:
catched!
Actual result:
--
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=62985&edit=1
Bug #62985 [Com]: set_exception_handler doesn't work from command line
Edit report at https://bugs.php.net/bug.php?id=62985&edit=1
ID: 62985
Comment by: larue...@php.net
Reported by:lgandras at gmail dot com
Summary:set_exception_handler doesn't work from command line
Status: Open
Type: Bug
Package:*Configuration Issues
Operating System: CentoOS 6.2 x64
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
a quick fix has been attached. but it is a change of zend API, so maybe someone
else will have objections
Previous Comments:
[2012-08-31 17:25:47] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62985.patch
Revision: 1346433947
URL:
https://bugs.php.net/patch-display.php?bug=62985&patch=bug62985.patch&revision=1346433947
[2012-08-31 16:40:05] lgandras at gmail dot com
Description:
This is the output of my console:
# /usr/local/bin/php -v
PHP 5.3.16 (cli) (built: Aug 30 2012 18:38:54)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
# /usr/local/bin/php -r 'set_exception_handler(function(){echo
"catched\n";});throw new Exception;'
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
root@vps:~#
Test script:
---
# /usr/local/bin/php -r 'set_exception_handler(function($e){echo
"catched!\n";});throw new Exception;'
Expected result:
catched!
Actual result:
--
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=62985&edit=1
Bug #62985 [PATCH]: set_exception_handler doesn't work from command line
Edit report at https://bugs.php.net/bug.php?id=62985&edit=1
ID: 62985
Patch added by: larue...@php.net
Reported by:lgandras at gmail dot com
Summary:set_exception_handler doesn't work from command line
Status: Open
Type: Bug
Package:*Configuration Issues
Operating System: CentoOS 6.2 x64
PHP Version:5.3.16
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62985.patch
Revision: 1346433947
URL:
https://bugs.php.net/patch-display.php?bug=62985&patch=bug62985.patch&revision=1346433947
Previous Comments:
[2012-08-31 16:40:05] lgandras at gmail dot com
Description:
This is the output of my console:
# /usr/local/bin/php -v
PHP 5.3.16 (cli) (built: Aug 30 2012 18:38:54)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
# /usr/local/bin/php -r 'set_exception_handler(function(){echo
"catched\n";});throw new Exception;'
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
root@vps:~#
Test script:
---
# /usr/local/bin/php -r 'set_exception_handler(function($e){echo
"catched!\n";});throw new Exception;'
Expected result:
catched!
Actual result:
--
Fatal error: Uncaught exception 'Exception' in Command line code on line 1
Exception: in Command line code on line 1
Call Stack:
0.0002 632056 1. {main}() Command line code:0
--
Edit this bug report at https://bugs.php.net/bug.php?id=62985&edit=1
Bug #62977 [PATCH]: array_unique() misbehaves with array of DateTimes
Edit report at https://bugs.php.net/bug.php?id=62977&edit=1
ID: 62977
Patch added by: larue...@php.net
Reported by:ladislav at marek dot su
Summary:array_unique() misbehaves with array of DateTimes
Status: Assigned
Type: Bug
Package:Class/Object related
Operating System: Linux
PHP Version:5.4Git-2012-08-30 (Git)
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62977.patch
Revision: 1346341925
URL:
https://bugs.php.net/patch-display.php?bug=62977&patch=bug62977.patch&revision=1346341925
Previous Comments:
[2012-08-30 13:24:49] ladislav at marek dot su
Description:
array_unique() returns duplicates for array which contains objects with
DateTime
instances.
Test script:
---
dt = $dt;
}
}
$foo = new Foo(new DateTime);
$std = new stdClass;
$arr = [$foo, $foo, $std, $std, $std];
var_dump(array_unique($arr, SORT_REGULAR));
Expected result:
array(4) {
[0]=>
object(Foo)#1 (1) {
["dt"]=>
object(DateTime)#2 (3) {
["date"]=>
string(19) "2012-08-30 15:18:01"
["timezone_type"]=>
int(3)
["timezone"]=>
string(13) "Europe/Prague"
}
}
[2]=>
object(stdClass)#3 (0) {
}
}
Actual result:
--
array(4) {
[0]=>
object(Foo)#1 (1) {
["dt"]=>
object(DateTime)#2 (3) {
["date"]=>
string(19) "2012-08-30 15:18:01"
["timezone_type"]=>
int(3)
["timezone"]=>
string(13) "Europe/Prague"
}
}
[1]=>
object(Foo)#1 (1) {
["dt"]=>
object(DateTime)#2 (3) {
["date"]=>
string(19) "2012-08-30 15:18:01"
["timezone_type"]=>
int(3)
["timezone"]=>
string(13) "Europe/Prague"
}
}
[2]=>
object(stdClass)#3 (0) {
}
[4]=>
object(stdClass)#3 (0) {
}
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=62977&edit=1
[PHP-BUG] Bug #62925 [NEW]: some issues while --enable-intl
From: laruence Operating system: PHP version: Irrelevant Package: I18N and L10N related Bug Type: Bug Bug description:some issues while --enable-intl Description: 1. php-trunk branch build failed: source/trunk/ext/intl/dateformat/dateformat_format_object.cpp -o ext/intl/dateformat/dateformat_format_object.o /home/huixinchen/opensource/trunk/ext/intl/dateformat/dateformat_format_object.c pp:42: error: âkFullRelativeâ is not a member of âicu_3_6::DateFormatâ /home/huixinchen/opensource/trunk/ext/intl/dateformat/dateformat_format_object.c pp:43: error: âkLongRelativeâ is not a member of âicu_3_6::DateFormatâ /home/huixinchen/opensource/trunk/ext/intl/dateformat/dateformat_format_object.c pp:44: error: âkMediumRelativeâ is not a member of âicu_3_6::DateFormatâ 2. coding standard: I am not sure, whether the c99 comment is okey, and no footer in source codes 3. test failed , in 5.4-zts, there are some tests failed = FAILED TEST SUMMARY - Bug #62082: Memory corruption in internal get_icu_disp_value_src_php() [ext/intl/tests/bug62082.phpt] Cloning datefmt icu <= 4.2 [ext/intl/tests/dateformat_clone.phpt] datefmt_get_pattern_code and datefmt_set_pattern_code() icu <= 4.2 [ext/intl/tests/dateformat_get_set_pattern.phpt] datefmt_set_timezone_id_code() icu <= 4.2 [ext/intl/tests/dateformat_set_timezone_id.phpt] numfmt_format() icu <= 4.2 [ext/intl/tests/formatter_format.phpt] numfmt_format_currency() icu <= 4.2 [ext/intl/tests/formatter_format_currency.phpt] numfmt_get/set_attribute() [ext/intl/tests/formatter_get_set_attribute.phpt] grapheme() [ext/intl/tests/grapheme.phpt] = Test script: --- none Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=62925&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62925&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62925&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62925&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62925&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62925&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62925&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62925&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62925&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62925&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62925&r=support Expected behavior: https://bugs.php.net/fix.php?id=62925&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62925&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62925&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62925&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62925&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62925&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62925&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62925&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62925&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62925&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62925&r=mysqlcfg
[PHP-BUG] Bug #62907 [NEW]: Double free when use traits
From: laruence Operating system: PHP version: 5.4.6 Package: Scripting Engine problem Bug Type: Bug Bug description:Double free when use traits Description: This bug is related to #61998, but was spotting when I fixing the bug #62358, PS: it really tough to refine this reproduce script :) Test script: --- https://bugs.php.net/bug.php?id=62907&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62907&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62907&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62907&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62907&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62907&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62907&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62907&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62907&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62907&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62907&r=support Expected behavior: https://bugs.php.net/fix.php?id=62907&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62907&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62907&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62907&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62907&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62907&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62907&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62907&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62907&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62907&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62907&r=mysqlcfg
Bug #62874 [Com]: getDefaultValue() fails
Edit report at https://bugs.php.net/bug.php?id=62874&edit=1
ID: 62874
Comment by: larue...@php.net
Reported by:karsten at typo3 dot org
Summary:getDefaultValue() fails
Status: Feedback
Type: Bug
Package:Reflection related
Operating System: OS X
PHP Version:5.3.16
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
seems it already be fixed. please try with the 5.3-master snapshot
Previous Comments:
[2012-08-21 05:41:58] larue...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
[2012-08-20 14:27:41] karsten at typo3 dot org
You mean https://bugs.php.net/62715 - it brought me on track. I have a report
for
my test script ran on 5.4 that results in
https://gist.github.com/467127b13f987b1633d9, so it seems
isDefaultValueAvailable() returns false thereâ¦
[2012-08-20 14:04:10] larue...@php.net
hmm, I fixed a similar bug before, I still think it's a wrong usage..
however I will fix this later.
[2012-08-20 13:22:42] karsten at typo3 dot org
Description:
If isDefaultValueAvailable() returns TRUE I expect to be able to call
getDefaultValue()
Test script:
---
getMethods() as $method) {
foreach ($method->getParameters() as $p) {
echo $p->getName() . "\n";
echo " isDefaultValueAvailable: " .
var_export($p->isDefaultValueAvailable(), true) . "\n";
if ($p->isDefaultValueAvailable()) {
echo "default value: " .
var_export($p->getDefaultValue(), true) . "\n";
}
echo "isOptional: " . var_export($p->isOptional(), true) . "\n";
echo "allowsNull: " . var_export($p->allowsNull(), true) . "\n";
echo "\n";
}
}
?>
Expected result:
a
isDefaultValueAvailable: true
default value: NULL
isOptional: false
allowsNull: true
b
isDefaultValueAvailable: false
isOptional: false
allowsNull: true
c
isDefaultValueAvailable: true
default value: NULL
isOptional: true
allowsNull: true
Actual result:
--
a
isDefaultValueAvailable: true
Fatal error: Uncaught exception 'ReflectionException' with message 'Parameter
is
not optional' in test.php on line 12
ReflectionException: Parameter is not optional in test.php on line 12
Call Stack:
0.0010 646632 1. {main}() test.php:0
0.0011 651128 2. ReflectionParameter->getDefaultValue() test.php:12
--
Edit this bug report at https://bugs.php.net/bug.php?id=62874&edit=1
Bug #62737 [PATCH]: Segfault invoking SplFileInfo->openFile
Edit report at https://bugs.php.net/bug.php?id=62737&edit=1
ID: 62737
Patch added by: larue...@php.net
Reported by:leight at gmail dot com
Summary:Segfault invoking SplFileInfo->openFile
Status: Analyzed
Type: Bug
Package:Reproducible crash
Operating System: Linux / OSX
PHP Version:master-Git-2012-08-03 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62737.phpt
Revision: 1344093279
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.phpt&revision=1344093279
Previous Comments:
[2012-08-04 15:13:57] larue...@php.net
The following patch has been added/updated:
Patch Name: bug62737.patch
Revision: 1344093237
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.patch&revision=1344093237
[2012-08-04 02:58:23] larue...@php.net
I split the "dangling pointer" bug out to #62744, we can look at this one after
we
fixed that one.
----
[2012-08-03 16:27:55] larue...@php.net
Actually, I have improved the patch, and I don't know what's your test script?
get_class_vars("splFileObject")?
you can try with the new patch.
--------
[2012-08-03 16:23:54] larue...@php.net
sure, I am still working on this, thanks
--------
[2012-08-03 16:21:25] larue...@php.net
The following patch has been added/updated:
Patch Name: ChangeDisableClassHandler.patch
Revision: 1344010885
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=ChangeDisableClassHandler.patch&revision=1344010885
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=62737
--
Edit this bug report at https://bugs.php.net/bug.php?id=62737&edit=1
Bug #62737 [PATCH]: Segfault invoking SplFileInfo->openFile
Edit report at https://bugs.php.net/bug.php?id=62737&edit=1
ID: 62737
Patch added by: larue...@php.net
Reported by:leight at gmail dot com
Summary:Segfault invoking SplFileInfo->openFile
Status: Analyzed
Type: Bug
Package:Reproducible crash
Operating System: Linux / OSX
PHP Version:master-Git-2012-08-03 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug62737.patch
Revision: 1344093237
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=bug62737.patch&revision=1344093237
Previous Comments:
[2012-08-04 02:58:23] larue...@php.net
I split the "dangling pointer" bug out to #62744, we can look at this one after
we
fixed that one.
----
[2012-08-03 16:27:55] larue...@php.net
Actually, I have improved the patch, and I don't know what's your test script?
get_class_vars("splFileObject")?
you can try with the new patch.
--------
[2012-08-03 16:23:54] larue...@php.net
sure, I am still working on this, thanks
--------
[2012-08-03 16:21:25] larue...@php.net
The following patch has been added/updated:
Patch Name: ChangeDisableClassHandler.patch
Revision: 1344010885
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=ChangeDisableClassHandler.patch&revision=1344010885
[2012-08-03 15:43:01] reeze dot xia at gmail dot com
Hi,
by replace create_object function pointer and free function table
isn't enough, after apply the patch, I got this,
maybe more handlers need to be replaced and cleanup.
Fatal error: Uncaught exception 'RuntimeException' with message
'get_class_vars() expects exactly 1 parameter, 2 given' in
/Users/reeze/Opensource/php-test/php-src-5.3-dev/xx.php:6
Stack trace:
#0 [internal function]: SplFileObject->get_class_vars('/bin/ls', 'r')
#1 /Users/reeze/Opensource/php-test/php-src-5.3-dev/xx.php(6): SplFileInfo-
>openFile('r')
#2 {main}
thrown in /Users/reeze/Opensource/php-test/php-src-5.3-dev/xx.php on line 6
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=62737
--
Edit this bug report at https://bugs.php.net/bug.php?id=62737&edit=1
[PHP-BUG] Bug #62744 [NEW]: Wild pointers made by zend_disable_class
From: laruence Operating system: PHP version: 5.3.15 Package: Scripting Engine problem Bug Type: Bug Bug description:Wild pointers made by zend_disable_class Description: this bug is found by digging bug #62737 Extensions use zend_register_internal_class to register class, and they often preserved the return value and reuse that pointer instead of search in class table when that class will be used. but when user specific disable_classes in php.ini zend_disable_class will delete the corresponding class entry, then make the pointer which is preserved by extension become a wild pointer. http://lxr.php.net/xref/PHP_5_3/Zend/zend_API.c#2348 Test script: --- similar as #62733 Expected result: none Actual result: -- none -- Edit bug report at https://bugs.php.net/bug.php?id=62744&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62744&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62744&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62744&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62744&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62744&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62744&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62744&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62744&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62744&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62744&r=support Expected behavior: https://bugs.php.net/fix.php?id=62744&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62744&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62744&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62744&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62744&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62744&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62744&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62744&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62744&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62744&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62744&r=mysqlcfg
[PHP-BUG] Bug #62742 [NEW]: Memory leak in php -s while build with --enable-zend-multibyte
From: laruence
Operating system:
PHP version: 5.3.15
Package: Scripting Engine problem
Bug Type: Bug
Bug description:Memory leak in php -s while build with --enable-zend-multibyte
Description:
openFile
('r');
print_r($b);print_r(get_class_methods("SplFileObject"));$file = new SplFileObject(__FILE__);
var_dump
(get_class_vars("SplFileObject"));
[Sat Aug 4 01:12:37 2012] Script: '/tmp/1.php'
Zend/zend_language_scanner.l(714) : Freeing 0x091F3600 (201 bytes),
script=/tmp/1.php
[Sat Aug 4 01:12:37 2012] Script: '/tmp/1.php'
Zend/zend_language_scanner.l(288) : Freeing 0x091F3720 (202 bytes),
script=/tmp/1.php
=== Total 2 memory leaks detected ===
Test script:
---
a php script, whatever it is
Expected result:
no leak
Actual result:
--
mem leak
--
Edit bug report at https://bugs.php.net/bug.php?id=62742&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=62742&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=62742&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=62742&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=62742&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=62742&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=62742&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=62742&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=62742&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=62742&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=62742&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=62742&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=62742&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=62742&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=62742&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=62742&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=62742&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=62742&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=62742&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=62742&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=62742&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=62742&r=mysqlcfg
Bug #62737 [PATCH]: Segfault invoking SplFileInfo->openFile
Edit report at https://bugs.php.net/bug.php?id=62737&edit=1
ID: 62737
Patch added by: larue...@php.net
Reported by:leight at gmail dot com
Summary:Segfault invoking SplFileInfo->openFile
Status: Analyzed
Type: Bug
Package:Reproducible crash
Operating System: Linux / OSX
PHP Version:master-Git-2012-08-03 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: ChangeDisableClassHandler.patch
Revision: 1344010885
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=ChangeDisableClassHandler.patch&revision=1344010885
Previous Comments:
[2012-08-03 15:43:01] reeze dot xia at gmail dot com
Hi,
by replace create_object function pointer and free function table
isn't enough, after apply the patch, I got this,
maybe more handlers need to be replaced and cleanup.
Fatal error: Uncaught exception 'RuntimeException' with message
'get_class_vars() expects exactly 1 parameter, 2 given' in
/Users/reeze/Opensource/php-test/php-src-5.3-dev/xx.php:6
Stack trace:
#0 [internal function]: SplFileObject->get_class_vars('/bin/ls', 'r')
#1 /Users/reeze/Opensource/php-test/php-src-5.3-dev/xx.php(6): SplFileInfo-
>openFile('r')
#2 {main}
thrown in /Users/reeze/Opensource/php-test/php-src-5.3-dev/xx.php on line 6
--------
[2012-08-03 15:03:17] larue...@php.net
I have made a patch for this.
--------
[2012-08-03 15:02:48] larue...@php.net
The following patch has been added/updated:
Patch Name: ChangeDisableClassHandler.patch
Revision: 1344006168
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=ChangeDisableClassHandler.patch&revision=1344006168
--------
[2012-08-03 14:25:19] larue...@php.net
this is a very badly bug.
but I think it's not a spl issues, we should change the behavior of
zend_disable_class,
since for now, it will delete the class entry, which will make the class entry
pointer (preserved by extension) become a wild pointer..
dereference it is a undefined behavior, in this sense, segfault is lucky.
--------
[2012-08-03 14:12:33] larue...@php.net
I think this is not only splFileObject, many classes may has such issues.
(especially those who preserves their own class entry).
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=62737
--
Edit this bug report at https://bugs.php.net/bug.php?id=62737&edit=1
Bug #62737 [PATCH]: Segfault invoking SplFileInfo->openFile
Edit report at https://bugs.php.net/bug.php?id=62737&edit=1
ID: 62737
Patch added by: larue...@php.net
Reported by:leight at gmail dot com
Summary:Segfault invoking SplFileInfo->openFile
Status: Analyzed
Type: Bug
Package:Reproducible crash
Operating System: Linux / OSX
PHP Version:master-Git-2012-08-03 (Git)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: ChangeDisableClassHandler.patch
Revision: 1344006168
URL:
https://bugs.php.net/patch-display.php?bug=62737&patch=ChangeDisableClassHandler.patch&revision=1344006168
Previous Comments:
[2012-08-03 14:25:19] larue...@php.net
this is a very badly bug.
but I think it's not a spl issues, we should change the behavior of
zend_disable_class,
since for now, it will delete the class entry, which will make the class entry
pointer (preserved by extension) become a wild pointer..
dereference it is a undefined behavior, in this sense, segfault is lucky.
[2012-08-03 14:12:33] larue...@php.net
I think this is not only splFileObject, many classes may has such issues.
(especially those who preserves their own class entry).
[2012-08-03 11:06:18] leight at gmail dot com
Description:
When SplFileObject is on the disable_classes list, and SplFileInfo->openFile is
called, PHP crashes because there is no check on whether the SplFileObject
object
was actually created or not, before trying to use it.
The offending code is in ext/spl/spl_directory.c in
spl_filesystem_object_create_type
Test script:
---
openFile('r');
Expected result:
A message stating SplFileObject is disabled.
Actual result:
--
Segmentation fault
--
Edit this bug report at https://bugs.php.net/bug.php?id=62737&edit=1
[PHP-BUG] Bug #62615 [NEW]: test ext/curl/tests/curl_escape.phpt failed
From: laruence Operating system: PHP version: 5.4Git-2012-07-20 (Git) Package: cURL related Bug Type: Bug Bug description:test ext/curl/tests/curl_escape.phpt failed Description: seems the behavior is different in curl 7.15.5 curl cURL support => enabled cURL Information => 7.15.5 Test script: --- ext/curl/tests/curl_escape.phpt Expected result: test pass Actual result: -- 001+ string(40) "http%3A%2F%2Fwww%2Ephp%2Enet%2F%20%3F%21" 001- string(36) "http%3A%2F%2Fwww.php.net%2F%20%3F%21" -- Edit bug report at https://bugs.php.net/bug.php?id=62615&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=62615&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=62615&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=62615&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=62615&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=62615&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=62615&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=62615&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=62615&r=needscript Try newer version: https://bugs.php.net/fix.php?id=62615&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=62615&r=support Expected behavior: https://bugs.php.net/fix.php?id=62615&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=62615&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=62615&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=62615&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=62615&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=62615&r=dst IIS Stability: https://bugs.php.net/fix.php?id=62615&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=62615&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=62615&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=62615&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=62615&r=mysqlcfg
[PHP-BUG] Bug #62600 [NEW]: test failed ext/json/tests/pass001.1_64bit.phpt
From: laruence
Operating system: Linux
PHP version: 5.4Git-2012-07-18 (Git)
Package: Testing related
Bug Type: Bug
Bug description:test failed ext/json/tests/pass001.1_64bit.phpt
Description:
test failed ext/json/tests/pass001.1_64bit.phpt
Test script:
---
ext/json/tests/pass001.1_64bit.phpt
Expected result:
pass
Actual result:
--
423+
423- ["JSON Test Pattern pass1",{"object with 1 member":["array with 1
element"]},{},[],-42,true,false,null,
{"integer":1234567890,"real":-9876.54321,"e":1.23456789e-
13,"E":1.23456789e+34,"_empty_":0,"E no
.":4,"zero":0,"one":1,"space":"
","quote":"\"","backslash":"\\","controls":"\b\f\n\r\t","slash":"\/ &
\/","alpha":"abcdefghijklmnopqrstuvwyz","ALPHA":"ABCDEFGHIJKLMNOPQRSTUVWYZ","dig
it":"0123456789","special":"`1~!@#$%^&*()_+-={':[,]}|;.
<\/>?","hex":"\u0123\u4567\u89ab\ucdef\uabcd\uef4a","unicode":"\u30d7\u30ec\u30b
9\u30ad\u30c3\u30c8","\u30d7\u30ec\u30b9\u30ad\u30c3\u30c8":"\u30d7\u30ec\u30b9\
u30ad\u30c3\u30c8","empty_string":"","true":true,"false":false,"null":null,"arra
y":[],"object":{},"123":{"456":{"abc":{"789":"def","012":[1,2,"5",500],"ghi":
[1,2,"five",50,"sixty"]}}},"address":"50 St. James
Street","url":"http:\/\/www.JSON.org\/","comment":"\/\/ \/*
*\/":" "," s p a c e d
":[1,2,3,4,5,6,7],"compact":[1,2,3,4,5,6,7],"jsontext":"
{\"object with 1 member\":[\"array with 1 element\"]}","quotes":"" \"
%22
0x22 034
"","\/\\\"\ucafe\ubabe\uab98\ufcde\ubcda\uef4a\b\f\n\r\t`1~!@#$%^&*()_+-=[]
{}|;:',.\/<>?":"A key can be any string"},0.5,98.6,99.44,1066,"rosebud"]
425+
425- ["JSON Test Pattern pass1",{"object with 1 member":["array with 1
element"]},[],[],-42,true,false,null,
{"integer":1234567890,"real":-9876.54321,"e":1.23456789e-
13,"E":1.23456789e+34,"":0,"E no
.":4,"zero":0,"one":1,"space":"
","quote":"\"","backslash":"\\","controls":"\b\f\n\r\t","slash":"\/ &
\/","alpha":"abcdefghijklmnopqrstuvwyz","ALPHA":"ABCDEFGHIJKLMNOPQRSTUVWYZ","dig
it":"0123456789","special":"`1~!@#$%^&*()_+-={':[,]}|;.
<\/>?","hex":"\u0123\u4567\u89ab\ucdef\uabcd\uef4a","unicode":"\u30d7\u30ec\u30b
9\u30ad\u30c3\u30c8","\u30d7\u30ec\u30b9\u30ad\u30c3\u30c8":"\u30d7\u30ec\u30b9\
u30ad\u30c3\u30c8","empty_string":"","true":true,"false":false,"null":null,"arra
y":[],"object":[],"123":{"456":{"abc":{"789":"def","012":[1,2,"5",500],"ghi":
[1,2,"five",50,"sixty"]}}},"address":"50 St. James
Street","url":"http:\/\/www.JSON.org\/","comment":"\/\/ \/*
*\/":" "," s p a c e d
":[1,2,3,4,5,6,7],"compact":[1,2,3,4,5,6,7],"jsontext":"
{\"object with 1 member\":[\"array with 1 element\"]}","quotes":"" \"
%22
0x22 034
"","\/\\\"\ucafe\ubabe\uab98\ufcde\ubcda\uef4a\b\f\n\r\t`1~!@#$%^&*()_+-=[]
{}|;:',.\/<>?":"A key can be any string"},0.5,98.6,99.44,1066,"rosebud"]
427+ NULL
428+ DECODE AGAIN: AS ARRAY
429+ NULL
427- array(14) {
428- [0]=>
429- string(23) "JSON Test Pattern pass1"
430- [1]=>
431- object(stdClass)#%d (1) {
432- ["object with 1 member"]=>
433- array(1) {
434- [0]=>
435- string(20) "array with 1 element"
436- }
437- }
438- [2]=>
439- object(stdClass)#%d (0) {
440- }
441- [3]=>
442- array(0) {
443- }
444- [4]=>
445- int(-42)
446- [5]=>
447- bool(true)
448- [6]=>
449- bool(false)
450- [7]=>
451- NULL
452- [8]=>
453- object(stdClass)#%d (36) {
454- ["integer"]=>
455- int(1234567890)
456- ["real"]=>
457- float(-9876.54321)
458- ["e"]=>
459- float(1.23456789E-13)
460- ["E"]=>
461- float(1.23456789E+34)
462- ["_empty_"]=>
463- int(0)
464- ["E no ."]=>
465- int(4)
466- ["zero"]=>
467- int(0)
468- ["one"]=>
469- int(1)
470- ["space"]=>
471- string(1) " "
472- ["quote"]=>
473- string(1) """
474- ["backslash"]=>
475- string(1) "\"
476- ["controls"]=>
477- string(5) "
478-"
479- ["slash"]=>
480- string(5) "/ & /"
481- ["alpha"]=>
482- string(25) "abcdefghijklmnopqrstuvwyz"
483- ["ALPHA"]=>
484- string(25) "ABCDEFGHIJKLMNOPQRSTUVWYZ"
485- ["digit"]=>
486- string(10) "0123456789"
487- ["special"]=>
488- string(31) "`1~!@#$%^&*()_+-={':[,]}|;.?"
489- ["hex"]=>
490- string(17) "Ä£ä§è¦«ì·¯ê¯î½"
491- ["unicode"]=>
492- string(18) "ãã¬ã¹ããã"
493- ["ãã¬ã¹ããã"]=>
494- string(18) "ãã¬ã¹ããã"
495- ["empty_string"]=>
496- string(0) ""
497- ["true"]=>
498- bool(true)
499- ["false"]=>
500- bool(false)
501- ["null"]=>
502- NULL
503- ["array"]=>
504- array(0) {
505- }
506- ["object"]=>
507- object(stdClass)#%d (0) {
508- }
509- ["123"]=>
510- object(stdClass)#%d (1) {
511- ["456"]=>
512- object(stdClass)#%d (1) {
513- ["abc"]=>
514- object(stdClass)#%d (3) {
515- ["789"]=>
516- string(3) "def"
517-
