Request making a second request makes it hang #164
Comments
|
Have the same problem |
|
This is really annoying, the browser tab just hangs and time out if there are parallel requests to the same app. I really hope it's fairly simple to fix... |
|
@ZurabWeb yes, me too, but look at issue open time. 15 May. 5 months :( |
|
@SarnaMC I think it didn't get the attention of the author. Maybe with more comments we could draw their attention. |
|
I get a notification for every comment and more comments won't fix the issue ;) |
|
@felixfbecker Maybe you already noticed this but to me, it looks like on the second request, it attempts to send the breakpoints, and is hung before it gets a response. Looking at the code, if I'm reading it correctly it looks like it attempts to send the breakpoints to all connections. I wonder if it tries to send it to the initial connection which is paused so is not going to respond... I was going to test this theory but can't seem to get the extension set up for debugging, it keeps telling me |
|
That could very well be the problem. I have not debugged this extension in a long time, the config might have changed. What config did you use exactly? Did you follow the contribution guide? |
|
@jonyo - I'm working on a project that uses microservices and this is a deal breaker for me too - hope you figure something out. |
For debugging the extension, used the "launch extension" config:
I tried to as close as possible, ran into a few issues I am not sure about:
When I try this it gives some errors: I was able to just open the test project using the menus but not sure if that sets it up correctly. Here's a quick screencast: |
|
That sounds very weird to me. What npm/node version are you running? Did you try a git clean fresh npm install? |
I tried fresh I wonder if it is something to do with the This is on macOS 10.13 High Sierra if that makes a difference. |
|
You need to use the Node version that VS Code uses, which is v7. |
|
@felixfbecker Ran that, now it's working. 👍 Will report back if I find a solution to the multiple call issue. |
|
My configuration (use xdebug) Last log in Debug Console: The path is good, and debugging work on Atom so xdebug works |
|
@SarnaMC I see the same thing. I started debugging, I didn't get very far as I'm not familiar with debugging VSC extensions, I couldn't figure out where to put breakpoints and have it actually work lol... What I did figure out, I believe the breakpoint requests are sent ASYNC so I think that just happens to be the "last thing" it sends, it may not necessarily be the thing that causes it to hang up. The last response it gets back before it hangs is this one... My current working theory is maybe it just isn't set up to fork the connections, so maybe it has trouble keeping both connections open or something. It does seem to be keeping track of multiple connections, it just hangs up when trying to communicate with multiple ones at same time. If I can figure out how / where to add breakpoints (adding them in the main src/* files has no effect, adding them in out/* files has no effect either), I might be able to tell more. |
|
@jonyo funny but... after computer restart debug works perfectly. What have J done yesterday is J installed node 7.4.0 instead of 8.* and use command npm run compile. Now it works. Thank you @felixfbecker for your support, you are awesome! |
|
The problem really is the multiple connections hitting it at the same time. Looks like this plugin do not support simultaneous connections. I couldn't do it with this plugin, but the PHPStorm + Komodo DBGP proxy + some additional configurations in PHPStorm did the job. It works perfectly. If anyone is interested I can explain what I did. Basically these links: You need to uncheck both "Force break" options in the xDebug section in PHPStorm settings also. |
|
@RaulGRoque That's the weird thing, looking at the code, it appears to be coded to handle multiple connections. It keeps track of multiple connections, for whatever reason it just doesn't handle it if multiple connections are happening at once. @felixfbecker Do you have any tips how to get a breakpoint to work? Like I mentioned in a previous comment, I've tried adding breakpoints in the main code and in the generated code but neither one seems to make it actually pause at the line. I'm trying to add a breakpoint to the part where it is initially setting up the connection but it isn't working. Any help would be appreciated! |
|
I would have to debug the code. It should work |
|
@jonyo I only achived debugging multiple connections at once when I increased the number in the debug config of PHPStorm. I also unchecked the External Connections options and the XDebug ones like the image below:
|
|
@RaulGRoque not to be that guy, but please keep the discussions in this repo around this debugger, not PHPStorm. Anyone can use whatever editor they want, but there are folks here (including me) that get notified on every comment and if it's about configuring PHPStorm then there are forums that are a better place than this ❤️ |
|
As a side note, I accomplished debugging the backend application in my scenario putting it on an external XAMPP with a particular xDebug port. With the frontend and backend in separated XAMPPs and xDebug ports, the conflicts didn't happen using this plugin one application at a time. But it became messy and the only peaceful solution was this one that I posted above. @felixfbecker It's ok. Thanks! |
|
One big limitation of XDebug is that the whole protocol is synchronous. So while the program (on one Xdebug TCP connection) is running (I sent a |
|
I am also having this same issue when trying to debug phpunit tests |
|
For debugging any php code, which was started with exec/system/passthru functions It will be good to add "multiple connections" option to "Listen for XDebug" configuration in launch.json file. |
|
I forgot that the debug session was already running so I clicked the green play button again (Start Debugging) and now it stopped working. Even when I restart the computer it does't work anymore.
only one request request is usable, the other is like frozen or something like that. |
|
Edit: the following is completely incorrect, keeping it here for posterity and for my own humility.
|
|
@elifiner from me it still behaves the same way as mentioned here #164 (comment) Reading from the docs: This does't seem to have anything to do with number of calls. |
|
@elifiner The max_children setting definitely helps with this issue. The site I am dealing with makes a whole lot of ajax requests so it has been very hard to debug. I see the following in the DEBUG console and am lucky if I get to my breakpoint: command is not availableread ECONNRESETwrite ECONNABORTEDwrite ECONNABORTEDread ECONNRESETread ECONNRESETread ECONNRESETread ECONNRESETread .... |
|
@bdicioccio I think there may be a slight difference in your problem, for you it sounds like the multiple requests are being made by the browser. In my case, the additional request is made server-side. I don't see any errors like you do, just the normal debug notices, then it just hangs, it acts like it is getting into some kind of deadlock situation. Too bad I thought maybe it was finally fixed... Also, I believe what @jonagoldman said is correct, in theory that should just affect how much data it keeps track of by xdebug. If that fixes it for you, I wonder if somehow the default it is using for you is too high so it is running out of resources or something, so setting it to 20 is limiting it and keeping it from running out of memory. Just speculating 😄 |
|
I suspect my problem might be related to CORS. An additional OPTIONS request is always sent before the actual request so on paper two requests are always made. The issue now is why this is causing the debugger to pause like there is a hidden break-point somewhere instead of ignoring the request and pausing on the actual break-point in the second request. UPDATE 1: I can confirm this is part of the problem. I started Chrome with the UPDATE 2: I am completely guessing here, but to me it seems that the debugger breaks when two requests are made almost simultaneously. This might explain why it breaks when CORS is used, and also why it sometimes works on multiple requests and sometimes it breaks, like I explained in above. |
|
For anyone else coming across this thread: the answer described in this SO question fixed my error with multiple requests sent simultaneously freezing up VSCode/php debug. |
|
Regarding the original problem, when the server itself is making the 2nd request using curl... Its been a while since I tried, so thought I would have another go with debugging. I added breakpoints at the point it is "writing" and point it is "reading" to/from the connection. I found a few interesting things:
I'm still troubleshooting but I'll probably need to take a break soon to get some "actual" work done, just wanted to mention what I found so far in case it makes any sense to you @felixfbecker. If nothing else and I don't make any further progress I can put in a PR for the one bug fix that properly stops it from trying to send a second command until the first one is done. edit: And I meant to make this clear: it is not the case that it is hung up because xdebug is sync instead of async. Like I said in point 2 it sent several commands for the 2nd connection and got responses, every command sent was getting a response. Something else odd is going on. |
|
Got it working! I'll make a PR to fix. So, when you send the run command (or step into, etc), xdebug basically doesn't do anything on that socket connection until it hits a breakpoint or the next line is run or whatever. So if the code it is running hangs up, say you add a In this scenario described, a new connection is being made during that time it is hung up running PHP code. When there is a new connection, vscode makes requests that basically reset all the breakpoints. But the way it is coded, it attempts to set the breakpoints on ALL connections and it waits for the results of all those calls. For the first connection, it ends up adding those calls to the queue, but it never gets to run them because it's waiting on that curl request, which is waiting on breakpoint calls... So it gets deadlocked. |
|
@jonyo Awesome work! |
This introduces a new concept in the xDebug connection: "execution commands": these are commands that result in PHP being executed. The way xDebug works, if one of these commands is run, that connection is hung until the PHP code is done executing (until it gets to the next stopping point). By keeping track of when such commands are still in progress, and making it something that the adapter can check, it allows the adapter to specifically code for when the connection is currently hung. Which allows preventing the deadlock situation described in #164 The adapter also now emits `before-execution-command` since it results in possibly going into a hung state for a while. The adapter uses that event to send a `ContinueEvent`, this is just a side advantage that makes the interface more responsive. Before when you click continue, if the PHP code is hung for whatever reason (it is slow, it has a lot to do, etc), it appears that it did not work as it appears to still be stopped on a breakpoint (but it is not, which you can tell by trying to view any of the details in the debug pane). With the change, now when you click continue it immediately changes the process back to "running" state which is more truthful. Since #164 has a lot of comments, here is the **tl;dr:** deadlock explanation: 1. Connection 1 makes a second connection with curl. 2. It sends command to all connections to set breakpoints, and waits for response. 3. The second connection hangs as it is waiting for connection 1 to set breakpoints, connection 1 hangs without setting those breakpoints because it is waiting for connection 2 to respond and can't do anything until that completes. This PR makes it not wait for the breakpoints to be set on a connection if the connection is waiting for code to execute. So now connection 2 can finish initializing and run, no more deadlock. Fixes #164
|
🎉 This issue has been resolved in version 1.12.5 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
|
I know you said this was fixed in the latest release, but I'm not sure it is. I have two ajax calls for a page going to server. I see two process running in the debug window, however sometimes it does stop on the breakpoints while at other times it doesn't. Then on top of that even if I tell it to finish and the processes go away from the debug window, the browser freezes until I stop the debug. { |
|
It now hangs when receiving a second Ajax request. My web page sends Ajax requests continuously. |
…ebug#294) This introduces a new concept in the xDebug connection: "execution commands": these are commands that result in PHP being executed. The way xDebug works, if one of these commands is run, that connection is hung until the PHP code is done executing (until it gets to the next stopping point). By keeping track of when such commands are still in progress, and making it something that the adapter can check, it allows the adapter to specifically code for when the connection is currently hung. Which allows preventing the deadlock situation described in xdebug#164 The adapter also now emits `before-execution-command` since it results in possibly going into a hung state for a while. The adapter uses that event to send a `ContinueEvent`, this is just a side advantage that makes the interface more responsive. Before when you click continue, if the PHP code is hung for whatever reason (it is slow, it has a lot to do, etc), it appears that it did not work as it appears to still be stopped on a breakpoint (but it is not, which you can tell by trying to view any of the details in the debug pane). With the change, now when you click continue it immediately changes the process back to "running" state which is more truthful. Since xdebug#164 has a lot of comments, here is the **tl;dr:** deadlock explanation: 1. Connection 1 makes a second connection with curl. 2. It sends command to all connections to set breakpoints, and waits for response. 3. The second connection hangs as it is waiting for connection 1 to set breakpoints, connection 1 hangs without setting those breakpoints because it is waiting for connection 2 to respond and can't do anything until that completes. This PR makes it not wait for the breakpoints to be set on a connection if the connection is waiting for code to execute. So now connection 2 can finish initializing and run, no more deadlock. Fixes xdebug#164
…ebug#294) This introduces a new concept in the xDebug connection: "execution commands": these are commands that result in PHP being executed. The way xDebug works, if one of these commands is run, that connection is hung until the PHP code is done executing (until it gets to the next stopping point). By keeping track of when such commands are still in progress, and making it something that the adapter can check, it allows the adapter to specifically code for when the connection is currently hung. Which allows preventing the deadlock situation described in xdebug#164 The adapter also now emits `before-execution-command` since it results in possibly going into a hung state for a while. The adapter uses that event to send a `ContinueEvent`, this is just a side advantage that makes the interface more responsive. Before when you click continue, if the PHP code is hung for whatever reason (it is slow, it has a lot to do, etc), it appears that it did not work as it appears to still be stopped on a breakpoint (but it is not, which you can tell by trying to view any of the details in the debug pane). With the change, now when you click continue it immediately changes the process back to "running" state which is more truthful. Since xdebug#164 has a lot of comments, here is the **tl;dr:** deadlock explanation: 1. Connection 1 makes a second connection with curl. 2. It sends command to all connections to set breakpoints, and waits for response. 3. The second connection hangs as it is waiting for connection 1 to set breakpoints, connection 1 hangs without setting those breakpoints because it is waiting for connection 2 to respond and can't do anything until that completes. This PR makes it not wait for the breakpoints to be set on a connection if the connection is waiting for code to execute. So now connection 2 can finish initializing and run, no more deadlock. Fixes xdebug#164
…ebug#294) This introduces a new concept in the xDebug connection: "execution commands": these are commands that result in PHP being executed. The way xDebug works, if one of these commands is run, that connection is hung until the PHP code is done executing (until it gets to the next stopping point). By keeping track of when such commands are still in progress, and making it something that the adapter can check, it allows the adapter to specifically code for when the connection is currently hung. Which allows preventing the deadlock situation described in xdebug#164 The adapter also now emits `before-execution-command` since it results in possibly going into a hung state for a while. The adapter uses that event to send a `ContinueEvent`, this is just a side advantage that makes the interface more responsive. Before when you click continue, if the PHP code is hung for whatever reason (it is slow, it has a lot to do, etc), it appears that it did not work as it appears to still be stopped on a breakpoint (but it is not, which you can tell by trying to view any of the details in the debug pane). With the change, now when you click continue it immediately changes the process back to "running" state which is more truthful. Since xdebug#164 has a lot of comments, here is the **tl;dr:** deadlock explanation: 1. Connection 1 makes a second connection with curl. 2. It sends command to all connections to set breakpoints, and waits for response. 3. The second connection hangs as it is waiting for connection 1 to set breakpoints, connection 1 hangs without setting those breakpoints because it is waiting for connection 2 to respond and can't do anything until that completes. This PR makes it not wait for the breakpoints to be set on a connection if the connection is waiting for code to execute. So now connection 2 can finish initializing and run, no more deadlock. Fixes xdebug#164
|
For me, it hangs too when receiving an AJAX request. Still didn't try to downgrade. |
|
Running v 1.3.8.0 Any time there are 2 or more ajax calls php debugging hangs. Had to switch from vscode to phpstorm so I could debug. I didn't make any changes. Phpstorm works, vscode does not.
|
|
@Zelfapp By the way that sounds like a different issue, this one was a deadlock that happened when one request made a second request, it was not related to multiple ajax requests. Also this one was resolved and closed over a year ago, you may get more traction creating a new issue or looking for a more recent issue that involves multiple ajax requests. I see the confusion though if you only read the issue title it does sound related; since you are not the first to comment on it I'll update the title (if it lets me). |
jonyo
changed the title
jonyo
changed the title
For a project, we have multiple micro services, running in different containers each set up with it's own xdebug port so I can debug a specific micro service or multiple microservices at once. Everything is working well, breakpoints break, code is able to step properly etc. Unless one microservice makes a call to another one that makes a call back to the first micro service, at which point it hangs until the connection times out.
Before it times out though, in the editor it shows 2 requests on the call stack. If I put a breakpoint in the code in "container A" before the point it makes that call to container B, it breaks just fine. If I then try to step through it, it hangs once it gets to the line that makes the call to container B until the container B call times out, then it continues on with a timeout error creating a stop point in xdebug.
I was able to simplify the error down to a simple test not involving multiple containers or anything, basically just have a call make a curl connection to make a second call.
PHP version: 5.6.30
XDebug version: 2.5.0
Adapter version: 1.10.0
Your launch.json:
XDebug php.ini config:
XDebug logfile (from setting
xdebug.remote_login php.ini):Adapter logfile (from setting
"log": truein launch.json):Code snippet to reproduce:
The text was updated successfully, but these errors were encountered: