Re: [PHP-DEV] Fix for bug #25543
On October 3, 2003 05:43 am, Jani Taskinen wrote: > #25543 is documentation 'bug', what exactly does your > patch fix? I don't see anything wrong with set_error_handler().. > > --Jani > > On Fri, 3 Oct 2003, Moriyoshi Koizumi wrote: > >Attached is a fix for bug #25543 (Error in set_error_handler() > > definition), which is caused by disordered scheduling of the garbage > > collection (zend_clean_garbage()). as the patch filenames suggest he meant to fix bug #25547 (error_handler and array index with function call). -- ralf willenbacher ([EMAIL PROTECTED]) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug #25543
Jani Taskinen <[EMAIL PROTECTED]> wrote: > > #25543 is documentation 'bug', what exactly does your > patch fix? I don't see anything wrong with set_error_handler().. > Oops, #25547 is the right number. Moriyoshi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] argv and argc on cliphp
Rasmus Lerdorf wrote: Andrei and I discussed this change and at the conceptual level at least $_SERVER should be populated with argc and argv if variables_order includes "S". If you have specifically configured your system to not create $_SERVER, then of course it shouldn't be there. The change was to always make argc and argv available in the CLI version regardless of the variables_order setting. As in, the CLI version will now always populate the global $argc and $argv variables. I don't really like the idea of populating two global variables, and I'm not sure where this is at right now, since I've only been following internals for the last few weeks. It's a good idea to be sure that argv and argc are always available (though, arguably, argc is not all that useful), but it would probably make more sense to put them in $_SERVER (and without the rest of the $_SERVER variables, if variables_order doesn't include "S"). You're not breaking code (since it can always use $_SERVER) and you're not introducing any globals (which goes along with the register_globals setting). Hopefully this discussion hasn't already taken place, but this is my two cents. ttyl, greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] argv and argc on cliphp
On Fri, 3 Oct 2003, Greg MacLellan wrote: > Rasmus Lerdorf wrote: > > Andrei and I discussed this change and at the conceptual level at least > > $_SERVER should be populated with argc and argv if variables_order > > includes "S". If you have specifically configured your system to not > > create $_SERVER, then of course it shouldn't be there. The change was to > > always make argc and argv available in the CLI version regardless of the > > variables_order setting. As in, the CLI version will now always populate > > the global $argc and $argv variables. > > I don't really like the idea of populating two global variables, and I'm > not sure where this is at right now, since I've only been following > internals for the last few weeks. It's a good idea to be sure that argv > and argc are always available (though, arguably, argc is not all that > useful), but it would probably make more sense to put them in $_SERVER > (and without the rest of the $_SERVER variables, if variables_order > doesn't include "S"). > > You're not breaking code (since it can always use $_SERVER) and you're > not introducing any globals (which goes along with the register_globals > setting). Sure you are, you are creating the global $_SERVER which was specifically not enabled in your scenario. To me it is more consistent with every other language out there to make $argc and $argv available directly. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PATCH: error message length limit
Hello,
First, I want to apologize in advance if this should be the wrong list for
this. Please just point me to the correct list in this case.
As noted in the documentation of the function trigger_error
(http://www.php.net/trigger_error), an error message is limited to 1024
characters. It gets truncated if it is longer.
In the PHP web application i currently develop, this can sometimes be pretty
annoying, because i use trigger_error to report error messages i get when
executing SQL queries to a custom error handler that mails me all those
errors. This error message sometimes contain SQL statements that are far
longer than 1024 characters. They get truncated, and i can not see the real
reason of the error then.
The patch i attached increases this limit by continually increasing the
buffer that should hold the error message, until the error message does not
fill up the entire buffer any more.
The patch is against 4.3.4RC1, but should still seemlessly apply to the 4.3
branch in CVS.
--- php-4.3.4RC1.orig/Zend/zend.c 2003-09-22 06:22:06.0 +0200
+++ php-4.3.4RC1/Zend/zend.c 2003-10-02 13:35:38.0 +0200
@@ -705,6 +705,7 @@
char *error_filename;
uint error_lineno;
zval *orig_user_error_handler;
+ uint errmsg_buffer_size;
TSRMLS_FETCH();
/* Obtain relevant filename and lineno */
@@ -766,22 +767,31 @@
ALLOC_INIT_ZVAL(z_error_filename);
ALLOC_INIT_ZVAL(z_error_lineno);
ALLOC_INIT_ZVAL(z_context);
- z_error_message->value.str.val = (char *) emalloc(ZEND_ERROR_BUFFER_SIZE);
+ errmsg_buffer_size = 0;
+ z_error_message->value.str.val = NULL;
+
+ do {
+errmsg_buffer_size += ZEND_ERROR_BUFFER_SIZE;
+if (NULL != z_error_message->value.str.val)
+ efree(z_error_message->value.str.val);
+z_error_message->value.str.val = (char *) emalloc(errmsg_buffer_size);
#ifdef HAVE_VSNPRINTF
- vsnprintf(z_error_message->value.str.val, ZEND_ERROR_BUFFER_SIZE, format, args);
- /* this MUST be revisited, but for now handle ALL implementation
- * out there correct. Since this is inside an error handler the
- * performance loss by strlne is irrelevant. */
- z_error_message->value.str.val[ZEND_ERROR_BUFFER_SIZE - 1] = '\0';
- z_error_message->value.str.len = strlen(z_error_message->value.str.val);
+vsnprintf(z_error_message->value.str.val, errmsg_buffer_size, format, args);
+/* this MUST be revisited, but for now handle ALL implementation
+ * out there correct. Since this is inside an error handler the
+ * performance loss by strlen is irrelevant. */
+z_error_message->value.str.val[errmsg_buffer_size - 1] = '\0';
+z_error_message->value.str.len = strlen(z_error_message->value.str.val);
#else
- strncpy(z_error_message->value.str.val, format, ZEND_ERROR_BUFFER_SIZE);
- z_error_message->value.str.val[ZEND_ERROR_BUFFER_SIZE - 1] = '\0';
- z_error_message->value.str.len = strlen(z_error_message->value.str.val);
- /* This is risky... */
- /* z_error_message->value.str.len = vsprintf(z_error_message->value.str.val, format, args); */
+strncpy(z_error_message->value.str.val, format, errmsg_buffer_size);
+z_error_message->value.str.val[errmsg_buffer_size - 1] = '\0';
+z_error_message->value.str.len = strlen(z_error_message->value.str.val);
+/* This is risky... */
+/* z_error_message->value.str.len = vsprintf(z_error_message->value.str.val, format, args); */
#endif
+ } while (z_error_message->value.str.len >= (errmsg_buffer_size - 1));
+
z_error_message->type = IS_STRING;
z_error_type->value.lval = type;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PATCH: error message length limit
Hello Aigner, Friday, October 3, 2003, 6:34:13 PM, you wrote: > Hello, > First, I want to apologize in advance if this should be the wrong list for > this. Please just point me to the correct list in this case. > As noted in the documentation of the function trigger_error > (http://www.php.net/trigger_error), an error message is limited to 1024 > characters. It gets truncated if it is longer. > In the PHP web application i currently develop, this can sometimes be pretty > annoying, because i use trigger_error to report error messages i get when > executing SQL queries to a custom error handler that mails me all those > errors. This error message sometimes contain SQL statements that are far > longer than 1024 characters. They get truncated, and i can not see the real > reason of the error then. > The patch i attached increases this limit by continually increasing the > buffer that should hold the error message, until the error message does not > fill up the entire buffer any more. > The patch is against 4.3.4RC1, but should still seemlessly apply to the 4.3 > branch in CVS. This is fixed for HEAD already and i don't think we should backport the solution to the 4.3 tree. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: farell
I request CVS access to HTML_CSS package because i'm developer on next release 0.3.0 ( see Leader Klaus Guenther ). And i'm leader of HTML_Progress package i request also access to put my code online in repository to help my contributor ( Stefan Neufeind ) to help me on next release. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug #25543
Hi, I don't like this patch because already the gc is a very sensitive mechanism and we're not allowed to collect too much or too little at any given time. Your patch can easily lead to too much being collected before previous zval's are freed which can lead to problems (this mechanism was refined a couple of times due to such problems). The only real solution I can see is to nuke the garbage completely. I already have a rough idea of how to do it but it requires quite a lot of work. BTW, I didn't quite understand the bug report 25543. It doesn't seem to be very well written (I know it's not you :) Andi At 09:32 AM 10/3/2003 +0900, Moriyoshi Koizumi wrote: Hi, Attached is a fix for bug #25543 (Error in set_error_handler() definition), which is caused by disordered scheduling of the garbage collection (zend_clean_garbage()). With this patch I'm adding the following two inline functions, zend_begin_atomic() and zend_end_atomic(), to prevent GC from being performed at the right time. Calls to those functions are inserted at the beginning / end of zend_fetch_dimension_address(), zend_fetch_property_address(), and some other functions of the same kind. I'll commit these shortly if you don't see any problem. Regards, Moriyoshi -- 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] Fix for bug #25543
Andi Gutmans <[EMAIL PROTECTED]> wrote: > Hi, > > I don't like this patch because already the gc is a very sensitive > mechanism and we're not allowed to collect too much or too little at any > given time. Your patch can easily lead to too much being collected before > previous zval's are freed which can lead to problems (this mechanism was > refined a couple of times due to such problems). > The only real solution I can see is to nuke the garbage completely. I > already have a rough idea of how to do it but it requires quite a lot of work. > BTW, I didn't quite understand the bug report 25543. It doesn't seem to be > very well written (I know it's not you :) Actually the PR number is 25547 :) Anyway, I don't think my patch is so harmful because the pointer to a zval (semantically a container of a zval instance) that has been created at certain znode construction is supposed not to be destroyed during an atomic operation, by which I mean a single opcode processing. That's why I named them zend_*_atomic(). Moriyohi > > Andi > > At 09:32 AM 10/3/2003 +0900, Moriyoshi Koizumi wrote: > >Hi, > > > >Attached is a fix for bug #25543 (Error in set_error_handler() definition), > >which is caused by disordered scheduling of the garbage collection > >(zend_clean_garbage()). > > > >With this patch I'm adding the following two inline functions, > >zend_begin_atomic() and zend_end_atomic(), to prevent GC from being > >performed at the right time. Calls to those functions are inserted > >at the beginning / end of zend_fetch_dimension_address(), > >zend_fetch_property_address(), and some other functions of the same kind. > > > >I'll commit these shortly if you don't see any problem. > > > >Regards, > > > >Moriyoshi > > > > > >-- > >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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug #25547
The actual bug report in question is 25547.. --Jani On Sat, 4 Oct 2003, Andi Gutmans wrote: >Hi, > >I don't like this patch because already the gc is a very sensitive >mechanism and we're not allowed to collect too much or too little at any >given time. Your patch can easily lead to too much being collected before >previous zval's are freed which can lead to problems (this mechanism was >refined a couple of times due to such problems). >The only real solution I can see is to nuke the garbage completely. I >already have a rough idea of how to do it but it requires quite a lot of work. >BTW, I didn't quite understand the bug report 25543. It doesn't seem to be >very well written (I know it's not you :) > >Andi > >At 09:32 AM 10/3/2003 +0900, Moriyoshi Koizumi wrote: >>Hi, >> >>Attached is a fix for bug #25543 (Error in set_error_handler() definition), >>which is caused by disordered scheduling of the garbage collection >>(zend_clean_garbage()). >> >>With this patch I'm adding the following two inline functions, >>zend_begin_atomic() and zend_end_atomic(), to prevent GC from being >>performed at the right time. Calls to those functions are inserted >>at the beginning / end of zend_fetch_dimension_address(), >>zend_fetch_property_address(), and some other functions of the same kind. >> >>I'll commit these shortly if you don't see any problem. >> >>Regards, >> >>Moriyoshi >> >> >>-- >>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
