Symfony web debug toolbar segfaults PHP when debugging using xdebug

A suggestion:

Create a new environment-level parameter that makes symfony explicitly ignore xdebug even if the functions are defined. This is an acceptable workaround when debugging using an outside attached debugger like Eclipse PDT.

I don't think it has anything to do with Eclipse. I am getting the same thing just between symfony and xdebug (v2.0.2).

Here is the tail end of an xdebug trace:

1.0857 2039912 +1000 -> sfConfig::get($name = 'sf_web_debug', $default = ???) /usr/local/php5/lib/php/symfony/log/sfLogger/sfWebDebugLogger.class.php:47

>=> TRUE

1.0859 2040032 +120 -> function_exists('xdebug_get_function_stack') /usr/local/php5/lib/php/symfony/log/sfLogger/sfWebDebugLogger.class.php:54

>=> TRUE

1.0860 2039960 -72 -> xdebug_get_function_stack() /usr/local/php5/lib/php/symfony/log/sfLogger/sfWebDebugLogger.class.php:56

** SEGMENTATION FAULT HERE **

I am working around this by commenting out lines 53-75 in sfWebDebugLogger.class.php and adding "$debug_stack = array();" after line 75.

I second the suggestion made by klemen.

In symfony 1.1 r6973 I changed line 49 in lib/log/sfWebDebugLogger.class.php to the following:

if (isset($optionsxdebug_logging?) && !isset($_GETXDEBUG_SESSION_START?))

This causes the xdebug_logging option on the sfLogger instance to be set only when a XDEBUG_SESSION_START query variable is supplied. I would have accessed the sfRequest but it is not ready at that point. I'm sure there is a better way to do this but I'll leave that to any senior developers who are interested.

Jesse.

Sorry, I didn't realize that the wiki formatting would ruin the code. This is the changed line:

if (isset($options![xdebug_logging]) && !isset($_GET![XDEBUG_SESSION_START]))

Also, this causes the xdebug_logging option on the sfLogger instance to be set only when a XDEBUG_SESSION_START query variable is NOT supplied.

The fix above fails to cover the case when a request is POSTed.

Index: sfWebDebugLogger.class.php
===================================================================
--- sfWebDebugLogger.class.php  (revision 7337)
+++ sfWebDebugLogger.class.php  (working copy)
@@ -51,7 +51,9 @@

     // if we have xdebug, add some stack information
     $debug_stack = array();
-    if (function_exists('xdebug_get_function_stack'))
+    if (function_exists('xdebug_get_function_stack') &&
+       !isset($_GET['XDEBUG_SESSION_START']) &&
+       !isset($_COOKIE['XDEBUG_SESSION']))
     {
       foreach (xdebug_get_function_stack() as $i => $stack)
       {

The aggregate $_REQUEST could be used in place of $_GET or $_COOKIE. Any reason not to use it?

I'm also having the same issue, though it appears more likely that this is an issue with XDebug. It's also not 100% of the time, either, as doing a tedious step through the code reveals.

Some calls to the function appear to behave just fine. It's not random, though, and it appears that it does, in fact, always fail at the same moment. In my case, my stack was consistently:

/usr/share/pear/symfony/log/sfLogger/sfWebDebugLogger.class.php.sfWebDebugLogger->log : lineno 56	
/usr/share/pear/symfony/log/sfLogger.class.php.sfLogger->log : lineno 141	
/usr/share/pear/symfony/log/sfLogger.class.php.sfLogger->info : lineno 212	
/usr/share/pear/symfony/controller/sfRouting.class.php.sfRouting->parse : lineno 619	
/usr/share/pear/symfony/request/sfWebRequest.class.php.sfWebRequest->loadParameters : lineno 485	
/usr/share/pear/symfony/request/sfWebRequest.class.php.sfWebRequest->initialize : lineno 333	
cache/applicant/dev/config/config_factories.yml.php.require : lineno 11	
/usr/share/pear/symfony/util/sfContext.class.php.sfContext->initialize : lineno 70	
/usr/share/pear/symfony/util/sfContext.class.php.sfContext::getInstance : lineno 87	
plugins/sfTCPDFPlugin/config/config.php.include : lineno 2	
/usr/share/pear/symfony/config/sfLoader.class.php.sfLoader::loadPluginConfig : lineno 369	
/usr/share/pear/symfony/symfony.php.require : lineno 129	
/usr/share/pear/symfony/util/sfCore.class.php.sfCore::callBootstrap : lineno 56	
/usr/share/pear/symfony/util/sfCore.class.php.sfCore::bootstrap : lineno 34	
apps/applicant/config/config.php.require_once : lineno 8	
web/applicant_dev.php.{main} : lineno 8	

I could get to this exact moment every time with a condition of $message == '{sfRouting} match route [homepage] "/"' on my breakpoint (YMMV with different routing, but I'd wager it's the first routing rule checked).

In my case: PHP 5.2.4, Xdebug v2.0.2 (both installed via yum), and Symfony 1.0.11, on FC7.

The aggregate $_REQUEST could be used in place of $_GET or $_COOKIE. Any reason not to use it?

The real cause was my ignorance. But I may still prefer to use the latter as I usually stay in the camp where 'explicit is bette than implicit'.

I agree wholely that it's xdebug that needs fixing but even getting fixed version installed may be difficult in a shared hosting environment.

(In [7763]) fixed web debug toolbar segfaults PHP when debugging using xdebug (closes #2438)

in r7762

I'll open this ticket, because my Apache (and PHP) crashes when I try to debug Symfony application. I use Aptana + xdebug for debugging and there is no $_GET["XDEBUG_SESSION_START"] or $_COOKIE["XDEBUG_SESSION"] variables now. Instead of it, there is a $_SERVER["XDEBUG_CONFIG"] variable:

["XDEBUG_CONFIG"]=>
  string(35) "remote_enable=1 idekey=ECLIPSE_DBGP"

Fixes for sfVarLogger.class.php

The fix implemented in Symfony did not seem to work using Eclipse PDT (3.3) and Symfony 1.0. I still experience the same issue without fail when I initiate an xdebug session through Eclipse using xdebug < 2.0.4. Neither the xdebug GET variable or cookie is present. It presents as "canary mismatch on efree(), heap overflow" when Suhosin is installed. It has been fixed in xdebug 2.0.4 and upgrading resolves the issue.

It doesn't need fixing since it's an xdebug issue, I just hope this might help someone trying to work out the same problem.