Hi,

I can't seem to reproduce this with Linux and PHP's built-in web server.

What is your set up? Do you use Apache, or IIS, or something else? Could you try with PHP's built-in web server?

I ran my test as follows, on a command prompt:

php -n -d xdebug.mode=debug -d zend_extension=xdebug -S localhost:9242

You might have to change paths. The -n disables all ini settings

And then opened http://localhost:9242/info.php in my browser, which contained only a call to xdebug_info().

I will have a look later on Windows, but it would help me if you let me know more about your setup.

cheers,
Derick

Okay, so I can confirm that it's working just fine with the PHP integrated webserver (like it should).

The error occurred on a standard XAMPP installation (that I was using as a quick development server).

These are the minimal steps to reproduce it:

• Download the current (8.1.12) version at https://www.apachefriends.org/de/index.html

• Install it to the default directory C:\xampp and uncheck every feature you can (we just need Apache and PHP; you can't uncheck them)

• Copy php_xdebug-3.1.6-8.1-vs16-x86_64.dll and php_xdebug-3.2.0-8.1-vs16-x86_64.dll to C:\xampp\php\ext

• Edit C:\xampp\php\php.ini and add:
  [XDebug]
  zend_extension = C:\xampp\php\ext\php_xdebug-3.2.0-8.1-vs16-x86_64.dll
  xdebug.mode = debug

• Remove everything in C:\xampp\php\htdocs and add a xdebug.php containing:
  <?php
  xdebug_info();

• Run Apache from the Control Panel or by executing C:\xampp\apache_start.bat

• Open http://localhost/xdebug.php

• All Xdebug features are enabled (but they shouldn't)

• Optional: Stop Apache, change the xdebug extension to 3.1.6 in php.ini - the Xdebug feature list will only show the Step Debugger now

So maybe I should report this to the Apache foundation then?

But I wonder why this error didn't occur before. I was able to use Xdebug with a standard XAMPP installation for years just fine.

Apache Friends, not Apache foundation.

(Sorry, I can't seem to edit my comments here).

Hi,

I have tried this now, and I can indeed reproduce this. I think I also have a vague idea where and why this happens. The problem is is that I don't know how to debug this properly on Windows, so I am going to have to see if I can reproduce this on Linux. But now I know what the issue could be, that is easier.

You don't need to report this to the Apache Friends people.

cheers,
Derick

I've stumbled upon it on CentOS 7.9.2009 with latest PHP and XDebug from remi-php80.
Comparing my older VM with a newly deployed one,

[code]
-<tr><td class="e">Development Helpers</td><td class="v">[x] disabled</td><td class="d"><a href="https://xdebug.org/docs/develop"></a></td></tr>
+<tr><td class="e">Development Helpers</td><td class="v">[v] enabled</td><td class="d"><a href="https://xdebug.org/docs/develop"></a></td></tr>
-<tr><td class="e">Step Debugger</td><td class="v">[v] enabled</td><td class="d"><a href="https://xdebug.org/docs/remote"></a></td></tr>
+<tr><td class="e">Step Debugger</td><td class="v">[x] disabled</td><td class="d"><a href="https://xdebug.org/docs/remote"></a></td></tr>
+<tr><td class="e">'xdebug://gateway' pseudo-host support </td><td class="v">yes </td></tr>
+<tr><td class="e">'xdebug://nameserver' pseudo-host support </td><td class="v">yes </td></tr>
-<tr><td class="e">xdebug.client_discovery_header</td><td class="v">no value</td><td class="v">no value</td></tr>
+<tr><td class="e">xdebug.client_discovery_header</td><td class="v">HTTP_X_FORWARDED_FOR,REMOTE_ADDR</td><td class="v">HTTP_X_FORWARDED_FOR,REMOTE_ADDR</td></tr>
[/code]

P.S.
Please fix collation on database tables.
Database query failed. Error received from database was 0001366: Incorrect string value: '\xE2\x9C\x98 di...' for column bugs.mantis_bugnote_text_table.note at row 1 for the query: INSERT INTO mantis_bugnote_text_table ( note ) VALUES ( ? ).

@AnrDaemon — I'd love to fix the collation, but the last time I tried I ended up messing everything up. Don't really want to do that again.

In any case, what is the web server setup that you use? Apache? Which MPM? Something else?

nginx, php-fpm, socket.
Trivial by-the-books setup with

        location ~ ^/.+\.php$ {
                include fastcgi.conf;
                fastcgi_index index.php;
                fastcgi_pass unix:/var/run/xxx.sock;
                fastcgi_read_timeout 180s;
        }

Any update on the issue? Sorry to bother, but manually installing 3.1 from PECL is very inconvenient on package managed systems.

No update, I can't reproduce this.

Whatever is it, is isn't related to php-fpm because it also happens with mod_php.

Derick, what kind of reproduction setup you would accept to evaluate this issue? Docker, LXD, ovirt?

Docker would be fine, preferably with the container having debug builds of PHP and Xdebug and with gdb and valgrind installed.

If you have a readily available Dockerfile with these tools, it would help greatly.

Sorry, I don't have a Dockerfile with these tools yet — but it's usually not hard to add them (apt-get install valgrind gdb strace) so no sweat if your repo case wouldn't have them.

@AnrDaemon I just tried to reproduce this again with PHP 8.2.5 and both ZTS and NTS versions of PHP-FPM with Xdebug 3.2.0, and I see no problems. If you have any sort of Docker environment that can reproduce this, that would be most welcome!

I have just made a PR to fix this bug, which as far as I can tell only occurred in threaded environments:

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

If you're on Linux and can compile Xdebug yourself to test, please use this branch: https://github.com/derickr/xdebug/tree/issue2144-mode-in-threaded-environment

If you're on Windows, please use one of the new DLLs (called Artifacts) https://github.com/xdebug/xdebug/actions/runs/4471304815?pr=881#artifacts — You'll likely need the ones that don't have "nts" in their filename.

It is OK now with 3.2.1 dev TS on PHP 8.2.4 - Thanks

xdebug_mode_develop3.2.1.png (113,609 bytes)   

xdebug_mode_develop3.2.1.png (113,609 bytes)   

https://github.com/xdebug/xdebug/pull/875 — which is now merged, and 3.2.1 will be released soon.

Turned out, in my case it was more a reading documentation issue.
In modern xdebug, mode can not be set in FPM configuration.
Which is bad. I do not want to have, say, profiler enabled for all sites.
Nor do I want to have a zillion of different FPM daemons running with the same PHP version, even though it is somewhat trivial with modern systemd.

@AnrDaemon — I know it is annoying. Unfortunately it isn't something I can relax right now, due to the way how PHP-FPM initialises PHP and its extensions. Xdebug (and likely other extensions) rely on the hooks being set-up right, and once, depending on an authoritative value of options (xdebug.mode in our case). PHP-FPM allows ini settings to be overridden after extensions have been initialised (it starts PHP once, and the forks for each worker, which then can have different values), which is a no-no for Xdebug.