Req #54564 [Opn]: extension_dir should be used for loading zend_extensions
Edit report at https://bugs.php.net/bug.php?id=54564&edit=1 ID: 54564 Updated by: s...@php.net Reported by:tyra3l at gmail dot com Summary:extension_dir should be used for loading zend_extensions Status: Open Type: Feature/Change Request Package:Scripting Engine problem PHP Version:5.3.6 Block user comment: N Private report: N New Comment: I think loading extensions through relative path opens a way to all kinds of dangerous behavior and may have problematic security implications - like ones described here: http://arstechnica.com/information-technology/2010/08/new- windows-dll-security-flaw-everything-old-is-new-again/. I'm not sure also why it is necessary - why can't PHP extension be installed in extension dir and run from there? If one needs multiple ones, multiple php.ini files can always be used. Previous Comments: [2011-04-18 23:05:25] tyra3l at gmail dot com Description: I've brought this topic on the internals http://marc.info/?l=php-internals&m=130314285822279&w=2 and I think that it would be useful and more consistent, if this could be changed, so one could easily load both "normal" and zend extensions without the need to use absolute paths. Test script: --- php -n -d zend_extension=xdebug.so -r '' Actual result: -- Failed loading xdebug.so: xdebug.so: cannot open shared object file: No such file or directory -- Edit this bug report at https://bugs.php.net/bug.php?id=54564&edit=1
Req #61421 [Asn->]: OpenSSL signature verification missing RMD160, SHA224, SHA256, SHA384, SHA512
Edit report at https://bugs.php.net/bug.php?id=61421&edit=1 ID: 61421 Updated by: s...@php.net Reported by:mark at zedwood dot com Summary:OpenSSL signature verification missing RMD160, SHA224, SHA256, SHA384, SHA512 -Status: Assigned +Status: To be documented Type: Feature/Change Request Package:OpenSSL related Operating System: Ubuntu Linux PHP Version:5.4.5 Assigned To:pajoye 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-09-14 17:56:53] mark at zedwood dot com PHP 5.4 release manager stas had me create a pull request for this bug. https://github.com/php/php-src/pull/196 [2012-07-20 00:05:02] mark at zedwood dot com updated version to php 5.4.5 [2012-06-27 06:21:58] paj...@php.net Patch compiles fine, I asked the RMs if it is fine to merge into 5.3/4. Will commit all at once once I got an answer. Thanks for your work and patience! [2012-06-21 20:14:04] mark at zedwood dot com This issue is an important feature to add to PHP, considering "SHA-1 has recently been demonstrated to provide less than 80 bits of security for digital signatures; at the publication of this Recommendation, the security strength against collisions is assessed at 69 bits. The use of SHA-1 is not recommended for the generation of digital signatures in new systems; new systems should use one of the larger hash functions. (SHA-224, SHA-256, SHA-384 and SHA-512)" https://wiki.mozilla.org/CA:MD5and1024 [2012-06-19 13:43:53] mark at zedwood dot com Those new examples are also all be in the openssl-add-sig-algs.txt patch file I uploaded yesterday. So we should be good to go. 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=61421 -- Edit this bug report at https://bugs.php.net/bug.php?id=61421&edit=1
Bug #62852 [ReO]: Unserialize Invalid Date causes crash
Edit report at https://bugs.php.net/bug.php?id=62852&edit=1 ID: 62852 Updated by: larue...@php.net Reported by:kasper at webmasteren dot eu Summary:Unserialize Invalid Date causes crash Status: Re-Opened Type: Bug Package:Reproducible crash Operating System: windows, linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: @reeze first: it's not about why he want to do this, like:"why do you want to unserialize a abnormal data?" and your new fix, will allow a incomplete date object in $foo, right? I don't this this fix is acceptable, the fix should warning about the wrong data, and result a NULL or FALSE. Previous Comments: [2012-09-16 02:31:20] re...@php.net @laruence, What do you think about this, if you have any better solutions will be much appreciated :) [2012-09-16 02:23:42] re...@php.net @tstarling the partially initialize problem could be fixed by adding and exception checking. (the attache patch is a fix for this) As the exception throwing, I think it's not bc break, since before the fix, it will just crash, fix the crash is not bc break, and the use could define __walkup method, it may throw exception too, so I think throw exception won't make unserialize inconsistant. Just my 2 cents; [2012-09-16 02:18:49] re...@php.net The following patch has been added/updated: Patch Name: Fix-add-exception-checking Revision: 1347761929 URL: https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929 [2012-09-15 06:57:20] larue...@php.net closed by commit email, reopen [2012-09-15 04:26:07] re...@php.net Yeah, the segfault is bad. but the test script is wired, why do you want to refer to it before wakeup? When construct the DateTime if invalid date it throw exception, so when unserialize from an invalid date throw exception is reasonable. 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=62852 -- Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1
Bug #62852 [Com]: Unserialize Invalid Date causes crash
Edit report at https://bugs.php.net/bug.php?id=62852&edit=1 ID: 62852 Comment by: re...@php.net Reported by:kasper at webmasteren dot eu Summary:Unserialize Invalid Date causes crash Status: Re-Opened Type: Bug Package:Reproducible crash Operating System: windows, linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: @laruence, What do you think about this, if you have any better solutions will be much appreciated :) Previous Comments: [2012-09-16 02:23:42] re...@php.net @tstarling the partially initialize problem could be fixed by adding and exception checking. (the attache patch is a fix for this) As the exception throwing, I think it's not bc break, since before the fix, it will just crash, fix the crash is not bc break, and the use could define __walkup method, it may throw exception too, so I think throw exception won't make unserialize inconsistant. Just my 2 cents; [2012-09-16 02:18:49] re...@php.net The following patch has been added/updated: Patch Name: Fix-add-exception-checking Revision: 1347761929 URL: https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929 [2012-09-15 06:57:20] larue...@php.net closed by commit email, reopen [2012-09-15 04:26:07] re...@php.net Yeah, the segfault is bad. but the test script is wired, why do you want to refer to it before wakeup? When construct the DateTime if invalid date it throw exception, so when unserialize from an invalid date throw exception is reasonable. [2012-09-15 03:33:26] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7 Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes crash)" 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=62852 -- Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1
Bug #62852 [Com]: Unserialize Invalid Date causes crash
Edit report at https://bugs.php.net/bug.php?id=62852&edit=1 ID: 62852 Comment by: re...@php.net Reported by:kasper at webmasteren dot eu Summary:Unserialize Invalid Date causes crash Status: Re-Opened Type: Bug Package:Reproducible crash Operating System: windows, linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: @tstarling the partially initialize problem could be fixed by adding and exception checking. (the attache patch is a fix for this) As the exception throwing, I think it's not bc break, since before the fix, it will just crash, fix the crash is not bc break, and the use could define __walkup method, it may throw exception too, so I think throw exception won't make unserialize inconsistant. Just my 2 cents; Previous Comments: [2012-09-16 02:18:49] re...@php.net The following patch has been added/updated: Patch Name: Fix-add-exception-checking Revision: 1347761929 URL: https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929 [2012-09-15 06:57:20] larue...@php.net closed by commit email, reopen [2012-09-15 04:26:07] re...@php.net Yeah, the segfault is bad. but the test script is wired, why do you want to refer to it before wakeup? When construct the DateTime if invalid date it throw exception, so when unserialize from an invalid date throw exception is reasonable. [2012-09-15 03:33:26] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7 Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes crash)" [2012-09-15 03:32:53] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7 Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes crash)" 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=62852 -- Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1
Bug #62852 [PATCH]: Unserialize Invalid Date causes crash
Edit report at https://bugs.php.net/bug.php?id=62852&edit=1 ID: 62852 Patch added by: re...@php.net Reported by:kasper at webmasteren dot eu Summary:Unserialize Invalid Date causes crash Status: Re-Opened Type: Bug Package:Reproducible crash Operating System: windows, linux PHP Version:Irrelevant Assigned To:laruence Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: Fix-add-exception-checking Revision: 1347761929 URL: https://bugs.php.net/patch-display.php?bug=62852&patch=Fix-add-exception-checking&revision=1347761929 Previous Comments: [2012-09-15 06:57:20] larue...@php.net closed by commit email, reopen [2012-09-15 04:26:07] re...@php.net Yeah, the segfault is bad. but the test script is wired, why do you want to refer to it before wakeup? When construct the DateTime if invalid date it throw exception, so when unserialize from an invalid date throw exception is reasonable. [2012-09-15 03:33:26] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7 Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes crash)" [2012-09-15 03:32:53] larue...@php.net Automatic comment on behalf of laruence Revision: http://git.php.net/?p=php-src.git;a=commit;h=e766f85405cd936a07a30a045f419199b6c02ed7 Log: Revert "Fixed bug #62852 (Unserialize invalid DateTime causes crash)" [2012-09-15 03:30:56] larue...@php.net @tstarling okey, I reverted. and make the test XFAIL for now, we should fix this in another way. 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=62852 -- Edit this bug report at https://bugs.php.net/bug.php?id=62852&edit=1
Bug #63097 [Com]: Segfault on php-fpm service start
Edit report at https://bugs.php.net/bug.php?id=63097&edit=1
ID: 63097
Comment by: admin at yqed dot com
Reported by:admin at yqed dot com
Summary:Segfault on php-fpm service start
Status: Open
Type: Bug
Package:FPM related
Operating System: CentOS 5/6 64bits
PHP Version:5.3.17
Block user comment: N
Private report: N
New Comment:
Some additional troubleshooting:
# DAEMON_COREFILE_LIMIT=unlimited strace -s 1024 -f /etc/init.d/php-fpm restart
2>&1 | grep -i SEGV
[pid 21884] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 21883] <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV &&
WCOREDUMP(s)}], 0, NULL) = 21884
The above error occurs on a regular basis, no matter how many times I run the
strace:
# DAEMON_COREFILE_LIMIT=unlimited strace -s 1024 -f /etc/init.d/php-fpm restart
2>&1 | grep -i SEGV
[pid 21914] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 21913] <... wait4 resumed> [{WIFSIGNALED(s) && WTERMSIG(s) == SIGSEGV &&
WCOREDUMP(s)}], 0, NULL) = 21914
I believe it could be related to this bug:
https://bugs.php.net/bug.php?id=61231
Previous Comments:
[2012-09-16 01:36:48] admin at qyqed dot com
The segfault occurs randomly, I can restart the service several times without
issues. All of the sudden, it pops without explanation.
[2012-09-16 01:34:28] admin at yqed dot com
The error format I get when I restart the php-fpm service:
# service php-fpm restart
Stopping php-fpm: [ OK ]
Starting php-fpm: /bin/bash: line 1: 20659 Segmentation fault
/usr/sbin/php-
fpm -y /etc/php-fpm/php-fpm.conf
[FAILED]
[2012-09-16 01:25:02] admin at yqed dot com
Description:
This issue started making surface with PHP 5.3.15 and is still present in
5.3.17
release. In /var/log/messages, you will see entries similar to:
hermes kernel: php-fpm[20659]: segfault at 2aea5a750210 rip
003ca220da3e
rsp 7fff6b7d56b0 error 4
I created a objdump which will help you precisely locate the current issue.
Test script:
---
php-fpm.debug objdump file: http://www.mediafire.com/?qbkjzbidj9b1zsr
--
Edit this bug report at https://bugs.php.net/bug.php?id=63097&edit=1
Bug #63097 [Com]: Segfault on php-fpm service start
Edit report at https://bugs.php.net/bug.php?id=63097&edit=1 ID: 63097 Comment by: admin at qyqed dot com Reported by:admin at yqed dot com Summary:Segfault on php-fpm service start Status: Open Type: Bug Package:FPM related Operating System: CentOS 5/6 64bits PHP Version:5.3.17 Block user comment: N Private report: N New Comment: The segfault occurs randomly, I can restart the service several times without issues. All of the sudden, it pops without explanation. Previous Comments: [2012-09-16 01:34:28] admin at yqed dot com The error format I get when I restart the php-fpm service: # service php-fpm restart Stopping php-fpm: [ OK ] Starting php-fpm: /bin/bash: line 1: 20659 Segmentation fault /usr/sbin/php- fpm -y /etc/php-fpm/php-fpm.conf [FAILED] [2012-09-16 01:25:02] admin at yqed dot com Description: This issue started making surface with PHP 5.3.15 and is still present in 5.3.17 release. In /var/log/messages, you will see entries similar to: hermes kernel: php-fpm[20659]: segfault at 2aea5a750210 rip 003ca220da3e rsp 7fff6b7d56b0 error 4 I created a objdump which will help you precisely locate the current issue. Test script: --- php-fpm.debug objdump file: http://www.mediafire.com/?qbkjzbidj9b1zsr -- Edit this bug report at https://bugs.php.net/bug.php?id=63097&edit=1
Bug #63097 [Com]: Segfault on php-fpm service start
Edit report at https://bugs.php.net/bug.php?id=63097&edit=1 ID: 63097 Comment by: admin at yqed dot com Reported by:admin at yqed dot com Summary:Segfault on php-fpm service start Status: Open Type: Bug Package:FPM related Operating System: CentOS 5/6 64bits PHP Version:5.3.17 Block user comment: N Private report: N New Comment: The error format I get when I restart the php-fpm service: # service php-fpm restart Stopping php-fpm: [ OK ] Starting php-fpm: /bin/bash: line 1: 20659 Segmentation fault /usr/sbin/php- fpm -y /etc/php-fpm/php-fpm.conf [FAILED] Previous Comments: [2012-09-16 01:25:02] admin at yqed dot com Description: This issue started making surface with PHP 5.3.15 and is still present in 5.3.17 release. In /var/log/messages, you will see entries similar to: hermes kernel: php-fpm[20659]: segfault at 2aea5a750210 rip 003ca220da3e rsp 7fff6b7d56b0 error 4 I created a objdump which will help you precisely locate the current issue. Test script: --- php-fpm.debug objdump file: http://www.mediafire.com/?qbkjzbidj9b1zsr -- Edit this bug report at https://bugs.php.net/bug.php?id=63097&edit=1
Bug #63096 [Opn->Fbk]: Crash when run cli script
Edit report at https://bugs.php.net/bug.php?id=63096&edit=1 ID: 63096 Updated by: re...@php.net Reported by:pracanowo at gmail dot com Summary:Crash when run cli script -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: win xp sp3 PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Could you please try to get a reproducible test script ? if possible it would be much easier to spot. Previous Comments: [2012-09-15 20:48:36] pracanowo at gmail dot com Error are somtimes random, script parse lot of data [ so i think is preg ], on Monday i will be able to reproduce error, now all sessio that my script need handle are finish. I need also create some markers in my code. Now i install Xdebug. I remember in 5.3 whose the same now i update to 5.4.7 [2012-09-15 19:32:54] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-09-15 17:49:09] pracanowo at gmail dot com Description: [Web crawler preg curl etc] Report for php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name Operating System Windows XP Dodatek Service Pack 3 Number Of Processors 2 Process ID 2688 Process Image ...php.exe System Up-Time 8 day(s) 01:44:43 Process Up-Time 00:02:07 Thread 0 - System ID 3144 Entry point php!sapi_cli_single_write+80d8 Create time 2012-09-15 13:28:59 Time spent in user mode 0 Days 0:0:43.468 Time spent in kernel mode 0 Days 0:0:1.109 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5!zval_dtor_func+45 02b24040 0128f408 03ab0a38 0128f408 php5!zend_objects_store_del_ref_by_handle_ex+24b 01280888 00c1e8f0 00c1e944 php5!execute+164 012bea58 012bc688 00c1e9a8 00c1e9b4 php5!zend_call_function+269 00c1e9b4 012bc688 00c1e9a8 1050f034 php5!zend_objects_destroy_object+bc 03d0ccb8 000c 012253b4 03587678 php5!libiconv_open+57a97 Exception Information PHP5!ZVAL_DTOR_FUNC+45WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp the assembly instruction at php5!zval_dtor_func+45 in G:\Home\PHP5\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x1874 on thread 0 Test script: --- too big need first find error line -- Edit this bug report at https://bugs.php.net/bug.php?id=63096&edit=1
[PHP-BUG] Bug #63097 [NEW]: Segfault on php-fpm service start
From: admin at yqed dot com Operating system: CentOS 5/6 64bits PHP version: 5.3.17 Package: FPM related Bug Type: Bug Bug description:Segfault on php-fpm service start Description: This issue started making surface with PHP 5.3.15 and is still present in 5.3.17 release. In /var/log/messages, you will see entries similar to: hermes kernel: php-fpm[20659]: segfault at 2aea5a750210 rip 003ca220da3e rsp 7fff6b7d56b0 error 4 I created a objdump which will help you precisely locate the current issue. Test script: --- php-fpm.debug objdump file: http://www.mediafire.com/?qbkjzbidj9b1zsr -- Edit bug report at https://bugs.php.net/bug.php?id=63097&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63097&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63097&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63097&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63097&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63097&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63097&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63097&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63097&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63097&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63097&r=support Expected behavior: https://bugs.php.net/fix.php?id=63097&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63097&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63097&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63097&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63097&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63097&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63097&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63097&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63097&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63097&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63097&r=mysqlcfg
Req #41810 [Nab]: Unable to catch Parse Errors
Edit report at https://bugs.php.net/bug.php?id=41810&edit=1
ID: 41810
Updated by: ras...@php.net
Reported by:d dot albano at gmail dot com
Summary:Unable to catch Parse Errors
Status: Not a bug
Type: Feature/Change Request
Package:*General Issues
Operating System: Linux
PHP Version:5.2.3
Block user comment: N
Private report: N
New Comment:
This can't be done safely within the same parser instance as your main script.
You will need to create a separate instance, as in system("php -l $script"); to
do that check. I would suggest you do this once when these scripts are created
and move them into a "checked" directory or something so you don't do it on
every
include.
Previous Comments:
[2012-09-15 20:53:11] james dot dobb at gmail dot com
I agree that this, perhaps not a bug but a missing feature needs to be
addressed,
There should be a secure way of including scripts from another script and be
able
to continue the calling script if an error occurs, the lack of functionality
here
is causing me a major headache.
[2010-07-02 13:41:24] paj...@php.net
It is not, please double read the manual about require/include_once.
[2010-07-02 12:34:32] sneak at datavibe dot net
This classification is not bogus at all. Consider the following:
== main.php ==
== myfile.php ==
The parsing of myfile.php must necessarily happen at main.php's RUNTIME,
because
the filename is not available until sprintf() is called.
This is a bug.
[2007-07-03 16:36:51] tony2...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
[2007-07-03 16:29:58] d dot albano at gmail dot com
Looking to the code looks simply to do the modification, naturally, as you
said, the problem is testing.
However i founded an eval behaviour to support my feature request: if there is
a parse error execution continues
Can be that this is a bug or an unwanted behaviour, however nothing start to
work strange after that a parse error was outputted.
So, if all works with eval why it shouldn't work correctly with normal parse
errors?
Here there is some example code:
It output
BEGIN
Parse error: syntax error, unexpected '-', expecting '}' in
C:\web\htdocs\test.php(5) : eval()'d code on line 1
END
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=41810
--
Edit this bug report at https://bugs.php.net/bug.php?id=41810&edit=1
Req #41810 [Com]: Unable to catch Parse Errors
Edit report at https://bugs.php.net/bug.php?id=41810&edit=1 ID: 41810 Comment by: james dot dobb at gmail dot com Reported by:d dot albano at gmail dot com Summary:Unable to catch Parse Errors Status: Not a bug Type: Feature/Change Request Package:*General Issues Operating System: Linux PHP Version:5.2.3 Block user comment: N Private report: N New Comment: I agree that this, perhaps not a bug but a missing feature needs to be addressed, There should be a secure way of including scripts from another script and be able to continue the calling script if an error occurs, the lack of functionality here is causing me a major headache. Previous Comments: [2010-07-02 13:41:24] paj...@php.net It is not, please double read the manual about require/include_once. [2010-07-02 12:34:32] sneak at datavibe dot net This classification is not bogus at all. Consider the following: == main.php == == myfile.php == The parsing of myfile.php must necessarily happen at main.php's RUNTIME, because the filename is not available until sprintf() is called. This is a bug. [2007-07-03 16:36:51] tony2...@php.net Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php [2007-07-03 16:29:58] d dot albano at gmail dot com Looking to the code looks simply to do the modification, naturally, as you said, the problem is testing. However i founded an eval behaviour to support my feature request: if there is a parse error execution continues Can be that this is a bug or an unwanted behaviour, however nothing start to work strange after that a parse error was outputted. So, if all works with eval why it shouldn't work correctly with normal parse errors? Here there is some example code: It output BEGIN Parse error: syntax error, unexpected '-', expecting '}' in C:\web\htdocs\test.php(5) : eval()'d code on line 1 END [2007-06-26 13:07:22] d dot albano at gmail dot com When i said: > If it remains in a unstable state there is serious problem somewhere i answered to your phrase: > After parse error the parser/compiler and whole engine may be in unstable state If parsing a file may put the entire engine in an unstable state there is a problem: never heard that a parser can do this The problem can be that the engine is written to shutdown after a parser error and this is can cause troubles i think, but the problem is that i'm not zend/php developer :) However i don't think that is necessary to rewrite the engine from the scracth, a feature like this, at logic level, must follow rules followed by other errors This afternoon i'll take a look to the parser and to the zend engine to understand how errors are passed Thanks a lot Bye 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=41810 -- Edit this bug report at https://bugs.php.net/bug.php?id=41810&edit=1
Bug #63096 [Fbk->Opn]: Crash when run cli script
Edit report at https://bugs.php.net/bug.php?id=63096&edit=1 ID: 63096 User updated by:pracanowo at gmail dot com Reported by:pracanowo at gmail dot com Summary:Crash when run cli script -Status: Feedback +Status: Open Type: Bug Package:*General Issues Operating System: win xp sp3 PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Error are somtimes random, script parse lot of data [ so i think is preg ], on Monday i will be able to reproduce error, now all sessio that my script need handle are finish. I need also create some markers in my code. Now i install Xdebug. I remember in 5.3 whose the same now i update to 5.4.7 Previous Comments: [2012-09-15 19:32:54] fel...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. [2012-09-15 17:49:09] pracanowo at gmail dot com Description: [Web crawler preg curl etc] Report for php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name Operating System Windows XP Dodatek Service Pack 3 Number Of Processors 2 Process ID 2688 Process Image ...php.exe System Up-Time 8 day(s) 01:44:43 Process Up-Time 00:02:07 Thread 0 - System ID 3144 Entry point php!sapi_cli_single_write+80d8 Create time 2012-09-15 13:28:59 Time spent in user mode 0 Days 0:0:43.468 Time spent in kernel mode 0 Days 0:0:1.109 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5!zval_dtor_func+45 02b24040 0128f408 03ab0a38 0128f408 php5!zend_objects_store_del_ref_by_handle_ex+24b 01280888 00c1e8f0 00c1e944 php5!execute+164 012bea58 012bc688 00c1e9a8 00c1e9b4 php5!zend_call_function+269 00c1e9b4 012bc688 00c1e9a8 1050f034 php5!zend_objects_destroy_object+bc 03d0ccb8 000c 012253b4 03587678 php5!libiconv_open+57a97 Exception Information PHP5!ZVAL_DTOR_FUNC+45WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp the assembly instruction at php5!zval_dtor_func+45 in G:\Home\PHP5\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x1874 on thread 0 Test script: --- too big need first find error line -- Edit this bug report at https://bugs.php.net/bug.php?id=63096&edit=1
Bug #63096 [Opn->Fbk]: Crash when run cli script
Edit report at https://bugs.php.net/bug.php?id=63096&edit=1 ID: 63096 Updated by: fel...@php.net Reported by:pracanowo at gmail dot com Summary:Crash when run cli script -Status: Open +Status: Feedback Type: Bug Package:*General Issues Operating System: win xp sp3 PHP Version:5.4.7 Block user comment: N Private report: N New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. Previous Comments: [2012-09-15 17:49:09] pracanowo at gmail dot com Description: [Web crawler preg curl etc] Report for php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name Operating System Windows XP Dodatek Service Pack 3 Number Of Processors 2 Process ID 2688 Process Image ...php.exe System Up-Time 8 day(s) 01:44:43 Process Up-Time 00:02:07 Thread 0 - System ID 3144 Entry point php!sapi_cli_single_write+80d8 Create time 2012-09-15 13:28:59 Time spent in user mode 0 Days 0:0:43.468 Time spent in kernel mode 0 Days 0:0:1.109 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5!zval_dtor_func+45 02b24040 0128f408 03ab0a38 0128f408 php5!zend_objects_store_del_ref_by_handle_ex+24b 01280888 00c1e8f0 00c1e944 php5!execute+164 012bea58 012bc688 00c1e9a8 00c1e9b4 php5!zend_call_function+269 00c1e9b4 012bc688 00c1e9a8 1050f034 php5!zend_objects_destroy_object+bc 03d0ccb8 000c 012253b4 03587678 php5!libiconv_open+57a97 Exception Information PHP5!ZVAL_DTOR_FUNC+45WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp the assembly instruction at php5!zval_dtor_func+45 in G:\Home\PHP5\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x1874 on thread 0 Test script: --- too big need first find error line -- Edit this bug report at https://bugs.php.net/bug.php?id=63096&edit=1
[PHP-BUG] Bug #63096 [NEW]: Crash when run cli script
From: pracanowo at gmail dot com Operating system: win xp sp3 PHP version: 5.4.7 Package: *General Issues Bug Type: Bug Bug description:Crash when run cli script Description: [Web crawler preg curl etc] Report for php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp Type of Analysis Performed Crash Analysis Machine Name Operating System Windows XP Dodatek Service Pack 3 Number Of Processors 2 Process ID 2688 Process Image ...php.exe System Up-Time 8 day(s) 01:44:43 Process Up-Time 00:02:07 Thread 0 - System ID 3144 Entry point php!sapi_cli_single_write+80d8 Create time 2012-09-15 13:28:59 Time spent in user mode 0 Days 0:0:43.468 Time spent in kernel mode 0 Days 0:0:1.109 Full Call Stack Function Arg 1 Arg 2 Arg 3 Arg 4 Source php5!zval_dtor_func+45 02b24040 0128f408 03ab0a38 0128f408 php5!zend_objects_store_del_ref_by_handle_ex+24b 01280888 00c1e8f0 00c1e944 php5!execute+164 012bea58 012bc688 00c1e9a8 00c1e9b4 php5!zend_call_function+269 00c1e9b4 012bc688 00c1e9a8 1050f034 php5!zend_objects_destroy_object+bc 03d0ccb8 000c 012253b4 03587678 php5!libiconv_open+57a97 Exception Information PHP5!ZVAL_DTOR_FUNC+45WARNING - DebugDiag was not able to locate debug symbols for php5.dll, so the information below may be incomplete. In php__PID__2688__Date__09_15_2012__Time_01_31_06PM__296__Second_Chance_Exception_C005.dmp the assembly instruction at php5!zval_dtor_func+45 in G:\Home\PHP5\php5.dll from The PHP Group has caused an access violation exception (0xC005) when trying to read from memory location 0x1874 on thread 0 Test script: --- too big need first find error line -- Edit bug report at https://bugs.php.net/bug.php?id=63096&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63096&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63096&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63096&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63096&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63096&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63096&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63096&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63096&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63096&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63096&r=support Expected behavior: https://bugs.php.net/fix.php?id=63096&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63096&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63096&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63096&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63096&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63096&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63096&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63096&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63096&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63096&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63096&r=mysqlcfg
Bug #62452 [Com]: Variable Aliasing does not work in Closure
Edit report at https://bugs.php.net/bug.php?id=62452&edit=1
ID: 62452
Comment by: ni...@php.net
Reported by:hanskrentel at yahoo dot de
Summary:Variable Aliasing does not work in Closure
Status: Re-Opened
Type: Bug
Package:Scripting Engine problem
Operating System: Multiple
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
I just looked into this a bit but couldn't find a good way to fix it. The main
issue is that the prototype hack is only done in ZEND_INIT_FCALL_BY_NAME and
only for VARs. Doing the same for CVs (as in this case) would be easy, but it
sadly does not work properly if the closure is also invoked using
call_user_func or any other function using zend_call_function internally.
zend_call_function does not back the closure into the prototype and due to the
way it works I'm not sure how this could be added there. For zcf the
get_closure object handler call is done within zend_is_callable_ex and the
results are put into the passed function_call_cache then. But the fcc can be
reused for multiple calls (or not be used at all), so I really don't know how
to do this safely without causing leaks or double frees.
Previous Comments:
[2012-07-03 17:49:27] ni...@php.net
@laruence: The closure can still exist even if it is not referenced by $f
anymore. I didn't look into this yet, but the fix should be along the lines of
adding a ref to the closure when it is called and removing it again when it
finishes running. Actually, I remember seeing something in the code that backs
up the function zval into op_array.prototype (disguised as a zend_function*)
and dtors it in the leave_helper. But clearly that isn't enough yet.
[2012-07-03 17:39:24] hanskrentel at yahoo dot de
hi @laurence, thank's for taking the time to review it. If I write code like
unset($this);
it does not fatal error either (you can not destroy a object while you are
calling
it.).
Also I don't want to destroy the closure, I just want to re-use that variable.
Can't you just let the garbage collector do the dirty work?
[2012-07-02 07:03:19] larue...@php.net
you can not destroy a closure while you are calling it.
when you override $f in $f, zend vm try to destroy the closure $f, since the
refcout of it is 1.
try following :
$b = $f = function() use (&$f) {
$f = function() {};
};
$f();
$f();
[2012-06-29 20:05:06] ni...@php.net
Verified on master.
[2012-06-29 19:53:22] hanskrentel at yahoo dot de
Description:
It's not possible to make use of variable aliasing in PHP when the alias is
used
within the use clause of a lambda function construct that is assigned to that
variable (recursion).
PHP denies to do what it is commanded with a Fatal error: Cannot destroy active
lambda function. But the function is not destroyed. It's just not that the
variable container contains the identifier of it.
I'd like to change that, and I don't want to waste another variable name. Also
I
don't understand how I can actually destroy something I should not have any
access
to from PHP userland.
Or if that is intended, please allow us to destroy the active lambda making the
function return NULL and continue to execute.
Test script:
---
$f = function() use (&$f) {
$f = function() {echo "hello"};
};
$f();
$f();
Expected result:
hello
Actual result:
--
Fatal error: Cannot destroy active lambda function
--
Edit this bug report at https://bugs.php.net/bug.php?id=62452&edit=1
[PHP-BUG] Bug #63094 [NEW]: Different behavior of $_POST data when setting mbstring.internal_encoding on ru
From: seven at nivas dot hr Operating system: windows & unix PHP version: 5.4.7 Package: mbstring related Bug Type: Bug Bug description:Different behavior of $_POST data when setting mbstring.internal_encoding on ru Description: I am unaware if this is a bug or feature, but itâs strange. It should be fixed or documented somewhere. Iâve run into this in process of debugging a problem I was having with old code running on php 5.4 and php 5.4.7 which caused all utf8 form data to be submitted in wrong encoding. Instead of â[Å¡ÄÄÄž]â I would get â[à ¡ÃÂÃÂÃÂà ¾]â. After a while I've found out that because of the utf8 changes implemented into php 5.4.x mbstring.http_input=auto should be set to âpassâ. my php.ini has default_charset = "UTF-8" and my form is on utf8 html page and https://bugs.php.net/bug.php?id=63094&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63094&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63094&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63094&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63094&r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=63094&r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=63094&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63094&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63094&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63094&r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=63094&r=support Expected behavior: https://bugs.php.net/fix.php?id=63094&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63094&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63094&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63094&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63094&r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=63094&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63094&r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=63094&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63094&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63094&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63094&r=mysqlcfg
Bug #62885 [Csd]: mysqli_poll - Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=62885&edit=1
ID: 62885
Updated by: larue...@php.net
Reported by:mateusz dot goik at aliantsoft dot pl
Summary:mysqli_poll - Segmentation fault
Status: Closed
Type: Bug
Package:MySQLi related
Operating System: Backtrack 5r2
PHP Version:5.4Git-2012-08-21 (snap)
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
seems this fix is not merged into 5.4.7 release,
https://github.com/php/php-src/blob/php-5.4.7/NEWS
Previous Comments:
[2012-09-15 09:20:12] mateusz dot goik at aliantsoft dot pl
PHP 5.4.7 (cli) (built: Sep 14 2012 21:58:46)
Program received signal SIGSEGV, Segmentation fault.
0x084b1d2e in mysqlnd_stream_array_check_for_readiness (conn_array=0x0) at
/home/test/Pobrane/php-5.4.7/ext/mysqlnd/mysqlnd.c:1113
1113while (*p) {
[2012-08-22 05:49:22] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e5bdd2c0eeab50dc1f863dae9a32d3857ece6a79
Log: Fixed bug #62885 (mysqli_poll - Segmentation fault)
[2012-08-22 05:48:13] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e5bdd2c0eeab50dc1f863dae9a32d3857ece6a79
Log: Fixed bug #62885 (mysqli_poll - Segmentation fault)
[2012-08-22 05:40:53] larue...@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.
hmm, simple fix.. committed
[2012-08-22 05:39:13] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e5bdd2c0eeab50dc1f863dae9a32d3857ece6a79
Log: Fixed bug #62885 (mysqli_poll - Segmentation fault)
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=62885
--
Edit this bug report at https://bugs.php.net/bug.php?id=62885&edit=1
Bug #62885 [Com]: mysqli_poll - Segmentation fault
Edit report at https://bugs.php.net/bug.php?id=62885&edit=1
ID: 62885
Comment by: mateusz dot goik at aliantsoft dot pl
Reported by:mateusz dot goik at aliantsoft dot pl
Summary:mysqli_poll - Segmentation fault
Status: Closed
Type: Bug
Package:MySQLi related
Operating System: Backtrack 5r2
PHP Version:5.4Git-2012-08-21 (snap)
Assigned To:laruence
Block user comment: N
Private report: N
New Comment:
PHP 5.4.7 (cli) (built: Sep 14 2012 21:58:46)
Program received signal SIGSEGV, Segmentation fault.
0x084b1d2e in mysqlnd_stream_array_check_for_readiness (conn_array=0x0) at
/home/test/Pobrane/php-5.4.7/ext/mysqlnd/mysqlnd.c:1113
1113while (*p) {
Previous Comments:
[2012-08-22 05:49:22] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e5bdd2c0eeab50dc1f863dae9a32d3857ece6a79
Log: Fixed bug #62885 (mysqli_poll - Segmentation fault)
[2012-08-22 05:48:13] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e5bdd2c0eeab50dc1f863dae9a32d3857ece6a79
Log: Fixed bug #62885 (mysqli_poll - Segmentation fault)
[2012-08-22 05:40:53] larue...@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.
hmm, simple fix.. committed
[2012-08-22 05:39:13] larue...@php.net
Automatic comment on behalf of laruence
Revision:
http://git.php.net/?p=php-src.git;a=commit;h=e5bdd2c0eeab50dc1f863dae9a32d3857ece6a79
Log: Fixed bug #62885 (mysqli_poll - Segmentation fault)
[2012-08-21 23:58:48] mateusz dot goik at aliantsoft dot pl
Description:
mysqli_poll - Segmentation fault
PHP 5.4.7-dev (cli) (built: Aug 22 2012 00:48:06)
Program received signal SIGSEGV, Segmentation fault.
0x009051a1 in mysqlnd_stream_array_check_for_readiness (conn_array=0x0)
at /home/test/php-trunk-201208212130/ext/mysqlnd/mysqlnd.c:1113
1113while (*p) {
Test script:
---
Actual result:
--
#0 0x009051a1 in mysqlnd_stream_array_check_for_readiness
(conn_array=0x0) at /home/test/php-trunk-201208212130/ext/mysqlnd/mysqlnd.c:1113
#1 0x00905533 in _mysqlnd_poll (r_array=0x0, e_array=0x0,
dont_poll=0x7fff82480080, sec=0, usec=0, desc_num=0x7fff8248006c) at
/home/test/php-trunk-201208212130/ext/mysqlnd/mysqlnd.c:1223
#2 0x006e6012 in zif_mysqli_poll (ht=4, return_value=0x7fb217b8b370,
return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at
/home/test/php-trunk-201208212130/ext/mysqli/mysqli_nonapi.c:791
#3 0x009fe45c in zend_do_fcall_common_helper_SPEC
(execute_data=0x7fb217b57060) at
/home/test/php-trunk-201208212130/Zend/zend_vm_execute.h:642
#4 0x00a05075 in ZEND_DO_FCALL_SPEC_CONST_HANDLER
(execute_data=0x7fb217b57060) at
/home/test/php-trunk-201208212130/Zend/zend_vm_execute.h:2219
#5 0x009fcefd in execute (op_array=0x7fb217b8ac50) at
/home/test/php-trunk-201208212130/Zend/zend_vm_execute.h:410
#6 0x009c38e3 in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /home/test/php-trunk-201208212130/Zend/zend.c:1286
#7 0x009413a4 in php_execute_script (primary_file=0x7fff82483940) at
/home/test/php-trunk-201208212130/main/main.c:2473
#8 0x00af847d in do_cli (argc=2, argv=0x7fff82483cf8) at
/home/test/php-trunk-201208212130/sapi/cli/php_cli.c:988
#9 0x00af92a3 in main (argc=2, argv=0x7fff82483cf8) at
/home/test/php-trunk-201208212130/sapi/cli/php_cli.c:1364
--
Edit this bug report at https://bugs.php.net/bug.php?id=62885&edit=1
