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
Req #60408 [PATCH]: Array/String element access on instantiation (same like class member in 5.4RC)
Edit report at https://bugs.php.net/bug.php?id=60408&edit=1 ID: 60408 Patch added by: larue...@php.net Reported by:bugzilla33 at gmail dot com Summary:Array/String element access on instantiation (same like class member in 5.4RC) Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.0RC2 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: req60408.patch Revision: 1322646333 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=req60408.patch&revision=1322646333 Previous Comments: [2011-11-30 08:55:21] larue...@php.net Dmitry, could you look at this please? thanks patch and test list in: https://wiki.php.net/rfc/constdereference All existing test passed. [2011-11-30 08:40:17] lunter at interia dot pl I'm all for it. example: short switch/case alternative -- is equivalent to long: [2011-11-30 07:47:07] bugzilla33 at gmail dot com /Summary change/ Array -> Array/String [2011-11-30 07:36:07] larue...@php.net support (of course). yes, but it need to be disscussd first ;) [2011-11-30 07:29:12] bugzilla33 at gmail dot com >> echo array(1, 2, 3)[0]; //output 1 >> echo "foobar"[2]; //output o >> echo "foobar"["foo"][0] // output f >> works. Excellent! Have you tested it with short array constructor? echo [1, 2, 3][0]; //output 1 Are there any opportunities to make it public in the final 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=60408 -- Edit this bug report at https://bugs.php.net/bug.php?id=60408&edit=1
Req #60408 [PATCH]: Array/String element access on instantiation (same like class member in 5.4RC)
Edit report at https://bugs.php.net/bug.php?id=60408&edit=1 ID: 60408 Patch added by: larue...@php.net Reported by:bugzilla33 at gmail dot com Summary:Array/String element access on instantiation (same like class member in 5.4RC) Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.0RC2 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: const_dereference_001.phpt Revision: 1322646369 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_001.phpt&revision=1322646369 Previous Comments: [2011-11-30 09:45:33] larue...@php.net The following patch has been added/updated: Patch Name: req60408.patch Revision: 1322646333 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=req60408.patch&revision=1322646333 [2011-11-30 08:55:21] larue...@php.net Dmitry, could you look at this please? thanks patch and test list in: https://wiki.php.net/rfc/constdereference All existing test passed. [2011-11-30 08:40:17] lunter at interia dot pl I'm all for it. example: short switch/case alternative -- is equivalent to long: [2011-11-30 07:47:07] bugzilla33 at gmail dot com /Summary change/ Array -> Array/String ---- [2011-11-30 07:36:07] larue...@php.net support (of course). yes, but it need to be disscussd first ;) 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=60408 -- Edit this bug report at https://bugs.php.net/bug.php?id=60408&edit=1
Req #60408 [PATCH]: Array/String element access on instantiation (same like class member in 5.4RC)
Edit report at https://bugs.php.net/bug.php?id=60408&edit=1 ID: 60408 Patch added by: larue...@php.net Reported by:bugzilla33 at gmail dot com Summary:Array/String element access on instantiation (same like class member in 5.4RC) Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.0RC2 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: const_dereference_003.phpt Revision: 1322646387 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_003.phpt&revision=1322646387 Previous Comments: [2011-11-30 09:46:09] larue...@php.net The following patch has been added/updated: Patch Name: const_dereference_001.phpt Revision: 1322646369 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_001.phpt&revision=1322646369 [2011-11-30 09:45:33] larue...@php.net The following patch has been added/updated: Patch Name: req60408.patch Revision: 1322646333 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=req60408.patch&revision=1322646333 ---- [2011-11-30 08:55:21] larue...@php.net Dmitry, could you look at this please? thanks patch and test list in: https://wiki.php.net/rfc/constdereference All existing test passed. [2011-11-30 08:40:17] lunter at interia dot pl I'm all for it. example: short switch/case alternative -- is equivalent to long: [2011-11-30 07:47:07] bugzilla33 at gmail dot com /Summary change/ Array -> Array/String 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=60408 -- Edit this bug report at https://bugs.php.net/bug.php?id=60408&edit=1
Req #60408 [PATCH]: Array/String element access on instantiation (same like class member in 5.4RC)
Edit report at https://bugs.php.net/bug.php?id=60408&edit=1 ID: 60408 Patch added by: larue...@php.net Reported by:bugzilla33 at gmail dot com Summary:Array/String element access on instantiation (same like class member in 5.4RC) Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.4.0RC2 Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: const_dereference_002.phpt Revision: 1322646398 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_002.phpt&revision=1322646398 Previous Comments: [2011-11-30 09:46:27] larue...@php.net The following patch has been added/updated: Patch Name: const_dereference_003.phpt Revision: 1322646387 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_003.phpt&revision=1322646387 [2011-11-30 09:46:09] larue...@php.net The following patch has been added/updated: Patch Name: const_dereference_001.phpt Revision: 1322646369 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=const_dereference_001.phpt&revision=1322646369 ---- [2011-11-30 09:45:33] larue...@php.net The following patch has been added/updated: Patch Name: req60408.patch Revision: 1322646333 URL: https://bugs.php.net/patch-display.php?bug=60408&patch=req60408.patch&revision=1322646333 ---- [2011-11-30 08:55:21] larue...@php.net Dmitry, could you look at this please? thanks patch and test list in: https://wiki.php.net/rfc/constdereference All existing test passed. [2011-11-30 08:40:17] lunter at interia dot pl I'm all for it. example: short switch/case alternative -- is equivalent to long: 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=60408 -- Edit this bug report at https://bugs.php.net/bug.php?id=60408&edit=1
Bug #60362 [PATCH]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Patch added by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
Previous Comments:
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o"
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) "f"
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60362&edit=1
Bug #60362 [Com]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Comment by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
update patch, only change the code style, and fix one test faild, thanks
Previous Comments:
[2011-12-04 16:43:01] larue...@php.net
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) "f"
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) "f"
expected: sub-key 1 is NOT empty: string(1) "o
Bug #60362 [PATCH]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Patch added by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: string_offset_trigger_notice.patch
Revision: 1323019601
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323019601
Previous Comments:
[2011-12-04 16:43:41] larue...@php.net
update patch, only change the code style, and fix one test faild, thanks
[2011-12-04 16:43:01] larue...@php.net
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ";
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key &#x
Bug #60362 [Com]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1
ID: 60362
Comment by: larue...@php.net
Reported by:danielc at analysisandsolutions dot com
Summary:non-existent sub-sub keys should not have values
Status: Open
Type: Bug
Package:Arrays related
Operating System: linux
PHP Version:5.4SVN-2011-11-23 (SVN)
Block user comment: N
Private report: N
New Comment:
submit a new patch, which only trigger notice when string offset cast occurred.
Previous Comments:
[2011-12-04 17:26:41] larue...@php.net
The following patch has been added/updated:
Patch Name: string_offset_trigger_notice.patch
Revision: 1323019601
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323019601
[2011-12-04 16:43:41] larue...@php.net
update patch, only change the code style, and fix one test faild, thanks
[2011-12-04 16:43:01] larue...@php.net
The following patch has been added/updated:
Patch Name: fix_disabling_bad_string_offsets
Revision: 1323016981
URL:
https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981
[2011-12-04 12:52:52] alan at akbkhome dot com
This is the test output after the changes:
- most of this makes sense - string offsets of strings are now invalid, and the
dereferencing of strings with numerical indexes is 'fixed' and a behaviour
change.
BEHAVIOR CHANGED: sub-key 'non_existent' is not set.
expected: sub-key 1 is set: string(1) "o"
---
good: sub-sub-key 'sub_sub' is not set.
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o"
---
BEHAVIOR CHANGED: sub-key 'non_existent' is empty.
expected: sub-key 1 is NOT empty: string(1) "o"
---
good: sub-sub-key 'sub_sub' is empty.
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o"
[2011-11-23 01:37:51] danielc at analysisandsolutions dot com
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of the
value indexed by the main key. This is a regression in 5.4. PHP 5.3 still
operates as expected. I suspect this is related to the array dereferencing
changes.
Test script:
---
$arr = array('exists' => 'foo');
if (isset($arr['exists']['non_existent'])) {
echo "expected: sub-key 'non_existent' is set: ";
var_dump($arr['exists']['non_existent']);
} else {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n";
}
if (isset($arr['exists'][1])) {
echo "expected: sub-key 1 is set: ";
var_dump($arr['exists'][1]);
} else {
echo "BEHAVIOR CHANGED: sub-key 1 is not set.\n";
}
echo "---\n";
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo "BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo "good: sub-sub-key 'sub_sub' is not set.\n";
}
if (isset($arr['exists'][1][0])) {
echo "BEHAVIOR CHANGED: sub-sub-key 0 is set: ";
var_dump($arr['exists'][1][0]);
} else {
echo "good: sub-sub-key 0 is not set.\n";
}
echo "---\n";
if (empty($arr['exists']['non_existent'])) {
echo "BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n";
} else {
echo "expected: sub-key 'non_existent' is not empty: ";
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo "BEHAVIOR CHANGED: sub-key 1 is empty.\n";
} else {
echo "expected: sub-key 1 is NOT empty: ";
var_dump($arr['exists'][1]);
}
echo "---\n";
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo "good: sub-sub-key 'sub_sub' is empty.\n";
} else {
echo "BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ";
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo "good: sub-sub-key 0 is empty.\n&q
Bug #60362 [PATCH]: non-existent sub-sub keys should not have values
Edit report at https://bugs.php.net/bug.php?id=60362&edit=1 ID: 60362 Patch added by: larue...@php.net Reported by:danielc at analysisandsolutions dot com Summary:non-existent sub-sub keys should not have values Status: Open Type: Bug Package:Arrays related Operating System: linux PHP Version:5.4SVN-2011-11-23 (SVN) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: string_offset_trigger_notice.patch Revision: 1323062240 URL: https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323062240 Previous Comments: [2011-12-04 17:27:28] larue...@php.net submit a new patch, which only trigger notice when string offset cast occurred. [2011-12-04 17:26:41] larue...@php.net The following patch has been added/updated: Patch Name: string_offset_trigger_notice.patch Revision: 1323019601 URL: https://bugs.php.net/patch-display.php?bug=60362&patch=string_offset_trigger_notice.patch&revision=1323019601 [2011-12-04 16:43:41] larue...@php.net update patch, only change the code style, and fix one test faild, thanks [2011-12-04 16:43:01] larue...@php.net The following patch has been added/updated: Patch Name: fix_disabling_bad_string_offsets Revision: 1323016981 URL: https://bugs.php.net/patch-display.php?bug=60362&patch=fix_disabling_bad_string_offsets&revision=1323016981 [2011-12-04 12:52:52] alan at akbkhome dot com This is the test output after the changes: - most of this makes sense - string offsets of strings are now invalid, and the dereferencing of strings with numerical indexes is 'fixed' and a behaviour change. BEHAVIOR CHANGED: sub-key 'non_existent' is not set. expected: sub-key 1 is set: string(1) "o" --- good: sub-sub-key 'sub_sub' is not set. BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) "o" --- BEHAVIOR CHANGED: sub-key 'non_existent' is empty. expected: sub-key 1 is NOT empty: string(1) "o" --- good: sub-sub-key 'sub_sub' is empty. BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) "o" 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=60362 -- Edit this bug report at https://bugs.php.net/bug.php?id=60362&edit=1
Bug #60444 [PATCH]: Segmentation fault with include & class extending
Edit report at https://bugs.php.net/bug.php?id=60444&edit=1 ID: 60444 Patch added by: larue...@php.net Reported by:php-bugs at majkl578 dot cz Summary:Segmentation fault with include & class extending Status: Open Type: Bug Package:Reproducible crash Operating System: Linux Debian PHP Version:5.4SVN-2011-12-05 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60444.patch Revision: 1323073138 URL: https://bugs.php.net/patch-display.php?bug=60444&patch=bug60444.patch&revision=1323073138 Previous Comments: [2011-12-05 02:44:39] php-bugs at majkl578 dot cz Description: Crash on combination of class & include & extends. Test script: --- a.php: https://bugs.php.net/bug.php?id=60444&edit=1
Bug #60444 [PATCH]: Segmentation fault with include & class extending
Edit report at https://bugs.php.net/bug.php?id=60444&edit=1 ID: 60444 Patch added by: larue...@php.net Reported by:php-bugs at majkl578 dot cz Summary:Segmentation fault with include & class extending Status: Open Type: Bug Package:Reproducible crash Operating System: Linux Debian PHP Version:5.4SVN-2011-12-05 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60444.phpt Revision: 1323073171 URL: https://bugs.php.net/patch-display.php?bug=60444&patch=bug60444.phpt&revision=1323073171 Previous Comments: [2011-12-05 08:18:58] larue...@php.net The following patch has been added/updated: Patch Name: bug60444.patch Revision: 1323073138 URL: https://bugs.php.net/patch-display.php?bug=60444&patch=bug60444.patch&revision=1323073138 [2011-12-05 02:44:39] php-bugs at majkl578 dot cz Description: Crash on combination of class & include & extends. Test script: --- a.php: https://bugs.php.net/bug.php?id=60444&edit=1
[PHP-BUG] Req #60448 [NEW]: Add argument info in zbacktrace
From: laruence Operating system: PHP version: 5.4.0RC2 Package: *General Issues Bug Type: Feature/Change Request Bug description:Add argument info in zbacktrace Description: There is no argument info in zbacktrace when debugging php it will be useful for troubleshooting problem. thanks -- Edit bug report at https://bugs.php.net/bug.php?id=60448&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60448&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60448&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60448&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60448&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60448&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60448&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60448&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60448&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60448&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60448&r=support Expected behavior: https://bugs.php.net/fix.php?id=60448&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60448&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60448&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60448&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60448&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60448&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60448&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60448&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60448&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60448&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60448&r=mysqlcfg
[PHP-BUG] Bug #60528 [NEW]: EG(precision) affects round function's behavior
From: laruence Operating system: PHP version: 5.3.8 Package: *General Issues Bug Type: Bug Bug description:EG(precision) affects round function's behavior Description: as doc said: precision: The number of significant digits displayed in floating point numbers. so precision suppose to only affect the display format of a float; but the fact is: $php -dprecision=14 -r 'echo round(1.22, 2);' 1.22 php -dprecision=20 -r 'echo round(1.22, 2);' 1.2199734 the eg(precision) affected the round result. Test script: --- $php -dprecision=14 -r 'echo round(1.22, 2);' php -dprecision=20 -r 'echo round(1.22, 2);' Expected result: 1.22 1.22 Actual result: -- 1.22 1.2199734 -- Edit bug report at https://bugs.php.net/bug.php?id=60528&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60528&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60528&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60528&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60528&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60528&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60528&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60528&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60528&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60528&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60528&r=support Expected behavior: https://bugs.php.net/fix.php?id=60528&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60528&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60528&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60528&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60528&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60528&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60528&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60528&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60528&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60528&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60528&r=mysqlcfg
Bug #60536 [PATCH]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1
ID: 60536
Patch added by: larue...@php.net
Reported by:scott...@php.net
Summary:Traits Segfault
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: ubuntu 11.11
PHP Version:5.4SVN-2011-12-15 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60536.patch
Revision: 1324050855
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.patch&revision=1324050855
Previous Comments:
[2011-12-15 20:38:27] scott...@php.net
backtrace:
#0 0x000100289c71 in zend_mm_check_ptr (heap=0x10100, ptr=0x100c4f730,
silent=1, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:1380
#1 0x00010028c1ad in _zend_mm_free_int (heap=0x10100, p=0x100c4f730,
__zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2064
#2 0x00010028de9d in _efree (ptr=0x100c4f730, __zend_filename=0x1005476a8
"/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_vm_execute.h",
__zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2436
#3 0x0001003742c8 in i_zval_ptr_dtor [inlined] () at
/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_execute.h:88
#4 0x0001003742c8 in ZEND_RETURN_SPEC_VAR_HANDLER
(execute_data=0x1009802f8)
at zend_execute.h:10833
#5 0x00010032a882 in execute (op_array=0x1009bad50) at
zend_vm_execute.h:410
#6 0x0001002d733b in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:1272
#7 0x000100219973 in php_execute_script (primary_file=0x7fff5fbff170) at
main.c:2476
[2011-12-15 20:37:07] scott...@php.net
Description:
Following code crashes.
Test script:
---
x; }
}
class Z extends Y {
function z() { return ++$this->x; }
}
$a = new Z();
$a->x();
--
Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
Bug #60536 [PATCH]: Traits Segfault
Edit report at https://bugs.php.net/bug.php?id=60536&edit=1
ID: 60536
Patch added by: larue...@php.net
Reported by:scott...@php.net
Summary:Traits Segfault
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: ubuntu 11.11
PHP Version:5.4SVN-2011-12-15 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60536.phpt
Revision: 1324051021
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.phpt&revision=1324051021
Previous Comments:
[2011-12-16 15:54:15] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60536.patch
Revision: 1324050855
URL:
https://bugs.php.net/patch-display.php?bug=60536&patch=bug60536.patch&revision=1324050855
[2011-12-15 20:38:27] scott...@php.net
backtrace:
#0 0x000100289c71 in zend_mm_check_ptr (heap=0x10100, ptr=0x100c4f730,
silent=1, __zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:1380
#1 0x00010028c1ad in _zend_mm_free_int (heap=0x10100, p=0x100c4f730,
__zend_filename=0x1005476a8 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h", __zend_lineno=10833,
__zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2064
#2 0x00010028de9d in _efree (ptr=0x100c4f730, __zend_filename=0x1005476a8
"/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_vm_execute.h",
__zend_lineno=10833, __zend_orig_filename=0x1005437a0 "/Users/macvicar/dev/php-
src/branches/PHP_5_4/Zend/zend_execute.h", __zend_orig_lineno=88) at
zend_alloc.c:2436
#3 0x0001003742c8 in i_zval_ptr_dtor [inlined] () at
/Users/macvicar/dev/php-src/branches/PHP_5_4/Zend/zend_execute.h:88
#4 0x0001003742c8 in ZEND_RETURN_SPEC_VAR_HANDLER
(execute_data=0x1009802f8)
at zend_execute.h:10833
#5 0x00010032a882 in execute (op_array=0x1009bad50) at
zend_vm_execute.h:410
#6 0x0001002d733b in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at zend.c:1272
#7 0x000100219973 in php_execute_script (primary_file=0x7fff5fbff170) at
main.c:2476
[2011-12-15 20:37:07] scott...@php.net
Description:
Following code crashes.
Test script:
---
x; }
}
class Z extends Y {
function z() { return ++$this->x; }
}
$a = new Z();
$a->x();
--
Edit this bug report at https://bugs.php.net/bug.php?id=60536&edit=1
[PHP-BUG] Bug #60558 [NEW]: Invalid read and writes
From: laruence Operating system: PHP version: 5.4.0RC3 Package: Scripting Engine problem Bug Type: Bug Bug description:Invalid read and writes Description: Valgrind complains about invalid read and writes in the tests: http://dev.daylessday.org/diff/bug60536_001.mem http://dev.daylessday.org/diff/bug60536_003.mem So the problem is definitely not fixed yet. Test script: --- http://dev.daylessday.org/diff/bug60536_001.mem http://dev.daylessday.org/diff/bug60536_003.mem -- Edit bug report at https://bugs.php.net/bug.php?id=60558&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60558&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60558&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60558&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60558&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60558&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60558&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60558&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60558&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60558&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60558&r=support Expected behavior: https://bugs.php.net/fix.php?id=60558&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60558&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60558&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60558&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60558&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60558&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60558&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60558&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60558&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60558&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60558&r=mysqlcfg
Bug #60558 [Com]: Invalid read and writes
Edit report at https://bugs.php.net/bug.php?id=60558&edit=1 ID: 60558 Comment by: larue...@php.net Reported by:larue...@php.net Summary:Invalid read and writes Status: Open Type: Bug Package:Scripting Engine problem PHP Version:5.4.0RC3 Block user comment: N Private report: N New Comment: found while diagnosing #60536 Previous Comments: [2011-12-19 04:05:56] larue...@php.net Description: Valgrind complains about invalid read and writes in the tests: http://dev.daylessday.org/diff/bug60536_001.mem http://dev.daylessday.org/diff/bug60536_003.mem So the problem is definitely not fixed yet. Test script: --- http://dev.daylessday.org/diff/bug60536_001.mem http://dev.daylessday.org/diff/bug60536_003.mem -- Edit this bug report at https://bugs.php.net/bug.php?id=60558&edit=1
[PHP-BUG] Bug #60572 [NEW]: Can't make a optional callback arguments in extension
From: laruence
Operating system:
PHP version: 5.3.8
Package: *General Issues
Bug Type: Bug
Bug description:Can't make a optional callback arguments in extension
Description:
following codes in extension didn't work as expected:
zend_fcall_info fci = {0};
zend_fcall_info_cache fci_cache;
...
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "s|f", &key,
&klen,
&fci, &fci_cache) {
return;
}
if (!fci.size) {
// not a valid callback
}
in PHP script:
php_ext_function("name", NULL);
result in:
argument 2 not a valid callback...
I haved tried set the arginfo with all_null.
--
Edit bug report at https://bugs.php.net/bug.php?id=60572&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60572&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60572&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60572&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60572&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60572&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60572&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60572&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60572&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60572&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60572&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60572&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60572&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60572&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60572&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60572&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60572&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60572&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60572&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60572&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60572&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60572&r=mysqlcfg
Req #60573 [PATCH]: type hinting with "self" keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573&edit=1 ID: 60573 Patch added by: larue...@php.net Reported by:jpa...@php.net Summary:type hinting with "self" keyword causes weird errors Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem Operating System: *nix PHP Version:5.3.8 Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60573.patch Revision: 1324396875 URL: https://bugs.php.net/patch-display.php?bug=60573&patch=bug60573.patch&revision=1324396875 Previous Comments: [2011-12-20 12:53:38] larue...@php.net I have a patch now, will apply it after do careful testings [2011-12-20 12:31:44] larue...@php.net This is really a tough one, think about following: - https://bugs.php.net/bug.php?id=60573&edit=1
Req #60573 [PATCH]: type hinting with "self" keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573&edit=1 ID: 60573 Patch added by: larue...@php.net Reported by:jpa...@php.net Summary:type hinting with "self" keyword causes weird errors Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem Operating System: *nix PHP Version:5.3.8 Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60573.phpt Revision: 1324396902 URL: https://bugs.php.net/patch-display.php?bug=60573&patch=bug60573.phpt&revision=1324396902 Previous Comments: [2011-12-20 16:01:15] larue...@php.net The following patch has been added/updated: Patch Name: bug60573.patch Revision: 1324396875 URL: https://bugs.php.net/patch-display.php?bug=60573&patch=bug60573.patch&revision=1324396875 ---- [2011-12-20 12:53:38] larue...@php.net I have a patch now, will apply it after do careful testings ---- [2011-12-20 12:31:44] larue...@php.net This is really a tough one, think about following: - https://bugs.php.net/bug.php?id=60573&edit=1
Req #60573 [Com]: type hinting with "self" keyword causes weird errors
Edit report at https://bugs.php.net/bug.php?id=60573&edit=1 ID: 60573 Comment by: larue...@php.net Reported by:jpa...@php.net Summary:type hinting with "self" keyword causes weird errors Status: Assigned Type: Feature/Change Request Package:Scripting Engine problem Operating System: *nix PHP Version:5.3.8 Assigned To:laruence Block user comment: N Private report: N New Comment: a patch for php 5.4 was submitted, since 5.4 will generate detailed info about the prototype argument list, so this defect is more significant for 5.4. and Tyrael suggest commit this only after 5.4.0 release. so leave this open, I will commit later. thanks Previous Comments: [2011-12-20 16:01:42] larue...@php.net The following patch has been added/updated: Patch Name: bug60573.phpt Revision: 1324396902 URL: https://bugs.php.net/patch-display.php?bug=60573&patch=bug60573.phpt&revision=1324396902 [2011-12-20 16:01:15] larue...@php.net The following patch has been added/updated: Patch Name: bug60573.patch Revision: 1324396875 URL: https://bugs.php.net/patch-display.php?bug=60573&patch=bug60573.patch&revision=1324396875 ---- [2011-12-20 12:53:38] larue...@php.net I have a patch now, will apply it after do careful testings ---- [2011-12-20 12:31:44] larue...@php.net This is really a tough one, think about following: - https://bugs.php.net/bug.php?id=60573&edit=1
[PHP-BUG] Bug #60591 [NEW]: Memory leak when access a non-exists file
From: laruence Operating system: PHP version: 5.4.0RC3 Package: Built-in web server Bug Type: Bug Bug description:Memory leak when access a non-exists file Description: report by cjones if built-in server start with a router: then accesss a non-exists file like(a.jpe) will result in mem leak. Test script: --- Expected result: cjones@mlt:~/w$ php54 -S localhost:8000 routing.php PHP 5.4.0RC4-dev Development Server started at Mon Dec 19 18:55:25 2011 Listening on localhost:8000 Document root is /home/cjones/public_html Press Ctrl-C to quit. [Mon Dec 19 18:55:30 2011] ::1:48358 [200]: /oraclelogo.jpg [Mon Dec 19 18:55:30 2011] Script: '/home/cjones/public_html/favicon.ico' /home/cjones/phpsrc/php/php-src/branches/PHP_5_4/ext/filter/filter.c(451) : Freeing 0xB493F0E4 (16 bytes), script=/home/cjones/public_html/favicon.ico Last leak repeated 19 times [Mon Dec 19 18:55:30 2011] Script: '/home/cjones/public_html/favicon.ico' /home/cjones/phpsrc/php/php-src/branches/PHP_5_4/Zend/zend_execute.h(184) : Freeing 0xB493F19C (65484 bytes), script=/home/cjones/public_html/favicon.ico [Mon Dec 19 18:55:30 2011] Script: '/home/cjones/public_html/favicon.ico' . -- Edit bug report at https://bugs.php.net/bug.php?id=60591&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60591&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60591&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60591&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60591&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60591&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60591&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60591&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60591&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60591&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60591&r=support Expected behavior: https://bugs.php.net/fix.php?id=60591&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60591&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60591&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60591&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60591&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60591&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60591&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60591&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60591&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60591&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60591&r=mysqlcfg
Bug #60627 [PATCH]: httpd.worker segfault on startup
Edit report at https://bugs.php.net/bug.php?id=60627&edit=1 ID: 60627 Patch added by: larue...@php.net Reported by:fedora at famillecollet dot com Summary:httpd.worker segfault on startup Status: Analyzed Type: Bug Package:Apache2 related Operating System: GNU/Linux (Fedora 16) PHP Version:5.4SVN-2011-12-30 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60627.patch Revision: 1325663174 URL: https://bugs.php.net/patch-display.php?bug=60627&patch=bug60627.patch&revision=1325663174 Previous Comments: [2012-01-04 07:32:22] larue...@php.net hmm, the problem is when the real_value_hnd is called, the signal_startup has not been called yet... [2012-01-01 19:22:16] public at wernig dot net Just tried with 5.3.9RC4, and the problem does not occur. Seems to be something in 5.4 [2012-01-01 19:05:57] public at wernig dot net I have the same problem on Solaris 11 (express) i86pc. I'm not sure about ZTS mode (I have NOT set --enable-maintainer-zts) I have compiled php-5.4 (various versions, the latest one being 5.4.0RC4) with the following configure flags: --with-apxs2=/usr/local/apache2/bin/apxs --with-openssl=/usr/local/ssl --with-openssl-dir=/usr/local/ssl --with-zlib --enable-sockets --enable-shared=yes --enable-static=yes --prefix=/usr/local/apache2/php --enable-calendar --disable-ftp --with-mysql=/usr/local/mysql --with-imap=/usr/local/imap --with-imap-ssl=/usr/local/ssl --enable-flatfile --without-recode --disable-ipv6 --with-mysql-sock=/var/run/mysql/mysql.sock --with-gettext=/opt/csw --enable-libxml --with-db4=/usr/local/BerkeleyDB Builds and installs fine. But during apache (2.2.21) startup, it segfaults and dumps core: # /usr/local/svc/init.d/apache2 restart Restarting Apache2 httpd ... /usr/local/apache2/bin/apachectl: line 80: 17568: Memory fault(coredump) In fact, uncommenting all php_admin_value lines from apache config file, apache starts normally. When compiling and installing 5.3.6 with the same configure options, the problem does not occur. [2011-12-31 07:21:41] fedora at famillecollet dot com segfault occurs during apache config analyse. If config doesnt have any php_flag, php_value,... apache starts and works as expected. [2011-12-30 19:10:16] fedora at famillecollet dot com Description: With PHP build in ZTS mode, apache in worker mode segfault during launch Test script: --- $ gdb /usr/sbin/httpd.worker (gdb) run -X Expected result: no error Actual result: -- (gdb) run -X ... Program received signal SIGSEGV, Segmentation fault. 0x7fffec8ca897 in _zend_hash_add_or_update (ht=0x5585a2e8, arKey=, nKeyLength=17, pData=0x7fffde70, nDataSize=24, pDest=0x0, flag=1) at /usr/src/debug/php5.4-201112300630/Zend/zend_hash.c:268 268 HANDLE_BLOCK_INTERRUPTIONS(); (gdb) bt #0 0x7fffec8ca897 in _zend_hash_add_or_update (ht=0x5585a2e8, arKey=, nKeyLength=17, pData=0x7fffde70, nDataSize=24, pDest=0x0, flag=1) at /usr/src/debug/php5.4-201112300630/Zend/zend_hash.c:268 #1 0x7fffec979217 in real_value_hnd (cmd=0x7fffe1a0, dummy=0x5585a2e8, name=0x558c40b8 "register_globals", value=0x7fffded0 "0", status=4) at /usr/src/debug/php5.4-201112300630/sapi/apache2handler/apache_config.c:73 #2 0x7fffec9792ae in real_flag_hnd (cmd=0x7fffe1a0, dummy=0x5585a2e8, arg1=0x558c40b8 "register_globals", arg2=0x558c40d0 "off", status=) at /usr/src/debug/php5.4-201112300630/sapi/apache2handler/apache_config.c:98 #3 0x55580483 in invoke_cmd (cmd=0x7fffecc918f8, parms=0x7fffe1a0, mconfig=0x5585a2e8, args=0x5582f224 "") at /usr/src/debug/httpd-2.2.21/server/config.c:810 #4 0x555826fa in ap_walk_config_sub (section_vector=0x557dc798, parms=0x7fffe1a0, current=0x5582f1d0) at /usr/src/debug/httpd-2.2.21/server/config.c:1163 #5 ap_walk_config (current=0x5582f1d0, parms=0x7fffe1a0, section_vector=0x557dc798) at /usr/src/debug/httpd-2.2.21/server/config.c:1196 #6 0x55583612 in ap_process_config_tree (s=, conftree=, p=0x557b7158, ptemp=) at /usr/src/debug/httpd-2.2.21/server/config.c:1765 #7 0x5556c314 in main (argc=2, argv=0x7fffe418) at /usr/src/debug/httpd-2.2.21/server/main.c:644 -
[PHP-BUG] Bug #60655 [NEW]: add max_input_vars for json/serialize
From: laruence Operating system: PHP version: 5.3.9RC4 Package: *General Issues Bug Type: Bug Bug description:add max_input_vars for json/serialize Description: the max_input_vars restriction should also affect the json_encode and unserialize -- Edit bug report at https://bugs.php.net/bug.php?id=60655&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60655&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60655&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60655&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60655&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60655&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60655&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60655&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60655&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60655&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60655&r=support Expected behavior: https://bugs.php.net/fix.php?id=60655&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60655&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60655&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60655&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60655&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60655&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60655&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60655&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60655&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60655&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60655&r=mysqlcfg
Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 Previous Comments: [2012-01-04 15:26:11] larue...@php.net Description: the max_input_vars restriction should also affect the json_encode and unserialize -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 Previous Comments: [2012-01-05 04:08:22] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 [2012-01-04 15:26:11] larue...@php.net Description: the max_input_vars restriction should also affect the json_encode and unserialize -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 Previous Comments: [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 [2012-01-05 04:08:22] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 ---- [2012-01-04 15:26:11] larue...@php.net Description: the max_input_vars restriction should also affect the json_encode and unserialize -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 Previous Comments: [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 ---- [2012-01-05 04:08:22] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 ---- [2012-01-04 15:26:11] larue...@php.net Description: the max_input_vars restriction should also affect the json_encode and unserialize -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 Previous Comments: [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 ---- [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 ---- [2012-01-05 04:08:22] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 -------- [2012-01-04 15:26:11] larue...@php.net Description: the max_input_vars restriction should also affect the json_encode and unserialize -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Req #60655 [PATCH]: add max_input_vars for json/serialize
Edit report at https://bugs.php.net/bug.php?id=60655&edit=1 ID: 60655 Patch added by: larue...@php.net Reported by:larue...@php.net Summary:add max_input_vars for json/serialize Status: Open Type: Feature/Change Request Package:*General Issues PHP Version:5.3.9RC4 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: rand_hash_resize.patch Revision: 1325750958 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=rand_hash_resize.patch&revision=1325750958 Previous Comments: [2012-01-05 05:04:53] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739893 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739893 [2012-01-05 05:03:29] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739809 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739809 ---- [2012-01-05 05:02:16] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325739736 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325739736 ---- [2012-01-05 04:17:03] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325737023 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325737023 -------- [2012-01-05 04:08:22] larue...@php.net The following patch has been added/updated: Patch Name: max_input_vars.patch Revision: 1325736502 URL: https://bugs.php.net/patch-display.php?bug=60655&patch=max_input_vars.patch&revision=1325736502 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=60655 -- Edit this bug report at https://bugs.php.net/bug.php?id=60655&edit=1
Bug #60707 [Com]: max_input_vars allows one extra var
Edit report at https://bugs.php.net/bug.php?id=60707&edit=1 ID: 60707 Comment by: larue...@php.net Reported by:vr...@php.net Summary:max_input_vars allows one extra var Status: Open Type: Bug Package:Variables related Operating System: Irrelevant PHP Version:5.3.9 Block user comment: N Private report: N New Comment: max_input_vars is used to protected from ddos attack, IMO it's not a big deal :) Previous Comments: [2012-01-11 05:15:12] vr...@php.net Description: Setting max_input_vars to N allows N+1 variables. Test script: --- \n"; } var_dump($max_input_vars); var_dump(count($_POST)); ?> Expected result: string(4) "1000" int(1000) Actual result: -- string(4) "1000" int(1001) -- Edit this bug report at https://bugs.php.net/bug.php?id=60707&edit=1
Req #60760 [Com]: Converting zend_parse_parameters() to zend_parse_parameters_none()
Edit report at https://bugs.php.net/bug.php?id=60760&edit=1 ID: 60760 Comment by: larue...@php.net Reported by:dragoo...@php.net Summary:Converting zend_parse_parameters() to zend_parse_parameters_none() Status: Open Type: Feature/Change Request Package:SPL related Operating System: N/A PHP Version:5.4.0RC5 Block user comment: N Private report: N New Comment: if no parameters will be accpected, why call to zend_parse_parameters? just a arginfo will be enough. Previous Comments: [2012-01-15 03:33:27] dragoo...@php.net The following patch has been added/updated: Patch Name: spl_dllist_zend_parse_parameters_none.diff Revision: 1326598407 URL: https://bugs.php.net/patch-display.php?bug=60760&patch=spl_dllist_zend_parse_parameters_none.diff&revision=1326598407 [2012-01-15 03:32:21] dragoo...@php.net Description: Half of the file base uses zend_parse_parameters() to check if theres no params passed. Half of the file already uses zend_parse_parameters_none(). The work done here just updates zend_parse_parameters() calls to zend_parse_parameters_none() where necessary. Test script: --- N/A Expected result: N/A Actual result: -- N/A -- Edit this bug report at https://bugs.php.net/bug.php?id=60760&edit=1
Bug #60708 [PATCH]: segmentation fault, use max_input_vars
Edit report at https://bugs.php.net/bug.php?id=60708&edit=1
ID: 60708
Patch added by: larue...@php.net
Reported by:masugata at gmail dot com
Summary:segmentation fault, use max_input_vars
Status: Assigned
Type: Bug
Package:*General Issues
Operating System: x86_64 GNU/Linux
PHP Version:5.3.9
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: memleak_fix_for_bug60708
Revision: 1328173952
URL:
https://bugs.php.net/patch-display.php?bug=60708&patch=memleak_fix_for_bug60708&revision=1328173952
Previous Comments:
[2012-02-02 09:02:16] paj...@php.net
Assign to Dmitry as he is working on that now.
[2012-02-02 08:58:46] larue...@php.net
fix for leaks referred by Pierre:
--- php_variables.c (revision 323011)
+++ php_variables.c (working copy)
@@ -187,6 +187,10 @@
array_init(gpc_element);
zend_symtable_update(symtable1,
escaped_index, index_len + 1, &gpc_element, sizeof(zval *), (void **)
&gpc_element_p);
} else {
+ if (index != escaped_index) {
+ efree(escaped_index);
+ }
+ zval_dtor(val);
free_alloca(var_orig, use_heap);
return;
}
[2012-02-02 08:00:21] huzaifas at redhat dot com
Is this bug fixed by the following svn commit?
http://svn.php.net/viewvc?view=revision&revision=323007
[2012-02-02 07:55:42] paj...@php.net
Are you sure the fix is complete? There are leaks afaik.
[2012-02-02 07:29:21] s...@php.net
This bug has been fixed in SVN.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
For Windows:
http://windows.php.net/snapshots/
Thank you for the report, and for helping us make PHP better.
Thanks, should be fine in current 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=60708
--
Edit this bug report at https://bugs.php.net/bug.php?id=60708&edit=1
Bug #60968 [Com]: Late static binding doesn't work with ReflectionMethod::invokeArgs()
Edit report at https://bugs.php.net/bug.php?id=60968&edit=1
ID: 60968
Comment by: larue...@php.net
Reported by:rosen at developer dot bg
Summary:Late static binding doesn't work with
ReflectionMethod::invokeArgs()
Status: Assigned
Type: Bug
Package:Reflection related
Operating System: CentOS 5.6 (kernel 2.6.18-238.1)
PHP Version:5.3.10
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
fixed in 5.3 , trunk, will close this after ci to 5.4
Previous Comments:
[2012-02-03 16:27:31] larue...@php.net
Automatic comment from SVN on behalf of laruence
Revision: http://svn.php.net/viewvc/?view=revision&revision=323045
Log: Fixed bug #60968 (Late static binding doesn't work with
ReflectionMethod::invokeArgs())
[2012-02-03 13:18:43] rosen at developer dot bg
Description:
This bug was fixed in 5.3.9 for ReflectionMethod::invoke() (see bug #60367),
but it still exists for ReflectionMethod::invokeArgs()
Test script:
---
getMethod('method')->invoke(null); // outputs 'B'
$b->getMethod('method')->invokeArgs(null, array()); // outputs 'A'
Expected result:
BB
Actual result:
--
BA
--
Edit this bug report at https://bugs.php.net/bug.php?id=60968&edit=1
Bug #60978 [PATCH]: exit code incorrect
Edit report at https://bugs.php.net/bug.php?id=60978&edit=1
ID: 60978
Patch added by: larue...@php.net
Reported by:the...@php.net
Summary:exit code incorrect
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.0RC7
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: wrong_exit_code.patch
Revision: 1328522147
URL:
https://bugs.php.net/patch-display.php?bug=60978&patch=wrong_exit_code.patch&revision=1328522147
Previous Comments:
[2012-02-05 13:36:33] the...@php.net
Checking SVN history revealed r322922 as the cause - see
http://svn.php.net/viewvc?view=revision&revision=322922. Reverting it fixes
this bug.
The commit mentions a relation to bug #60218 but I'm not sure why it
"Reinstated correct return values". Before this fix the code in
zend_execute_API.c read:
zend_execute(new_op_array TSRMLS_CC);
[...]
retval = SUCCESS;
After the fix it read:
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_end_try();
[...]
retval = SUCCESS;
Finally, r322922 changed it to:
retval = SUCCESS;
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_catch {
retval = FAILURE;
} zend_end_try();
The zend_catch "block" is executed whenever SETJMP returns non-zero, so
basically when LONGJMP is called, which is the case for zend_bailout(), which
again is used by exit() and die(). To my eyes, this *changed* the return value
instead of reinstating it.
@derick, maybe you can shed some light on this commit?
[2012-02-05 10:54:30] the...@php.net
Test suite:
0,
"exit('test');"=> 0,
"exit(2);" => 2,
"fatal();" => 255,
"\$->" => 254,
"throw new Exception('test');" => 255
);
foreach ($tests as $source => $expected) {
$cmd= '"'.$php.'" -r "'.$source.'" 2>&1';
$output= array();
exec($cmd, $output, $actual);
if ($actual === $expected) {
printf("%-30s: [OK]\n", $source);
} else {
printf("%-30s: [FAIL, expect %d, have %d (%s)]\n", $source, $expected,
$actual, implode(' ', $output));
}
}
?>
[2012-02-05 10:01:41] the...@php.net
...oh, and:
* Uncaught exception exit, `php -r 'throw new Exception("test");' ; echo $?` =
255
[2012-02-05 09:59:54] the...@php.net
Your patch breaks the exitcode 254 for parse errors.
We have the following cases and expected exit codes:
* Clean exit, `php -r 'echo "";' ; echo $?` = 0
* Clean explicit exit with message, `php -r 'exit("test");' ; echo $?` = 0
* Clean explicit exit with exitcode, `php -r 'exit(2);' ; echo $?` = 2
* Exit after a fatal error, `php -r '$fatal->error();' ; echo $?` = 255
* Exit after compile error, `php -r '$->' ; echo $?` = 254
[2012-02-04 20:43:08] php-dev at zerocue dot com
Alright, in 5.3.10@php_cli:1023 the call to zend_eval_string_ex() never
returned
after a zend_bailout(), if it had this bug would have been present there
because
zend_bailout always returns FAILURE even in non-failure cases.
In 5.4 and trunk, the zend_eval_string_ex() does return and hits the
exit_status=254 line. The proper fix would be to have zend_bailout not return
FAILURE unless it did fail but this is a much larger change. In this case the
patch simply ignores the return state of the zend_eval_string_ex() and always
returns the EG(exit_status) value.
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=60978
--
Edit this bug report at https://bugs.php.net/bug.php?id=60978&edit=1
Bug #60978 [Com]: exit code incorrect
Edit report at https://bugs.php.net/bug.php?id=60978&edit=1
ID: 60978
Comment by: larue...@php.net
Reported by:the...@php.net
Summary:exit code incorrect
Status: Assigned
Type: Bug
Package:Scripting Engine problem
Operating System: Windows
PHP Version:5.4.0RC7
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
I think a appropriate way to fix these issues(memleak, xdebug, this issue) is
catch->efree->throw. I have made a patch.
Derick, what do you think?
Previous Comments:
[2012-02-06 09:55:47] larue...@php.net
The following patch has been added/updated:
Patch Name: wrong_exit_code.patch
Revision: 1328522147
URL:
https://bugs.php.net/patch-display.php?bug=60978&patch=wrong_exit_code.patch&revision=1328522147
[2012-02-05 13:36:33] the...@php.net
Checking SVN history revealed r322922 as the cause - see
http://svn.php.net/viewvc?view=revision&revision=322922. Reverting it fixes
this bug.
The commit mentions a relation to bug #60218 but I'm not sure why it
"Reinstated correct return values". Before this fix the code in
zend_execute_API.c read:
zend_execute(new_op_array TSRMLS_CC);
[...]
retval = SUCCESS;
After the fix it read:
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_end_try();
[...]
retval = SUCCESS;
Finally, r322922 changed it to:
retval = SUCCESS;
zend_try {
zend_execute(new_op_array TSRMLS_CC);
} zend_catch {
retval = FAILURE;
} zend_end_try();
The zend_catch "block" is executed whenever SETJMP returns non-zero, so
basically when LONGJMP is called, which is the case for zend_bailout(), which
again is used by exit() and die(). To my eyes, this *changed* the return value
instead of reinstating it.
@derick, maybe you can shed some light on this commit?
[2012-02-05 10:54:30] the...@php.net
Test suite:
0,
"exit('test');"=> 0,
"exit(2);" => 2,
"fatal();" => 255,
"\$->" => 254,
"throw new Exception('test');" => 255
);
foreach ($tests as $source => $expected) {
$cmd= '"'.$php.'" -r "'.$source.'" 2>&1';
$output= array();
exec($cmd, $output, $actual);
if ($actual === $expected) {
printf("%-30s: [OK]\n", $source);
} else {
printf("%-30s: [FAIL, expect %d, have %d (%s)]\n", $source, $expected,
$actual, implode(' ', $output));
}
}
?>
[2012-02-05 10:01:41] the...@php.net
...oh, and:
* Uncaught exception exit, `php -r 'throw new Exception("test");' ; echo $?` =
255
[2012-02-05 09:59:54] the...@php.net
Your patch breaks the exitcode 254 for parse errors.
We have the following cases and expected exit codes:
* Clean exit, `php -r 'echo "";' ; echo $?` = 0
* Clean explicit exit with message, `php -r 'exit("test");' ; echo $?` = 0
* Clean explicit exit with exitcode, `php -r 'exit(2);' ; echo $?` = 2
* Exit after a fatal error, `php -r '$fatal->error();' ; echo $?` = 255
* Exit after compile error, `php -r '$->' ; echo $?` = 254
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=60978
--
Edit this bug report at https://bugs.php.net/bug.php?id=60978&edit=1
Bug #61000 [PATCH]: Exceeding max nesting level doesn't delete numerical vars
Edit report at https://bugs.php.net/bug.php?id=61000&edit=1 ID: 61000 Patch added by: larue...@php.net Reported by:cataphr...@php.net Summary:Exceeding max nesting level doesn't delete numerical vars Status: Open Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:trunk-SVN-2012-02-07 (snap) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61000.patch Revision: 1328681292 URL: https://bugs.php.net/patch-display.php?bug=61000&patch=bug61000.patch&revision=1328681292 Previous Comments: [2012-02-07 09:45:58] cataphr...@php.net Description: Exceeding the max nesting level doesn't delete numerical vars, while it deletes the non-numerical ones. php_register_variable_ex inappropriately uses zend_hash_del. (Found out by Stefan Esser, who points this can be used, together with max_input_vars, to determine whether PHP is a 32-bit or 64-bit process) Test script: --- With max nesting level=2: http://nebm.ist.utl.pt/phpinfo?1[a][]=foo&1[a][b][c]=bar Expected result: _GET is empty Actual result: -- _GET["1"] = Array ( [a] => Array ( [0] => foo ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=61000&edit=1
Bug #61000 [Com]: Exceeding max nesting level doesn't delete numerical vars
Edit report at https://bugs.php.net/bug.php?id=61000&edit=1 ID: 61000 Comment by: larue...@php.net Reported by:cataphr...@php.net Summary:Exceeding max nesting level doesn't delete numerical vars Status: Open Type: Bug Package:Scripting Engine problem Operating System: Irrelevant PHP Version:trunk-SVN-2012-02-07 (snap) Block user comment: N Private report: N New Comment: I am wondering that was there a disscussion about how to fix this? seems replace zend_hash_del with zend_symbol_del will solve this issue. since it is so suspicious(seems too easy), so I attached my fix. I was wondering is there already a discussion about how to fix it ? if not, I think zend_symbol_del will works I think Catahract already had a fix, didn't he? it was probably just that though thanks Previous Comments: [2012-02-08 06:08:12] larue...@php.net The following patch has been added/updated: Patch Name: bug61000.patch Revision: 1328681292 URL: https://bugs.php.net/patch-display.php?bug=61000&patch=bug61000.patch&revision=1328681292 [2012-02-07 09:45:58] cataphr...@php.net Description: Exceeding the max nesting level doesn't delete numerical vars, while it deletes the non-numerical ones. php_register_variable_ex inappropriately uses zend_hash_del. (Found out by Stefan Esser, who points this can be used, together with max_input_vars, to determine whether PHP is a 32-bit or 64-bit process) Test script: --- With max nesting level=2: http://nebm.ist.utl.pt/phpinfo?1[a][]=foo&1[a][b][c]=bar Expected result: _GET is empty Actual result: -- _GET["1"] = Array ( [a] => Array ( [0] => foo ) ) -- Edit this bug report at https://bugs.php.net/bug.php?id=61000&edit=1
Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1
ID: 61011
Patch added by: larue...@php.net
Reported by:ahar...@php.net
Summary:Crash when an exception is thrown by __autoload
accessing a static property
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: OSX 10.6.8 & Linux
PHP Version:5.4SVN-2012-02-08 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135
Previous Comments:
[2012-02-08 14:47:27] ahar...@php.net
Description:
I get a reproducible crash on PHP_5_4 and trunk when accessing a static
property
on a non-existent class with an autoloader registered if the __autoload()
function
throws an exception.
PHP_5_3 doesn't crash, and throws an exception as expected.
Test script:
---
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 "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object...
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1 0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property",
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2 0x083f1711 in zend_std_get_static_property (ce=0x0,
property_name=0xb7b60d40
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3 0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0,
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4 0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5 0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6 0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7 0x08348b0e in php_execute_script (primary_file=0xb518) at
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8 0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9 0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61011&edit=1
Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1
ID: 61011
Patch added by: larue...@php.net
Reported by:ahar...@php.net
Summary:Crash when an exception is thrown by __autoload
accessing a static property
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: OSX 10.6.8 & Linux
PHP Version:5.4SVN-2012-02-08 (SVN)
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61011.phpt
Revision: 1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158
Previous Comments:
[2012-02-08 16:05:36] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135
[2012-02-08 14:47:27] ahar...@php.net
Description:
I get a reproducible crash on PHP_5_4 and trunk when accessing a static
property
on a non-existent class with an autoloader registered if the __autoload()
function
throws an exception.
PHP_5_3 doesn't crash, and throws an exception as expected.
Test script:
---
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 "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object...
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1 0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property",
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2 0x083f1711 in zend_std_get_static_property (ce=0x0,
property_name=0xb7b60d40
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3 0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0,
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4 0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5 0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6 0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7 0x08348b0e in php_execute_script (primary_file=0xb518) at
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8 0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9 0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61011&edit=1
Bug #61011 [Com]: Crash when an exception is thrown by __autoload accessing a static property
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1
ID: 61011
Comment by: larue...@php.net
Reported by:ahar...@php.net
Summary:Crash when an exception is thrown by __autoload
accessing a static property
Status: Open
Type: Bug
Package:Reproducible crash
Operating System: OSX 10.6.8 & Linux
PHP Version:5.4SVN-2012-02-08 (SVN)
Block user comment: N
Private report: N
New Comment:
I am not sure whether the patch is okey(it seems related to CACHE mechanism).
anyway the patch will show where the problem comes from.
Dmitry, could plz look at this? thanks .
Previous Comments:
[2012-02-08 16:05:58] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.phpt
Revision: 1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158
[2012-02-08 16:05:36] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135
[2012-02-08 14:47:27] ahar...@php.net
Description:
I get a reproducible crash on PHP_5_4 and trunk when accessing a static
property
on a non-existent class with an autoloader registered if the __autoload()
function
throws an exception.
PHP_5_3 doesn't crash, and throws an exception as expected.
Test script:
---
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 "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object...
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1 0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property",
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2 0x083f1711 in zend_std_get_static_property (ce=0x0,
property_name=0xb7b60d40
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3 0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0,
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4 0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5 0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6 0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7 0x08348b0e in php_execute_script (primary_file=0xb518) at
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8 0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9 0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61011&edit=1
Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1
ID: 61011
Patch added by: larue...@php.net
Reported by:ahar...@php.net
Summary:Crash when an exception is thrown by __autoload
accessing a static property
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: OSX 10.6.8 & Linux
PHP Version:5.4SVN-2012-02-08 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328929988
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328929988
Previous Comments:
[2012-02-08 16:07:37] larue...@php.net
I am not sure whether the patch is okey(it seems related to CACHE mechanism).
anyway the patch will show where the problem comes from.
Dmitry, could plz look at this? thanks .
[2012-02-08 16:05:58] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.phpt
Revision: 1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158
----
[2012-02-08 16:05:36] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135
[2012-02-08 14:47:27] ahar...@php.net
Description:
I get a reproducible crash on PHP_5_4 and trunk when accessing a static
property
on a non-existent class with an autoloader registered if the __autoload()
function
throws an exception.
PHP_5_3 doesn't crash, and throws an exception as expected.
Test script:
---
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 "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object...
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1 0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property",
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2 0x083f1711 in zend_std_get_static_property (ce=0x0,
property_name=0xb7b60d40
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3 0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0,
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4 0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5 0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6 0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7 0x08348b0e in php_execute_script (primary_file=0xb518) at
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8 0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:983
#9 0x084db492 in main (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php_cli.c:1356
(gdb)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61011&edit=1
Bug #61011 [PATCH]: Crash when an exception is thrown by __autoload accessing a static property
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1
ID: 61011
Patch added by: larue...@php.net
Reported by:ahar...@php.net
Summary:Crash when an exception is thrown by __autoload
accessing a static property
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: OSX 10.6.8 & Linux
PHP Version:5.4SVN-2012-02-08 (SVN)
Assigned To:dmitry
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61011.phpt
Revision: 1328930087
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328930087
Previous Comments:
[2012-02-11 03:13:08] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328929988
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328929988
----
[2012-02-08 16:07:37] larue...@php.net
I am not sure whether the patch is okey(it seems related to CACHE mechanism).
anyway the patch will show where the problem comes from.
Dmitry, could plz look at this? thanks .
----
[2012-02-08 16:05:58] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.phpt
Revision: 1328717158
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158
----
[2012-02-08 16:05:36] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61011.patch
Revision: 1328717135
URL:
https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135
[2012-02-08 14:47:27] ahar...@php.net
Description:
I get a reproducible crash on PHP_5_4 and trunk when accessing a static
property
on a non-existent class with an autoloader registered if the __autoload()
function
throws an exception.
PHP_5_3 doesn't crash, and throws an exception as expected.
Test script:
---
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 "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/php...pdone.
(gdb) r /tmp/native-autoload.php
Starting program: /home/adam/trees/php-src/branches/PHP_5_4/sapi/cli/php
/tmp/native-autoload.php
[Thread debugging using libthread_db enabled]
referencing a static property on a non existent object...
Program received signal SIGSEGV, Segmentation fault.
0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
54 if (ht->inconsistent==HT_OK) {
(gdb) bt
#0 0x083d0d39 in _zend_is_inconsistent (ht=0x44, file=0x87bb748
"/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c", line=946) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend_hash.c:54
#1 0x083d36d4 in zend_hash_quick_find (ht=0x44, arKey=0xb7b60d40 "property",
nKeyLength=9, h=2332364938, pData=0xbfffd01c) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_hash.c:946
#2 0x083f1711 in zend_std_get_static_property (ce=0x0,
property_name=0xb7b60d40
"property", property_name_len=8, silent=0 '\000', key=0xb7c6b67c)
at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_object_handlers.c:1232
#3 0x0840369b in zend_fetch_var_address_helper_SPEC_CONST_CONST (type=0,
execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3244
#4 0x08403bfe in ZEND_FETCH_R_SPEC_CONST_CONST_HANDLER
(execute_data=0xb7c4f074) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:3335
#5 0x083f94b7 in execute (op_array=0xb7c6a4d0) at /home/adam/trees/php-
src/branches/PHP_5_4/Zend/zend_vm_execute.h:410
#6 0x083c3ec9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at
/home/adam/trees/php-src/branches/PHP_5_4/Zend/zend.c:1272
#7 0x08348b0e in php_execute_script (primary_file=0xb518) at
/home/adam/trees/php-src/branches/PHP_5_4/main/main.c:2475
#8 0x084da44e in do_cli (argc=2, argv=0xb7a4) at /home/adam/trees/php-
src/branches/PHP_5_4/sapi/cli/
Bug #61011 [Com]: Crash when an exception is thrown by __autoload accessing a static property
Edit report at https://bugs.php.net/bug.php?id=61011&edit=1 ID: 61011 Comment by: larue...@php.net Reported by:ahar...@php.net Summary:Crash when an exception is thrown by __autoload accessing a static property Status: Assigned Type: Bug Package:Reproducible crash Operating System: OSX 10.6.8 & Linux PHP Version:5.4SVN-2012-02-08 (SVN) Assigned To:dmitry Block user comment: N Private report: N New Comment: Hi, I attached a improved patch and phpt. thanks Previous Comments: [2012-02-11 03:14:47] larue...@php.net The following patch has been added/updated: Patch Name: bug61011.phpt Revision: 1328930087 URL: https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328930087 [2012-02-11 03:13:08] larue...@php.net The following patch has been added/updated: Patch Name: bug61011.patch Revision: 1328929988 URL: https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328929988 ---- [2012-02-08 16:07:37] larue...@php.net I am not sure whether the patch is okey(it seems related to CACHE mechanism). anyway the patch will show where the problem comes from. Dmitry, could plz look at this? thanks . ---- [2012-02-08 16:05:58] larue...@php.net The following patch has been added/updated: Patch Name: bug61011.phpt Revision: 1328717158 URL: https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.phpt&revision=1328717158 ---- [2012-02-08 16:05:36] larue...@php.net The following patch has been added/updated: Patch Name: bug61011.patch Revision: 1328717135 URL: https://bugs.php.net/patch-display.php?bug=61011&patch=bug61011.patch&revision=1328717135 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=61011 -- Edit this bug report at https://bugs.php.net/bug.php?id=61011&edit=1
Bug #61165 [PATCH]: Segfault - strip_tags()
Edit report at https://bugs.php.net/bug.php?id=61165&edit=1
ID: 61165
Patch added by: larue...@php.net
Reported by:tomas dot liska at actumg2 dot cz
Summary:Segfault - strip_tags()
Status: Assigned
Type: Bug
Package:Reproducible crash
Operating System: 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: bug61165.phpt
Revision: 1330102962
URL:
https://bugs.php.net/patch-display.php?bug=61165&patch=bug61165.phpt&revision=1330102962
Previous Comments:
[2012-02-24 16:58:16] larue...@php.net
this seems introduced by #43450.
so if you stash the $this in __toString, $this will be relased, so undefined
error occurred (in this case, I guess, the next return_value suddenly point to
the previous $this which was be released just before, due to the zend mm cache);
I have made a patch, but cause 43450 test failed again ,although I am not sure
whether the test self is right or not, will keep diggin.
[2012-02-24 09:22:28] me at ktamura dot com
I am fairly certain it is some kind of pointer deferencing here on L446 of
Zend/zend_execution_API.c (php-5.3.10) I am not sure what the exact cause is
yet
though.
434 ZEND_API void _zval_ptr_dtor(zval **zval_ptr ZEND_FILE_LINE_DC) /* {{{ */
435 {
436 zval *zv = *zval_ptr;
437
438 #if DEBUG_ZEND>=2
439 printf("Reducing refcount for %x (%x): %d->%d\n", *zval_ptr, zval_ptr,
Z_REFCOUNT_PP(zval_ptr), Z_REFCOUNT_PP(zval_ptr) - 1);
440 #endif
441 Z_DELREF_P(zv);
442 if (Z_REFCOUNT_P(zv) == 0) {
443 TSRMLS_FETCH();
444
445 if (zv != &EG(uninitialized_zval)) {
446 GC_REMOVE_ZVAL_FROM_BUFFER(zv);
447 zval_dtor(zv);
448 efree_rel(zv);
[2012-02-24 08:32:29] tomas dot liska at actumg2 dot cz
I might have the cause of this. This code produces $cnt - 1 leaks:
params['this'] = $this; // <-- uncoment this
//$this->_this = $this; // <-- or this (both cause the leak)
return 'A';
}
}
$t = new T;
$cnt = 2;
for ($i = 0; $i < $cnt; $i++) {
strip_tags($t);
echo "$i\n";
}
Output:
0
1
[Fri Feb 24 09:27:16 2012] Script: 'go_own_own.php'
/home/users/tliska/wd/php/php-5.4.0RC8/ext/standard/string.c(4087) : Freeing
0x2B9B23ADC678 (2 bytes), script=go_own_own.php
--------
[2012-02-24 04:56:31] larue...@php.net
this is not the strip_tags's issue.
ervery internal function perfer a 's', will act the same result(segfault).
so the problem should be in the __toString of that object...
I will keep digging..
thanks
----
[2012-02-23 05:41:30] larue...@php.net
I can confirm this issue exists. but still can not figure out the reason.
dmitry, could you plz look at this? 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=61165
--
Edit this bug report at https://bugs.php.net/bug.php?id=61165&edit=1
[PHP-BUG] Bug #61186 [NEW]: valgrind complain of invalid reading
From: laruence Operating system: PHP version: 5.3.10 Package: Scripting Engine problem Bug Type: Bug Bug description:valgrind complain of invalid reading Description: while use valgrind exam PHP 5.3, it complain of invalid reading. Test script: --- #run $USE_ZEND_ALLOC=0 valgrind php53 above.php Expected result: no complaint Actual result: -- ==11759== Memcheck, a memory error detector ==11759== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==11759== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==11759== Command: php above.php ==11759== ==11759== Invalid read of size 1 ==11759==at 0x8F4D95: lex_scan (zend_language_scanner.c:1028) ==11759==by 0x932C91: zendlex (zend_compile.c:4975) ==11759==by 0x8EA7E3: zendparse (zend_language_parser.c:2948) ==11759==by 0x8F240B: compile_file (zend_language_scanner.l:364) ==11759==by 0x6CA931: phar_compile_file (phar.c:3393) ==11759==by 0x94DD0E: zend_execute_scripts (zend.c:1228) ==11759==by 0x8B5E33: php_execute_script (main.c:2308) ==11759==by 0xA430C4: main (php_cli.c:1184) ==11759== Address 0x87ec132 is 0 bytes after a block of size 18 alloc'd ==11759==at 0x490514E: malloc (vg_replace_malloc.c:195) ==11759==by 0x91DC2D: _emalloc (zend_alloc.c:2348) ==11759==by 0x8F1E36: open_file_for_scanning (zend_language_scanner.l:288) ==11759==by 0x8F2343: compile_file (zend_language_scanner.l:352) ==11759==by 0x6CA931: phar_compile_file (phar.c:3393) ==11759==by 0x94DD0E: zend_execute_scripts (zend.c:1228) ==11759==by 0x8B5E33: php_execute_script (main.c:2308) ==11759==by 0xA430C4: main (php_cli.c:1184) ==11759== 2==11759== ==11759== HEAP SUMMARY: ==11759== in use at exit: 46,688 bytes in 1,586 blocks ==11759== total heap usage: 29,304 allocs, 27,718 frees, 4,549,300 bytes allocated ==11759== ==11759== LEAK SUMMARY: ==11759==definitely lost: 0 bytes in 0 blocks ==11759==indirectly lost: 0 bytes in 0 blocks ==11759== possibly lost: 0 bytes in 0 blocks ==11759==still reachable: 46,688 bytes in 1,586 blocks ==11759== suppressed: 0 bytes in 0 blocks ==11759== Rerun with --leak-check=full to see details of leaked memory ==11759== ==11759== For counts of detected and suppressed errors, rerun with: -v ==11759== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4) -- Edit bug report at https://bugs.php.net/bug.php?id=61186&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61186&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61186&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61186&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61186&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61186&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61186&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61186&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61186&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61186&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61186&r=support Expected behavior: https://bugs.php.net/fix.php?id=61186&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61186&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61186&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61186&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61186&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61186&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61186&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61186&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61186&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61186&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61186&r=mysqlcfg
[PHP-BUG] Bug #61347 [NEW]: inconsist isset behavior of Arrayobject
From: laruence Operating system: PHP version: Irrelevant Package: SPL related Bug Type: Bug Bug description:inconsist isset behavior of Arrayobject Description: isset(arrayobject['index']) act inconsistently with isset(array['index']) Test script: --- NULL); var_dump(isset($a['b'])); $b = new ArrayObject($a); var_dump(isset($b['b'])); Expected result: bool(false) bool(false) Actual result: -- bool(false) bool(true) -- Edit bug report at https://bugs.php.net/bug.php?id=61347&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61347&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61347&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61347&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61347&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61347&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61347&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61347&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61347&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61347&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61347&r=support Expected behavior: https://bugs.php.net/fix.php?id=61347&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61347&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61347&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61347&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61347&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61347&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61347&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61347&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61347&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61347&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61347&r=mysqlcfg
Bug #61347 [Com]: inconsist isset behavior of Arrayobject
Edit report at https://bugs.php.net/bug.php?id=61347&edit=1
ID: 61347
Comment by: larue...@php.net
Reported by:larue...@php.net
Summary:inconsist isset behavior of Arrayobject
Status: Open
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
these codes are weired(spl_array.c:603):
switch(Z_TYPE_P(offset)) {
case IS_STRING:
if (check_empty) {
if (zend_symtable_find(spl_array_get_hash_table(intern, 0
TSRMLS_CC), Z_STRVAL_P(offset), Z_STRLEN_P(offset)+1, (void **) &tmp) !=
FAILURE) {
switch (check_empty) {
case 0:
return Z_TYPE_PP(tmp) != IS_NULL;
case 2:
return 1;
default:
return zend_is_true(*tmp);
}
}
return 0;
} else {
return zend_symtable_exists(spl_array_get_hash_table(intern, 0
TSRMLS_CC), Z_STRVAL_P(offset), Z_STRLEN_P(offset)+1);
}
note the switch statement, there is no chance check_empty will be 0, since
there
is a if(check_empty) before.
and, I don't see any chance that the check_empty could be 2.
any idea? thanks
Previous Comments:
[2012-03-11 05:17:21] larue...@php.net
Description:
isset(arrayobject['index']) act inconsistently with isset(array['index'])
Test script:
---
NULL);
var_dump(isset($a['b']));
$b = new ArrayObject($a);
var_dump(isset($b['b']));
Expected result:
bool(false)
bool(false)
Actual result:
--
bool(false)
bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61347&edit=1
Bug #61347 [Com]: inconsist isset behavior of Arrayobject
Edit report at https://bugs.php.net/bug.php?id=61347&edit=1
ID: 61347
Comment by: larue...@php.net
Reported by:larue...@php.net
Summary:inconsist isset behavior of Arrayobject
Status: Open
Type: Bug
Package:SPL related
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
one more :
$a = array('b' => "test");
$b = new ArrayObject($a);
var_dump(isset($b->b));
outputed : bool(false)
should this be true?
Previous Comments:
----
[2012-03-11 05:38:30] larue...@php.net
these codes are weired(spl_array.c:603):
switch(Z_TYPE_P(offset)) {
case IS_STRING:
if (check_empty) {
if (zend_symtable_find(spl_array_get_hash_table(intern, 0
TSRMLS_CC), Z_STRVAL_P(offset), Z_STRLEN_P(offset)+1, (void **) &tmp) !=
FAILURE) {
switch (check_empty) {
case 0:
return Z_TYPE_PP(tmp) != IS_NULL;
case 2:
return 1;
default:
return zend_is_true(*tmp);
}
}
return 0;
} else {
return zend_symtable_exists(spl_array_get_hash_table(intern, 0
TSRMLS_CC), Z_STRVAL_P(offset), Z_STRLEN_P(offset)+1);
}
note the switch statement, there is no chance check_empty will be 0, since
there
is a if(check_empty) before.
and, I don't see any chance that the check_empty could be 2.
any idea? thanks
----
[2012-03-11 05:17:21] larue...@php.net
Description:
isset(arrayobject['index']) act inconsistently with isset(array['index'])
Test script:
---
NULL);
var_dump(isset($a['b']));
$b = new ArrayObject($a);
var_dump(isset($b['b']));
Expected result:
bool(false)
bool(false)
Actual result:
--
bool(false)
bool(true)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61347&edit=1
Bug #61484 [Com]: iconv //IGNORE option doesn't work anymore in PHP5.4
Edit report at https://bugs.php.net/bug.php?id=61484&edit=1
ID: 61484
Comment by: larue...@php.net
Reported by:juzna dot cz at gmail dot com
Summary:iconv //IGNORE option doesn't work anymore in PHP5.4
Status: Open
Type: Bug
Package:ICONV related
Operating System: Ubuntu
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
see http://sources.redhat.com/bugzilla/show_bug.cgi?id=13518
Previous Comments:
[2012-03-23 07:01:36] larue...@php.net
this should be a issue of glibc, but I am not sure since when it has been
changed. :(
[2012-03-22 23:59:36] juzna dot cz at gmail dot com
Description:
When adding "//IGNORE" to target encoding in iconv function, wrong characters
should be skipped. This worked in PHP 5.3, but doesn't work anymore in 5.4.
I just compiled 5.3.10, where it works fine. Doesn't work on 5.4.0 nor on 5.4.1-
RC1.
Test script:
---
var_dump(iconv('UTF-8', 'UTF-16//IGNORE',
"\xc5\xbea\x01b\xed\xa0\x80c\xef\xbb\xbfd\xf4\x90\x80\x80e"));
Expected result:
string(18) "��~abc��de"
Actual result:
--
bool(false)
--
Edit this bug report at https://bugs.php.net/bug.php?id=61484&edit=1
Req #60738 [PATCH]: Allow 'set_error_handler' to handle NULL
Edit report at https://bugs.php.net/bug.php?id=60738&edit=1
ID: 60738
Patch added by: larue...@php.net
Reported by:four dot zerooneunauthorized at gmail dot com
Summary:Allow 'set_error_handler' to handle NULL
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: irrelivant
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60738.patch
Revision: 1332559481
URL:
https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559481
Previous Comments:
[2012-03-23 20:50:45] ni...@php.net
The following patch has been added/updated:
Patch Name: error_handler_patch_1.diff
Revision: 1332535845
URL:
https://bugs.php.net/patch-display.php?bug=60738&patch=error_handler_patch_1.diff&revision=1332535845
[2012-03-13 08:56:27] kevin dot swinton at gmail dot com
In the first instance, nothing in here relates to a bug, rather both are
feature requests.
The first request is for set_error_handler() to function in an identical way to
set_exception_handler() when called with a single NULL parameter. In the
interests of a more consistent API this would seem sensible.
The second request is for set_exception_handler() (and by extension
set_error_handler()) to behave in a different way when called with a single
NULL parameter.
Given there is no compelling argument, and that such a change could technically
break BC, and that the request in itself doesn't appear to achieve anything
useful, the suggestion would be that the first request could be implemented
whilst the second request has no case.
As a result, I have attached a patch to implement only the first request.
[2012-01-13 02:22:55] four dot zerooneunauthorized at gmail dot com
Description:
Can the 'set_error_handler' function be made to accept NULL as the parameter in
such a way as to reset this feature to the default state of -no- handler being
set? This would duplicate the behavior of the 'set_exception_handler' function.
Note: this change should not interfere with the 'restore_error_handler'
function.
And as for the 'set_exception_handler' function - if NULL is given as a
parameter, can the return value of 'set_exception_handler' be set to the
details of the previously set exception handler function (string or array)
instead of always '(bool) true' as it now does?
Test script:
---
function testhandler1($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('1: ' . print_r(func_get_args(), true));
die();
}
function testhandler2($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('2: ' . print_r(func_get_args(), true));
die();
}
var_dump(set_error_handler('testhandler1'));
var_dump(set_error_handler('testhandler2'));
var_dump(set_error_handler(null));
Expected result:
NULL
string(12) "testhandler1"
string(12) "testhandler2"
Actual result:
--
On line 'var_dump(set_error_handler(null));', a 'set_error_handler() expects
the argument () to be a valid callback' error is generated and handled by
function "testhandler2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60738&edit=1
Req #60738 [PATCH]: Allow 'set_error_handler' to handle NULL
Edit report at https://bugs.php.net/bug.php?id=60738&edit=1
ID: 60738
Patch added by: larue...@php.net
Reported by:four dot zerooneunauthorized at gmail dot com
Summary:Allow 'set_error_handler' to handle NULL
Status: Open
Type: Feature/Change Request
Package:Unknown/Other Function
Operating System: irrelivant
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug60738.patch
Revision: 1332559848
URL:
https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559848
Previous Comments:
[2012-03-24 03:26:17] larue...@php.net
Hi, I attached another fix, this will save one alloc/free pair, and also save
one
(IS_NULL == Z_TYPE_P(error_handler).
Nikic, if you have no objection, I will commit the patch.
thanks
[2012-03-24 03:24:41] larue...@php.net
The following patch has been added/updated:
Patch Name: bug60738.patch
Revision: 1332559481
URL:
https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559481
[2012-03-23 20:50:45] ni...@php.net
The following patch has been added/updated:
Patch Name: error_handler_patch_1.diff
Revision: 1332535845
URL:
https://bugs.php.net/patch-display.php?bug=60738&patch=error_handler_patch_1.diff&revision=1332535845
[2012-03-13 08:56:27] kevin dot swinton at gmail dot com
In the first instance, nothing in here relates to a bug, rather both are
feature requests.
The first request is for set_error_handler() to function in an identical way to
set_exception_handler() when called with a single NULL parameter. In the
interests of a more consistent API this would seem sensible.
The second request is for set_exception_handler() (and by extension
set_error_handler()) to behave in a different way when called with a single
NULL parameter.
Given there is no compelling argument, and that such a change could technically
break BC, and that the request in itself doesn't appear to achieve anything
useful, the suggestion would be that the first request could be implemented
whilst the second request has no case.
As a result, I have attached a patch to implement only the first request.
[2012-01-13 02:22:55] four dot zerooneunauthorized at gmail dot com
Description:
Can the 'set_error_handler' function be made to accept NULL as the parameter in
such a way as to reset this feature to the default state of -no- handler being
set? This would duplicate the behavior of the 'set_exception_handler' function.
Note: this change should not interfere with the 'restore_error_handler'
function.
And as for the 'set_exception_handler' function - if NULL is given as a
parameter, can the return value of 'set_exception_handler' be set to the
details of the previously set exception handler function (string or array)
instead of always '(bool) true' as it now does?
Test script:
---
function testhandler1($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('1: ' . print_r(func_get_args(), true));
die();
}
function testhandler2($errno= null, $errstr= null, $errfile= null, $errline =
null)
{
error_log('2: ' . print_r(func_get_args(), true));
die();
}
var_dump(set_error_handler('testhandler1'));
var_dump(set_error_handler('testhandler2'));
var_dump(set_error_handler(null));
Expected result:
NULL
string(12) "testhandler1"
string(12) "testhandler2"
Actual result:
--
On line 'var_dump(set_error_handler(null));', a 'set_error_handler() expects
the argument () to be a valid callback' error is generated and handled by
function "testhandler2"
--
Edit this bug report at https://bugs.php.net/bug.php?id=60738&edit=1
Req #60738 [PATCH]: Allow 'set_error_handler' to handle NULL
Edit report at https://bugs.php.net/bug.php?id=60738&edit=1 ID: 60738 Patch added by: larue...@php.net Reported by:four dot zerooneunauthorized at gmail dot com Summary:Allow 'set_error_handler' to handle NULL Status: Open Type: Feature/Change Request Package:Unknown/Other Function Operating System: irrelivant PHP Version:5.3.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332559920 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559920 Previous Comments: [2012-03-24 03:30:48] larue...@php.net The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332559848 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559848 ---- [2012-03-24 03:26:17] larue...@php.net Hi, I attached another fix, this will save one alloc/free pair, and also save one (IS_NULL == Z_TYPE_P(error_handler). Nikic, if you have no objection, I will commit the patch. thanks ---- [2012-03-24 03:24:41] larue...@php.net The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332559481 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559481 [2012-03-23 20:50:45] ni...@php.net The following patch has been added/updated: Patch Name: error_handler_patch_1.diff Revision: 1332535845 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=error_handler_patch_1.diff&revision=1332535845 [2012-03-13 08:56:27] kevin dot swinton at gmail dot com In the first instance, nothing in here relates to a bug, rather both are feature requests. The first request is for set_error_handler() to function in an identical way to set_exception_handler() when called with a single NULL parameter. In the interests of a more consistent API this would seem sensible. The second request is for set_exception_handler() (and by extension set_error_handler()) to behave in a different way when called with a single NULL parameter. Given there is no compelling argument, and that such a change could technically break BC, and that the request in itself doesn't appear to achieve anything useful, the suggestion would be that the first request could be implemented whilst the second request has no case. As a result, I have attached a patch to implement only the first 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=60738 -- Edit this bug report at https://bugs.php.net/bug.php?id=60738&edit=1
Req #60738 [PATCH]: Allow 'set_error_handler' to handle NULL
Edit report at https://bugs.php.net/bug.php?id=60738&edit=1 ID: 60738 Patch added by: larue...@php.net Reported by:four dot zerooneunauthorized at gmail dot com Summary:Allow 'set_error_handler' to handle NULL Status: Open Type: Feature/Change Request Package:Unknown/Other Function Operating System: irrelivant PHP Version:5.3.9 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332562646 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332562646 Previous Comments: [2012-03-24 03:32:00] larue...@php.net The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332559920 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559920 ---- [2012-03-24 03:30:48] larue...@php.net The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332559848 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559848 ---- [2012-03-24 03:26:17] larue...@php.net Hi, I attached another fix, this will save one alloc/free pair, and also save one (IS_NULL == Z_TYPE_P(error_handler). Nikic, if you have no objection, I will commit the patch. thanks ---- [2012-03-24 03:24:41] larue...@php.net The following patch has been added/updated: Patch Name: bug60738.patch Revision: 1332559481 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=bug60738.patch&revision=1332559481 [2012-03-23 20:50:45] ni...@php.net The following patch has been added/updated: Patch Name: error_handler_patch_1.diff Revision: 1332535845 URL: https://bugs.php.net/patch-display.php?bug=60738&patch=error_handler_patch_1.diff&revision=1332535845 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=60738 -- Edit this bug report at https://bugs.php.net/bug.php?id=60738&edit=1
Bug #61529 [PATCH]: Parsing error
Edit report at https://bugs.php.net/bug.php?id=61529&edit=1 ID: 61529 Patch added by: larue...@php.net Reported by:asserte at gmail dot com Summary:Parsing error Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.1RC/5.5.0-dev Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61529.patch Revision: 1333025364 URL: https://bugs.php.net/patch-display.php?bug=61529&patch=bug61529.patch&revision=1333025364 Previous Comments: [2012-03-28 08:51:33] yohg...@php.net Verified. $ php -r '1 && unset($var["a"]);' is enough. -- [yohgaki@dev php-src]$ ./sapi/cli/php -v PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies [yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var["a"]);' [yohgaki@dev php-src]$ ./sapi/cli/php -r '1 && unset($var["a"]);' Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on line 1 -- [2012-03-27 13:49:14] asserte at gmail dot com Move to SE problems [2012-03-27 13:45:26] asserte at gmail dot com Description: isset() && unset() PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in /tmp/isset.php on line 4 Tested on PHP 5.4.0-3 (cli) (built: Mar 22 2012 07:59:57) Test script: --- $> cat /tmp/isset.php 1 1, 'name' => 'example'); 4 isset( $entity['id'] ) && unset( $entity['id'] ); $> php /tmp/isset.php PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in /tmp/isset.php on line 3 Expected result: unset should works. -- Edit this bug report at https://bugs.php.net/bug.php?id=61529&edit=1
Bug #61529 [Com]: Parsing error
Edit report at https://bugs.php.net/bug.php?id=61529&edit=1 ID: 61529 Comment by: larue...@php.net Reported by:asserte at gmail dot com Summary:Parsing error Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.1RC/5.5.0-dev Assigned To:dmitry Block user comment: N Private report: N New Comment: Dmitry, could you review my patch for this bug plz? thanks Previous Comments: [2012-03-29 12:49:24] larue...@php.net The following patch has been added/updated: Patch Name: bug61529.patch Revision: 1333025364 URL: https://bugs.php.net/patch-display.php?bug=61529&patch=bug61529.patch&revision=1333025364 [2012-03-28 08:51:33] yohg...@php.net Verified. $ php -r '1 && unset($var["a"]);' is enough. -- [yohgaki@dev php-src]$ ./sapi/cli/php -v PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies [yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var["a"]);' [yohgaki@dev php-src]$ ./sapi/cli/php -r '1 && unset($var["a"]);' Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on line 1 -- [2012-03-27 13:49:14] asserte at gmail dot com Move to SE problems [2012-03-27 13:45:26] asserte at gmail dot com Description: isset() && unset() PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in /tmp/isset.php on line 4 Tested on PHP 5.4.0-3 (cli) (built: Mar 22 2012 07:59:57) Test script: --- $> cat /tmp/isset.php 1 1, 'name' => 'example'); 4 isset( $entity['id'] ) && unset( $entity['id'] ); $> php /tmp/isset.php PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in /tmp/isset.php on line 3 Expected result: unset should works. -- Edit this bug report at https://bugs.php.net/bug.php?id=61529&edit=1
Bug #61529 [PATCH]: Parsing error
Edit report at https://bugs.php.net/bug.php?id=61529&edit=1 ID: 61529 Patch added by: larue...@php.net Reported by:asserte at gmail dot com Summary:Parsing error Status: Verified Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.4.1RC/5.5.0-dev Assigned To:dmitry Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61529.phpt Revision: 1333025478 URL: https://bugs.php.net/patch-display.php?bug=61529&patch=bug61529.phpt&revision=1333025478 Previous Comments: [2012-03-29 12:49:51] larue...@php.net Dmitry, could you review my patch for this bug plz? thanks [2012-03-29 12:49:24] larue...@php.net The following patch has been added/updated: Patch Name: bug61529.patch Revision: 1333025364 URL: https://bugs.php.net/patch-display.php?bug=61529&patch=bug61529.patch&revision=1333025364 [2012-03-28 08:51:33] yohg...@php.net Verified. $ php -r '1 && unset($var["a"]);' is enough. -- [yohgaki@dev php-src]$ ./sapi/cli/php -v PHP 5.5.0-dev (cli) (built: Mar 28 2012 17:33:51) (DEBUG) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2012 Zend Technologies [yohgaki@dev php-src]$ ./sapi/cli/php -r 'unset($var["a"]);' [yohgaki@dev php-src]$ ./sapi/cli/php -r '1 && unset($var["a"]);' Parse error: syntax error, unexpected 'unset' (T_UNSET) in Command line code on line 1 -- [2012-03-27 13:49:14] asserte at gmail dot com Move to SE problems [2012-03-27 13:45:26] asserte at gmail dot com Description: isset() && unset() PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in /tmp/isset.php on line 4 Tested on PHP 5.4.0-3 (cli) (built: Mar 22 2012 07:59:57) Test script: --- $> cat /tmp/isset.php 1 1, 'name' => 'example'); 4 isset( $entity['id'] ) && unset( $entity['id'] ); $> php /tmp/isset.php PHP Parse error: syntax error, unexpected 'unset' (T_UNSET), expecting ')' in /tmp/isset.php on line 3 Expected result: unset should works. -- Edit this bug report at https://bugs.php.net/bug.php?id=61529&edit=1
[PHP-BUG] Bug #61617 [NEW]: Libxml tests failed(ht is already destroyed)
From: laruence Operating system: PHP version: 5.4.0 Package: *XML functions Bug Type: Bug Bug description:Libxml tests failed(ht is already destroyed) Description: Two tests faild in php debug mode. libxml_set_streams_context() [ext/libxml/tests/004.phpt] Bug #54440: libxml extension ignores default context[ext/libxml/tests/bug54440.phpt] Test script: --- libxml_set_streams_context() [ext/libxml/tests/004.phpt] Bug #54440: libxml extension ignores default context[ext/libxml/tests/bug54440.phpt] Expected result: pass Actual result: -- ht=0x1183710 is already destroyed -- Edit bug report at https://bugs.php.net/bug.php?id=61617&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61617&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61617&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61617&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61617&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61617&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61617&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61617&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61617&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61617&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61617&r=support Expected behavior: https://bugs.php.net/fix.php?id=61617&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61617&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61617&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61617&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61617&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61617&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61617&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61617&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61617&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61617&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61617&r=mysqlcfg
[PHP-BUG] Bug #61649 [NEW]: zend gc should not mark persistent hashtable
From: laruence
Operating system:
PHP version: 5.3.10
Package: Scripting Engine problem
Bug Type: Bug
Bug description:zend gc should not mark persistent hashtable
Description:
zend gc was introducted in 5.3
thinking of a zval which is a Hashtable allocated by a extension in
persistent,
and it also has hashtable children in it,
then , if the extension return this to php script:
array_init(return_value);
zend_hash_copy(Z_ARRVAL_P(return_value),
Z_ARRVAL_P(persitent_zval_hashtable),
***)..
since zval_copy_ctor does shallow copy, so the persistent array return to
the
php
script.
then if it happen to be parsed by zval_ptr_dtor, then the persistent array
will
be
parsed by gc_zval_possible_root,
ZEND_API void gc_zval_possible_root(zval *zv TSRMLS_DC)
{
..
if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) {
GC_ZVAL_SET_PURPLE(zv);
..
then the malloc info of the block(not sure before or after) will be
polluted.
then when the extension try to free the block, a warning will be show
like:
munmap_chunk(): invalid pointer 0x***
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit bug report at https://bugs.php.net/bug.php?id=61649&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=61649&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=61649&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=61649&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=61649&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=61649&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=61649&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=61649&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=61649&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=61649&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=61649&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=61649&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=61649&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=61649&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=61649&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=61649&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=61649&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=61649&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=61649&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=61649&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=61649&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=61649&r=mysqlcfg
Bug #61649 [PATCH]: zend gc should not mark persistent hashtable
Edit report at https://bugs.php.net/bug.php?id=61649&edit=1
ID: 61649
Patch added by: larue...@php.net
Reported by:larue...@php.net
Summary:zend gc should not mark persistent hashtable
Status: Open
Type: Bug
Package:Scripting Engine problem
PHP Version:5.3.10
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61649.patch
Revision: 1333714735
URL:
https://bugs.php.net/patch-display.php?bug=61649&patch=bug61649.patch&revision=1333714735
Previous Comments:
[2012-04-06 12:17:59] larue...@php.net
Description:
zend gc was introducted in 5.3
thinking of a zval which is a Hashtable allocated by a extension in persistent,
and it also has hashtable children in it,
then , if the extension return this to php script:
array_init(return_value);
zend_hash_copy(Z_ARRVAL_P(return_value), Z_ARRVAL_P(persitent_zval_hashtable),
***)..
since zval_copy_ctor does shallow copy, so the persistent array return to the
php
script.
then if it happen to be parsed by zval_ptr_dtor, then the persistent array will
be
parsed by gc_zval_possible_root,
ZEND_API void gc_zval_possible_root(zval *zv TSRMLS_DC)
{
..
if (GC_ZVAL_GET_COLOR(zv) != GC_PURPLE) {
GC_ZVAL_SET_PURPLE(zv);
..
then the malloc info of the block(not sure before or after) will be polluted.
then when the extension try to free the block, a warning will be show like:
munmap_chunk(): invalid pointer 0x***
Test script:
---
none
Expected result:
none
Actual result:
--
none
--
Edit this bug report at https://bugs.php.net/bug.php?id=61649&edit=1
[PHP-BUG] Bug #61681 [NEW]: Malformed grammar
From: laruence Operating system: PHP version: 5.3.10 Package: *General Issues Bug Type: Bug Bug description:Malformed grammar Description: if use '@', you can call function in a string substitution context. Test script: --- https://bugs.php.net/bug.php?id=61681&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61681&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61681&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61681&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61681&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61681&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61681&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61681&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61681&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61681&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61681&r=support Expected behavior: https://bugs.php.net/fix.php?id=61681&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61681&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61681&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61681&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61681&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61681&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61681&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61681&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61681&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61681&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61681&r=mysqlcfg
Bug #61697 [PATCH]: spl_autoload_functions returns lambda functions incorrectly
Edit report at https://bugs.php.net/bug.php?id=61697&edit=1 ID: 61697 Patch added by: larue...@php.net Reported by:stadli at gmx dot de Summary:spl_autoload_functions returns lambda functions incorrectly Status: Open Type: Bug Package:SPL related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61697.patch Revision: 1334207765 URL: https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.patch&revision=1334207765 Previous Comments: [2012-04-11 18:29:18] stadli at gmx dot de Description: spl_autoload_functions() doesn't return the names of lambda-functions registered with spl_autoload_register() correctly. Actually it always returns '__lambda_func' for every lambda function so you can't use the result with spl_autoload_unregister() for example. Test script: --- Expected result: All autoload functions are unregistered Actual result: -- lambda functions aren't unregistered -- Edit this bug report at https://bugs.php.net/bug.php?id=61697&edit=1
Bug #61697 [PATCH]: spl_autoload_functions returns lambda functions incorrectly
Edit report at https://bugs.php.net/bug.php?id=61697&edit=1 ID: 61697 Patch added by: larue...@php.net Reported by:stadli at gmx dot de Summary:spl_autoload_functions returns lambda functions incorrectly Status: Open Type: Bug Package:SPL related PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61697.phpt Revision: 1334207979 URL: https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.phpt&revision=1334207979 Previous Comments: [2012-04-12 05:16:05] larue...@php.net The following patch has been added/updated: Patch Name: bug61697.patch Revision: 1334207765 URL: https://bugs.php.net/patch-display.php?bug=61697&patch=bug61697.patch&revision=1334207765 [2012-04-11 18:29:18] stadli at gmx dot de Description: spl_autoload_functions() doesn't return the names of lambda-functions registered with spl_autoload_register() correctly. Actually it always returns '__lambda_func' for every lambda function so you can't use the result with spl_autoload_unregister() for example. Test script: --- Expected result: All autoload functions are unregistered Actual result: -- lambda functions aren't unregistered -- Edit this bug report at https://bugs.php.net/bug.php?id=61697&edit=1
Bug #61728 [PATCH]: php-fpm SIGSEGV running friendica on nginx
Edit report at https://bugs.php.net/bug.php?id=61728&edit=1 ID: 61728 Patch added by: larue...@php.net Reported by:frederik_php at vanrenterghem dot biz Summary:php-fpm SIGSEGV running friendica on nginx Status: Open Type: Bug Package:Reproducible crash Operating System: Linux Debian Wheezy PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61728.phpt Revision: 1334422666 URL: https://bugs.php.net/patch-display.php?bug=61728&patch=bug61728.phpt&revision=1334422666 Previous Comments: [2012-04-14 15:13:47] frederik_php at vanrenterghem dot biz I get the same error on apache2: Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal 11, Segmentation fault. #0 0xb5cf371d in zend_stack_push (stack=, element=, size=) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_stack.c:42 42 /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_stack.c: No such file or directory. (gdb) bt #0 0xb5cf371d in zend_stack_push (stack=, element=, size=) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_stack.c:42 #1 0xb5ca1c1c in php_output_handler_start (handler=0xb5ca06d0) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/main/output.c:563 #2 0xb5ca413b in php_output_start_default () at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/main/output.c:412 #3 0xb5c0a0dd in zif_print_r (ht=-1295141216, return_value=0x0, return_value_ptr=0x0, this_ptr=0x1, return_value_used=-1228621212) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/standard/basic_functions.c:5496 #4 0xb5da40b1 in zend_do_fcall_common_helper_SPEC (execute_data=0xb6c1e908) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_vm_execute.h:642 #5 0xb5d5fc75 in execute (op_array=0xb5ce70c6) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_vm_execute.h:410 #6 0xb5ce70c6 in zend_call_function (fci=0x7, fci_cache=0xb61cc7c4) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_execute_API.c:958 #7 0xb5ce7463 in call_user_function_ex (function_table=0xb82d57f8, object_pp=0x0, function_name=0xb2c89c18, retval_ptr_ptr=0xbfbeb81c, param_count=, params=0xb6c361a4, no_separation=1, symbol_table=0x0) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_execute_API.c:750 #8 0xb5ce74d8 in call_user_function (function_table=0x0, object_pp=0xb2c89c18, function_name=0xb2d59274, retval_ptr=0x2, param_count=, params=0xb) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_execute_API.c:723 #9 0xb5b76fa0 in ps_call_handler (func=0xb2c89c18, argc=2, argv=0x13b) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/mod_user.c:53 #10 0xb5b771fe in ps_write_user (mod_data=0xb5b6f4e5, key=0xb61c8a94 "", val=0xb6c41214 "qm2ukkgs12n6ftusrqrihd9qo2", vallen=-1296104456) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/mod_user.c:144 #11 0xb5b6f4e5 in php_session_flush () at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/session.c:489 #12 0xb5b703b5 in zm_deactivate_session (type=-1239763244, module_number=-1078019424) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/session.c:2144 #13 0xb5cfc684 in zend_deactivate_modules () at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_API.c:2328 #14 0xb5c8e5d5 in php_request_shutdown (dummy=0xb630c838) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/main/main.c:1755 #15 0xb5da6824 in php_handler (r=0xb630f4c0) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/sapi/apache2handler/sapi_apache2.c:520 #16 0xb77945be in ap_run_handler (r=0xb630f4c0) at config.c:159 #17 0xb7794a36 in ap_invoke_handler (r=0xb630f4c0) at config.c:377 #18 0xb77a5efc in ap_internal_redirect (new_uri=0xb630f490 "/index.php?q=admin/plugins/facebook/&a=t", r=0xb631d058) at http_request.c:554 #19 0xb6c93d96 in handler_redirect (r=0xb631d058) at mod_rewrite.c:4860 #20 0xb77945be in ap_run_handler (r=0xb631d058) at config.c:159 #21 0xb7794a36 in ap_invoke_handler (r=0xb631d058) at config.c:377 #22 0xb77a6878 in ap_process_request (r=0xb631d058) at http_request.c:282 #23 0xb77a3350 in ap_process_http_connection (c=0xb6bb81f0) at http_core.c:190 #24 0xb779bbce in ap_run_process_connection (c=0xb6bb81f0) at connection.c:43 #25 0xb77ac125 in child_main (child_num_arg=) at prefork.c:667 #26 0xb77aca83 in make_child (slot=0, s=) at prefork.c:768 #27 make_child (s=, slot=0) at prefork.c:696 #28 0xb77acb5c in startup_children (number_to_start=5) at prefork.c:786 #2
Bug #61728 [PATCH]: php-fpm SIGSEGV running friendica on nginx
Edit report at https://bugs.php.net/bug.php?id=61728&edit=1 ID: 61728 Patch added by: larue...@php.net Reported by:frederik_php at vanrenterghem dot biz Summary:php-fpm SIGSEGV running friendica on nginx Status: Open Type: Bug Package:Reproducible crash Operating System: Linux Debian Wheezy PHP Version:5.4.0 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug61728.patch Revision: 1334422683 URL: https://bugs.php.net/patch-display.php?bug=61728&patch=bug61728.patch&revision=1334422683 Previous Comments: [2012-04-14 16:57:46] larue...@php.net The following patch has been added/updated: Patch Name: bug61728.phpt Revision: 1334422666 URL: https://bugs.php.net/patch-display.php?bug=61728&patch=bug61728.phpt&revision=1334422666 [2012-04-14 15:13:47] frederik_php at vanrenterghem dot biz I get the same error on apache2: Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal 11, Segmentation fault. #0 0xb5cf371d in zend_stack_push (stack=, element=, size=) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_stack.c:42 42 /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_stack.c: No such file or directory. (gdb) bt #0 0xb5cf371d in zend_stack_push (stack=, element=, size=) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_stack.c:42 #1 0xb5ca1c1c in php_output_handler_start (handler=0xb5ca06d0) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/main/output.c:563 #2 0xb5ca413b in php_output_start_default () at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/main/output.c:412 #3 0xb5c0a0dd in zif_print_r (ht=-1295141216, return_value=0x0, return_value_ptr=0x0, this_ptr=0x1, return_value_used=-1228621212) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/standard/basic_functions.c:5496 #4 0xb5da40b1 in zend_do_fcall_common_helper_SPEC (execute_data=0xb6c1e908) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_vm_execute.h:642 #5 0xb5d5fc75 in execute (op_array=0xb5ce70c6) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_vm_execute.h:410 #6 0xb5ce70c6 in zend_call_function (fci=0x7, fci_cache=0xb61cc7c4) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_execute_API.c:958 #7 0xb5ce7463 in call_user_function_ex (function_table=0xb82d57f8, object_pp=0x0, function_name=0xb2c89c18, retval_ptr_ptr=0xbfbeb81c, param_count=, params=0xb6c361a4, no_separation=1, symbol_table=0x0) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_execute_API.c:750 #8 0xb5ce74d8 in call_user_function (function_table=0x0, object_pp=0xb2c89c18, function_name=0xb2d59274, retval_ptr=0x2, param_count=, params=0xb) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_execute_API.c:723 #9 0xb5b76fa0 in ps_call_handler (func=0xb2c89c18, argc=2, argv=0x13b) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/mod_user.c:53 #10 0xb5b771fe in ps_write_user (mod_data=0xb5b6f4e5, key=0xb61c8a94 "", val=0xb6c41214 "qm2ukkgs12n6ftusrqrihd9qo2", vallen=-1296104456) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/mod_user.c:144 #11 0xb5b6f4e5 in php_session_flush () at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/session.c:489 #12 0xb5b703b5 in zm_deactivate_session (type=-1239763244, module_number=-1078019424) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/ext/session/session.c:2144 #13 0xb5cfc684 in zend_deactivate_modules () at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/Zend/zend_API.c:2328 #14 0xb5c8e5d5 in php_request_shutdown (dummy=0xb630c838) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/main/main.c:1755 #15 0xb5da6824 in php_handler (r=0xb630f4c0) at /build/buildd-php5_5.4.1~rc1-1-i386-2yRNQU/php5-5.4.1~rc1/sapi/apache2handler/sapi_apache2.c:520 #16 0xb77945be in ap_run_handler (r=0xb630f4c0) at config.c:159 #17 0xb7794a36 in ap_invoke_handler (r=0xb630f4c0) at config.c:377 #18 0xb77a5efc in ap_internal_redirect (new_uri=0xb630f490 "/index.php?q=admin/plugins/facebook/&a=t", r=0xb631d058) at http_request.c:554 #19 0xb6c93d96 in handler_redirect (r=0xb631d058) at mod_rewrite.c:4860 #20 0xb77945be in ap_run_handler (r=0xb631d058) at config.c:159 #21 0xb7794a36 in ap_invoke_handler (r=0xb631d058) at config.c:377 #22 0xb77a6878 in ap_process_request (r=0xb631d058) at http_request.c:282 #23 0xb77a3350 in ap_process_http_connection (c=0xb6bb81f0) at http_core.c:190 #2
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 #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 #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
[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 #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
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 #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 #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 #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 [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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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
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 #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
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
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 #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 #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 #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 #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 #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 #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
[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 #61767 [PATCH]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Patch added by: larue...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Open
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: bug61767.patch
Revision: 1334901670
URL:
https://bugs.php.net/patch-display.php?bug=61767&patch=bug61767.patch&revision=1334901670
Previous Comments:
[2012-04-20 05:52:05] larue...@php.net
a E_NOTICE "undefined variable" has been triggered before the FATAL_ERROR.
hmm,
the same thing as #60909
[2012-04-19 22:56:56] ni...@php.net
This seems related: https://bugs.php.net/bug.php?id=60909
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
[2012-04-18 18:39:02] shiranai7 at hotmail dot com
Description:
I am using register_shutdown_function() toghether with error_get_last() and
set_error_handler() to "handle" fatal errors (to display message in debug
screen etc, details do not matter).
Everything works perfectly except for one specific scenario - If there is an
error caused by calling a method on UNDEFINED (really undefined, not null etc)
variable, then the following happens (NOT OK, UNEXPECTED):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler throws an ErrorException
3. the exception gets *eaten* by something, it never makes it out of the
error_handler
4. PHP exits with FATAL error (Call to a member function foo() on a non-object)
5. No shutdown functions get called
If the variable is not UNDEFINED but just not an object (e.g. null), everything
happens as follows (ALL OK, EXPECTED):
1. PHP exits with FATAL error (Call to a member function foo() on a non-object)
2. Registered shutdown functions are called
If I return TRUE from the error_handler, following happens (OK, BUT NOT
ACCEPTABLE):
1. registered error_handler is invoked for E_NOTICE (undefined variable)
2. the error_handler returns TRUE
3. PHP exits with FATAL error (Call to a member function foo() on a non-object)
4. Registered shutdown functions are called
Test script:
---
set_error_handler(function($code, $msg, $file = null, $line = null) {
echo "Error handler called\n";
throw new \ErrorException($msg, $code, 0, $file, $line);
});
register_shutdown_function(function(){
echo "Shutting down\n";
print_r(error_get_last());
});
// $undefined = null; // defined variable does not cause problems
$undefined->foo();
Expected result:
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 14
Shutting down Array ( [type] => 1 [message] => Call to a member function foo()
on a non-object [file] => _example_ [line] => 14 )
Actual result:
--
Error handler called
Fatal error: Call to a member function foo() on a non-object in _example_ on
line 13
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
Bug #61767 [PATCH]: Shutdown functions not called in certain error situation
Edit report at https://bugs.php.net/bug.php?id=61767&edit=1
ID: 61767
Patch added by: larue...@php.net
Reported by:shiranai7 at hotmail dot com
Summary:Shutdown functions not called in certain error
situation
Status: Analyzed
Type: Bug
Package:Scripting Engine problem
Operating System: Win7
PHP Version:5.4.0
Block user comment: N
Private report: N
New Comment:
The following patch has been added/updated:
Patch Name: another_fix_for_bug61767.patch
Revision: 1334915414
URL:
https://bugs.php.net/patch-display.php?bug=61767&patch=another_fix_for_bug61767.patch&revision=1334915414
Previous Comments:
[2012-04-20 06:02:25] larue...@php.net
I attached a fix for this, maybe need dmitry to review it.
[2012-04-20 06:01:10] larue...@php.net
The following patch has been added/updated:
Patch Name: bug61767.patch
Revision: 1334901670
URL:
https://bugs.php.net/patch-display.php?bug=61767&patch=bug61767.patch&revision=1334901670
[2012-04-20 05:52:05] larue...@php.net
a E_NOTICE "undefined variable" has been triggered before the FATAL_ERROR.
hmm,
the same thing as #60909
[2012-04-19 22:56:56] ni...@php.net
This seems related: https://bugs.php.net/bug.php?id=60909
[2012-04-19 09:07:06] shiranai7 at hotmail dot com
Allow me to re-specify the expected result:
--
Error handler called
Fatal error: Uncaught exception 'ErrorException' with message 'Undefined
variable: undefined' in C:\Dokumenty\localhost\base\test_case1.php:14 Stack
trace: #0 _example_(14): {closure}(8, 'Undefined varia...',
'C:\Dokumenty\lo...', 14, Array) #1 {main} thrown in
C:\Dokumenty\localhost\base\test_case1.php on line 14
Shutting down Array ( [type] => 1 [message] => Uncaught exception
'ErrorException' with message 'Undefined variable: undefined' in _example_:14
Stack trace: ... [file] => _example_ [line] => 14 )
--
This is because the error_handler gets actually called for the E_NOTICE - so an
exception should be thrown (and later uncaught in the example). But the
exception gets *eaten* as I described.
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=61767
--
Edit this bug report at https://bugs.php.net/bug.php?id=61767&edit=1
[PHP-BUG] Bug #61810 [NEW]: ext/dom/tests/dom007.phpt failed
From: laruence Operating system: PHP version: 5.3.10 Package: Testing related Bug Type: Bug Bug description:ext/dom/tests/dom007.phpt failed Description: EXPECTED OUTPUT Length: 1 Key GIF: GIF (image/gif) (-) Index 0: GIF (image/gif) (-) NULL Length: 3 Key: test Name: test Key: rdf Name: rdf Key: myimage Name: myimage Index 0: test Index 1: rdf Index 2: myimage NULL NULL ACTUAL OUTPUT Length: 1 Key GIF: GIF (image/gif) (-) Index 0: GIF (image/gif) (-) NULL Length: 3 Key: myimage Name: myimage Key: rdf Name: rdf Key: test Name: test Index 0: myimage Index 1: rdf Index 2: test NULL NULL FAILED -- Edit bug report at https://bugs.php.net/bug.php?id=61810&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=61810&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=61810&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=61810&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=61810&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=61810&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=61810&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=61810&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=61810&r=needscript Try newer version: https://bugs.php.net/fix.php?id=61810&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=61810&r=support Expected behavior: https://bugs.php.net/fix.php?id=61810&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=61810&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=61810&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=61810&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=61810&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=61810&r=dst IIS Stability: https://bugs.php.net/fix.php?id=61810&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=61810&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=61810&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=61810&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=61810&r=mysqlcfg
