xdebug configuration change - breaks coverage reports

[robertdeboer]

We use this image for running PHPUnit test in as part of our GitLab CI process for projects. Today I have noticed that running PHP Unit configurations with clover reports for coverage no longer creates these reports.

In order to verify if it was something within the docker environment,I have gone to other another project that uses the same image and push a small text file to trigger the CI and confirmed the coverage report is not being created. Looking at past CI pipelines, my last successful run was 1 month ago

The next job - ran a week or so after that is when I first see this issue pop up:

Using the latest PHPUnit produces the following:

When I grep XDebug settings as a pre-script action, I see the following:

/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini,
xdebug
Support Xdebug on Patreon, GitHub, or as a business: https://xdebug.org/support
xdebug.auto_trace => no value => no value
xdebug.cli_color => 0 => 0
xdebug.client_discovery_header => no value => no value
xdebug.client_host => localhost => localhost
xdebug.client_port => 9003 => 9003
xdebug.cloud_id => no value => no value
xdebug.collect_assignments => Off => Off
xdebug.collect_includes => no value => no value
xdebug.collect_params => no value => no value
xdebug.collect_return => Off => Off
xdebug.collect_vars => no value => no value
xdebug.connect_timeout_ms => 200 => 200
xdebug.coverage_enable => no value => no value
xdebug.default_enable => no value => no value
xdebug.discover_client_host => Off => Off
xdebug.dump.COOKIE => no value => no value
xdebug.dump.ENV => no value => no value
xdebug.dump.FILES => no value => no value
xdebug.dump.GET => no value => no value
xdebug.dump.POST => no value => no value
xdebug.dump.REQUEST => no value => no value
xdebug.dump.SERVER => no value => no value
xdebug.dump.SESSION => no value => no value
xdebug.dump_globals => On => On
xdebug.dump_once => On => On
xdebug.dump_undefined => Off => Off
xdebug.extended_info => no value => no value
xdebug.file_link_format => no value => no value
xdebug.filename_format => no value => no value
xdebug.force_display_errors => Off => Off
xdebug.force_error_reporting => 0 => 0
xdebug.gc_stats_enable => no value => no value
xdebug.gc_stats_output_dir => no value => no value
xdebug.gc_stats_output_name => gcstats.%p => gcstats.%p
xdebug.halt_level => 0 => 0
xdebug.idekey => no value => no value
xdebug.log => no value => no value
xdebug.log_level => 7 => 7
xdebug.max_nesting_level => 256 => 256
xdebug.max_stack_frames => -1 => -1
xdebug.mode => develop => develop
xdebug.output_dir => /tmp => /tmp
xdebug.overload_var_dump => no value => no value
xdebug.profiler_append => Off => Off
xdebug.profiler_enable => no value => no value
xdebug.profiler_enable_trigger => no value => no value
xdebug.profiler_enable_trigger_value => no value => no value
xdebug.profiler_output_dir => no value => no value
xdebug.profiler_output_name => cachegrind.out.%p => cachegrind.out.%p
xdebug.remote_autostart => no value => no value
xdebug.remote_connect_back => no value => no value
xdebug.remote_enable => no value => no value
xdebug.remote_handler => no value => no value
xdebug.remote_host => no value => no value
xdebug.remote_log => no value => no value
xdebug.remote_log_level => no value => no value
xdebug.remote_mode => no value => no value
xdebug.remote_port => no value => no value
xdebug.remote_timeout => no value => no value
xdebug.scream => Off => Off
xdebug.show_error_trace => Off => Off
xdebug.show_exception_trace => Off => Off
xdebug.show_local_vars => Off => Off
xdebug.show_mem_delta => no value => no value
xdebug.start_upon_error => default => default
xdebug.start_with_request => default => default
xdebug.trace_enable_trigger => no value => no value
xdebug.trace_enable_trigger_value => no value => no value
xdebug.trace_format => 0 => 0
xdebug.trace_options => 0 => 0
xdebug.trace_output_dir => no value => no value
xdebug.trace_output_name => trace.%c => trace.%c
xdebug.trigger_value => no value => no value
xdebug.var_display_max_children => 128 => 128
xdebug.var_display_max_data => 512 => 512
xdebug.var_display_max_depth => 3 => 3

Here is the GitLab CI file for the project

stages:
  - test
  - quality
  - deploy

phpunit:
  stage: test
  image: edbizarro/gitlab-ci-pipeline-php:7.4
  before_script:
    - composer install
    - cp .env.example .env
    - php artisan key:generate
  script:
    - ./vendor/bin/phpunit --testdox --verbose --configuration phpunit.xml
  artifacts:
    reports:
      junit: tests/coverage/junit.xml
    paths:
      - tests/coverage/clover.xml
      - tests/coverage/junit.xml
    expire_in: 1 days
  variables:
    GIT_DEPTH: 0
  only:
    - develop
    - master
    - merge_request

To me this looks like a dependency changed it's setup or configuration that the docker image uses, thus changing the environment by accident.

[robertdeboer]

If it helps any, I cleared out our runner docker image cache around 2 weeks ago to get room on the runner and to clear out unused image. So it would of have to pulled the latest image and re-ran the docker scripts after that.

[robertdeboer]

A possible solution would be to add some configs as is done for OpCache

{ \
    echo 'xdebug.coverage_enable=1'; \
   
} > /usr/local/etc/php/conf.d/20-xdebug.ini

[stephane-poirier-umrsu]

I just encountered a similar issue. Tests on Gitlab CI were running fine last week (using XDebug v2.9.8) and started failing today (using Xdebug v3.0.0beta1). Code hasn't changed much. The most likely cause seems to be the XDebug upgrade, or another change in the docker image.

My error message is different, though. I get a Segmentation fault (core dumped) / error code 139.

Here a the relevant logs:

Pulling docker image edbizarro/gitlab-ci-pipeline-php:7.3 ...

$ php -v
PHP 7.3.23 (cli) (built: Oct 13 2020 10:26:06) ( NTS )
[...]
Zend Engine v3.3.23, Copyright (c) 1998-2018 Zend Technologies
    with Zend OPcache v7.3.23, Copyright (c) 1999-2018, by Zend Technologies
    with Xdebug v3.0.0beta1, Copyright (c) 2002-2020, by Derick Rethans

> phpunit -c phpunit.dev.xml --colors=never --stderr --log-junit phpunit-report.xml --coverage-text
PHPUnit 9.3.2 by Sebastian Bergmann and contributors.
Warning:       xdebug.mode=coverage has to be set in php.ini
...............................................................  63 / 125 ( 50%)
....................................................Segmentation fault (core dumped)
Script phpunit -c phpunit.dev.xml --colors=never --stderr --log-junit phpunit-report.xml --coverage-text handling the coverage-ci event returned with error code 139

[chiiya]

Experiencing the same issue (Segmentation fault) in all of our pipelines. Any plans to merge the attempted fix?

Edit: Segmentation fault only occurs for the 7.3 image. 7.4 works, but throws the xdebug.coverage_enable=On has to be set in php.ini Error.

[MatusBoa]

Same for me

Error: xdebug.coverage_enable=On has to be set in php.ini

Using 7.4 version

[bu4ak]

Same issue for 7.4

7.4-alpine works fine

[edbizarro]

I change xdebug back to 2.9.8 until PHP 8 release, i believe that everything should work now

[rocksfrow]

@edbizarro we're seeing segfaults in CI (using 7.3 image) -- I see xdebug 3.0.2 instead of 2.x again.

did you change your mind on keeping xdebug frozen at 2.x until php 8? based on the commit referenced above I'm guessing maybe this was an upstream change? thoughts?

Our latest failing CI:

PHPUnit 8.5.13 by Sebastian Bergmann and contributors.
Runtime:       PHP 7.3.26 with Xdebug 3.0.2

...../bin/bash: line 132:  1150 Segmentation fault 

Our latest passing CI:

PHPUnit 8.5.13 by Sebastian Bergmann and contributors.
Runtime:       PHP 7.3.24 with Xdebug 2.9.8

[rocksfrow]

This works for now:

before_script:
    - sudo pecl uninstall xdebug && sudo pecl install xdebug-2.9.8

[edbizarro]

hi @rocksfrow with the release of PHP 8 I think we can move forward to support only xdebug 3 as the default one

Ref: https://xdebug.org/docs/compat#versions

[chiiya]

That would break all projects running older versions of PHPUnit (including still supported Laravel versions such as 7.x)

[rocksfrow]

I guess I will stick w/ my before_script usage to avoid the seg faults until we can figure out what in the hell incompatible extension is causing these seg faults then. thanks for the feedback.

[evs-xsarus]

Magento 2 also breaks with XDebug as it throws:

Fatal error: Uncaught Error: Call to undefined function xdebug_disable() in /builds/lov/magento2/vendor/magento/magento2-functional-testing-framework/src/Magento/FunctionalTestingFramework/_bootstrap.php on line 78