View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002252 | Xdebug | Code Coverage | public | 2024-03-21 09:10 | 2024-08-30 09:29 |
Reporter | JoshuaBehrens | Assigned To | derick | ||
Priority | normal | Severity | crash | Reproducibility | always |
Status | acknowledged | Resolution | open | ||
OS | Debian | OS Version | buster | ||
Product Version | 3.3.1 | ||||
Target Version | 3.3dev | ||||
Summary | 0002252: Running phpunit in coverage triggers segfault in xdebug_branch_info_mark_reached | ||||
Description | When using php 8.2.17 and xdebug 3.3.1 on phpunit 9 coverage test triggers a segfault | ||||
Steps To Reproduce | $ git clone https://github.com/HEPTACOM/heptaconnect-framework segfault breakpoint should trigger at https://github.com/xdebug/xdebug/blob/5115378c10642280f8f70034afd6401355f6e620/src/coverage/branch_info.c#L383-L387 Most of the time (flaky due to phpunit randomOrder) the method, that is referenced in the stacktrace is Heptacom\HeptaConnect\Dataset\Base\Support\AbstractCollection->getIterator . I was not yet able to reduce the test to a certain test that fails as I did not understand how to get the stacktrace out of it. | ||||
Additional Information | Our CI using the same docker image (heptacom/heptaconnect-pipeline:php81-8.0.0 based on debian:buster-slim) runs always into segfault running the coverage tests. Running locally on MacOS 14 I get into the same issue. When I bisect my way to the broken commit I noticed, that this https://github.com/xdebug/xdebug/commit/7d5e2e91f4b08eb673a20c8f57abfc1507889b27 broke it for php 8.2.17 but after reverting the changes I noticed changes in xdebug_execute_ex where a not operation was missing and has been moved to a wrapper with a comment https://github.com/xdebug/xdebug/blame/5115378c10642280f8f70034afd6401355f6e620/src/base/base.c#L857-L873 and having no not in this wrapper solves it for me. But I do not know why. I have also seen list structs where size and count where not 32 items apart (which seems to be the standard list memory append buffer size) but multiple thousands. So I assume it is just the wrong memory displayed at this struct. The gdb and valgrind is from the pipeline image which has no debug symbols installed so I am not sure how helpful this is. GDB valgrind | ||||
Tags | segfault | ||||
Operating System | MacOS 14, Debian buster | ||||
PHP Version | 8.2.0-8.2.9 | ||||
|
I can reproduce this, with your information. I have also found out a few tests for which this happens:
Running these single ones with GDB:
and
Valgrind are similar, but not the same:
vs |
|
I believe that https://github.com/xdebug/xdebug/commit/91bfb654b0a6cfed63d327728db8ec2f3f82c97a is the faulty commit |
Date Modified | Username | Field | Change |
---|---|---|---|
2024-03-21 09:10 | JoshuaBehrens | New Issue | |
2024-03-21 09:10 | JoshuaBehrens | Tag Attached: segfault | |
2024-03-21 13:56 | derick | Assigned To | => derick |
2024-03-21 13:56 | derick | Status | new => acknowledged |
2024-03-21 13:56 | derick | Note Added: 0006864 | |
2024-03-28 16:57 | derick | Relationship added | has duplicate 0002254 |
2024-03-28 16:59 | derick | Relationship added | has duplicate 0002236 |
2024-03-28 17:00 | derick | Relationship added | has duplicate 0002241 |
2024-07-18 13:27 | derick | Target Version | => 3.3dev |
2024-08-30 09:23 | qkdreyer | Note Added: 0007047 |