Nearly identical problem on my system when using Apache 2.4.58 + php 8.3 + xdebug 3.3.0_8.3 does freeze my Apache process. In my case, the CPU usage does not go up, it just freezes.

Running Apache 2.4.58 + php 8.2 + xdebug 3.3.0_8.2 works without any problems.

Are there any logs I can provide to help diagnose this problem?

I'm having the same issue with php hanging when running Wampserver 3.3.3 with Apache 2.4.58 + php 8.3 + php_xdebug-3.3.0-8.3-vs16-x86_64.dll while php_xdebug-3.3.0-8.2-vs16-x86_64.dll is working fine on php 8.2

Setting xdebug.mode=off fixes the handing issue.

Happy to provide any relevant logs.

I have released Xdebug 3.3.1, in which I believe these issues are fixed. Could you all please try that version?

Unfortunately Xdebug 3.3.1 didn’t fix the issue for me when using xdebug.mode = develop,debug I also checked the following modes individually and get the same issue

xdebug.mode = develop
xdebug.mode = debug
xdebug.mode = trace

When browsing the site normally everything seems fine however when running Playwright tests once specific set of pages handled by one php file consistently triggers the hanging behaviour normally on page 5 of the tested pages. It seems the speed the pages are accessed is a factor.

I will investigate further and try and put together a php file that triggers the issue that I can share.

If there are any xdebug configurations I can use to log what’s going on please let me know.

Installed xdebug 3.3.1 and can also confirm the hanging behaviour is still present

Apache 2.4.58
PHP 8.3.0
xDebug 3.3.1 (also previously tried the full 3.3.0 non-alpha version)

Ok, I’ve attached the smallest amount of code that causes the page to hang normally on the second refresh, if you don’t see the issue try refreshing with chrome dev tools open (F12) with the “Disable cache” setting ticked on the “Network tab”

The issues goes away if I comment out error_reporting(0); or disable to RewriteRule in the .htaccess file or there is only one image on the page.

Let me know if you are not able to reproduce the issue I’m seeing with the attached code, and I can send php.ini and httpd.conf in case there is some that is different from your test environment.

See this video of the page loading normally with error_reporting(0); commented out and then hanging once error_reporting(0); is uncommented.

https://www.dropbox.com/scl/fi/fzhythftrv04jybawdztj/xdebug_hang.mp4?rlkey=h6twyjhhyaf6h4tweyfndutdt&dl=0

The video link I post was modified by the form, to view it you will need to replace & with & at the end of the url

I'll have a look after the break.

I can confirm this issue.
Even with version 3.3.1

Can any of you report this on Linux?

I checked my test case in a docker container (based on debian 12) with the following config and there was no issues so I’m assuming the issue is specific to PHP on windows.

========= Dockerfile_custom start =========

FROM php:8.3-apache

# Install system dependencies
RUN apt-get update && apt-get install -y \
    git \
    libzip-dev \
    zip \
    && docker-php-ext-install zip

# Enable Apache mod_rewrite
RUN a2enmod rewrite

# Install Xdebug
RUN pecl install xdebug \
    && docker-php-ext-enable xdebug

EXPOSE 80

========= Dockerfile_custom end =========

========= docker-compose.yml start =========

version: '3.8'

services:
  web:
    build:
        context: .
        dockerfile: Dockerfile_custom
    ports:
        - "80:80"
    volumes:
        - C:\docker_www:/var/www/html
        - ./config/xdebug.ini:/usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
    stdin_open: true
    tty: true
    restart: "no"

========= docker-compose.yml end =========

========= xdebug.ini start =========

zend_extension=xdebug
xdebug.remote_enable=1
xdebug.remote_autostart=1
xdebug.mode = debug,develop

========= xdebug.ini end =========

xdebug_info(); was used to confirm xdebug was active and the version was 3.3.1

I can also not reproduce it on macOS.

test.php:

<?
    error_reporting(0);

    sleep(1);

    echo "SUCCESS\n";
?>

call in terminal:

for i in {1..100}; do curl "http://host/test.php" &; done

I doubt this would reproduce on the CLI with concurrent requests, there is something that happens in a threaded environment I suspect. This is probably also why your Apache/Linux run didn't work. By default it still uses mpm_prefork, and not mpm_worker, I believe.

FWIW, I have no Windows to test this on.

I checked and the docker container I used above and it uses mpm_prefork with mod_php (Server API: Apache 2.0 Handler)

I did some further testing on windows and the following code only hangs when using mod_php (Server API: Apache 2.0 Handler) but works fine when using mod_fcgid (Server API: CGI/FastCGI)

error_reporting(0);
sleep(1);
echo "SUCCESS";

Something not mentioned before:
The issue doesn't happen if the error reporting level is set with the ini_set function.
ini_set('error_reporting', 0);
(Doesn't matter what the value of the second argument is.)

same thing here with FrankenPHP (Caddy)

i can report this happening also on Slackware current.

Description

The following code:

<?php error_reporting(-1); ?>

Seems to randomly hang when called from the line BasicErrorHandler.php:23 of Symfony. I'm running it on a Apache web server. When checking the server status, the process linked to the request is hanged in "W" status (sending response) and the browser received no byte from the server.

I run pstack on the process that is handling the request, obtaining the following trace: https://pastebin.com/iNxBiEtn.

The part that seems interesting is:

* 9  Thread 0x7fac137fe6c0 (LWP 18791) "httpd" 0x00007fac25f08700 in tsrm_get_ls_cache () from /usr/lib64/httpd/modules/libphp.so
#0  0x00007fac25f08700 in tsrm_get_ls_cache () from /usr/lib64/httpd/modules/libphp.so
#1  0x00007fac26b31e3d in zif_xdebug_error_reporting () from /usr/lib64/php/extensions/xdebug.so
#2  0x00007fac25d523ca in ?? () from /usr/lib64/httpd/modules/libphp.so
#3  0x00007fac25d52cc4 in ?? () from /usr/lib64/httpd/modules/libphp.so
#4  0x00007fac25d52303 in ?? () from /usr/lib64/httpd/modules/libphp.so
#5  0x00007fac25d52cc4 in ?? () from /usr/lib64/httpd/modules/libphp.so
#6  0x00007fac25d52303 in ?? () from /usr/lib64/httpd/modules/libphp.so
#7  0x00007fac25d52cc4 in ?? () from /usr/lib64/httpd/modules/libphp.so
#8  0x00007fac25d52303 in ?? () from /usr/lib64/httpd/modules/libphp.so
#9  0x00007fac25d52cc4 in ?? () from /usr/lib64/httpd/modules/libphp.so
#10 0x00007fac25d52303 in ?? () from /usr/lib64/httpd/modules/libphp.so
#11 0x00007fac25d52cc4 in ?? () from /usr/lib64/httpd/modules/libphp.so
#12 0x00007fac25fb77ce in ?? () from /usr/lib64/httpd/modules/libphp.so
#13 0x00007fac25fdf8f1 in execute_ex () from /usr/lib64/httpd/modules/libphp.so
#14 0x00007fac25fe9439 in zend_execute () from /usr/lib64/httpd/modules/libphp.so
#15 0x00007fac25f77196 in zend_execute_scripts () from /usr/lib64/httpd/modules/libphp.so
#16 0x00007fac25f0ba95 in php_execute_script () from /usr/lib64/httpd/modules/libphp.so
#17 0x00007fac2605e268 in ?? () from /usr/lib64/httpd/modules/libphp.so
#18 0x000055782b451bf0 in ap_run_handler ()
#19 0x000055782b4521d6 in ap_invoke_handler ()
#20 0x000055782b4674be in ap_internal_redirect ()
#21 0x00007fac29710134 in ?? () from /usr/lib64/httpd/modules/mod_rewrite.so
#22 0x000055782b451bf0 in ap_run_handler ()
#23 0x000055782b4521d6 in ap_invoke_handler ()
#24 0x000055782b4674be in ap_internal_redirect ()
#25 0x00007fac29710134 in ?? () from /usr/lib64/httpd/modules/mod_rewrite.so
#26 0x000055782b451bf0 in ap_run_handler ()
#27 0x000055782b4521d6 in ap_invoke_handler ()
#28 0x000055782b468057 in ap_process_async_request ()
#29 0x000055782b46454c in ?? ()
#30 0x000055782b45b1f0 in ap_run_process_connection ()
#31 0x00007fac2a1a9776 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#32 0x00007fac2a1aa172 in ?? () from /usr/lib64/httpd/modules/mod_mpm_event.so
#33 0x00007fac29e94d57 in start_thread () from /lib64/libc.so.6
#34 0x00007fac29f196a8 in clone3 () from /lib64/libc.so.6

The hang happens not for all the call to the same file, but always at the same line. With XDebug disabled it seems to not happen

I'll monitor this thread if you need any more informations

PHP Version

8.3.3

Operating System

Slackware-current

Adding to the one before: downgrading to 8.2.13 without changing any configuration or downgrading Xdebug, makes the problem not happen

For the record, I created a minimal reproducer that isn't using Docker: https://github.com/dunglas/frankenphp/issues/563#issuecomment-2009244388
This is likely the same bug.

https://github.com/xdebug/xdebug/pull/958

Is there a compiled windows version of the dll for PHP 8.3 VS16 TS (64 bit) with the patch to check if the crash has been fixed on windows.

Just to report back, I compiled the 3.3.2-dev release from dunglas:fix/overloaded_functions_zts and the issues I reported in this thread seem to be fixed now.

You can use the artefacts from https://github.com/xdebug/xdebug/actions/runs/8470808863#artifacts

I'll remove your attached dlls, as I can't verify where they came from.

Just downloaded php_xdebug-3.3.2-dev-8.2-vs16-x86_64.dll and noticed that phpinfo displays "with Xdebug v3.3.2-dev, Copyright (c) 2002-2023, by Derick Rethans".
Shouldn't it be "2024" ?

No worries Vincent, I'll update that when I make a release.