I'm following https://xdebug.org/docs/install guideline
When I run sudo make test In my MAC 2 PHP versions are installed PHP5 & PHP7 as project requires.
PHP : /usr/local/php5/bin/php
PHP_SAPI : cli
PHP_VERSION : 7.2.7
It gives below error
=====================================================================
EXPECTED FAILED TEST SUMMARY
---------------------------------------------------------------------
Test for bug #1530: Code coverage incorrect for last code line in a loop [tests/bug01530.phpt] XFAIL REASON: PHP bug #76046: PHP generates "FE_FREE" opcode on the wrong line.
=====================================================================
You may have found a problem in PHP.
This report can be automatically sent to the PHP QA team at
http://qa.php.net/reports and http://news.php.net/php.qa.reports
This gives us a better understanding of PHP's behavior.
If you don't want to send the report immediately you can choose
option "s" to save it. You can then email it to qa-reports#lists.php.net later.
Do you want to send this report now? [Yns]:
I tried 2-3 times but same issue occurs.
the reason for the test failure is obvious:
XFAIL REASON: PHP bug #76046: PHP generates "FE_FREE" opcode on the wrong line.
you would need to patch zend_compile.c in the PHP source code (or wait for a fixed version). without patching zend_compile.c test-coverage results might be inaccurate - but nevertheless, common debugging should work. make test wouldn't check for it, when xdebug wouldn't partially rely on it (the title of the test even explicitly states why it checks for the bug). here's the diff, which adds CG(zend_lineno) = ast->lineno;. this "fixes the issue 100%" and not only it's symptoms:
index f1dd49a..9c0893b 100644 (file)
--- a/Zend/zend_compile.c
+++ b/Zend/zend_compile.c
## -4807,6 +4807,7 ## void zend_compile_foreach(zend_ast *ast) /* {{{ */
zend_end_loop(opnum_fetch, &reset_node);
+ CG(zend_lineno) = ast->lineno;
opline = zend_emit_op(NULL, ZEND_FE_FREE, &reset_node, NULL);
}
/* }}} */
this bug affects PHP 7.0, 7.1, 7.2 - PHP 5.x was at least not reported.
since this is not a xdebug bug, installing even with the failed test shouldn't make anything worse, than it already is. to install xdebug, it's not sudo make test but make && sudo make install (only make install requires sudo).
Related
I am searching for a way to check my PHP code for compatibility with different PHP versions.
Especially compatibility to PHP version 7.2 - 8.1 is what I am looking for. At first I tried phpcs but the results were not really good, so I tried something different.
To test the code I introduced phpstan which works really well (for one PHP version) but it seems it is only possible to specify one PHP version per configuration.
My phpstan.neon file:
parameters:
level: 0
phpVersion: 70400
paths:
- src/project
- src/library
Running vendor/bin/phpstan -c phpstan.neon works as expected.
Tried to specify more than one value for phpVersion but this only produces an error because the argument has to be int|null value.
Does anyone know a method to check more than one PHP vesion in just one run of phpstan? Maybe there is an appropriate rule set for different PHP versions?
From a couple of hours, PHP commands, given from the console, are not accepting local path.
For example in laravel i've always given the command
php artisan
but from this night i'm receiving the following reply
Status: 404 Not Found
Content-type: text/html; charset=UTF-8
No input file specified
but if i try php ./artisan, it's working.
The server is configured with WHM/cPanel and, the strangest thing, is that nothing has been changed, and yesterday everything was working correctly.
Also the row with the Content-type was not appearing before today.
Here I have the response (with the solution) from cPanel team that solved this problem a few hours ago.
Thanks for your patience while I corrected this issue. This was
occurring due to an update in the ea-php-cli package which occurred
last night which conflicted with another case EA-4753 in which the
include_path was set incorrectly and the issue wasn't visible until
the update of ea-php-cli last night.
I've corrected your issue and have filed case EA-5106 so that our
developers ensure that EA4 doesn't allow for this to occur again. The
current workaround is to go to Home »Software »Editor INI MultiPHP,
select the version of php, scroll down to include_path and then added
.:/path/to/php/pear as opposed to .;/path/to/php/pear which has
corrected your issue.
EDIT: We also made a downgrade of the package ea-php-cli because in this version there are multiple problems (for example when you do a 'php artisan' (or any other php file) command, it prints the headers), so the command is:
====
yum downgrade ea-php-cli-0.0.6-3.3.1
====
And is possible to lock the package, to prevent it updates automatically before a 'stable' version is released.
====
yum versionlock add ea-php-cli
====
Note that you will need to remove the versionlock once a corrected version has been released:
====
yum versionlock delete ea-php-cli
yum upgrade ea-php-cli
====
my rep is too low to up vote or comment, but i'm having this issue now it seemed to start around the same time as you and I also use a dedicated server from OVH.
I just replace serialized PHP with IGBinary .
I follow this steps:
cd /tmp
git clone https://github.com/phadej/igbinary
cd igbinary
phpize
./configure CFLAGS="-O2 -g" –-enable-igbinary –-with-php-config=/usr/bin/php-config
make
make test
make install
But in the step : make test
I get stuck with:
ERROR: Cannot run tests without CLI sapi.
and this is probably is what is causing this other error:
in
http://censocanino.com/log.php
here I use a code to see if the session starts correctly.
and that brought a couple of errors:
Warning: session_start(): Cannot find serialization handler 'igbinary' - session startup failed in /sites/censocanino.com/public/log.php on line 6
and
The current "session.save_path" is "/var/lib/php5".
Session file name: "sess_".
That error prove why phpmyadmin does't work.
http://censocanino.com/phpmyadmin/
What shows here is :
Cannot start session without errors, please check errors given in your PHP and/or webserver log file and configure your PHP installation properly. Also ensure that cookies are enabled in your browser.
all that brought me to the IGBinary Error.
thanks
SOLVED
You know that time when you haver 12 hors investigating why the code is not working and suddly you decide to type everything again .
well that happened to me , it seems was a typo erro.
may be was in --enable-igbinary that the -- were different characters.
but thanks anyway
I'm trying to get xdebug working on my Mac. I'm using OS 10.6 with the built-in versions of Apache (2.2.1) and PHP (5.3.8). I followed the "tailored installation instructions" on the xdebug website, which basically consisted of these steps:
Build xdebug (version 2.1.3) from source
Move xdebug.so to /usr/lib/php/extensions/no-debug-non-zts-20090626
Add to php.ini:
zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Restart the webserver.
From what I understand, that should be it. I know most people use xdebug with an IDE like PHPEclipse, but it doesn't sound like that's necessary just to get debugging output on the page. And a lot of old instructions involve installing MAMP, but it looks like that's no longer necessary.
Signs xdebug is working: When I run php -m and phpinfo() I get the expected information on xdebug. In scripts I'm able to call functions like xdebug_is_enabled() (returns 1) and xdebug_get_function_stack() (returns the stack).
Ways xdebug is not working: The main reason I installed xdebug was to get a stack trace when there's an error, and that's not happening. According to this documentation page, I should get a stack trace as long as display_errors is set to On in php.ini, (which it is). I've tried code that should evoke a warning (e.g., echo(hello)) as well as code that produces a fatal error (e.g., $x->awesomefunction() when $x isn't an object). Neither one produces any xdebug output, and the fatal error just causes the page to die silently. The test code given in the documentation I linked to also produces nothing.
UPDATE: It turns out that if I run a script with a fatal error from the terminal, I do get a stack trace from xdebug. However, it's still not showing up when I run the script from a browser
Also, regular error reporting is now broken: Previously, I'd get error output by including the commands:
ini_set("display_errors","1");
ERROR_REPORTING(E_ALL);
Now, putting those lines in my script doesn't produce any error reporting either. (in the browser. It does cause errors to be shown when I run the script from the terminal.)
So, what's wrong here? Did I leave something out of the xcode installation? Do I have a setting hanging around somewhere else on my system, suppressing errors? I've tried everything I can think of, but I'd be happy to test any ideas you have.
If it is working on console and not on browser, it's probably a xdebug configuration issue.
I'm not a Mac user, but on Ubuntu there are 2 different php.ini files, one for console and one for apache. If that's the case for Mac also, you can check if xdebug is enabled and properly set up in both php.ini files.
Also you can check the xdebug settings mentioned in the guide.
After several more hours of thrashing, I discovered that one of my test files actually was including another file that set display_errors to 0. The other test file was straight off of the xdebug site, but I think that at the time I was using it I'd introduced some other config error that prevented it from working properly. I'm truly embarrassed! Let this be today's object lesson in the importance of systematic, repeatable tests during debugging. On the bright side, xdebug is now working like a peach.
To summarize, the series of steps that worked was:
Build xdebug (version 2.1.3) from source
Move xdebug.so to /usr/lib/php/extensions/no-debug-non-zts-20090626
Add to php.ini: zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Add to php.ini: display_errors = On
Restart the webserver.
UPDATE (5/21/2010) SUCCESS!
So after MUCH $head->desk()'ing, I've solved it.
Remember kids, be wary of the instant client version you use, dependent on the virtualization settings!
I had been installing the generic Instant Client (not aware our ESX servers sit on AMD processors, not Intel) and that worked fine internally (the CentOS install was 32-bit since our internal ESXi servers aren't 64-bit). Well lo-and-behold, even if you have a 32-bit install running on a virtualized server which is sitting on an AMD64, it still matters what instant client you install.
It was the last thing I thought to check but as it appears, everything is running fine now.
I would like to thank everyone who helped me run through every possible test to figure this out but in the end, it was my fault for not realizing the differences in the virtualizations.
UPDATE (5/21/2010)
I thought this bug had escaped me when I installed it on a new VM internally but I have now found a narrowing link.
I was trying to install this on our production server when I posted this. After a week of no progress and in need to get back to development, I outfitted a VM on our internal server with a brand new install of Crap... CentOS, and fresh installs of instant client and oci8.
Worked perfectly.
However we just uploaded an exact copy of the VM to our production servers and it magically no longer works. Tried reinstalling everything, no avail.
So the only things I could narrow it down to is a firewall issue (although I get the same issue when trying 127.0.0.1) or possibly an ESX (our production servers) server issue, internal servers are running ESXi.
Any thoughts?
UPDATE (3/8/2010) I installed Xdebug and have it tracing my code. This is the output I am getting:
TRACE START [2010-03-08 17:53:05]
0.2090 327864 -> {main}() /data/aims3/http/octest.php:0
0.2091 327988 -> ini_set(string(14), string(1)) /data/aims3/http/octest.php:3
0.2093 327920 -> error_reporting(long) /data/aims3/http/octest.php:4
0.2094 328048 -> oci_connect(string(8), string(8), string(25)) /data/aims3/http/octest.php:6
The trace halts at that point.
I have installed everything the same way on a local server and it works fine. To say I am at a complete loss would be putting it lightly.
*NOTE: I ran make test and it returned FAIL on every test. I never ran this on my working machine to see if it reports the same errors. Any idea why make test would report FAIL but make doesn't report any error?
I've installed the Oracle Instantclient with no reported errors along with the OCI8 PECL package and at a loss. Whenever I try to open a connection with oci_connect, it halts my entire PHP script.
EXAMPLE:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
$conn = oci_connect("username", "password", "host");
echo "after";
?>
Returns a complete blank page. The module is loaded (seen in phpinfo) and everything installed with no errors.
I am at a complete loss.
CentOS: 5.4
Apache: 2.2.3
PHP: 5.3.1
InstantClient: 11.2
oci8: 1.4.1
Any thoughts?
NOTES
Apache Error Log reports nothing
Attempted Debugging:
1:
<?php
ini_set ("display_errors", "1");
error_reporting(E_ALL);
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
echo "after";
?>
Returns:
beforeafter
2:
Changing host to //host
Returns:
Same error
Is there anything in Apache's error_log? Is this mod_php or FastCGI or normal CGI PHP? What happens if you run the script via the command line?
You could also try setting PHP's error log and looking in there.
EDIT1: Try:
echo "before";
if(!function_exists('oci_connect')) die('Oracle Not Installed');
And post the results...
EDIT2: I'm really not sure. My best bet is this info from the PHP manual:
The most common problem with
installing OCI8 is not having the
Oracle environment correctly set. This
typically appears as a problem using
oci_connect() or oci_pconnect(). The
error may be a PHP error such as Call
to undefined function oci_connect(),
an Oracle error such as ORA-12705, or
even an Apache crash. Check the Apache
log files for startup errors and see
the sections above to resolve this
problem.
Anyone else have any ideas to help out Bryan?
Bryan,
I am going to be honest: I tried this two years ago and failed miserably. :) I could not get the OCI functions to work for anything by compiling myself.
But in the interest of getting it done I looked for an alternate solution and found it in Zend Core for Oracle. All I did was download, run the installer, and it was done. It installs Apache/PHP, MySQL (optional), and the InstantClient for you.
Now as Zend Server, it is basically the same product. I realize that this may not be the solution you hoped for, but if it works...
Zend Server
are you connecting to remote or to local db? i think, for localhost you must replace "host" with "false". I hope, this will help you...
edit: i think, you are missing a parameter...my last suggestions are: 1. you must set the port (default 1521) AND/OR 2. You must enter db name AND/OR you must set the instance name (the ORACLE_SID parameter)
You never check the return value of oci_connect() or call oci_error() but it doesn't look relevant to your problem since you seem to be suffering from a PHP crash. There's an open bug for RHEL that may affect you too:
http://pecl.php.net/bugs/bug.php?id=16626
Did you build the oci8 package yourself? Are you using a third-party binary?
It has been fixed. See the top for details but here is the cliff notes: virtualiztion environments matter.