View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002198XdebugStep Debuggingpublic2023-08-28 16:352023-09-19 15:48
Reportercllamas Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status newResolutionopen 
PlatformDocker LinuxOSDebinOS Version6.4.12-arch1-1
Product Version3.2.2 
Summary0002198: Slowness due to report errors ignored by error_reporting
Description

Hello,

I am working on migrating an old codebase that partly worked on PHP 5.6 to PHP 8.2. You can imagine how many errors and warnings this application gives, so the strategy I am following is focusing on solving errors and then continue with all the warnings and notices to reduce it to the minimum. This strategy is working, but I am facing a problem that when debugging and a debugger is connected the requests are being processed very slowly compared without a debugger connected. Frpm 0.1s to 6-8s per request.

I have inspected the logs with log level 7 (I have tried log level 10, but generates gigabyte size log file) and I see more than 10000 lines of messages of warning, deprecated and notice sent to the debugger client. The error_reporting configuration I have setup is this:

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE & ~E_WARNING

This way I hide warning, notice and deprecated messages, but it seems Xdebug is ignoring it internally and reporting it to the debugger client, which makes it very slow due to the high number of warnings and notices of the codebase. I also have xdebug.start_with_request=yes, which makes it slower to debug, because all requests are being processed by Xdebug.

I attach a log with redacted information.

Thank you and sorry to bother you if this is how the debugger works.

Additional Information

Configuration:

xdebug.mode=develop,debug
xdebug.client_host=host.docker.internal
xdebug.start_with_request=yes

xdebug.log = /data/xdebug.log
xdebug.log_level = 7

TagsNo tags attached.
Attached Files
xdebug.log (394,315 bytes)
Operating SystemDocker Debian Linux
PHP Version8.2.0-8.2.9

Activities

derick

2023-09-14 16:43

administrator   ~0006650

Hi,

For the notifications, this is something that IDEs need to opt into. In your log, there is:

feature_set -i 5 -n notify_ok -v 1

Which does exactly that. I've had a quick stroll through the rest of your log, and I understand exactly why this is causing a slow-down. There are indeed more than a 1000 in just that single file.

Unlike some other features, it doesn't seem PhpStorm (nor VS Code) lets you configure this.

So, I see a few options to address this, in no particular order

  1. Lobby for IDEs (PhpStorm and VS Code) to make this a feature flag. That would however also mean that resolving breakpoints will no longer work (As they use notifications too).
  2. Change Xdebug to respect the error_reporting setting, which is IMO a BC break as Xdebug is meant to show all debug information.
  3. Change Xdebug to use the xdebug.force_error_reportingsetting (https://xdebug.org/docs/all_settings#force_error_reporting). This makes things a little nuanced, as it is usually used for forcing to enable warnings, and not turn them off.
  4. Set a maximum number of warning/error notifications sends per request (say 50 max) — although that won't totally solve the problem, it should mitigate that.

I don't really know which one is best. I lean towards 3.

Furthermore, I would suggest to make sure you only enable the breakpoints that you need for this project, as there is overhead for each of them as they need to be checked after each statement. You don't have to remove them, but just disable them.

cllamas

2023-09-19 15:48

reporter   ~0006659

Hello,

I have tried option 3 with this value, but it still takes the same time:

xdebug.force_error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT & ~E_NOTICE & ~E_WARNING

About option 1, if it will stop breakpoint resolve I don't think it would be analyzed, but I will try to contact Jetbrains which is the IDE we use.
For option 2, I can study contributing it, but if you think this is gonna break the specification, it doesn't make sense to do it.

And option 4 I haven't found which option is to use it.

For the breakpoint, yes you are sure. Every often I clean them when there are a lot. I have cleared them and got the same result. I also tested it on VS Code before posting the issue with a clean installation of it to discard any phpstorm configuration and got the same results.

Thank you.

Issue History

Date Modified Username Field Change
2023-08-28 16:35 cllamas New Issue
2023-08-28 16:35 cllamas File Added: xdebug.log
2023-09-14 16:43 derick Severity minor => feature
2023-09-14 16:43 derick Note Added: 0006650
2023-09-19 15:48 cllamas Note Added: 0006659