[PHP-DEV] PHP 5 Bug Summary Report
PHP 5 Bug Database summary - http://bugs.php.net/ Num Status Summary (1309 total -- which includes 855 feature requests) ===[*Network Functions]=== 48167 To be documented undefined function checkdnsrr() ===[*XML functions]=== 48095 Verified Load RDF Format Error ===[Apache2 related]== 32220 Assigned [PATCH] thread_resources for thread not getting freed when apache kills thread 47675 Open File descriptor leaked due to HAVE_BROKEN_GETCWD 47681 Open System TMP dir ignored in file uploads 48134 Feedback php crash after a few days (backtrace attached) with worker MPM ===[Arrays related]=== 47221 Open no result from array_diff() ===[BC math related]== 44995 Open bcpowmod() using a scale function always returns 0 46564 Verified bcmod( '1071', '357.5' ) returns '0' ===[Bzip2 Related] 29521 Assigned compress.bzip2 wrapper ===[Calendar related]= 40213 Suspended easter_date() returns wrong timestamp if ... ===[CGI related]== 45217 Open crash if -z and -m are used together 47042 Open cgi sapi is incorrectly removing the SCRIPT_FILENAME for non apache 47412 Open PHP_MSHUTDOWN_FUNCTION not being called under FastCGI 47540 Open CLI can go into an infinite write() loop when ignore_user_abort(true) 47605 Open CGI SAPI can not send HTTP 200 header 47627 Open No input file specified causing crash 47766 Assigned php-cgi.exe crashes ===[Class/Object related]= 41461 Verified E_STRICT notice when overriding methods not defined by an Interface in hierarchy 46140 Open Unserializing with __wakeup that removes child causes subsequent refs to shift 46812 Verified get_class_vars() does not include visible private variable looking at subclass 47405 Verified error reports wrong file/line 48215 Verified Child calling parent::func calls constructor instead of method (BC break!) ===[COM related]== 31327 Assigned chinese char and word problem 32099 Assigned After opening ADO connection and closing it repeatedly, Apache stops service 34253 Assigned COM binary object/array issue (question marks?) 35875 Assigned IE event failure upon scheduling script 36360 Assigned PHP crashes when accessing an object that was just create by parent object 37562 Assigned Unable to lookup ParameterFieldDefinitions 37899 Assigned [PATCH] php_char_to _OLECHAR copies junk bytes 37965 Assigned Multi-dimensional array between PHP and COM 38719 Assigned COM Error during accessing function VirtualMachines 40424 Assigned Fatal error when setting the value of COM object's property array 40581 Assigned Pass Struct type to COM object from PHP 40664 Assigned String conversion functions wrong for multibyte chars 41055 Assigned DOTNET not instantiating fully-pathed assembly 41078 Assigned Its not possible to call Static dotNet Classes with dotnet 41189 Assigned Multi-dimensional array in COM function causes hang 41368 Assigned ADODB.Recordset ActiveConnection property - can't set with PHP 5.2.1+ 41388 Assigned Error in COM Object results 41577 Assigned DOTNET is successful once per server run 42413 Assigned Cannot iterate IE's event object 42551 Assigned new COM(HTMLFile) = warnings 42585 Assigned die() in event handler = PHP hangs 43275 Open get_class problem with COM objects 43432 Open Fatal error when setting the value of COM object's Attribute property 43470 Open COM API fails to correctly return [OUT] VT_PTR references 43506 Open com_get_active_object always fails 43521 Open Problem with Variant/Parameters 43838 Open variant_set with IE leads to hang 43897 Open $ie not cleared on IE quit 44256 Open Pb with COM in PHP5 44578 Open Strange Behavior of PHP using COM Object 45280 Feedback Reflection of instantiated COM classes causes PHP to crash. 45704 Open $exception-getCode() always return 0x80020009 even when it shouldn't 45855 Open COM-Problem with GET/SET, using same method name (but with different arg count) 46224 Open Cannot instantiate .Net object (ABCpdf 6.1 .Net) 46522 Open Problem using new com 47401 Open Can't instantiate VARIANT objects with VT_BYREF flag 47458 Open PHP run as CGI module onapache giving ADODB error on win2008 47569 Open DOTNET Excpection error 47869 Open DocumentComplete does not return a useful COM object 47878 Open ScriptControl
[PHP-DEV] PHP 6 Bug Summary Report
PHP 6 Bug Database summary - http://bugs.php.net/ Num Status Summary (75 total -- which includes 34 feature requests) ===[*Unicode Issues]== 48170 Feedback Array key differentiates between unicode and binary strings ===[Apache related]=== 47061 Open User not logged under Apache ===[Apache2 related]== 44083 Open virtual() not outputting results if zlib.output_compression = On ===[Arrays related]=== 35277 Suspended incorrect recursion detection 41758 Assigned SORT_LOCALE_STRING broken for sort() in PHP6 43109 Open array_intersect() emits unexpected no of notices when 2d array is passed as arg ===[COM related]== 45836 Open cannot use com 46909 Open COM object not allowing calls to methods ===[Compile Failure]== 42606 Open unicode/constants.c relies on ICU draft api 44502 Suspended Compiling ok with MySQL 5.0 ===[Date/time related] 46948 Assigned ext/date/lib/parse_tz.c:99: Memory leak: buffer ===[Filesystem function related]== 42110 Open fgetcsv doesn't handle \n correctly in multiline csv record 44034 Open FILE_IGNORE_NEW_LINES in FILE does not work as expected when lines end in \r\n 46688 Open Return values differ from 5.3 and are also inconsistent 46689 Open Downcoded notices suggest unfinished code in file system? ===[GD related]=== 34670 Assigned imageTTFText for Indian scripts (Devanagari) 34992 Assigned imageconvolution does not respect alpha ===[I18N and L10N related] 42471 Open locale_set_default returns true on invalid locales ===[mcrypt related]=== 46834 Assigned Range of mcrypt functions fail on PHP 6.0 ===[MySQL related] 44076 Open mysql_result returns nothing with blob ===[OpenSSL related]== 25614 Assigned openssl_pkey_get_public() fails when given a private key ===[PDO related]== 35368 Suspended PDO query does not work properly with serialize ===[Performance problem]== 42528 Open Out of char(8-bit) range value doesn't roll back, with uni-code ON. ===[Program Execution] 39992 Open proc_terminate() leaves children of child running 43784 Assigned escapeshellarg removes % from given string ===[Regexps related]== 44923 Open ereg functions are not unicode aware: provide wrapper functions in PCRE ===[Reproducible crash]=== 45107 Open setting ext_dir to ./ (and other ini settings) causes apache crash 47756 Open Segfault on HTML Purifier test suite ===[Scripting Engine problem]= 42194 Open $argc/$argv[] won't work when .php extension is assigned to php.exe 47154 Open Object properties unset after setting. ===[Session related]== 44860 Open session_encode() fails for php_binary serializer ===[Strings related]== 45566 Open Strict comparision on $_SERVER values fail 47691 Verified strtr bug. Not replace unicode values from array, in binary string. ===[Unicode Engine related]=== 45087 Open Illegal or truncated character in input 47155 Open PHP 6.0 decodes base64 into incorrect uft-8 string 47164 Assigned uncomfortable (binary)char() append to binary string ===[URL related]== 45602 Open urlencode/urldecode should use ASCII encoding ===[XSLT related]= 38218 Assigned php:functionString tries to access objects with their names in lowercase ===[Zlib Related]= 30153 Suspended FATAL erealloc() error when using gzinflate() 47178 Suspended Missing gzip headers in gzencode() output 47179 Open gzuncompress does not report expcted error Assigned bugs and feature requests (reminders sent): andrei 41758: SORT_LOCALE_STRING broken for sort() in PHP6 derick
[PHP-DEV] Reflection
Hello Internals I've been reading some over the reflection sources, and theres a few things that made me wonder abit; 1) ReflectionParameter::getDefaultValue(), was added to HEAD in 2006, but never merged to a stable branch? I made a backport of the function to 5.3 [1] which I think we should merge, whether its gonna be 5.3.1 or what. 2) _default_lookup_entry() is commented out by a macro in HEAD but is used in 5.3, and the only difference is the zend_hash_find - zend_u_hash_find call for unicode? 3) Closures, theres alot of closure differences in HEAD and 5.3, for example HEAD has ReflectionMethod::getClosure() and ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it looks like a change in 5.3 that never occured to HEAD, unless that is the logic is fixed in HEAD. We should really fix this, so 5.3 have these if needed. 4) How about an ReflectionNamespace, to analyze a namespace? Since theres no real way to use reflection on namespaces other than the isNamespace methods etc. On a related note, I'd also like to propose an addition for reflection, whether its 5.3.1 or what (since we're so late in 5.3, theres no need to push more features), this is 3 new methods to the ReflectionExtension class[2]: ReflectionExtension::isDynamicLoaded() - Returns if an extension was loaded through dl() ReflectionExtension::getBuildId() - Gets the zend build id (added in 5.3) ReflectionExtension::getAPINo() - Gets the zend api no that the extension was compiled for (may not really be needed, since the number doesn't change very often nor may be of any real use) [1] http://pastie.org/474289 [2] http://pastie.org/474293 -- Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC3
On 08.05.2009, at 10:31, Lukas Kahwe Smith wrote: 1. fix open PHP 5.3 bugs To spare us surprises so late in the game, please only commit bug fixes with accompanying tests. Again as Johannes mentioned, tests in the testfest repo do not count. They should go into php-src along with the actual fix. 2. finish UPGRADING README file (Steph) 3. write migration guide for the manual (Steph) @Steph: Where do we stand here? This item needs to be in full swing to be finished right now. Preferably before RC3, so that this release can also put the documentation to the test. If you need additional hands or cannot complete this by this weekend alone, we need others to step up and help out. Critical issues: 1) I assume the issues with rounding are resolved. If any issues pop up again, please let the list know. @Matt/Dmitry: Can you just give us the quick nod that all is well here? 2) The re2c EOF bug needs a clean fix @Nuno/Macus/The rest of the world: This issue is still open. If we can find a fix for this we are all comfortable with by Thursday evening, I would like to go ahead with RC3 next week. The idea being that this change needs to be validated a bit before its worth going into release mode and also re2c needs to put this change into a release as well. If not, then it just means we need to wait an extra week before we can look at releasing RC3 again. We have identified another critical issue on windows. Pierre is in the process of validating the fix: http://bugs.php.net/bug.php?id=44859 regards, Lukas Kahwe Smith m...@pooteeweet.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reflection
Hi Kalle, 3) Closures, theres alot of closure differences in HEAD and 5.3, for example HEAD has ReflectionMethod::getClosure() and ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it looks like a change in 5.3 that never occured to HEAD, unless that is the logic is fixed in HEAD. We should really fix this, so 5.3 have these if needed. The reason for this is that I removed $this and OOP support from closures on Johannes's and Lukas's request in 5.3 since there was no consensus on how this should actually work (see [1]). I didn't revert in HEAD because there was at least consensus on the fact that someday in the future Closures should support OOP/$this after we decide how. The discussion on that topic has not progressed, however - nobody actually reacted to my explanation on this topic (see [2]) - even after the removal in 5.3 (which was done in order to allow the discussion to progress independently of 5.3 so that a solution is not forced due to time constraints). My rationale for not removing it from HEAD was the simple fact that I thought the discussion on this topic would progress and after 5.3 we would reach a consensus on how to implement that. In that case, the code in HEAD would have only needed to be changed, but not re-added. I did not anticipate that the discussion would die down completely for so long and that no progress would be made in that case. Anyway, we have the following two options for HEAD: 1. Sync HEAD with 5.3 and remove that stuff also. Which could lead to additional, unecessary work after we decide which way we want to go. 2. Leave it as is until we have decided. Anyway, if anybody wants to renew the discussion on this topic, look at [2] where all the details and problems are explained. [1] http://wiki.php.net/rfc/closures/removal-of-this [2] http://wiki.php.net/rfc/closures/object-extension (please ignore timeline in the second link, it's outdated) Regards, Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Reflection
(re-sending, sorry if this arrives twice) Hi, On Mon, 2009-05-11 at 12:34 +0200, Kalle Sommer Nielsen wrote: 1) ReflectionParameter::getDefaultValue(), was added to HEAD in 2006, but never merged to a stable branch? I made a backport of the function to 5.3 [1] which I think we should merge, whether its gonna be 5.3.1 or what. This should be low risk as it's a self-contained function and we all est HEAD ... but I'd prefer not adding anything but bug fixes to 5.3 as it already took way too long. 2) _default_lookup_entry() is commented out by a macro in HEAD but is used in 5.3, and the only difference is the zend_hash_find - zend_u_hash_find call for unicode? Didn't take a look at the code so can't say much 3) Closures, theres alot of closure differences in HEAD and 5.3, for example HEAD has ReflectionMethod::getClosure() and ReflectionFunction::getClosureThis(), but 5.3 does not, which makes it looks like a change in 5.3 that never occured to HEAD, unless that is the logic is fixed in HEAD. We should really fix this, so 5.3 have these if needed. At least getClosureThis() depends on $this handling which was reverted from 5.3. Not sure what getClosure() does. 4) How about an ReflectionNamespace, to analyze a namespace? Since theres no real way to use reflection on namespaces other than the isNamespace methods etc. We have no real namespace meta-data available, the only way doing things there would be by iterating over the class table and parsing the class names. Not usre that's really a good thing to do. On a related note, I'd also like to propose an addition for reflection, whether its 5.3.1 or what (since we're so late in 5.3, theres no need to push more features), this is 3 new methods to the ReflectionExtension class[2]: ReflectionExtension::isDynamicLoaded() - Returns if an extension was loaded through dl() I was under the impression this was possible, or is it only printed by export()? ReflectionExtension::getBuildId() - Gets the zend build id (added in 5.3) ReflectionExtension::getAPINo() - Gets the zend api no that the extension was compiled for (may not really be needed, since the number doesn't change very often nor may be of any real use) I don't think this belongs to that class as these values should match the one PHP was compiled with, so I think this should be a global function. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hi guys, What's the status on this one?! It's an important optimization that should be considered. Save more than a million method calls on a framework does not worth? None gave a final word on this subject. I could not see this commited in 5.3 neither in HEAD. So...can someone notify me about the status of this??? Cheers, On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote: Marcus Boerger wrote: Aren't we able to bind these at least partially to the function call opcode, in case we know they are constant? If all is constsnt we could even store the whole lookup in the opcode. Well you'd have to convince Zend to do that because os far they have always been against this approach. We can't modify opcode it self as it'll break opcode caches. However we can introduce some indirect table associated with op_array, which can be used to implement inline caches without direct opcode modification (in the same way as IS_CV variables work). There are a lot of papers about polymorphic inline caches (e.g. http://research.sun.com/self/papers/pics.html) which we probably should use to not to invite bicycle. Thanks. Dmitry. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco - Web Developer CBC - Certified Bindows Consultant Cell Phone: +55 (16) 9215-8480 MSN: guilhermebla...@hotmail.com URL: http://blog.bisna.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
On Mon, May 11, 2009 at 7:47 PM, Guilherme Blanco guilhermebla...@gmail.com wrote: What's the status on this one?! I think it died from neglect. But it was a really good idea. One question that was raised was: On Thu, Jan 22, 2009 at 10:20 AM, Dmitry Stogov dmi...@zend.com wrote: However we can introduce some indirect table associated with op_array, which can be used to implement inline caches without direct opcode modification (in the same way as IS_CV variables work). There are a lot of papers about polymorphic inline caches (e.g. http://research.sun.com/self/papers/pics.html) which we probably should use to not to invite bicycle. You can't actually use PICs or even ICs with the Zend engine, because you can't insert code into the callee method's header (you would need a JIT). You also wouldn't want to, since PHP can't use the recompilation techniques that Self had. You can use lookup caches, which is exactly what the original patch was. FWIW, since PHP has a static inheritence chain, the best approach seems to be to build a virtual dispatch table, instead of a hashtable for functions. However, there might be some esoteric extensions which make this difficult. Paul -- Paul Biggar paul.big...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Method call improvements
Hi! FWIW, since PHP has a static inheritence chain, the best approach seems to be to build a virtual dispatch table, instead of a hashtable for functions. However, there might be some esoteric extensions which make this difficult. IHMO it's not static enough. I.e., since PHP is not compiled, we can not create VD table for the class until runtime inheritance, which means that the code using this class can use method resolution more efficient than name-function, i.e. hashtable. These lookups can be cached (i.e. CV style) but I don't see how they can be altogether prevented. -- Stanislav Malyshev, Zend Software Architect s...@zend.com http://www.zend.com/ (408)253-8829 MSN: s...@zend.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC3
Hi Lukas, - Original Message - From: Lukas Kahwe Smith Sent: Monday, May 11, 2009 [...] Critical issues: 1) I assume the issues with rounding are resolved. If any issues pop up again, please let the list know. @Matt/Dmitry: Can you just give us the quick nod that all is well here? No, can't say that all is well. :-/ Nothing was changed yet, sorry if you misunderstood. (BTW, it's not rounding/parsing, but conversion/casting of floats-integers... :-)) I sent the updated patch a month ago, and then the next week Stas asked some questions off-list, for clarification, etc. and then said that the patch looks good and since it appears to fix things I think it can be applied. That's the only feedback I had really, and Dmitry mentioned that it breaks about 30 tests (I'd consider them broken now, to match the code, however ;-)), which I knew would have to be updated. I didn't try to fix them yet, since I didn't know if the changes would finally be applied or not. I was going to bring it up again but then it was too close to RC2. There were some e-mails on the subject that I didn't follow up on (nothing major, just comments), including one of yours I think. Anyway, I guess I/we can wonder about RC3 now? Again, the *very minor* modifications only help to ensure the [usual] long-standing behavior on all platforms -- e.g. most users would see no change from 5.2 or prior. I'll try to be sure to do what I can to take care of anything now, since I shouldn't be distracted with other stuff like leading up to RC2... [...] regards, Lukas Kahwe Smith m...@pooteeweet.org - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC3
Before committing anything else into PHP_5_3, can you first make sure everything you provided is ALSO IN HEAD?! Hint: zend_operators.* --Jani Matt Wilmas kirjoitti: Hi Lukas, - Original Message - From: Lukas Kahwe Smith Sent: Monday, May 11, 2009 [...] Critical issues: 1) I assume the issues with rounding are resolved. If any issues pop up again, please let the list know. @Matt/Dmitry: Can you just give us the quick nod that all is well here? No, can't say that all is well. :-/ Nothing was changed yet, sorry if you misunderstood. (BTW, it's not rounding/parsing, but conversion/casting of floats-integers... :-)) I sent the updated patch a month ago, and then the next week Stas asked some questions off-list, for clarification, etc. and then said that the patch looks good and since it appears to fix things I think it can be applied. That's the only feedback I had really, and Dmitry mentioned that it breaks about 30 tests (I'd consider them broken now, to match the code, however ;-)), which I knew would have to be updated. I didn't try to fix them yet, since I didn't know if the changes would finally be applied or not. I was going to bring it up again but then it was too close to RC2. There were some e-mails on the subject that I didn't follow up on (nothing major, just comments), including one of yours I think. Anyway, I guess I/we can wonder about RC3 now? Again, the *very minor* modifications only help to ensure the [usual] long-standing behavior on all platforms -- e.g. most users would see no change from 5.2 or prior. I'll try to be sure to do what I can to take care of anything now, since I shouldn't be distracted with other stuff like leading up to RC2... [...] regards, Lukas Kahwe Smith m...@pooteeweet.org - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3.0RC3
Hi Jani, - Original Message - From: Jani Taskinen Sent: Monday, May 11, 2009 Before committing anything else into PHP_5_3, can you first make sure everything you provided is ALSO IN HEAD?! To answer that directly, no. :-) Everything I do is in HEAD first, of course, to keep things correct and in sync. But I'm not going to go and update HEAD on behalf of someone else right at this time, which has been missing forever, when things are trying to be finished up for 5.3. Hint: zend_operators.* (I noticed your recent cleanup stuff, and thought He has to notice.) I'm very well aware of anything I was involved with that has or hasn't been done (no hints needed). ;-) Like many, many, many things that are (I don't think it's were?) out-of-sync, Ilia can take credit for that! Off-list message from him Jan 18, 2007, after asking about when HEAD would be updated: The PHP 6 patches are up to Andrei to approve and commit, I am only looking over the 5.2 tree and occasionally the 4.4 tree as well. That was 16 months before I had a CVS account... The patch is still there [1], unchanged from that day, if someone wants to take it, update and apply or whatever before I get to it sometime after 5.3-critical stuff, I guess. I *despise* these screwed up commits to wrong branches, so you'll never catch me doing one. And I like bunnies too much (actually, don't care much either way, but that sounds nice. :O)). I'd vote for karma removal until people can learn to do stuff correctly; you'd probably agree. [1] http://realplain.com/php/is_numeric.diff --Jani - Matt Matt Wilmas kirjoitti: Hi Lukas, - Original Message - From: Lukas Kahwe Smith Sent: Monday, May 11, 2009 [...] Critical issues: 1) I assume the issues with rounding are resolved. If any issues pop up again, please let the list know. @Matt/Dmitry: Can you just give us the quick nod that all is well here? No, can't say that all is well. :-/ Nothing was changed yet, sorry if you misunderstood. (BTW, it's not rounding/parsing, but conversion/casting of floats-integers... :-)) I sent the updated patch a month ago, and then the next week Stas asked some questions off-list, for clarification, etc. and then said that the patch looks good and since it appears to fix things I think it can be applied. That's the only feedback I had really, and Dmitry mentioned that it breaks about 30 tests (I'd consider them broken now, to match the code, however ;-)), which I knew would have to be updated. I didn't try to fix them yet, since I didn't know if the changes would finally be applied or not. I was going to bring it up again but then it was too close to RC2. There were some e-mails on the subject that I didn't follow up on (nothing major, just comments), including one of yours I think. Anyway, I guess I/we can wonder about RC3 now? Again, the *very minor* modifications only help to ensure the [usual] long-standing behavior on all platforms -- e.g. most users would see no change from 5.2 or prior. I'll try to be sure to do what I can to take care of anything now, since I shouldn't be distracted with other stuff like leading up to RC2... [...] regards, Lukas Kahwe Smith m...@pooteeweet.org - Matt -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
