Multiple ajax calls not stopping on breakpoint

[Zelfapp]

I don't recall which version upgrade started this, but I'm running VSCode 1.38.0 now. When there are multiple ajax calls on a screen and I've set the breakpoint in a php file everything just hangs and it never reaches the breakpoint. I thought this might have been related to #164, but I guess not. Also #161 is not the issue because I already have the remote_autostart setting. Eventually, I just have to kill it. Also, without changing any settings, I can jump into phpstorm and debug the same screen with multiple ajax calls with no issue.

I see this in the Call Stack pane:

PHP version: 7.0.33
XDebug version: 2.4.0

launch.json:

{
    "name": "Listen for XDebug",
    "type": "php",
    "request": "launch",
    "port": 9000
}

XDebug php.ini config:

[XDebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1
xdebug.var_display_max_children = 20
xdebug.var_display_max_data = 512
xdebug.var_display_max_depth = 5

[alcidesrh]

The issue occur when ajax's requests are to same endpoint.

[bobkingof12vs]

This is happening to me too..

Similar to alcidesrh, I am finding that it happens when I have a break point on a file that multiple requests point at. But for that same request, if I put the break point in a file that only that request looks at, everything is fine. Even when I step into the file that would give me this problem

vscode 1.41.0, php 5.6.40, xdebug Xdebug 2.5.5

[edelauna]

Adding the following to my php.ini seemed to help:

xdebug.max_nesting_level = 1000

[TheFrogDaddy]

Adding the following to my php.ini seemed to help:

xdebug.max_nesting_level = 1000

Unfortunately, this did not help me.

[edelauna]

You're right - it seems that I was using a different break point.

Seems to be very much related to breakpoint placement (e.g. if I remove the breakpoint from the AJAX request workflow, it doesn't hang). It's almost like it's registering the breakpoint, but that information isn't making it to the UI.

This is at the end of my log (Debug Session is hanging):

<- threadsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 47,
  command: 'threads',
  success: true,
  body: {
    threads: [
      Thread { id: 2, name: 'Request 2 (12:55:21 PM)' },
      Thread { id: 4, name: 'Request 4 (12:55:21 PM)' },
      Thread { id: 5, name: 'Request 5 (12:55:21 PM)' },
      Thread { id: 6, name: 'Request 6 (12:55:21 PM)' }
    ]
  }
}
-> setBreakpointsRequest
{
  command: 'setBreakpoints',
  arguments: {
    source: {
      name: 'some.php',
      path: '/the/path/some.php'
    },
    lines: [ 181 ],
    breakpoints: [ { line: 181 } ],
    sourceModified: false
  },
  type: 'request',
  seq: 48
}

<- setBreakpointsResponse
Response {
  seq: 0,
  type: 'response',
  request_seq: 48,
  command: 'setBreakpoints',
  success: false,
  body: {
    breakpoints: [],
    error: { id: 205, format: 'no such breakpoint', showUser: true }
  },
  message: 'no such breakpoint'
}

[edelauna]

For more information here are the logs for when the breakpoint is disabled vs. enabled: https://gist.github.com/edelauna/d970c67b37af443dcb0552e1153f8374

I noticed that when I disable the breakpoint I'm getting the following XDebug Error. Is there something I could do further to troubleshoot?

<- outputEvent
OutputEvent {
  seq: 0,
  type: 'event',
  event: 'output',
  body: {
    category: 'console',
    output: 'XDebugError: command is not available\n    at new Response ' +
      '(/home/elliott/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:56:19)\n' +
      '    at Connection.<anonymous> ' +
      '(/home/elliott/.vscode-server/extensions/felixfbecker.php-debug- 1.13.0/out/xdebugConnection.js:611:20)\n' +
      '    at Generator.next (<anonymous>)\n    at fulfilled ' +
      '(/home/elliott/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:4:58)\n' +
      '    at processTicksAndRejections ' +
      '(internal/process/task_queues.js:89:5) {\n  code: 5,\n  name: ' +
      "'XDebugError'\n}\n"
  }
}
XDebugError: command is not available
    at new Response (/home/elliott/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:56:19)
    at Connection.<anonymous> (/home/elliott/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:611:20)
    at Generator.next (<anonymous>)
    at fulfilled (/home/elliott/.vscode-server/extensions/felixfbecker.php-debug-1.13.0/out/xdebugConnection.js:4:58)
    at processTicksAndRejections (internal/process/task_queues.js:89:5) {
  code: 5,
  name: 'XDebugError'
}

[edelauna]

I'm not sure if this will solve it for anyone else. But I was debugging via remote development on a Linux system, and it seems that there are two php.ini files (one for the apache and one for cli).

Specifically for me:
/etc/php/7.2/cli/php.ini
/etc/php/7.2/apache2/php.ini <-(this is what I updated to install xdebug because it's displayed via phpinfo() in a web browser)

It no longer hangs for me after adding:

[XDebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

;don't forget to change the path and filename to the correct one
;but make sure you use the full path
zend_extension="/usr/local/php/modules/xdebug.so"

to /etc/php/7.2/cli/php.ini

Best way to check would be to host a php file with phpinfo(), and also run php -i from the command line and confirm the Configuration File (php.ini) Path =>.

[sadovsf]

Is there anything new around this? I can confirm it is still happening. Server scripts:

api.php
req1.php
req2.php
req3.php

All AJAX requests go through api.php which is routing them to different req files. When page is being loaded javascripts calls 3 of these requests. When only one AJAX call is made everything works great, breakpoints, debugging etc... But as soon as more requests are done right after each other debuging is gone. VS Code complains about no such breakpoint or something about invalid thread ID and debuggig simply does not work at all.

I would say that debugging breaks simply as soon as single file is no matter how being opened by server more than once (in my case by include to api.php so api.php opened as result of request nor any of req files cant be debugged). At that point debugger is confused (PHP debug extension) and refuses to work

[mikocevar]

I got the same issue...everything hangs. I did manage to get it to stop when I put the "stopOnEntry:true" setting.. But that actually stops at every script entry and i need to press F5 multiple times, till the right ajax call for that breakpoint comes.

[zobo]

Hi. Can you attach a log from Debug console. Turn on "log":true in launch,json. It will log vscode-adapter as well as adapter-xdebug communication. This should give me a good look into what is happening.

[mikocevar]

@zobo of course! So let me first elaborate on what works and what does not work, just for the sake of clarity and context, right?

So debugging by itself works, I can set a breakpoint and VScode stops and I can step-into, step-over..everything works. But as said in this issue, multiple ajax calls seem to somehow break the situation. So, there's a piece of code that some of the ajax calls reach, and setting a breakpoint there does not open VScode (if I open the specific ajax route in my browser, it works again). So unless I put "stopOnEntry:true" in the launch.json file and hit F5 every time I get stopped until I get to those ajax calls that actually should stop, it won't work. I hope I explained everything well. So the log I'm pasting here is the one without the "stopOnEntry:true" flag, where the call stack just hangs when all those ajax calls which should open vscode at the breakpoint get called.

https://pastebin.com/0uwTKp3f

Let me inform you, that I had to clean the log because it contained sensitive information about my project which I do not want to share. If you think that the log is malformed because of my cleanup, please let me know and I'll try to provide a better one.

What I also just discovered is, that my ajax calls are also lazy-loaded, which means, that the breakpoint actually gets successfully triggered, if I first refresh my page, wait a few seconds and then scroll to the point where the ajax call gets triggered. But if I'm already on the section which normally instantly gets called if I refresh the page, the breakpoint does not get triggered but the stack call just waits there doing nothing, until I refresh the xdebug listener. That should mean, that if ajax calls get called too fast or something, then vscode(xdebug plugin) doesn't know what to do?

Regards

[zobo]

Hi @degusssa ! I had a quick look but it seems to me you’ve cut out a lot of messages. Is there a way you can give me a more complete log? You can change all path prefixes to (censored) but please be consistent. You can also strip the body of all property messages, but leave the headers so I will know they are there… If you feel more comfortable you can send me the file over mail…

[mikocevar]

@zobo I'd appreciated that. I still have no idea how to not expose your email here, how do we get in contact?

[zobo]

Follow the links on my profile or look at my blog on https://damjan.cvetko.org/ there should be an email link. One of my emails is in the packages.json or the commits..

[zobo]

Hi @degusssa!
Thanks for sending the log. I was able to identify the issue. As expected it has to do with the design choice/limitation that I usually whine about here. The DAP (debug adapter protocol) extension tries to keep track of different incoming Xdebug connections and display them as threads. However as it was meant to be a one-on-one design.

So in this mess of async race conditions it happens every now and then that a connection gets continued without receiving all breakpoints. This happens where two Xdebug connections come in very closely together.

I already made a branch that redefines this behavior (https://github.com/xdebug/vscode-php-debug/tree/feat/multi-session-debugging) but with that leaves other IDEs (besides VSCode) in a deprivileged position. So I'm still sitting on that and figuring out what the best approach here could be.

I have however managed to create a small change that should stabilize this issue. I'll make a PR shortly and let you know.

[mikocevar]

Hey @zobo!

I'm really happy I could provide a useful log after all. I understand your concerns. Currently, I'm tackling the issue the way that I block a few ajax requests I don't need, to be able to continue developing what I'm working on, so that helps too!

I'm glad to hear that you were able to provide a hotfix and I'm happy to test it, once it goes live.

Also, big respect from my side for being a collaborator on this project, I hope I'll one day reach the knowledge to take part at something great too!

Best regards, Mike

[zobo]

Hi!

This is a build from this branch: https://github.com/xdebug/vscode-php-debug/tree/feat/multi-session-debugging

It should handle the issue you are seeing. Do you have a chance to test it?

php-debug-0.0.0-development.zip

You can also build it yourself by checking out the said branch, running npm ci then npm run build and then node_modules/.bin/vsce package

Thanks!

[mikocevar]

@zobo Just tested it and it works!!

I think I'll just ignore the little button saying I should update to 1.16.0 since this is working awesome and nothing gets skipped 😎. I get the breakpoint triggered on all 3 requests that were usually just hanging there unless i activated them slowly.

I hope your fix gets included in the main branch for everyone eventually! Thank you