xdebug, result in variables window is removed after aprox. 30 secs

Hi.
I have been using xdebug in PhpStorm 9 with Apache 2.2 and PHP 5.4.
Now I updated to Apache 2.4, and PHP 5.6

Before I did that, the debug result remained in the Variables window, even after the session in the browser timed out.
Now it gets wiped out after about 30 seconds, and I'm having a hard time managing to finding what I need to see.

Is there any way to keep the result in memory?



Attachment(s):
debug.png
13 comments

Hi there,

Is debug session is still actually active? Please collect xdebug log.

In general 30 seconds sounds like Apache stops the PHP process (or script execution time limit was reached, maybe) -- have a look at Apache detailed log as well.

0

Hi Andriy.
Yes, there is an active connection - I get debug result, but while I look throught the variables, Apache cuts the connection, and the debug results are gone.
The debug session is still active, waiting for incomming connection.

The xdebug log gives no usable information at all, only a lon chain of nested function calls.

0

The debug session is still active, waiting for incomming connection

What do you mean by that? Are you able to step in/over after that?

The xdebug log gives no usable information at all, only a lon chain of nested function calls.

Does it says that debug session was successfully closed or what?

-----

Right now it looks like Apache settings.

0

How do you run PHP under Apache? FastCGI?

Please show your phpinfo() output + Apache config for PHP

0

It's active in that it waits for a connection.
When the results are removed, there's nothing to navigate in - it abruptly throws the connection - but still, the debug session is waiting for a connection.

In the log there's no "Trace End" information.

0

I use fastCGI.

I'm not sure what you are getting at - what are you suspecting is wrong?

0

It's active in that it waits for a connection.
When the results are removed, there's nothing to navigate in - it abruptly throws the connection - but still, the debug session is waiting for a connection.

This means that debug session has ended.

0

OK... Do you have any idea as to why it does that with the new setup? It kept the debug results before, with the old apache and php.

0

Check your Apache config for settings like FcgidIdleTimeout and/or FcgidIOTimeout

e.g. http://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgididletimeout or http://www.fastcgi.com/mod_fastcgi/docs/mod_fastcgi.html (not using Apache now myself, so cannot say what directive it is exactly)

Try increasing those values (add extra 0 at the end). if you do not have such settings set -- set up them yourself (to override default values).

0

I tried to add the parameters with no luck.
You mentioned that the session was ended when the results are removed, but it's still alive, because the Frames chain of files are still active, and I need to press Resume Program (F9) to end the session. When I do that, the Frames window are cleared too.

0
You mentioned that the session was ended when the results are removed, but it's still alive, because the Frames chain of files are still active, and I need to press Resume Program (F9) to end the session. When I do that, the Frames window are cleared too.

The way how it looks to me:

  • process (php and therefore xdebug session) was killed by Apache
  • IDE did not received any signals about ended session therefore it still looks like it's alive


"Resume Program" just tells that program can be run till next breakpoint. If you do not have more breakpoints then it will run till the end. That's why I have asked what "Step In" and "Step Over" actions do -- do they behave just like "Resume Program" or do they stop on next line?

Even if PhpStorm will be stopping debug session, the xdebug log will have "session was ended" kind of lines in the log. Accordingly to your words it has none of it hence the suspicion of the Apache's FastCGI handler that may have killed the not-sending-data process.

I've made my assumptions on your words alone since you have not provided any logs (xdebug and Apache). Especially Apache's ones -- detailed log will have "process was killed" kind of entry for sure (if it was the case, of course).

0

I went all in on settings and got it working.
The solution in my case was a combination of:

php.ini

  • max_execution_time in php.ini


httpd.conf

  • FcgidIdleTimeout
  • FcgidIOTimeout
  • IPCCommTimeout
  • IdleTimeout


Now it's working - no bugs or errors, just laid back settings :)

0

You are right, Andriy. The session was killed, and no further breakpoints could be reached.
I got it right with the settings, as you can se in my own answer at the bottom.
Everything is jolly good!

0

Please sign in to leave a comment.