Re: [PHP-DEV] error handling
On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall wrote: If I hacked on the source a bit and got this redirect-error thing working, would it Be perhaps worthy of a commit? +1 Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Edin Kadribasic wrote: On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). And in the real life you sometimes must change things live on the server, in the middle of the night. If you make a mistake then, and we all do, you will go to sleep without realising that the app/web site no longer works properly. I use logwatch for this at the moment, but that is, IMHO, a very, very, clumsy solution. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GIF support
*lol* ! You could do something like --enable-have-a-lzw-license But noone can control this so unisys would consider anybody using php with gif a criminal. And i do not want to know what they think about the development of php. MAybe they find a solution to stop us because *we* are violating their patent in any way. marcus At 23:31 20.11.2002, Stefan Esser wrote: Question... Would it be illegal (patent violation) to add a compile switch to php... --enable-gif-support-and-violate-the-unisys-patent which activates the GIF support? We cleary say, that using it is a violation... As far as i know, only using the LZW Algo violates the patent, but not having it on your harddisk, or? Stefan Esser -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] GIF support
guys, how about we just like leave this for a couple of months till 2003 when the patent runs out? -- james -Original Message- From: Marcus Borger [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 10:23 AM To: Stefan Esser Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] GIF support *lol* ! You could do something like --enable-have-a-lzw-license But noone can control this so unisys would consider anybody using php with gif a criminal. And i do not want to know what they think about the development of php. MAybe they find a solution to stop us because *we* are violating their patent in any way. marcus At 23:31 20.11.2002, Stefan Esser wrote: Question... Would it be illegal (patent violation) to add a compile switch to php... --enable-gif-support-and-violate-the-unisys-patent which activates the GIF support? We cleary say, that using it is a violation... As far as i know, only using the LZW Algo violates the patent, but not having it on your harddisk, or? Stefan Esser -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, John Coggeshall wrote: Again, what about IIS, etc? Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. Never used IIS in my entire life, but I would be scared shall PHP start loosing its IIS support letting .NET and Java more space on Win32 systems. I am sure there are cases when IIS is prefered to Apache on MS servers and when MS is prefered for certain production architectures and these architectures are prefer by certain brains. Don't ask me why - I hate that myself, but we should not ignore if want to be competitive. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] Redirect on Error
Okay...
Well, even though I've yet to convince Derick and a few others... I did
see enough interest in this to create a patch. This creates two new
directives: error_redirect (bool) which turns this on/off, and
error_redirect_url (string) which is the URL to redirect to upon error.
In order for these directives to have any effect, the headers (of
course) must not have been already sent. This means that either output
buffering must be enabled, or the script never got around to outputting
anything. This patch will allow users to handle every error PHP
generates if desired (including E_PARSE, etc).
The URL which is redirected to is passed the following parameters via a
GET statement:
errno - The error number (i.e. E_PARSE, whatever)
Errfile - The path/file of the effected file
Errline - The line which the error occurred
Errmsg - The message provided describing the error:
If the redirection fails (i.e. because headers had already been sent,
whatever) the standard PHP error routine is used.
Disclaimer: This is totally meant to be RFC at this point. It works, but
Its not very friendly right now with the other error stuff (i.e.
error_prepend, etc). If I can get a +1 on this concept, I'll clean
things up before I commit.
John
--- php4/main/main.org.cThu Nov 21 05:43:05 2002
+++ php4/main/main.cThu Nov 21 05:43:18 2002
@@ -236,6 +236,8 @@
STD_PHP_INI_ENTRY(docref_root, http://www.php.net/;,
PHP_INI_ALL, OnUpdateString, docref_root,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(docref_ext, ,
PHP_INI_ALL, OnUpdateString, docref_ext,
php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(html_errors, 1,
PHP_INI_ALL, OnUpdateBool, html_errors,
php_core_globals,core_globals)
+ STD_PHP_INI_BOOLEAN(error_redirect, 0,
PHP_INI_SYSTEM, OnUpdateBool, error_redirect,
php_core_globals, core_globals)
+STD_PHP_INI_ENTRY(error_redirect_url, NULL,
PHP_INI_SYSTEM, OnUpdateString,
error_redirect_url, php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(xmlrpc_errors,0,
PHP_INI_SYSTEM, OnUpdateBool, xmlrpc_errors,
php_core_globals,core_globals)
STD_PHP_INI_ENTRY(xmlrpc_error_number,0,
PHP_INI_ALL,OnUpdateInt,
xmlrpc_error_number,php_core_globals, core_globals)
STD_PHP_INI_ENTRY(max_input_time, -1,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateInt,
max_input_time,php_core_globals,core_globals)
@@ -605,7 +607,40 @@
if (prepend_string) {
PUTS(prepend_string);
}
- php_printf(error_format, error_type_str, buffer,
error_filename, error_lineno);
+ if(PG(error_redirect) !SG(headers_sent)) {
+
+sapi_header_line ctr = {0};
+char *url_params;
+
+int out_url_len, t_header_len;
+
+url_params = do_alloca(ERRORURL_BUF_LEN);
+
+snprintf(url_params,
+ERRORURL_BUF_LEN-1,
+
?errno=%derrfile=%serrline=%derrmsg=%s,
+type,
+php_url_encode((char
*)error_filename, strlen(error_filename), NULL),
+error_lineno,
+php_url_encode(buffer,
strlen(buffer), NULL));
+
+/* The +10 is to account for Location:
*/
+t_header_len =
strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
+ctr.line = do_alloca(t_header_len);
+snprintf(ctr.line,
t_header_len+9,Location: %s%s, PG(error_redirect_url), url_params);
+
+ctr.line_len = strlen(ctr.line);
+
+sapi_header_op(SAPI_HEADER_REPLACE, ctr
TSRMLS_CC);
+
+free_alloca(url_params);
+free_alloca(ctr.line);
+
+ } else {
+
+php_printf(error_format, error_type_str,
buffer, error_filename, error_lineno);
+ }
+
if (PG(xmlrpc_errors)) {
free_alloca(error_format);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Hello PHP-Developers I have an idea! I recently went through the pain of creating an ISAPI DLL for IIS and what I found was that IIS was *incredibly* sensitive to things going wrong in the DLL with the result that the IIS process would hang and the whole damn machine would need a reboot on a regular basis. So, I went back to the drawing board for version 2 of my DLL and I designed an architecture whereby the DLL would be the thinnest I could possibly make it, and the guts would be in a separate application server. I accomplished communication between the DLL and the application server via named pipes, which are very fast and efficient on Win NT and above servers. This works fine and I've never had an IIS crash since. Why don't we move PHP into a separate executable. Design a thin ISAPI DLL which purely passes the data which the ISAPI DLL exposes between the IIS process and the PHP process (or process-pool for added reliability). The resulting page is processed in the application server and returned to the ISAPI DLL where it is output. Then if PHP crashes for whatever reason (i.e. database-client library bug), a) it won't take down IIS and b) it can simply be restarted and continue serving requests. A bit like the way it runs on UNIX really with Apache's process-pool architecture. I think this solution will be *way* easier than trying to fix every single bug in PHP so that it is utterly thread-safe and crash-free. It would also scale more nicely because you could run multiple PHP binaries across different machines if you are doing very intensive PHP stuff. I think this might solve the pain of trying to run PHP on IIS in a non-CGI environment with a relatively trivial piece of code. If anyone wants to take this on I can give source code to my DLL and application server to give you a kickstart in the right direction. Additionally if there is a problem with my idea, I'd love to hear from you all. Nick. On Thu, 21 Nov 2002, Maxim Maletsky wrote: Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, John Coggeshall wrote: Again, what about IIS, etc? Who cares? :) It really would be much better if some person who thinks IIS rulez fixes the ISAPI module. If that doesn't work correctly nobody should use it at all. Never used IIS in my entire life, but I would be scared shall PHP start loosing its IIS support letting .NET and Java more space on Win32 systems. I am sure there are cases when IIS is prefered to Apache on MS servers and when MS is prefered for certain production architectures and these architectures are prefer by certain brains. Don't ask me why - I hate that myself, but we should not ignore if want to be competitive. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GIF support
On Thu, Nov 21, 2002 at 10:25:57AM -, James Cox wrote: guys, how about we just like leave this for a couple of months till 2003 when the patent runs out? -- james I was just joking... Anyway I dislike all this patent shit. Stefan Esser -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Writing for newbies, I often heard them mentioning one things they liked about PHP (before even trying to use it) - PHP errors are not 500 weird pages made by your browser. Moving fatal errors to HTTP 500 can be somewhat confusing, unless we have a solid way handling ALL errors in some very logical way. In other words - powerful but clear enough to understand and use for neo programmers. +1 to what someone mentioned earlier - PHP is not *only* for web, it is *primarily* for web. Maybe, using HTTP headers for error handling would make this less obvious. just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] wrote... : it can; 500 means server error -- perl, cgi, mod_include, etc all do it, so why shouldn't php? -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 11:06 PM To: 'James Cox' Cc: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] error handling true... i'd like to see a 500 error though, and some persistent vars... See, the problem that I'm seeing here is that I don't believe PHP is reponsible for setting the error code returned by PHP.. For instance, a 404 error isn't handle by PHP at all. Likewise, I don't think PHP can say turn this into a 500 error to Apache. John -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:48 PM To: 'James Cox' Subject: RE: [PHP-DEV] error handling that can't really be done because parsing has happened, and so output has started -- but if we return status 500, the webserver can manage it properly.. Only if output buffering is off. Custom error handling should have output buffering on anyway as I've already said... John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Windows Threads
Shane (and everyone else): Why don't we move PHP into a separate executable. Design a thin ISAPI DLL which purely passes the data which the ISAPI DLL exposes between the IIS process and the PHP process (or process-pool for added reliability). The resulting page is processed in the application server and returned to the ISAPI DLL where it is output. Shane and I have already been looking into a similar solution for the UNIX version of PHP. In fact, if you ask'd him I think he's already got something working in this respect using FastCGI. Incidently, Shane weren't you involved in the Windows port of PHP? :) I think this solution will be *way* easier than trying to fix every single bug in PHP so that it is utterly thread-safe and crash-free. That's the idea. Part of the issue is that the external libraries PHP uses can't be promised to be thread-safe. If anyone wants to take this on I can give source code to my DLL and application server to give you a kickstart in the right direction. I'm CC'ing Shane on this... -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
Moving fatal errors to HTTP 500 can be somewhat confusing, unless we have a solid way handling ALL errors in some very logical way. In other words - powerful but clear enough to understand and use for neo programmers. Check out my patch and tell me what you think. Since this can be turned on/off (default will be off) we'll maintain the current pretty (sorta) errors and it is completely platform-independant +1 to what someone mentioned earlier - PHP is not *only* for web, it is *primarily* for web. Maybe, using HTTP headers for error handling would make this less obvious. Again, check my patch out and let me know what you think. John just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] wrote... : it can; 500 means server error -- perl, cgi, mod_include, etc all do it, so why shouldn't php? -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 11:06 PM To: 'James Cox' Cc: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] error handling true... i'd like to see a 500 error though, and some persistent vars... See, the problem that I'm seeing here is that I don't believe PHP is reponsible for setting the error code returned by PHP.. For instance, a 404 error isn't handle by PHP at all. Likewise, I don't think PHP can say turn this into a 500 error to Apache. John -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:48 PM To: 'James Cox' Subject: RE: [PHP-DEV] error handling that can't really be done because parsing has happened, and so output has started -- but if we return status 500, the webserver can manage it properly.. Only if output buffering is off. Custom error handling should have output buffering on anyway as I've already said... John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
First of all i like the way you did it.
But why do you cut the errors by using snprintf with maximum length
set to ERRORURL_BUF_LEN. Instead you can simply use spprintf
and we would get the whole message. I guess you did it because you
created a GET solution?
marcus
At 12:56 21.11.2002, John Coggeshall wrote:
Okay...
Well, even though I've yet to convince Derick and a few others... I did
see enough interest in this to create a patch. This creates two new
directives: error_redirect (bool) which turns this on/off, and
error_redirect_url (string) which is the URL to redirect to upon error.
In order for these directives to have any effect, the headers (of
course) must not have been already sent. This means that either output
buffering must be enabled, or the script never got around to outputting
anything. This patch will allow users to handle every error PHP
generates if desired (including E_PARSE, etc).
The URL which is redirected to is passed the following parameters via a
GET statement:
errno - The error number (i.e. E_PARSE, whatever)
Errfile - The path/file of the effected file
Errline - The line which the error occurred
Errmsg - The message provided describing the error:
If the redirection fails (i.e. because headers had already been sent,
whatever) the standard PHP error routine is used.
Disclaimer: This is totally meant to be RFC at this point. It works, but
Its not very friendly right now with the other error stuff (i.e.
error_prepend, etc). If I can get a +1 on this concept, I'll clean
things up before I commit.
John
--- php4/main/main.org.cThu Nov 21 05:43:05 2002
+++ php4/main/main.cThu Nov 21 05:43:18 2002
@@ -236,6 +236,8 @@
STD_PHP_INI_ENTRY(docref_root, http://www.php.net/;,
PHP_INI_ALL, OnUpdateString, docref_root,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(docref_ext, ,
PHP_INI_ALL, OnUpdateString, docref_ext,
php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(html_errors, 1,
PHP_INI_ALL, OnUpdateBool, html_errors,
php_core_globals,core_globals)
+ STD_PHP_INI_BOOLEAN(error_redirect, 0,
PHP_INI_SYSTEM, OnUpdateBool, error_redirect,
php_core_globals, core_globals)
+STD_PHP_INI_ENTRY(error_redirect_url, NULL,
PHP_INI_SYSTEM, OnUpdateString,
error_redirect_url, php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(xmlrpc_errors,0,
PHP_INI_SYSTEM, OnUpdateBool, xmlrpc_errors,
php_core_globals,core_globals)
STD_PHP_INI_ENTRY(xmlrpc_error_number,0,
PHP_INI_ALL,OnUpdateInt,
xmlrpc_error_number,php_core_globals, core_globals)
STD_PHP_INI_ENTRY(max_input_time, -1,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateInt,
max_input_time,php_core_globals,core_globals)
@@ -605,7 +607,40 @@
if (prepend_string) {
PUTS(prepend_string);
}
- php_printf(error_format, error_type_str, buffer,
error_filename, error_lineno);
+ if(PG(error_redirect) !SG(headers_sent)) {
+
+sapi_header_line ctr = {0};
+char *url_params;
+
+int out_url_len, t_header_len;
+
+url_params = do_alloca(ERRORURL_BUF_LEN);
+
+snprintf(url_params,
+ERRORURL_BUF_LEN-1,
+
?errno=%derrfile=%serrline=%derrmsg=%s,
+type,
+php_url_encode((char
*)error_filename, strlen(error_filename), NULL),
+error_lineno,
+php_url_encode(buffer,
strlen(buffer), NULL));
+
+/* The +10 is to account for Location:
*/
+t_header_len =
strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
+ctr.line = do_alloca(t_header_len);
+snprintf(ctr.line,
t_header_len+9,Location: %s%s, PG(error_redirect_url), url_params);
+
+ctr.line_len = strlen(ctr.line);
+
+sapi_header_op(SAPI_HEADER_REPLACE, ctr
TSRMLS_CC);
+
+free_alloca(url_params);
+free_alloca(ctr.line);
+
+ } else {
+
+php_printf(error_format, error_type_str,
buffer, error_filename, error_lineno);
+ }
+
if (PG(xmlrpc_errors)) {
free_alloca(error_format);
}
--
PHP Development Mailing List
RE: [PHP-DEV] [PATCH] Redirect on Error
First of all i like the way you did it.
But why do you cut the errors by using snprintf with maximum
length set to ERRORURL_BUF_LEN. Instead you can simply use
spprintf and we would get the whole message. I guess you did
it because you created a GET solution?
Well, I guess it could be implemented with spprintf -- However
For the use I really didn't see the need to use it. The only
Real variables in the string length are the filename/path and
The error-message.. These are of pretty finite length so I figured
A few kilobytes statically wouldn't hurt anyone and makes it
That much more efficient.
marcus
At 12:56 21.11.2002, John Coggeshall wrote:
Okay...
Well, even though I've yet to convince Derick and a few
others... I did
see enough interest in this to create a patch. This creates two new
directives: error_redirect (bool) which turns this on/off, and
error_redirect_url (string) which is the URL to redirect to
upon error.
In order for these directives to have any effect, the headers (of
course) must not have been already sent. This means that
either output
buffering must be enabled, or the script never got around to
outputting
anything. This patch will allow users to handle every error PHP
generates if desired (including E_PARSE, etc).
The URL which is redirected to is passed the following
parameters via a
GET statement:
errno - The error number (i.e. E_PARSE, whatever)
Errfile - The path/file of the effected file
Errline - The line which the error occurred
Errmsg - The message provided describing the error:
If the redirection fails (i.e. because headers had already been sent,
whatever) the standard PHP error routine is used.
Disclaimer: This is totally meant to be RFC at this point. It works,
but Its not very friendly right now with the other error stuff (i.e.
error_prepend, etc). If I can get a +1 on this concept, I'll clean
things up before I commit.
John
--- php4/main/main.org.cThu Nov 21 05:43:05 2002
+++ php4/main/main.cThu Nov 21 05:43:18 2002
@@ -236,6 +236,8 @@
STD_PHP_INI_ENTRY(docref_root, http://www.php.net/;,
PHP_INI_ALL, OnUpdateString, docref_root,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(docref_ext, ,
PHP_INI_ALL, OnUpdateString, docref_ext,
php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(html_errors, 1,
PHP_INI_ALL, OnUpdateBool, html_errors,
php_core_globals,core_globals)
+ STD_PHP_INI_BOOLEAN(error_redirect, 0,
PHP_INI_SYSTEM, OnUpdateBool,
error_redirect,
php_core_globals, core_globals)
+STD_PHP_INI_ENTRY(error_redirect_url, NULL,
PHP_INI_SYSTEM, OnUpdateString,
error_redirect_url, php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(xmlrpc_errors,0,
PHP_INI_SYSTEM, OnUpdateBool, xmlrpc_errors,
php_core_globals,core_globals)
STD_PHP_INI_ENTRY(xmlrpc_error_number,0,
PHP_INI_ALL,OnUpdateInt,
xmlrpc_error_number,php_core_globals, core_globals)
STD_PHP_INI_ENTRY(max_input_time, -1,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateInt,
max_input_time,php_core_globals,core_globals)
@@ -605,7 +607,40 @@
if (prepend_string) {
PUTS(prepend_string);
}
- php_printf(error_format,
error_type_str, buffer,
error_filename, error_lineno);
+ if(PG(error_redirect) !SG(headers_sent)) {
+
+sapi_header_line ctr = {0};
+char *url_params;
+
+int out_url_len, t_header_len;
+
+url_params = do_alloca(ERRORURL_BUF_LEN);
+
+snprintf(url_params,
+ERRORURL_BUF_LEN-1,
+
?errno=%derrfile=%serrline=%derrmsg=%s,
+type,
+php_url_encode((char
*)error_filename, strlen(error_filename), NULL),
+error_lineno,
+php_url_encode(buffer,
strlen(buffer), NULL));
+
+/* The +10 is to account for
Location:
*/
+t_header_len =
strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
+ctr.line = do_alloca(t_header_len);
+snprintf(ctr.line,
t_header_len+9,Location: %s%s, PG(error_redirect_url), url_params);
+
+ctr.line_len = strlen(ctr.line);
+
+sapi_header_op(SAPI_HEADER_REPLACE, ctr
TSRMLS_CC);
+
+free_alloca(url_params);
+
RE: [PHP-DEV] [PATCH] Redirect on Error
At 13:27 21.11.2002, John Coggeshall wrote: First of all i like the way you did it. But why do you cut the errors by using snprintf with maximum length set to ERRORURL_BUF_LEN. Instead you can simply use spprintf and we would get the whole message. I guess you did it because you created a GET solution? Well, I guess it could be implemented with spprintf -- However For the use I really didn't see the need to use it. The only Real variables in the string length are the filename/path and The error-message.. These are of pretty finite length so I figured A few kilobytes statically wouldn't hurt anyone and makes it That much more efficient. The problem i saw was that the errormessage itself can't be determined in its length and that you cannot use unlimited length in GET. Besides you used '' instead or arg_separator_output. (...) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I agree with Derick's assessment. I always have the option of turning display errors off (which is the recommendation for production sites) and cranking stuff out to syslog or some file I can monitor. Throwing a 500 document is ugly, and so 90's. :) Being competitive does not mean 'being like the other guys', a path PHP has carefully and rightfully avoided. Regards Mike Robinson Ivan Ristic writes: Edin Kadribasic wrote: On Thursday 21 November 2002 08:04, Derick Rethans wrote: I still think that an included file just should fail hard and I just dont like this kind of obfucsication. I agree with this 100%. It is IMHO a complete waste of time trying to handle parse errors gracefully. Most solutions proposed in this thread are either server specific or would have an impact on normal php operation (would require output buffering, etc.). And in the real life you sometimes must change things live on the server, in the middle of the night. If you make a mistake then, and we all do, you will go to sleep without realising that the app/web site no longer works properly. I use logwatch for this at the moment, but that is, IMHO, a very, very, clumsy solution. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Mike Robinson wrote: In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I assume then that you run regression tests for your web sites after every change? Or stay awake throughout the night? Or not make mistakes at all and so you have nothing to fix at nights? :)) Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Thu, 21 Nov 2002, Ivan Ristic wrote: Mike Robinson wrote: In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. I assume then that you run regression tests for your web sites after every change? Or stay awake throughout the night? Or not make mistakes at all and so you have nothing to fix at nights? We were talking about parse errors here. php -l before you put it life should be enough for that. And yes, I run that before 'cvs commit'. Also, I sleep at night and do not dream about coding or website errors at all. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] error reporting for PHP5
Guys,
I have been following the thread about error reporting thing and, I
think, it is all going off route.
Of course, the ideas John and Marcus working on both are very nice, they seem
to make many interested. But PHP's error reporting itself is very
limited. So, as often mentioned in past, the whole error reporting
logic should be redesigned at some point. PHP5 comes in mind.
I will start laying out some my thoughts to hopefully get a discussion
towards working on the complete error reporting logic. I had an
extensive experience implementing custom errors, so approve or
disapprove my ideas.
1. Error message should be ported to multiple languages. Most of the
largest app. servers do that - Oracle, for instance has a wonderful
one - you specify NLS and all the errors appear in your language.
Can't PHP be the same?
It can if, every PHP error is completely exported from C code and
stored in an XML file. The errors would be then called by passing the error
codes as numbers.
This will allow:
a) Having one XML file per language. Thus, translations can be easily
done by dozens of people without having to hassle with core and
extensions.
b) Documentation Team can edit errors files at any time and, by using
XML definitions, add any possible kind of features to it.
Something like what Marcus has been doing with docref. We could
add other important notices, relevances etc, etc. Possibilities
would be infinite.
c) Having error codes as well is handy. This can be very helpful for
docref - you can provide a link to FAQ with code in GET and help
immensely any developer understanding and debugging the error.
Few other apps do that and, I think, it could be an enormous jump for
usability of PHP.
d) Users will be able to alter their custom error codes if needed.
This could be helpful in cases when one wants to control the
appearance of error messages.
e) Any patch (like one proposed by John, for example) or
functionality on user's end that requires to recognize or store an
error can use error code to point to the specific message. For
instance, imagine this:
?php
...
// Assume that 225 is the code for Undefined variable error
// message
if(!@$var) {
// Assume we have such function that returns us last error code
if(last_error_code(225)) {
echo Failed because \$var was undefined;
}
else {
echo Failed because \$var is an empty string, zero, null or
false;
}
}
...
?
Of course, I know that you could use isset() function to work out
code below - I simply used it as the simplest example of
flexibility a user can have with this methology of coding.
f) You might add your own errors by reusing the same logic.
For instance:
?
// If you don't have error stored in XML,
// define it run-time:
register_error(346, Hey, this is what I failed like);
// To use it do simply:
trigger_error(E_ERROR, 346);
// throws user defined error on screen
?
Or, for instance, one can alter error message per-script in order
to have it differently for his case:
?
modify_error(225, Undefined Username);
// instead of just Undefined Variable
?
And things like this. Very, very useful for debugging logistics.
I believe that there will be the difficulty on dynamically passing
values to errors. Sometimes adding %s in messages might not be enough
because the words order isn't same in all languages. So, we should be
passing named values. I have done it once in one of my projects - I
can share the code.
2. Error messages can be controlled by locales runtime on multi-language
sites.
As i mentioned - this framework can be very flexible.
These are my ideas. I have been working on error reporting features
quite a few times for several clients, but mostly in PHP, where only
methodic are useful.
I think this (or whatever else that has this result) has to be
implemented in PHP from PHP5. It shouldn't break an y existing code, it
would be firstly an internal change, but it would definitely scale PHP
a lot. I would be happy to work on this if it gets approved
Now, throw all your good and bad thoughts into me :)
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
We were talking about parse errors here. php -l before you put it life should be enough for that. And yes, I run that before 'cvs commit'. Well, I am afraid that it is not that simple, as there are other fatal errors that cannot be caught and where lint is useless. For example, $object-wrong_function_name() is a fatal error. Since I am no perfect and make mistakes all the time, I would like my programming environment of choice to help me as much as possible. Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error reporting for PHP5
I quite like Maxim's ideas myself. +1 --- Maxim Maletsky [EMAIL PROTECTED] wrote: I will start laying out some my thoughts to hopefully get a discussion towards working on the complete error reporting logic. I had an extensive experience implementing custom errors, so approve or disapprove my ideas. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php and cyrillics (possibly others)
hi everyone i already checked the archives on this one, to no avail. apparantly php doesn't treat cyrillic characters quite correctly, or i don't get it; and this is an example: let's say i have a cyrillic string which i want to post to another script which then again inserts it (into oracle). i have tried all possible encoding settings and nothing worked. all that gets inserted is '??'. i'm pretty sure it's not the oci8 extension causing the problem here, since there are no character set options for ocistmtprepare and ocistmtexecute. where could i look further? thx and cheers! Abdul -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: error reporting for PHP5
I will start laying out some my thoughts to hopefully get a discussion towards working on the complete error reporting logic. I had an extensive experience implementing custom errors, so approve or disapprove my ideas. I like your ideas too, but some of your suggestions need to be compared to the exception mechanism, to avoid duplicated effort. I have been following the thread about error reporting thing and, I think, it is all going off route. While I do agree that the error handling mechanism needs to be enhanced, none of your suggestions are directly related to the error handling discussion and the patch. I think we should finish with the patch discussion first so that we can later proceed to more complex issues. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: error reporting for PHP5
Ivan Ristic [EMAIL PROTECTED] wrote... : I will start laying out some my thoughts to hopefully get a discussion towards working on the complete error reporting logic. I had an extensive experience implementing custom errors, so approve or disapprove my ideas. I like your ideas too, but some of your suggestions need to be compared to the exception mechanism, to avoid duplicated effort. You are right. Extension errors, such as the ones returned from database, should be incorporated in a way that you can pass them to the end user. I think with a little bit of logic this is very much doable. For instance, in one of the project I have done it like: Error 1256: Cannot Connect to Oracle Listener. Oracle reported $ora_error where you pass as the parameter the actual message Oracle receives. So, in my opinion it is simple do accomplish. I have been following the thread about error reporting thing and, I think, it is all going off route. While I do agree that the error handling mechanism needs to be enhanced, none of your suggestions are directly related to the error handling discussion and the patch. I think we should finish with the patch discussion first so that we can later proceed to more complex issues. Completely agree again. It is why I started the new thread. Throwing this idea on another time can sound rush. Rright now, when our heads are occupied analysing error reporting, this can result being more productive, IMO. And, it is till related anyway. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] URL for segfaults
Does anyone have an idea on how to track down segfaults from a production Apache 1.3.27/PHP 4.2.3 server? If I could just figure out the URL for the page that died, it would go a very long way... My Apache error_log file is filled with this stuff and it is hurting the server's performance: [Thu Nov 21 08:10:11 2002] [notice] child pid 12850 exit signal Segmentation fault (11) [Thu Nov 21 08:10:17 2002] [notice] child pid 12908 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12593 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12525 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12815 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12518 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12454 exit signal Segmentation fault (11) [Thu Nov 21 08:10:20 2002] [notice] child pid 12600 exit signal Segmentation fault (11) [Thu Nov 21 08:10:21 2002] [notice] child pid 12645 exit signal Segmentation fault (11) [Thu Nov 21 08:10:22 2002] [notice] child pid 12569 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 13051 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 12633 exit signal Segmentation fault (11) [Thu Nov 21 08:10:28 2002] [notice] child pid 12714 exit signal Segmentation fault (11) [Thu Nov 21 08:10:31 2002] [notice] child pid 12461 exit signal Segmentation fault (11) [Thu Nov 21 08:10:37 2002] [notice] child pid 12658 exit signal Segmentation fault (11) [Thu Nov 21 08:10:39 2002] [notice] child pid 12565 exit signal Segmentation fault (11) [Thu Nov 21 08:10:42 2002] [notice] child pid 12524 exit signal Segmentation fault (11) [Thu Nov 21 08:10:43 2002] [notice] child pid 12922 exit signal Segmentation fault (11) [Thu Nov 21 08:10:49 2002] [notice] child pid 12875 exit signal Segmentation fault (11) [Thu Nov 21 08:10:52 2002] [notice] child pid 12508 exit signal Segmentation fault (11) [Thu Nov 21 08:10:58 2002] [notice] child pid 12656 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 13076 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12826 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12659 exit signal Segmentation fault (11) [Thu Nov 21 08:11:01 2002] [notice] child pid 12812 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12982 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12780 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12740 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12540 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12778 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12603 exit signal Segmentation fault (11) [Thu Nov 21 08:11:10 2002] [notice] child pid 13079 exit signal Segmentation fault (11) [Thu Nov 21 08:11:11 2002] [notice] child pid 13080 exit signal Segmentation fault (11) [Thu Nov 21 08:11:12 2002] [notice] child pid 12823 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12712 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12455 exit signal Segmentation fault (11) [Thu Nov 21 08:11:14 2002] [notice] child pid 12701 exit signal Segmentation fault (11) [Thu Nov 21 08:11:23 2002] [notice] child pid 12672 exit signal Segmentation fault (11) Sincerely, Steven Roussey http://Network54.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] URL for segfaults
Hi ! Did you have some stranges URL request in access_log ? Michael- - Original Message - From: Steven Roussey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 21, 2002 5:39 PM Subject: [PHP-DEV] URL for segfaults Does anyone have an idea on how to track down segfaults from a production Apache 1.3.27/PHP 4.2.3 server? If I could just figure out the URL for the page that died, it would go a very long way... My Apache error_log file is filled with this stuff and it is hurting the server's performance: [Thu Nov 21 08:10:11 2002] [notice] child pid 12850 exit signal Segmentation fault (11) [Thu Nov 21 08:10:17 2002] [notice] child pid 12908 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12593 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12525 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12815 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12518 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12454 exit signal Segmentation fault (11) [Thu Nov 21 08:10:20 2002] [notice] child pid 12600 exit signal Segmentation fault (11) [Thu Nov 21 08:10:21 2002] [notice] child pid 12645 exit signal Segmentation fault (11) [Thu Nov 21 08:10:22 2002] [notice] child pid 12569 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 13051 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 12633 exit signal Segmentation fault (11) [Thu Nov 21 08:10:28 2002] [notice] child pid 12714 exit signal Segmentation fault (11) [Thu Nov 21 08:10:31 2002] [notice] child pid 12461 exit signal Segmentation fault (11) [Thu Nov 21 08:10:37 2002] [notice] child pid 12658 exit signal Segmentation fault (11) [Thu Nov 21 08:10:39 2002] [notice] child pid 12565 exit signal Segmentation fault (11) [Thu Nov 21 08:10:42 2002] [notice] child pid 12524 exit signal Segmentation fault (11) [Thu Nov 21 08:10:43 2002] [notice] child pid 12922 exit signal Segmentation fault (11) [Thu Nov 21 08:10:49 2002] [notice] child pid 12875 exit signal Segmentation fault (11) [Thu Nov 21 08:10:52 2002] [notice] child pid 12508 exit signal Segmentation fault (11) [Thu Nov 21 08:10:58 2002] [notice] child pid 12656 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 13076 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12826 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12659 exit signal Segmentation fault (11) [Thu Nov 21 08:11:01 2002] [notice] child pid 12812 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12982 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12780 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12740 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12540 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12778 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12603 exit signal Segmentation fault (11) [Thu Nov 21 08:11:10 2002] [notice] child pid 13079 exit signal Segmentation fault (11) [Thu Nov 21 08:11:11 2002] [notice] child pid 13080 exit signal Segmentation fault (11) [Thu Nov 21 08:11:12 2002] [notice] child pid 12823 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12712 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12455 exit signal Segmentation fault (11) [Thu Nov 21 08:11:14 2002] [notice] child pid 12701 exit signal Segmentation fault (11) [Thu Nov 21 08:11:23 2002] [notice] child pid 12672 exit signal Segmentation fault (11) Sincerely, Steven Roussey http://Network54.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php cyrillic
hi everyone i already checked the archives on this one, to no avail. apparantly php doesn't treat cyrillic characters quite correctly, or i don't get it; and this is an example: let's say i have a cyrillic string which i want to post to another script which then again inserts it (into oracle). i have tried all possible encoding settings and nothing worked. all that gets inserted is '??'. i'm pretty sure it's not the oci8 extension causing the problem here, since there are no character set options for ocistmtprepare and ocistmtexecute. where could i look further? thx and cheers! Abdul
[PHP-DEV] Re: error reporting for PHP5
Throwing this idea on another time can sound rush. Rright now, when our heads are occupied analysing error reporting, this can result being more productive, IMO. And, it is till related anyway. I don't mind, I just don't want the patch forgotten :) Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] URL for segfaults
Like Vergoz mentioned, just review the times in both files and you can narrow down which page caused the seg fault. On Thu, 2002-11-21 at 09:39, Steven Roussey wrote: Does anyone have an idea on how to track down segfaults from a production Apache 1.3.27/PHP 4.2.3 server? If I could just figure out the URL for the page that died, it would go a very long way... My Apache error_log file is filled with this stuff and it is hurting the server's performance: [Thu Nov 21 08:10:11 2002] [notice] child pid 12850 exit signal Segmentation fault (11) [Thu Nov 21 08:10:17 2002] [notice] child pid 12908 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12593 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12525 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12815 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12518 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12454 exit signal Segmentation fault (11) [Thu Nov 21 08:10:20 2002] [notice] child pid 12600 exit signal Segmentation fault (11) [Thu Nov 21 08:10:21 2002] [notice] child pid 12645 exit signal Segmentation fault (11) [Thu Nov 21 08:10:22 2002] [notice] child pid 12569 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 13051 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 12633 exit signal Segmentation fault (11) [Thu Nov 21 08:10:28 2002] [notice] child pid 12714 exit signal Segmentation fault (11) [Thu Nov 21 08:10:31 2002] [notice] child pid 12461 exit signal Segmentation fault (11) [Thu Nov 21 08:10:37 2002] [notice] child pid 12658 exit signal Segmentation fault (11) [Thu Nov 21 08:10:39 2002] [notice] child pid 12565 exit signal Segmentation fault (11) [Thu Nov 21 08:10:42 2002] [notice] child pid 12524 exit signal Segmentation fault (11) [Thu Nov 21 08:10:43 2002] [notice] child pid 12922 exit signal Segmentation fault (11) [Thu Nov 21 08:10:49 2002] [notice] child pid 12875 exit signal Segmentation fault (11) [Thu Nov 21 08:10:52 2002] [notice] child pid 12508 exit signal Segmentation fault (11) [Thu Nov 21 08:10:58 2002] [notice] child pid 12656 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 13076 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12826 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12659 exit signal Segmentation fault (11) [Thu Nov 21 08:11:01 2002] [notice] child pid 12812 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12982 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12780 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12740 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12540 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12778 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12603 exit signal Segmentation fault (11) [Thu Nov 21 08:11:10 2002] [notice] child pid 13079 exit signal Segmentation fault (11) [Thu Nov 21 08:11:11 2002] [notice] child pid 13080 exit signal Segmentation fault (11) [Thu Nov 21 08:11:12 2002] [notice] child pid 12823 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12712 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12455 exit signal Segmentation fault (11) [Thu Nov 21 08:11:14 2002] [notice] child pid 12701 exit signal Segmentation fault (11) [Thu Nov 21 08:11:23 2002] [notice] child pid 12672 exit signal Segmentation fault (11) Sincerely, Steven Roussey http://Network54.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] URL for segfaults
No. And I wish access_log logged requests at the beginning of a request and had the child pid. There has to be some way of discovering or logging URLs and seeing if they complete without a segfault, at which point I'd look for those that did not complete. Surely I'm missing something simple... Sincerely, Steven Roussey http://Network54.com/ -Original Message- From: Vergoz Michael [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 8:47 am To: Steven Roussey; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] URL for segfaults Hi ! Did you have some stranges URL request in access_log ? Michael- - Original Message - From: Steven Roussey [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, November 21, 2002 5:39 PM Subject: [PHP-DEV] URL for segfaults Does anyone have an idea on how to track down segfaults from a production Apache 1.3.27/PHP 4.2.3 server? If I could just figure out the URL for the page that died, it would go a very long way... My Apache error_log file is filled with this stuff and it is hurting the server's performance: [Thu Nov 21 08:10:11 2002] [notice] child pid 12850 exit signal Segmentation fault (11) [Thu Nov 21 08:10:17 2002] [notice] child pid 12908 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12593 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12525 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12815 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12518 exit signal Segmentation fault (11) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RC2
I think RC1 is going quite well (with the exception of bcmath issues, I believe?), so I propose putting out RC2 next week. If that one does just swimmingly, we should be ready for the release. -Andrei http://www.gravitonic.com/ For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Windows Threads
John Coggeshall wrote: Shane (and everyone else): Why don't we move PHP into a separate executable. Design a thin ISAPI DLL which purely passes the data which the ISAPI DLL exposes between the IIS process and the PHP process (or process-pool for added reliability). The resulting page is processed in the application server and returned to the ISAPI DLL where it is output. Shane and I have already been looking into a similar solution for the UNIX version of PHP. In fact, if you ask'd him I think he's already got something working in this respect using FastCGI. This is exactly what fastcgi does. Incidently, Shane weren't you involved in the Windows port of PHP? :) Yes, I am to blame. I think this solution will be *way* easier than trying to fix every single bug in PHP so that it is utterly thread-safe and crash-free. That's the idea. Part of the issue is that the external libraries PHP uses can't be promised to be thread-safe. An thus why I did the isapi fastcgi plugin. www.fastcgi.com Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Windows Threads
Well, that's cool then! Why not simply include all this stuff with PHP rather than supporting the flawed ISAPI that it currently is packaged with? On Thu, 21 Nov 2002, Shane Caraveo wrote: John Coggeshall wrote: Shane (and everyone else): Why don't we move PHP into a separate executable. Design a thin ISAPI DLL which purely passes the data which the ISAPI DLL exposes between the IIS process and the PHP process (or process-pool for added reliability). The resulting page is processed in the application server and returned to the ISAPI DLL where it is output. Shane and I have already been looking into a similar solution for the UNIX version of PHP. In fact, if you ask'd him I think he's already got something working in this respect using FastCGI. This is exactly what fastcgi does. Incidently, Shane weren't you involved in the Windows port of PHP? :) Yes, I am to blame. I think this solution will be *way* easier than trying to fix every single bug in PHP so that it is utterly thread-safe and crash-free. That's the idea. Part of the issue is that the external libraries PHP uses can't be promised to be thread-safe. An thus why I did the isapi fastcgi plugin. www.fastcgi.com Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] URL for segfaults
Steven Roussey wrote: No. And I wish access_log logged requests at the beginning of a request and had the child pid. It would be very easy to write a custom module to log that at the beginning of the request. Would that help? Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Windows Threads
Nick Loman wrote: Well, that's cool then! Why not simply include all this stuff with PHP rather than supporting the flawed ISAPI that it currently is packaged with? 4.3 the windows cgi binary is compiled with fastcgi support. I'm going to be testing the fastcgi on osx this week once I get things building correctly, so that should allow easy building of the cgi/fcgi binary on osx and linux. fastcgi itself is not php specific, and is supported from fastcgi.com. It's not the isapi plugin itself that is at fault, and likely not too much of the core is a problem, it is the state of thread safety in the extensions and third party libraries that are used in php. It's also a lack of good mt testing facilities. And for those who dont care about isapi, face it, you'll have the same exact problems with apache 2 mpm. Shane -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] URL for segfaults
Yes. Ideally such that you can grep for the failed URLs. I can see this as being very helpful to a lot of people. Debug modes don't work for production servers and it is only there that it is showing itself. BTW - Easy for you maybe! Sincerely, Steven Roussey http://Network54.com/ -Original Message- From: Ivan Ristic [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 9:24 am To: Steven Roussey Cc: 'Vergoz Michael'; [EMAIL PROTECTED] Subject: Re: [PHP-DEV] URL for segfaults Steven Roussey wrote: No. And I wish access_log logged requests at the beginning of a request and had the child pid. It would be very easy to write a custom module to log that at the beginning of the request. Would that help? Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] need directions adding a func.
Guys, I've added an OCI8 function in CVS the other week. I've avoided its release in RC1 so I can test it well, but it seems to be pretty stable and can be released with RC2. Since I never had to do this yet, I wanted to know a few things before I mess up something: 1. How do I get it onto ChangeLog? Normally, I would commit it with @ my Message to have it in NEWS, but I heard it is broken. What should I do? 2. Is there anything I should be aware of before tagging current oci8.c for RC2? Will all CVS be tagged for RC2 or is it left up to maintainers? 3. How would I go about adding the docs for the function? The function I refer to is OCIPasswordChange(). It allows you to handle expired Oracle users. OCIPasswordChange() is strictly based on Oracle internal permissions and directly aliases OCI. It was in TODO list for quite long time. I've been also considering disallowing this function in safe mode for security reasons. Opinions? (Thies disappeared somewhere. Anyone heard from him?) Cheers, m -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need directions adding a func.
On Thu, 21 Nov 2002, Maxim Maletsky wrote: I've added an OCI8 function in CVS the other week. I've avoided its release in RC1 so I can test it well, but it seems to be pretty stable and can be released with RC2. We dont put new functions in a release after we branched to make sure we don't introduce new bugs with functions. Since I never had to do this yet, I wanted to know a few things before I mess up something: 1. How do I get it onto ChangeLog? Normally, I would commit it with @ my Message to have it in NEWS, but I heard it is broken. What should I do? It went to ChangeLog automatically, and you should indeed just use @- before your commit message. 2. Is there anything I should be aware of before tagging current oci8.c for RC2? Will all CVS be tagged for RC2 or is it left up to maintainers? It wont be in RC2, as you didn't commit the function to the branch; and it should not be in the branch for PHP_4_3. 3. How would I go about adding the docs for the function? checkout the phpdoc module and just put a new .xml file in the en/reference/oci8 directory. The function I refer to is OCIPasswordChange(). It allows you to handle expired Oracle users. OCIPasswordChange() is strictly based on Oracle internal permissions and directly aliases OCI. It was in TODO list for quite long time. I've been also considering disallowing this function in safe mode for security reasons. Opinions? I think it should be disabled in safe_mode indeed. (Thies disappeared somewhere. Anyone heard from him?) He is at ApacheCon in las Vegas, might be just too busy. Derick -- --- Derick Rethans http://derickrethans.nl/ JDI Media Solutions --[ if you hold a unix shell to your ear, do you hear the c? ]- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] need directions adding a func.
Thanks, Derick, Derick Rethans [EMAIL PROTECTED] wrote... : On Thu, 21 Nov 2002, Maxim Maletsky wrote: I've added an OCI8 function in CVS the other week. I've avoided its release in RC1 so I can test it well, but it seems to be pretty stable and can be released with RC2. We dont put new functions in a release after we branched to make sure we don't introduce new bugs with functions. Wasn't aware of this at all. Good I asked. Since I never had to do this yet, I wanted to know a few things before I mess up something: 1. How do I get it onto ChangeLog? Normally, I would commit it with @ my Message to have it in NEWS, but I heard it is broken. What should I do? It went to ChangeLog automatically, and you should indeed just use @- before your commit message. OK. If I commit oci.c with @- as HEAD now, ChangeLog will copy it into HEAD branch for NEWS without affecting PHP_4_3, correct? Or is it better if I wait? 3. How would I go about adding the docs for the function? checkout the phpdoc module and just put a new .xml file in the en/reference/oci8 directory. Can I already start preparing it now, or better leave it for later as well? I've been also considering disallowing this function in safe mode for security reasons. Opinions? I think it should be disabled in safe_mode indeed. Will do now. -- Maxim Maletsky [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] URL for segfaults
Well, I think I found the cause if not the cure. I posted a bug report yesterday about zLib (http://bugs.php.net/?id=20535) that seems to be the culprit for another crash. Since our output compression uses it as well, I tried turning output compression off. No more segfaults. Unfortunately, I'll have to turn it back on and live with the segfaults for now until I find the problem with zLib 1.1.4. :( Luckily, I happen to have one string saved away that I know crashes it. Hopefully it will be enough to figure things out. Sincerely, Steven Roussey http://Network54.com/ On Thu, 2002-11-21 at 09:39, Steven Roussey wrote: Does anyone have an idea on how to track down segfaults from a production Apache 1.3.27/PHP 4.2.3 server? If I could just figure out the URL for the page that died, it would go a very long way... My Apache error_log file is filled with this stuff and it is hurting the server's performance: [Thu Nov 21 08:10:11 2002] [notice] child pid 12850 exit signal Segmentation fault (11) [Thu Nov 21 08:10:17 2002] [notice] child pid 12908 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12593 exit signal Segmentation fault (11) [Thu Nov 21 08:10:18 2002] [notice] child pid 12525 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12815 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12518 exit signal Segmentation fault (11) [Thu Nov 21 08:10:19 2002] [notice] child pid 12454 exit signal Segmentation fault (11) [Thu Nov 21 08:10:20 2002] [notice] child pid 12600 exit signal Segmentation fault (11) [Thu Nov 21 08:10:21 2002] [notice] child pid 12645 exit signal Segmentation fault (11) [Thu Nov 21 08:10:22 2002] [notice] child pid 12569 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 13051 exit signal Segmentation fault (11) [Thu Nov 21 08:10:25 2002] [notice] child pid 12633 exit signal Segmentation fault (11) [Thu Nov 21 08:10:28 2002] [notice] child pid 12714 exit signal Segmentation fault (11) [Thu Nov 21 08:10:31 2002] [notice] child pid 12461 exit signal Segmentation fault (11) [Thu Nov 21 08:10:37 2002] [notice] child pid 12658 exit signal Segmentation fault (11) [Thu Nov 21 08:10:39 2002] [notice] child pid 12565 exit signal Segmentation fault (11) [Thu Nov 21 08:10:42 2002] [notice] child pid 12524 exit signal Segmentation fault (11) [Thu Nov 21 08:10:43 2002] [notice] child pid 12922 exit signal Segmentation fault (11) [Thu Nov 21 08:10:49 2002] [notice] child pid 12875 exit signal Segmentation fault (11) [Thu Nov 21 08:10:52 2002] [notice] child pid 12508 exit signal Segmentation fault (11) [Thu Nov 21 08:10:58 2002] [notice] child pid 12656 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 13076 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12826 exit signal Segmentation fault (11) [Thu Nov 21 08:10:59 2002] [notice] child pid 12659 exit signal Segmentation fault (11) [Thu Nov 21 08:11:01 2002] [notice] child pid 12812 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12982 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12780 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12740 exit signal Segmentation fault (11) [Thu Nov 21 08:11:03 2002] [notice] child pid 12540 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12778 exit signal Segmentation fault (11) [Thu Nov 21 08:11:04 2002] [notice] child pid 12603 exit signal Segmentation fault (11) [Thu Nov 21 08:11:10 2002] [notice] child pid 13079 exit signal Segmentation fault (11) [Thu Nov 21 08:11:11 2002] [notice] child pid 13080 exit signal Segmentation fault (11) [Thu Nov 21 08:11:12 2002] [notice] child pid 12823 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12712 exit signal Segmentation fault (11) [Thu Nov 21 08:11:13 2002] [notice] child pid 12455 exit signal Segmentation fault (11) [Thu Nov 21 08:11:14 2002] [notice] child pid 12701 exit signal Segmentation fault (11) [Thu Nov 21 08:11:23 2002] [notice] child pid 12672 exit signal Segmentation fault (11) Sincerely, Steven Roussey http://Network54.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] URL for segfaults
Steven Roussey wrote:
Yes. Ideally such that you can grep for the failed URLs. I can see this
as being very helpful to a lot of people. Debug modes don't work for
production servers and it is only there that it is showing itself.
BTW - Easy for you maybe!
Don't take my word, have a look at it! :)
Ivan
#include httpd.h
#include http_config.h
#include http_request.h
#include http_protocol.h
#include http_core.h
#include http_main.h
#include http_log.h
module MODULE_VAR_EXPORT earlylog_module;
static int el_log(request_rec *r) {
ap_log_rerror(APLOG_MARK, APLOG_NOTICE|APLOG_NOERRNO, r, mod_earlylog: [%s]
%s, r-hostname, r-the_request);
return DECLINED;
}
module MODULE_VAR_EXPORT earlylog_module = {
STANDARD_MODULE_STUFF,
NULL, /* module initializer */
NULL, /* create per-dirconfig structures */
NULL, /* merge per-dirconfig structures */
NULL, /* create per-server config structures */
NULL, /* merge per-server config structures */
NULL, /* table of config file commands */
NULL, /* [#8] MIME-typed-dispatched handlers */
NULL, /* [#1] URI to filename translation*/
NULL, /* [#4] validate user id from request */
NULL, /* [#5] check if the user is ok _here_ */
NULL, /* [#3] check access by host address */
NULL, /* [#6] determine MIME type*/
NULL, /* [#7] pre-run fixups */
NULL, /* [#9] log a transaction */
NULL, /* [#2] header parser */
NULL, /* child_init */
NULL, /* child_exit */
el_log /* [#0] post read-request */
};
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PATCH] thread safe bcmath
At 07:06 PM 11/21/2002 +0100, Sander Roobol wrote: Hey, Attached is a patch that makes the bcmath extension thread safe. Very cool! Thanks a lot. I'm new to all that TSRM stuff, but I think this should do it. I replaced the old globals with TSRM globals (inspired by the CG() and the ext/crack implementation), and wrapped, as you proposed, all references to _zero_, _one_ and _two_ in a BCG() macro, that does basically the same as the CG() macro. Furthermore, I added TSRMLS_* macros to all bc_* functions that need it. You were talking about a new BC_ARGS macro, but I don't see any reason not to use the TSRMLS macros. Correct me if I'm wrong. When I mentioned the BC_ARGS macro I was thinking of another way but the way you did it is just as good. It now compiles and runs fine (passes all tests) both with and without ZTS. I can't test it in a multithreaded environment, so I'm asking you to look over the patch. If everything's ok, I'll commit this patch to CVS HEAD and the 4.3 branch. Yep, go ahead. This was the last thing that bugged me personally for 4.3. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZEND_PUTC question
I was looking at compile warnings for 4.3, and came across this in Zend/zend.h /* output support */ #define ZEND_WRITE(str, str_len)zend_write((str), (str_len)) #define ZEND_PUTS(str) zend_write((str), strlen((str))) #define ZEND_PUTC(c)zend_write((c), 1), (c) is there a reason why that last line isn't just #define ZEND_PUTC(c)zend_write((c), 1) ?? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] ZEND_PUTC question
Yes, so that it'll be compatible with the way libc's putc() works (the value is the written char). Andi At 01:20 PM 11/21/2002 -0800, Brad Bulger wrote: I was looking at compile warnings for 4.3, and came across this in Zend/zend.h /* output support */ #define ZEND_WRITE(str, str_len)zend_write((str), (str_len)) #define ZEND_PUTS(str) zend_write((str), strlen((str))) #define ZEND_PUTC(c)zend_write((c), 1), (c) is there a reason why that last line isn't just #define ZEND_PUTC(c)zend_write((c), 1) ?? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c zend_compile.h zend_execute.c zend_language_parser.y zend_language_scanner.l
Tried a bit with your implementation and i wonder why you
allow redeclared functions to be abstract:
class pass {
function show() {
echo Call to function show()\n;
}
}
class fail extends pass {
abstract function show();
}
Another thing i wonder is that you did not allow static abstract
while we allow mixing static and non static:
?php
class a {
static function show() { echo a\n; }
}
class b extends a{
function show() { echo b\n; }
}
class c extends b {
static function show() { echo c\n; }
}
a::show();
$t = new b();$t-show();
c::show();
?
The solution to the above is the following:
cvs -z3 -q diff zend_compile.c (in directory S:\php4-ZE2\Zend)
Index: zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.324
diff -u -r1.324 zend_compile.c
--- zend_compile.c 20 Nov 2002 18:00:21 - 1.324
+++ zend_compile.c 21 Nov 2002 22:00:25 -
@@ -1529,6 +1529,19 @@
ce-__call = ce-parent-__call;
}
+static zend_bool do_inherit_method_check(zend_function *child,
zend_function *parent) {
+ /* You cannot change from static to non static and vice versa
+*/
+ if (child-common.is_static != parent-common.is_static) {
+ if (child-common.is_static) {
+ zend_error(E_COMPILE_ERROR, Cannot make non static
function %s() static in class %s, child-common.function_name,
child-common.scope ? child-common.scope-name : );
+ } else {
+ zend_error(E_COMPILE_ERROR, Cannot make static
function %s() non static in class %s, child-common.function_name,
child-common.scope ? child-common.scope-name : );
+ }
+ }
+ return SUCCESS;
+}
+
void zend_do_inheritance(zend_class_entry *ce, zend_class_entry *parent_ce)
{
zend_function tmp_zend_function;
@@ -1540,7 +1553,7 @@
/* STATIC_MEMBERS_FIXME */
/* zend_hash_merge(ce-static_members, parent_ce-static_members,
(void (*)(void *)) zval_add_ref, (void *) tmp, sizeof(zval *), 0); */
zend_hash_merge(ce-constants_table, parent_ce-constants_table,
(void (*)(void *)) zval_add_ref, (void *) tmp, sizeof(zval *), 0);
- zend_hash_merge(ce-function_table, parent_ce-function_table,
(void (*)(void *)) function_add_ref, tmp_zend_function,
sizeof(zend_function), 0);
+ zend_hash_merge_ex(ce-function_table, parent_ce-function_table,
(void (*)(void *)) function_add_ref, sizeof(zend_function), (zend_bool
(*)(void *, void *))do_inherit_method_check);
ce-parent = parent_ce;
if (!ce-handle_property_get)
ce-handle_property_get = parent_ce-handle_property_get;
And now it prints:
/usr/src/php4-HEAD/tests/classes/static_mix.php(6) : Fatal error - Cannot
make static function show() non static in class b
marcus
At 19:00 20.11.2002, Andi Gutmans wrote:
andiWed Nov 20 13:00:24 2002 EDT
Modified files:
/ZendEngine2zend_compile.c zend_compile.h zend_execute.c
zend_language_parser.y zend_language_scanner.l
Log:
- Fix build (thanks Marcus)
- Implement abstract methods, syntax:
-abstract function foo($vars);
- I don't see any reason why modifiers such as static/public need to be
- used with abstract. PHP is weakly typed and there would be no meaning to
- this anyway. People who want a strictly typed compiled language are
- looking in the wrong place.
Index: ZendEngine2/zend_compile.c
diff -u ZendEngine2/zend_compile.c:1.323 ZendEngine2/zend_compile.c:1.324
--- ZendEngine2/zend_compile.c:1.323Sun Nov 10 17:02:28 2002
+++ ZendEngine2/zend_compile.c Wed Nov 20 13:00:21 2002
(...)
RE: [PHP-DEV] [PATCH] Redirect on Error
did you forget to return http 500 in the sapis?
-- james
-Original Message-
From: John Coggeshall [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 21, 2002 11:56 AM
To: 'PHP Developers Mailing List'
Subject: [PHP-DEV] [PATCH] Redirect on Error
Okay...
Well, even though I've yet to convince Derick and a few others... I did
see enough interest in this to create a patch. This creates two new
directives: error_redirect (bool) which turns this on/off, and
error_redirect_url (string) which is the URL to redirect to upon error.
In order for these directives to have any effect, the headers (of
course) must not have been already sent. This means that either output
buffering must be enabled, or the script never got around to outputting
anything. This patch will allow users to handle every error PHP
generates if desired (including E_PARSE, etc).
The URL which is redirected to is passed the following parameters via a
GET statement:
errno - The error number (i.e. E_PARSE, whatever)
Errfile - The path/file of the effected file
Errline - The line which the error occurred
Errmsg - The message provided describing the error:
If the redirection fails (i.e. because headers had already been sent,
whatever) the standard PHP error routine is used.
Disclaimer: This is totally meant to be RFC at this point. It works, but
Its not very friendly right now with the other error stuff (i.e.
error_prepend, etc). If I can get a +1 on this concept, I'll clean
things up before I commit.
John
--- php4/main/main.org.cThu Nov 21 05:43:05 2002
+++ php4/main/main.cThu Nov 21 05:43:18 2002
@@ -236,6 +236,8 @@
STD_PHP_INI_ENTRY(docref_root, http://www.php.net/;,
PHP_INI_ALL, OnUpdateString, docref_root,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(docref_ext, ,
PHP_INI_ALL, OnUpdateString, docref_ext,
php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(html_errors, 1,
PHP_INI_ALL, OnUpdateBool, html_errors,
php_core_globals,core_globals)
+ STD_PHP_INI_BOOLEAN(error_redirect, 0,
PHP_INI_SYSTEM, OnUpdateBool, error_redirect,
php_core_globals, core_globals)
+STD_PHP_INI_ENTRY(error_redirect_url, NULL,
PHP_INI_SYSTEM, OnUpdateString,
error_redirect_url, php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(xmlrpc_errors,0,
PHP_INI_SYSTEM, OnUpdateBool, xmlrpc_errors,
php_core_globals,core_globals)
STD_PHP_INI_ENTRY(xmlrpc_error_number,0,
PHP_INI_ALL,OnUpdateInt,
xmlrpc_error_number,php_core_globals, core_globals)
STD_PHP_INI_ENTRY(max_input_time, -1,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateInt,
max_input_time,php_core_globals,core_globals)
@@ -605,7 +607,40 @@
if (prepend_string) {
PUTS(prepend_string);
}
- php_printf(error_format, error_type_str, buffer,
error_filename, error_lineno);
+ if(PG(error_redirect) !SG(headers_sent)) {
+
+sapi_header_line ctr = {0};
+char *url_params;
+
+int out_url_len, t_header_len;
+
+url_params = do_alloca(ERRORURL_BUF_LEN);
+
+snprintf(url_params,
+ERRORURL_BUF_LEN-1,
+
?errno=%derrfile=%serrline=%derrmsg=%s,
+type,
+php_url_encode((char
*)error_filename, strlen(error_filename), NULL),
+error_lineno,
+php_url_encode(buffer,
strlen(buffer), NULL));
+
+/* The +10 is to account for Location:
*/
+t_header_len =
strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
+ctr.line = do_alloca(t_header_len);
+snprintf(ctr.line,
t_header_len+9,Location: %s%s, PG(error_redirect_url), url_params);
+
+ctr.line_len = strlen(ctr.line);
+
+sapi_header_op(SAPI_HEADER_REPLACE, ctr
TSRMLS_CC);
+
+free_alloca(url_params);
+free_alloca(ctr.line);
+
+ } else {
+
+php_printf(error_format, error_type_str,
buffer, error_filename, error_lineno);
+ }
+
if (PG(xmlrpc_errors)) {
free_alloca(error_format);
RE: [PHP-DEV] error handling
The point is that it should be possible to throw a HTTP 500 error. This is really only useful in production environments, ie, when the code going live should already be free of things like parse errors. Throwing a 500 error would make it easier to merge into your already existing error handling systems -- eg, for 404. -- james -Original Message- From: Maxim Maletsky [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 21, 2002 12:15 PM To: James Cox Cc: [EMAIL PROTECTED]; 'PHP Developers Mailing List' Subject: Re: [PHP-DEV] error handling Writing for newbies, I often heard them mentioning one things they liked about PHP (before even trying to use it) - PHP errors are not 500 weird pages made by your browser. Moving fatal errors to HTTP 500 can be somewhat confusing, unless we have a solid way handling ALL errors in some very logical way. In other words - powerful but clear enough to understand and use for neo programmers. +1 to what someone mentioned earlier - PHP is not *only* for web, it is *primarily* for web. Maybe, using HTTP headers for error handling would make this less obvious. just my +.2c -- Maxim Maletsky [EMAIL PROTECTED] James Cox [EMAIL PROTECTED] wrote... : it can; 500 means server error -- perl, cgi, mod_include, etc all do it, so why shouldn't php? -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 11:06 PM To: 'James Cox' Cc: 'PHP Developers Mailing List' Subject: RE: [PHP-DEV] error handling true... i'd like to see a 500 error though, and some persistent vars... See, the problem that I'm seeing here is that I don't believe PHP is reponsible for setting the error code returned by PHP.. For instance, a 404 error isn't handle by PHP at all. Likewise, I don't think PHP can say turn this into a 500 error to Apache. John -- james -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 20, 2002 10:48 PM To: 'James Cox' Subject: RE: [PHP-DEV] error handling that can't really be done because parsing has happened, and so output has started -- but if we return status 500, the webserver can manage it properly.. Only if output buffering is off. Custom error handling should have output buffering on anyway as I've already said... John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
In Real Life [Patent Pending], if you cripple your production site in the middle of the night then go to bed, you won't have to worry about any of this because you'd be unemployed in the morning. +1... don't commit code without QA! I agree with Derick's assessment. I always have the option of turning display errors off (which is the recommendation for production sites) and cranking stuff out to syslog or some file I can monitor. Throwing a 500 document is ugly, and so 90's. :) Being competitive does not mean 'being like the other guys', a path PHP has carefully and rightfully avoided. i see your point, but php doesn't really provide a way of halting on all errors, unless you code yourself a funky error handler and well... it gets messy. throwing http 500 is the right way to do it (tm), and i think would be better http conformance if we did. -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. if a programmer is too lazy to test, fire them. there are plenty more better ones to hire. -- james -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Redirect on Error
What is so hard to understand in word 'FATAL'?
If your script doesn't work, what use is it to make it
show the cryptic 500 error??
I'm -10 for adding anything like this, even if and
even more then if it's optional.
Just forget this.
--Jani
On Thu, 21 Nov 2002, John Coggeshall wrote:
Okay...
Well, even though I've yet to convince Derick and a few others... I did
see enough interest in this to create a patch. This creates two new
directives: error_redirect (bool) which turns this on/off, and
error_redirect_url (string) which is the URL to redirect to upon error.
In order for these directives to have any effect, the headers (of
course) must not have been already sent. This means that either output
buffering must be enabled, or the script never got around to outputting
anything. This patch will allow users to handle every error PHP
generates if desired (including E_PARSE, etc).
The URL which is redirected to is passed the following parameters via a
GET statement:
errno - The error number (i.e. E_PARSE, whatever)
Errfile - The path/file of the effected file
Errline - The line which the error occurred
Errmsg - The message provided describing the error:
If the redirection fails (i.e. because headers had already been sent,
whatever) the standard PHP error routine is used.
Disclaimer: This is totally meant to be RFC at this point. It works, but
Its not very friendly right now with the other error stuff (i.e.
error_prepend, etc). If I can get a +1 on this concept, I'll clean
things up before I commit.
John
--- php4/main/main.org.cThu Nov 21 05:43:05 2002
+++ php4/main/main.cThu Nov 21 05:43:18 2002
@@ -236,6 +236,8 @@
STD_PHP_INI_ENTRY(docref_root, http://www.php.net/;,
PHP_INI_ALL, OnUpdateString, docref_root,
php_core_globals, core_globals)
STD_PHP_INI_ENTRY(docref_ext, ,
PHP_INI_ALL, OnUpdateString, docref_ext,
php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(html_errors, 1,
PHP_INI_ALL, OnUpdateBool, html_errors,
php_core_globals,core_globals)
+ STD_PHP_INI_BOOLEAN(error_redirect, 0,
PHP_INI_SYSTEM, OnUpdateBool, error_redirect,
php_core_globals, core_globals)
+STD_PHP_INI_ENTRY(error_redirect_url, NULL,
PHP_INI_SYSTEM, OnUpdateString,
error_redirect_url, php_core_globals,core_globals)
STD_PHP_INI_BOOLEAN(xmlrpc_errors,0,
PHP_INI_SYSTEM, OnUpdateBool, xmlrpc_errors,
php_core_globals,core_globals)
STD_PHP_INI_ENTRY(xmlrpc_error_number,0,
PHP_INI_ALL,OnUpdateInt,
xmlrpc_error_number,php_core_globals, core_globals)
STD_PHP_INI_ENTRY(max_input_time, -1,
PHP_INI_SYSTEM|PHP_INI_PERDIR, OnUpdateInt,
max_input_time,php_core_globals,core_globals)
@@ -605,7 +607,40 @@
if (prepend_string) {
PUTS(prepend_string);
}
- php_printf(error_format, error_type_str, buffer,
error_filename, error_lineno);
+ if(PG(error_redirect) !SG(headers_sent)) {
+
+sapi_header_line ctr = {0};
+char *url_params;
+
+int out_url_len, t_header_len;
+
+url_params = do_alloca(ERRORURL_BUF_LEN);
+
+snprintf(url_params,
+ERRORURL_BUF_LEN-1,
+
?errno=%derrfile=%serrline=%derrmsg=%s,
+type,
+php_url_encode((char
*)error_filename, strlen(error_filename), NULL),
+error_lineno,
+php_url_encode(buffer,
strlen(buffer), NULL));
+
+/* The +10 is to account for Location:
*/
+t_header_len =
strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
+ctr.line = do_alloca(t_header_len);
+snprintf(ctr.line,
t_header_len+9,Location: %s%s, PG(error_redirect_url), url_params);
+
+ctr.line_len = strlen(ctr.line);
+
+sapi_header_op(SAPI_HEADER_REPLACE, ctr
TSRMLS_CC);
+
+free_alloca(url_params);
+free_alloca(ctr.line);
+
+ } else {
+
+php_printf(error_format, error_type_str,
buffer, error_filename, error_lineno);
+ }
+
if (PG(xmlrpc_errors)) {
free_alloca(error_format);
}
--
- For Sale!
[PHP-DEV] zend_API.c patch
In zend_API.c we do not initialize is_static for the registered function.
Therefore sometime they are static and sometimes not. We must
make those non static or provide the information in the call. Non static
is required for things like ext/domxml.
marcus
cvs -z3 -q diff zend_API.c (in directory S:\php4-ZE2\Zend)
Index: zend_API.c
===
RCS file: /repository/ZendEngine2/zend_API.c,v
retrieving revision 1.134
diff -u -r1.134 zend_API.c
--- zend_API.c 9 Oct 2002 14:21:40 - 1.134
+++ zend_API.c 21 Nov 2002 22:37:28 -
@@ -1055,6 +1055,7 @@
internal_function-arg_types = ptr-func_arg_types;
internal_function-function_name = ptr-fname;
internal_function-scope = NULL;
+ internal_function-is_static = 0;
if (!internal_function-handler) {
zend_error(error_type, Null function defined as
active function);
zend_unregister_functions(functions, count,
target_function_table TSRMLS_CC);
Re: [PHP-DEV] error handling
James Cox wrote: Also, from a management point of view (I manage programmers), what you are describing there can work in some cases but what if a programmer forgets/is-too-lazy to to that? I don't want to wait for the next morning to know about it. if a programmer is too lazy to test, fire them. there are plenty more better ones to hire. That's very funny! :) You are oversimplifying a complex issue. Real life is a series of compromises. But let us not stray anymore, this is not the subject of the discussion. If you want, you can still email me privately. Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Making NULL a scalar
It seems like the NULL type is a scalar type, ie it has a discrete set of
values. I suppose from an SQL perspective, one could argue NULL is a
special value that destroys any attempts at evaluation. However, PHP has a
precedent that relates to this issue: the ctype functions. For example,
is_alpha('') is TRUE...of course, because the null set is always a part of
every set (in textbook mathematics, anyway).
Anyway, the is_scalar() function is currently returning FALSE when passed a
NULL value. May I suggest adding the IS_NULL constant to the top part of
this function's case statement? I'm not sure if this has negative BC
issues.
I don't feel particularly passionate about this issue, it just occurred to
me as I was reviewing the function.
Comments?
Thanks,
Leon
---
Leon Atkinson http://www.leonatkinson.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP 4.3.0)
Attached is a patch that fixes bug #19207 in accordance with previous
discussion on php-dev. It add cgi.rfc2616_headers ini option which is by
default set to off and mimics current 4.3.0 behaviour. If its set to on the
HTTP status line is sent in accordance to RFC2616 which was default for PHP
4.2.3 and earlier.
Any objections to commiting this fix?
Edin
diff -u -3 -p -r1.190.2.2 cgi_main.c
--- cgi_main.c 15 Nov 2002 00:33:18 - 1.190.2.2
+++ cgi_main.c 22 Nov 2002 00:12:20 -
@@ -241,8 +241,23 @@ static int sapi_cgi_send_headers(sapi_he
int len;
sapi_header_struct *h;
zend_llist_position pos;
-
- len = sprintf(buf, Status: %d\r\n, SG(sapi_headers).http_response_code);
+ long rfc2616_headers = 0;
+
+ /* Check wheater to send RFC2616 style headers compatible with
+* PHP versions 4.2.3 and earlier compatible with web servers
+* such as IIS. Default is informal CGI RFC header compatible
+* with Apache.
+*/
+ if (cfg_get_long(cgi.rfc2616_headers, rfc2616_headers) == FAILURE) {
+rfc2616_headers = 0;
+ }
+
+ if (rfc2616_headers SG(sapi_headers).http_status_line) {
+ len = sprintf(buf, %s\r\n, SG(sapi_headers).http_status_line);
+ } else {
+ len = sprintf(buf, Status: %d\r\n,
+SG(sapi_headers).http_response_code);
+ }
+
PHPWRITE_H(buf, len);
if (SG(sapi_headers).send_default_content_type) {
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZE2 + F3P
In the following link you will find final, public, protected and private (f + 3p) for ZE2: http://marcus-boerger.de/php/ext/ze2/ What it does: - introduced final, public, protected, private member functions (methods) - Since we have aggregation already (and a patch from me some days before shows that it can work even with ZE2) and 3p member variables i thought why not having 3p member functions. - This does not make PHP a strictly typed language. But it makes PHP more OO powerfull and allows real Class-Design. - i also introduced a forth visibility private+hidden. That means when you inherit a private method it is always marked as hidden. This way you cannot overload a private method in a second derived class. You could check without inheriting the private method as hidden but that would take longer. - and i added a fifth visibility . This is currently mapped to puiblic but the informaion is kept. I could have forced this to public but found it better to keep the visibility to make it possible to display the correct decorated method string. - since abstract made it already into ZE2 i wanted to have final (overloading not allowed) what could be thought of as the opposite of abstract (must be overloaded). - Every method now knows its scope. This allows better error messages since we can allways show class and method name. Without this part of the patch we cannot allways do this. - When at compile time a class inherits methods from another class there are several checks to veify that you do not change the visibility, do not mix static and non static and do not overload private methods. - for the 'speed guys': during runtime (zend_execute.c) public static methods only have one additional check. public methods have one additional call and one additional check. protected and private checks take longer since they often require rekursive scope lookups. - 'speed guys' continued: during compile time (zend_compile.c) - before this patch we had the structure member is_static in zend_op_array/zend_function. Now we have fn_flags which stores information about abstract/final/static/public/protected/private. On modern CPUs it makes no speed difference if we have a packed bitset or single boolean values but we require less memory. - i store abstract in fn_flags to disallow overloading a method with an abstract method. There is no further change in abstract. - last but not least i made 27 tests for everything i had in mind during patching the ZendEngine. What's left: - create a global scope with a name that can be referred by the error message. Not doing this will either result in errors when working with dynaming function call by name (i guess so) or we have to check or skip class/namespace names in error messages. - i haven't experimented with aggregation yet since it does not work without my patch mentioned already. - the other OO features interfaces and such: but i remember all those were disagreed on this list. - more tests - more than i know yet - i guess :-) regards marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Fix for bug 19207 (change of cgi behaviour in PHP4.3.0)
On Fri, 22 Nov 2002, Edin Kadribasic wrote: Attached is a patch that fixes bug #19207 in accordance with previous discussion on php-dev. It add cgi.rfc2616_headers ini option which is by default set to off and mimics current 4.3.0 behaviour. If its set to on the HTTP status line is sent in accordance to RFC2616 which was default for PHP 4.2.3 and earlier. Any objections to commiting this fix? I can't remember that discussion..but why do we need yet another ini option? If the current behaviour is incorrect, and you can fix it..why do you even ask here? :) --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Compile error current head
Hi! From head i get an error when I compile it. config.nice: './configure' \ '--disable-all' \ '--prefix=/usr/local/www/php4cli' \ '--enable-debug' \ '--enable-sysvshm' \ '--enable-aggregate' \ '--enable-xslt' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-dbase' \ '--enable-dio' \ '--enable-dbx' \ '--enable-exif' \ '--enable-filepro' \ '--enable-ftp' \ '--enable-gd-native-ttf' \ '--enable-sockets' \ '--enable-yp' \ '--enable-enable-trans-sid' \ '--enable-pcntl' \ '--enable-inline-optimization' \ '--enable-cli' \ '--enable-rpath' \ '--enable-short-tags' \ '--enable-ipv6' \ '--enable-ctype' \ '--enable-overload' \ '--enable-posix' \ '--enable-session' \ '--enable-tokenizer' \ '--enable-xml' \ '--enable-libtool-lock' \ '--with-xslt-sablot=/usr/' \ '--with-expat-dir=/usr' \ '--with-qtdom' \ '--with-recode' \ '--with-mysql=/usr/' \ '--with-openssl' \ '--with-zlib-dir=/usr' \ '--with-jpeg-dir' \ '--with-tiff-dir' \ '--with-db' \ '--with-gdbm' \ '--with-dom' \ '--with-dom-xslt' \ '--with-gd' \ '--with-png-dir' \ '--with-xpm-dir' \ '--with-freetype-dir' \ '--with-ttf' \ '--with-t1lib' \ '--with-gettext' \ '--with-gmp' \ '--with-kerberos=/usr' \ '--with-ldap' \ '--with-mcrypt' \ '--with-mhash' \ '--with-unixODBC' \ '--with-snmp' \ '--with-pspell' \ '--with-readline' \ '--with-bz2' \ '--with-pcre-regex' \ '--with-pear' \ $@ Output: gcc -g -Wall ext/zlib/zlib.o ext/zlib/zlib_fopen_wrapper.o ext/bcmath/bcmath.o ext/bcmath/libbcmath/src/add.o ext/bcmath/libbcmath/src/div.o ext/bcmath/libbcmath/src/init.o ext/bcmath/libbcmath/src/neg.o ext/bcmath/libbcmath/src/outofmem.o ext/bcmath/libbcmath/src/raisemod.o ext/bcmath/libbcmath/src/rt.o ext/bcmath/libbcmath/src/sub.o ext/bcmath/libbcmath/src/compare.o ext/bcmath/libbcmath/src/divmod.o ext/bcmath/libbcmath/src/int2num.o ext/bcmath/libbcmath/src/num2long.o ext/bcmath/libbcmath/src/output.o ext/bcmath/libbcmath/src/recmul.o ext/bcmath/libbcmath/src/sqrt.o ext/bcmath/libbcmath/src/zero.o ext/bcmath/libbcmath/src/debug.o ext/bcmath/libbcmath/src/doaddsub.o ext/bcmath/libbcmath/src/nearzero.o ext/bcmath/libbcmath/src/num2str.o ext/bcmath/libbcmath/src/raise.o ext/bcmath/libbcmath/src/rmzero.o ext/bcmath/libbcmath/src/str2num.o ext/bz2/bz2.o ext/calendar/calendar.o ext/calendar/dow.o ext/calendar/french.o ext/calendar/gregor.o ext/calendar/jewish.o ext/calendar/julian.o ext/calendar/easter.o ext/calendar/cal_unix.o ext/ctype/ctype.o ext/db/db.o ext/dba/dba.o ext/dba/dba_cdb.o ext/dba/dba_db2.o ext/dba/dba_dbm.o ext/dba/dba_gdbm.o ext/dba/dba_ndbm.o ext/dba/dba_db3.o ext/dbase/dbf_head.o ext/dbase/dbf_rec.o ext/dbase/dbf_misc.o ext/dbase/dbf_ndx.o ext/dbase/dbase.o ext/dbx/dbx.o ext/dbx/dbx_mysql.o ext/dbx/dbx_odbc.o ext/dbx/dbx_pgsql.o ext/dbx/dbx_mssql.o ext/dbx/dbx_fbsql.o ext/dbx/dbx_oci8.o ext/dbx/dbx_sybasect.o ext/dio/dio.o ext/domxml/php_domxml.o ext/exif/exif.o ext/filepro/filepro.o ext/ftp/php_ftp.o ext/ftp/ftp.o ext/gd/gd.o ext/gd/gdttf.o ext/gd/libgd/gd.o ext/gd/libgd/gd_gd.o ext/gd/libgd/gd_gd2.o ext/gd/libgd/gd_io.o ext/gd/libgd/gd_io_dp.o ext/gd/libgd/gd_io_file.o ext/gd/libgd/gd_ss.o ext/gd/libgd/gd_io_ss.o ext/gd/libgd/gd_png.o ext/gd/libgd/gd_jpeg.o ext/gd/libgd/gdxpm.o ext/gd/libgd/gdfontt.o ext/gd/libgd/gdfonts.o ext/gd/libgd/gdfontmb.o ext/gd/libgd/gdfontl.o ext/gd/libgd/gdfontg.o ext/gd/libgd/gdtables.o ext/gd/libgd/gdft.o ext/gd/libgd/gdcache.o ext/gd/libgd/gdkanji.o ext/gd/libgd/wbmp.o ext/gd/libgd/gd_wbmp.o ext/gd/libgd/gdhelpers.o ext/gd/libgd/gd_topal.o ext/gd/libgd/gd_gif_in.o ext/gettext/gettext.o ext/gmp/gmp.o ext/ldap/ldap.o ext/mcrypt/mcrypt.o ext/mhash/mhash.o ext/mysql/php_mysql.o ext/odbc/php_odbc.o ext/openssl/openssl.o ext/overload/overload.o ext/pcntl/pcntl.o ext/pcntl/php_signal.o ext/pcre/pcrelib/maketables.o ext/pcre/pcrelib/get.o ext/pcre/pcrelib/study.o ext/pcre/pcrelib/pcre.o ext/pcre/php_pcre.o ext/posix/posix.o ext/pspell/pspell.o ext/qtdom/qtdom.o ext/qtdom/qtdom_qt.o ext/readline/readline.o ext/recode/recode.o ext/session/session.o ext/session/mod_files.o ext/session/mod_mm.o ext/session/mod_user.o ext/snmp/snmp.o ext/sockets/sockets.o ext/standard/array.o ext/standard/base64.o ext/standard/basic_functions.o ext/standard/browscap.o ext/standard/crc32.o ext/standard/crypt.o ext/standard/cyr_convert.o ext/standard/datetime.o ext/standard/dir.o ext/standard/dl.o ext/standard/dns.o ext/standard/exec.o ext/standard/file.o ext/standard/filestat.o ext/standard/flock_compat.o ext/standard/formatted_print.o ext/standard/fsock.o ext/standard/head.o ext/standard/html.o ext/standard/image.o ext/standard/info.o ext/standard/iptc.o ext/standard/lcg.o ext/standard/link.o ext/standard/mail.o ext/standard/math.o ext/standard/md5.o ext/standard/metaphone.o ext/standard/microtime.o ext/standard/pack.o ext/standard/pageinfo.o ext/standard/parsedate.o ext/standard/quot_print.o ext/standard/rand.o ext/standard/reg.o ext/standard/soundex.o ext/standard/string.o ext/standard/scanf.o
