PHPUnit Segmentation fault

Question

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 sam

Answer 1

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.

Answer 2

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.

Answer 3

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:

1. Use a single base class for all my test classes (which fortunately I was already doing)
2. 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.

Answer 4

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');

  }
}

Answer 5

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.

Answer 6

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