View Issue Details

IDProjectCategoryView StatusLast Update
0002318XdebugStep Debuggingpublic2025-02-18 11:51
Reportersavemetenminutes Assigned Toderick  
PrioritynormalSeveritymajorReproducibilityalways
Status assignedResolutionopen 
Product Version3.4.1 
Summary0002318: Another segfault report
Description

This issue has been reported multiple times.
https://bugs.xdebug.org/view.php?id=2225
https://bugs.xdebug.org/view.php?id=2271
https://github.com/oerdnj/deb.sury.org/issues/2059
https://github.com/ddev/ddev/issues/5633

I'm not sure how to label the reproducibility of the issue as in certain scenarios the issue is reproducible without failure, but with other scripts/breakpoints/run to cursor actions it never manifests. I've labeled it as always reproducible, as with my current test case and steps I'm undergoing it will crash and produce exactly the same step debug log every time. I'd say that the frequency of occurrence on my environment is around 40%-50% of all step debug sessions I go though during my daily routine. I haven't been able to reproduce it using simple "1 file" or "20-30 lines of code" scripts, so I'm afraid that I cannot fulfil one of the requirements of bug reporting as described in the Xdebug documentation. I went through the generated step debug log generated by xdebug.log=/tmp/xdebug.log, but I don't think that it contains the culprit of the issue.

Otherwise the issue is pretty straightforward to explain. Using PhpStorm, after stopping at a cursor position using "Force run to cursor" or at a breakpoint, using "Force run to cursor" again will result in the debug session and script to terminate. I can confirm that this issue started manifesting after PHP version 8(.1?). As I've pointed out in a comment on the first referenced issue above:

Quote:
I also just found out that the problem occurs also when running a script through a web server's fcgi proxy to PHP-FPM, although instead of the "Segmentation fault" I get the following errors in the web server error logs along with a 503 Service Unavailable response.

Nginx:

2024/01/05 12:41:58 [error] 47#47: *10 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 223.223.0.1, server: $host, request: "GET /some-resource/1?XDEBUG_SESSION=asd HTTP/1.1", upstream: "fastcgi://223.223.0.37:9090", host: "127.0.0.1:19492"
Apache:

[Fri Jan 05 12:38:48.373555 2024] [proxy_fcgi:error] [pid 34:tid 140142342183736] [client 223.223.0.1:52312] AH01067: Failed to read FastCGI header
[Fri Jan 05 12:38:48.373602 2024] [proxy_fcgi:error] [pid 34:tid 140142342183736] (104)Connection reset by peer: [client 223.223.0.1:52312] AH01075: Error dispatching request to :18492

Steps To Reproduce

PHP 8.1
Xdebug 3.2.1-3.4.1
PhpStorm
Only under certain scripts/execution stacks/breakpoints
Stop at a breakpoint/cursor position
Force run to cursor or resume the step debug session normally

Additional Information

Somewhere I came across a suggestion to enable "develop" in the xdebug.mode setting (to enable the built-in stack overflow prevention? IIRC). This caused my debug session to hang forever. It also has the unwanted effect of modifying the var_dump functions and the exceptions stringification becomes HTML based if I remember correctly.

Tagscrash, segfault
Operating System
PHP Version8.1.30-8.1.39

Activities

savemetenminutes

2025-02-12 10:42

reporter   ~0007173

I cannot find an edit button to fix my quote in the description. I'm also having trouble uploading/attaching files.

xdebug.log (328,171 bytes)

derick

2025-02-12 14:30

administrator   ~0007174

I haven't been able to reproduce it using simple "1 file" or "20-30 lines of code" scripts, so I'm afraid that I cannot fulfil one of the requirements of bug reporting as described in the Xdebug documentation.

Then how can I? If I can't reproduce it, I can not fix it.

savemetenminutes

2025-02-13 11:56

reporter   ~0007175

Then how can I? If I can't reproduce it, I can not fix it.

I would think that there would be comprehensive enough logs and diagnostic tools to be able to catch such sort of bugs similar to how an APM works in a regular PHP project. On our production environments we do not require customers to provide us with screenshots and browser request/response dumps. We monitor the Elastic logs and catch the exceptions before they are reported and we can obtain the request data and stack traces of where the code errors out. I'm actually kind of surprised that the mindset is to put away such a prevalent issue, which has been lingering and reported a multitude of times not only on this issue tracker and label it as unreproducible.

That aside, I can reproduce it at will. And I'm willing to install whatever tracer/debug tool you might have on your end and contribute actively towards diagnosing and providing whatever you need as info or even provide live feed on the subject or multple screen recodings if that will help.

Issue History

Date Modified Username Field Change
2025-02-12 10:36 savemetenminutes New Issue
2025-02-12 10:36 savemetenminutes Tag Attached: crash
2025-02-12 10:36 savemetenminutes Tag Attached: segfault
2025-02-12 10:42 savemetenminutes Note Added: 0007173
2025-02-12 10:42 savemetenminutes File Added: xdebug.log
2025-02-12 14:30 derick Assigned To => derick
2025-02-12 14:30 derick Status new => feedback
2025-02-12 14:30 derick Note Added: 0007174
2025-02-13 11:56 savemetenminutes Note Added: 0007175
2025-02-13 11:56 savemetenminutes Status feedback => assigned
2025-02-18 11:51 derick View Status private => public