Phpstorm 2.1 upgrade xdebug stopped working

Hello,

Like the subject line says, I have been trying to get xdebug to work again on my Phpstorm setup. The only thing that changed was downloading and installing the new binary.

I am on OSx runngin MAMP.

With 2.0.0 and 2.0.1 everything worked.

I tried several projects just to make sure, and none of them work.

Here is my conf:

[xdebug] zend_extension="/Applications/MAMP/bin/php5/lib/php/extensions/no-debug-non-zts-20060613/xdebug.so" xdebug.remote_mode="req" xdebug.var_display_max_depth=10 xdebug.var_display_max_data=1000 xdebug.remote_enable=1 xdebug.remote_host=127.0.0.1 xdebug.remote_port=9001 xdebug.remote_handler="dbgp"



Is there anything else I can attach to get to the bottom of this.

Best Regards,
Fotis
15 comments
Comment actions Permalink

Hello Fotis,

[xdebug]
xdebug.remote_port=9001 


Please check that you set up the same value for Xdebug port in Project Settings -> PHP -> Debug. Probably some settings were reset to default after upgrade.

Do you use 'Listen' debug button?

Thank you for feedback!

0
Comment actions Permalink

Hello Nikolay,

Yes the xdebug port is set correct.

I did check the break on first line, and the debug script does break on the first line of an index.php file, but anything furder than that doesn't work, any ideas?

Thanks,
Fotis

0
Comment actions Permalink

Fotis,

Looks like the problem with path mappings. Could you attach a screenshot of your server configuration(Project Settings->PHP->Servers)?

0
Comment actions Permalink

Hello Nikolay,

Thanks so far, I am attaching the screenshot.

Please don't forget that this used to work on the previous version.

My apache configuration

<VirtualHost *:8888>   ServerName aktel.fotis   DocumentRoot "/Home/webdev/aKtel/web"   DirectoryIndex index.php   <Directory "/Home/webdev/aKtel/web">     Options Indexes FollowSymLinks MultiViews      AllowOverride All     Allow from All   </Directory>   Alias /sf /opt/symfony/1.4.9/data/web/sf </VirtualHost>



My corresponding /etc/hosts

127.0.0.1   aktel.fotis



And the screensho attached.

Best,
Fotis

Attachment(s):
Screen shot 2011-05-25 at 11.04.26 PM.png
0
Comment actions Permalink

Few suggestions to check:
1) Any symbolic links used inside the project ? if so ...
2) Settings | PHP | Server -- please check if path mappings are correct (if you are using them -- they may have been reset), especially if symbolic links are in use.

Please try this:
When index.php is hit, continue debugging line by line. If PhpStorm cannot find the file to debug it should tell you (AFAIK) and then you may need to check the path mappings (see above).

Also, what kind of lines are you trying to setup breakpoints at -- are they simple statements like $a = 14; or $bbb = App::doSomethingUseful(); etc ... or something multi-line (array definition that occupies few lines etc) ?

0
Comment actions Permalink

Hello Andriy,

The project is based on the Symfony 1.4 platform. I uses the front controller pattern. As far as I can recall I did not set any path mappings in previous versoin of Phpstorm.

The structure of the project is very specific, so I don't know where to start setting up the paths for the plethora of classes and conventions used in the plattform.


The debug breakpoint is on a proper line, I have been hit by that issue in the past, and I make sure of where the debug points are.

0
Comment actions Permalink

Hi Fotis,

1) If you do not mind -- please try my suggestion from my previous post.
2) Please enable xdebug log (by configuring xdebug.remote_log in php.ini) & PhpStorm debugger log http://devnet.jetbrains.net/docs/DOC-1202 and attach results here -- it should give some info about which file xdebug tries to debug (in case if path mapping is actually required and is missing) and/or why that break point is not hit (but do not use breakpoints where they work & disable "break at first line" during this "experiment").

In any case -- Nikolay knows this area much better than me.

P.S.
Just some thoughts (which most likely make no sense, but still...)
When did you used debugger for this project last time (using 2.0.1 version)? Have you made any big changes since? (of course, you know much more about your own project than me, but maybe (just maybe) that breakpoint is not hit because that part of code is not actually executed -- for example, because of internal caching or something like that).

0
Comment actions Permalink

Hello Andriy,

I did try your suggestion to no avail.

I am attaching both logs here. It seems from the xdebug logs that the breakpoints are picked up, but the ide is not respoding to them.


My debugger worked for 2.0.1 version, and I haven't done anything tragic to code, I am setting the breakpoints on key locations that I know will be called throughout the application lifecycle.



Attachment(s):
idea.log.zip
xdebug.log.zip
0
Comment actions Permalink

Hi Fotis,

1) Based on idea.log I may say that the PhpStorm log does not seem to be activated (i'm not 100% sure, but I think you have missed # symbol for category name -- proper "command" should look like this:

<category name="#com.jetbrains.php.debug">
    <priority value="DEBUG"/>
</category>

But I think we can do this without this part (as xdebug log may provide enough info -- based on what I see so far)

2) Can you confirm me the project path (or paths if you have multiple protect roots) please.

From what I see the debuger is triggered for this file:
/Users/fotis/Development/workspace/pdt-ganymede-sr1/aKtel/web/frontend_dev.php

0
Comment actions Permalink

Hello,

Yes this is correct, that is the first script that it is called. If you see the xdebug logs, it does have the breakpoints in the other files of the project.

I re-attaching the logs, I missed the "g" in "debug".



Attachment(s):
xdebug.log.zip
idea.log.zip
0
Comment actions Permalink

What I'm trying to say here (when asking for the project path) is that I see different paths:

1) Debugger is triggered for
/Users/fotis/Development/workspace/pdt-ganymede-sr1/aKtel/web/frontend_dev.php

2) But breakpoints are set in:
/Users/fotis/Development/workspace/pdt/aKtel/lib/ktel/WsAccessor.class.php
/Users/fotis/Development/workspace/pdt/aKtel/apps/frontend/modules/ticketEngine/actions/actions.class.php

My point here, that this folder:
/Users/fotis/Development/workspace/pdt-ganymede-sr1/aKtel/
does not equal
/Users/fotis/Development/workspace/pdt/aKtel

The files with breakpoints could be outside the project (the actually running project) and that 2nd path is simply may not be used by PHP/Apache

0
Comment actions Permalink

Also on Mac.

I also lost debugging after I upgraded.  BUT I rebuilt the project and all is fine (why I didn't report it).  A stupid question; but have you tried that? It looks like the pathing got mixed up somehow.

A side note: I don't use MAMP. I use the 10.6 stock install. In case, that makes any differnece.

0
Comment actions Permalink

Hello Adriy,

You hit the spot with that one.

This is what was happening:

The way I have my structure setup up, I have several real paths

/Users/fotis/Development/workspace/pdt-ganymede-sr1/
/Users/fotis/Development/workspace/phpstorm/
/Users/fotis/Development/workspace/pdt-gallileo/

and so on. This helps me protect myself from having eclipse kill my workspace anytime I upgrade ( which has happened several times). I then "symlink" the directory I want to work on to

/Users/fotis/Development/workspace/pdt/



Opening the project using  "/Users/fotis/Development/workspace/pdt-ganymede-sr1/" solved the problem. But I am 99.999% sure that this worked in previous versions.

Thank you for helping me with the matter.

Best Regards,
Fotis

0
Comment actions Permalink

Andriy,

Thank you for your help!:)

0
Comment actions Permalink

Fortis,

Opening the project using  "/Users/fotis/Development/workspace/pdt-ganymede-sr1" solved the problem.

You can also open your project using "/Users/fotis/Development/workspace/pdt" as before, but you need to set up proper path mappings. See screenshot(just example):
path_mappings.png

But I am 99.999% sure that this worked in previous versions.

There were no changes in this area since 2.0.1.

Thank you for feedback!

0

Please sign in to leave a comment.