[dev] Fwd: php5-xdebug should be avoided in php-horde* packages

[Michael M Slusarz]

Quoting Mathieu Parent <math.parent at gmail.com>:

> (Forwarding to the proper mailing lists).
>
> Hi Hans,
>
> This question should probably be asked upstream. I'm forwarding to them too:
> horde depends on Horde_Core
> which has optional dep on Horde_Test
> which depends on phpunit
> which depends on CodeCoverage
> which has optional dep on xdebug extension.
>
> This extension creates the below PHP fatal errors:
>
> ---------- Forwarded message ----------
> From: Hans Dingemans <hans.dingemans at tacticalops.nl>
> Date: 2013/12/14
> Subject: php5-xdebug should be avoided in php-horde* packages
> To: math.parent at gmail.com
>
>
> Hello,
>
> First of all thanks for your excellent work on the packaging of horde
> for Debain!
>
> I wanted to share something with you, in the hope others will profit
> from it in the long run; I ran into this error message, when using the
> "autocomplete" function in IMP in the "To:  field, on an extremely
> large (>200 contacts) contactlist.
>
> PHP Fatal error:  Maximum function nesting level of '100' reached,
> aborting! in /usr/share/php/Horde/Mail/Rfc822/List.php on line 382,
> referer:
>  followed by a lot of other error messages.

There is nothing wrong with the Horde code.  It is known (and desired)  
to have this kind of recursion for this particular action.  There's  
nothing to "fix" from the Horde side.  (FWIW, 100 is an artifically  
low default value that is not useful for any kind of advanced PHP  
functionality.)

Not to mention that xdebug should never be enabled on a production  
system in the first place.  So the error listed above is entirely  
harmless.  If you are running xdebug, you are both expecting fatal  
errors to be possibly thrown at some point and have implicitly  
accepted that fact.

> Also ActiveSync of one of my users, with extremely high number of
> folders to synchronize, generated similar error messages.
>
> The cause seems to be the xdebug extension, that limits the number of
> recursions to 100 in PHP.

Well, not exactly.  First: it can be easily configured to something  
else (and probably should - see above).  Second: there is NO  
requirement that this particular setting must be active (it can be 0,  
for example).  xdebug can exist and be active on a PHP server without  
function nesting checking being active.

I really hope Debian doesn't install php5-xdebug with xdebug on/active  
by default.  A developer should have to manually activate it when they  
need it, not the other way around.

> Simply purging php5-xdebug, and with it php-code-coverage,
> php-horde-test and phpunit solved the problem.
>
> To avoid people installing these modules in a production environment,
> would it perhaps be a good idea to exclude these packages from the
> "apt-get install horde" install list?

Obviously, that can only be answered by a packager.  But there is  
nothing wrong with Horde packages listing xdebug as a dependency,  
whether required or optional.

But as mentioned above, seems like the more correct solution is to  
disable xdebug from being active on installation of that package.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]