View Issue Details

IDProjectCategoryView StatusLast Update
0001586XdebugUsage problems (Wrong Results)public2019-11-12 13:56
ReporterLanaZemAssigned Toderick 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version2.6.0 
Target VersionFixed in Version2.7.2 
Summary0001586: error_reporting()'s return value is incorrect during debugger's 'eval' command
DescriptionXdebug sends error notification even if they are disabled in php.ini
Steps To Reproduce1) Set error_reporting to `E_ALL & ~E_NOTICE`
2) Create a php script:
<?php

echo $undefined;

3) Make sure that regular execution doesn't generate PHP Notification
4) Start Xdebug debug session
5) Enable notify feature
<- feature_set -i 5 -n notify_ok -v 1
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="feature_set" transaction_id="5" feature="notify_ok" success="1"></response>

6) Finish debug session
7) Note that there's a notification in xdebug log:
-> <notify xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" name="error"><xdebug:message filename="file:///path/to/project/withNotice.php" lineno="6" type="Notice"><![CDATA[Undefined variable: x]]></xdebug:message></notify>
Additional InformationPhpStorm issue: https://youtrack.jetbrains.com/issue/WI-43921
TagsNo tags attached.
Operating System
PHP Version7.1.0-7.1.4

Activities

LanaZem

2018-11-12 12:18

reporter  

xdebug_with_notify.log (13,202 bytes)

derick

2018-12-01 11:28

administrator   ~0004733

I saw the issue when you submitted it, but so far I had neglected to reply as I am unsure whether Xdebug is doing anything *wrong* here. I'm going to argue that it doesn't.

As Xdebug is a *debugging* tool, it should provide as much information as it can. When an IDE sets the ``-n notify_ok -v 1`` it indicates that the debug engine may send the IDE notifications. These notifications are not necessarily restricted to ``error`` notifications (https://xdebug.org/docs-dbgp.php#error-notification), but can in the future also include ``breakpoint_resolved`` notifications (these are currently unimplemented in Xdebug today, but part of a future feature, as requested by the PhpStorm team).

The DBGp specification says:

> When a language engine creates a debugging notification, the debugger engine MAY convert this to a DBGp notification.

The language engine (PHP) creates a debugging notice (including formatting, stack traces, etc) regardless of whether PHP outputs it to the screen. The decision to show debugging information is taken much later. This means that leaving many notices unfixed in your PHP script actually creates quite a slow down to begin with (even if Xdebug is not involved at all).

As a debugging notice is created, Xdebug decides to send it over the DBGp connection to the IDE, to point out that there is a mistake in the script. I would say that it should continue to do so.

LanaZem

2018-12-03 10:30

reporter   ~0004742

Thank you for the answer!
Ok, it make sense.

We'll think how it should be fixed on PhpStorm side. Probably we should show error according to error level but notify user if there are too much hidden notifications and warnings.

derick

2019-01-22 22:30

administrator   ~0004836

Thanks Svetlana. I'll close the issue for now. If we can come up with a better solution in the future, then we can create a new issue for it.

cheers,
Derick

LanaZem

2019-05-02 14:38

reporter   ~0005011

Last edited: 2019-05-06 06:01

View 2 revisions

My colleague is currently looking how can we fix this issue on IDE side and we can't find a good way to find error reporting level for a current debug process.
If we try to evaluate "error_reporting()" on IDE side, we always get 0.

Is there more appropriate way to get the error_reporting level during debugging ?

To reproduce:
1) Create a PHP script
<?php

function sum($a, $b) {
    return $a + $b;
}

echo error_reporting() . PHP_EOL;
error_reporting(E_ALL);
echo error_reporting() . PHP_EOL;

$a = 1 + 179;
echo $a . PHP_EOL;


2) Place a breakpoint on lines 7 and 12. In both cases, evaluating 'error_reporting()' will return 0.

xdebug.log:
...
[25705] <- eval -i 34 -- JEdMT0JBTFNbJ0lERV9FVkFMX0NBQ0hFJ11bJzkwZmI4NjBkLTgwOGUtNDRmOC1hMzk2LTM0N2RiZDkwNjU3OCddPWVycm9yX3JlcG9ydGluZygpOw==
[25705] -> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug" command="eval" transaction_id="34"><property type="int"><![CDATA[0]]></property></response>
…


derick

2019-05-02 15:05

administrator   ~0005012

I'll have a look again.

derick

2019-05-06 06:01

administrator   ~0005017

I've found out why your eval statement returns `0`: https://github.com/derickr/xdebug/blob/master/xdebug_handler_dbgp.c#L935 — Xdebug sets the error_reporting internally to `0` in case the `eval` command is used. I believe that's because I didn't/couldn't rely on eval always being used on correct PHP code, as it is user input (i.e., people can put random stuff in PhpStorm's watches, and I didn't want that then to show errors in their HTML output). Now the question is how to fix this.

derick

2019-05-06 09:37

administrator   ~0005018

This is now fixed in the xdebug_2_7 and master branches.

cljk

2019-11-12 13:21

reporter   ~0005178

Is it possible that this bug is still unfixed in 2.8?

I´m debugging with IntelliJ Ultimate 2019.2 and Xdebug 2.8.0 on Windows PHP 7.3 x64 (VC15).
The problem I´m facing is described here:
https://youtrack.jetbrains.com/issue/WI-43921

IntelliJ outputs a lot of garbace (NOTICEs) when in debugging mode - despite it should not...

derick

2019-11-12 13:56

administrator   ~0005179

@cljk Your comment is unrelated to this report. This report is about error_reporting() returning the wrong value.

The youtrack issue that you linked to explains why these extra notices are not a bug in Xdebug.

Issue History

Date Modified Username Field Change
2018-11-12 12:18 LanaZem New Issue
2018-11-12 12:18 LanaZem File Added: xdebug_with_notify.log
2018-12-01 11:28 derick Note Added: 0004733
2018-12-02 18:45 derick Assigned To => derick
2018-12-02 18:45 derick Status new => feedback
2018-12-03 10:30 LanaZem Note Added: 0004742
2018-12-03 10:30 LanaZem Status feedback => assigned
2019-01-22 22:30 derick Note Added: 0004836
2019-01-22 22:30 derick Status assigned => resolved
2019-01-22 22:30 derick Resolution open => no change required
2019-05-02 14:38 LanaZem Note Added: 0005011
2019-05-02 15:05 derick Status resolved => acknowledged
2019-05-02 15:05 derick Note Added: 0005012
2019-05-06 06:01 derick Note Added: 0005017
2019-05-06 06:01 derick Note Edited: 0005011 View Revisions
2019-05-06 09:28 derick Summary Error notifier doesn't respect error_reporting level => error_reporting()'s return value is incorrect during debugger's 'eval' command
2019-05-06 09:28 derick Steps to Reproduce Updated View Revisions
2019-05-06 09:37 derick Status acknowledged => closed
2019-05-06 09:37 derick Fixed in Version => 2.7.0dev
2019-05-06 09:37 derick Note Added: 0005018
2019-05-06 09:38 derick Resolution no change required => fixed
2019-05-06 15:46 derick Fixed in Version 2.7.0dev => 2.7.2
2019-11-12 13:21 cljk Note Added: 0005178
2019-11-12 13:56 derick Note Added: 0005179