I am using php 5.5.9 on Ubuntu 14.04. I have upgraded Xdebug to the version that its Wizard recommends, that is version 2.2.6, and I have used apt-get to make sure my Ubuntu system is up to date. The problem is, however, that my code coverage reports lines as executed when they are clearly not.
Here are the offending lines:
if(!$filter->isValid()) {
throw new Exception\InvalidInput($this->formatFilterErrors($filter));
}
I know that the conditional code inside the if statement is not being executed, since the filtered data is always valid. I can prove this by putting echo or die statements in the code block (above the throw statement) and they are never executed.
So why is code coverage telling me that the throw statement is being executed, numerous times?
Although I only have one example of incorrect reporting I really need to sort it out as a priority since I have a lot of testing to do on this application. I could try upgraded PHP (but that has other consequences, of course). Apart from that, my only option is to raise a but with the developer.
Have you come across this bug? I have heard of others having problems with Xdebug on Ubuntu 14.04, but upgrading Xdebug has sorted their problems out.
Related
I was using PHP 7.0.4 and everything was running smoothly and I just upgraded to PHP 7.0.8 and I started getting errors like this one all over the place.
Fatal error: Cannot declare class Plugins\Users\Plugin because the name is already in use in /var/www/html/plugins/Users/Plugin.php on line 8
Does anyone have any idea whats going on, I've been reading through the change logs but that's a patch update it should not break anything?
Additionally, if no solution is found to this problem, how can I downgrade back to 7.0.4? (I'm using ubuntu 16.04 and I just upgraded to the point release)
To sum the comments so far:
I have tried disabling opcache this did not solve the problem
I am using composer's autoloader - I am not using require or include anywhere
This error is happening for a ton of classes, so it is clearly not a code issue (on my part), furthermore the code was working before I upgraded to 7.0.8
There is not enough data to say definitively, however I suspect opcache. That error, in fact, originates in opcache so I suspect until this point the error had been hidden by one of several opcode bugs, probably #66773.
You legitimately have an autoloading issue that needs to be fixed. Rename the class, check your namespaces, and remove any hard requires.
You might be able to restore the former buggy behavior by disabling/re-enabling opcache or reverting to 7.0.4, but really the bug was only masked by a particular combination of autoloading and opcache. It was, indeed, only by chance that the issue went undetected until now and it'll be only by chance that you can mask it again.
So the best course is to fix the issue.
Well, apparently I was so blinded by the fact that the error started occurring after the upgrade, that I ignored it even though it was right before my eyes.
These are the first few lines of the class in question (and apparently a bunch of other classes):
<?php
namespace Plugins\Users;
use FW\Utility\Models\Plugins\Plugin;
class Plugin extends Plugin {
As you, and finally I, can clearly see, the class name Plugin is ambiguous, but wasn't in 7.0.4, which is weird and is probably caused by the bug described in bishop's answer
Guess I should have listened to Machavity, huh.
Firstly forgive me if my terminology isn't entirely accurate. I have only limited knowledge on this subject, but will best try to convey the problems we are having. My server administrator is trying to deploy php 5.5.9 on a live server. Originally the intention was to install php 5.4.x, but we opted for the latest version instead (a manual compile is required regardless due to the o/s)
The O/S is OpenSuse 12.1 and the server is a Plesk server (Plesk Version 11.0.9) with Apache 2.2.1. This particular o/s does not have the ability to update php automatically so everything has to be done manually. Since we didn't want to risk screwing up the server (currently running with php 5.3.8), we opted to install a second version of php alongside the current one. The instructions we followed are outlined here: http://kb.parallels.com/en/114753
After numerous failed attempts due to missing libraries during compilation, we were finally able to compile php 5.5.9 without error and then proceeded to run tests with 'make test'
Unfortunately, the test results came back with 32 failures and 20% of the total tests were skipped. A total of 13011 tests were done, 10410 of which were completed. The TEST SUMMARY can be downloaded from here: http://uploaded.net/file/v6ug55l8
Anyway, deciding we might aswell give it a try, we applied the changes as indicated in the first link above to the vhost.conf. However, it didn't work, and the vhost then returned Internal Server Errors for every page regardless of script or extension. The errors logs sadly do not indicate any errors, only a whole ton of internal server errors recorded by mod_security. We did notice a huge number of these in the error log: Warning: SuexecUserGroup directive requires SUEXEC wrapper. But, it doesn't seem to be related, as the same error goes back several weeks.
So, we're stuck without any idea what to do next. Our next attempt will be to try and compile a php 5.4.x instead, as perhaps something is bumping heads with 5.5.9...
Any and all advice will be appreciated. As per the opening statement, I'm not an expert here, so if you need any additional information about the machine and it's server, feel free to ask. Thankyou for your attention!
Problem solved. The vhost's CGI-BIN needed to be CHMOD 755 and not 775.
I'm having a strange issue with PHPUnit. I'm working on a project with a team of developers, all of which must use PHPUnit 3.6.5. For the most part, my PHPUnit works great and yields the same results as on other developers' machines. However, I will occasionally find that a certain line isn't covered on my machine, but is on other developers' machines. Here is a recent scenario:
Bob is checking in a new file that he just updated. He made sure the unit test passed for this file and had 95% code coverage. After performing this check, he checks in the file, where it is built and the unit test is run. If the unit test fails on the server, our build goes red and nobody can check in.
The server runs the phpunit test and it passes.
Other developers, including myself, get the latest from the perforce repository
After making my own set of changes, I run all of the phpunit tests for the application, but I notice one of the files does not have enough code coverage. It's the file that Bob just checked in. I check with some of the other developers on my team and the file passes code coverage without any problems for them. When I check the code coverage report, I see the following:
array_walk(
$variable1,
function($val,$key) use(&$variableData, &$variable2)
{
$variableData[$variable2][$key] = 1;
}
);
$variable1,
function($val,$key) use(&$variableData, &$variable2)
These two lines are not covered! I don't understand why my phpunit doesn't want to cover these lines. There must be a setting that I am not aware of that is causing this as I have the same version of PHPUnit as other developers and it passes fine on their machine but not on mine. I'm also seeing the same problem in a statement like this:
if ($var === 1) {
echo 'yes';
} else {
echo 'nope';
}
Now, the unit test will cover both conditions, however, it doesn't cover the following line:
} else {
Does this make any sense at all? The strangest part about it is that it works most of the time, but there are a few locations that have this behavior, though there is no pattern to indicate what it causing it. I've had other developers look at this issue on my machine and they are baffled and cannot explain what is causing it. The problem is, since it is failing for me locally, even though I haven't touched Bob's file, it is preventing me from checking in my changes. Has anyone ran into this problem before? I am going to try uninstalling php unit and re-installing it, but other than that, I am at a loss for words. Any help would be greatly appreciated! Here are my specs:
PHPUnit: Version 3.6.5
Operating system: OS X 10.6.8
PHP: PHP 5.3.8-ZS5.5.0 (cli) (built: Aug 24 2011 11:03:29)
Zend Debugger: Turned off
XDebug: Turned on
Zend Optimizer+: off
Regards,
Will
Executable and executed lines are reported by xdebug to PHPUnit. Different versions of xdebug may vary in the lines reported as covered.
If you feel that they are incorrect, provide a simple testcase and open a bug at xdebug's issue tracker.
I'm currently trying to level up on my PHP debugging skills and as part of that I'm trying to learn several new tools. One of them is inclued.
The extension seemingly works fine (no startup error, shows up in phpinfo, generates dump files), but it always reports number of includes as 0, so something is clearly not working right.
At first I suspected this was related to my heavy use of auto_include, but after doing some tests which do not, I doubt that is related.
Class graphs are generated OK, but include maps simply don't exist. Am I simply Doing It Wrong, or is the extension broken? I just don't know and even after some heavy duty googling cannot find anything useful.
I installed inclued using the "phpize method". My PHP version is 5.3.2 running on Mac OSX 10.6.5. I also have XDebug and memtrack installed.
After doing a test run with valgrind watching Apache I noticed xdebug was operating below inclued. On a blind test I tried disabling XDebug and lo and behold: inclued works as expected.
So to answer my own question:
Don't use XDebug in conjunction with inclued if you want to have include graphs. Class graphing works fine with XDebug running.
I've been working on writing unit tests for my PHP code. PHPUnit is what I'm using for this.
I have some classes that work great until...
I throw XDebug into the mix.
At that point, PHPUnit doesn't crash or anything, but setExpectedException never triggers.
In fact, the code never goes beyond that point.
Anyone run across this and know what the solution is?
Edit: This is with the PHP5.2.6, Latest versions of XUnit and XDebug. This is on linux fedora 7
I've had some problems before with one combination of Xdebug & PHPUnit (as did others, from a report I say on devzone.zend.com at the time), but that was a while ago. PHPUnit does explicitly support Xdebug though - and I'm using it to produce code coverage reports for my own systems.
I'd suggest the fairly standard debugging techniques, updating any versions you can (maybe even PHP?) commenting out the #setExpectedException, or throwing it explicitly - and of course, making sure that you have full warnings and errors being shown with error_reporting(E_ALL|E_STRICT); set on.
Don't forget to stop and restart the Apache server to make sure that the Xdebug module is loaded as well.