How to diagnose these PHP-Code-Coverage segmentati

问题:

I have been happily coding away on my Ubuntu machine. It's a beefy machine with plenty of RAM. I was working on 4 new classes, writing and running unit tests as I go. At some point I noticed that, while the unit tests were completing fine, code coverage was not.

After the message "Generating code coverage report...etc.." I would get a message saying zend_mm_heap corrupted. I tried a few fixes including: setting output_buffering = On in my php.ini (both apache2 and cli), and removing calls to unset() from my code. (I read on SO these fixed might be required).

Now, I seem to alternate between the zend_mm... error, and a Segmentation fault (core dump) error, no matter what I do. I comment out tests until I narrow down the one that I think causes the problem, and make some changes there until I get a clean run. Then I'll uncomment all the test only to find the that fault still occurs.

Any ideas? What tools or method could I use to gather more info?

I am using PHP_CodeCoverage 1.2.6, PHP 5.3.10-1ubuntu3.5, PHPUnit 3.7.9.

EDIT:

As an aside, I can't find any core dump files. Have searched from the root of both my physical disks with no luck. I have read the man entry on core, including the possible reasons for core dumps not creating a file, but I don't think any of those apply.

回答1:

I had the same issue recently. It appears to be an issue with PHP garbage collection. Disabling garbage collection during phpunit runs solved the problem to me.

Add:

zend.enable_gc=0 

to your php.ini file or from the command line with:

phpunit -d zend.enable_gc=0

回答2:

It's really hard sometimes to understand the Segmentation fault error when running PhpUnit with code coverage. I had segmentation fault on PHP 7.0.5 with 2 versions of PhpUnit.

Finally, after tracking the issue down in my case something like this was causing segmentation fault

$x = doSomething(doSomethingElse());

and extracting internal function to variable like so:

$y = doSomethingElse();
$x = doSomething($y);

solved the issue. This above it's of course simplified code but you should understand sometimes there's no real fault in your code but you should modify this to make PhpUnit with code coverage work for your code.

回答3:

I had the same issue and tried using zend.enable_gc=0, but then phpunit ran out of memory. To fix it, I basically modified my coverage whitelist to be more granular. So, in phpunit.xml, where I previously had this:

<filter>
    <whitelist>
        <directory suffix=".php">../application/src</directory>
    </whitelist>
</filter>

I changed it to this:

<filter>
    <whitelist>
        <directory suffix=".php">../application/src/module1</directory>
        <directory suffix=".php">../application/src/module2</directory>
        <directory suffix=".php">../application/src/module3</directory>
        <exclude>
            <directory>../application/src/module1/views</directory>
        </exclude>

    </whitelist>
</filter>

So just try to limit the filter to only include the files that actually matter. It's still a bug, but for now I think that limiting the amount of files that get considered for the coverage calculation will help prevent these sort of issues.