Getting Error in Xdebug

Xdebug stopped working, where do I look for errors?

At the end, left with only two solutions - to reinstall the Ubuntu OS or to install a new VM especially for xdebug, I'm going for the second one.
Funny thing is, everything was working according to the "RTM" (f=freaking). One thing that I couldn't figure out is how to read the logs for XDebug in order to understand where the real problem is.

UPDATE

After some struggling, I deleted every single line related to xdebug from every php.ini that I had. And moved these lines to /etc/php5/conf.d/xdebug.ini. Restarted Apache, and then PHPStorm, and it works.
P.S. in the middle, I tried to install xdebug with pecl, from github, and the standard Ubuntu version. I think the one that I compiled is currently working. And.. the log gets updated as well.

;xdebug configuration
zend_extension = /usr/lib/php5/20090626/xdebug.so
xdebug.remote_host = 127.0.0.1
xdebug.remote_enable = 1
xdebug.remote_port = 9000
xdebug.remote_handler = dbgp
xdebug.remote_mode = req
xdebug.profiler_enable=0
xdebug.profiler_enable_trigger=1
xdebug.remote_autostart=1
xdebug.idekey=PHPSTORM
xdebug.remote_log="/tmp/xdebug.log"

Visual Studio, PHP, Xdebug: Error evaluating code while debugging

The base64 decode of that string results in:

eval("try { return  1 + 1; }catch (Throwable $t){ return new DevsenseEvalError($t->getMessage());}catch (Exception $e){ return new DevsenseEvalError($e->getMessage());}");

Which can't really work, as you haven't escaped the $t in catch (Throwable $t) for example, and that throws a warning and a parse error when you run this with normal PHP:

Warning: Undefined variable $t in /tmp/foo.php on line 2

Warning: Undefined variable $t in /tmp/foo.php on line 2

Warning: Attempt to read property "getMessage" on null in /tmp/foo.php on line 2

Warning: Undefined variable $e in /tmp/foo.php on line 2

Warning: Undefined variable $e in /tmp/foo.php on line 2

Warning: Attempt to read property "getMessage" on null in /tmp/foo.php on line 2

Parse error: syntax error, unexpected token ")" in /tmp/foo.php(2) : eval()'d code on line 1

It seems likely that Devsense (I don't know what that is) is throwing a spanner in the works, as it literally just should send MSsx (base 64 encoded form of 1+1).

Xdebug 3 not included in phpinfo()

The error that you will get when develop is not part of the xdebug.mode setting is:

Warning: Function must be enabled in php.ini by setting 'xdebug.mode' to 'develop'

As you get the "Call to undefined function" error, that means that Xdebug is not loaded in your web server environment. It is often that the web server environment has a different INI file.

In order to see if Xdebug is loaded, and which INI files PHP has read, you can use use phpinfo() in a PHP script requested through a browser. This will also show whether Xdebug is loaded. If it does, you can use xdebug_info() to check its settings.

PhpStorm's "Interpreter Check" also only checks the command line, and not the web server version of PHP.

Xdebug Error: Failed loading xdebug.so: xdebug.so: cannot open shared object file: No such file or directory

Even though you have the two sites split up and using two different php.ini files, CRON will still use whichever php.ini file the PHP-CLI is configured to use. So, to figure out which php.ini CRON is using, this is the command to use:

php -i | grep php.ini

If PHP-CLI happens to be using a php.ini file that you didn't expect it to be using (such as /usr/local/lib/php.ini) then that will be the key to figuring out why you're seeing Xdebug errors in the logs.

It turns out that the /usr/local/lib/php.ini file had these two values set:

extension_dir = "/usr/local/lib/php/extensions/no-debug-non-zts-20090626"
zend_extension = "xdebug.so"

That was causing the error from the php script that was run by CRON (i.e. PHP-CLI) because zend_extensions need the full path to the module. This is also stated in the Xdebug documentation: http://xdebug.org/docs/install

So, to get rid of the error, just comment out that line (or just remove it). You could also comment out or remove the extension_dir line as long as you are not loading any other modules such as:

extension = memcached.so 

---

Related Topics