It works normally in the same environment with XDebug 2.5.1.

I can't reproduce this - there is a bug in 2.5.2 that might relate do this, so can you please show:

php -v

and, the exact script that you use to replicate this problem.

I'm encountering the same problem. Using macOS 10.12.4 homebrew php56-xdebug, which was recently updated from 2.5.1 to 2.5.3, and any call to set_time_limit() just hangs with 100% cpu usage for 30 seconds before failing.

My test script is:
<?php
echo "before:".ini_get('max_execution_time');flush();
set_time_limit(100);
echo "after:".ini_get('max_execution_time');flush();

With Xdebug 2.5.3, this fails (when run via apache, php-cli doesn't seem to be affected)
php -v
PHP 5.6.30 (cli) (built: Mar 11 2017 11:59:19)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.5.3, Copyright (c) 2002-2017, by Derick Rethans

Output of test script via apache:
before:30
( ! ) Fatal error: Maximum execution time of 30 seconds exceeded in limit.php on line 3
Call Stack

Time Memory Function Location

1 0.0001 228688 {main}( ) .../limit.php:0
2 0.0002 228944 set_time_limit ( ) .../limit.php:3

Switching back to 2.5.1 with "brew switch php56-xdebug 2.5.1; sudo apachectl restart" and:

php -v
PHP 5.6.30 (cli) (built: Mar 11 2017 11:59:19)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.5.1, Copyright (c) 2002-2017, by Derick Rethans

Output of test script via apache:
before:30after:100

Trying to debug the apache process with 2.5.3:
cd /tmp; cp /usr/sbin/httpd httpd-debug #bypass SIP
sudo apachectl stop
sudo lldb ./httpd-debug -- -X -DFOREGROUND -DNO_DETACH
run
(load script twice via browser so that it hangs)
^C
bt all

• thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  • frame #0: 0x0000000103dd0338 xdebug.sozif_xdebug_set_time_limit + 23 frame #1: 0x00000001033b3869 libphp5.sodtrace_execute_internal + 126
    frame 0000002: 0x0000000103dcf979 xdebug.soxdebug_execute_internal + 425 frame #3: 0x000000010342b31e libphp5.sozend_do_fcall_common_helper_SPEC + 1327
    frame 0000004: 0x00000001033e9451 libphp5.soexecute_ex + 959 frame #5: 0x00000001033b37a5 libphp5.sodtrace_execute_ex + 226
    frame 0000006: 0x0000000103dcf638 xdebug.soxdebug_execute_ex + 2426 frame #7: 0x00000001033c1cd1 libphp5.sozend_execute_scripts + 491
    frame 0000008: 0x000000010336c6eb libphp5.sophp_execute_script + 746 frame #9: 0x0000000103448a83 libphp5.sophp_handler + 1251
    frame 0000010: 0x0000000100001e6f httpd-debugap_run_handler + 95 frame #11: 0x00000001000026c9 httpd-debugap_invoke_handler + 393
    frame 0000012: 0x0000000100066938 httpd-debugap_process_async_request + 2904 frame #13: 0x0000000100066a14 httpd-debugap_process_request + 36
    frame 0000014: 0x00000001000612e0 httpd-debugap_process_http_sync_connection + 240 frame #15: 0x0000000100060ecc httpd-debugap_process_http_connection + 76
    frame 0000016: 0x000000010002107f httpd-debugap_run_process_connection + 95 frame #17: 0x0000000100021855 httpd-debugap_process_connection + 101
    frame 0000018: 0x00000001000779b0 httpd-debugchild_main + 2352 frame #19: 0x00000001000766e6 httpd-debugmake_child + 198
    frame 0000020: 0x0000000100074d38 httpd-debugprefork_run + 200 frame #21: 0x0000000100024aaf httpd-debugap_run_mpm + 111
    frame 0000022: 0x000000010000f0bc httpd-debugmain + 4316 frame #23: 0x00007fffe7895235 libdyld.dylibstart + 1
    frame 0000024: 0x00007fffe7895235 libdyld.dylib`start + 1

And like the original post said, the very first page load seems to work ok, but any subsequent page load hangs.

php -v:

PHP 5.6.30 (cli) (built: Mar 21 2017 23:05:12)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.5.3, Copyright (c) 2002-2017, by Derick Rethans

The exact script:

<?php
set_time_limit(5);

The bug does not appear in cli-mode, so phpinfo could help:

PHP Version 5.6.30
System Linux fbd33545699c 4.4.59-boot2docker #1 SMP Fri Mar 31 17:24:41 UTC 2017 x86_64
Build Date Mar 21 2017 23:04:38
Configure Command './configure' '--with-config-file-path=/usr/local/etc/php' '--with-config-file-scan-dir=/usr/local/etc/php/conf.d' '--disable-cgi' '--enable-ftp' '--enable-mbstring' '--enable-mysqlnd' '--with-curl' '--with-libedit' '--with-openssl' '--with-zlib' '--enable-fpm' '--with-fpm-user=www-data' '--with-fpm-group=www-data' 'CFLAGS=-fstack-protector-strong '-fpic' '-fpie' '-O2'' 'LDFLAGS=-Wl,-O1 '-Wl,--hash-style=both' '-pie'' 'CPPFLAGS=-fstack-protector-strong '-fpic' '-fpie' '-O2''
Server API FPM/FastCGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /usr/local/etc/php
Loaded Configuration File (none)
Scan this dir for additional .ini files /usr/local/etc/php/conf.d
Additional .ini files parsed /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
PHP API 20131106
PHP Extension 20131226
Zend Extension 220131226
Zend Extension Build API220131226,NTS
PHP Extension Build API20131226,NTS
Debug Build no
Thread Safety disabled
Zend Signal Handling disabled
Zend Memory Manager enabled
Zend Multibyte Support provided by mbstring
IPv6 Support enabled
DTrace Support disabled
Registered PHP Streams https, ftps, compress.zlib, php, file, glob, data, http, ftp, phar
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters zlib., convert.iconv., string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk
Zend logo This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.5.3, Copyright (c) 2002-2017, by Derick Rethans

I can provide docker-compose.yml if it could help.

I've tried this again, with various configurations, but I still can't reproduce this. A docker compose file is likely going to be useless as it makes it nearly impossible to inject debugging tools that I would need as well. A VirtualBox image would however be very much welcome - or perhaps through Vagrant too.

It is also important to know which GCC version you've been using (gcc --version), and whether the problem still occurs without the "'CFLAGS=-fstack-protector-strong '-fpic' '-fpie' '-O2'' 'LDFLAGS=-Wl,-O1 '-Wl,--hash-style=both' '-pie'' 'CPPFLAGS=-fstack-protector-strong '-fpic' '-fpie' '-O2''" in your configure line.

I've rebuilt from https://github.com/docker-library/php/blob/master/5.6/fpm/Dockerfile with deleted export flags:

PHP Version 5.6.30
System Linux ac0ad65e2ac6 4.4.59-boot2docker #1 SMP Fri Mar 31 17:24:41 UTC 2017 x86_64
Build Date Apr 20 2017 10:49:10
Configure Command './configure' '--with-config-file-path=/usr/local/etc/php' '--with-config-file-scan-dir=/usr/local/etc/php/conf.d' '--disable-cgi' '--enable-ftp' '--enable-mbstring' '--enable-mysqlnd' '--with-curl' '--with-libedit' '--with-openssl' '--with-zlib' '--enable-fpm' '--with-fpm-user=www-data' '--with-fpm-group=www-data'
Server API FPM/FastCGI
Virtual Directory Support disabled
Configuration File (php.ini) Path /usr/local/etc/php
Loaded Configuration File (none)
Scan this dir for additional .ini files /usr/local/etc/php/conf.d
Additional .ini files parsed /usr/local/etc/php/conf.d/docker-php-ext-xdebug.ini
PHP API 20131106
PHP Extension 20131226
Zend Extension 220131226
Zend Extension Build API220131226,NTS
PHP Extension Build API20131226,NTS
Debug Build no
Thread Safety disabled
Zend Signal Handling disabled
Zend Memory Manager enabled
Zend Multibyte Support provided by mbstring
IPv6 Support enabled
DTrace Support disabled
Registered PHP Streams https, ftps, compress.zlib, php, file, glob, data, http, ftp, phar
Registered Stream Socket Transports tcp, udp, unix, udg, ssl, sslv3, tls, tlsv1.0, tlsv1.1, tlsv1.2
Registered Stream Filters zlib., convert.iconv., string.rot13, string.toupper, string.tolower, string.strip_tags, convert.*, consumed, dechunk
Zend logo This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
with Xdebug v2.5.3, Copyright (c) 2002-2017, by Derick Rethans

gcc --version:

gcc (Debian 4.9.2-10) 4.9.2

The problem still occurs.

It looks like my apache php does not have pcntl_exec despite my cli php having it, the php versions being the same, and I don't have anything in disable_functions or safe mode or anything. var_dump(function_exists("pcntl_exec")) returns false in apache and true on cli.

Looking at https://github.com/xdebug/xdebug/blob/XDEBUG_2_5_3/xdebug.c#L1295 - it does not seem like the return value of zend_hash_find is being checked for errors. Could it be that the next statements on line 1297 onwards are using the "orig" that points to set_time_limit as set in line 1286?

I created a pull request on github that seems to fix this problem in my environment. https://github.com/xdebug/xdebug/pull/341

@fm - that PR seems right, but it should be extended to the other two as well.

What is curious though is that I did use apache without pcntl_exec and couldn't reproduce this.

OK, I wasn't too sure about the others since they didn't even have the if(orig) check, and I wasn't sure if that would also cascade elsewhere for cleanup etc. I'm more comfortable leaving that to the experts, if you don't mind :) (Can you even have a PHP without "var_dump"? Maybe if it's listed in php.ini's disable_functions? I digress..)

Even if it's in disable_functions, it will have a function entry in the symbol table. Fixing this up now, but might need to push it back til tomorrow (ZzZz)

I've merged this into the master and xdebug_2_5 branches. Can everybody please check whether it works now before I roll another release?

Latest xdebug_2_5 branch on commit 4232d3cff53c0dbcb1ff3cfcb0ebb4a3f939c0e1 works fine for me here (homebrew php 5.6.30, macOS 10.12.4 x86_64, with the included system apache).

By the way, for some reason it looks like some travis tests failed on xdebug_2_5? https://travis-ci.org/xdebug/xdebug/builds/224151546

I tried running "make test" on my mac and it gave like 84 failed tests and created a file called "C:\Windows\Temp\remote-log4.txt" in the xdebug directory, on both commit 2d9cebd20b8e2eeac8c0116876b5ba76bd4d24ee and commit 4232d3cff53c0dbcb1ff3cfcb0ebb4a3f939c0e1 (i.e. before and after your "Refactor overloading functions"), perhaps the tests don't work on macOS.

There are test failures on Travis because it uses ZTS builds, which I had forgotten to test locally - that's what you get for doing this late at night!

However, tests should work fine on the mac - would you mind tar.gz-ing your tests directory and attach it here? Don't worry about the C:\Windows... file, I get that too (and it's harmless).

OK I'll try to find some time this weekend to investigate the mac test failures.

I've pushed a fix that should make travis happy now too.

@rnix, does this work for you too now?

rnix - please let me know ASAP whether this fixes your original problem, so I can make a new release.

Ok. I just need some time to build from sources.

I've built from https://github.com/xdebug/xdebug/tree/xdebug_2_5, got Xdebug v2.5.4 and the problem does not occurs. It works fine. Thank you.

Perfect. Closing this out then. I am hoping to resolve 0001335 as well, before rolling Xdebug 2.5.4 though.