View Issue Details

IDProjectCategoryView StatusLast Update
0001374XdebugStep Debuggingpublic2023-10-28 17:24
ReporterRadek Suski Assigned Toderick  
Status resolvedResolutionunable to reproduce 
PlatformRaspberry PI OSraspbianOS Version4.4
Product Version2.4.0 
Summary0001374: XDebug seems to be overwriting thee FILE and DIR constants

as in the summary.

Steps To Reproduce

Well, this is a bit strange because I know it worked before but suddenly when I am trying to debug within Joomla! my own library those constants containing values as follow:

__FILE__ =  xdebug://debug-eval
__DIR__  = xdebug:   


TagsNo tags attached.
Operating SystemmacOS 10.12.1 (16B2555)
PHP Version7.0.10-7.0.14


Radek Suski

2016-12-03 11:39

reporter   ~0003874

BTW: I am apparently not the only one:

Additionally because every time I wrote it people assuming I am using "eval", so just to clarify I don't
For debugging I am using phpStorm 2016.2.2


2016-12-03 12:46

administrator   ~0003875


thanks for the report. In order to find and fix the bug, I really do need a reproducible case. As this seems to be a remote debugging issues, please refer to as to what I would require.


Radek Suski

2016-12-03 13:21

reporter   ~0003882

Last edited: 2023-09-03 13:47

Sure thing, here is the script:
Here is the log file:

What really weird, I just realised, that debugging this script gives following results:

__FILE__ = "xdebug://debug-eval"
__DIR__ = "xdebug:"
$file = "/www/Neo/libraries/Sobi/index.php"
$dir = "/www/Neo/libraries/Sobi"
$dirname = "/www/Neo/libraries/Sobi"

Which means that if I assign those constants to variables, those variables are having correct values.



2016-12-04 17:33

administrator   ~0003924


I see what happens now. You have these in the "Watches" field. PhpStorm handles watches by running the DBGp "eval" command. In the log, that looks like:

<- eval -i 62 -- JEdMT0JBTFNbJ0lERV9FVkFMX0NBQ0hFJ11bJzlmNmZiNjcxLWU0ZWItNDIyNy04Mzc2LTNhNjNkZDNiMmNmMCddPV9fRElSX18=

As the eval command really just calls PHP's eval, you get the same result:

$ php -r "echo eval('echo FILE;');"
Command line code(1) : eval()'d code

Xdebug does replace the "Command line code(1) : eval()'d code" with "xdebug://debug-eval" though.

This is something I can not change.

Radek Suski

2016-12-04 17:39

reporter   ~0003925

@derick Thank for your answer. Yet I am not sure if you are entirely correct. Yes, I have it in watches. But even if, the logical execution is failing. I am asking:

if(file_exists( DIR.'/file.php'))

and it returns "false". It can't be just because I have it in my "watches" because at the first time I was debugging my case, it wasn't


2016-12-04 17:54

administrator   ~0003927

No, it can't be because it's in watches. But that "file_exists" would only file for real reasons. If you can reproduce this, I would use "strace -o /tmp/strace.log php script.php" and see for which file it is doing a "stat".

Radek Suski

2016-12-04 18:50

reporter   ~0003928

I know for sure that this file exists. That's how I figured out this issue


2016-12-04 19:09

administrator   ~0003929

Okay - I would definitely use the strace then. There must be something why PHP thinks it's not there, and strace is your only hope I think.

Radek Suski

2016-12-04 19:11

reporter   ~0003930

no problem. I will try to deliver it soon. Thank you very much


2016-12-05 14:19

administrator   ~0003943

(Changing it to feedback until you do).


2017-01-03 18:49

administrator   ~0004128



2017-02-07 17:08

administrator   ~0004200

I am closing this, as I can't reproduce this, and the requested feedback has not been given. Please feel free to reopen this if you can provide more information as requested.


2017-12-20 16:43

reporter   ~0004523

This error is repeated for me! How can I fix it? xdebug 2.5.5-1


2023-09-02 06:31

reporter   ~0006644

Xdebug 3.2.1, the problem persists (as far as I understand, in all other versions too). To reproduce it, it is enough (when working in phpstorm) during a debugging session to open the Evaluate Expression window (alt + F8) and enter one of these constants there. You can just use the debug console, you can use the clock, the behavior is the same everywhere.


2023-09-03 13:59

administrator   ~0006645

@anton.m4354: I would still expect what you show. When PhpStorm evaluates __DIR__ or __FILE__, it uses eval under the hood. This evaluates the string, exactly what this would do:

echo eval(__DIR__);

Which on the PHP CMD also produces a similar result:

php -r &quot;echo eval('return __FILE__;');&quot;


Command line code(1) : eval()'d code

Xdebug does wrap that in its own file name though, which is xdebug://debug-eval. There is nothing I can change here, and I am not sure whether PhpStorm can, but you can always ask them at


2023-09-03 19:14

reporter   ~0006646

@derick that is, if Phpstorm would directly echo __FILE__;, then the result would be correct?


2023-10-18 16:08

reporter   ~0006661

@derick, well, I tried to display the FILE constant in cmd with and without eval, and the difference is that without eval there will be no right-hand side of the "eval()'d code". And in the case of a constant, DIR is not replaced there at all, and is output correctly.

And you said that xdebug wraps in its filename, that is, in xdebug:. But you are developing xdebug, it’s not entirely clear why then you can’t do anything with it

image.png (5,515 bytes)   
image.png (5,515 bytes)   
image-2.png (6,156 bytes)   
image-2.png (6,156 bytes)   


2023-10-22 12:01

reporter   ~0006662

@derick I think I understand what's going on. I’m certainly not a C++ programmer, but after looking at your repository, as well as the php source repository, I saw a function like zend_eval_string(), and you pass xdebug://debug-eval as parameter 3 to it. And in the php source code, where php-cli is implemented, I accordingly saw how the 'Command line code' is transmitted there. This suggests that this is most likely a required parameter of the function, and the function itself makes the substitution.

But nevertheless, if you run debug_backtrace()[0] in the debug console, then in its output you can see the correct full path to the file, and from it you could get values equivalent to __FILE__ and __DIR__. This means that when executing the code in zend_eval_string(), it is not impossible to get the real path of the folder and file, they just apparently do not go into the magic constants for some other reason. But since this function is part of the Zend Php API, then perhaps it’s worth creating a corresponding ticket in the Php developer tracker and transferring this matter to them?

UPD: I noticed that debug_backtrace[0] does not always display the file where the stop occurred. In some cases, xdebug:/debug-eval is displayed there. But anyway, in this case the file with the breakpoint is already in the next element of the result array - in debug_backtrace[1]. That is, there is still information about him

image-3.png (205,657 bytes)   
image-3.png (205,657 bytes)   


2023-10-27 10:24

administrator   ~0006663

The PHP interpreter replaces __FILE__ and __DIR__ with the directory name and file name of the file being parsed.

If Xdebug calls zend_eval_string (or you, in a PHP script run eval), then there is no file associated with the code that is being evaled.

The third argument to zend_eval_string is just so that PHP can show parse errors with a reasonable name. It is not possible to override __DIR__ and __FILE__ through this.


2023-10-28 17:24

reporter   ~0006665

@derick Well, I’m not saying that you need to redefine constants through the third argument in zend_eval_string, I’m suggesting to open a ticket for the php developers in their tracker so that they change the behavior of this function

Issue History

Date Modified Username Field Change
2016-12-03 11:30 Radek Suski New Issue
2016-12-03 11:39 Radek Suski Note Added: 0003874
2016-12-03 12:46 derick Note Added: 0003875
2016-12-03 12:46 derick Assigned To => derick
2016-12-03 12:46 derick Status new => feedback
2016-12-03 13:21 Radek Suski Note Added: 0003882
2016-12-03 13:21 Radek Suski Status feedback => assigned
2016-12-04 17:33 derick Note Added: 0003924
2016-12-04 17:33 derick Status assigned => resolved
2016-12-04 17:33 derick Resolution open => not fixable
2016-12-04 17:39 Radek Suski Note Added: 0003925
2016-12-04 17:39 Radek Suski Status resolved => feedback
2016-12-04 17:39 Radek Suski Resolution not fixable => reopened
2016-12-04 17:54 derick Note Added: 0003927
2016-12-04 17:54 derick Status feedback => resolved
2016-12-04 17:54 derick Resolution reopened => no change required
2016-12-04 18:50 Radek Suski Note Added: 0003928
2016-12-04 18:50 Radek Suski Status resolved => feedback
2016-12-04 18:50 Radek Suski Resolution no change required => reopened
2016-12-04 19:09 derick Note Added: 0003929
2016-12-04 19:11 Radek Suski Note Added: 0003930
2016-12-04 19:11 Radek Suski Status feedback => assigned
2016-12-05 14:19 derick Note Added: 0003943
2016-12-05 14:19 derick Status assigned => feedback
2017-01-03 18:49 derick Note Added: 0004128
2017-02-07 17:08 derick Note Added: 0004200
2017-02-07 17:08 derick Status feedback => resolved
2017-02-07 17:08 derick Resolution reopened => unable to reproduce
2017-12-20 16:43 spiritabsolute Note Added: 0004523
2020-03-12 16:33 derick Category Remote Debugging => Step Debugging
2023-09-02 06:31 anton.m4354 Note Added: 0006644
2023-09-02 06:31 anton.m4354 File Added: bandicam 2023-09-02 12-27-32-129.mp4
2023-09-03 13:47 derick Steps to Reproduce Updated
2023-09-03 13:47 derick Note Edited: 0003882
2023-09-03 13:59 derick Note Added: 0006645
2023-09-03 19:14 anton.m4354 Note Added: 0006646
2023-10-18 16:08 anton.m4354 Note Added: 0006661
2023-10-18 16:08 anton.m4354 File Added: image.png
2023-10-18 16:08 anton.m4354 File Added: image-2.png
2023-10-22 12:01 anton.m4354 Note Added: 0006662
2023-10-22 12:02 anton.m4354 File Added: image-3.png
2023-10-27 10:24 derick Note Added: 0006663
2023-10-28 17:24 anton.m4354 Note Added: 0006665