#50360 [Com]: Crash on is_subclass_of() under special conditions
ID: 50360 Comment by: mjomble at gmail dot com Reported By: mjomble at gmail dot com Status: Feedback Bug Type: Reproducible crash Operating System: Windows XP / Vista PHP Version: 5.2SVN-2009-12-02 (snap) New Comment: The crash can't be reproduced with a single file as that would not invoke the autoloader. Previous Comments: [2009-12-02 13:59:52] j...@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with , is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. ONE file, thank you. Use something else than zipped file. [2009-12-02 13:57:26] mjomble at gmail dot com Description: The issue seems similar to bug #46753, but with a much more compact reproduce code: 3 files; ~75 lines in total; no external dependencies. I've managed to reproduce the crash with the same code in 5.2.2, 5.2.11, 5.2.12RC3 and the 5.2 snapshot from 2009-12-02. It doesn't happen with 5.3.0 or 5.3.1, at least with this code. Factors that determine whether the crash occurs or not include: * Use of is_subclass_of() vs instanceof * Custom autoloader * A random function call in the autoloader function * Either the "width" or depth of the callstack at the time is_subclass_of() is called. In the provided reproduce code, there's a shallow call stack, but a large number of parameters. The crash could also be reproduced with fewer parameters, but a deeper call stack. * The number of methods in a specific class. See the comments in the reproduce code for more details on small code changes that can cause the crash not to occur. Reproduce code: --- http://files.rtedev.com/phpbug.zip The code is in three separate files. Putting the classes in fewer files will change the autoloader's behavior so that the crash will not occur. Extract the zip into a folder and run php run.php This should crash the PHP CLI. Expected result: "Done" should be printed to standard output. Actual result: -- Backtrace from Microsoft Debug Diagnostic Tools Thread 0 - System ID 5108 Entry point php!mainCRTStartup Function Arg 1 Arg 2 Arg 3 php5ts!is_a_impl+b6 019029ac 0190f9e0 php5ts!zif_is_subclass_of+25 0002 0190f9e0 php5ts!zend_do_fcall_common_helper_SPEC+7ab 00c0faf0 00312600 0190e818 php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+e5 003126d8 00c0fbf4 php5ts!execute+1c50190f328 003126d8 php5ts!zend_do_fcall_common_helper_SPEC+8ca 00c0fb98 00312601 1001c6c5 php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 00c0fb98 003126d8 003126d8 php5ts!execute+1c50190d210 003126d8 php5ts!zend_execute_scripts+107 0008 003126d8 php5ts!php_execute_script+20d 00c0fe90 003126d8 php!main+bca 0002 00312630 003116a0 php!mainCRTStartup+e3 7ffd4000 00c0ffd4 779119bb kernel32!BaseThreadInitThunk+e7ffd4000 7dc79c3d ntdll!__RtlUserThreadStart+23 00402f72 7ffd4000 ntdll!_RtlUserThreadStart+1b 00402f72 7ffd4000 -- Edit this bug report at http://bugs.php.net/?id=50360&edit=1
#50360 [NEW]: Crash on is_subclass_of() under special conditions
From: mjomble at gmail dot com Operating system: Windows XP / Vista PHP version: 5.2SVN-2009-12-02 (snap) PHP Bug Type: Reproducible crash Bug description: Crash on is_subclass_of() under special conditions Description: The issue seems similar to bug #46753, but with a much more compact reproduce code: 3 files; ~75 lines in total; no external dependencies. I've managed to reproduce the crash with the same code in 5.2.2, 5.2.11, 5.2.12RC3 and the 5.2 snapshot from 2009-12-02. It doesn't happen with 5.3.0 or 5.3.1, at least with this code. Factors that determine whether the crash occurs or not include: * Use of is_subclass_of() vs instanceof * Custom autoloader * A random function call in the autoloader function * Either the "width" or depth of the callstack at the time is_subclass_of() is called. In the provided reproduce code, there's a shallow call stack, but a large number of parameters. The crash could also be reproduced with fewer parameters, but a deeper call stack. * The number of methods in a specific class. See the comments in the reproduce code for more details on small code changes that can cause the crash not to occur. Reproduce code: --- http://files.rtedev.com/phpbug.zip The code is in three separate files. Putting the classes in fewer files will change the autoloader's behavior so that the crash will not occur. Extract the zip into a folder and run php run.php This should crash the PHP CLI. Expected result: "Done" should be printed to standard output. Actual result: -- Backtrace from Microsoft Debug Diagnostic Tools Thread 0 - System ID 5108 Entry point php!mainCRTStartup Function Arg 1 Arg 2 Arg 3 php5ts!is_a_impl+b6 019029ac 0190f9e0 php5ts!zif_is_subclass_of+25 0002 0190f9e0 php5ts!zend_do_fcall_common_helper_SPEC+7ab 00c0faf0 00312600 0190e818 php5ts!ZEND_DO_FCALL_SPEC_CONST_HANDLER+e5 003126d8 00c0fbf4 php5ts!execute+1c50190f328 003126d8 php5ts!zend_do_fcall_common_helper_SPEC+8ca 00c0fb98 00312601 1001c6c5 php5ts!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER+15 00c0fb98 003126d8 003126d8 php5ts!execute+1c50190d210 003126d8 php5ts!zend_execute_scripts+107 0008 003126d8 php5ts!php_execute_script+20d 00c0fe90 003126d8 php!main+bca 0002 00312630 003116a0 php!mainCRTStartup+e3 7ffd4000 00c0ffd4 779119bb kernel32!BaseThreadInitThunk+e7ffd4000 7dc79c3d ntdll!__RtlUserThreadStart+23 00402f72 7ffd4000 ntdll!_RtlUserThreadStart+1b 00402f72 7ffd4000 -- Edit bug report at http://bugs.php.net/?id=50360&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50360&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50360&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50360&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50360&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50360&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50360&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50360&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50360&r=needscript Try newer version: http://bugs.php.net/fix.php?id=50360&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50360&r=support Expected behavior: http://bugs.php.net/fix.php?id=50360&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50360&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50360&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50360&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50360&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50360&r=dst IIS Stability: http://bugs.php.net/fix.php?id=50360&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50360&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50360&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50360&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50360&r=mysqlcfg
#49485 [NEW]: Allow & when passing parameters by reference
From: mjomble at gmail dot com Operating system: Windows PHP version: 5.3.0 PHP Bug Type: Feature/Change Request Bug description: Allow & when passing parameters by reference Description: NB! I'm not asking for the un-deprecation of call-time pass-by-reference. The way I understand it, this could previously alter the behavior of a function at call time. I agree that this can make things ugly and I can see the reason for it being deprecated. However, I would still like to be able to use the & for decorative purposes. When you see a call to a function without knowing/remembering/looking up the function definition, there's no way of telling whether the call can modify the variable or not. In most cases, it is simply assumed that parameters are not passed by reference and will have the exact same value after the call. Which can cause problems when they're actually passed by reference. Currently, to avoid such problems, I often add comments like this: // $someParameter is passed by reference and may be modified by someMethod() $someObject->someMethod($someParameter); It would make things much clearer if it could be called like in the reproduce code, but ONLY if the function actually uses the first parameter by reference. Reproduce code: --- $someObject->someMethod(&$someParameter); Expected result: If the definition of someMethod() does not use the first parameter by reference, a warning should appear. Otherwise, the code should execute normally. Actual result: -- A warning always appears, regardless of how the parameter is used. -- Edit bug report at http://bugs.php.net/?id=49485&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=49485&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=49485&r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=49485&r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=49485&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=49485&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=49485&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=49485&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=49485&r=needscript Try newer version: http://bugs.php.net/fix.php?id=49485&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=49485&r=support Expected behavior: http://bugs.php.net/fix.php?id=49485&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=49485&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=49485&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=49485&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=49485&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=49485&r=dst IIS Stability: http://bugs.php.net/fix.php?id=49485&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=49485&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=49485&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=49485&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=49485&r=mysqlcfg
#46684 [NEW]: Could SimpleXmlElement's constructor be made non-final?
From: mjomble at gmail dot com Operating system: Irrelevant PHP version: 5.3.0alpha2 PHP Bug Type: Feature/Change Request Bug description: Could SimpleXmlElement's constructor be made non-final? Description: Why was the constructor made final in the first place? If there's a good reason for this, I'd like to find out. Otherwise, it would be useful if the SimpleXmlElement class could be properly extended. -- Edit bug report at http://bugs.php.net/?id=46684&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46684&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46684&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46684&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46684&r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=46684&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=46684&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46684&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=46684&r=needscript Try newer version: http://bugs.php.net/fix.php?id=46684&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46684&r=support Expected behavior: http://bugs.php.net/fix.php?id=46684&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46684&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46684&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46684&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46684&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=46684&r=dst IIS Stability: http://bugs.php.net/fix.php?id=46684&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46684&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46684&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46684&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=46684&r=mysqlcfg
