Debugging only works with breakpoint on first line

My question is very similar to this question: http://devnet.jetbrains.net/thread/304553

I upgraded to 2.1.4 a week or so ago.  Since then, I cannot debug my projects.  I do not use any sym links anywhere, so that should not be the problem.  The only way I am able to successfully use the debugger is if I either check off "Break at the first line" or if I actually put a break point at the first line.

When I do either one of these, the debugger will be triggered and will be stopped at the first line.  I can continue stepping over or stepping in through the completion of the request.  However, if I just continue the script by hitting "Play" then no other break points are honored.  If I don't have a break point on the first line, then the debugger is never even triggered.

I have been extremely pleased with PHPStorm thus far, and I am going to be making a recommendation for a debugger for all of my developers in the coming weeks.  If I can figure out this issue then PHPStorm is the clear choice of the 3 debuggers we have been evaluating, but this right now is a deal breaker.

Any help is appreciated.  I can supply any logs or configuration files needed.

0
44 comments

I am seeing something similar.  It's happenned a few times lately, and now it won't stop.  I though it might also be something in Firefox 6, and I was thinking of downgrading one or both of PHPStorm or Firefox.

I've tried rebooting, clearing my cookies for the zend debugger plugin, all that stuff, nothing seems to work!

Any help would be appreciated.

m

0

I just wanted to make clear, if I break on first line, it does break, and then I have to step through everything.  Breakpoints don't do anything.  

All the local variables and all that work fine.

0

Yep, my situation is the exact same.  I am using xdebug, but the symptoms are the same.

If I either check of the "Break at the first line", or put a break point on the first line then the debugger works.  I have to step through every line to get through the entire request.  Any additional break points are not honored.  

0

I have NEVER (any version) been able to debug any other way then how you described. I thought this was the normal procedure.

0

Really, that's too bad.  Breakpoints are a great way to debug.

I downgraded to 2.1.2, and it seems to work better.  Please let me know if this is fixed in the next version, and I'll upgrade then.  This is too important a feature to miss.

m

0

Just thought I would update this issue, as I am back to debugging the way I should be.

I went through and deleted all references to PHPStorm, following these instructions (I am on a Mac):
http://devnet.jetbrains.net/docs/DOC-181

After deleting those, plus deleting the binary, I rebooted.  I reinstalled 2.1.2 (I still had the dmg in my downloads)

Set everything back up and it appears I am back up and running.  I had gone through all of these steps before, but had never rebooted in between cleaning everything up and reinstalling.

-----

I hope this helps.  I certainly won't be upgrading to 2.1.4 since this seemed to be 100% tied to my issue.

0

Looks like I spoke too soon :(

About one hour of successfully debugging, and the same thing started happening again.  Huge problem for me.  I really want to continue using this awesome debugger, but I can't make a recommendation to purchase 6 licences if this is going to continue to be an issue.

0

Hello Sean,

Sorry for delay.

Does 'break at the first line' still work for you? If no, it is a problem with Xdebug (Zend Debugger) configuration and you can find a solution here - http://confluence.jetbrains.net/display/WI/Documentation
If yes, there is a problem with path mappings.

You need to use path mappings when the paths to the files processed by the server differ from the paths to the files in the project. This happens in the following cases:

  • The server is remote and the project files are local copies of the originals.
  • The files processed by the server and the files opened in the IDE are the same, but symlinks are used. Because the debugger resolves symlinks during a debugging session, you need to tell the IDE actual absolute physical paths to the files on the server.


Please describe your project configuration.

Thank you for feedback!

0

Thanks for the response Nikolay.

The server is remote and the project files are local copies of the originals.

My code is running locally in a directory like
/Users/sberry/Sites/ClientName/trunk
The entire ClientName directory is an SVN checkout.  There are no symlinks at all in the project.  



The files processed by the server and the files opened in the IDE are the same, but symlinks are used. Because the debugger resolves symlinks during a debugging session, you need to tell the IDE actual absolute physical paths to the files on the server.
If I break on the first line either by checking of the option, or placing a break myself on the first line, the execution halts at the line and I am presented with debugging options.  From there I can step over / through the entire request, one line at a time.  If I break on the first line, and step through until I get to another file and place a breakpoint there, remove my breakpoint on the first line and re-run, I get no break.


This was all working for 2+ weeks without issue.  I then upgraded to 2.1.4 and everything stopped working.  I went through the steps listed in one of my previous posts, deleting all references, rebooting, and reinstalling 2.1.2.  Everything started to work again.  I could break on any line that was executed during the request and the debugger would honor the breaks.

I can provide additional information if necessary.
0

I'm having similar problems.  My test environment is on Windows, so I believe there are no symlinks.

m

0

Sean,

Please provide a screenshot of you PHP server configuration (Project Settings -> PHP -> Servers).

Thank you for feedback!

0

Marc,

Nothing changes in this area since 2.0 release. So it is not related to update.
Please provide your php server configuration (Project Settings -> PHP -> Servers).

Thank you for feedback!

0

Nikolay,

Please see the attached screenshot.

local.bh.atvi.2advanced.com is a local virtual host.  It's docroot is at
/Users/sberry/Sites/beachhead/trunk

There are not symlinks in the docroot, and the docroot itself is not a symlink.  The framework in use does use a front-controller where every request is rewritten via mod_rewrite to go to index.php, though I can't imagine that being part of the issue since it had worked for a couple weeks.



Attachment(s):
Screen shot 2011-09-16 at 7.36.09 AM.png
0

Sean,

Sorry for delay.

What is your project root? Is the server document root located under your project root?
You are able to debug with 'Break at the first line' option enabled and it means that debugger set up is correct.

Thank you for feedback!
0

My project root is my document root.

0

same for me.

It breaks on first line, when I use the settings (break on first line).

When I don't it sometimes breaks on top level .php file, but usually doesn't break within functions.

Also, after it first breaks on first line, or another line in top level php, and I click run (f9) it usually won't stop inside function call.

0

Sean,

Ok, suppose you enabled 'Break at the first line' mode and suspended on the first line in the scipt.
What is the color of the script editor tab? Yellow?
yellow_tab.png

Also please inspect '$_SERVER['SCRIPT_FILENAME']' variable value. Is it the same as expected(current file name)?
script_filename.png

Thank you for feedback!

0

Nikolay,

My tab does not turn yellow.  I updated to the latest 2.1.5 version yesterday or the day before.  Inspecting $_SERVER['SCRIPT_FILENAME'] yeilds the correct path and filename of the front controller (index.php) which in this case is the file I am breaking on.

0

same for me.  I am able to get it to break on a top-level php file, but not within an included file.

The tab is not yellow.

The $_SERVER['SCRIPT_FILENAME'] yields the expected result.

m

0

Sean,

Please collect debugging log - http://devnet.jetbrains.net/docs/DOC-1202

Please step into index.php and included files (using 'Step Into' after break in index.php) where breakpoints don't work

Thank you for feedback!

0

Marc,

same for me.  I am able to get it to break on a top-level php file, but not within an included file.

Do you able to step into included files after break in the top-level file?

Also please collect debugging log - http://devnet.jetbrains.net/docs/DOC-1202

Thank you for feedback!

0

Nikolay,

Attached are two logs.  In the first log I just played from the first breakpoint.

In the second, I clicked step into about 3000 times :), not sure how many times, but I held down f7 for a couple minutes.



Attachment(s):
idea2.log.zip
idea.log.zip
0

ok, let me try to make it clearer.  I created two test files (and I've manually added line numbers/
testfile.php

<?php
a1 include 'inc1.php';
a2 $x = test();
a3 print $x;
?>



inc1.php

<?php
b1: function test() {
b2:   return 2;
}
?>



testfile.php is in top-level directory.

When inc1.php is top-level directory breakpoint on line b2: "return 2" works fine from Firefox.

When I move inc1.php to INCLUDES directory and change b1 to "include 'INCLUDES/inc1.php' ", I did the following tests with breakpoints
  1. b2 - ignored
  2. a2, b2 - a2 works
    1. hit f9,f8 - b2 ignored
    2. hit f7 - goes to b2
  3. a3, b2 - b2 ignored goes right to a3


Attachment(s):
idea.log.zip
0

Hello Sean,

Sorry for delay.

Unfortunately idea.log contains only steps in index.php file and idea2.log doesn' contains any steps at all (but a huge amount of stack variables information). Please attach the full log folder.
Also could you please provide own xdebug log(http://xdebug.org/docs/remote#remote_log)? One or two steps in included files would be enough.

Thank you for feedback!

0

Hello Marc,

Looks like you don't enable logging properly (note that category_name is '#com.jetbrains.php.debug' and not 'com.jetbrains.php.debug). Please try to collect logging again.
Also please provide own xdebug log (http://xdebug.org/docs/remote#remote_log).

Thank you for feedback!

0

it was.

I've attached the log.xml



Attachment(s):
log.xml
0

Hello Marc,

Sorry for delay. You put category description into the wrong place (it is necessary to put it before opening <root> tag).
I attached the correct version.

Thank you for feedback!



Attachment(s):
log.xml
0

Sean,

Do you still have the issue?

Thank you for feedback!

0

I do still have the issue.  Unfortunately I will have to wait another day or so to get you new data.  My wife's grandmother passed away last night so I will not be available to generate the logs.  However, I will do so in a couple days.

0

Here you go



Attachment(s):
idea.log.zip
0

Please sign in to leave a comment.