Debugging not working because routes aren't parsed

[advancingu]

The Symfony debugger of this plugin simply won't work under Eclipse 4.2.2 on my system. I've tried stable plugin version 1.0.85 and dev version 1.0.94 without success.

The Symfony tab in the debug launcher (configuration window) keeps telling me that The route MyRoute does not exist in the project MyProject, even though I can definitely see MyRoute printed out on the console when running php app/console router:debug. (The environment is recognized correctly in that tab.)

I've also tried removing all routes except a single one in app/config/routing.yml and app/config/routing_dev.yml and it still gives me this error.

How can I track down this issue?

[aledelgo]

Here exactly the same problem... any solution?

[pulse00]

Sorry, i'm currently too busy with projects to look into this issue. The Symfony debugger doesn't do anything special apart from generating the correct URL for your action

I'd suggest to use the regular debugging mechanisms, see http://wiki.eclipse.org/Debugging_using_XDebug. You can simply start a debug session on frontend_dev.php and then open the page you want to debug.

[aledelgo]

Perfect. found a workaround based on the pulse00 post (#171 (comment)) .
I had the problem because i selected "XDebug (Symfony)" as Server Debugger. When you select this, the Symfony TAB in the launcher configuration become checked wit a white-on-red X sayn that you need a valid Route or that the route name is not found in the project. This error on the Symfony Tab prevent you from clicking the 'Debug' or 'Run' button... so the launcher configuration can't be used.
If you select "XDebug", the Symfony tab become valid also without any route defined and you can use the launcher configuration and use xDebugger in eclipse. Hope this help.

[NelsonSR]

I'm having that issue with Eclipse Kepler (which I've just installed today). But in my case if I select XDebug instead XDebug (Symfony) I can't edit the launch settings, route and Generated URL (in the tab Symfony). Actually the drop list Enviroment is always disabled, not matter what debugger I choose.

That was not the case with Eclipse Indigo, which no only let me edit those fields, although auto-completed the route field for me. The only problem was that it never listed my custom routes, which it made useless for debugging.

Any alternativa to debug Symfony2 webapps with XDebug?

[pulse00]

@NelsonSR you can simply debug the project with the regular PDT functionality, the plugin only adds the convenience to generate an URL for your current controller action automatically.

So just set the debugger to xdebug and start a regular xdebug session. See http://wiki.eclipse.org/Debugging_using_XDebug

[NelsonSR]

Yeah, you were very clearly about that in your past post, but my problem was that I could not make XDebug works AT ALL in Eclipse. Looking for any clue I took a read on your FAQ page (http://symfony.dubture.com/faq/). After cleaning the project finally XDebug start to work.

Now, this is not a issue in regard to this plugin, just a confusion I have about XDebug on Eclipse: why it just stop the debugging in the app_dev.php controller?. Eclipse hangouts after that.

[pulse00]

Yeah, you were very clearly about that in your past post,

sorry, i should have read the whole thread first ;)

why it just stop the debugging in the app_dev.php controller

In your debug configuration, there's an option Stop at first line. I think this is enabled by default and will stop execution at the first line of the first executed script. Just turn this off and you should be good to go.

[NelsonSR]

I was aware of that option, but with all this configuration mess I just forget about it. Anyway, now debugging don't even starts. It just activate the internal browser. Seems like I touch something else, don't know what yet. If I activate Stop at first line I have a debugging session like always (just in app_dev.php controller).

[pulse00]

So when you activate Stop at first line, the debugger stops in app_dev.php, but when you deactivate, it doesn't stop at your breakpoint?

Does the request hit the script where you have set the breakpoint?

[NelsonSR]

No, I'm not using breakpoints at all, I just start the debugger on a custom Sonata Admin controller. It never gets there (which it's very frustrating).

If I activate Stop at first line the debugger gets to app_dev.php, but if I deactivate it, then the Variables panel is empty and the Debug panel just display the name of the PHP web application. Other thing: the change of perspective from PHP to Debug is not automatic (probably because there's nothing to display).

[advancingu]

You need to set a breakpoint somewhere. How else would you want to debug?

[NelsonSR]

@advancingu: as far as I know, breakpoints are optional. Actually two days ago I was debugging the Sonata Admin dashboard, with no breakpoints setted (it was almost a never ending debugging process, because of its complex structure, so I had to stopped), but it did walk through many line of many files (obviously I had to press F5 a lot of times, to step in).

That was on Eclipse Indigo, and setting a breakpoint never worked, so now on Eclipse Kepler I don't use them. But I'll give it a try, just to see what happens.

[NelsonSR]

Well, like I said, setting a breakpoint does not make any difference. The behavior is the same.

[pulse00]

Sorry, but breakpoints are not optional ;) How should the debugger know where yo want it to stop whithout having set a breakpoint?

[NelsonSR]

I understand what is the function of the breakpoints in a debugging process, but right now they are meaningless if the debugging process can not getting started. It's not important to me WHERE the debugging stops, the important thing is HOW to make it start in first place!.

In my personal case, I want to debug one action class of the Vich Uploader Bundle, to see what happens with the file_name field and where exactly gets disappear. I now I should put a breakpoint in one of those methods, but XDebug is never gonna get there, in fact, never gets out of app_dev.php.

[NelsonSR]

I've just created another Eclipse workspace on /var/www and copied the whole project there (the prior location was /home/sfprojects). Then I deleted the .eclipse file and .settings directory. With this fresh setting environment the behavior is the same (except for the fact that I have auto-complete in the route field when I selected XDebug (Symfony)), but no more.

[pulse00]

It's not important to me WHERE the debugging stops, the important thing is HOW to make it start in first place!.

Well, the debugging process starts if you run your PHP Web application debug configuration in debug mode. But simply that you started a XDebug debugging session does NOT make Eclipse stop at anywhere in your script execution. The whole process is explained here: http://wiki.eclipse.org/Debugging_using_XDebug, i really don't know how to explain it in more detail.

Here's my advice:

1. Do not use the XDebug (Symfony) debugger, but use the regular XDebug debugger
2. Make sure your xdebug settings in your php configuration are set to the ones described in the wiki i've linked above

I have to repeat myself here: If you never set a breakpoint, PDT will not stop the execution in your script at any point during a request - unless you set Stop at first line. It simply means that the IDE and XDebug have opened a debugging session.

Also, as this is a general PDT debugging question, not really related to the Symfony plugin, please see the PDT forum on advice how to get your pdt debugging setup working.

[NelsonSR]

Well, seems like I've been wrong all this days. Apparently in the case when the debugger starts, what I actually did was set a breakpoint; delete that breakpoint starts a session but with no debugging process. Besides that, the Symfony web app wasn't working (some mess files in the Firefox cache, a cache clean up solved the problem), and an automatic URL (writing it manually solved the problem).

Now I can debug simple PHP scripts as PHP Web Applications and Symfony action methods (but not using the option Symfony action, I must go to Debug configuration and click on the corresponding Debug button).

My last obstacle is to test a web app with FOS User Bundle and Sonata Admin (users stored to and retrieved from a database). I guess this is the recipe for that task: http://symfony.com/doc/current/cookbook/testing/http_authentication.html. The goal is run the debugger while I click on the save button, and see the field values. Any insights about it?

[pulse00]

@NelsonSR the debug session will be active during multiple requests, there's no need to start a debugging session for each request you make. The process basically works like this:

1. Start the debugger session
2. Eclipse will open a browser window with the first url to your app (with some XDebug parameters to start the session)
3. Now Eclipse and XDebug have an open debug session.
4. You can then browse through your app in the browser as you wish (e.g. browse to your authentication action and click save)
5. If anytime during this process the executed code hits a breakpoint, execution will halt there.

That's it basically. So let's assume the following example: Your symfony app lives under http://myApp.local/app_dev.php. Your authentication controller is available at http://myApp.local/app_dev.php/auth.

If you setup your debug configuration to start with the url http://myApp.local/app_dev.php, you simply need to start the debug session, and then browse to your /auth controller. Execution will halt if you've setup a breakpoint there.

[NelsonSR]

In the case of login forms, all the code is displayed in the Debug Output (HTML raw code) and Browser Output (web page with no CSS) Eclipse windows, but none data in the web page opened by the XDebug session. There's a breakpoint in one of the action methods.

I'm sure I'm missing something, but I wanted to ask before research something else about the subject.

[NelsonSR]

I've could start a debugging in the form login, but not by running the sonata_admin_dashboard route, but running
sonata_user_admin_security_login. Giving a look to app/log/dev.log I found the right route:

[2013-09-22 07:40:31] request.INFO: Matched route "sonata_user_admin_security_login" (parameters: "_controller": "Sonata\UserBundle\Controller\AdminSecurityController::loginAction", "_route": "sonata_user_admin_security_login") [] []

So, apparently I have to step in along all the files involved in the login process until the login form shows up in the browser, so I can fill the login and password fields, hit the login button and I go to the Employee File form, fill the required form fields and (finally) hit the save button, to see what I really want to see.

And I ask to myself: there's no exists any shortcut to debug an action method, without go through that extremely long and tedious process?.