1

My phpinfo() shows xdebug.remote_autostart = Off, but after each request, the XDEBUG_SESSION=PHPSTORM cookie is being kept set. What keeps initiating the Xdebug?

Environment = docker + WSL2 + PHP 7.3.22 + Xdebug v2.9.8 + PhpStorm 2020.2.3. IDE is closed all the time and Xdebug helper also disabled.

Here is the complete Xdebug part of phpinfo() output:

xdebug.auto_trace   Off Off
xdebug.cli_color    0   0
xdebug.collect_assignments  Off Off
xdebug.collect_includes On  On
xdebug.collect_params   0   0
xdebug.collect_return   Off Off
xdebug.collect_vars Off Off
xdebug.coverage_enable  On  On
xdebug.default_enable   Off Off
xdebug.dump.COOKIE  no value    no value
xdebug.dump.ENV no value    no value
xdebug.dump.FILES   no value    no value
xdebug.dump.GET no value    no value
xdebug.dump.POST    no value    no value
xdebug.dump.REQUEST no value    no value
xdebug.dump.SERVER  no value    no value
xdebug.dump.SESSION no value    no value
xdebug.dump_globals On  On
xdebug.dump_once    On  On
xdebug.dump_undefined   Off Off
xdebug.file_link_format no value    no value
xdebug.filename_format  no value    no value
xdebug.force_display_errors Off Off
xdebug.force_error_reporting    0   0
xdebug.gc_stats_enable  Off Off
xdebug.gc_stats_output_dir  /tmp    /tmp
xdebug.gc_stats_output_name gcstats.%p  gcstats.%p
xdebug.halt_level   0   0
xdebug.idekey   PHPSTORM    PHPSTORM
xdebug.max_nesting_level    256 256
xdebug.max_stack_frames -1  -1
xdebug.overload_var_dump    2   2
xdebug.profiler_append  Off Off
xdebug.profiler_enable  Off Off
xdebug.profiler_enable_trigger  Off Off
xdebug.profiler_enable_trigger_value    no value    no value
xdebug.profiler_output_dir  /tmp    /tmp
xdebug.profiler_output_name cachegrind.out.%p   cachegrind.out.%p
xdebug.remote_addr_header   no value    no value
xdebug.remote_autostart Off Off
xdebug.remote_connect_back  Off Off
xdebug.remote_cookie_expire_time    3600    3600
xdebug.remote_enable    On  On
xdebug.remote_host  172.18.31.113   localhost
xdebug.remote_log   no value    no value
xdebug.remote_log_level 7   7
xdebug.remote_mode  req req
xdebug.remote_port  9005    9005
xdebug.remote_timeout   200 200
xdebug.scream   Off Off
xdebug.show_error_trace Off Off
xdebug.show_exception_trace Off Off
xdebug.show_local_vars  Off Off
xdebug.show_mem_delta   Off Off
xdebug.trace_enable_trigger Off Off
xdebug.trace_enable_trigger_value   no value    no value
xdebug.trace_format 0   0
xdebug.trace_options    0   0
xdebug.trace_output_dir /tmp    /tmp
xdebug.trace_output_name    trace.%c    trace.%c
xdebug.var_display_max_children 128 128
xdebug.var_display_max_data 512 512
xdebug.var_display_max_depth    3   3
LazyOne
  • 158,824
  • 45
  • 388
  • 391
Tauri28
  • 888
  • 1
  • 18
  • 30
  • 1) What/How are you debugging: a web page or CLI script? On Linux (the OS inside the docker container) it is very common to have separate php.ini for CLI and a web server. So make sure to collect `phpinfo()` output in a same way as you are trying to debug. 2) If cookies is set -- ensure that Xdebug related browser extension is either diabled or configured not to set it. 3) If extension is fine ... check what cookies you have and manually delete it (using browser's Dev Tools). Sometimes (very rarely) the cookie may got stuck and will not be removed by the extension (seen it few times). – LazyOne Nov 29 '20 at 14:25
  • @LazyOne web page - looking the correct phpinfo. I wrote that the extension is disabled. I already have tried deleting cookies manually. The cookie will be set to the value specified by xdebug.idekey after each request. – Tauri28 Nov 30 '20 at 09:15
  • 1) Check other browser extensions (in case if you have any that can modify requests). Better disable them ALL for the moment. 2) It could be the code on PHP end that sends the cookie (very unlikely unless done on purposes, e.g. special debugging case). – LazyOne Nov 30 '20 at 10:19
  • Try this: open Incognito/Private session in your web browser; open Dev Tools, Network tab -- make sure that it will remember the requests between page navigation/redirects; call your page -- now check the original request -- see if the cookie was sent with the very original request. If not -- check if they appeared in response. Check subsequent requests (especially Ajax) -- maybe such cookie is added by some JS code. – LazyOne Nov 30 '20 at 10:20
  • P.S. If you can -- try it in a completely different browser (e.g. new Microsoft Edge if you are on Windows; Firefox Dev Edition; use separate profile in your browser (so it's definitely not anything from your current browser. P.P.S. I'm very doubt that it will be this .. but if you use any proxy for dev purposes (e.g. Charles proxy, Fiddler, Burp Suite etc) check them as well as well as corresponding browser settings. – LazyOne Nov 30 '20 at 10:24
  • 1
    @LazyOne Tried Firefox with no addons at all. Same happens. It must come from the server side since the cookie is set to the same value that is set in the php.ini xdebug.idekey. Whatever value I assign to xdebug.idekey, it will appear in the cookies. – Tauri28 Dec 01 '20 at 13:42
  • Check your PHP code then (could be some forgotten script/helper method that was written to help debugging some requests I guess). Start with searching for `xdebug.idekey` in all project files (as it needs to read that value first in order to set the cookie). If project search does not find anything -- do whole system search, outside of the IDE. I have no idea what that might be coming from... but it's unlikely to be a package, more like custom code. – LazyOne Dec 01 '20 at 13:48
  • @LazyOne Happens with empty script. – Tauri28 Dec 02 '20 at 10:46
  • 1) Check your PHP installation (`phpinfo()` output). Maybe you have `auto_prepend_file` file configured there. It may also be OPCache thing (e.g. `opcache.preload`). 2) What about the web server itself. You can set cookies with mod_rewrite or other Apache/nginx directives. – LazyOne Dec 02 '20 at 11:09
  • 3) I've completely overlooked this ... but **check your Docker file** -- you can easily have some Xdebug instructions set there (an environment variable that Xdebug uses) -- it's not rare to see Xdebug configured this way (at least partially). – LazyOne Dec 02 '20 at 11:12
  • @LazyOne auto_prepend_file has no value, opcache.preload does not exist. I disabled opcache. .htacces does not have anything in it. About docker: those env variables should still end up in the runtime so I should see something in the phpinfo. I noticed that If I change the value of the cookie to anything else (event empty string), it does not changed back. But if I delete it, it will be reassigned. – Tauri28 Dec 03 '20 at 10:19
  • @LazyOne If I set xdebug.remote_enable=0, the problem goes away. – Tauri28 Dec 03 '20 at 10:24
  • @LazyOne From the xdebug manual: ```Set the XDEBUG_SESSION_START=session_name GET (or POST) HTTP parameter. The value for session_name is not important. Xdebug will set the XDEBUG_SESSION cookie. As long as the cookie is present, debugging will be initiated for every HTTP request (including favicons and images if they go through PHP). ``` But I do not have XDEBUG_SESSION_START set in the request. – Tauri28 Dec 03 '20 at 10:31
  • In such case I have no clue where the cookie might be coming from. Those Xdebug settings (pretty standard) do not generate any cookies like that (never seen them in my environment or elsewhere, otherwise you would see a lot of similar questions here). – LazyOne Dec 03 '20 at 10:33
  • *"But I do not have XDEBUG_SESSION_START set in the request"* That would be way to obvious if you would had it there. You have tried another (fresh) browser and it behaves the same .. so it's not some remnant of an old browser config. It's not Xdebug config (php.ini). It's not PHP code from `*_prepend` PHP files. You say there is nothing in the Docker file. It's not a proxy as well (as I assume). **What about web server config** (mod_rewrite//htaccess/nginx file or alike) that can modify requests before it gets processed by the PHP? – LazyOne Dec 03 '20 at 10:37
  • *"If I set xdebug.remote_enable=0, the problem goes away."* Sure thing -- you are disabling the debugger. – LazyOne Dec 03 '20 at 10:38
  • @LazyOne Another piece to the puzzle: my only XDEBUG related configuration in docker-compose.yml is ```- XDEBUG_CONFIG=remote_host=${WSLHOST}```. Once I remove it, problem is fixed. It is a workaround to the dynamic IP of WSL2. – Tauri28 Dec 03 '20 at 10:42
  • It can be `XDEBUG_CONFIG` actually. I'm trying to find a comment or a link where I have seen such statement. – LazyOne Dec 03 '20 at 10:50
  • 1
    Phew .. found it (had to use Data Explorer to find it....). https://stackoverflow.com/a/53278116/783119 . It's undocumented behaviour: see bottom of the https://www.larry.dev/xdebug-on-docker/ – LazyOne Dec 03 '20 at 10:54
  • @LazyOne Okay. Using Windows unfortunately and at least month or so ago there were no reasonable solution to this dyanmic IP issue so this was the workaround I used. I guess I need to find another solution. Thank you very much for the help! – Tauri28 Dec 03 '20 at 10:59
  • Instead of using `XDEBUG_CONFIG` ... try to write `xdebug.remote_host=${WSLHOST}` string into the actual php.ini while building your image. I mean -- check the Dockerfile section from this answer/question to see what I mean: https://stackoverflow.com/a/44036045/783119 – LazyOne Dec 03 '20 at 11:05
  • BTW: try Xdebug 3. It was rewritten quite a lot so may have that undocumented part obsolete now. But note that Xdebug 3 uses different parameter names than v2 ... so you would need to check/update your Xdebug config. – LazyOne Dec 03 '20 at 11:14
  • @LazyOne Im not that proficient in docker. I am using existing images. Can I like add some kind of local Dockerfile to modify the build process of any of these existing images? – Tauri28 Dec 03 '20 at 15:14
  • Me too :( But in general: if Xdebug does not come as part of an existing (base) image then any config you can do during the build stage (just like Xdebug gets installed and configure via .ini file in that my last link). I guess make a new question and post your Dockerfile there -- there may be someone willing to give a hint or two. – LazyOne Dec 03 '20 at 15:18
  • And BTW: since the issue is resolved -- please post your final solution with any additional info (like what other options/places you have checked) as an answer (you can mark it as accepted later). This will help other users in a similar situation a lot (question with answer has much better visibility). – LazyOne Dec 03 '20 at 15:20

1 Answers1

1

Issue was related to Xdebug and Docker dombination. Quoting the description from the https://www.larry.dev/xdebug-on-docker/

On the other hand, there’s an undocumented side effect of using the XDEBUG_CONFIG environment variable vs. using the configuration file to set the remote host. When using the environment variable to set the IP address, PHP will try to connect to your debugger on each page request without being initiated by a browser plugin or other trigger. This is the same behavior as if you set xdebug.remote_autostart=1 . You can read more about this configuration item here.

Tauri28
  • 888
  • 1
  • 18
  • 30