SlickEdit Community
SlickEdit Product Discussion => SlickEdit® => Topic started by: redcar on July 28, 2015, 09:32:21 AM
-
I have been using slickedit/xdebug for a couple of days to do some debugging on a large PHP project (mediawiki to be precise), and I have found that the debugging tool is almost excellent, but has a couple of problems.
My configuration is slickedit V17, the local machine is windows 8.1 64 bit, tunnelling through ssh to a linux server running the current version of xdebug.
The problems are:
1. In the PHP debug options, if the "stay in debugger" check box is not ticked, then after resuming from a breakpoint, any subsequent breakpoints are often skipped. If the "stay in debugger" check box is ticked, then it is necessary to manually stop the debugger after each web page is loaded, otherwise, no breakpoints will be hit in subsequent pages.
2. Occasionally slickedit reports that it did not understand a debugger initialisation message, and stops listening for the debugger. I have not found a way to restart the listening, other than to go through the configuration windows and change some setting like "stay in debugger".
Have these issues already been addressed? as this is a hobby project, I am unlikely to be upgrading for now.
-
I set up my Windows box (Windows 7) as the client, and a Linux VM (Ubuntu 14.04) as the remote web server as a test. I tested with both SlickEdit v17 and the latest v19.0.2 and did not see your issues.
Some questions/comments:
1. If you are debugging remote web pages, then you must be certain you have set up remote-to-local mapping correctly (Build>PHP Options, Run tab, File mapping). Else no breakpoints will be hit. For example, if the local file is 'c:\project\index.php', and the remote path (not the url) is '/var/www/html/index.php', then your mapping would be:
Local Directory: c:\project
Remote Directory: /var/www/html
2. Can you reproduce with a small project?
3. Can you reproduce with a clean config?
That's all I can think of right now.
++rodney
-
Thanks Rodney,
Can you tell me how it should work? When the debugger is triggered, the STOP icon in the debug toolbar changes from grey to red. I expect it to go back to grey if the web page completes loading without hitting a breakpoint (ready to start the debugger again on the next page). How does the "stay in debugger" setting interact with that?
I will try to find a samll project that exhibits the symptoms (but I am not much of a PHP programmer yet!)
Mike
-
"Stay in debugger" means exactly that. ;-) The idea is that you do not want to be stopping and starting a debug session each and every time you perform some action (follow a link, etc.) that breaks (on a breakpoint, etc.); it would be visually disruptive (tool windows appearing/disappearing) not to mention tedious. "Stay in debugger" ON is typically what you want when debugging PHP for a website. The toolbar icon staying red is correct behavior, since you really are staying in the debugger.
++rodney
-
It has been a while, and I have sometimes got xdebug integration to work, and sometimes not. Then I got busy with other stuff...
I recently got back to some php debugging, and configured slickedit with the a new project connecting to our production server, and everything worked perfectly.
Buoyed with the success, I thought I would have a go at a development job on our test server, and again, it worked perfectly... for a couple of days, then the debugger ceased to stop at breakpoints and became generally unusable, which was where I got to 6 months ago.
This time however, I had one project that still works and one that doesn't, and a capture of some xdebug logs seems to give a big clue as to the problem:
On the server that works, setting a breakpoint gives this in the log:
<- breakpoint_set -i 24 -t line -s enabled -f file:///var/webs/forums/fcf/forum/download/file.php -n 92
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="24" state="enabled" id="265870002"></response>
Which has a sensible path on the Linux server, but on the other server, we get:
<- breakpoint_set -i 23 -t line -s enabled -f file:///C:/Users/Mike/Downloads/fcf/fcf_dev_316/forum/ext/anavaro/postlove/event/main_listener.php -n 23
-> <response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="23" state="enabled" id="174480001"></response>
Which is the local path on the windows machine running Slickedit.
I have checked and rechecked the path mapping in the project/project properties/options pane in SE, but it doesn't help.
It is puzzling that it worked for a while with this configuration and then (apparently autonomously) it stopped working.
Any hints to get the remote file path working?
BTW, still using SE v17, but now with windows 10 64 bit.
-
That means we are attempting to set a breakpoint on a file that has no remote-to-local mapping. At least that is what it looks like from the little I've seen here.
I would need to see the following to investigate this further:
1. The offending project (.vpj) file.
2. A debug log from the offending debug session. Set def_debug_logging to 1 (Macro>Set Macro Variable). The log is under your config-dir at logs/debug.log
Zip it up and attach it to your reply. If you'd rather you can upload it to support by opening a case under Support on our website. You'll need to provide me with the upload folder to get your stuff from.
++rodney
-
Thanks, I enabled the debug logging, and (I think coincidentally) the breakpoints started working again...
If it stops working again, I will post back here.
-
I have found what appears to be a minor bug.
I put a code error into my php and hit a php parse error exception (see attached debug log) The SE dialog popped up, telling me the kind of exception, but when the box was cleared, SE opened the file file:///var/webs/forums/fcf/forum/phpbb/class_loader.php" lineno="160", whereas the exception (and coding error) was at file:///var/webs/forums/fcf/forum/ext/anavaro/postlove/migrations/release_1_2_0.php" lineno="40"
-
From the log it is clear that the stack we are fetching does not include the line where the exception occurs. I tried reproducing this on my end by causing a 'Parse error' inside a called function and everything worked well for me (the exception line was included with the stack). I am using version 2.2.3 of the Xdebug plugin. What version are you using?
++rodney
-
I am using version 2.2.3 of the Xdebug plugin. What version are you using?
I am using 2.3.3
Another issue (I am not sure if it is an SE issue) is that the PHP code has an error handler which calls
trigger_error("Test message", E_USER_ERROR);This causes the script to abort and give a message via the http page being loaded.
Slickedit does not configure xdebug to break on these errors, (but I have not seen the xdebug syntax to allow this).
-
trigger_error('...', E_USER_ERROR) triggers a "Fatal error" exception for me and gives a correct stack. I don't know why it does not work for you. I've noted that you are running PHP 5.6.17 and I am running 5.5.9. You are running Xdebug 2.3.3 and I am running 2.2.3.
I can only attempt to set up a test vm configured similar to your setup and see if I can reproduce. I'm not sure when I will be able to do that (not today anyway).
++rodney
-
Thanks for your efforts Rodney, I can live with it as it is, but I would love it to be a little less fiddly.