[PHP-BUG] Bug #63766 [NEW]: sftp upload CURLOPT_URL errors with code 79 with directory path
From: mattsch at gmail dot com Operating system: Gentoo PHP version: 5.4.9 Package: cURL related Bug Type: Bug Bug description:sftp upload CURLOPT_URL errors with code 79 with directory path Description: When specifying a url in CURLOPT_URL with a directory path only using the sftp protocol, the upload will always fail with error code 79 (An unspecified error occurred during the SSH session). If you change the CURLOPT_URL to be the same path but add a filename at the end of the directory path, the upload will succeed. emerge -pv php:5.4 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] dev-lang/php-5.4.9:5.4 USE="apache2 bcmath bzip2 calendar cjk cli crypt ctype curl curlwrappers exif fileinfo filter ftp gd gdbm gmp hash iconv ipv6 json ldap mhash mysql mysqli mysqlnd nls pcntl pdo phar posix readline session simplexml snmp soap sockets spell sqlite ssl sysvipc threads tidy tokenizer truetype unicode wddx xml xmlwriter xpm xsl zip zlib -berkdb -cdb -cgi -debug -doc -embed -enchant -firebird -flatfile -fpm (-frontbase) -imap -inifile -intl -iodbc -kerberos (-kolab) -ldap-sasl -libedit -mssql -oci8-instant-client -odbc -pic -postgres -qdbm -recode (-selinux) -sharedmem (-sybase-ct) -xmlreader -xmlrpc" 0 kB emerge -pv curl These are the packages that would be merged, in order: Calculating dependencies e - ... done! [ebuild R ~] net-misc/curl-7.28.1 USE="idn ipv6 nonblocking ssh ssl threads -adns -kerberos -ldap -metalink -rtmp -static-libs {-test}" CURL_SSL="openssl -axtls -cyassl -gnutls -nss -polarssl" 0 kB emerge -pv libssh2 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ~] net-libs/libssh2-1.4.3 USE="zlib -gcrypt -static-libs {-test}" 0 kB curl -V curl 7.28.1 (x86_64-pc-linux-gnu) libcurl/7.28.1 OpenSSL/1.0.0j zlib/1.2.7 libidn/1.25 libssh2/1.4.3 Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp Features: AsynchDNS IDN IPv6 Largefile NTLM NTLM_WB SSL libz Test script: --- ftp://domain.tld:/tmp'); // prints 0 upload('sftp://domain.tld:/tmp/foo'); Expected result: 0 0 Actual result: -- 79 0 -- Edit bug report at https://bugs.php.net/bug.php?id=63766&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63766&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63766&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63766&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63766&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63766&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63766&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63766&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63766&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63766&r=support Expected behavior: https://bugs.php.net/fix.php?id=63766&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63766&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63766&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63766&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63766&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63766&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63766&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63766&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63766&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63766&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63766&r=mysqlcfg
Bug #63741 [PATCH]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Patch added by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452419 URL: https://bugs.php.net/patch-display.php?bug=63741&patch=bug63741.patch&revision=1355452419 Previous Comments: [2012-12-13 08:19:16] larue...@php.net however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- >called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 [2012-12-13 02:49:53] larue...@php.net unfortunately, I can not reproduce it. instead I got a FATAL ERROR: can not redeclare function main The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1
Bug #63741 [PATCH]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Patch added by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452420 URL: https://bugs.php.net/patch-display.php?bug=63741&patch=bug63741.patch&revision=1355452420 Previous Comments: [2012-12-14 02:33:39] larue...@php.net The following patch has been added/updated: Patch Name: bug63741.patch Revision: 1355452419 URL: https://bugs.php.net/patch-display.php?bug=63741&patch=bug63741.patch&revision=1355452419 [2012-12-13 08:19:16] larue...@php.net however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- >called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1
Req #63758 [Opn->Nab]: strftime for %x returns wrong format in Dutch
Edit report at https://bugs.php.net/bug.php?id=63758&edit=1 ID: 63758 Updated by: ahar...@php.net Reported by:giso at connectholland dot nl Summary:strftime for %x returns wrong format in Dutch -Status: Open +Status: Not a bug Type: Feature/Change Request -Package:I18N and L10N related +Package:Date/time related Operating System: Linux / Debian PHP Version:Irrelevant Block user comment: N Private report: N New Comment: strftime() uses the system's locale information â PHP itself doesn't handle the localisation in this case. I'd suggest reporting a bug on the Debian bug tracker against the relevant package (locales, I think, but you might want to check). Previous Comments: [2012-12-13 10:24:16] giso at connectholland dot nl Description: The format outputted in Dutch for %x is "dd-mm-yy" while it should be "dd-mm- " I'm from the Netherlands and can assure you nobody writes or uses dates like "dd- mm-yy" Test script: --- setlocale(LC_TIME, "nl_NL"); echo strftime("%x"); Expected result: 13-12-2012 Actual result: -- 13-12-12 -- Edit this bug report at https://bugs.php.net/bug.php?id=63758&edit=1
Bug #63379 [Com]: Warning when using session_regenerate_id(TRUE) with a SessionHandler
Edit report at https://bugs.php.net/bug.php?id=63379&edit=1 ID: 63379 Comment by: ar...@php.net Reported by:avatar2004-php at yahoo dot fr Summary:Warning when using session_regenerate_id(TRUE) with a SessionHandler Status: Closed Type: Bug Package:Session related Operating System: Gentoo PHP Version:5.4.8 Assigned To:arpad Block user comment: N Private report: N New Comment: Laruence you were correct, the reset wasn't necessary :) avatar2004, the flag is only meant to keep the parent session handler in a sane state. If a user implementation calls the parent handler in close() but not in open(), we need to be able to prevent the close() call on the parent handler even though session_status tells us that the session is open. The flag is a global because having more than one session handler instance active in the same request is nonsensical. Previous Comments: [2012-12-14 00:07:34] ar...@php.net Automatic comment on behalf of array...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=6566ea61732a1ab42c1a57e60adc96788cb0feb2 Log: Fix #63379 - Don't reset mod_user_is_open in destroy [2012-10-29 04:21:47] avatar2004-php at yahoo dot fr Looking at the code, it feels like the very semantics of the mod_user_is_open flag are not exactly consistent. The flag is a global, yet it is manipulated by instance code. Meaning if the user space code uses several handlers interchangeably, the result can quickly become confusing. I suggest a decision should be made as to whether the SessionHandler is a stateless, thin wrapper for the handler calls in which case it should default to the same checks as the procedural API. Otherwise, the flag should really be an instance variable used to track the proper invocation sequence of the different callbacks and make sure THIS handler is open before calling dependent routines. Adding an instance variable to the (base) class though is probably not worth it. The session management semantics are already defined by the procedural API which uses a global session state flag (session_status). If required for a handler implementation, the flag can simply be implemented in user space. Just my 2c. [2012-10-29 03:07:41] larue...@php.net I mean, maybe only reset it in close handler? [2012-10-29 03:07:08] larue...@php.net is the reseting of user_is_open necessary? diff --git a/ext/session/mod_user_class.c b/ext/session/mod_user_class.c index 70d2f40..4edac28 100644 --- a/ext/session/mod_user_class.c +++ b/ext/session/mod_user_class.c @@ -121,7 +121,6 @@ PHP_METHOD(SessionHandler, destroy) return; } - PS(mod_user_is_open) = 0; RETVAL_BOOL(SUCCESS == PS(default_mod)->s_destroy(&PS(mod_data), key TSRMLS_CC)); } /* }}} */ [2012-10-29 01:14:11] avatar2004-php at yahoo dot fr If I understand correctly and "mod_user_is_open" is just a global state parameter used by the SessionHandler instance, I was wondering why the check wasn't being done on "session_status" instead to conform with the rest of the session_* API ? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63379 -- Edit this bug report at https://bugs.php.net/bug.php?id=63379&edit=1
Bug #63379 [Asn->Csd]: Warning when using session_regenerate_id(TRUE) with a SessionHandler
Edit report at https://bugs.php.net/bug.php?id=63379&edit=1 ID: 63379 Updated by: ar...@php.net Reported by:avatar2004-php at yahoo dot fr Summary:Warning when using session_regenerate_id(TRUE) with a SessionHandler -Status: Assigned +Status: Closed Type: Bug Package:Session related Operating System: Gentoo PHP Version:5.4.8 Assigned To:arpad Block user comment: N Private report: N New Comment: Automatic comment on behalf of array...@gmail.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=6566ea61732a1ab42c1a57e60adc96788cb0feb2 Log: Fix #63379 - Don't reset mod_user_is_open in destroy Previous Comments: [2012-10-29 04:21:47] avatar2004-php at yahoo dot fr Looking at the code, it feels like the very semantics of the mod_user_is_open flag are not exactly consistent. The flag is a global, yet it is manipulated by instance code. Meaning if the user space code uses several handlers interchangeably, the result can quickly become confusing. I suggest a decision should be made as to whether the SessionHandler is a stateless, thin wrapper for the handler calls in which case it should default to the same checks as the procedural API. Otherwise, the flag should really be an instance variable used to track the proper invocation sequence of the different callbacks and make sure THIS handler is open before calling dependent routines. Adding an instance variable to the (base) class though is probably not worth it. The session management semantics are already defined by the procedural API which uses a global session state flag (session_status). If required for a handler implementation, the flag can simply be implemented in user space. Just my 2c. [2012-10-29 03:07:41] larue...@php.net I mean, maybe only reset it in close handler? [2012-10-29 03:07:08] larue...@php.net is the reseting of user_is_open necessary? diff --git a/ext/session/mod_user_class.c b/ext/session/mod_user_class.c index 70d2f40..4edac28 100644 --- a/ext/session/mod_user_class.c +++ b/ext/session/mod_user_class.c @@ -121,7 +121,6 @@ PHP_METHOD(SessionHandler, destroy) return; } - PS(mod_user_is_open) = 0; RETVAL_BOOL(SUCCESS == PS(default_mod)->s_destroy(&PS(mod_data), key TSRMLS_CC)); } /* }}} */ [2012-10-29 01:14:11] avatar2004-php at yahoo dot fr If I understand correctly and "mod_user_is_open" is just a global state parameter used by the SessionHandler instance, I was wondering why the check wasn't being done on "session_status" instead to conform with the rest of the session_* API ? [2012-10-29 01:04:34] avatar2004-php at yahoo dot fr Description: It seems there's an issue with the SessionHandler implementation and the way the destroy handler is invoked when using session_regenerate_id(TRUE) The problem seems to come from using the global "mod_user_is_open" in the PS_SANITY_CHECK_IS_OPEN macro (in ext/session/mod_user_class.c). The test script generates an undue warning: Test script: --- $handler = new SessionHandler(); session_set_save_handler($handler, TRUE); // or FALSE, doesn't matter session_start(); session_regenerate_id(TRUE); //session_write_close(); Expected result: No warning Actual result: -- PHP Warning: Unknown: Parent session handler is not open in Unknown on line 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=63379&edit=1
Bug #63762 [Csd]: Sigsegv when Exception::$trace is changed by user
Edit report at https://bugs.php.net/bug.php?id=63762&edit=1 ID: 63762 Updated by: johan...@php.net Reported by:bugs dot php dot net at majkl578 dot cz Summary:Sigsegv when Exception::$trace is changed by user Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.9 -Assigned To: +Assigned To:johannes Block user comment: N Private report: N New Comment: I've fixed this by adding some type checks. In general be aware that we can't fully protect you from shooting in your own foot ... Previous Comments: [2012-12-13 21:49:55] johan...@php.net Automatic comment on behalf of johannes Revision: http://git.php.net/?p=php-src.git;a=commit;h=a11606b18fd20be1048a858eb5011fb7117855a9 Log: Fix Bug #63762 Sigsegv when Exception::$trace is changed by user [2012-12-13 20:31:35] bugs dot php dot net at majkl578 dot cz Description: Segmentation fault occurs when calling Exception::getTraceAsString() after Exception::$trace has been changed by reflection to a value PHP doesn't understand. Test script: --- $e = new Exception(); $ref = new ReflectionProperty($e, 'trace'); $ref->setAccessible(TRUE); $ref->setValue($e, array(NULL)); var_dump($e->getTraceAsString()); Expected result: an error / trace converted using "fallback" mode (e.g. var_dump) / nothing Actual result: -- SIGSEGV backtrace: #0 0x00a20c30 in _zend_is_inconsistent (ht=0x0, file=0x10792f8 "/data/build/php/5.4/php-5.4.9/Zend/zend_hash.c", line=919) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:54 #1 0x00a237cc in zend_hash_find (ht=0x0, arKey=0x107c10d "file", nKeyLength=5, pData=0x7fffa558) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:919 #2 0x00a32fcc in _build_trace_string (frame=0x77fb4330, num_args=3, args=0x7fffa5f8, hash_key=0x7fffa5e0) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:472 #3 0x00a231ac in zend_hash_apply_with_arguments (ht=0x77fb41e0, apply_func=0xa32daa <_build_trace_string>, num_args=3) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:772 #4 0x00a335e4 in zim_exception_getTraceAsString (ht=0, return_value=0x77fb43b8, return_value_ptr=0x0, this_ptr=0x77fb27e8, return_value_used=1) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:515 #5 0x00a4f4c7 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:642 #6 0x00a50370 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:752 #7 0x00a4de96 in execute (op_array=0x77fb3680) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:410 #8 0x00a118c1 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/build/php/5.4/php-5.4.9/Zend/zend.c:1309 #9 0x00988cb0 in php_execute_script (primary_file=0x7fffdfd0) at /data/build/php/5.4/php-5.4.9/main/main.c:2482 #10 0x00b57db2 in do_cli (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:988 #11 0x00b58d6d in main (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:1364 -- Edit this bug report at https://bugs.php.net/bug.php?id=63762&edit=1
Bug #63762 [Opn->Csd]: Sigsegv when Exception::$trace is changed by user
Edit report at https://bugs.php.net/bug.php?id=63762&edit=1 ID: 63762 Updated by: johan...@php.net Reported by:bugs dot php dot net at majkl578 dot cz Summary:Sigsegv when Exception::$trace is changed by user -Status: Open +Status: Closed Type: Bug Package:Reproducible crash Operating System: Linux PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Automatic comment on behalf of johannes Revision: http://git.php.net/?p=php-src.git;a=commit;h=a11606b18fd20be1048a858eb5011fb7117855a9 Log: Fix Bug #63762 Sigsegv when Exception::$trace is changed by user Previous Comments: [2012-12-13 20:31:35] bugs dot php dot net at majkl578 dot cz Description: Segmentation fault occurs when calling Exception::getTraceAsString() after Exception::$trace has been changed by reflection to a value PHP doesn't understand. Test script: --- $e = new Exception(); $ref = new ReflectionProperty($e, 'trace'); $ref->setAccessible(TRUE); $ref->setValue($e, array(NULL)); var_dump($e->getTraceAsString()); Expected result: an error / trace converted using "fallback" mode (e.g. var_dump) / nothing Actual result: -- SIGSEGV backtrace: #0 0x00a20c30 in _zend_is_inconsistent (ht=0x0, file=0x10792f8 "/data/build/php/5.4/php-5.4.9/Zend/zend_hash.c", line=919) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:54 #1 0x00a237cc in zend_hash_find (ht=0x0, arKey=0x107c10d "file", nKeyLength=5, pData=0x7fffa558) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:919 #2 0x00a32fcc in _build_trace_string (frame=0x77fb4330, num_args=3, args=0x7fffa5f8, hash_key=0x7fffa5e0) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:472 #3 0x00a231ac in zend_hash_apply_with_arguments (ht=0x77fb41e0, apply_func=0xa32daa <_build_trace_string>, num_args=3) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:772 #4 0x00a335e4 in zim_exception_getTraceAsString (ht=0, return_value=0x77fb43b8, return_value_ptr=0x0, this_ptr=0x77fb27e8, return_value_used=1) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:515 #5 0x00a4f4c7 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:642 #6 0x00a50370 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:752 #7 0x00a4de96 in execute (op_array=0x77fb3680) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:410 #8 0x00a118c1 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/build/php/5.4/php-5.4.9/Zend/zend.c:1309 #9 0x00988cb0 in php_execute_script (primary_file=0x7fffdfd0) at /data/build/php/5.4/php-5.4.9/main/main.c:2482 #10 0x00b57db2 in do_cli (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:988 #11 0x00b58d6d in main (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:1364 -- Edit this bug report at https://bugs.php.net/bug.php?id=63762&edit=1
[PHP-BUG] Bug #63763 [NEW]: Installer provides incorrect ICU DLL versions
From: chi-yu at web dot de Operating system: Windows 7, Service Pack 1 PHP version: 5.3.19 Package: Windows Installer Bug Type: Bug Bug description:Installer provides incorrect ICU DLL versions Description: I just downloaded the installer version labeled with "VC9 x86 Non Thread Safe (2012-Nov-21 22:03:42)" and tried to install the INTL extension provided with the installer. The installer apparently provides the ICU DLLs for release 4.6 but when trying to run php.exe on the command line, an error message pops ups saying that the ICU DLLs for release 4.9 are missing. Manually downloading the 4.9 DLLs from http://site.icu-project.org/download/49 and putting them into the PHP install directory appears to fix the problem. -- Edit bug report at https://bugs.php.net/bug.php?id=63763&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63763&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63763&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63763&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63763&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63763&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63763&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63763&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63763&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63763&r=support Expected behavior: https://bugs.php.net/fix.php?id=63763&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63763&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63763&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63763&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63763&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63763&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63763&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63763&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63763&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63763&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63763&r=mysqlcfg
[PHP-BUG] Bug #63762 [NEW]: Sigsegv when Exception::$trace is changed by user
From: bugs dot php dot net at majkl578 dot cz Operating system: Linux PHP version: 5.4.9 Package: Reproducible crash Bug Type: Bug Bug description:Sigsegv when Exception::$trace is changed by user Description: Segmentation fault occurs when calling Exception::getTraceAsString() after Exception::$trace has been changed by reflection to a value PHP doesn't understand. Test script: --- $e = new Exception(); $ref = new ReflectionProperty($e, 'trace'); $ref->setAccessible(TRUE); $ref->setValue($e, array(NULL)); var_dump($e->getTraceAsString()); Expected result: an error / trace converted using "fallback" mode (e.g. var_dump) / nothing Actual result: -- SIGSEGV backtrace: #0 0x00a20c30 in _zend_is_inconsistent (ht=0x0, file=0x10792f8 "/data/build/php/5.4/php-5.4.9/Zend/zend_hash.c", line=919) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:54 #1 0x00a237cc in zend_hash_find (ht=0x0, arKey=0x107c10d "file", nKeyLength=5, pData=0x7fffa558) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:919 #2 0x00a32fcc in _build_trace_string (frame=0x77fb4330, num_args=3, args=0x7fffa5f8, hash_key=0x7fffa5e0) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:472 #3 0x00a231ac in zend_hash_apply_with_arguments (ht=0x77fb41e0, apply_func=0xa32daa <_build_trace_string>, num_args=3) at /data/build/php/5.4/php-5.4.9/Zend/zend_hash.c:772 #4 0x00a335e4 in zim_exception_getTraceAsString (ht=0, return_value=0x77fb43b8, return_value_ptr=0x0, this_ptr=0x77fb27e8, return_value_used=1) at /data/build/php/5.4/php-5.4.9/Zend/zend_exceptions.c:515 #5 0x00a4f4c7 in zend_do_fcall_common_helper_SPEC (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:642 #6 0x00a50370 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER (execute_data=0x77f7c0e8) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:752 #7 0x00a4de96 in execute (op_array=0x77fb3680) at /data/build/php/5.4/php-5.4.9/Zend/zend_vm_execute.h:410 #8 0x00a118c1 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /data/build/php/5.4/php-5.4.9/Zend/zend.c:1309 #9 0x00988cb0 in php_execute_script (primary_file=0x7fffdfd0) at /data/build/php/5.4/php-5.4.9/main/main.c:2482 #10 0x00b57db2 in do_cli (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:988 #11 0x00b58d6d in main (argc=2, argv=0x7fffe378) at /data/build/php/5.4/php-5.4.9/sapi/cli/php_cli.c:1364 -- Edit bug report at https://bugs.php.net/bug.php?id=63762&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63762&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63762&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63762&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63762&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63762&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63762&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63762&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63762&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63762&r=support Expected behavior: https://bugs.php.net/fix.php?id=63762&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63762&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63762&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63762&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63762&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63762&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63762&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63762&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63762&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63762&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63762&r=mysqlcfg
Bug #60790 [Com]: "curl_multi_select" executed first time always one second
Edit report at https://bugs.php.net/bug.php?id=60790&edit=1 ID: 60790 Comment by: leonchuk at gmail dot com Reported by:leonchuk at gmail dot com Summary:"curl_multi_select" executed first time always one second Status: Feedback Type: Bug Package:cURL related Operating System: windows (XP,7) PHP Version:5.3.9 Assigned To:pierrick Block user comment: N Private report: N New Comment: Thanks pierrick, marfil for answers. But, your codes still dont work:( I found the answer by putting the following code: ... while ($mrc == CURLM_CALL_MULTI_PERFORM); #fix if(strtoupper(substr(PHP_OS,0,3)) === 'WIN'){ curl_multi_select($this->m_handle, 0.005); curl_multi_exec($this->m_handle, $active); } ... Previous Comments: [2012-12-13 16:43:05] cristian dot marfil at gmail dot com Works for me! // jlcooke - thanks to http://technosophos.com/content/connection-sharing-curl- php-how-re-use-http-connections-knock-70-rest-network-time // https://forums.aws.amazon.com/thread.jspa?messageID=397448 class RequestCore { public static $curl_multi_handle = null; public static function curlExecUsingMulti($curl_handle) { set_time_limit(1); //Test // Create a multi if necessary. if (empty(RequestCore::$curl_multi_handle)) { RequestCore::$curl_multi_handle = curl_multi_init(); } // Add the handle to be processed. curl_multi_add_handle(RequestCore::$curl_multi_handle, $curl_handle); // Do all the processing. $active = NULL; do { $ret = curl_multi_exec(RequestCore::$curl_multi_handle, $active); } while ($ret == CURLM_CALL_MULTI_PERFORM); while ($active && $ret == CURLM_OK) { //FIX https://bugs.php.net/bug.php?id=60790&edit=1 by pierr...@php.net if (curl_multi_select(RequestCore::$curl_multi_handle) == -1) { usleep(100); } //if (curl_multi_select(RequestCore::$curl_multi_handle) != -1) { do { $mrc = curl_multi_exec(RequestCore::$curl_multi_handle, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); //} } // Remove the handle from the multi processor. curl_multi_remove_handle(RequestCore::$curl_multi_handle, $curl_handle); return curl_multi_getcontent($curl_handle); } } [2012-09-22 13:34:53] pierr...@php.net This behavior is probably related to Bug #61141. Can you try this script $ch1 = curl_init(); curl_setopt_array($ch1, array(CURLOPT_URL=>"http://lxr.php.net/";, CURLOPT_HEADER=>0, CURLOPT_RETURNTRANSFER=>1)); $mh = curl_multi_init(); curl_multi_add_handle($mh,$ch1); $active = null; do $mrc = curl_multi_exec($mh, $active); while ($mrc == CURLM_CALL_MULTI_PERFORM); $start_time = microtime(true); while ($active && $mrc == CURLM_OK) { if (curl_multi_select($mh) == -1) { usleep(100); } do $mrc = curl_multi_exec($mh, $active); while ($mrc == CURLM_CALL_MULTI_PERFORM); } curl_multi_remove_handle($mh, $ch1); curl_multi_close($mh); And let me know if you still have your problem ? [2012-04-03 16:27:11] bompus at gmail dot com Possibly related to 61141 and 61240 [2012-03-24 07:28:59] qiwei dot mo at gmail dot com I have the same problem white them. Env: win7 + php5.4.0 Use the code as curl_multi-exec http://cn2.php.net/manual/zh/function.curl-multi-exec.php cause the final error: Fatal error: Maximum execution time of 30 seconds exceeded. But it be runing well in php5.3.6 In PHP5.4 , when i replace the under code --- $active = null; // æ§è¡æ¹å¤çå¥æ do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); while ($active && $mrc == CURLM_OK) { if (curl_multi_select($mh) != -1) { do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); } } -- With do { curl_multi_exec($hMultiCurl, $iRunning); } while ($iRunning > 0); - the programe run ok So the question is the curl_multi_select bug , cause the while infinite loop. [2012-02-28 17:04:37] bompus at gmail dot com I've noticed this as well. The function should return as soon as it is finished I believe. This could be a CURL issue or a PHP issue. I'm interested to hear wha
Bug #60790 [Com]: "curl_multi_select" executed first time always one second
Edit report at https://bugs.php.net/bug.php?id=60790&edit=1 ID: 60790 Comment by: cristian dot marfil at gmail dot com Reported by:leonchuk at gmail dot com Summary:"curl_multi_select" executed first time always one second Status: Feedback Type: Bug Package:cURL related Operating System: windows (XP,7) PHP Version:5.3.9 Assigned To:pierrick Block user comment: N Private report: N New Comment: Works for me! // jlcooke - thanks to http://technosophos.com/content/connection-sharing-curl- php-how-re-use-http-connections-knock-70-rest-network-time // https://forums.aws.amazon.com/thread.jspa?messageID=397448 class RequestCore { public static $curl_multi_handle = null; public static function curlExecUsingMulti($curl_handle) { set_time_limit(1); //Test // Create a multi if necessary. if (empty(RequestCore::$curl_multi_handle)) { RequestCore::$curl_multi_handle = curl_multi_init(); } // Add the handle to be processed. curl_multi_add_handle(RequestCore::$curl_multi_handle, $curl_handle); // Do all the processing. $active = NULL; do { $ret = curl_multi_exec(RequestCore::$curl_multi_handle, $active); } while ($ret == CURLM_CALL_MULTI_PERFORM); while ($active && $ret == CURLM_OK) { //FIX https://bugs.php.net/bug.php?id=60790&edit=1 by pierr...@php.net if (curl_multi_select(RequestCore::$curl_multi_handle) == -1) { usleep(100); } //if (curl_multi_select(RequestCore::$curl_multi_handle) != -1) { do { $mrc = curl_multi_exec(RequestCore::$curl_multi_handle, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); //} } // Remove the handle from the multi processor. curl_multi_remove_handle(RequestCore::$curl_multi_handle, $curl_handle); return curl_multi_getcontent($curl_handle); } } Previous Comments: [2012-09-22 13:34:53] pierr...@php.net This behavior is probably related to Bug #61141. Can you try this script $ch1 = curl_init(); curl_setopt_array($ch1, array(CURLOPT_URL=>"http://lxr.php.net/";, CURLOPT_HEADER=>0, CURLOPT_RETURNTRANSFER=>1)); $mh = curl_multi_init(); curl_multi_add_handle($mh,$ch1); $active = null; do $mrc = curl_multi_exec($mh, $active); while ($mrc == CURLM_CALL_MULTI_PERFORM); $start_time = microtime(true); while ($active && $mrc == CURLM_OK) { if (curl_multi_select($mh) == -1) { usleep(100); } do $mrc = curl_multi_exec($mh, $active); while ($mrc == CURLM_CALL_MULTI_PERFORM); } curl_multi_remove_handle($mh, $ch1); curl_multi_close($mh); And let me know if you still have your problem ? [2012-04-03 16:27:11] bompus at gmail dot com Possibly related to 61141 and 61240 [2012-03-24 07:28:59] qiwei dot mo at gmail dot com I have the same problem white them. Env: win7 + php5.4.0 Use the code as curl_multi-exec http://cn2.php.net/manual/zh/function.curl-multi-exec.php cause the final error: Fatal error: Maximum execution time of 30 seconds exceeded. But it be runing well in php5.3.6 In PHP5.4 , when i replace the under code --- $active = null; // æ§è¡æ¹å¤çå¥æ do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); while ($active && $mrc == CURLM_OK) { if (curl_multi_select($mh) != -1) { do { $mrc = curl_multi_exec($mh, $active); } while ($mrc == CURLM_CALL_MULTI_PERFORM); } } -- With do { curl_multi_exec($hMultiCurl, $iRunning); } while ($iRunning > 0); - the programe run ok So the question is the curl_multi_select bug , cause the while infinite loop. [2012-02-28 17:04:37] bompus at gmail dot com I've noticed this as well. The function should return as soon as it is finished I believe. This could be a CURL issue or a PHP issue. I'm interested to hear what the dev's say since I've had all kinds of issues with curl_multi_select in newer PHP versions. I keep having to revert to 5.3.6.. I've tried 5.3.10 and using curl_multi_select within a loop checking for != -1 and it causes an infinite loop since it always returns -1 on Windows 7 x64/x86, PHP 5.3.10 [2012-01-18 13:18:08] leonchuk at gmail dot com Descripti
Bug #48539 [Com]: pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)"
Edit report at https://bugs.php.net/bug.php?id=48539&edit=1 ID: 48539 Comment by: wdmeldon at gmail dot com Reported by:frase at cs dot wisc dot edu Summary:pdo_dblib fails to connect, throws empty PDOException "SQLSTATE[] (null)" Status: Closed Type: Bug Package:PDO related Operating System: * PHP Version:5.2.10, 5.3.0RC4 Assigned To:felipe Block user comment: N Private report: N New Comment: I've tested this in 5.3.19 and was not able to replicate. Previous Comments: [2012-07-13 13:10:20] snowcorenet at gmail dot com Could anyone tell me, please, if this is fixed in php 5.3? [2011-04-11 18:37:18] tom at punkave dot com Did this fix ever get put in PHP 5.3? I am getting this error exactly as originally described with all PHP 5.3.x versions tried. [2009-06-28 02:10:33] fel...@php.net This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Fixed in 5.2 and HEAD. 5.3 in soon. Thanks. [2009-06-27 21:43:08] tilo at levante dot de The following patch solved the issue in version 5.2.10 These three lines were added from version 5.2.9 to 5.2.10. I use a ms sql 7 server, maybe this server is not able th set the TEXTLIMIT to the given value. Greetings tilo --- ext/pdo_dblib/dblib_driver.c.orig 2009-03-20 23:14:17.0 +0100 +++ ext/pdo_dblib/dblib_driver.c2009-06-28 01:50:50.0 +0200 @@ -230,9 +230,9 @@ goto cleanup; } - if (DBSETOPT(H->link, DBTEXTLIMIT, "2147483647") == FAIL) { - goto cleanup; - } +// if (DBSETOPT(H->link, DBTEXTLIMIT, "2147483647") == FAIL) { +// goto cleanup; +// } if (vars[3].optval && FAIL == dbuse(H->link, vars[3].optval)) { goto cleanup; [2009-06-25 16:57:52] nicholas dot j dot miller at gmail dot com Our development team is seeing this problem in 5.2.10 as well. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=48539 -- Edit this bug report at https://bugs.php.net/bug.php?id=48539&edit=1
[PHP-BUG] Bug #63760 [NEW]: microtime(true) profiling is unreliable
From: lennartvdd at gmail dot com Operating system: Windows Server 2008 R2 PHP version: 5.3.19 Package: Date/time related Bug Type: Bug Bug description:microtime(true) profiling is unreliable Description: Script executing timing (profiling) using microtime(true) can produce unexpected and very inaccurate results (perhaps only on windows, haven't tested on *nix) An often used method for execution time profiling is to substract the result of microtime(true) ($start) before execution of a code block from the result of microtime(true) ($end) after exection of the code block. $end - $start sometimes produces values that are close to a minute, when actual code execution time is only a few seconds. Note that this server is in a domain environment, so this issue could be related to clock drift caused by synchronization with the Domain Controller. I am however not sure of this because I don't know the exact inner working of this method, and since I haven't been able to find a viable alternative for microtime(true), in my opinion it was still worth submitting this issue as a bug. Test script: --- Expected result: On every iteration: [iteration no]. Sleep: 250 us. Measured: [a value very close to 2.5] s. Actual result: -- C:\php-5.3.19-Win32-VC9-x86>php c:\scripts\test.php PHP Version: 5.3.19 0. Sleep: 250 us. Measured: 2.5308179855347 s. 1. Sleep: 250 us. Measured: 2.519441376 s. 2. Sleep: 250 us. Measured: 2.5092051029205 s. 3. Sleep: 250 us. Measured: 2.5104570388794 s. 4. Sleep: 250 us. Measured: 2.555615901947 s. 5. Sleep: 250 us. Measured: 2.5104122161865 s. 6. Sleep: 250 us. Measured: 2.5099401473999 s. 7. Sleep: 250 us. Measured: 2.5175790786743 s. 8. Sleep: 250 us. Measured: 2.5002219676971 s. 9. Sleep: 250 us. Measured: 2.5104150772095 s. 10. Sleep: 250 us. Measured: 2.5105049610138 s. 11. Sleep: 250 us. Measured: 2.5094060897827 s. 12. Sleep: 250 us. Measured: 2.5106818675995 s. 13. Sleep: 250 us. Measured: 2.510064125061 s. 14. Sleep: 250 us. Measured: 2.5104229450226 s. 15. Sleep: 250 us. Measured: 2.5097119808197 s. 16. Sleep: 250 us. Measured: 45.459776878357 s. 17. Sleep: 250 us. Measured: 2.5101070404053 s. 18. Sleep: 250 us. Measured: 2.5096528530121 s. 19. Sleep: 250 us. Measured: 2.5101320743561 s. 20. Sleep: 250 us. Measured: 2.510097026825 s. 21. Sleep: 250 us. Measured: 2.5106229782104 s. 22. Sleep: 250 us. Measured: 2.5097360610962 s. 23. Sleep: 250 us. Measured: 2.5255708694458 s. 24. Sleep: 250 us. Measured: 2.5107710361481 s. --- C:\php-5.3.19-nts-Win32-VC9-x86>php c:\scripts\test.php PHP Version: 5.3.19 0. Sleep: 250 us. Measured: 2.5030770301819 s. 1. Sleep: 250 us. Measured: 2.5102460384369 s. 2. Sleep: 250 us. Measured: 2.5099611282349 s. 3. Sleep: 250 us. Measured: 2.5090620517731 s. 4. Sleep: 250 us. Measured: 2.5101220607758 s. 5. Sleep: 250 us. Measured: 2.509134054184 s. 6. Sleep: 250 us. Measured: 2.5101330280304 s. 7. Sleep: 250 us. Measured: 2.510134935379 s. 8. Sleep: 250 us. Measured: 2.510153055191 s. 9. Sleep: 250 us. Measured: 2.5335099697113 s. 10. Sleep: 250 us. Measured: 2.4988961219788 s. 11. Sleep: 250 us. Measured: 2.5346119403839 s. 12. Sleep: 250 us. Measured: 2.5179290771484 s. 13. Sleep: 250 us. Measured: 2.5092740058899 s. 14. Sleep: 250 us. Measured: 2.5102789402008 s. 15. Sleep: 250 us. Measured: 45.460343122482 s. 16. Sleep: 250 us. Measured: 2.5100581645966 s. 17. Sleep: 250 us. Measured: 2.5105128288269 s. 18. Sleep: 250 us. Measured: 2.5105159282684 s. 19. Sleep: 250 us. Measured: 2.5099229812622 s. 20. Sleep: 250 us. Measured: 2.7429389953613 s. 21. Sleep: 250 us. Measured: 2.5088560581207 s. 22. Sleep: 250 us. Measured: 2.5094420909882 s. 23. Sleep: 250 us. Measured: 2.5213050842285 s. 24. Sleep: 250 us. Measured: 2.5118818283081 s. Note iteration marked with no. 16. in the first result (ts version) The timing on my watch, server and in my mind sayd it took only 2.5 s but PHP seems to think the sleep took longer. Same behaviour on the nts version (iteration no. 15) --- -- Edit bug report at https://bugs.php.net/bug.php?id=63760&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63760&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63760&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63760&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63760&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63760&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63760&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63760&r=needscript Try newer version: https:
Bug #63759 [Opn->Nab]: Linebreak in .php file before “
Edit report at https://bugs.php.net/bug.php?id=63759&edit=1 ID: 63759 Updated by: johan...@php.net Reported by:binary dot coder at web dot de Summary:Linebreak in .php file before âhttp://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. . Previous Comments: [2012-12-13 10:33:02] binary dot coder at web dot de Description: Platform: Mac OS X 10.8.2, MAMP 2.1.1, PHPStorm 5.0.4 If I would sum the HR we needed to solve this problem, it would took us two days. For some reason on my mac machine the code stop to work, while on windows machines everything runs perfect. It was very hard to figure out was had gone wrong, because the error message does not gave us any clue and pointed us into several wrong directions like sending wrong http header and things like that. The solution was simple and we just figured it out trough line by line compare of some files in the svn history. A simple break of line before "" destroyed the whole system. I really dont know how this is possible. Normally the php parser should ignore this. I had to listen to Mac bashing for two days from my colleagues, which really sucks... -- Edit this bug report at https://bugs.php.net/bug.php?id=63759&edit=1
[PHP-BUG] Bug #63759 [NEW]: Linebreak in .php file before “
From: binary dot coder at web dot de Operating system: Mac OS X 10.8.2 PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:Linebreak in .php file before âhttps://bugs.php.net/bug.php?id=63759&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63759&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63759&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63759&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63759&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63759&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63759&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63759&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63759&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63759&r=support Expected behavior: https://bugs.php.net/fix.php?id=63759&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63759&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63759&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63759&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63759&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63759&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63759&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63759&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63759&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63759&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63759&r=mysqlcfg
[PHP-BUG] Req #63758 [NEW]: strftime for %x returns wrong format in Dutch
From: giso at connectholland dot nl Operating system: Linux / Debian PHP version: Irrelevant Package: I18N and L10N related Bug Type: Feature/Change Request Bug description:strftime for %x returns wrong format in Dutch Description: The format outputted in Dutch for %x is "dd-mm-yy" while it should be "dd-mm- " I'm from the Netherlands and can assure you nobody writes or uses dates like "dd- mm-yy" Test script: --- setlocale(LC_TIME, "nl_NL"); echo strftime("%x"); Expected result: 13-12-2012 Actual result: -- 13-12-12 -- Edit bug report at https://bugs.php.net/bug.php?id=63758&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63758&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63758&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63758&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63758&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63758&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63758&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63758&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63758&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63758&r=support Expected behavior: https://bugs.php.net/fix.php?id=63758&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63758&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63758&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63758&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63758&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63758&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63758&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63758&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63758&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63758&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63758&r=mysqlcfg
Bug #63757 [Csd]: getenv() prosuces memory leak with CGI SAPI
Edit report at https://bugs.php.net/bug.php?id=63757&edit=1 ID: 63757 Updated by: dmi...@php.net Reported by:dmi...@php.net Summary:getenv() prosuces memory leak with CGI SAPI Status: Closed Type: Bug Package:Filter related Operating System: * PHP Version:5.4Git-2012-12-13 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: The fix for this bug has been committed. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. For Windows: http://windows.php.net/snapshots/ Thank you for the report, and for helping us make PHP better. Previous Comments: [2012-12-13 09:40:50] dmi...@php.net Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=35f86d24d81b81e8c755e82d0b2e76d36f4a0201 Log: Fixed bug #63757 (getenv() produces memory leak with CGI SAPI) [2012-12-13 08:45:13] dmi...@php.net Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '�nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=�nG'�W�$� === Total 1 memory leaks detected === -- Edit this bug report at https://bugs.php.net/bug.php?id=63757&edit=1
Bug #63757 [Asn->Csd]: getenv() prosuces memory leak with CGI SAPI
Edit report at https://bugs.php.net/bug.php?id=63757&edit=1 ID: 63757 Updated by: dmi...@php.net Reported by:dmi...@php.net Summary:getenv() prosuces memory leak with CGI SAPI -Status: Assigned +Status: Closed Type: Bug Package:Filter related Operating System: * PHP Version:5.4Git-2012-12-13 (Git) Assigned To:dmitry Block user comment: N Private report: N New Comment: Automatic comment on behalf of dmi...@zend.com Revision: http://git.php.net/?p=php-src.git;a=commit;h=35f86d24d81b81e8c755e82d0b2e76d36f4a0201 Log: Fixed bug #63757 (getenv() produces memory leak with CGI SAPI) Previous Comments: [2012-12-13 08:45:13] dmi...@php.net Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '�nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=�nG'�W�$� === Total 1 memory leaks detected === -- Edit this bug report at https://bugs.php.net/bug.php?id=63757&edit=1
Bug #63757 [Opn->Asn]: getenv() prosuces memory leak with CGI SAPI
Edit report at https://bugs.php.net/bug.php?id=63757&edit=1 ID: 63757 Updated by: dmi...@php.net Reported by:dmi...@php.net Summary:getenv() prosuces memory leak with CGI SAPI -Status: Open +Status: Assigned Type: Bug Package:Filter related Operating System: * PHP Version:5.4Git-2012-12-13 (Git) -Assigned To: +Assigned To:dmitry Block user comment: N Private report: N Previous Comments: [2012-12-13 08:45:13] dmi...@php.net Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '�nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=�nG'�W�$� === Total 1 memory leaks detected === -- Edit this bug report at https://bugs.php.net/bug.php?id=63757&edit=1
[PHP-BUG] Bug #63757 [NEW]: getenv() prosuces memory leak with CGI SAPI
From: dmitry Operating system: * PHP version: 5.4Git-2012-12-13 (Git) Package: Filter related Bug Type: Bug Bug description:getenv() prosuces memory leak with CGI SAPI Description: The memory leak is well reproducible with debug build and CGI SAPI. It also possible to see it with valgrind. $ USE_ZEND_ALLOC=0 valgrind --leak-check=full sapi/cgi/php-cgi env.php ==27371== 136 bytes in 1 blocks are definitely lost in loss record 30 of 73 ==27371==at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==27371==by 0x84B1704: _emalloc (zend_alloc.c:2423) ==27371==by 0x84B1B37: _estrndup (zend_alloc.c:2596) ==27371==by 0x81E275D: php_sapi_filter (filter.c:468) ==27371==by 0x846FA0E: sapi_getenv (SAPI.c:1020) ==27371==by 0x8374964: zif_getenv (basic_functions.c:4020) ==27371==by 0x85189ED: zend_do_fcall_common_helper_SPEC (zend_vm_execute.h:553) ==27371==by 0x851E497: ZEND_DO_FCALL_SPEC_CONST_HANDLER (zend_vm_execute.h:2302) ==27371==by 0x8517422: execute_ex (zend_vm_execute.h:356) ==27371==by 0x8517B11: zend_execute (zend_vm_execute.h:381) ==27371==by 0x84E06D9: zend_execute_scripts (zend.c:1309) ==27371==by 0x8466F98: php_execute_script (main.c:2468) The leak is relate to JIT initialization of PG(http_globals)[TRACK_VARS_ENV] Test script: --- OK Expected result: DONE Actual result: -- DONE [Thu Dec 13 12:39:18 2012] Script: '�nG'�W�$�' /home/dmitry/php/php5.4/ext/filter/filter.c(468) : Freeing 0xF718F3D8 (136 bytes), script=�nG'�W�$� === Total 1 memory leaks detected === -- Edit bug report at https://bugs.php.net/bug.php?id=63757&edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=63757&r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=63757&r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=63757&r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=63757&r=fixed Fixed in release: https://bugs.php.net/fix.php?id=63757&r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=63757&r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=63757&r=needscript Try newer version: https://bugs.php.net/fix.php?id=63757&r=oldversion Not developer issue:https://bugs.php.net/fix.php?id=63757&r=support Expected behavior: https://bugs.php.net/fix.php?id=63757&r=notwrong Not enough info: https://bugs.php.net/fix.php?id=63757&r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=63757&r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=63757&r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=63757&r=php4 Daylight Savings: https://bugs.php.net/fix.php?id=63757&r=dst IIS Stability: https://bugs.php.net/fix.php?id=63757&r=isapi Install GNU Sed:https://bugs.php.net/fix.php?id=63757&r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=63757&r=float No Zend Extensions: https://bugs.php.net/fix.php?id=63757&r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=63757&r=mysqlcfg
Bug #63752 [Opn->Nab]: foreach increments pointer used by current() once
Edit report at https://bugs.php.net/bug.php?id=63752&edit=1 ID: 63752 Updated by: larue...@php.net Reported by:terrafr...@php.net Summary:foreach increments pointer used by current() once -Status: Open +Status: Not a bug Type: Bug Package:Arrays related Operating System: Windows 7 PHP Version:5.4.9 Block user comment: N Private report: N New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php 1. at the beginning of foreach: ZEND_FE_RESET which will increase the refoucnt of $a 2. then FE_FETCH, which will increase internal pointer of $a 3. then current, current declared to accept a reference, but $a is not a ref and refcount > 1 , then -> separation hope I made it clear. thanks Previous Comments: [2012-12-12 15:06:01] terrafr...@php.net Description: foreach seems to increment the pointer used by current() once even if foreach loops multiple times. Seems to me that it should not increment it at all or increment it multiple times. Not once and that's it. Test script: --- $elem) { echo "$key = $elem"; echo ' = '; var_dump(current($a)); } ?> Expected result: 0 = 1 = int(1) 1 = 2 = int(1) 2 = 3 = int(1) 3 = 4 = int(1) 4 = 5 = int(1) Actual result: -- 0 = 1 = int(2) 1 = 2 = int(2) 2 = 3 = int(2) 3 = 4 = int(2) 4 = 5 = int(2) -- Edit this bug report at https://bugs.php.net/bug.php?id=63752&edit=1
Bug #63741 [Fbk]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Updated by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: however, it is better if you can provide a access to a reproduceable box (via mail) :) thanks Previous Comments: [2012-12-13 08:18:15] larue...@php.net oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- >called_scope) [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 [2012-12-13 02:49:53] larue...@php.net unfortunately, I can not reproduce it. instead I got a FATAL ERROR: can not redeclare function main [2012-12-12 18:33:13] bobwei9 at hotmail dot com Segmentation fault: 11 (core dumped) Segfault if called from a function (â in a class) Can you reproduce this? Or do you need more info? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1
Bug #63741 [Fbk]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Updated by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: oh, seems your are a zts build, then you have to find out executor_global first it should be: (((zend_executor_globals *) (*((void ***) tsrm_ls))[executor_globals_id-1])- >called_scope) Previous Comments: [2012-12-13 08:12:44] larue...@php.net @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 [2012-12-13 02:49:53] larue...@php.net unfortunately, I can not reproduce it. instead I got a FATAL ERROR: can not redeclare function main [2012-12-12 18:33:13] bobwei9 at hotmail dot com Segmentation fault: 11 (core dumped) Segfault if called from a function (â in a class) Can you reproduce this? Or do you need more info? [2012-12-12 10:16:14] larue...@php.net yes, it's needed :), thanks The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1
Bug #63741 [Opn->Fbk]: Crash when autoloading from spl
Edit report at https://bugs.php.net/bug.php?id=63741&edit=1 ID: 63741 Updated by: larue...@php.net Reported by:bobwei9 at hotmail dot com Summary:Crash when autoloading from spl -Status: Open +Status: Feedback Type: Bug Package:SPL related Operating System: Mac OS X Mountain Lion PHP Version:master-Git-2012-12-11 (Git) Block user comment: N Private report: N New Comment: @bobwei9 hmm, seems EG(called_scope) was polluted somewhere, maybe you can break at zend_execute , then watch executor_globals->called_scope, find the place where it became 0x5a5a5a5a0 that will be very helpful.. thanks Previous Comments: [2012-12-13 06:36:22] bobwei9 at hotmail dot com I get everytime the same backtrace... Is it perhaps OS-dependent? The phpinfo() is here: http://bobweinand.no-ip.org/phpinfo.php instance_ce seems wrong: for example instance_ce->num_interfaces: it had a value of 2^32-1 #0 0x0001008fb936 in instanceof_function_ex (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, interfaces_only=0 '\0', tsrm_ls=0x101710f20) at zend_operators.c:1720 #1 0x0001008fb9e5 in instanceof_function (instance_ce=0x5a5a5a5a, ce=0x10223d8f0, tsrm_ls=0x101710f20) at zend_operators.c:1740 #2 0x000100934457 in zend_call_method (object_pp=0x0, obj_ce=0x10223d8f0, fn_proxy=0x10223f170, function_name=0x10223c418 "autoloader::autoload", function_name_len=21, retval_ptr_ptr=0x7fff5fbfd628, param_count=1, arg1=0x10223ada0, arg2=0x0, tsrm_ls=0x101710f20) at zend_interfaces.c:89 #3 0x0001005a6128 in zif_spl_autoload_call (ht=1, return_value=0x102237d18, return_value_ptr=0x7fff5fbfded8, this_ptr=0x0, return_value_used=1, tsrm_ls=0x101710f20) at php_spl.c:436 #4 0x0001008e7023 in zend_call_function (fci=0x7fff5fbfde78, fci_cache=0x7fff5fbfde50, tsrm_ls=0x101710f20) at zend_execute_API.c:979 #5 0x0001008e814a in zend_lookup_class_ex (name=0x10223dea8 "ClassToLoad", name_length=11, key=0x10223e008, use_autoload=1, ce=0x7fff5fbfdf70, tsrm_ls=0x101710f20) at zend_execute_API.c:1129 #6 0x0001008e9f2e in zend_fetch_class_by_name (class_name=0x10223dea8 "ClassToLoad", class_name_len=11, key=0x10223e008, fetch_type=0, tsrm_ls=0x101710f20) at zend_execute_API.c:1609 #7 0x000100978c23 in ZEND_INIT_STATIC_METHOD_CALL_SPEC_CONST_CONST_HANDLER (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:3550 #8 0x000100963fe2 in execute_ex (execute_data=0x102202358, tsrm_ls=0x101710f20) at zend_vm_execute.h:356 #9 0x0001009650fc in zend_execute (op_array=0x102239d98, tsrm_ls=0x101710f20) at zend_vm_execute.h:381 #10 0x000100905463 in zend_execute_scripts (type=8, tsrm_ls=0x101710f20, retval=0x0, file_count=3) at zend.c:1309 #11 0x0001008215ac in php_execute_script (primary_file=0x7fff5fbff728, tsrm_ls=0x101710f20) at main.c:2468 #12 0x000100b2e98f in do_cli (argc=2, argv=0x7fff5fbffa18, tsrm_ls=0x101710f20) at php_cli.c:988 #13 0x000100b30a3e in main (argc=2, argv=0x7fff5fbffa18) at php_cli.c:1364 [2012-12-13 02:49:53] larue...@php.net unfortunately, I can not reproduce it. instead I got a FATAL ERROR: can not redeclare function main [2012-12-12 18:33:13] bobwei9 at hotmail dot com Segmentation fault: 11 (core dumped) Segfault if called from a function (â in a class) Can you reproduce this? Or do you need more info? [2012-12-12 10:16:14] larue...@php.net yes, it's needed :), thanks [2012-12-12 09:15:58] bobwei9 at hotmail dot com In the base directory of the install. An autoloader defined previously with spl_autoload_register is called in the GlobalFunctions.php (see the zbacktrace in the opening post) and then crashes. In the evening I'll try to create a smaller reproduce script if needed. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=63741 -- Edit this bug report at https://bugs.php.net/bug.php?id=63741&edit=1