Home » Language IDEs » PHP Development Tools (PDT) » Debugger goes away, apparently making debugged project unusable (XDebug, PDT 3.5)
| Debugger goes away, apparently making debugged project unusable (XDebug, PDT 3.5) [message #1700736] |
Mon, 06 July 2015 17:55  |
Eclipse User |
|
|
|
After upgrading from Luna to Mars, I started experiencing a bug when debugging a certain project which made my life miserable, until I figured out what was going on after days.
When stepping through a script, I am sometimes too lazy to use Go to line, and quickly use F6 instead. Sometimes, that means I step over before Eclipse is done with the previous step. If that happens in 3.5, the debugger "goes away". Eclipse is still usable, but the debugger never reaches the following line.
Furthermore, if I attempt to go to a different page of that project while I'm waiting for the debugged script to timeout, the request never completes. I figured out this is because of the browser's xdebug cookie, which causes Apache to try opening a session with Eclipse. With my configuration, Eclipse will only debug one script at a time, which is why the entire project appears unusable. In fact, using a different browser or clearing the cookie will allow other requests to complete while Eclipse went away. However, Eclipse never comes back. I was surprised to see that Firefox never reports a timeout, and Apache keeps the request going after a day. This must be because XDebug does not count debugging client time in max_execution_time.
Restarting Apache is possible, but will not make Eclipse come back to reality. Eclipse can be shut down and restarted, but if one tries to start the debugger again, it will fail with "The debug port 9000 is in use. Please select a different port for the debugger." After rebooting Windows several times, I figured out the problem was that Eclipse was not actually closing properly. The eclipse.exe would stay open after shutdown for minutes, without reporting any issue.
In the end, all that's needed to workaround is to close Eclipse, to kill the ghost process and to [re]start Eclipse. When XDebug detects the connection ends, it will in fact complete the request as if there was no debugger.
Finding how to avoid triggering this bug was also difficult. Unlike what one may expect, it is not sufficient to wait until the next line has become green before stepping. One must also wait for the Variables panel to be ready. The panel indicates it is updating by making its title italic. Therefore, you must wait for the Variables panel's title to become non-italic before stepping further to avoid triggering this bug.
This bug made me realize that stepping was abnormally long. Any statement (including declaring an empty array) took about 1-2 seconds to step over. I eventually figured out that this project was taking abnormally long to step through. Simpler projects step much faster. The project which exposed the bug is a decade old and an insult to proper coding. It's overusing global variables, and I suspect that causes the Variables panel to take too long to update.
One thing I noticed is that after hitting Step Over (for example) too early, other icons (Step Into, Step Return, Resume) are still enabled. If I click one, it disables, but again the others remain enabled, so I would have to click 4 times to see them all disabled. Unsurprisingly, none of that clicking brings Eclipse back. This appears to be a simple bug exposed by the first bug.
When one steps after the next statement is highlighted in green but before the Variables panel is ready, the highlight disappears and the Variables title stays italic forever.
I do not remember experiencing this problem on 3.4 or any earlier release, and I would surely remember if I had experienced it. Since I have been using Eclipse's debugger on this project for years, this seems to be a PDT 3.5 (or platform 3.5) bug. However, 3.5 may simply be exposing the fundamental bug because it takes longer to update the Variables panel. If so, that would probably be a PDT 3.5 bug. One explanation for this could be that PDT 3.5 now colors variables whose value has changed. If it achieves this by comparing all values to their previous value, this could take a while in a project like mine.
Unfortunately, the code is huge and I have no rights over it, so I cannot share. It would be interesting to produce a test case where stepping is slow and see if others reproduce, but I am not sure how to do that. Would simply declaring a huge string cause it, or does it depend on the number of variables (and their types)?
To sum up, here are issues:
- Only the stepping icon clicked is disabled until the step completes
- The Variables view takes a long time to update in certain cases
- Eclipse's debugger becomes unusable when one steps "too fast"
- Eclipse does not warn when closing it fails
Issue 2 could be due to XDebug sending the value of all variables each step, rather than only that of updated variables. If so, that would be more of an XDebug issue than an Eclipse bug. However, if Eclipse spends much time comparing the values to determine which have changed (and should be highlighted), then a preference for better performance may be warranted. Either issue 2 or issue 3 must be new in Mars.
I originally experienced this with WampServer 2.4 (Apache 2.4.4, PHP 5.4.12, XDebug 2.2.3). Upgrading to WampServer 2.5 (Apace 2.4.9, PHP 5.5.12, XDebug 2.2.5) did not help.
I have failed to find a reference to issue 3 using Google, but have not searched issue trackers specifically. If these issues were not reported yet, I intend to formally report #3, and possibly #1, which are clearly bugs. I consider solving #4 as an enhancement, and I am not sure #2 is an Eclipse issue at all.
[Updated on: Wed, 09 September 2015 20:22] by Moderator Report message to a moderator |
|
| |
| Re: Debugger goes away, apparently making debugged project unusable (XDebug, PDT 3.5) [message #1701093 is a reply to message #1700744] |
Thu, 09 July 2015 09:16  |
 Bartlomiej Laczkowski
Messages: 1
Registered: July 2015 |
Junior Member |
|
|
Hello Filipus,
Thank you for this comprehensive problem description. I will try to find possible causes and improve the XDebug & Eclipse combo performance. If we talk about the "reasons why", I think that we should exclude the highlighting of variable changes as a possible cause of the problem with refreshing the Variables view. This feature uses very simple cache that stores the values from the previous step and is used to compare the values with the incoming ones. There are no additional requests being sent to debugger engine, etc. It is very lightweight implementation and it shouldn't cause any performance issues. It seems like the problem is somewhere else. I think that we will add some "debug policy" switch in PDT's XDebug implementation so that users will be able to start PDT in a mode that will track & log the additional info about the execution time, handled requests, etc. As for now it would be great if you could attach your .log file from your workspace, maybe we can find something interesting there. If it is not a problem for you, please attach it to the bug report:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=472226
I also suggest changing the default value of "Max children" option to eg. 20 in XDebug preferences (Window -> Preferences -> PHP -> Debug -> Debuggers). This might help to speed up the performance a little bit.
|
|
|
| Re: Debugger goes away, apparently making debugged project unusable (XDebug, PDT 3.5) [message #1707859 is a reply to message #1701093] |
Wed, 09 September 2015 22:24 |
| Eclipse User |
|
|
|
Apologies for not answering sooner, I had not noticed your answers. Unfortunately, I do not see how to subscribe to this topic, but I am now subscribed to issue 472226.
Thank you Dawid and Bartlomiej. To clarify, issue 472226 reports issue #2 of this topic. I have now reported issue #3 in issue 477011.
Bart, I did not attach my .log file, but feel free to ask in issue 472226 if what I wrote there does not suffice.
I noticed that the issue with stepping icons is not the one I described. In reality, when one clicks a certain stepping icon, that icon is immediately disabled. The other icons are only disabled about a second later (if a keyboard shortcut is used, all icons are disabled at that time). When issue #3 is triggered, this does not happen (only the icons directly clicked are disabled). I will not report any issue regarding that behavior.
|
|
| |
Goto Forum:
Current Time: Tue Apr 23 13:23:57 GMT 2024
Powered by FUDForum. Page generated in 0.02770 seconds |
] 
Search
Help
Register
Login
Home
