MantisBT - Xdebug
View Issue Details
0001263Xdebug(No Category)public2016-02-04 17:332016-06-06 22:26
iwex 
derick 
normalcrashalways
closedfixed 
LinuxUbuntu14.04
2.4.0rc4 
2.4.1 
7.0.0-7.0.4
0001263: Code coverage segmentation fault
When we run ours coverage tests we get Segmentation fault error.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff4f69173 in xdebug_build_fname_from_oparray (tmp=tmp@entry=0x7ffffffefb40, opa=opa@entry=0x7fffeac95b60) at /build/xdebug-FUEUgA/xdebug-2.4.0~rc4/xdebug-2.4.0RC4/xdebug_code_coverage.c:812
812 /build/xdebug-FUEUgA/xdebug-2.4.0~rc4/xdebug-2.4.0RC4/xdebug_code_coverage.c: No such file or directory.
This causes error:

public function getRequest()
    {
        if ($this->request === null) {
            $this->request = Request::find($this->getRequestId());
        }
        return $this->request;
    }

This works fine:

public function getRequest()
    {
        if ($this->request === null) {
            $requestId = $this->getRequestId();
            $this->request = Request::find($requestId);
        }
        return $this->request;
    }
No tags attached.
gz xdebug_test.tar.gz (1,030,525) 2016-02-17 08:54
https://bugs.xdebug.org/file_download.php?file_id=299&type=bug
txt xdebug_info.txt (7,550) 2016-02-17 11:47
https://bugs.xdebug.org/file_download.php?file_id=300&type=bug
? valgrind.out (17,987) 2016-02-18 21:38
https://bugs.xdebug.org/file_download.php?file_id=301&type=bug
Issue History
2016-02-04 17:33iwexNew Issue
2016-02-05 10:31derickNote Added: 0003437
2016-02-05 10:31derickAssigned To => derick
2016-02-05 10:31derickStatusnew => feedback
2016-02-08 13:27TonyBologniNote Added: 0003441
2016-02-08 16:48derickNote Added: 0003442
2016-02-09 16:02TonyBologniNote Added: 0003469
2016-02-11 18:48derickNote Added: 0003482
2016-02-12 09:34TonyBologniNote Added: 0003494
2016-02-16 11:29TonyBologniNote Added: 0003497
2016-02-16 12:06derickNote Added: 0003498
2016-02-17 08:54TonyBologniFile Added: xdebug_test.tar.gz
2016-02-17 08:58TonyBologniNote Added: 0003499
2016-02-17 11:27derickNote Added: 0003500
2016-02-17 11:47TonyBologniFile Added: xdebug_info.txt
2016-02-17 16:36TonyBologniNote Added: 0003501
2016-02-18 14:47ondrejNote Added: 0003502
2016-02-18 14:54TonyBologniNote Added: 0003503
2016-02-18 15:23ondrejNote Added: 0003504
2016-02-18 15:36ondrejNote Added: 0003505
2016-02-18 15:47ondrejNote Added: 0003506
2016-02-18 15:53TonyBologniNote Added: 0003507
2016-02-18 15:54TonyBologniNote Added: 0003508
2016-02-18 15:59derickNote Added: 0003509
2016-02-18 21:37TonyBologniNote Added: 0003510
2016-02-18 21:38TonyBologniFile Added: valgrind.out
2016-02-18 21:51TonyBologniNote Edited: 0003510bug_revision_view_page.php?bugnote_id=3510#r260
2016-02-22 10:55TonyBologniNote Added: 0003512
2016-02-22 11:38derickNote Added: 0003513
2016-02-22 11:39derickNote Added: 0003514
2016-02-25 11:16TonyBologniNote Added: 0003520
2016-02-27 16:03derickNote Added: 0003531
2016-06-06 22:26derickNote Added: 0003628
2016-06-06 22:26derickStatusfeedback => closed
2016-06-06 22:26derickResolutionopen => fixed
2016-06-06 22:26derickFixed in Version => 2.4.1
2016-07-31 13:35derickCategoryDebug client (console) => debugclient (debugging tool)
2016-07-31 13:35derickCategorydebugclient (debugging tool) => (No Category)

Notes
(0003437)
derick   
2016-02-05 10:31   
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
(0003441)
TonyBologni   
2016-02-08 13:27   
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
(0003442)
derick   
2016-02-08 16:48   
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.
(0003469)
TonyBologni   
2016-02-09 16:02   
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.
(0003482)
derick   
2016-02-11 18:48   
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)?
(0003494)
TonyBologni   
2016-02-12 09:34   
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.
(0003497)
TonyBologni   
2016-02-16 11:29   
Derick, would it help if I build phar archive including everything that's causing our segfault problem?
(0003498)
derick   
2016-02-16 12:06   
TonyBolgoni - no, please no phar. Just something I can extract and run (like a .tar.gz)
(0003499)
TonyBologni   
2016-02-17 08:58   
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.
(0003500)
derick   
2016-02-17 11:27   
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.
(0003501)
TonyBologni   
2016-02-17 16:36   
I've uploded the file, in case you were not notified.
(0003502)
ondrej   
2016-02-18 14:47   
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)
```
(0003503)
TonyBologni   
2016-02-18 14:54   
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?
(0003504)
ondrej   
2016-02-18 15:23   
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?
(0003505)
ondrej   
2016-02-18 15:36   
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
```
(0003506)
ondrej   
2016-02-18 15:47   
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?
(0003507)
TonyBologni   
2016-02-18 15:53   
# 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)
(0003508)
TonyBologni   
2016-02-18 15:54   
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.
(0003509)
derick   
2016-02-18 15:59   
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.
(0003510)
TonyBologni   
2016-02-18 21:37   
(edited on: 2016-02-18 21:51)
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.

(0003512)
TonyBologni   
2016-02-22 10:55   
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.
(0003513)
derick   
2016-02-22 11:38   
Tony, I can reproduce this now, with opcache loaded and enabled on the cli.
(0003514)
derick   
2016-02-22 11:39   
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"

...
(0003520)
TonyBologni   
2016-02-25 11:16   
Derick, is that something you can fix, or is it upstream? In opcache?
(0003531)
derick   
2016-02-27 16:03   
No, I just need some time for this.
(0003628)
derick   
2016-06-06 22:26   
My test cases now pass. I'm marking this as fixed for 2.4.1 which I'll be releasing shortly.