Can you provide a full but small script that I can run that demonstrates the problem? Starting it with:

<?php
xdebug_code_coverage_start( XDEBUG_CC_UNUSED | XDEBUG_CC_DEAD_CODE );

… your code …

should do the trick

We have the same problem here.
Some more input, maybe it helps.

Ubuntu 15.10 with PHP from Sury PPA

PHP 5.6 with coverage works:

PHP 5.6.18-2+deb.sury.org~wily+1 (cli)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.4.0RC4, Copyright (c) 2002-2016, by Derick Rethans

PHP 7.0 with coverage does segfault:

PHP 7.0.3-2+deb.sury.org~wily+1 (cli) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies
with Xdebug v2.4.0RC4, Copyright (c) 2002-2016, by Derick Rethans

TonyBologni, iwex. I really need a reproducible script that I can run locally (without any dependencies) to fix this. Without this, I can't debug it.

Hi Derick!

The problem is that I have no idea what causes the segfault, so how to reproduce without dependencies.
Even our simplest tests fail, but for sure they have dependencies, at minimum they extend \PHPUnit_Framework_TestCase which uses Composer's autoloader to bootstrap.

I have tried some simple script (as you suggested above), but this works fine.

TonyBolgoni - can you packaged it up in something that I can run with a "one shot command"? (Ie, without having to setup or configure anything)?

Oh my.
Not tried to package anything yet, I have zero experience with phar, etc.

Seems the original problem in this bug is not exactly the problem we are facing, we can't make anything work by changing the code that is tested.

@Derick, should I open another bug? Our problem seems very much related with PHPUnit and output while xdebug_coverate is started, but not stopped.

Derick, would it help if I build phar archive including everything that's causing our segfault problem?

TonyBolgoni - no, please no phar. Just something I can extract and run (like a .tar.gz)

Hi Derick, the archive I have uploaded works for me, hopefully also for you.

Run where you extract it:

bin/phpunit --configuration build/phpunit-with-coverage.xml

This assumes xdebug is enabled, I have it disabled by default, so I run:
php -dzend_extension=xdebug.so bin/phpunit --configuration build/phpunit-with-coverage.xml

I hope this is sufficient for identifying the problem.

Tony, sorry, I can't reproduce this with PHP 7.0.4 and Xdebug 2.4.0RC3, RC4 and RC5-dev. I might need more information:

The output of:

php -dzend_extension=xdebug.so -v
php -dzend_extension=xdebug.so --ri Xdebug

And then the output of:

Export variables:
export USE_ZEND_ALLOC=0

Starts gdb (you might have to install it first):
gdb --args php -dzend_extension=xdebug.so bin/phpunit --configuration build/phpunit-with-coverage.xml

On the prompt type:
run

And when it crashes, type:
bt full

Please attach all three outputs, put together in one file.

I've uploded the file, in case you were not notified.

JFTR I can't get this to segfault with PHP 7.0.3-5 on Debian unstable and xdebug 2.4.0~rc4.

Nor I can reproduce this on neither Ubuntu Trusty nor Ubuntu Wily with PHP 7.0.3-4 and 7.0.3-5.

I tested this on amd64 arch. Just for the case I tried Ubuntu Wily i386 and I can't reproduce this there. I don't have any armhf around to test.

valgrind also doesn't detect anything suspicious (on i386):

# valgrind php bin/phpunit --configuration build/phpunit-with-coverage.xml 
==35167== Memcheck, a memory error detector
==35167== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==35167== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==35167== Command: php bin/phpunit --configuration build/phpunit-with-coverage.xml
==35167== 
PHPUnit 5.2.4 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.0.3-5+deb.sury.org~wily+1 with Xdebug 2.4.0RC4
Configuration: /tmp/xdebug/build/phpunit-with-coverage.xml

.                                                                   1 / 1 (100%)

Time: 2.3 seconds, Memory: 4.00Mb

OK (1 test, 1 assertion)

Generating code coverage report in Clover XML format ... done
==35167== 
==35167== HEAP SUMMARY:
==35167==     in use at exit: 127,857 bytes in 4,144 blocks
==35167==   total heap usage: 95,443 allocs, 91,299 frees, 5,598,289 bytes allocated
==35167== 
==35167== LEAK SUMMARY:
==35167==    definitely lost: 64 bytes in 4 blocks
==35167==    indirectly lost: 0 bytes in 0 blocks
==35167==      possibly lost: 0 bytes in 0 blocks
==35167==    still reachable: 127,793 bytes in 4,140 blocks
==35167==         suppressed: 0 bytes in 0 blocks
==35167== Rerun with --leak-check=full to see details of leaked memory
==35167== 
==35167== For counts of detected and suppressed errors, rerun with: -v
==35167== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Hi Ondrej, that's weird. I have it on two different machines, so it does not seem to be a weird edge case.

Any chance it has to do with remainders of PHP5 (also from your PPA) that were not removed by apt? If so, what would I look for?

I don't think that leftovers from php5 should matter at all. You could issue apt-get --purge remove php5-common to do the cleanup, but PHP 7.0 packaging is completely independent.

Any chance you have any other PECL extensions installed & enabled?

Just checked whether I can reproduce this on Debian jessie (my build machine):

bin/phpunit --configuration build/phpunit-with-coverage.xml
PHPUnit 5.2.4 by Sebastian Bergmann and contributors.

Runtime:       PHP 7.0.3-5~bpo80+1 with Xdebug 2.4.0RC4
Configuration: /tmp/xdebug/build/phpunit-with-coverage.xml

.                                                                   1 / 1 (100%)

Time: 73 ms, Memory: 4.00Mb

OK (1 test, 1 assertion)

Generating code coverage report in Clover XML format ... done

Or any cruft installed in /usr/local/? (This is also common source of random unreproducible segfaults.) What does ldd /usr/bin/php7.0 and ldd /usr/lib/php/20151012/xdebug.so says?

ldd /usr/bin/php7.0

linux-vdso.so.1 =>  (0x00007fff1c992000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f4b51463000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f4b51248000)
libdb-5.3.so => /usr/lib/x86_64-linux-gnu/libdb-5.3.so (0x00007f4b50e9a000)
libqdbm.so.14 => /usr/lib/libqdbm.so.14 (0x00007f4b50c4c000)
libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f4b509df000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4b506d6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4b504d2000)
libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f4b5011a000)
libssl.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 (0x00007f4b4feb1000)
libcrypto.so.1.0.2 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.2 (0x00007f4b4fa67000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4b4f69d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4b4f47e000)
/lib64/ld-linux-x86-64.so.2 (0x00005616599a0000)
libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f4b4f0ea000)
libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f4b4d632000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f4b4d2b0000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f4b4d099000)

ldd /usr/lib/php/20151012/xdebug.so

linux-vdso.so.1 =>  (0x00007ffd37779000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f01a1b1b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f01a1751000)
/lib64/ld-linux-x86-64.so.2 (0x000055b994646000)

Regarding pecl / pear.
No package was currently installed and now I have even removed dh-php and php-pear. And anything I found that might have been leftovers from former pecl/pear installs.

In your output I see a big number that's -2 without the sign. Which should only happen if there is something wrong with the data type. But I ought to get the same thing and I'm not.

I found something.
If I disable opcache on cli it works!

I have installed a brand new Ubuntu 14.04 (server) with only PHP 7.0 from Ondrey PPA and tested on that.

The two machines that also segfault are Ubuntu 15.10 (desktop) and there it's the same. With disabled opcache it works.

I have attach a valgrind -v output.

I have also tested on another brand new 14.04 server, same result, works without opcache, coredumps with opcache.

Hi Derick, Ondrej!

Any updates?
I have done what I can do.
With the tgz I have provided it fails on two different "off the shelve" Ubuntu 14.04 installations when opcache is enabled.
If I can provide any more input, please let me know.

Tony, I can reproduce this now, with opcache loaded and enabled on the cli.

Valgrind also shows issues now:

derick@whisky:/tmp/test $ valgrind php -dopcache.enable_cli=1 -dzend_extension=opcache.so bin/phpunit --configuration build/phpunit-with-coverage.xml
==28797== Memcheck, a memory error detector
==28797== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28797== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==28797== Command: php -dopcache.enable_cli=1 -dzend_extension=opcache.so bin/phpunit --configuration build/phpunit-with-coverage.xml
==28797==
PHPUnit 5.2.4 by Sebastian Bergmann and contributors.

Runtime: PHP 7.0.3-dev with Xdebug 2.4.0RC5-dev
Configuration: /tmp/test/build/phpunit-with-coverage.xml

==28797== Invalid read of size 1
==28797== at 0xF3800EC: xdebug_set_in_ex (xdebug_set.c:71)
==28797== by 0xF36BA00: xdebug_analyse_branch (xdebug_code_coverage.c:705)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== by 0xF36BAC4: xdebug_analyse_branch (xdebug_code_coverage.c:729)
==28797== Address 0x159c2b14 is 2,548 bytes inside an unallocated block of size 101,952 in arena "client"

...

Derick, is that something you can fix, or is it upstream? In opcache?

No, I just need some time for this.

My test cases now pass. I'm marking this as fixed for 2.4.1 which I'll be releasing shortly.