View Issue Details

IDProjectCategoryView StatusLast Update
0001457XdebugUncategorizedpublic2017-07-22 08:20
Reporteralien_life_from Assigned Toderick  
PriorityhighSeveritymajorReproducibilityalways
Status resolvedResolutionduplicate 
PlatformLinuxOSCentOSOS Version6.9
Summary0001457: set_time_limit(0) hangs indefinitely
Description

For a (apache) system where the xdebug extension is installed calling set_time_limit(0) a few times hangs indenfinitely, with httpd stuck at 99 %CPU

Uninstalling the extension, the problem disappears.

System details:

OS: CentOS 6.9
apache 2.2.15
php 5.6 (webtatic RPM:php56w-5.6.30-1.w6.x86_64)
php56w-pecl-xdebug-2.5.3-1.w6.x86_64

Steps To Reproduce

Run the following script a few times (less then 4 is usually enough) through the web browser:

<?php
echo("<html><head><title>set_time test</title></head><body><h1>set_time test</h1>");
for ($i=0; $i<10; $i++) {
    error_log("Round $i");
    set_time_limit(0); echo("<p>$i</p>");
}
echo("</body></html>");

If DISPLAY_ERROS is on, the following is displayed:

// Fatal error: Maximum execution time of 30 seconds exceeded in .../_set_time.php on line 4
// Call Stack:
//   0.0007 231768 1. {main}() .../_set_time.php:0
//   0.0007 232000 2. set_time_limit() .../_set_time.php:4

30 seconds is the value of max_execution_time in php.ini. Raising it to some high value, the scripts just keeps spinning untile the HTTP request times out.

TagsNo tags attached.
Operating System
PHP Version7.1.0-7.1.4

Activities

derick

2017-07-20 14:23

administrator   ~0004372

This should be fixed in Xdebug 2.5.4 - you seem to be running an older 2.5.3.

alien_life_from

2017-07-20 15:08

reporter   ~0004373

True enough, but that's what the repo (webtatic) offers, so I have no "official" way to test that. (By the way CentOS7 - that tracks RHEL7 - is in somewhat worse shape, as fa as recent releases go, being at php-pecl-xdebug.x86_64 2.2.7-1.el7).

I will try to see if pinging the repo maintainers works (they go no higher than 2.5.3 across all php versions). Fact is, the bug is quite stealthy: you do not need to activate the extension to trigger it, just installing the RPM is enough to cause extended breakage in all kind of applications. I ran across this while investigating misbehaviors in moodle on a machine where xdebug had been installed weeks ago for unrelated purposes, then let around disabled 'just in case'.

derick

2017-07-22 08:20

administrator   ~0004375

Just installing the Xdebug extension shouldn't trigger this, but enabling them in php.ini or similar would. I am marking this as a duplicate, as this is fixed in a later version.

Issue History

Date Modified Username Field Change
2017-07-20 13:58 alien_life_from New Issue
2017-07-20 14:23 derick Note Added: 0004372
2017-07-20 14:23 derick Assigned To => derick
2017-07-20 14:23 derick Status new => feedback
2017-07-20 15:08 alien_life_from Note Added: 0004373
2017-07-20 15:08 alien_life_from Status feedback => assigned
2017-07-22 08:20 derick Note Added: 0004375
2017-07-22 08:20 derick Status assigned => resolved
2017-07-22 08:20 derick Resolution open => duplicate
2020-03-12 16:35 derick Category Usage problems (Wrong Results) => Variable Display
2020-03-12 16:38 derick Category Variable Display => Uncategorized