In my symfony project I got an error with a vendor.
Fatal error: Uncaught Symfony\Component\Debug\Exception\FatalThrowableError: Type error: Argument 1 passed to eZ\Publish\Core\MVC\Legacy\Kernel\Loader::setCLIHandler() must implement interface ezpKernelHandler, instance of eZ\Publish\Core\MVC\Legacy\Kernel\CLIHandler given, called in /Users/steve/Projects/Web/BuildSuccess/www/vendor/ezsystems/legacy-bridge/mvc/Kernel/Loader.php on line 237 in /Users/steve/Projects/Web/BuildSuccess/www/vendor/ezsystems/legacy-bridge/mvc/Kernel/Loader.php:255
But this error is strange because I checked and eZ\Publish\Core\MVC\Legacy\Kernel\CLIHandler implements the interface ezpKernelHandler !
namespace eZ\Publish\Core\MVC\Legacy\Kernel;
use ezpKernelHandler;
class CLIHandler implements ezpKernelHandler
{
...
}
I tried to debug, with get_class method and I get
"eZ\Publish\Core\MVC\Legacy\Kernel\CLIHandler"
I also used class_implements method and I get
array(0) {
}
Any idea what append ?
Thanks
I see that it is not your code, but rather eZ Publish itself. Because of this it is unlikely that you will be able to update sources, but there is still some things that you can do:
Check your Composer autoloader configuration to see that ezpKernelHandler class is properly resolved. You may need to register custom autoloader for it.
You're most likely receiving this error because you're using Symfony 3.3+ and its recently added services auto-configuration features. You can avoid this error to be thrown by disabling service auto-configuration for affected service, take a look at example here
Since this error is fatal but catchable - if nothing else will help you can create your own service factory for this particular service and catch error inside it.
Fixed : https://github.com/ezsystems/LegacyBridge/issues/132
It is easilly fixed by creating app/autoload.php file which requires both vendor/autoload.php and ezpublish_legacy/autoload.php and changing bin/console to require that file instead of vendor/autoload.php
I'm running drupal 8, composer and npm to perform gulp tasks.
When I run npm start.. my task manager: I get the following stack trace:
Fatal error: Uncaught exception 'Twig_Error_Syntax' with message 'Unknown "render" filter.' in /web/project/web/themes/emulsify/components/_patterns/04-templates/basic-page/_basic_page.twig:26
Stack trace:
#0 /web/project/web/themes/emulsify/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(481): Twig_ExpressionParser->getFilterNodeClass('render', 26)
#1 /web/project/web/themes/project_theme/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(466): Twig_ExpressionParser->parseFilterExpressionRaw(Object(Twig_Node_Expression_Name))
#2 /web/project/web/themes/project_theme/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(320): Twig_ExpressionParser->parseFilterExpression(Object(Twig_Node_Expression_Name))
#3 /web/project/web/themes/project_theme/pattern-lab/vendor/twig/twig/lib/Twig/ExpressionParser.php(212): Twig_ExpressionParser->parsePostfixExpression(Object(Twig_Node_Expression_Name))
#4 /web/project in /web/project/web/themes/project_theme/components/_patterns/04-templates/basic-page/_basic_page.twig on line 26
I've looked at installing twig-bridge / symfony twig via composer but I can't seem to get rid of the error message.
Do I just ditch using the twig filter "render"?
Update: 14/08/17
I've also ran into the same problem when trying to use the drupal_block function provided via Drupal 8's twig_tweak module.
The problem in the code above is that your Twig extension class is extending the internal Drupal Twig extension class. That breaks the Twig extensions added by Drupal core and that's why you are getting the error.
To fix this, you should make your Twig extensions extend Twigs internal Twig extension class. Your class should be defined like this:
class MyExtension extends \Twig_Extension {
After making that change, you can also remove arguments set for that class from the MODULE.services.yml
link
I've not seen this in the Drupal context, but working with other platforms that use Twig, I have seen similar issues occurring when an error occurs early in the platform setup process.
The typical sequence of events is like this:
The platform starts running its bootup; loading the CMS core, etc.
At some point early in this process, it hits an error.
It then tries to render an error page.
However, the error page uses a Twig template.
The startup process has not yet loaded all the twig extensions used in the template.
Boom, you get a twig error stating "unknown Twig function" instead of the real error message.
When I've had this before, it has proved very hard to diagnose what the actual error is.
The "correct" solution has been to modify the error page templates so that they are minimal and don't use any non-core twig functions. But if you're getting a crash early in the page load process it can be hard to actually do that.
In the first case, I resolved it by debugging the system and trapping what data was passed to the template. This showed me what the real error was. Resolving that error then stopped the twig error from occurring and allowed me to get into the system.
I don't know for sure if what you're seeing is the same kind of thing as what I was seeing, but it sounds similar so I hope this will help.
I'm trying to wrap a test class around a pre-existing PHP class file that does not adhere to any PSR standard.
The PHP object I'm trying to test has a constructor that accepts 1 argument.
When prepping my object in setUp, my test correctly fails because there is a constructor argument missing. Because of this, I feel good that my object is being correctly resolved.
protected function setUp() {
$this->object = new HierarchyChange();
}
However, when I do add a value:
$this->object = new HierarchyChange('username');
NetBeans throws a "Perhaps error occurred, verify in Output window" message when I run the tests. And the output window has no information.
Executing "phpunit . -v" from the command line simply outputs the PHPUnit version I'm working with, but does not show any exception information.
I've tracked the failing line in my HierarchyChange class to this line in the class constructor:
public function __construct($agent_manager)
{
/* require contracting base class */
require_once($_SERVER['DOCUMENT_ROOT'] . '/_inc/oc.class.php');
I've tried a number of different ways to add this file, thinking that the server variable was causing the problem, but even removing it and hardcoding the path in the constructor cause the test suite to crash.
It DOES, however, work when I comment out the require_once line completely.
It doesn't make sense to me why this fails, but I am grasping at straws with this. Thanks.
The issue stemmed from a few things:
incorrect configuration of PHP.ini (error messages were not being raised), but more importantly:
incorrectly setting server vars; I ended up modifying the phpunit.xml configuration file to include:
Since the tests were being executed via CLI, these server variables are not available, so they needed to be set. And when phpunit encountered this as an error, NetBeans didn't know how to report it in the output window because the local INI configuration was not set to do so.
I am upgrading a site from Fedora 14, PHP4, and PEAR DB to Fedora 16, PHP 5.4 and PEAR MDB2 2.5.0b3, and I am getting the error
Fatal error: Call to undefined function: MDB2_Driver_MYSQL::getAll(). in /usr/share/php/MDB2.php on line 1892
Obviously, I've checked line 1892 of the MDB2.php file, and it contains the error reporting code for the __call magic method (allows you to call a specific function by passing it into __call)
I have checked for usages of __call, and there don't seem to be any. Likewise, when I try to find where MDB2_Driver_MYSQL is coming from, the only place it is even mentioned is in MDB2.php (as a comment about the driver for MySQL), in the class declaration (class MDB2_Driver_mysql extends MDB2_Driver_Common), and the description title in the .xml file.
I have manually included the /usr/share/php/MDB2/Extended.php file in the file where the MDB2_Driver_mysql class is defined, and that didn't help (not that this would have been a permanant fix...)
Has anyone encountered this error, and if so, what did you do to fix it? Google has proved nearly useless, as the only place it is specifically mentioned doesn't really deal with fixing it.
change getAll() in your class, to queryAll(), cause there some difference between DB & MDB2, and the same with getOne, getRow - they all changed to queryOne, queryRow. Here you can read about it http://www.phpied.com/db-2-mdb2/
Make sure you load the extended module in your code prior to making a query, similar to below:
$db->loadModule('Extended');
When a PHPUnit test fails normally on my dev box (Linux Mint), it causes a "Segmentation Fault" on my Continous Integration box (Centos). Both machines are running the same version of PHPUnit. My dev box is running PHP 5.3.2-1ubuntu4.9, and the CI is PHP 5.2.17. I'd rather leave upgrading the PHP as a last resort though.
As per this thread: PHPUnit gets segmentation fault
I have tried deactivating / reinstalling Xdebug. I don't have inclue.so installed.
On the CI box I currently only have two extensions active: dom from php-xml (required for phpunit) and memcache (required by my framework), all the others have been turned off.
Next to what cweiske suggests, if upgrading PHP is not an option for you and you have problems to locate the source of the segfault, you can use a debugger to find out more.
You can launch gdb this way to debug a PHPUnit session:
gdb --args php /usr/bin/phpunit quiz_service_Test.php
Then type in r to run the program and/or set environment variables first.
set env MALLOC_CHECK_=3
r
You might also consider to install the debugging symbols for PHP on the system to get better results for debugging. gdb checks this on startup for you and leaves a notice how you can do so.
I've had an issue with PHPUnit segfaulting and had trouble finding an answer, so hopefully this helps someone with the same issue later.
PHPUnit was segfaulting, but only:
If there was an error (or more than one)
After all tests had run but before the errors were printed
After a while I realized that it was due to failures on tests that used data providers, and specifically for data providers that passed objects with lots of recursive references. A bell finally went off and I did some digging: the problem is that when you're using data providers and a test fails, PHPUnit tries to create a string representation of the provided arguments for the failure description to tell you what failed, but this is problematic when one of the arguments has some infinite recursion. In fact, what PHPUnit does in PHPUnit_Framework_TestCase::dataToString() (around line 1612) is print out all the arguments provided by the data provider using print_r, which causes the segfault when PHP tries to create a string representation of the infinitely recursive object.
The solution I came to was:
Use a single base class for all my test classes (which fortunately I was already doing)
Override dataToString() in my test base class, to check for these kinds of objects in the data array (which is possible in my case because I know what these objects look like). If the object is present, I return some special value, if not I just pass it along to the parent method.
I had similar problem and by disabling the garbge collactor in
PHPStorm => Edit configuration => Interpreter option : -d
zend.enable_gc=0
Or if you are running your tests from the command line you may try adding :
-d zend.enable_gc=0
When you get a segfault, upgrade your PHP to the latest version. Not only the latest in your package manager, but the latest available on php.net. If it still segfaults, you are sure that the problem has not been fixed yet in PHP itself. Don't bother trying to get rid of a segfault in old version of PHP because it might have been fixed already in a newer one.
Next step is to locating the problem: Make your test smaller and smaller until you can't remove anything (but it still segfaults). If you have that, move the test into a standalone php script that segfaults. Now you have a test script for your bug in the PHP bug tracker.
In addition to https://stackoverflow.com/a/38789046/246790 which helped me a lot:
You can use PHP function gc_disable();
I have placed it in my PHPUnit bootstrap code as well with ini_set('memory_limit', -1);
I had the same problem and could nail it down, that I tried to write a class variable which was not definied:
My class (it's a cakePHP-class) which caused segmentation fault:
class MyClass extends AppModel {
protected $classVariableOne;
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
// This line caused the segmentation fault as the variable doesn't exists
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
I fixed it by adding the second variable:
class MyClass extends AppModel {
protected $classVariableOne;
protected $classVariableTwo; // Added this line
public function __construct($id = false, $table = null, $ds = null) {
parent::__construct($id, $table, $ds);
$this->classVariableOne =& ClassRegistry::init('ClassVariableOne');
$this->classVariableTwo =& ClassRegistry::init('ClassVariableTwo');
}
}
Infinite recursion is normally what causes this issue for us. The symptoms of infinite recursion seem to be different when running code under phpunit, than they are when running it in other environments.
If anyone comes across this in relation to PHPunit within Laravel
It took a while to figure out what the issue was. I was going over the differences between my current code and the previous revision and through some trial and error finally got there.
I had two different models that were both including each other with the protected $with override.
This must have been causing some kind of loop that phpunit could not deal with.
Hopefully someone finds this useful.
Please update to the newest XDEBUG. Got the same error while using v3.1.5, and after upgrading to 3.1.6 eveything works.
I got into the same problem. I upgraded the PHPUnit to the 4.1 version (to run the tests) and it was able to show me the object, as pointed by Isaac.
So, if you get to this very same problem, upgrade to PHPUnit >= 4.1 and you'll be able to see the error instead of getting "Segmentation fault" message.
I kept getting a Segmentation fault: 11 when running PHPUnit with Code coverage. After doing a stack trace of the segmentation fault, I found the following was causing the Segmentation fault error:
Program received signal SIGSEGV, Segmentation fault.
0x0000000100b8421a in xdebug_path_info_get_path_for_level () from /usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
I replaced my current xdebug.so in the path above with the latest version from the Komodo Remote Debugging Package the sub-folder of the corresponding downloaded package with the PHP version I have (which is 5.5 for me) and everything worked.
The following fixed a similar issue for me (when the output of the gdb backtrace included libcurl.so and libcrypto.so):
disable /etc/php.d/pgsql.ini:
; Enable pgsql extension module
; extension=pgsql.so
edit /etc/php.d/curl.ini to ensure that pgsql.so is included before curl:
; Enable curl extension module
extension=pgsql.so
extension=curl.so
curl.cainfo=/home/statcounter/include/config/cacert.pem
if you have an object with property pointing to the same object, or other sort of pointer loops, you will have this message while running
serialize($object);
And if you are a Laravel user, and you are dealing with models. And if you think, you will never have this problem, because you avoiding pointer loops by using $hidden property on your models, please be advised, the $hidden property does not affect serialize, it only affects casting to JSON and array.
I had this problem, when I had a model saved into a property of a Mailable object.
fixed with
$this->model->refresh();
in a __construct method , just before the whole object is serialized.
This related to code not extension. In my case i had these two files
Test Case
Example Test
In Test Case there is method called createApplication. Just leave it empty.
In Example Test you can create the method and fill with
$this->assertTrue(true)
Above is basic setup hope you can extend the requirement as you need.