Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
Interesting. http://icu.sourceforge.net/apiref/icu4c/ uclean_8h.html#93f27d0ddc7c196a1da864763f2d8920 Perhaps we should not call u_cleanup() at all.. -Andrei On Oct 4, 2006, at 1:42 PM, Rob Richards wrote: That does prevent the crash. I did find that within zend_shutdown, if I comment out the call to u_cleanup(), then ucol_close doesn't crash within unicode_globals_dtor during tsrm_shutdown. If that helps any. Rob Andrei Zmievski wrote: I suppose we can omit the ucol_close() call since we're shutting down completely and ICU will close all resources anyway on exit, I believe. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
That does prevent the crash. I did find that within zend_shutdown, if I comment out the call to u_cleanup(), then ucol_close doesn't crash within unicode_globals_dtor during tsrm_shutdown. If that helps any. Rob Andrei Zmievski wrote: I suppose we can omit the ucol_close() call since we're shutting down completely and ICU will close all resources anyway on exit, I believe. -Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
I suppose we can omit the ucol_close() call since we're shutting down completely and ICU will close all resources anyway on exit, I believe. -Andrei On Oct 4, 2006, at 6:28 AM, Rob Richards wrote: Seems to be a windows only problem for me. Works fine under linux, but I've tried 3 different builds of the ICU library - even built one from source - and it always crashes at the same point within the ucol_close call. Rob Andrei Zmievski wrote: Strange. I don't see it here on FreeBSD. Does anyone else have this problem? -A On Oct 3, 2006, at 4:56 AM, Rob Richards wrote: I get consistent crashes on windows during shutdown with this change. Access violation in the dtor at: ucol_close(unicode_globals->root_collator); It did open correctly as: unicode_globals->root_collator = ucol_open("en_US", &status); returned -128, which is supposedly successful. I already tried upgrading ICU to 3.4.1 but still same problem. Rob Andrei Zmievski wrote: andreiFri Sep 29 20:59:26 2006 UTC Modified files: /ZendEngine2zend.c zend_globals.h zend_unicode.c Log: Fix off-by-one error. http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c? r1=1.372&r2=1.373&diff_format=u Index: ZendEngine2/zend.c diff -u ZendEngine2/zend.c:1.372 ZendEngine2/zend.c:1.373 --- ZendEngine2/zend.c:1.372Tue Sep 19 20:44:37 2006 +++ ZendEngine2/zend.cFri Sep 29 20:59:26 2006 @@ -17,7 +17,7 @@ +--- ---+ */ -/* $Id: zend.c,v 1.372 2006/09/19 20:44:37 andrei Exp $ */ +/* $Id: zend.c,v 1.373 2006/09/29 20:59:26 andrei Exp $ */ #include "zend.h" #include "zend_extensions.h" @@ -929,11 +929,26 @@ unicode_globals->to_error_mode = ZEND_CONV_ERROR_STOP; unicode_globals->conv_error_handler = NULL; +{ +UErrorCode status = U_ZERO_ERROR; + +unicode_globals->root_collator = ucol_open("en_US", &status); +ucol_setStrength(unicode_globals->root_collator, UCOL_PRIMARY); +unicode_globals->root_search = usearch_openFromCollator(EMPTY_STR, 1, EMPTY_STR, 1, + unicode_globals->root_collator, NULL, &status); +} + zend_hash_init_ex(&unicode_globals->flex_compatible, 0, NULL, NULL, 1, 0); } static void unicode_globals_dtor(zend_unicode_globals *unicode_globals TSRMLS_DC) { +if (unicode_globals->root_collator) { +ucol_close(unicode_globals->root_collator); +} +if (unicode_globals->root_search) { +usearch_close(unicode_globals->root_search); +} if (unicode_globals->fallback_encoding_conv) { ucnv_close(unicode_globals->fallback_encoding_conv); --PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
Seems to be a windows only problem for me. Works fine under linux, but I've tried 3 different builds of the ICU library - even built one from source - and it always crashes at the same point within the ucol_close call. Rob Andrei Zmievski wrote: Strange. I don't see it here on FreeBSD. Does anyone else have this problem? -A On Oct 3, 2006, at 4:56 AM, Rob Richards wrote: I get consistent crashes on windows during shutdown with this change. Access violation in the dtor at: ucol_close(unicode_globals->root_collator); It did open correctly as: unicode_globals->root_collator = ucol_open("en_US", &status); returned -128, which is supposedly successful. I already tried upgrading ICU to 3.4.1 but still same problem. Rob Andrei Zmievski wrote: andreiFri Sep 29 20:59:26 2006 UTC Modified files: /ZendEngine2zend.c zend_globals.h zend_unicode.c Log: Fix off-by-one error. http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c?r1=1.372&r2=1.373&diff_format=u Index: ZendEngine2/zend.c diff -u ZendEngine2/zend.c:1.372 ZendEngine2/zend.c:1.373 --- ZendEngine2/zend.c:1.372Tue Sep 19 20:44:37 2006 +++ ZendEngine2/zend.cFri Sep 29 20:59:26 2006 @@ -17,7 +17,7 @@ +--+ */ -/* $Id: zend.c,v 1.372 2006/09/19 20:44:37 andrei Exp $ */ +/* $Id: zend.c,v 1.373 2006/09/29 20:59:26 andrei Exp $ */ #include "zend.h" #include "zend_extensions.h" @@ -929,11 +929,26 @@ unicode_globals->to_error_mode = ZEND_CONV_ERROR_STOP; unicode_globals->conv_error_handler = NULL; +{ +UErrorCode status = U_ZERO_ERROR; + +unicode_globals->root_collator = ucol_open("en_US", &status); +ucol_setStrength(unicode_globals->root_collator, UCOL_PRIMARY); +unicode_globals->root_search = usearch_openFromCollator(EMPTY_STR, 1, EMPTY_STR, 1, + unicode_globals->root_collator, NULL, &status); +} + zend_hash_init_ex(&unicode_globals->flex_compatible, 0, NULL, NULL, 1, 0); } static void unicode_globals_dtor(zend_unicode_globals *unicode_globals TSRMLS_DC) { +if (unicode_globals->root_collator) { +ucol_close(unicode_globals->root_collator); +} +if (unicode_globals->root_search) { +usearch_close(unicode_globals->root_search); +} if (unicode_globals->fallback_encoding_conv) { ucnv_close(unicode_globals->fallback_encoding_conv); --PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c zend_globals.h zend_unicode.c
Strange. I don't see it here on FreeBSD. Does anyone else have this problem? -A On Oct 3, 2006, at 4:56 AM, Rob Richards wrote: I get consistent crashes on windows during shutdown with this change. Access violation in the dtor at: ucol_close(unicode_globals->root_collator); It did open correctly as: unicode_globals->root_collator = ucol_open("en_US", &status); returned -128, which is supposedly successful. I already tried upgrading ICU to 3.4.1 but still same problem. Rob Andrei Zmievski wrote: andrei Fri Sep 29 20:59:26 2006 UTC Modified files: /ZendEngine2 zend.c zend_globals.h zend_unicode.c Log: Fix off-by-one error. http://cvs.php.net/viewvc.cgi/ZendEngine2/zend.c? r1=1.372&r2=1.373&diff_format=u Index: ZendEngine2/zend.c diff -u ZendEngine2/zend.c:1.372 ZendEngine2/zend.c:1.373 --- ZendEngine2/zend.c:1.372Tue Sep 19 20:44:37 2006 +++ ZendEngine2/zend.c Fri Sep 29 20:59:26 2006 @@ -17,7 +17,7 @@ +- -+ */ -/* $Id: zend.c,v 1.372 2006/09/19 20:44:37 andrei Exp $ */ +/* $Id: zend.c,v 1.373 2006/09/29 20:59:26 andrei Exp $ */ #include "zend.h" #include "zend_extensions.h" @@ -929,11 +929,26 @@ unicode_globals->to_error_mode = ZEND_CONV_ERROR_STOP; unicode_globals->conv_error_handler = NULL; + { + UErrorCode status = U_ZERO_ERROR; + + unicode_globals->root_collator = ucol_open("en_US", &status); + ucol_setStrength(unicode_globals->root_collator, UCOL_PRIMARY); + unicode_globals->root_search = usearch_openFromCollator(EMPTY_STR, 1, EMPTY_STR, 1, + unicode_globals->root_collator, NULL, &status); + } + zend_hash_init_ex(&unicode_globals->flex_compatible, 0, NULL, NULL, 1, 0); } static void unicode_globals_dtor(zend_unicode_globals *unicode_globals TSRMLS_DC) { + if (unicode_globals->root_collator) { + ucol_close(unicode_globals->root_collator); + } + if (unicode_globals->root_search) { + usearch_close(unicode_globals->root_search); + } if (unicode_globals->fallback_encoding_conv) { ucnv_close(unicode_globals->fallback_encoding_conv); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I agree with all of this. Anyone want to update README.UNICODE to reflect this change? -Andrei On Aug 16, 2005, at 4:52 PM, Andi Gutmans wrote: I think we should make the following assumptions: a) Being able to create and manipulate IS_UNICODE zvals when unicode_semantics=off will be very useful to people including the exposing of the ICU extension. b) Defining Unicode identifiers like classes/properties/functions if unicode_semantics=off does not seem useful and should be prohibited. c) People can always find ways of misusing the language & apis to reach a state which they shouldn't be reaching, For example, assuming (a) & (b) using create_function to misuse the engine and create a Unicode function name when Unicode=off. I don't believe we can or should enforce every possibility of misuse or we'll bloat the code and will never reach perfection. That said, we probably can enforce the obvious places where people try to define unicode classes/functions/properties when unicode_semantics=off. btw, I'm only referring to identifiers. If unicode=off then i believe things like arrays should support IS_UNCODE keys/values in addition to IS_STRING for reasons as in (a). As per original design those two wouldn't match though as they would when we're in full blown unicode mode. Dmitry, do you thing that not allowing unicode identifiers when unicode=off would be hard to accomplish? it would make life easier when it comes to code that sparked this discussion (and maybe harder in other cases). Due to (c) I'm king of worried of trying to simplify the model and we might just need to provide eaier to use apis to extension writers which would save them effort in checking the different options. A ggood API is key in making sure that we get a consistent implementation and upgrade of php functions. Andi At 03:13 PM 8/16/2005 -0700, Andrei Zmievski wrote: It does make the engine more complicated though, because we can't just check for UG(unicode) and expect all identifiers to be of the same type. We would actually need to amend a lot of API functions to include passing the identifier type along, e.g. zend_get_active_function() would need to return the identifier type along with the identifier itself. -Andrei On Aug 16, 2005, at 1:36 PM, Andi Gutmans wrote: IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I think we should make the following assumptions: a) Being able to create and manipulate IS_UNICODE zvals when unicode_semantics=off will be very useful to people including the exposing of the ICU extension. b) Defining Unicode identifiers like classes/properties/functions if unicode_semantics=off does not seem useful and should be prohibited. c) People can always find ways of misusing the language & apis to reach a state which they shouldn't be reaching, For example, assuming (a) & (b) using create_function to misuse the engine and create a Unicode function name when Unicode=off. I don't believe we can or should enforce every possibility of misuse or we'll bloat the code and will never reach perfection. That said, we probably can enforce the obvious places where people try to define unicode classes/functions/properties when unicode_semantics=off. btw, I'm only referring to identifiers. If unicode=off then i believe things like arrays should support IS_UNCODE keys/values in addition to IS_STRING for reasons as in (a). As per original design those two wouldn't match though as they would when we're in full blown unicode mode. Dmitry, do you thing that not allowing unicode identifiers when unicode=off would be hard to accomplish? it would make life easier when it comes to code that sparked this discussion (and maybe harder in other cases). Due to (c) I'm king of worried of trying to simplify the model and we might just need to provide eaier to use apis to extension writers which would save them effort in checking the different options. A ggood API is key in making sure that we get a consistent implementation and upgrade of php functions. Andi At 03:13 PM 8/16/2005 -0700, Andrei Zmievski wrote: It does make the engine more complicated though, because we can't just check for UG(unicode) and expect all identifiers to be of the same type. We would actually need to amend a lot of API functions to include passing the identifier type along, e.g. zend_get_active_function() would need to return the identifier type along with the identifier itself. -Andrei On Aug 16, 2005, at 1:36 PM, Andi Gutmans wrote: IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
It does make the engine more complicated though, because we can't just check for UG(unicode) and expect all identifiers to be of the same type. We would actually need to amend a lot of API functions to include passing the identifier type along, e.g. zend_get_active_function() would need to return the identifier type along with the identifier itself. -Andrei On Aug 16, 2005, at 1:36 PM, Andi Gutmans wrote: IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
IIRC if unicode_semnantics=on, we agreed to use Unicode for array offsets and properties (and do auto-conversion). however, if unicode = off, we should not do auto conversion but allow php users to manually create unicode data. when it comes to arrays we agreed that in this case they can use strings and unicode as they wish (makes sense for apps that can't make the complete move but can unicode-enable some of the app, for example, a web service). so bottom line, i dont think we can expect class name and property to be in the same encoding unless we hard code it, but i like the flexibility of being able to use unicode strings when unicode_semantics is off (this took me far too long to write :) At 10:30 AM 8/16/2005 -0700, Andrei Zmievski wrote: Hmm, should we allow this? It is much easier to deal with having common identifier type everywhere. -Andrei On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote: You aren't right. It is posiible to have unicode property in non-unicode mode (class name is string and property name is unicode). {(unicode)"asd"} = 1; var_dump($obj); ?> Dmitry. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 11:36 PM To: Dmitry Stogov Cc: [EMAIL PROTECTED] Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c Hello Dmitry, ah that's the point i didn't get. Anyway still prop_name and class_name are the same string type so still it should be zend_printf("%R:%R:private", ztype, prop_name, ztype, class_name); instead of zend_printf("%R:%v:private", ztype, prop_name, class_name); can you please check? regards marcus Monday, August 15, 2005, 4:43:49 PM, you wrote: In unicode mode class_names are always unicode. The key_type is not IS_UNICODE but ZEND_HASH_KEY_UNICODE in this code. Dmitry. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:34 PM To: Dmitry Stogov Cc: [EMAIL PROTECTED] Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c Hello Dmitry, what does this fix? The names are stored in the same value and thus should either be both unicode or native strings. Did you find something else? marcus Monday, August 15, 2005, 9:12:55 AM, you wrote: dmitry Mon Aug 15 03:12:55 2005 EDT Modified files: /ZendEngine2zend.c Log: Fixed another print_r() bug http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.314&r2=1.315&ty=u Index: ZendEngine2/zend.c diff -u ZendEngine2/zend.c:1.314 ZendEngine2/zend.c:1.315 --- ZendEngine2/zend.c:1.314Mon Aug 15 02:34:20 2005 +++ ZendEngine2/zend.c Mon Aug 15 03:12:52 2005 @@ -17,7 +17,7 @@ +- -+ */ -/* $Id: zend.c,v 1.314 2005/08/15 06:34:20 dmitry Exp $ */ +/* $Id: zend.c,v 1.315 2005/08/15 07:12:52 dmitry Exp $ */ #include "zend.h" #include "zend_extensions.h" @@ -276,7 +276,7 @@ if (class_name[0]=='*') { zend_printf("%R:protected", ztype, prop_name); } else { - zend_printf("%R:%R:private", ztype, prop_name, key_type, class_name); + zend_printf("%R:%v:private", ztype, prop_name, class_name); } } else { zend_printf("%R", ztype, prop_name); -- Zend Engine CVS Mailing List (http://cvs.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Zend Engine CVS Mailing List (http://cvs.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Andrei, if unicode is enabled we could handle all property/class and function names as unicode internally and as native strings if unicode is disabled. However that would be a slowdown, so i asked which is better, ease of coding or speed. Anyway i'd like to have property keys always be stored in one string represenation so when class or property name is unicode then store the whole thing as unicode and else store it as native strings. This involves that we store any property names as unicode if the classname is stored as unicode. This parses better? marcus Tuesday, August 16, 2005, 9:31:53 PM, you wrote: > I couldn't parse this. Could you restate your question? > -Andrei > On Aug 16, 2005, at 11:40 AM, Marcus Boerger wrote: >> >> Another thing is if we simply shouldn't treat all class/prop/fun >> names as >> native strings if unicode is off and as unicode strings if it is on. >> Or do >> you guys think that would be a too great slowdown? >> Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I couldn't parse this. Could you restate your question? -Andrei On Aug 16, 2005, at 11:40 AM, Marcus Boerger wrote: Another thing is if we simply shouldn't treat all class/prop/fun names as native strings if unicode is off and as unicode strings if it is on. Or do you guys think that would be a too great slowdown? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hello Andrei, i am actually convinced that property and class names should always be of same string type at least for the property key. If not then how the heck can we ensure that the code will work? That's why i was asking for %R being used twice and referencing the same type, that of the hash. Another thing is if we simply shouldn't treat all class/prop/fun names as native strings if unicode is off and as unicode strings if it is on. Or do you guys think that would be a too great slowdown? regards marcus Tuesday, August 16, 2005, 7:30:37 PM, you wrote: > Hmm, should we allow this? It is much easier to deal with having common > identifier type everywhere. > -Andrei > On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote: >> You aren't right. >> It is posiible to have unicode property in non-unicode mode (class >> name is >> string and property name is unicode). >> >> > $obj = new stdClass(); >> $obj->{(unicode)"asd"} = 1; >> var_dump($obj); >> ?> >> >> Dmitry. >> >>> -Original Message- >>> From: Marcus Boerger [mailto:[EMAIL PROTECTED] >>> Sent: Monday, August 15, 2005 11:36 PM >>> To: Dmitry Stogov >>> Cc: [EMAIL PROTECTED] >>> Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c >>> >>> >>> Hello Dmitry, >>> >>> ah that's the point i didn't get. Anyway still prop_name >>> and class_name are the same string type so still it should be >>> zend_printf("%R:%R:private", ztype, prop_name, ztype, >>> class_name); instead of zend_printf("%R:%v:private", ztype, >>> prop_name, class_name); >>> >>> can you please check? >>> >>> regards >>> marcus >>> >>> >>> Monday, August 15, 2005, 4:43:49 PM, you wrote: >>> In unicode mode class_names are always unicode. >>> The key_type is not IS_UNICODE but ZEND_HASH_KEY_UNICODE in >>> this code. >>> Dmitry. >>> > -Original Message- > From: Marcus Boerger [mailto:[EMAIL PROTECTED] > Sent: Monday, August 15, 2005 12:34 PM > To: Dmitry Stogov > Cc: [EMAIL PROTECTED] > Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c > > > Hello Dmitry, > > what does this fix? The names are stored in the same value > and thus should either be both unicode or native strings. Did > you find something else? > > marcus > > Monday, August 15, 2005, 9:12:55 AM, you wrote: > >> dmitry Mon Aug 15 03:12:55 2005 EDT > >> Modified files: >> /ZendEngine2zend.c >> Log: >> Fixed another print_r() bug > > >> > >>> http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.314&r2=1.315&ty=u >> Index: ZendEngine2/zend.c >> diff -u ZendEngine2/zend.c:1.314 ZendEngine2/zend.c:1.315 >> --- ZendEngine2/zend.c:1.314Mon Aug 15 02:34:20 2005 >> +++ ZendEngine2/zend.c Mon Aug 15 03:12:52 2005 >> @@ -17,7 +17,7 @@ >> >> > +- > -+ >> */ > >> -/* $Id: zend.c,v 1.314 2005/08/15 06:34:20 dmitry Exp $ */ >> +/* $Id: zend.c,v 1.315 2005/08/15 07:12:52 dmitry Exp $ */ > >> #include "zend.h" >> #include "zend_extensions.h" >> @@ -276,7 +276,7 @@ >> if >> (class_name[0]=='*') { >> >> zend_printf("%R:protected", ztype, prop_name); >> } else { >> - >> zend_printf("%R:%R:private", ztype, prop_name, key_type, > class_name); >> + >> zend_printf("%R:%v:private", ztype, prop_name, class_name); >> } >> } else { >> zend_printf("%R", >> ztype, prop_name); -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Hmm, should we allow this? It is much easier to deal with having common identifier type everywhere. -Andrei On Aug 15, 2005, at 11:41 PM, Dmitry Stogov wrote: You aren't right. It is posiible to have unicode property in non-unicode mode (class name is string and property name is unicode). {(unicode)"asd"} = 1; var_dump($obj); ?> Dmitry. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 11:36 PM To: Dmitry Stogov Cc: [EMAIL PROTECTED] Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c Hello Dmitry, ah that's the point i didn't get. Anyway still prop_name and class_name are the same string type so still it should be zend_printf("%R:%R:private", ztype, prop_name, ztype, class_name); instead of zend_printf("%R:%v:private", ztype, prop_name, class_name); can you please check? regards marcus Monday, August 15, 2005, 4:43:49 PM, you wrote: In unicode mode class_names are always unicode. The key_type is not IS_UNICODE but ZEND_HASH_KEY_UNICODE in this code. Dmitry. -Original Message- From: Marcus Boerger [mailto:[EMAIL PROTECTED] Sent: Monday, August 15, 2005 12:34 PM To: Dmitry Stogov Cc: [EMAIL PROTECTED] Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c Hello Dmitry, what does this fix? The names are stored in the same value and thus should either be both unicode or native strings. Did you find something else? marcus Monday, August 15, 2005, 9:12:55 AM, you wrote: dmitry Mon Aug 15 03:12:55 2005 EDT Modified files: /ZendEngine2zend.c Log: Fixed another print_r() bug http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.314&r2=1.315&ty=u Index: ZendEngine2/zend.c diff -u ZendEngine2/zend.c:1.314 ZendEngine2/zend.c:1.315 --- ZendEngine2/zend.c:1.314Mon Aug 15 02:34:20 2005 +++ ZendEngine2/zend.c Mon Aug 15 03:12:52 2005 @@ -17,7 +17,7 @@ +- -+ */ -/* $Id: zend.c,v 1.314 2005/08/15 06:34:20 dmitry Exp $ */ +/* $Id: zend.c,v 1.315 2005/08/15 07:12:52 dmitry Exp $ */ #include "zend.h" #include "zend_extensions.h" @@ -276,7 +276,7 @@ if (class_name[0]=='*') { zend_printf("%R:protected", ztype, prop_name); } else { - zend_printf("%R:%R:private", ztype, prop_name, key_type, class_name); + zend_printf("%R:%v:private", ztype, prop_name, class_name); } } else { zend_printf("%R", ztype, prop_name); -- Zend Engine CVS Mailing List (http://cvs.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Zend Engine CVS Mailing List (http://cvs.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I'd like to see this in PHP4 too. -Rasmus On Tue, 1 Jun 2004, Andrei Zmievski wrote: > Should we add this to PHP 4 as well? > > On Tue, 01 Jun 2004, Andi Gutmans wrote: > > andiTue Jun 1 07:45:46 2004 EDT > > > > Modified files: > > /ZendEngine2zend.c > > Log: > > - If user error handler returns "false" then we relay to the built in error > > handler > > > > > > http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284&r2=1.285&ty=u > > Index: ZendEngine2/zend.c > > diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285 > > --- ZendEngine2/zend.c:1.284Fri May 28 13:28:33 2004 > > +++ ZendEngine2/zend.c Tue Jun 1 07:45:46 2004 > > @@ -17,7 +17,7 @@ > > +--+ > > */ > > > > -/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */ > > +/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */ > > > > #include "zend.h" > > #include "zend_extensions.h" > > @@ -974,7 +974,7 @@ > > > > if (call_user_function_ex(CG(function_table), NULL, > > orig_user_error_handler, &retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) { > > if (retval) { > > - if (Z_TYPE_P(retval) != IS_NULL && > > !zend_is_true(retval)) { > > + if (Z_TYPE_P(retval) == IS_BOOL && > > Z_LVAL_P(retval) == 0) { > > zend_error_cb(type, error_filename, > > error_lineno, format, args); > > } > > zval_ptr_dtor(&retval); > > > > -- > > Zend Engine CVS Mailing List (http://cvs.php.net/) > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > - Andrei > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
I think it's OK to add. At 09:26 AM 6/1/2004 -0700, Andrei Zmievski wrote: Should we add this to PHP 4 as well? On Tue, 01 Jun 2004, Andi Gutmans wrote: > andi Tue Jun 1 07:45:46 2004 EDT > > Modified files: > /ZendEngine2 zend.c > Log: > - If user error handler returns "false" then we relay to the built in error > handler > > > http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284&r2=1.285&ty=u > Index: ZendEngine2/zend.c > diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285 > --- ZendEngine2/zend.c:1.284 Fri May 28 13:28:33 2004 > +++ ZendEngine2/zend.cTue Jun 1 07:45:46 2004 > @@ -17,7 +17,7 @@ > +--+ > */ > > -/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */ > +/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */ > > #include "zend.h" > #include "zend_extensions.h" > @@ -974,7 +974,7 @@ > > if (call_user_function_ex(CG(function_table), NULL, orig_user_error_handler, &retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) { > if (retval) { > - if (Z_TYPE_P(retval) != IS_NULL && !zend_is_true(retval)) { > + if (Z_TYPE_P(retval) == IS_BOOL && Z_LVAL_P(retval) == 0) { > zend_error_cb(type, error_filename, error_lineno, format, args); > } > zval_ptr_dtor(&retval); > > -- > Zend Engine CVS Mailing List (http://cvs.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Should we add this to PHP 4 as well? On Tue, 01 Jun 2004, Andi Gutmans wrote: > andi Tue Jun 1 07:45:46 2004 EDT > > Modified files: > /ZendEngine2 zend.c > Log: > - If user error handler returns "false" then we relay to the built in error > handler > > > http://cvs.php.net/diff.php/ZendEngine2/zend.c?r1=1.284&r2=1.285&ty=u > Index: ZendEngine2/zend.c > diff -u ZendEngine2/zend.c:1.284 ZendEngine2/zend.c:1.285 > --- ZendEngine2/zend.c:1.284 Fri May 28 13:28:33 2004 > +++ ZendEngine2/zend.cTue Jun 1 07:45:46 2004 > @@ -17,7 +17,7 @@ > +--+ > */ > > -/* $Id: zend.c,v 1.284 2004/05/28 17:28:33 andrei Exp $ */ > +/* $Id: zend.c,v 1.285 2004/06/01 11:45:46 andi Exp $ */ > > #include "zend.h" > #include "zend_extensions.h" > @@ -974,7 +974,7 @@ > > if (call_user_function_ex(CG(function_table), NULL, > orig_user_error_handler, &retval, 5, params, 1, NULL TSRMLS_CC)==SUCCESS) { > if (retval) { > - if (Z_TYPE_P(retval) != IS_NULL && > !zend_is_true(retval)) { > + if (Z_TYPE_P(retval) == IS_BOOL && > Z_LVAL_P(retval) == 0) { > zend_error_cb(type, error_filename, > error_lineno, format, args); > } > zval_ptr_dtor(&retval); > > -- > Zend Engine CVS Mailing List (http://cvs.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php - Andrei -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
At 12:54 AM 12/20/2003 +0900, Moriyoshi Koizumi wrote: On 2003/12/20, at 0:21, Dmitry Stogov wrote: Hi Moriyoshi, Yes I am sure. Andi approved this patch today. I didn't know about your patch. May be you know some situations when my patch will not work properly? As far as I looked over the patch, your patch appears the right fix for the problem. I asked you it because I was told by Andi that the garbage collection is sensitive stuff and handled with extreme care. Actually I think nothing will be wrong with it. However, I suspect that we don't need to replicate the same garbage collecting code to that place. I think all we have to do is delay the GC timing so it would be performed after the error handler is executed. Just to explain in a bit more detail, your atomic postponing of garbage collecting isn't good because too much can accumulate and/or the life time of garbage could be too long. I think Dmitry's patch handles this slightly in a different way and better although as I said, a thorough fix should be done. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
On 2003/12/20, at 1:36, Dmitry Stogov wrote: I do GC after error_handler execution, because GC stack has limited size and if I will try to link old garbage with garbage from error_handler I can overflow it. Okay, so it seems my patch was not sufficient as it's still possible GC stack will overflow. Then, could you take a look at the 4.3 branch also? It still seems to have the same problem as HEAD. Besides operations on undefined object properties lead to the same situation with ZE1. (I wasn't able to verify it with ZE2.) function foo($x) { return "foo"; } set_error_handler('custom_err_hdlr'); $a->b[foo("bar")]++; ?> With the above snippet, valgrind reported the following leaks: ==2279== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==2279== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==2279== Using valgrind-2.0.0, a program supervision framework for x86-linux. ==2279== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==2279== Estimated CPU clock rate is 1001 MHz ==2279== For more details, rerun with: -v ==2279== ==2279== Conditional jump or move depends on uninitialised value(s) ==2279==at 0x40009520: _dl_relocate_object (in /lib/ld-2.3.2.so) ==2279==by 0x407E1E25: (within /lib/libc-2.3.2.so) ==2279==by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so) ==2279==by 0x407E20A8: _dl_open (in /lib/libc-2.3.2.so) ==2279== ==2279== Conditional jump or move depends on uninitialised value(s) ==2279==at 0x40009575: _dl_relocate_object (in /lib/ld-2.3.2.so) ==2279==by 0x407E1E25: (within /lib/libc-2.3.2.so) ==2279==by 0x4000BF15: _dl_catch_error (in /lib/ld-2.3.2.so) ==2279==by 0x407E20A8: _dl_open (in /lib/libc-2.3.2.so) ==2279== ==2279== Invalid read of size 1 ==2279==at 0x81CCB53: zend_hash_add_or_update (zend_hash.c:238) ==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner (zend_execute.c:648) ==2279==by 0x81D6BEA: zend_fetch_dimension_address (zend_execute.c:787) ==2279==by 0x81D8A3B: execute (zend_execute.c:1290) ==2279==Address 0x42334F14 is 36 bytes inside a block of size 48 free'd ==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310) ==2279==by 0x81B6662: _erealloc (zend_alloc.c:323) ==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017) ==2279==by 0x81D9C1D: execute (zend_execute.c:1483) ==2279== ==2279== Invalid read of size 1 ==2279==at 0x81CCB5E: zend_hash_add_or_update (zend_hash.c:238) ==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner (zend_execute.c:648) ==2279==by 0x81D6BEA: zend_fetch_dimension_address (zend_execute.c:787) ==2279==by 0x81D8A3B: execute (zend_execute.c:1290) ==2279==Address 0x42334F14 is 36 bytes inside a block of size 48 free'd ==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310) ==2279==by 0x81B6662: _erealloc (zend_alloc.c:323) ==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017) ==2279==by 0x81D9C1D: execute (zend_execute.c:1483) ==2279== ==2279== Invalid read of size 1 ==2279==at 0x81CFE99: zend_inline_hash_func (zend_hash.h:198) ==2279==by 0x81CCCA4: zend_hash_add_or_update (zend_hash.c:240) ==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner (zend_execute.c:648) ==2279==by 0x81D6BEA: zend_fetch_dimension_address (zend_execute.c:787) ==2279==Address 0x42334F14 is 36 bytes inside a block of size 48 free'd ==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310) ==2279==by 0x81B6662: _erealloc (zend_alloc.c:323) ==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017) ==2279==by 0x81D9C1D: execute (zend_execute.c:1483) ==2279== ==2279== Invalid read of size 1 ==2279==at 0x4002433F: memcpy (mac_replace_strmem.c:258) ==2279==by 0x81CCF57: zend_hash_add_or_update (zend_hash.c:276) ==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner (zend_execute.c:648) ==2279==by 0x81D6BEA: zend_fetch_dimension_address (zend_execute.c:787) ==2279==Address 0x42334F17 is 39 bytes inside a block of size 48 free'd ==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310) ==2279==by 0x81B6662: _erealloc (zend_alloc.c:323) ==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017) ==2279==by 0x81D9C1D: execute (zend_execute.c:1483) ==2279== ==2279== Invalid read of size 1 ==2279==at 0x40024346: memcpy (mac_replace_strmem.c:259) ==2279==by 0x81CCF57: zend_hash_add_or_update (zend_hash.c:276) ==2279==by 0x81DF3E7: zend_fetch_dimension_address_inner (zend_execute.c:648) ==2279==by 0x81D6BEA: zend_fetch_dimension_address (zend_execute.c:787) ==2279==Address 0x42334F16 is 38 bytes inside a block of size 48 free'd ==2279==at 0x4002D07F: realloc (vg_replace_malloc.c:310) ==2279==by 0x81B6662: _erealloc (zend_alloc.c:323) ==2279==by 0x81C44B7: add_string_to_string (zend_operators.c:1017) ==2279==by 0x81D9C1D: execute (zend_execute.c:1483) ==2279== ==2279== Invalid read of
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
On 2003/12/20, at 0:21, Dmitry Stogov wrote: Hi Moriyoshi, Yes I am sure. Andi approved this patch today. I didn't know about your patch. May be you know some situations when my patch will not work properly? As far as I looked over the patch, your patch appears the right fix for the problem. I asked you it because I was told by Andi that the garbage collection is sensitive stuff and handled with extreme care. Actually I think nothing will be wrong with it. However, I suspect that we don't need to replicate the same garbage collecting code to that place. I think all we have to do is delay the GC timing so it would be performed after the error handler is executed. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Zeev Suraski wrote: > Was it crashing under a specific script, or always? Always since the "MEGA-patch: namespaces are R.I.P.". -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ http://www.professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Zeev Suraski wrote: > When was it crashing, prior to that fix? zend.c:1.231 segfaulted. In zend.c:1.232 I "fixed" the segfault, or what fix did you mean? -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ http://www.professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
At 23:00 05/06/2003, Sebastian Bergmann wrote: Zeev Suraski wrote: > It does look like a voodoo fix. What's crashing exactly? Zeev, Stanislav already looked into this and the segfault related to GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone. But with a fairly odd fix. When was it crashing, prior to that fix? Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Zeev Suraski wrote: > It does look like a voodoo fix. What's crashing exactly? Zeev, Stanislav already looked into this and the segfault related to GLOBAL_CONSTANTS_TABLE not beeing malloc()ed in ZTS mode is now gone. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ http://www.professionelle-softwareentwicklung-mit-php5.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
On Wed, 4 Jun 2003, Sebastian Bergmann wrote: > Marcus Börger wrote: > > So he should be forgiven if he doesn't try all version. > > Marcus, Derick, *, > > relax. Don't "defend" me, as I feel not "offended". For the first time > I did not test a non-ZTS build before committing a ZTS fix, so it was a > mistake on my side. Hi Sebastian, I found Stanislav's comments offensive no matter that they were sent to you. My guess other people felt offended by that attitude as well. Edin -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Marcus Börger wrote: So he should be forgiven if he doesn't try all version. Marcus, Derick, *, relax. Don't "defend" me, as I feel not "offended". For the first time I did not test a non-ZTS build before committing a ZTS fix, so it was a mistake on my side. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
At 15:43 04.06.2003, Sebastian Bergmann wrote: Thies C. Arntzen wrote: > i trust you;-) but - after looking thru zend.c - i think that > the TLS stuff is getting more and more un-maintainable. What really looks messed up is #ifdef ZTS ... #ifdef ZTS ... #else ... #endif ... #endif And there is really no reson for. Really not. marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Thies C. Arntzen wrote: > i trust you;-) but - after looking thru zend.c - i think that > the TLS stuff is getting more and more un-maintainable. What really looks messed up is #ifdef ZTS ... #ifdef ZTS ... #else ... #endif ... #endif -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend.c
Stanislav Malyshev wrote: > _explain_ what you are doing instead of submitting patched that don't > even compile? It compiles fine here (Debug_TS build on Windows). Without that patch it compiles as well, but segfaults during startup. See http://news.php.net/article.php?group=php.internals&article=2125 for a backtrace and http://news.php.net/article.php?group=php.internals&article=2136 for its analysis (GLOBAL_CONSTANTS_TABLE is not malloced). -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php