Bug #60825 [Com]: Segfault when running symfony 2 tests
Edit report at https://bugs.php.net/bug.php?id=60825&edit=1
ID: 60825
Comment by: php at wallbash dot com
Reported by:php at wallbash dot com
Summary:Segfault when running symfony 2 tests
Status: Critical
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu 10.04.3 LTS
PHP Version:5.4.0RC6
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Yes. It is that function that cases the crash rasmus.
Compiling php-5.4 from current SVN the tests run just fine :)
Regards,
Edorian
Previous Comments:
[2012-01-21 05:23:50] ras...@php.net
Can you try reproducing with the current svn code?
I went through the reproduce steps and the unit tests ran to completion for me.
However, under Valgrind I did get some complaints for one of the tests. Can you
tell if your crash is on this same test?
Starting test
'Symfony\Bundle\SecurityBundle\Tests\Functional\FormLoginTest::testFormLogin
with data set #0 ('config.yml')'.
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DE434: zend_call_function (zend_execute_API.c:925)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9F2AEF: zend_execute_scripts (zend.c:1272)
==24587==
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DBB70: _zval_ptr_dtor (zend_execute_API.c:433)
==24587==by 0x9DED15: zend_call_function (zend_execute_API.c:1019)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DBC28: _zval_ptr_dtor (zend_execute_API.c:444)
==24587==by 0x9DED15: zend_call_function (zend_execute_API.c:1019)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
[2012-01-21 04:59:45] ras...@php.net
Stas, this looks like a blocker for 5.4
[2012-01-20 20:20:21] php at wallbash dot com
Description:
First off: Sorry not being able to provide a better reproduce. I tried to dig
into symfony but failed as I'm not familiar with it. I was testing phpunit
against frameworks when I found this.
Running the symfony 2 test suite with RC6 leads to a segfault that I had across
two machines so I'll open this just in case it helps out and ask sf people to
maybe provide a better reproduce.
PHP Configure: Configure Command => './configure' '--enable-mbstring'
'--with-readline' '--enable-pcntl' '--with-zlib' '--prefix=/opt/php-5.4.0RC6/'
'--enable-debug'
Test script:
---
git clone git://github.com/symfony/symfony.git
cd symfony
./vendors.php
/opt/php-
Bug #60825 [Ctl]: Segfault when running symfony 2 tests
Edit report at https://bugs.php.net/bug.php?id=60825&edit=1
ID: 60825
Updated by: ras...@php.net
Reported by:php at wallbash dot com
Summary:Segfault when running symfony 2 tests
Status: Critical
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu 10.04.3 LTS
PHP Version:5.4.0RC6
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Can you try reproducing with the current svn code?
I went through the reproduce steps and the unit tests ran to completion for me.
However, under Valgrind I did get some complaints for one of the tests. Can you
tell if your crash is on this same test?
Starting test
'Symfony\Bundle\SecurityBundle\Tests\Functional\FormLoginTest::testFormLogin
with data set #0 ('config.yml')'.
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DE434: zend_call_function (zend_execute_API.c:925)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9F2AEF: zend_execute_scripts (zend.c:1272)
==24587==
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DBB70: _zval_ptr_dtor (zend_execute_API.c:433)
==24587==by 0x9DED15: zend_call_function (zend_execute_API.c:1019)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==
==24587== Conditional jump or move depends on uninitialised value(s)
==24587==at 0x9DBC28: _zval_ptr_dtor (zend_execute_API.c:444)
==24587==by 0x9DED15: zend_call_function (zend_execute_API.c:1019)
==24587==by 0xA128C3: zend_call_method (zend_interfaces.c:97)
==24587==by 0xA2BAE6: zend_std_cast_object_tostring
(zend_object_handlers.c:1494)
==24587==by 0x9E582A: _convert_to_string (zend_operators.c:588)
==24587==by 0xB05BB6: ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(zend_vm_execute.h:27073)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
==24587==by 0x9DE67C: zend_call_function (zend_execute_API.c:958)
==24587==by 0x74F4C9: zim_reflection_method_invokeArgs
(php_reflection.c:2926)
==24587==by 0xA35C22: zend_do_fcall_common_helper_SPEC
(zend_vm_execute.h:642)
==24587==by 0xA36C1E: ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(zend_vm_execute.h:752)
==24587==by 0xA342CC: execute (zend_vm_execute.h:410)
Previous Comments:
[2012-01-21 04:59:45] ras...@php.net
Stas, this looks like a blocker for 5.4
[2012-01-20 20:20:21] php at wallbash dot com
Description:
First off: Sorry not being able to provide a better reproduce. I tried to dig
into symfony but failed as I'm not familiar with it. I was testing phpunit
against frameworks when I found this.
Running the symfony 2 test suite with RC6 leads to a segfault that I had across
two machines so I'll open this just in case it helps out and ask sf people to
maybe provide a better reproduce.
PHP Configure: Configure Command => './configure' '--enable-mbstring'
'--with-readline' '--enable-pcntl' '--with-zlib' '--prefix=/opt/php-5.4.0RC6/'
'--enable-debug'
Test script:
---
git clone git://github.com/symfony/symfony.git
cd symfony
./vendors.php
/opt/php-5.4.0RC6/bin/php `which phpunit` --debug --filter FormLoginTest
Expected result:
No segfault
Actual result:
--
Configuration read from
/home/edo/Desktop/PHP/phpunit-dev/phpunit-testing-with-frameworks/vendor/symfony/phpunit
Bug #60825 [Opn->Ctl]: Segfault when running symfony 2 tests
Edit report at https://bugs.php.net/bug.php?id=60825&edit=1
ID: 60825
Updated by: ras...@php.net
Reported by:php at wallbash dot com
Summary:Segfault when running symfony 2 tests
-Status: Open
+Status: Critical
Type: Bug
Package:Reproducible crash
Operating System: Ubuntu 10.04.3 LTS
PHP Version:5.4.0RC6
-Assigned To:
+Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Stas, this looks like a blocker for 5.4
Previous Comments:
[2012-01-20 20:20:21] php at wallbash dot com
Description:
First off: Sorry not being able to provide a better reproduce. I tried to dig
into symfony but failed as I'm not familiar with it. I was testing phpunit
against frameworks when I found this.
Running the symfony 2 test suite with RC6 leads to a segfault that I had across
two machines so I'll open this just in case it helps out and ask sf people to
maybe provide a better reproduce.
PHP Configure: Configure Command => './configure' '--enable-mbstring'
'--with-readline' '--enable-pcntl' '--with-zlib' '--prefix=/opt/php-5.4.0RC6/'
'--enable-debug'
Test script:
---
git clone git://github.com/symfony/symfony.git
cd symfony
./vendors.php
/opt/php-5.4.0RC6/bin/php `which phpunit` --debug --filter FormLoginTest
Expected result:
No segfault
Actual result:
--
Configuration read from
/home/edo/Desktop/PHP/phpunit-dev/phpunit-testing-with-frameworks/vendor/symfony/phpunit.xml.dist
Starting test
'Symfony\Bundle\SecurityBundle\Tests\Functional\FormLoginTest::testFormLogin
with data set #0 ('config.yml')'.
Segmentation fault (core dumped)
(gdb) bt
#0 _zend_mm_free_int (heap=0x1a85310, p=0x7fff9c786460) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_alloc.c:2100
#1 0x006be6cd in zend_call_function (fci=0x7fff9c786210,
fci_cache=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_execute_API.c:1019
#2 0x006e06ff in zend_call_method (object_pp=0x7fff9c786338,
obj_ce=0x5f4a370, fn_proxy=0x5f4a4d8, function_name=0xaa65b0 "__tostring",
function_name_len=3, retval_ptr_ptr=, param_count=0,
arg1=0x0,
arg2=0x0) at /home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_interfaces.c:97
#3 0x006ebb11 in zend_std_cast_object_tostring
(readobj=0x7fff9c786460, writeobj=0x7fff9c786390, type=)
at /home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_object_handlers.c:1494
#4 0x006c2ad0 in _convert_to_string (op=0x1a85310) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_operators.c:588
#5 0x0071212a in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(execute_data=0x7f33c5361908) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:27073
#6 0x00730010 in execute (op_array=0x5f4c280) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:410
#7 0x006be773 in zend_call_function (fci=0x7fff9c786660,
fci_cache=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_execute_API.c:958
#8 0x005c4020 in zim_reflection_method_invokeArgs (ht=, return_value=0x58193d0, return_value_ptr=,
this_ptr=, return_value_used=)
at /home/edo/Desktop/PHP/php-5.4.0RC6/ext/reflection/php_reflection.c:2926
#9 0x00742c5c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f33c53604c0) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:642
#10 0x00730010 in execute (op_array=0x5c12cd8) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:410
#11 0x006c8d5a in zend_execute_scripts (type=8, retval=, file_count=3) at /home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend.c:1272
#12 0x0066de5d in php_execute_script (primary_file=) at /home/edo/Desktop/PHP/php-5.4.0RC6/main/main.c:2476
#13 0x00770757 in do_cli (argc=0, argv=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/sapi/cli/php_cli.c:983
#14 0x00770e64 in main (argc=, argv=) at /home/edo/Desktop/PHP/php-5.4.0RC6/sapi/cli/php_cli.c:1356
--
Edit this bug report at https://bugs.php.net/bug.php?id=60825&edit=1
Bug #60828 [Com]: crash with specific php.ini
Edit report at https://bugs.php.net/bug.php?id=60828&edit=1 ID: 60828 Comment by: anon at anon dot anon Reported by:bugzilla33 at gmail dot com Summary:crash with specific php.ini Status: Open Type: Bug Package:Reproducible crash Operating System: Win 7 32/64 bit PHP Version:5.4.0RC6 Block user comment: N Private report: N New Comment: A possibly related issue: it also crashes with php_exif.dll listed before php_mbstring.dll. It has done for years. Previous Comments: [2012-01-20 21:39:02] bugzilla33 at gmail dot com Description: 1. use Apache 2.2.21 VC9 2. download http://windows.php.net/downloads/qa/php-5.4.0RC6-Win32-VC9-x86.zip 3. unpack to c:\php5\ 4. use php.ini-production -> php.ini 5. change php.ini: extension_dir = "c:\php5\ext" extension=php_gd2.dll extension=php_mbstring.dll extension=php_openssl.dll extension=php_sockets.dll 6. or download php.ini from http://host0001.webd.pl/bugs/php/crash.zip 7. restart apache 8. run test script Test script: --- http://php.net/'); ?> or Expected result: no crush like 5.4 RC4 - bug introduced in PHP 5.4 RC5 Actual result: -- crush on first (second) script run after apache restart -- Edit this bug report at https://bugs.php.net/bug.php?id=60828&edit=1
Bug #52078 [Asn]: fileinode overflow test ext/standard/tests/file/fileinode_variation3.phpt
Edit report at https://bugs.php.net/bug.php?id=52078&edit=1
ID: 52078
User updated by:glen at delfi dot ee
Reported by:glen at delfi dot ee
Summary:fileinode overflow test
ext/standard/tests/file/fileinode_variation3.phpt
Status: Assigned
Type: Bug
Package:Filesystem function related
Operating System: PLD Linux
PHP Version:5.3.2
Assigned To:tyrael
Block user comment: N
Private report: N
New Comment:
please note that the patch provided in bug was not complete (there are more
tests
suffering the same deficiency), because did not get any feedback to decide to
proceed further.
"find -name '*.phpt' | xargs grep fileinode" in source tree should give ideas
what more to patch (and of course all inode related functions: getmyinode,
stat,
...)
Previous Comments:
[2012-01-19 19:09:44] tyr...@php.net
I commited the %d->%i changes to trunk and 5.3, waiting for approval to commit
it
to 5.4 as well, I will keep the ticket open until.
http://svn.php.net/viewvc?view=revision&revision=322460
[2012-01-17 10:18:51] tyr...@php.net
I will look into merging this, thanks for the patch and the heads up.
[2011-11-05 20:49:17] glen at delfi dot ee
any interest of getting it fixed?
i could supply patches, if i see any interest at all on this topic from upstream
[2010-12-12 21:32:27] glen at delfi dot ee
as you maybe have noted, one chunk takes different approach:
if (PHP_INT_SIZE == 4) die("skip this test is for >32bit platform only (inodes
overflow there)");
maybe should rather skip overflowing tests there?
[2010-12-12 21:31:01] glen at delfi dot ee
i've kept it somewhat updated here:
http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/packages/php/bug-52078-fileinode.patch
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=52078
--
Edit this bug report at https://bugs.php.net/bug.php?id=52078&edit=1
[PHP-BUG] Bug #60828 [NEW]: crash with specific php.ini
From: Operating system: Win 7 32/64 bit PHP version: 5.4.0RC6 Package: Reproducible crash Bug Type: Bug Bug description:crash with specific php.ini Description: 1. use Apache 2.2.21 VC9 2. download http://windows.php.net/downloads/qa/php-5.4.0RC6-Win32-VC9-x86.zip 3. unpack to c:\php5\ 4. use php.ini-production -> php.ini 5. change php.ini: extension_dir = "c:\php5\ext" extension=php_gd2.dll extension=php_mbstring.dll extension=php_openssl.dll extension=php_sockets.dll 6. or download php.ini from http://host0001.webd.pl/bugs/php/crash.zip 7. restart apache 8. run test script Test script: --- http://php.net/'); ?> or Expected result: no crush like 5.4 RC4 - bug introduced in PHP 5.4 RC5 Actual result: -- crush on first (second) script run after apache restart -- Edit bug report at https://bugs.php.net/bug.php?id=60828&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60828&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60828&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60828&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60828&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60828&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60828&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60828&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60828&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60828&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60828&r=support Expected behavior: https://bugs.php.net/fix.php?id=60828&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60828&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60828&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60828&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60828&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60828&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60828&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60828&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60828&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60828&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60828&r=mysqlcfg
[PHP-BUG] Bug #60826 [NEW]: raw POST data missing with chunked encoding, FastCGI
From: Operating system: Windows XP PHP version: 5.3.9 Package: CGI/CLI related Bug Type: Bug Bug description:raw POST data missing with chunked encoding, FastCGI Description: When a POST is sent with the header "Transfer-Encoding: chunked" and PHP 5.3 is running via FastCGI, $HTTP_RAW_POST_DATA is not set. In IIS, the receiving PHP process simply hangs and does not execute at all. If chunked encoding is not set, it executes successfully and $HTTP_RAW_POST_DATA is populated. Comparing ISAPI to FastCGI (using PHP 5.2 which has both implementations), PHP ISAPI works fine with "Transfer-Encoding: chunked" but PHP FastCGI does not. This issue also occurred running Linux/Apache with PHP 5.3 FastCGI. In that scenario, the PHP process did not completely hang, but $HTTP_RAW_POST_DATA and php://input were empty when the script executed. Test script: --- Two files, postsend.php and postreceive.php, can be found within the question here: http://stackoverflow.com/questions/8899239/http-raw-post-data-not-being-populated-after-upgrade-to-php-5-3 Expected result: $HTTP_RAW_POST_DATA and the php://input stream should contain the raw binary data that was sent in the POST. Actual result: -- On Windows/IIS, the PHP process hangs and does not execute. On Linux/Apache, the PHP process executes but $HTTP_RAW_POST_DATA and php://input are empty. -- Edit bug report at https://bugs.php.net/bug.php?id=60826&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60826&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60826&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60826&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60826&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60826&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60826&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60826&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60826&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60826&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60826&r=support Expected behavior: https://bugs.php.net/fix.php?id=60826&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60826&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60826&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60826&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60826&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60826&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60826&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60826&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60826&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60826&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60826&r=mysqlcfg
Req #26379 [Fbk->Csd]: ext/interbase: must be linked with -lcrypt under FreeBSD
Edit report at https://bugs.php.net/bug.php?id=26379&edit=1 ID: 26379 Updated by: mar...@php.net Reported by:nicol at aokp dot ru Summary:ext/interbase: must be linked with -lcrypt under FreeBSD -Status: Feedback +Status: Closed Type: Feature/Change Request Package:InterBase related Operating System: FreeBSD 4.9 PHP Version:4.3.4 Assigned To:mariuz Block user comment: N Private report: N New Comment: Thank you for your bug report. This issue has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2012-01-20 20:46:20] mar...@php.net tested with bsd 9.0 php 5.3.9 and all seems to be fine now ./configure --with-interbase works out of the box (tar) [2011-09-12 09:51:45] mar...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2011-07-19 16:29:58] mar...@php.net To do test ./configure on newest freebsd stable 8.x but i don't think this bug can be reproduced anymore (firebird doesn't use lcrypt or the extension for it) [2003-11-24 03:11:13] nicol at aokp dot ru Description: php 4.3.4/5.0.0.Beta2 same bug configure fails when detecting Interbase(Firebird) under FreeBSD (undefined reference to 'crypt'), because configure checks crypt() in -lcrypt after checking isc_detach_database() in -lgds and test program was linke without -lcrypt. -- Edit this bug report at https://bugs.php.net/bug.php?id=26379&edit=1
Req #26379 [Com]: ext/interbase: must be linked with -lcrypt under FreeBSD
Edit report at https://bugs.php.net/bug.php?id=26379&edit=1 ID: 26379 Comment by: mar...@php.net Reported by:nicol at aokp dot ru Summary:ext/interbase: must be linked with -lcrypt under FreeBSD Status: Feedback Type: Feature/Change Request Package:InterBase related Operating System: FreeBSD 4.9 PHP Version:4.3.4 Assigned To:mariuz Block user comment: N Private report: N New Comment: tested with bsd 9.0 php 5.3.9 and all seems to be fine now ./configure --with-interbase works out of the box (tar) Previous Comments: [2011-09-12 09:51:45] mar...@php.net Please try using this snapshot: http://snaps.php.net/php5.4-latest.tar.gz For Windows: http://windows.php.net/snapshots/ [2011-07-19 16:29:58] mar...@php.net To do test ./configure on newest freebsd stable 8.x but i don't think this bug can be reproduced anymore (firebird doesn't use lcrypt or the extension for it) [2003-11-24 03:11:13] nicol at aokp dot ru Description: php 4.3.4/5.0.0.Beta2 same bug configure fails when detecting Interbase(Firebird) under FreeBSD (undefined reference to 'crypt'), because configure checks crypt() in -lcrypt after checking isc_detach_database() in -lgds and test program was linke without -lcrypt. -- Edit this bug report at https://bugs.php.net/bug.php?id=26379&edit=1
Bug #60802 [Asn->Csd]: ibase_trans() gives segfault when passing params
Edit report at https://bugs.php.net/bug.php?id=60802&edit=1 ID: 60802 Updated by: mar...@php.net Reported by:lars dot westermann at privat dot dk Summary:ibase_trans() gives segfault when passing params -Status: Assigned +Status: Closed Type: Bug Package:InterBase related Operating System: Linux PHP Version:5.3.9 Assigned To:mariuz Block user comment: N Private report: N New Comment: 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. Previous Comments: [2012-01-19 22:31:18] mar...@php.net I saw that difference from 5.4 and now i know what was :) I will merge back patch and 5.3 will look the same like in 5.2 , and 5.4 [2012-01-19 22:25:54] mar...@php.net Automatic comment from SVN on behalf of mariuz Revision: http://svn.php.net/viewvc/?view=revision&revision=322477 Log: Fix #60802 ibase_trans() gives segfault when passing params (The &argn passed to zend_parse_parameters shall be a pointer to an integer, not to an unsigned short.) [2012-01-19 09:48:11] lars dot westermann at privat dot dk Description: The ibase_trans() function segfaults when you pass connection-id and/or mode to the function. After comparing both 5.2.x version of interbase.c and 5.3.x version, I found the solution: # diff interbase.c interbase-fix.c 1128c1128,1129 < unsigned short i, argn, link_cnt = 0, tpb_len = 0; --- > unsigned short i, link_cnt = 0, tpb_len = 0; > int argn; The &argn passed to zend_parse_parameters shall be a pointer to an integer, not to an unsigned short. Test script: --- $DB = ibase_pconnect($DB_name, $DB_user, $DB_pw ); $TR = ibase_trans($DB); is enough to trigger the error. -- Edit this bug report at https://bugs.php.net/bug.php?id=60802&edit=1
[PHP-BUG] Bug #60825 [NEW]: Segfault when running symfony 2 tests
From:
Operating system: Ubuntu 10.04.3 LTS
PHP version: 5.4.0RC6
Package: Reproducible crash
Bug Type: Bug
Bug description:Segfault when running symfony 2 tests
Description:
First off: Sorry not being able to provide a better reproduce. I tried to
dig into symfony but failed as I'm not familiar with it. I was testing
phpunit against frameworks when I found this.
Running the symfony 2 test suite with RC6 leads to a segfault that I had
across two machines so I'll open this just in case it helps out and ask sf
people to maybe provide a better reproduce.
PHP Configure: Configure Command => './configure' '--enable-mbstring'
'--with-readline' '--enable-pcntl' '--with-zlib'
'--prefix=/opt/php-5.4.0RC6/' '--enable-debug'
Test script:
---
git clone git://github.com/symfony/symfony.git
cd symfony
./vendors.php
/opt/php-5.4.0RC6/bin/php `which phpunit` --debug --filter FormLoginTest
Expected result:
No segfault
Actual result:
--
Configuration read from
/home/edo/Desktop/PHP/phpunit-dev/phpunit-testing-with-frameworks/vendor/symfony/phpunit.xml.dist
Starting test
'Symfony\Bundle\SecurityBundle\Tests\Functional\FormLoginTest::testFormLogin
with data set #0 ('config.yml')'.
Segmentation fault (core dumped)
(gdb) bt
#0 _zend_mm_free_int (heap=0x1a85310, p=0x7fff9c786460) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_alloc.c:2100
#1 0x006be6cd in zend_call_function (fci=0x7fff9c786210,
fci_cache=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_execute_API.c:1019
#2 0x006e06ff in zend_call_method (object_pp=0x7fff9c786338,
obj_ce=0x5f4a370, fn_proxy=0x5f4a4d8, function_name=0xaa65b0 "__tostring",
function_name_len=3, retval_ptr_ptr=, param_count=0,
arg1=0x0,
arg2=0x0) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_interfaces.c:97
#3 0x006ebb11 in zend_std_cast_object_tostring
(readobj=0x7fff9c786460, writeobj=0x7fff9c786390, type=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_object_handlers.c:1494
#4 0x006c2ad0 in _convert_to_string (op=0x1a85310) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_operators.c:588
#5 0x0071212a in ZEND_INCLUDE_OR_EVAL_SPEC_CV_HANDLER
(execute_data=0x7f33c5361908) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:27073
#6 0x00730010 in execute (op_array=0x5f4c280) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:410
#7 0x006be773 in zend_call_function (fci=0x7fff9c786660,
fci_cache=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_execute_API.c:958
#8 0x005c4020 in zim_reflection_method_invokeArgs (ht=, return_value=0x58193d0, return_value_ptr=, this_ptr=, return_value_used=)
at
/home/edo/Desktop/PHP/php-5.4.0RC6/ext/reflection/php_reflection.c:2926
#9 0x00742c5c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7f33c53604c0) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:642
#10 0x00730010 in execute (op_array=0x5c12cd8) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend_vm_execute.h:410
#11 0x006c8d5a in zend_execute_scripts (type=8, retval=, file_count=3) at
/home/edo/Desktop/PHP/php-5.4.0RC6/Zend/zend.c:1272
#12 0x0066de5d in php_execute_script (primary_file=) at /home/edo/Desktop/PHP/php-5.4.0RC6/main/main.c:2476
#13 0x00770757 in do_cli (argc=0, argv=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/sapi/cli/php_cli.c:983
#14 0x00770e64 in main (argc=, argv=) at
/home/edo/Desktop/PHP/php-5.4.0RC6/sapi/cli/php_cli.c:1356
--
Edit bug report at https://bugs.php.net/bug.php?id=60825&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60825&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60825&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60825&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60825&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60825&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60825&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60825&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60825&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60825&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60825&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60825&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60825&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60825&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60825&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60825&r=php4
Daylight Savings:
Bug #60779 [Com]: Incorrect return value for getprotobyname
Edit report at https://bugs.php.net/bug.php?id=60779&edit=1
ID: 60779
Comment by: phpmpan at mpan dot pl
Reported by:wojtos at gmail dot com
Summary:Incorrect return value for getprotobyname
Status: Duplicate
Type: Bug
Package:*Network Functions
Operating System: Debian Squeeze
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
There is nothing negative in having your post marked as DUP in this case. I
believe it's purely organisational thing and laruence's intention wasn't
telling you that you did something wrong. If one of the two reports is closed
after fixing an issue, the second one needs to be set to DUP. This is not a
contest on who will get more successful reports ;), so it doesn't matter which
one it is. The goal was accomplished: PHP is better than it was before.
Don't get discouraged and keep helping to improve PHP.
Previous Comments:
[2012-01-20 12:01:04] wojtos at gmail dot com
That is a duplicate of this and not the other way around! (id and time).
Anyhow. Glad it's fixed.
[2012-01-20 02:22:30] larue...@php.net
dup to #60781
[2012-01-18 08:21:40] wojtos at gmail dot com
Thank You for your reply. Indeed I checked and it does return FALSE. The bug or
rather misinformation lies in the documentation where it states "Returns the
protocol number or -1 if the protocol is not found.". When in the test script I
checked for === FALSE it worked as expected.
[2012-01-17 16:25:28] phpmpan at mpan dot pl
Or you can't...
Are you sure that you're receiving 0, not `FALSE`? If yes, than I'm NOT
confirming this behaviour with 5.3.9, 5.3-dev, 5.4-dev or trunk-dev (on
Arch64). In all four versions `getprotobyname` returns `FALSE`.
Also returning 0 seems very strange. PHP just forwards the call to
`getprotobyname` from netdb. In case of an error or if a protocol is not found,
this function should return `NULL`. PHP checks if the call has returned `NULL`
and, if it did, returns `FALSE`. Therefore if you're receiving 0, this would
indicate a bug in the host environment, not in PHP itself.
BEGIN CODE
// ext/standard/basic_functions.c from SVN
// ...
ent = getprotobyname(name);
if (ent == NULL) {
RETURN_FALSE;
}
// ...
- END CODE -
[2012-01-17 15:46:49] phpmpan at mpan dot pl
This is not a bug in `getprotobyname`. It's a bug in documentation for the
function. `getprotobyname` returns `FALSE`, not 0 in case of an error. I will
fill a report for that in a moment. You can close this one.
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=60779
--
Edit this bug report at https://bugs.php.net/bug.php?id=60779&edit=1
Req #47456 [Asn->Opn]: Missing PCRE option 'J'
Edit report at https://bugs.php.net/bug.php?id=47456&edit=1 ID: 47456 Updated by: nlop...@php.net Reported by:rodricg at sellingsource dot com Summary:Missing PCRE option 'J' -Status: Assigned +Status: Open Type: Feature/Change Request Package:PCRE related Operating System: Linux PHP Version:5.3CVS-2009-02-19 (CVS) -Assigned To:nlopess +Assigned To: Block user comment: N Private report: N Previous Comments: [2009-02-19 23:47:05] rodricg at sellingsource dot com Didn't see how else to include this diff for php_pcre.c http://diff.pastebin.com/f5639d5a5 [2009-02-19 23:36:11] fel...@php.net Currently you can only use PCRE_INFO_JCHANGED by (?J) in the pattern. I have suggested times ago to the maintainer, but it wasn't accept the addiction of 'J' as valid modifier in the extension. Anyway, assigned to maintainer. [2009-02-19 23:12:33] rodricg at sellingsource dot com Description: The PCRE extension does not recognize the 'J' option for setting PCRE_DUPNAMES. Reproduce code: --- [ac])(?\d)|(?[b])/J', 'a1bc3', $m, PREG_SET_ORDER); print_r($m); ?> Expected result: Array ( [0] => Array ( [0] => a1 [chr] => a [1] => a [num] => 1 [2] => 1 ) [1] => Array ( [0] => b [chr] => b [1] => [num] => [2] => [3] => b ) [2] => Array ( [0] => c3 [chr] => c [1] => c [num] => 3 [2] => 3 ) ) Actual result: -- PHP Warning: preg_match(): Unknown modifier 'J' in -- Edit this bug report at https://bugs.php.net/bug.php?id=47456&edit=1
Bug #49151 [Asn->Opn]: relocation must bind locally
Edit report at https://bugs.php.net/bug.php?id=49151&edit=1 ID: 49151 Updated by: nlop...@php.net Reported by:tech at uscki dot nl Summary:relocation must bind locally -Status: Assigned +Status: Open Type: Bug Package:Compile Failure Operating System: Sun Solaris 5.10 (i386) PHP Version:5.3.0 -Assigned To:nlopess +Assigned To: Block user comment: N Private report: N Previous Comments: [2010-09-13 23:45:24] brentk at birs dot ca I'm getting the same problem with PHP 5.3.3 on Solaris 10 (x64), gcc 4.3.3. The compile dies at php_date.o with the same message as the original post. If I remove the "-fvisibility=hidden" part from configure, this doesn't happen. [2010-05-24 17:20:11] dbakyle at gmail dot com I've removed the -fvisibility=hidden from the Makefile and tried the make again. The process is still failing on glob_wrapper.lo I'm using 4.1.2 of gcc and 2.6.18-92.1.22.0.1 of Red Hat. [2009-08-17 09:42:07] j...@php.net It should be as simple as adding 'static' in the macro ZEND_DECLARE_MODULE_GLOBALS since those should be static anyway.. [2009-08-14 23:13:32] tech at uscki dot nl Yeah, got it compiling! I removed "-fvisibility=hidden" from the Makefile after running ./configure, guess that boils down to the same result, though your suggestion is a bit tidier. Compiler: gcc (GCC) 4.0.1 Thanks for all your help! [2009-08-14 21:54:04] nlop...@php.net sorry, I forgot to say that before ./configure you must run ./buildconf 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=49151 -- Edit this bug report at https://bugs.php.net/bug.php?id=49151&edit=1
Req #36030 [Com]: stream_set_timeout() does not work for php://stdin
Edit report at https://bugs.php.net/bug.php?id=36030&edit=1 ID: 36030 Comment by: an0nym at narod dot ru Reported by:silencer at inbox dot ru Summary:stream_set_timeout() does not work for php://stdin Status: Open Type: Feature/Change Request Package:Streams related Operating System: * PHP Version:5.3 Block user comment: N Private report: N New Comment: Still isn't working on PHP 5.3.9. [an0nym@localhost ~]$ php -v PHP 5.3.9 (cli) (built: Jan 11 2012 17:59:59) Copyright (c) 1997-2012 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies [an0nym@localhost ~]$ cat test.php Expected result: output "Success" Actual result: -- output "Failed" -- Edit this bug report at https://bugs.php.net/bug.php?id=36030&edit=1
Bug #54520 [Com]: Font in cifs mounted path causes "Could not read font" error
Edit report at https://bugs.php.net/bug.php?id=54520&edit=1 ID: 54520 Comment by: akger1379 at gmail dot com Reported by:rpoca at androme dot es Summary:Font in cifs mounted path causes "Could not read font" error Status: Open Type: Bug Package:GD related Operating System: Linux Debian 6.0 Squeeze PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I found a solution! It seems to be a problem of freetype... Just mount the cifs with the "noserverinfo" option and it will work. For more information: https://savannah.gnu.org/bugs/?func=detailitem&item_id=31791 PS: I tried to write a comment to the linke above but I was not able to do so. Maybe someone else could push a bit to get this bug solved. Previous Comments: [2011-04-13 12:40:37] rpoca at androme dot es Description: Trying to open a .ttf file in a CIFS mounted share (644 file permissions) causes PHP Warning: imagefttext(): Could not read font in /var/www/whatever/whatever/morewhatever/whatever/whatever/test.php on line 23 I tried to create the attached script (which sets GDFONTPATH to the current dir) to have a test. When run from /tmp with all the font files in the same directory, it works. But when I moved into a CIFS mounted webroot, it stops working. It also fails when executing from the command line, from apache, as root, etc. Test script: --- Expected result: Both on a cifs mounted drive and a normal path you should get the PNG image with the "Test1" string. Actual result: -- # php test.php PHP Warning: imagefttext(): Could not find/open font in /var/www/phemiumconsultant/portals/consultant/runtime3g/layouts/fonts/test.php on line 12 ...PNG... binary data... -- Edit this bug report at https://bugs.php.net/bug.php?id=54520&edit=1
Bug #60457 [Com]: gc_zval_possible_root SIGSEGV
Edit report at https://bugs.php.net/bug.php?id=60457&edit=1 ID: 60457 Comment by: sjon at hortensius dot net Reported by:Sjon at hortensius dot net Summary:gc_zval_possible_root SIGSEGV Status: Open Type: Bug Package:Scripting Engine problem Operating System: Linux PHP Version:5.3.8 Block user comment: N Private report: N New Comment: This bug has been solved in a more specific bug which includes a patch: https://bugs.php.net/bug.php?id=60701 Previous Comments: [2012-01-04 08:26:51] Sjon at hortensius dot net For anyone interested, this bug is not related to a single class, but we have worked around, and seen this bug occur again, in many different places. I have also been reproducing this in 5.3.6 / 5.3.5 / 5.3.4 and 5.3.3 [2012-01-04 07:31:07] no at snaxor dot com I may be bumping into this one as well, Similarly, I cannot provide a script to reproduce it since it happens in a project with many classes, but I'll see if I can narrow it down and create one. It is very inconsistent. It will die one the same page but with different data it will be fine. What seems to be sparking it in my case is Smarty, with lots of sub-template files. The content is rendered correctly, but during Smarty's cleanup is when it dies. It is trigger-able via php command line or apache module. gc_disable() doesn't unfortunately have any effect. PHP Version: 5.3.8 on OSX. Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x003dca9fd2f1 0x000100359618 in gc_zval_possible_root () (gdb) bt #0 0x000100359618 in gc_zval_possible_root () #1 0x00010034a765 in zend_hash_destroy () #2 0x00010035c86c in zend_object_std_dtor () #3 0x00010035c4f8 in zend_objects_free_object_storage () #4 0x00010035faae in zend_objects_store_del_ref_by_handle_ex () #5 0x00010035fb64 in zend_objects_store_del_ref () #6 0x000100334e2d in _zval_ptr_dtor () #7 0x00010034a765 in zend_hash_destroy () #8 0x00010033f1b0 in _zval_dtor_func () #9 0x000100334e2d in _zval_ptr_dtor () #10 0x00010034a765 in zend_hash_destroy () #11 0x00010035c86c in zend_object_std_dtor () #12 0x00010035c4f8 in zend_objects_free_object_storage () #13 0x00010035f6eb in zend_objects_store_free_object_storage () #14 0x000100337750 in shutdown_executor () #15 0x00010033feae in zend_deactivate () #16 0x0001002f08b1 in php_request_shutdown () #17 0x0001003ba366 in main () #18 0x000110ec in start () [2011-12-12 15:58:33] Sjon at hortensius dot net I am afraid not, gc_disable() doesn't solve this segfault unfortunately [2011-12-11 19:41:22] arekm at maven dot pl Isn't this something similar to last comments of #40479 (there is reproduction script there). [2011-12-07 14:05:33] Sjon at hortensius dot net Description: Our application segfaults after completely finishing the request. Unfortunately I cannot provide a script to reproduce this as it occurs in an application consisting of many classes. I have been poking at this with gdb for a while, but can't find the cause for this problem. How can I supply you with the information you need to resolve this? We can 'fix' the problem by die()-ing in the __destruct of the class that seems to cause this Actual result: -- #0 0x005bf0e9 in gc_zval_possible_root (zv=0x1985580) at /usr/src/debug/php-5.3.8/Zend/zend_gc.c:143 #1 0x005aeb28 in zend_hash_destroy (ht=0x1363998) at /usr/src/debug/php-5.3.8/Zend/zend_hash.c:529 #2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at /usr/src/debug/php-5.3.8/Zend/zend_objects.c:45 #3 0x005c0629 in zend_objects_free_object_storage (object=0x1985580) at /usr/src/debug/php-5.3.8/Zend/zend_objects.c:126 #4 0x005c46d6 in zend_objects_store_free_object_storage (objects=0x91bef8) at /usr/src/debug/php-5.3.8/Zend/zend_objects_API.c:92 #5 0x00595757 in shutdown_executor () at /usr/src/debug/php- 5.3.8/Zend/zend_execute_API.c:304 #6 0x005a1fc2 in zend_deactivate () at /usr/src/debug/php- 5.3.8/Zend/zend.c:891 #7 0x0054f2ce in php_request_shutdown (dummy=) at /usr/src/debug/php-5.3.8/main/main.c:1640 #8 0x0062b10f in main (argc=3, argv=0x7fffea88) at /usr/src/debug/php-5.3.8/sapi/cli/php_cli.c:1363 (gdb) frame 2 #2 0x005c0609 in zend_object_std_dtor (object=0x1363970) at /usr/src/debug/php-5.3.8/Zend/zend_objects.c:45 45 zend_h
Bug #60701 [Com]: __toString() which stores $this reference triggers segfault
Edit report at https://bugs.php.net/bug.php?id=60701&edit=1
ID: 60701
Comment by: hans at rakers dot org
Reported by:daan at react dot com
Summary:__toString() which stores $this reference triggers
segfault
Status: Open
Type: Bug
Package:Class/Object related
Operating System: CentOS
PHP Version:5.3.8
Block user comment: N
Private report: N
New Comment:
This bug is caused by zend_std_cast_object_tostring() not checking the refcount
of readobj when readobj==writeobj. It calls INIT_PZVAL(writeobj) without
checking the refcount first, causing any further references to this zval to get
corrupted (in this case, the 'test' property of StringableObject).
My patch against 5.3 is attached.
Previous Comments:
[2012-01-10 19:22:39] sjon at hortensius dot net
This bug is not reproducible when php is compiled with enable-debug. It is
however reproducible in other PHP versions, such as 5.3.7/5.3.6/5.3.5
[2012-01-10 16:43:17] daan at react dot com
Description:
A simple object construction where a __toString() stores $this, will trigger a
segfault during garbage collection at the end of the request.
Probably related bug: https://bugs.php.net/bug.php?id=60598
Is a distilled version of this bug: https://bugs.php.net/bug.php?id=60457
Test script:
---
object = new StringableObject();
return $this->object;
}
// This destructor is required to exist to trigger the segfault
public function __destruct()
{
}
}
class StringableObject
{
public function __toString()
{
$this->test = $this;
return '';
}
}
$container = new Container();
$object = $container->getObject();
// Any kind of function which triggers a 'to string' object conversion
// Casting $object with (string) will circumvent the problem
echo trim($object);
// Another call is required to corrupt heap
echo trim('test');
Expected result:
test
Actual result:
--
Segfault
gdb backtrace (with commandline PHP with build tag ZEND_DEBUG_OBJECTS)
[Thread debugging using libthread_db enabled]
Allocated object id #1
Allocated object id #2
Increased refcount of object id #2
Decreased refcount of object id #2
testIncreased refcount of object id #1
Decreased refcount of object id #1
Deallocated object id #1
Program received signal SIGSEGV, Segmentation fault.
0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_gc.c:143
143GC_ZOBJ_CHECK_POSSIBLE_ROOT(zv);
(gdb) bt
#0 0x006d4c69 in gc_zval_possible_root (zv=0x1023e40) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_gc.c:143
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
#3 0x006d6029 in zend_objects_free_object_storage (object=0x1023dc8)
at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:126
#4 0x006da037 in zend_objects_store_del_ref_by_handle_ex (handle=2,
handlers=) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_objects_API.c:220
#5 0x006da053 in zend_objects_store_del_ref (zobject=0x1022350) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects_API.c:172
#6 0x006a9571 in _zval_dtor (zvalue=0x1022350) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_variables.h:35
#7 _zval_ptr_dtor (zval_ptr=) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:447
#8 0x006c3645 in zend_hash_apply_deleter (ht=0xe33188, p=0x1026728) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_hash.c:612
#9 0x006c4f81 in zend_hash_reverse_apply (ht=0xe33188,
apply_func=0x6a9430 ) at /home/sjon/php-debug/php-
5.3.8/Zend/zend_hash.c:762
#10 0x006a9921 in shutdown_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend_execute_API.c:226
#11 0x006b7747 in zend_call_destructors () at /home/sjon/php-debug/php-
5.3.8/Zend/zend.c:875
#12 0x006651fd in php_request_shutdown (dummy=) at
/home/sjon/php-debug/php-5.3.8/main/main.c:1594
#13 0x0042d105 in main (argc=2, argv=0x7fffebb8) at /home/sjon/php-
debug/php-5.3.8/sapi/cli/php_cli.c:1363
(gdb) frame 2
#2 0x006d6009 in zend_object_std_dtor (object=0x1023dc8) at
/home/sjon/php-debug/php-5.3.8/Zend/zend_objects.c:45
45zend_hash_destroy(object->properties);
(gdb) print object->ce->name
$1 = 0x1025af0 "StringableObject"
(gdb) frame 1
#1 0x006c4ad8 in zend_hash_destroy (ht=0x10266d0) at /home/sjon/php-
debug/php-5.3.8/Zend/zend_hash.c:529
529ht->pDestructor(q->pData);
(gdb)
Bug #60816 [Opn]: spl_autoload_register fails with __call magic
Edit report at https://bugs.php.net/bug.php?id=60816&edit=1
ID: 60816
User updated by:dan dot lugg at gmail dot com
Reported by:dan dot lugg at gmail dot com
Summary:spl_autoload_register fails with __call magic
Status: Open
Type: Bug
Package:SPL related
Operating System: Windows 7x64
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Fellow programmers online have confirmed this may be a non-issue, however all
cases where the problem did not crop up were on *nix flavours; perhaps it is an
OS
specific/related issue.
Previous Comments:
[2012-01-20 06:57:01] le...@php.net
This works on viper-7: http://viper-7.com/KPlQLa
[2012-01-20 06:22:38] dan dot lugg at gmail dot com
Description:
When registering a callback object/method pair to spl_autoload_register(), if
the
method is not defined, though the object class has defined __call() magic, the
method will not be called during an autoload attempt.
In a larger project, I found that the PHP executable was crashing out
altogether,
appending no output to the logs, and offering minimal information. When I
isolated
what I suspected to be the problem, it was in fact the
spl_autoload_register()/__call() combination. In isolation, it did not crash
out
spectacularly as in my project, however it still failed.
While I marked this 5.3.9, these failures have been observed on 5.3.8, 5.3.9,
and
5.4.0.RC3.
While this is a bit of an edge case, I doubt that this is expected or
acceptable
behaviour, and have not been able to find mention of this elsewhere.
Test script:
---
string(10) "load_class"
["arguments"]=>
array(1) {
[0]=>
string(3) "Bar"
}
}
Fatal error: Class 'Bar' not found in - on line 12
Actual result:
--
Fatal error: Class 'Bar' not found in - on line 12
As you can see, while this test script made no attempt to actually load the
class,
it should at least be dumping the array before failing, as in the expected
output.
--
Edit this bug report at https://bugs.php.net/bug.php?id=60816&edit=1
Bug #60809 [Ctl->Csd]: TRAITS - PHPDoc Comment Style Bug
Edit report at https://bugs.php.net/bug.php?id=60809&edit=1
ID: 60809
Updated by: dmi...@php.net
Reported by:micronix at gmx dot net
Summary:TRAITS - PHPDoc Comment Style Bug
-Status: Critical
+Status: Closed
Type: Bug
Package:*General Issues
Operating System: Windows
PHP Version:5.4.0RC5
Assigned To:pierrick
Block user comment: N
Private report: N
New Comment:
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.
Previous Comments:
[2012-01-20 12:30:58] dmi...@php.net
Automatic comment from SVN on behalf of dmitry
Revision: http://svn.php.net/viewvc/?view=revision&revision=322495
Log: Fixed Bug #60809 (TRAITS - PHPDoc Comment Style Bug)
Fixed some other traits related bugs (uninitialized variable, return =>
continue)
Removed some trait related redundant code and variables
[2012-01-20 02:39:57] pierr...@php.net
The following patch has been added/updated:
Patch Name: bug60809.phpt
Revision: 1327027197
URL:
https://bugs.php.net/patch-display.php?bug=60809&patch=bug60809.phpt&revision=1327027197
[2012-01-20 02:32:52] larue...@php.net
ah, you are right, ingore my noise :)
[2012-01-20 02:28:53] pierr...@php.net
I can do it like that yes. I'll just have to declare the variable inside the
loop
to make sure the doc_comment is reinitialized and NULL if no doc_comment is
there.
[2012-01-20 02:26:32] larue...@php.net
pierrick, I suggest doing like:
char *doccomment = NULL;
if () {
doccomment = estrndup();
}
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=60809
--
Edit this bug report at https://bugs.php.net/bug.php?id=60809&edit=1
[PHP-BUG] Bug #60818 [NEW]: Problem storing UTF data
From: Operating system: PHP version: Irrelevant Package: PDO related Bug Type: Bug Bug description:Problem storing UTF data Description: I have a problem storing UTF data on MSSQL using pdo_dblib. In the following query: EXECUTE p_proc id = :id, @name = :name I cannot bind the ":name" param using the N'string' notation required by SQL Server (see http://support.microsoft.com/kb/239530) You cannot get around this by typing: EXECUTE p_proc id = :id, @name = N:name because binding fails on N:name The same problem happens with qoute function - it allways quotes with '' a never with N'' - perhaps there should be a new param like PDO::PARAM_STR to tell that with deal with a Unicode value? -- Edit bug report at https://bugs.php.net/bug.php?id=60818&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60818&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60818&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60818&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60818&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60818&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60818&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60818&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60818&r=needscript Try newer version: https://bugs.php.net/fix.php?id=60818&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60818&r=support Expected behavior: https://bugs.php.net/fix.php?id=60818&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60818&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60818&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60818&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60818&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60818&r=dst IIS Stability: https://bugs.php.net/fix.php?id=60818&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60818&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60818&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60818&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60818&r=mysqlcfg
Bug #60779 [Dup]: Incorrect return value for getprotobyname
Edit report at https://bugs.php.net/bug.php?id=60779&edit=1
ID: 60779
User updated by:wojtos at gmail dot com
Reported by:wojtos at gmail dot com
Summary:Incorrect return value for getprotobyname
Status: Duplicate
Type: Bug
Package:*Network Functions
Operating System: Debian Squeeze
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
That is a duplicate of this and not the other way around! (id and time).
Anyhow. Glad it's fixed.
Previous Comments:
[2012-01-20 02:22:30] larue...@php.net
dup to #60781
[2012-01-18 08:21:40] wojtos at gmail dot com
Thank You for your reply. Indeed I checked and it does return FALSE. The bug or
rather misinformation lies in the documentation where it states "Returns the
protocol number or -1 if the protocol is not found.". When in the test script I
checked for === FALSE it worked as expected.
[2012-01-17 16:25:28] phpmpan at mpan dot pl
Or you can't...
Are you sure that you're receiving 0, not `FALSE`? If yes, than I'm NOT
confirming this behaviour with 5.3.9, 5.3-dev, 5.4-dev or trunk-dev (on
Arch64). In all four versions `getprotobyname` returns `FALSE`.
Also returning 0 seems very strange. PHP just forwards the call to
`getprotobyname` from netdb. In case of an error or if a protocol is not found,
this function should return `NULL`. PHP checks if the call has returned `NULL`
and, if it did, returns `FALSE`. Therefore if you're receiving 0, this would
indicate a bug in the host environment, not in PHP itself.
BEGIN CODE
// ext/standard/basic_functions.c from SVN
// ...
ent = getprotobyname(name);
if (ent == NULL) {
RETURN_FALSE;
}
// ...
- END CODE -
[2012-01-17 15:46:49] phpmpan at mpan dot pl
This is not a bug in `getprotobyname`. It's a bug in documentation for the
function. `getprotobyname` returns `FALSE`, not 0 in case of an error. I will
fill a report for that in a moment. You can close this one.
[2012-01-17 14:19:22] wojtos at gmail dot com
Description:
---
>From manual page:
>http://www.php.net/function.getprotobyname#refsect1-function.getprotobyname-returnvalues
---
Return for unrecognized protocol is 0 instead of -1.
PHP 5.3.3-7+squeeze3 with Suhosin-Patch (cli) (built: Jun 28 2011 13:13:26)
Test script:
---
Expected result:
Invalid Protocol
Actual result:
--
Protocol #0
--
Edit this bug report at https://bugs.php.net/bug.php?id=60779&edit=1
Bug #60817 [Opn]: stream_get_line() incorrectly blocks
Edit report at https://bugs.php.net/bug.php?id=60817&edit=1
ID: 60817
User updated by:landeholm at gmail dot com
Reported by:landeholm at gmail dot com
Summary:stream_get_line() incorrectly blocks
Status: Open
Type: Bug
Package:Streams related
Operating System: Linux/Ubuntu
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
Oops, the expected result should be:
server got line: test #1
server got line: test2
server got line: test3
server got line: test4
server done
client done
Previous Comments:
[2012-01-20 11:55:10] landeholm at gmail dot com
Description:
stream_get_line() will block even though data has been received and there are
lines ready to be parsed in php's internal buffer.
It makes it impossible for example to implement a blocking HTTP server as the
server will only parse the first line in the HTTP request and then both the
server and client will hang as both are waiting for more data.
Test script:
---
$c = pcntl_fork();
if ($c > 0) {
$socket = stream_socket_server("tcp://127.0.0.1:1");
$socket2 = stream_socket_accept($socket);
while (!feof($socket2))
print "server got line: " . stream_get_line($socket2, 1024, "\r\n") . "\n";
print "server done\n";
} else {
sleep(1);
$socket = stream_socket_client("tcp://127.0.0.1:1");
fwrite($socket, "test #1\r\ntest2\r\ntest3\r\ntest4\r\n");
fread($socket, 1000);
print "client done\n";
}
die(0);
Expected result:
client done
server got line: test #1
server got line: test2
server got line: test3
server got line: test4
server done
Actual result:
--
server got line: test #1
--
Edit this bug report at https://bugs.php.net/bug.php?id=60817&edit=1
[PHP-BUG] Bug #60817 [NEW]: stream_get_line() incorrectly blocks
From:
Operating system: Linux/Ubuntu
PHP version: 5.3.9
Package: Streams related
Bug Type: Bug
Bug description:stream_get_line() incorrectly blocks
Description:
stream_get_line() will block even though data has been received and there
are lines ready to be parsed in php's internal buffer.
It makes it impossible for example to implement a blocking HTTP server as
the server will only parse the first line in the HTTP request and then both
the server and client will hang as both are waiting for more data.
Test script:
---
$c = pcntl_fork();
if ($c > 0) {
$socket = stream_socket_server("tcp://127.0.0.1:1");
$socket2 = stream_socket_accept($socket);
while (!feof($socket2))
print "server got line: " . stream_get_line($socket2, 1024, "\r\n") .
"\n";
print "server done\n";
} else {
sleep(1);
$socket = stream_socket_client("tcp://127.0.0.1:1");
fwrite($socket, "test #1\r\ntest2\r\ntest3\r\ntest4\r\n");
fread($socket, 1000);
print "client done\n";
}
die(0);
Expected result:
client done
server got line: test #1
server got line: test2
server got line: test3
server got line: test4
server done
Actual result:
--
server got line: test #1
--
Edit bug report at https://bugs.php.net/bug.php?id=60817&edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60817&r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60817&r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60817&r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60817&r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60817&r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60817&r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60817&r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60817&r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60817&r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60817&r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60817&r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60817&r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60817&r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60817&r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60817&r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60817&r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60817&r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60817&r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60817&r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60817&r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60817&r=mysqlcfg
Req #43203 [Com]: PDO better support for float bind values
Edit report at https://bugs.php.net/bug.php?id=43203&edit=1
ID: 43203
Comment by: r dot wilczek at web-appz dot de
Reported by:lafriks at inbox dot lv
Summary:PDO better support for float bind values
Status: Open
Type: Feature/Change Request
Package:PDO related
PHP Version:5.2.4
Block user comment: N
Private report: N
New Comment:
The missing PDO::PARAM_DOUBLE actually leads to very annoying problems.
SQLite considers a NUMERIC to be always less than a TEXT or REAL.
So string '1' is not less than double 1.1.
The following unparameterized statement shows this behaviour:
$rs = $sqlite->prepare('SELECT '1' < 1.1 as "result"');
$stmt->execute();
$rs = $stmt->fetch();
$stmt->closeCursor();
print_r($rs['result']); // 0 works as expected (and the same way as SQLite CLI.)
Now we try to perform the same operation using a parameterized statement:
$stmt = $sqlite->prepare('SELECT :left < :right as "result"');
Option A. Binding double as string:
$stmt->bindValue(':left', '1', PDO::PARAM_STR);
$stmt->bindValue(':right', 1.1, PDO::PARAM_STR);
$stmt->execute();
$rs = $stmt->fetch();
$stmt->closeCursor();
print_r($rs['result']); // 1 failure.
Option B. Binding double as integer:
$stmt->bindValue(':left', '1', PDO::PARAM_STR);
$stmt->bindValue(':right', 1.1, PDO::PARAM_INT);
$stmt->execute();
$rs = $stmt->fetch();
$stmt->closeCursor();
print_r($rs['result']); // 0 Seems to work, but ...
... this way we cannot tell double from integer. SQLite would consider
integer 1 to be less than double 1.1.
$stmt->bindValue(':left', 1, PDO::PARAM_INT);
$stmt->bindValue(':right', 1.1, PDO::PARAM_INT);
$stmt->execute();
$rs = $stmt->fetch();
$stmt->closeCursor();
print_r($rs['result']); // 0 Failure
So there is no way with PDO to correctly parameterize double values.
I request to provide PDO::PARAM_DOUBLE.
Previous Comments:
[2007-11-06 09:22:33] lafriks at inbox dot lv
Description:
It would be way easier to work with PDO if there was PDO::PARAM_FLOAT.
Otherwise there is always need to check for comma and point if in different
locales and that just makes it unnecessary hard to work with float numbers and
binding to prepared statements.
--
Edit this bug report at https://bugs.php.net/bug.php?id=43203&edit=1
Bug #60723 [Com]: error_log error time has changed to UTC ignoring default timezo
Edit report at https://bugs.php.net/bug.php?id=60723&edit=1
ID: 60723
Comment by: tomop at teamgedoh dot net
Reported by:olemarkus at gentoo dot org
Summary:error_log error time has changed to UTC ignoring
default timezo
Status: Open
Type: Bug
Package:*General Issues
Operating System: Gentoo Linux
PHP Version:5.3.9
Block user comment: N
Private report: N
New Comment:
I have the same problem.
The "localtime" argument passed to the php_format_date() function
was changed from 1 to 0 between 5.3.8 and 5.3.9.
Did it cause the problem?
In /[svn]/php/php-src/branches/PHP_5_3/main/main.c
*revision 319750, line 602:
error_time_str = php_format_date("d-M-Y H:i:s", 11, error_time, 1
TSRMLS_CC);
*revision 319823, line 602:
error_time_str = php_format_date("d-M-Y H:i:s e", 13, error_time, 0
TSRMLS_CC);
Previous Comments:
[2012-01-12 09:08:22] olemarkus at gentoo dot org
Description:
PHP error log no longer respects timezone and always logs in UTC.
Setting error_log to a filesystem path and date.default_timezone to e.g
Europe/Oslo gives the following log lines in 5.3.8:
[12-Jan-2012 10:02:38] PHP Notice: Undefined variable: foo in
/home/htdocs/index.php on line 3
[12-Jan-2012 10:02:38] PHP Fatal error: Call to a member function bar() on a
non-object in /home/htdocs/index.php on line 3
While in 5.3.9 you get:
[12-Jan-2012 09:06:00 UTC] PHP Notice: Undefined variable: foo in
/home/htdocs/index.php on line 3
[12-Jan-2012 09:06:00 UTC] PHP Fatal error: Call to a member function bar() on
a non-object in /home/htdocs/index.php on line 3
Also see downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=398445
--
Edit this bug report at https://bugs.php.net/bug.php?id=60723&edit=1
