RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: |I know this is possible now, but not within the error handling |function of PHP, or without setting a custom error handler. Well, it's not really possible now -- a E_PARSE won't get thrown to a custom PHP handler, it'll just die with a parse error. And this can never be supported safely, as a parse error leaves the parse in an unstable state. Also, I really don't think that we should try to add hacks to make this possible. 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] error handling
|And this can never be supported safely, as a parse error leaves the |parse in an unstable state. Also, I really don't think that we should |try to add hacks to make this possible. Is this directed toward my wish (of having a secondary error if the custom error handler also errors) or toward Mattia's suggestion? John |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] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: |And this can never be supported safely, as a parse error leaves the |parse in an unstable state. Also, I really don't think that we should |try to add hacks to make this possible. Is this directed toward my wish (of having a secondary error if the custom error handler also errors) or toward Mattia's suggestion? Both? I'm not totally sure what you mean with when the custom error handler also has errors. Can you elaborate? (and can you please use for quoting mail?) 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] error handling
Well, I certainly don't want errors handled this way for my web apps. And you would be hard pressed to find 2 people on this list that agree exactly how to do it which is why PHP provides you with the tools to do it any way you want. -Rasmus On Mon, 18 Nov 2002, Mattia wrote: I think in a modern web application the error handling function should do the following: in case of error (any: parse error, internal application error,) 1. a message should be shown to the user sayng that an error has occured like an internal error has occured. the webmaster has been notified via email 2. a more detailed message should be logged in a generic system ErrorLog, or notified via email or fax, or telephone, or SMS. Depending on the severity of the error (warning, fatal,...) All this done with PHP error handling function (this is not to male distinction between PHP error and application internal error), and the ErrorLog kept via system/server methods (like syslogd). The message shown to the user should be accompained by an HTTP 500 (or more) error. This to make clear to human users that an error has occured therefore the request cannot be fulfilled, and if the cliens is another computer (robot,...) to make it as well (computer look at error codes rather than at things written for humans. I know this is possible now, but not within the error handling function of PHP, or without setting a custom error handler. Mattia Cazzola -- 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
Both? I'm not totally sure what you mean with when the custom error
handler also has errors. Can you elaborate?
Okay
?php
set_error_handler(myerrorhandler);
function myerrorhandler($errno, $errstr, $errfile, $errline) {
echo There was an error.;
$int = 10 / 0 ; // Divide by zero error
}
echo This will break
?
Which would output something like this:
Error: There was an parse error on line X of file.php.
Additional Error: Custom error handler myerrorhandler() also errored in
line X of file.php
What I mean here is that, allow PHP to have custom error handlers for
core errors instead of just the user-defined errors.
Am I being clear?
John
(and can you please use for quoting mail?)
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] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote:
Both? I'm not totally sure what you mean with when the custom error
handler also has errors. Can you elaborate?
Okay
?php
set_error_handler(myerrorhandler);
function myerrorhandler($errno, $errstr, $errfile, $errline) {
echo There was an error.;
$int = 10 / 0 ; // Divide by zero error
}
echo This will break
?
Which would output something like this:
Error: There was an parse error on line X of file.php.
Additional Error: Custom error handler myerrorhandler() also errored in
line X of file.php
What I mean here is that, allow PHP to have custom error handlers for
core errors instead of just the user-defined errors.
Core errors are _fatal_ because it leaves the engine in an unclean
state. If you have a parse error then the script hasn't been parsed
fully and thus the compilation step did not even interpreted the tokens
generated by the parse, so how do you want PHP to execute a function then?
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] CVS Account Request: monomelodies
Would like to be involved in further development, since I'm using PHP intensively. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: But why do you assume that the documentation was right and the code was wrong and not the other way around? Because it was working like documented before. (When the documentation was written). Anyway, not sure what to do with this one... I don't have the energy to do a cvs check, but I remember adding this restriction years ago (php2 days) and then removing it (by commenting out the check) ages ago as well. I'm not sure PHP4 ever had this check turned on (the commented out check was ported to php4), so the documentation has not reflected reality in a very long time. I agree that this change is going to break a lot of code. Some of it is my own :) I suggest that we always populate $PHP_AUTH_USER since that one has no security consequences and the information is awailable elsewhere ($_SERVER['REMOTE_USER']). $PHP_AUTH_PW should be set when there are no safe_mode/open_basedir restrctions in effects. Would this solution be satisfactory to everyone? Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Mon, 18 Nov 2002, Edin Kadribasic wrote: On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: I don't have the energy to do a cvs check, but I remember adding this restriction years ago (php2 days) and then removing it (by commenting out the check) ages ago as well. I'm not sure PHP4 ever had this check turned on (the commented out check was ported to php4), so the documentation has not reflected reality in a very long time. I agree that this change is going to break a lot of code. Some of it is my own :) I suggest that we always populate $PHP_AUTH_USER since that one has no security consequences and the information is awailable elsewhere ($_SERVER['REMOTE_USER']). $PHP_AUTH_PW should be set when there are no safe_mode/open_basedir restrctions in effects. Would this solution be satisfactory to everyone? Perfectly fine with me. 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] error handling
John Coggeshall [EMAIL PROTECTED] ha scritto nel messaggio 001201c28ed8$a2fb6620$3801a8c0@cooglewin">news:001201c28ed8$a2fb6620$3801a8c0@cooglewin... |And this can never be supported safely, as a parse error leaves the |parse in an unstable state. Also, I really don't think that we should |try to add hacks to make this possible. Is this directed toward my wish (of having a secondary error if the custom error handler also errors) or toward Mattia's suggestion? Well, I agree that after an E_PARSE the execution must die() and the script can't go on, so when an E_PARSE occurs I havo to choiches (both poor). 1. notify the error on screen (display_errors ...) and let the user know what kind of error is occured, on wich line, on wich file... (NOONE LIKES THIS) 2. interrupt the script in silence and display nothing I would like to be notified of the error, so that I can notify whoever, and the user, that the service is unavaiable and such like an exit function that gets executed on program exit (just before) and whenever the E_PARSE occurs. Mattia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Rasmus Lerdorf [EMAIL PROTECTED] ha scritto nel messaggio [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Well, I certainly don't want errors handled this way for my web apps. Well, would you please tell us why and propose an alternative? Mattia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
I think in a modern web application the error handling function should do
the following:
in case of error (any: parse error, internal application error,)
1. a message should be shown to the user sayng that an error has occured
like an internal error has occured. the webmaster has been notified via
email
2. a more detailed message should be logged in a generic system ErrorLog, or
notified via email or fax, or telephone, or SMS. Depending on the severity
of the error (warning, fatal,...)
On a similar note, I posted a patch a few days ago which was intended
for development environments - it makes error messages appear in a
clear 'window' in the middle of the browser window, so that you don't
have to hunt around in the output of the program to find it. I've
attached it again, in case you're insterested.
John.
Index: main/main.c
===
RCS file: /repository/php4/main/main.c,v
retrieving revision 1.512
diff -u -r1.512 main.c
--- main/main.c 12 Nov 2002 14:40:00 - 1.512
+++ main/main.c 14 Nov 2002 20:57:31 -
@@ -246,6 +246,7 @@
STD_PHP_INI_BOOLEAN(expose_php, 1,
PHP_INI_SYSTEM, OnUpdateBool, expose_php,
php_core_globals, core_globals)
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(fancy_html_errors,1,PHP_INI_ALL,
+ OnUpdateBool, fancy_html_errors,
+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(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)
@@ -453,7 +454,11 @@
}
}
if (PG(html_errors)) {
- php_error(type, %s(%s) [a href='%s%s%s'%s/a]:
%s, get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target,
docref, buffer);
+ if (PG(fancy_html_errors)) {
+ php_error(type, div
+style=\position:fixed;left:25%;right:25%;top:25%;bottom:25%;border-style:dashed;border-size:2;background:white;\%s(%s)
+ [a href='%s%s%s'%s/a]: %s/div, get_active_function_name(TSRMLS_C), params,
+docref_root, docref, docref_target, docref, buffer);
+ } else {
+ }
+ php_error(type, %s(%s) [a href='%s%s%s'%s/a]: %s,
+get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target,
+docref, buffer);
} else {
php_error(type, %s(%s) [%s%s%s]: %s,
get_active_function_name(TSRMLS_C), params, docref_root, docref, docref_target,
buffer);
}
@@ -609,6 +614,9 @@
error_format = PG(html_errors) ?
br /\nb%s/b: %s in b%s/b on line
b%d/bbr /\n
: \n%s: %s in %s on line %d\n;
+ if (PG(fancy_html_errors)) {
+ error_format = div
+style=\position:fixed;left:25%;right:25%;top:25%;bottom:25%;border-style:dashed;border-size:2;background:white;\br
+ /\nb%s/b: %s in b%s/b on line b%d/bbr //div\n;
+ }
if (PG(xmlrpc_errors)) {
error_format = do_alloca(ERROR_BUF_LEN);
snprintf(error_format, ERROR_BUF_LEN-1, ?xml
version=\1.0\?methodResponsefaultvaluestructmembernamefaultCode/namevalueint%ld/int/value/membermembernamefaultString/namevaluestring%%s:%%s
in %%s on line
%%d/string/value/member/struct/value/fault/methodResponse,
PG(xmlrpc_error_number));
Index: main/php_globals.h
===
RCS file: /repository/php4/main/php_globals.h,v
retrieving revision 1.84
diff -u -r1.84 php_globals.h
--- main/php_globals.h 21 Oct 2002 16:41:06 - 1.84
+++ main/php_globals.h 14 Nov 2002 20:57:31 -
@@ -125,6 +125,7 @@
char *docref_ext;
FW: [PHP-DEV] error handling
This is what I sent Derick about a possible method of implementing a custom error handler for E_PARSE, etc... Free to flame if I'm off base here :) -Original Message- From: John Coggeshall [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 3:52 AM To: 'Derick Rethans' Subject: RE: [PHP-DEV] error handling Core errors are _fatal_ because it leaves the engine in an unclean state. If you have a parse error then the script hasn't been parsed fully and thus the compilation step did not even interpreted the tokens generated by the parse, so how do you want PHP to execute a function then? Well, in order for it to work you'd have to be prepared to parse the Error function completely on its own merit... How about this... Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is responsible For dealing with any (and all) errors which occur, or 'internal' which is Of course the internal PHP handler.. Then, upon script execution if there Is a error_handler script that gets executed and parsed first. If no core Errors occur during the parse/execution of the error handler script then shouldn't The engine be capiable of executing that script upon an error somewhere else? John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] getimagesize() broken in HEAD
getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Bradford wrote: I think in a modern web application the error handling function should do the following: in case of error (any: parse error, internal application error,) 1. a message should be shown to the user sayng that an error has occured like an internal error has occured. the webmaster has been notified via email 2. a more detailed message should be logged in a generic system ErrorLog, or notified via email or fax, or telephone, or SMS. Depending on the severity of the error (warning, fatal,...) On a similar note, I posted a patch a few days ago which was intended for development environments - it makes error messages appear in a clear 'window' in the middle of the browser window, so that you don't have to hunt around in the output of the program to find it. I've attached it again, in case you're insterested. I don't like this patch because it doesn't add anything to PHP itself. You can easily do this with the error_prepend_string and error_append_string configuration settings. 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] error handling
On Mon, 18 Nov 2002, John Bradford wrote: On a similar note, I posted a patch a few days ago which was intended for development environments - it makes error messages appear in a clear 'window' in the middle of the browser window, so that you don't have to hunt around in the output of the program to find it. I've attached it again, in case you're insterested. You were also told that this functionality can be achieved with error_prepend_string and error_append_string ini settings, so there is no real need for additional functionality. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getimagesize() broken in HEAD
On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. It might have something to do with this patch: http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2r1=1.72r2=1.73ty=h 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] [PATH] update to earlier proposed patch for getanyrr() function addition
At 07:52 18-11-2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: I don't think so. It is only a small extension to the functionality we have already. If there would be more functionality to add during the next release cycle i would agree to move this to a new extension. But let's here the others. It's only 2 functions for now, IMO it doesn't warrant a new extention yet. Actually - I think it should be PHP_API'd. Any extension needing DNS lookups doesn't have to rewrite it's own routine then. Especially now that you can get any record type, I can see the usefullness. And of course a central place for all those different implemenations to maintain. With kind regards, Melvyn Sopacua ?php include(not_reflecting_employers_views.txt); ? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: Core errors are _fatal_ because it leaves the engine in an unclean state. If you have a parse error then the script hasn't been parsed fully and thus the compilation step did not even interpreted the tokens generated by the parse, so how do you want PHP to execute a function then? Well, in order for it to work you'd have to be prepared to parse the Error function completely on its own merit... How about this... Create a configuration directive error_handler which accepts one of Two values... Either a PHP script (like auto_prepend) which is responsible For dealing with any (and all) errors which occur, or 'internal' which is Of course the internal PHP handler.. Then, upon script execution if there Is a error_handler script that gets executed and parsed first. If no core Errors occur during the parse/execution of the error handler script then shouldn't The engine be capiable of executing that script upon an error somewhere else? That can be done, but I don't like this. You should not have any parse errors in your code anyway, so it just should fail as hard as possible. 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] [PATH] update to earlier proposed patch for getanyrr()function addition
On Mon, 18 Nov 2002, Melvyn Sopacua wrote: At 07:52 18-11-2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: I don't think so. It is only a small extension to the functionality we have already. If there would be more functionality to add during the next release cycle i would agree to move this to a new extension. But let's here the others. It's only 2 functions for now, IMO it doesn't warrant a new extention yet. Actually - I think it should be PHP_API'd. Any extension needing DNS lookups doesn't have to rewrite it's own routine then. Especially now that you can get any record type, I can see the usefullness. And of course a central place for all those different implemenations to maintain. Makes sense to me... 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] error handling
Monday, November 18, 2002, 11:23:08 AM, Derick Rethans wrote:
That can be done, but I don't like this. You should not have any
parse errors in your code anyway, so it just should fail as hard as
possible.
Can't argue with that, however (;)), I find it annoying that PHP stops
processing if there is a parse error passed to an eval() command. I'd
like a way to make eval() just return E_PARSE if the script passed to it
fails. Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
--
Kjartan [EMAIL PROTECTED] (http://natrak.net/)
:: Programming is like sex: one mistake and you have to
support it for the rest of your life. - Michael Sinz
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, Kjartan Mannes wrote:
Monday, November 18, 2002, 11:23:08 AM, Derick Rethans wrote:
That can be done, but I don't like this. You should not have any
parse errors in your code anyway, so it just should fail as hard as
possible.
Can't argue with that, however (;)), I find it annoying that PHP stops
processing if there is a parse error passed to an eval() command. I'd
like a way to make eval() just return E_PARSE if the script passed to it
fails.
hmm, that might be useful, and would not really be a problem to implemtn
I think, but I'd like to know what the Zend Wizards think of this :)
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
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] [PATH] update to earlier proposed patch for getanyrr() function addition
At 11:23 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Melvyn Sopacua wrote: At 07:52 18-11-2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: I don't think so. It is only a small extension to the functionality we have already. If there would be more functionality to add during the next release cycle i would agree to move this to a new extension. But let's here the others. It's only 2 functions for now, IMO it doesn't warrant a new extention yet. Actually - I think it should be PHP_API'd. Any extension needing DNS lookups doesn't have to rewrite it's own routine then. Especially now that you can get any record type, I can see the usefullness. And of course a central place for all those different implemenations to maintain. Makes sense to me... Derick The first step should be making it a woring function with an agreed prototype and behaviour. I guess we would need some new datatype definitions to make this happen. So this would require some more work not needed directly. I made a new version which allows the use of a bitmask for the type parameter as suggested by Derick. You can now do dns_get_resord(...,DNS_ANY) dns_get_resord(...,DNS_ALL) dns_get_resord(...,DNS_MX) dns_get_resord(...,DNS_MX|DNS_SOA|...) DNS_ANY|DNS_xxx is not allowed. http://marcus-boerger.de/dns_get_record.diff marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
I don't like this patch because it doesn't add anything to PHP itself. You can easily do this with the error_prepend_string and error_append_string configuration settings. You were also told that this functionality can be achieved with error_prepend_string and error_append_string ini settings, so there is no real need for additional functionality. Ah, right, sorry about that I didn't read the explaination properly :-). Yes, you're right, it can be done without a patch. What I'm now thinking, though, is that it might be useful to have all of the non-fatal error messages buffered, and output in a visible way at the end. I know you can log to a file, or the system log, but I can't see a way of buffering all errors until the script ends either properly, or with a fatal error. Is this worth working on, or a waste of time? :-) John. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
At 11:39 18-11-2002, Derick Rethans wrote:
[...]
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Since there is '-l'int in the cli, how about a lint function? At least then,
you can verify includes before including them and take any action you want,
including mail().
In a well designed application, you would be able to act on any parse error,
but the 'main' file. Of course this won't work with 'require'.
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
Can't argue with that, however (;)), I find it annoying that
PHP stops
processing if there is a parse error passed to an eval()
command. I'd
like a way to make eval() just return E_PARSE if the script
passed to
it fails.
This is exactly the type of situation where E_PARSE really bothers me as
well.. Although no one likes eval(), and it seems to me it is become
more and more of a security-risk and less and less useful... The last
time I've actually seen it implemented in a useful way (that couldn't be
done in a better way) was in PHPLIB. Then again, maybe I'm not coding
things that would need such a function :)
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation
in the zend
engine is about the same.
What about require'd files?
Back on the note that I was discussing (the E_PARSE with a user
error-handler), Perhaps the issue can be slightly skirted without having
to code a whole lot... Specifically, what about simply re-directing the
user to another URL in the event of a fatal PHP error (as specified by a
directive)... Ie.
On_fatal_error=http://somewhere.com/error.php
Where on a E_PARSE, or something similar, PHP basically does a C-version
of:
?php header(Location: http://somewhere.com/error.php?errno=4;); ?
This way, users who don't care can still re-direct a browser to a nice
and pretty sorry, the server is really screwed HTML page... Or, if
they'd like, they can simply take that error number and create a
error-handler in PHP without us having to bother with the problems
surrounding a bad parser-state...
John
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] error handling
Can't argue with that, however (;)), I find it annoying that PHP stops processing if there is a parse error passed to an eval() command. I'd like a way to make eval() just return E_PARSE if the script passed to it fails. Or a more general command to verify PHP code well, well, well... everybody is talking about E_PARSE but none is talking about E_ERROR. The correct syntax of a program is easy to verify (php -l file). But it's impossible to know if it'll execute correctly without E_ERROR. So to be sure that there will be no E_PARSE is enough to execute it once, but not the same with E_ERROR. Mattia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Limitations of the ZendEngine2 Object Model?
PM ?php
PM class Root {
PM class Nested {
PMfunction Nested() {
PM print(Root::Nested constructed\n);
PM}
PM }
PM }
PM
PM class Child extends Root {
PM class Nested {
PMfunction Nested() {
PM parent::Nested();
PM print(Child::Nested constructed\n);
PM}
PM }
PM }
PM
PM $object = new Child::Nested;
PM ?
PM
PM If you attempt to execute this script with the PHP 4.3.0 ZE2 alphas (either
PM 1 or 2), you'll get a fatal error specifying that Cannot fetch parent:: as
PM current class scope has no parent, referring to the Child::Nested
PM constructor and the parent::Nested(); line. Is the outer classes just
But the Child::Nested class doesn't have parent indeed! Child has parent,
but Child::Nested doesn't.
PM meant to be for namespacing purposes? Any class deriving from the
PM parent will not have its nested classes derive from the parents
PM nested classes. So then why can't nested classes be extended from
PM anything? Just some symbolism: P is parent, defines P.n is nested, D
It can. You can use extends in nested class, AFAIK, just as you do in
plain one - just interitance is not inherited (brrr... what a messy
phrase) by the nested classes.
PM extends P, defines D.n nested, yet D.n has no relation to P.n and is
PM not allowed to extend it explicitly (wouldn't it be implicit, with
You definitely can do it explicitly - by saying extends Root::Nested in
Child::Nested.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Apache hooks link problem
I'm trying to make project files to make apache_hooks available on windows. However, I cannot get it to link properly. I'm getting 'php_request_startup_for_hook' undefined symbol error. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
Derick Rethans wrote: On Sun, 17 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Brian Havard wrote: When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. Thanks, I'll check the whole source for strdup now. Okay, I committed this, but I found that some of the functions use malloc, others emalloc and more others use gdMalloc (which is a wrapper for emalloc). I don't think this is what we want, but I'm also afraid that changing everything to the gd* functions is a bad thing, as some of the structures should be persistent. Ok, that's better but there's still a problem when running as an Apache module. It crashes on the 2nd image request changing gdhelpers.c back to using malloc/free/strdup cures it. I haven't traced it but my money's on the font cache which is meant to be persistent between images (see static gdCache_head_t *fontCache at gdft.c:721) but is allocated with gdMalloc() therefore emalloc() in gdCacheCreate(). -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On Mon, 18 Nov 2002, Brian Havard wrote: Derick Rethans wrote: On Sun, 17 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Brian Havard wrote: When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. Thanks, I'll check the whole source for strdup now. Okay, I committed this, but I found that some of the functions use malloc, others emalloc and more others use gdMalloc (which is a wrapper for emalloc). I don't think this is what we want, but I'm also afraid that changing everything to the gd* functions is a bad thing, as some of the structures should be persistent. Ok, that's better but there's still a problem when running as an Apache module. It crashes on the 2nd image request changing gdhelpers.c back to using malloc/free/strdup cures it. I haven't traced it but my money's on the font cache which is meant to be persistent between images (see static gdCache_head_t *fontCache at gdft.c:721) but is allocated with gdMalloc() therefore emalloc() in gdCacheCreate(). yeah, I'm going to revert back to the original memory management functions, it needs some thourough checking before we can swap again. 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] getimagesize() broken in HEAD
At 11:20 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. It might have something to do with this patch: http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2r1=1.72r2=1.73ty=h Derick But i applied the same patch to 4.3 and branch. For me both 4.3 and branch are working. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getimagesize() broken in HEAD
I just merged some streams fixes back from the branch, so perhaps it was a streams problem after all? --Wez. On Mon, 18 Nov 2002, Marcus [iso-8859-1] Börger wrote: At 11:20 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. It might have something to do with this patch: http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2r1=1.72r2=1.73ty=h Derick But i applied the same patch to 4.3 and branch. For me both 4.3 and branch are working. -- 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] GD segfault in 4.3.0RC1
At 13:07 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Brian Havard wrote: Derick Rethans wrote: On Sun, 17 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Brian Havard wrote: When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. Thanks, I'll check the whole source for strdup now. Okay, I committed this, but I found that some of the functions use malloc, others emalloc and more others use gdMalloc (which is a wrapper for emalloc). I don't think this is what we want, but I'm also afraid that changing everything to the gd* functions is a bad thing, as some of the structures should be persistent. Ok, that's better but there's still a problem when running as an Apache module. It crashes on the 2nd image request changing gdhelpers.c back to using malloc/free/strdup cures it. I haven't traced it but my money's on the font cache which is meant to be persistent between images (see static gdCache_head_t *fontCache at gdft.c:721) but is allocated with gdMalloc() therefore emalloc() in gdCacheCreate(). yeah, I'm going to revert back to the original memory management functions, it needs some thourough checking before we can swap again. Derick Brian could you create a short test for the segfault? It would help us finding out the problems. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On Mon, 18 Nov 2002, Marcus Börger wrote: Brian could you create a short test for the segfault? It would help us finding out the problems. For now I think it's very wise to remove all the e*() memory functions from the branch, it's not strictly needed and we need to be very careful not to emalloc data that should be preserved accross requests. That's why I've a patch read to remove the e*() stuff for the branch so that we have a lot of time for the 4.4/5.0 version to check all these things out. regards, 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] GD segfault in 4.3.0RC1
On Mon, 18 Nov 2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: Brian could you create a short test for the segfault? It would help us finding out the problems. For now I think it's very wise to remove all the e*() memory functions from the branch, it's not strictly needed and we need to be very careful not to emalloc data that should be preserved accross requests. That's why I've a patch read to remove the e*() stuff for the branch so that we have a lot of time for the 4.4/5.0 version to check all these things out. +1 I think it's the safest thing to do ATM. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On November 18, 2002 07:44 am, Derick Rethans wrote: On Mon, 18 Nov 2002, Marcus Börger wrote: Brian could you create a short test for the segfault? It would help us finding out the problems. For now I think it's very wise to remove all the e*() memory functions from the branch, it's not strictly needed and we need to be very careful not to emalloc data that should be preserved accross requests. That's why I've a patch read to remove the e*() stuff for the branch so that we have a lot of time for the 4.4/5.0 version to check all these things out. +1 I think we don't have nearly enough time to fully test this change in gd before 4.3.0 is out, so this will need to wait till the next release. We've used gd for many years without auditing it's memory, I am sure another half a year or so won't too much difference. Ilia -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GD segfault in 4.3.0RC1
On Mon, 18 Nov 2002 13:31:58 +0100, Marcus Börger wrote: At 13:07 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Brian Havard wrote: Derick Rethans wrote: On Sun, 17 Nov 2002, Derick Rethans wrote: On Sun, 17 Nov 2002, Brian Havard wrote: When trying out the RC1 code I found that my GD test segfaults every time. I traced the problem to the fact that efree is used on memory that was allocated with strdup. See the fontlist variable in ext\gd\libgd\gdft.c:fontFetch() This started happening when gdhelpers.c was changed to use emalloc etc in r1.3. Thanks, I'll check the whole source for strdup now. Okay, I committed this, but I found that some of the functions use malloc, others emalloc and more others use gdMalloc (which is a wrapper for emalloc). I don't think this is what we want, but I'm also afraid that changing everything to the gd* functions is a bad thing, as some of the structures should be persistent. Ok, that's better but there's still a problem when running as an Apache module. It crashes on the 2nd image request changing gdhelpers.c back to using malloc/free/strdup cures it. I haven't traced it but my money's on the font cache which is meant to be persistent between images (see static gdCache_head_t *fontCache at gdft.c:721) but is allocated with gdMalloc() therefore emalloc() in gdCacheCreate(). yeah, I'm going to revert back to the original memory management functions, it needs some thourough checking before we can swap again. Derick Brian could you create a short test for the segfault? It would help us finding out the problems. It should be easy to reproduce. Any script that uses ImageTTFText() requested more than once from a persistent SAPI seems to do it. If you read the source at the points I've mentioned above it becomes pretty obvious that it will try to access freed memory pointed to by fontCache. -- __ | Brian Havard | He is not the messiah! | | [EMAIL PROTECTED] | He's a very naughty boy! - Life of Brian | -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
On Mon, 18 Nov 2002, Melvyn Sopacua wrote:
At 11:39 18-11-2002, Derick Rethans wrote:
[...]
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Since there is '-l'int in the cli, how about a lint function? At least then,
you can verify includes before including them and take any action you want,
including mail().
In a well designed application, you would be able to act on any parse error,
but the 'main' file. Of course this won't work with 'require'.
IMO parse errors should just kill your script. It's IMO not up to the
language to provide fall back mechanisms for this. If a user too stupid
to use broken files it's their problem.
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] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: Can't argue with that, however (;)), I find it annoying that PHP stops processing if there is a parse error passed to an eval() command. I'd like a way to make eval() just return E_PARSE if the script passed to it fails. This is exactly the type of situation where E_PARSE really bothers me as well.. Although no one likes eval(), and it seems to me it is become uhm, John, we dont have a E_PARSE yet. Back on the note that I was discussing (the E_PARSE with a user error-handler), Perhaps the issue can be slightly skirted without having to code a whole lot... Specifically, what about simply re-directing the user to another URL in the event of a fatal PHP error (as specified by a directive)... Ie. On_fatal_error=http://somewhere.com/error.php Where on a E_PARSE, or something similar, PHP basically does a C-version of: ?php header(Location: http://somewhere.com/error.php?errno=4;); ? This way, users who don't care can still re-direct a browser to a nice and pretty sorry, the server is really screwed HTML page... Or, if they'd like, they can simply take that error number and create a error-handler in PHP without us having to bother with the problems surrounding a bad parser-state... I stil see not why you would want to handle PARSE errors gracefully. If a user has broken code it should not even be on a production box. Bad code - dead site. 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] error handling
uhm, John, we dont have a E_PARSE yet. It's late... I actually stared at that sentence for about 30 seconds trying to determine if I had spelled PARSE wrong... Then I actually went and checked the manual to make sure I hadn't lost my mind and there was actually a E_PARSE constant... Now I'm just confused as to what the heck your talkin' about Derick :) I stil see not why you would want to handle PARSE errors gracefully. If a user has broken code it should not even be on a production box. Bad code - dead site. Can't argue about broken code not being a production box. However, dealing with errors in code cleanly (regardless of the problem) is more than just an internal PHP problem. Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... On a secondary note, as Rasmus pointed out when Mattia first suggested his ideas for error handling, everyone's got their own method. This seems like a reasonable and easy way to allow Mattia to SMS, Fax, Call, log, whatever on a critical error without forcing the rest of the PHP community to conform to an entirely new way of doing business. John 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
On Mon, 18 Nov 2002, John Coggeshall wrote: uhm, John, we dont have a E_PARSE yet. It's late... I actually stared at that sentence for about 30 seconds trying to determine if I had spelled PARSE wrong... Then I actually went and checked the manual to make sure I hadn't lost my mind and there was actually a E_PARSE constant... Now I'm just confused as to what the heck your talkin' about Derick :) hmm, I really thought we didn't have one, as it doesn't make sense at all :) I stil see not why you would want to handle PARSE errors gracefully. If a user has broken code it should not even be on a production box. Bad code - dead site. Can't argue about broken code not being a production box. However, dealing with errors in code cleanly (regardless of the problem) is more than just an internal PHP problem. Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... Your cat knows your passwords? :) Anyway, you can always use the error_append_string and error_prepend_string for this. (by putting !-- in prepend_string and -- in append string for example). 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] error handling
After all the decision what about an ini directive that makes it possible to send back another file that contains the error message? That would be something like apaches ability to direct some errors to some special pages. The main problem would be how to pass the error information to that script. To overcome such problems i would suggest we'd allow just a simple text file (non php interpreted) and just log the error. marcus At 14:21 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, John Coggeshall wrote: uhm, John, we dont have a E_PARSE yet. It's late... I actually stared at that sentence for about 30 seconds trying to determine if I had spelled PARSE wrong... Then I actually went and checked the manual to make sure I hadn't lost my mind and there was actually a E_PARSE constant... Now I'm just confused as to what the heck your talkin' about Derick :) hmm, I really thought we didn't have one, as it doesn't make sense at all :) I stil see not why you would want to handle PARSE errors gracefully. If a user has broken code it should not even be on a production box. Bad code - dead site. Can't argue about broken code not being a production box. However, dealing with errors in code cleanly (regardless of the problem) is more than just an internal PHP problem. Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... Your cat knows your passwords? :) Anyway, you can always use the error_append_string and error_prepend_string for this. (by putting !-- in prepend_string and -- in append string for example). 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] error handling
hmm, I really thought we didn't have one, as it doesn't make sense at all :) Ha! I'm not crazy! :) Having a solid way to gracefully bow-out because my cat managed to open, fill with junk, and save a critical include file would just be nice. The choice between the blank screen, or a nasty error message isn't a good one... I'd personally love to have a sorry, our site is hosed error page... If for nothing else then piece of mind... Your cat knows your passwords? :) Anyway, you can always use the error_append_string and error_prepend_string for this. (by putting !-- in prepend_string and -- in append string for example). Not true. All I've done in that case is display a half-completed page And hide the fact it died in a comment. Not to mention that doesn't allow For any sort of e-mailing me to let me know my cat hacked my account again (she's a smart little bugger). I guess I just really do believe that PHP's Error handling mechanism has little real use in its current form. There are Better methods of dealing with logic-errors than using trigger_error() if The only thing they are good for is logic-errors... However, If I could handle Every single error that didn't cause some catastrophe seg-fault I feel that It would add a nice capability to the language. Hence, I am still standing by my re-direct (with GET parameters for the nature Of the error :)) suggestion :) John (and his cat) -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
John Coggeshall [EMAIL PROTECTED] wrote... : What about require'd files? Back on the note that I was discussing (the E_PARSE with a user error-handler), Perhaps the issue can be slightly skirted without having to code a whole lot... Specifically, what about simply re-directing the user to another URL in the event of a fatal PHP error (as specified by a directive)... Ie. On_fatal_error=http://somewhere.com/error.php Where on a E_PARSE, or something similar, PHP basically does a C-version of: ?php header(Location: http://somewhere.com/error.php?errno=4;); ? This way, users who don't care can still re-direct a browser to a nice and pretty sorry, the server is really screwed HTML page... Or, if they'd like, they can simply take that error number and create a error-handler in PHP without us having to bother with the problems surrounding a bad parser-state... John I must say that I like this idea. User should be alble to specify the error page in php.ini for different error types and instructing the script to move onto a custom page, leaving the execution of a bad code alone. There would be several reasons why to treat errors gracefuly, even the E_PARSE ones: First reason is to be able to update the current pages in the production server with less risks. When you edit a file on a production site, you might create an E_PARSE error and correct it few seconds later. Not a big deal, but users currently online will be simply told - be back later - server experiences some trouble. Throwing errors on screen includes the full path and can sometimes be a theoretical security risk. Another reason I find for this is, when you do dynamic things like grabbing PHP code from other sources passing it through eval(). That can be out of your control and as such requires a more friendly error treatment. All that provided that an error log is being generated with on line xxx in file xxx but the page is the URL you specify in php.ini. -- 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
Monday, November 18, 2002, 11:43:48 AM, John Coggeshall wrote: Back on the note that I was discussing (the E_PARSE with a user error-handler), Perhaps the issue can be slightly skirted without having to code a whole lot... Specifically, what about simply re-directing the user to another URL in the event of a fatal PHP error (as specified by a directive)... Ie. On_fatal_error=http://somewhere.com/error.php Where on a E_PARSE, or something similar, PHP basically does a C-version of: ?php header(Location: http://somewhere.com/error.php?errno=4;); ? This way, users who don't care can still re-direct a browser to a nice and pretty sorry, the server is really screwed HTML page... Or, if they'd like, they can simply take that error number and create a error-handler in PHP without us having to bother with the problems surrounding a bad parser-state... I don't think this will work. First of all PHP would have to do output buffering as sending an header() after output has been sent wont work. ? print Welcome; include(File that doesn't parse.inc); ? This would show the parse error then a header() error, unless you buffer everything and only do output after processing. Also if I allow users to input PHP code to allow for greater customization of an application then I wouldn't want eval() to redirect you to the page saying the site is down for maintenance when they preview their script. (I'd rather have eval() create a non fatal error so I can give them a more useful error message.) If people are updating a site with code they haven't tested then you probably are not running a major site, or shouldn't be. If you expect things to break while doing an upgrade it is easy enough to force the web server to serve an Upgrade in progress page. -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: Choose your friends by their character and your socks by their color. Choosing your socks by their character makes no sense, and choosing your friends by their color is unthinkable. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
It would still be good to have as there are tons of sites that use sessions and plain header() calls - they care of not having the output before processing is done. If E_PARSE error happens after an output the header() can fail bad too with headers sent message. But, if one wants to control well the whole error thing - it would then be possible. -- Maxim Maletsky [EMAIL PROTECTED] Kjartan Mannes [EMAIL PROTECTED] wrote... : Monday, November 18, 2002, 11:43:48 AM, John Coggeshall wrote: Back on the note that I was discussing (the E_PARSE with a user error-handler), Perhaps the issue can be slightly skirted without having to code a whole lot... Specifically, what about simply re-directing the user to another URL in the event of a fatal PHP error (as specified by a directive)... Ie. On_fatal_error=http://somewhere.com/error.php Where on a E_PARSE, or something similar, PHP basically does a C-version of: ?php header(Location: http://somewhere.com/error.php?errno=4;); ? This way, users who don't care can still re-direct a browser to a nice and pretty sorry, the server is really screwed HTML page... Or, if they'd like, they can simply take that error number and create a error-handler in PHP without us having to bother with the problems surrounding a bad parser-state... I don't think this will work. First of all PHP would have to do output buffering as sending an header() after output has been sent wont work. ? print Welcome; include(File that doesn't parse.inc); ? This would show the parse error then a header() error, unless you buffer everything and only do output after processing. Also if I allow users to input PHP code to allow for greater customization of an application then I wouldn't want eval() to redirect you to the page saying the site is down for maintenance when they preview their script. (I'd rather have eval() create a non fatal error so I can give them a more useful error message.) If people are updating a site with code they haven't tested then you probably are not running a major site, or shouldn't be. If you expect things to break while doing an upgrade it is easy enough to force the web server to serve an Upgrade in progress page. -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: Choose your friends by their character and your socks by their color. Choosing your socks by their character makes no sense, and choosing your friends by their color is unthinkable. -- 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
?php header(Location: http://somewhere.com/error.php?errno=4;); ? This way, users who don't care can still re-direct a browser to a nice and pretty sorry, the server is really screwed HTML page... Or, if they'd like, they can simply take that error number and create a error-handler in PHP without us having to bother with the problems surrounding a bad parser-state... I don't think this will work. First of all PHP would have to do output buffering as sending an header() after output has been sent wont work. Simply fixed if you fix output buffering to ON if you are using a custom re-direct handler for errors. Also if I allow users to input PHP code to allow for greater customization of an application then I wouldn't want eval() to redirect you to the page saying the site is down for maintenance when they preview their script. (I'd rather have eval() create a non fatal error so I can give them a more useful error message.) What are you doing giving users access to eval()??? That's an incredibly huge security risk allowing an arbitary user to execute code of their choosing on your server... (I shiver to think if you actually had the PEAR Inline_C installed).. Besides, as with all of the directives in this nature, a function or two could be created to get/set this directive as necessary from PHP code. If people are updating a site with code they haven't tested then you probably are not running a major site, or shouldn't be. If you expect things to break while doing an upgrade it is easy enough to force the web server to serve an Upgrade in progress page. Valid, but I'd be careful being too judgemental... I've seen some pretty big web sites doing some pretty stupid things ... Putting untested code on them is sometimes the least of it. John -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: Choose your friends by their character and your socks by their color. Choosing your socks by their character makes no sense, and choosing your friends by their color is unthinkable. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] error handling
Monday, November 18, 2002, 3:03:39 PM, John Coggeshall wrote: What are you doing giving users access to eval()??? That's an incredibly huge security risk allowing an arbitary user to execute code of their choosing on your server... (I shiver to think if you actually had the PEAR Inline_C installed).. Besides, as with all of the directives in this nature, a function or two could be created to get/set this directive as necessary from PHP code. Selected users with the proper user permissions. What is the point of developing a fine grained user system and not use its power to control the cool stuff? Personally I could live without the option as adding a PHP file is usually faster for me than adding PHP code into a textarea is, but I must admit the latter is quiet handy when you just need a small dynamic page and don't feel like adding more code to the core script just to do it. Also PEAR is a concept I haven't bothered much with yet as the installer has been buggy at best and the code in there doesn't suit my needs. The added level of complexity is unnecessary, and even unwanted if an optimized solution is required. Maybe when it matures more and there is a wider array of packages it will be worth the effort :) Valid, but I'd be careful being too judgemental... I've seen some pretty big web sites doing some pretty stupid things ... Putting untested code on them is sometimes the least of it. So have I. I've also hired, worked with and eventually fired people who didn't get the concept of testing before uploading. Ofcoz I don't test when I update stuff on my own personal sites, but financially they don't cost me anything if they are down all day ;) -- Kjartan [EMAIL PROTECTED] (http://natrak.net/) :: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. - C.A.R. Hoare -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] MULTIPLE PHP SESSIONS ON THE SAME CLIENT PC
I have a problem with the session way of working. I´ve made an CMS application integrated with database for the purpose of making a web site easier to change and update. ### THE FACTS: ### Lets review the process to see the real problem. 1- Browser. Site URL. Access to a public site. 2- Session starts with global variables. Needed for making all the tools (more than 7) work for the right company without having to pass the variables from one page to the next one (to many pages, libraries, functions, etc), and then on -. Group name (anonimous). Each group has its own menu of web pages non dependent of any other, that means that each group is a site public (URL) or private (log in) -. User name (anonimous) -. Site name (URL). -. Company name (URL owner) 3- The user has a login in (User and password) so the session must change variables. -. Group name (the one of the user) -. User name (user) -. Private site. So the system shows the tool bar of the system. Untill then, there´s no problem in the system, but here´s where the problem starts. PROBLEM (A)- The user opens a new browser in order to see the changes he has made to the contents. He navigates through the public site to look. When he does so as the system previously did recognize the URL in the first place will do again. Then all the variables will be reset to anonimous user and group. When the user comes back to the first browser to continue making changes finds one of the following: -. the system doesn´t permit him to continue and he has to log in again. (thats not comfortable) -. the system permit some of the changes as anonimous user so he will never find again the changes he made. (thats wrong) PROBLEM (B)- The user opens a new browser with the URL of another company, concidentily that site is hosted in the system too, so the system makes the same as in PROBLEM (A) plus the user goes to he´s tools in the other company and starts making changes: -. the system doesn´t permit the access. (thats good but uncomfortable) -. the system permits changes because concidentily recognizes the group name. The user begin to see the wrong menu. (that´s the worst of all, the user could make changes to sites that he doesn´t own) PROBLEM (C)- The user opens many browsers of many companies hosted in the system. So the problems start to multiply. (very bad) PROBLEM (D)- The user access another site thas also made in PHP with sessions. Some of the variables maybe reseted by the other site or the way around. (disconcerting). ### THE PROBLEM: ### PHP session start only once in the user machine. I haven´t found a way around. 1- With the first browser that initiates it. 2- You can open an close browser windows and as long there´s one browser open the session remains the same. 3- Many diferent applications can mix variables without knowing. 4- You need different applications to work together without making a mess complicating the integration process. ### SUGGESTED SOLUTION: ### The problems could be solve 1- if the PHP session could be started with unique PIN number on request. 2- if the session could be different from browser to browser. 3- if you could have different instances of the session. 4- if you could have different instances of the variables. 5- if you could start the variables with a unique vector variable or some thing like that. Well, as with any other, I need feedback on the problem in order to know what to do (if I haven´t discover the right PHP functions to do the job), or this is something the the comunity is working on. Thanks in advance, Zaaptar Chazzy PHP Developer [EMAIL PROTECTED] - Do you Yahoo!? Yahoo! Web Hosting - Let the expert host your site
[PHP-DEV] RE: hebrew patch for jewish calendar
Hey Moshe, Could you resend your revised patch to Tal (and the list)? --Wez. smime.p7s Description: application/pkcs7-signature
[PHP-DEV] problem with GPL code in PHP4
Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. Do you plan to change the licence of these 2 files, or relax it with LGPL ? The reason is that having these 2 files covered by GPL licence will prevent PHP4 ports to some proprietary platform which could only live with ASF or LGPL licence model. Thanks for you clarification. Regards -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getimagesize() broken in HEAD
Try grabbing this image: lerdorf.com/serverside.png And do a getimagesize() on it. I am getting a negative value for the width. -Rasmus On Mon, 18 Nov 2002, Marcus Börger wrote: At 11:20 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. It might have something to do with this patch: http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2r1=1.72r2=1.73ty=h Derick But i applied the same patch to 4.3 and branch. For me both 4.3 and branch are working. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
On Mon, 18 Nov 2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. image.c only uses very little original code, so I think we can just remove that GPL thing, and rand.c is not GPL afaics. 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] error handling
At 13:56 18-11-2002, Derick Rethans wrote:
On Mon, 18 Nov 2002, Melvyn Sopacua wrote:
At 11:39 18-11-2002, Derick Rethans wrote:
[...]
Or a more general command to verify PHP code
php_valid($code_str). That way the people who expect parse errors in
their include files can do
$code_str(implode(, file(include.inc)));
if (php_valid($code_str)) {
include_once(include.inc);
}
That would be hard, as the zend_compile function which runs the parse
also adds the functions, so if the code parses it includes it right
away. Again, for this one we _could_ not abort the script, but in the
case of include files I'd like to see it die hard again. eval() is
something different in a logical way, but the implementation in the zend
engine is about the same.
Since there is '-l'int in the cli, how about a lint function? At least
then,
you can verify includes before including them and take any action you want,
including mail().
In a well designed application, you would be able to act on any parse
error,
but the 'main' file. Of course this won't work with 'require'.
IMO parse errors should just kill your script. It's IMO not up to the
language to provide fall back mechanisms for this. If a user too stupid
to use broken files it's their problem.
Refrase with 'one of the people, who has ftp-access to the site, to update
parts
of the HTML'.
Secondly - a parse error is not by definition a 'stupid user' mistake. It
can also
be, because 'short_open_tags' was switched off. It can also be, because in
transit
via FTP the connection died. Or a hickup in the filesystem.
I'd rather have Please wait while we fix this than a half-baked site, or
worse -
a queue of people reloading because nothing shows up.
With kind regards,
Melvyn Sopacua
?php include(not_reflecting_employers_views.txt); ?
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
At 16:21 18.11.2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. Do you plan to change the licence of these 2 files, or relax it with LGPL ? The reason is that having these 2 files covered by GPL licence will prevent PHP4 ports to some proprietary platform which could only live with ASF or LGPL licence model. Thanks for you clarification. Regards I think we can remove the info about the ancestor imageingo.c in image.c since we completley rewrote that stuff. Leaves the other file rand.c. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
Derick Rethans wrote: On Mon, 18 Nov 2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. image.c only uses very little original code, so I think we can just remove that GPL thing Great and rand.c is not GPL afaics. In 4.2.2 source I'm reading from, the MT RAND functions are marked as GPL (and you know that any single piece of GPL in a code base make it GPLized ;) Regards -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: Well, he is talking about the Mersenne Twister code in rand.c. The is a GPL reference in that. (search for GNU) Ah, right, missed that. 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] problem with GPL code in PHP4
On Mon, 18 Nov 2002, Henri Gomez wrote: In 4.2.2 source I'm reading from, the MT RAND functions are marked as GPL (and you know that any single piece of GPL in a code base make it GPLized ;) Somebody which rewrites this code will pop-up soon :) 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] problem with GPL code in PHP4
Derick Rethans wrote: On Mon, 18 Nov 2002, Henri Gomez wrote: In 4.2.2 source I'm reading from, the MT RAND functions are marked as GPL (and you know that any single piece of GPL in a code base make it GPLized ;) Somebody which rewrites this code will pop-up soon :) What do you means ? Did this rewrite is a planned task and that a non GPL version will be available soon in CVS ? It will be a great news ;) Just to clarify, I know a team working on a port for a major proprietary Operating System which is waiting to see GPL code removed to finish its port of PHP4 to their OS. So it's more than important -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getimagesize() broken in HEAD
Fixed. Are you on a online book or where does the image come from? marcus At 16:23 18.11.2002, Rasmus Lerdorf wrote: Try grabbing this image: lerdorf.com/serverside.png And do a getimagesize() on it. I am getting a negative value for the width. -Rasmus On Mon, 18 Nov 2002, Marcus Börger wrote: At 11:20 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. It might have something to do with this patch: http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2r1=1.72r 2=1.73ty=h Derick But i applied the same patch to 4.3 and branch. For me both 4.3 and branch are working. -- 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] Memory persistence with apache question
Hello, I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP. Recently some clients started using a gallery php script: http://gallery.sf.net that causes excessive memory utilization on the server: http://sourceforge.net/tracker/index.php?func=detailaid=498028group_id=7130atid=107130 So here goes the question: In what situations will memory allocated to a script remain with the apache process after the script has terminated ? I always thought that memory allocated would be released on script termination - Am I wrong in this assumption ? Could it be that the heap in the apache process stays at the maximally used level ? Thanks for any pointers or how I should approach resolving this problem. (I am already using 'MaxRequestsPerChild 5' in apache as a stopgap measure) Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] getimagesize() broken in HEAD
It is one I created for a presentation. Just about to give a tutorial at Apachecon here in Vegas and the slide with this image on it was broken because of this bug. I swear that my 100-slide PHP talk is one of the best regression test cases we have for PHP. ;) -Rasmus On Mon, 18 Nov 2002, Marcus Börger wrote: Fixed. Are you on a online book or where does the image come from? marcus At 16:23 18.11.2002, Rasmus Lerdorf wrote: Try grabbing this image: lerdorf.com/serverside.png And do a getimagesize() on it. I am getting a negative value for the width. -Rasmus On Mon, 18 Nov 2002, Marcus Börger wrote: At 11:20 18.11.2002, Derick Rethans wrote: On Mon, 18 Nov 2002, Rasmus Lerdorf wrote: getimagesize() works ok in the 4.3 branch, but in HEAD it is returning weird data. streams problem? too tired to track it down right now. It might have something to do with this patch: http://cvs.php.net/diff.php/php4/ext/standard/image.c?login=2r1=1.72r 2=1.73ty=h Derick But i applied the same patch to 4.3 and branch. For me both 4.3 and branch are working. -- 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] problem with GPL code in PHP4
On Mon, Nov 18, 2002 at 04:33:59PM +0100, Henri Gomez wrote: In 4.2.2 source I'm reading from, the MT RAND functions are marked as GPL (and you know that any single piece of GPL in a code base make it GPLized ;) It's actually LGPL, see line 117: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by ... Sander -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
Sander Roobol wrote: On Mon, Nov 18, 2002 at 04:33:59PM +0100, Henri Gomez wrote: In 4.2.2 source I'm reading from, the MT RAND functions are marked as GPL (and you know that any single piece of GPL in a code base make it GPLized ;) It's actually LGPL, see line 117: This library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by ... You got it, Library GPL = Lesser GPL, I expected to see LESSER somewhere. So when the GNU GPL will be removed from image.c, there won't be any more GPL stuff in PHP 4 which will prevent it to be ported to the proprietary OS. There are still some GNU General Public License file, ie muscat which won't be used, the others being bison generated files which could be used even if marked GNU GPL. Any date to make the change in image.c ? Regards -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] on the subject of overloading: __call()
BB but there is no way to make equivalent calls using call_user_func()
BB or call_user_func_array(). you can't use parent::a_method,
BB array($this,'parent::a_method'), array(parent,a_method),
BB or array('parent',a_method). if you use the literal class name,
BBcall_user_func_array(array(get_parent_class($this),'a_method'), $args);
BB it doesn't fail, but it's as if you were making a static method call
BB from outside of an object context - $this is not defined.
I fear you lost me here. Is the a_method static method or not? If yes -
why not pass $this? If not - why do you need $this?
I will look into your examples later and respond what I think.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.109
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
On Monday, November 18, 2002, at 04:35 PM, Derick Rethans wrote: On Mon, 18 Nov 2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. image.c only uses very little original code, so I think we can just IMHO, little is already to much. remove that GPL thing, and rand.c is not GPL afaics. 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
Henri Gomez wrote: Any date to make the change in image.c ? It's already fixed in CVS. -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] is_callable Bug 20216
Can someone shed some light on is_callable? I think I understand it's meant
for testing whether a function or method is callable, but it would be nice
to get some confirmation from someone who knows for sure. Philip and I are
trying to add this function to the manual.
Here are some rough notes I have on my understanding of the function (from
http://bugs.php.net/bug.php?id=20216):
This function wraps zend_is_callable. The first argument is the name
of a function or method. Class and object methods are specified by
passing an array with two elements: class or object and method name.
The second argument seems to be for checking syntax only, but I can't
figure out how to make is_callable return FALSE when the second
argument is TRUE.
The third argument receives the callable name. In the example below
it's a::b. Note, however, that despite the implication that a::b()
is a callable static method, this is not the case.
?
class a
{
var $c;
function b()
{
return($this-c);
}
}
$d = new a;
if(is_callable(array($d, 'b'), FALSE, $name))
{
print($name);
}
?
Thanks!
---
Leon Atkinson http://www.leonatkinson.com/
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_callable Bug 20216
Since I wrote the function, I can provide some insight.
On Mon, 18 Nov 2002, Leon Atkinson wrote:
This function wraps zend_is_callable. The first argument is the name
of a function or method. Class and object methods are specified by
passing an array with two elements: class or object and method name.
Right.
The second argument seems to be for checking syntax only, but I can't
figure out how to make is_callable return FALSE when the second
argument is TRUE.
Try this:
var_dump(is_callable(array(1,2), true));
The third argument receives the callable name. In the example below
it's a::b. Note, however, that despite the implication that a::b()
is a callable static method, this is not the case.
?
class a
{
var $c;
function b()
{
return($this-c);
}
}
$d = new a;
if(is_callable(array($d, 'b'), FALSE, $name))
{
print($name);
}
?
Well, $name is just supposed to indicate which class/method you were
checking. It doesn't tell you whether the method is static or not,
because in PHP 4 it doesn't make sense.
-Andrei http://www.gravitonic.com/
Politics is for the moment, an equation is for eternity.
-- Albert Einstein
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
At 17:36 18.11.2002, Harrie Hazewinkel wrote: On Monday, November 18, 2002, at 04:35 PM, Derick Rethans wrote: On Mon, 18 Nov 2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. image.c only uses very little original code, so I think we can just IMHO, little is already to much. No problem - as far as i know i completley everything but swf/swc code which did not came from imageinfo.c. So it is leagal to remove the note. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
Sebastian Bergmann wrote: Henri Gomez wrote: Any date to make the change in image.c ? It's already fixed in CVS. Thanks, you're faster than light, I'll try to get a CVS snapshot. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH]-[calendar more flexible heberw date format]
since Wez response, here the patch + testing file again. that patch make the return string more flexible, and improve the speed using char insteed of emaloc memory http://212.199.221.100/moshe/calendar.patch.tar.gz Tal may u'll commit that? thnxs moshe
Re: [PHP-DEV] is_callable Bug 20216
The second argument seems to be for checking syntax only, but I can't
figure out how to make is_callable return FALSE when the second
argument is TRUE.
Try this:
var_dump(is_callable(array(1,2), true));
Hmm...OK. Yes, that does make is_callable return false. Can you explain
the logic behind this? I tried lots of other values and got TRUE. For
example:
var_dump(is_callable(array('$$$','%^'), true));
var_dump(is_callable('%^', true));
These aren't valid identifiers, but the function is (apparently) reporting
that syntax is OK.
Well, $name is just supposed to indicate which class/method you were
checking. It doesn't tell you whether the method is static or not,
because in PHP 4 it doesn't make sense.
Ah, yeah, I guess there isn't a way to tell if a method is callable
statically or not unless you check that it contains no references to
instance properties.
So, would it be fair to say this function is intended for debugging the
core? And, if you have the time, could you describe the situation where
this function is useful?
Thanks Much!
Leon
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] is_callable Bug 20216
On Mon, 18 Nov 2002, Leon Atkinson wrote:
Hmm...OK. Yes, that does make is_callable return false. Can you explain
the logic behind this? I tried lots of other values and got TRUE. For
example:
var_dump(is_callable(array('$$$','%^'), true));
var_dump(is_callable('%^', true));
These aren't valid identifiers, but the function is (apparently) reporting
that syntax is OK.
The syntax check is only intended to reject arrays that don't have a
valid structure to be used as callbacks. The valid ones are supposed to
have only 2 entries, the first of which is an object or a string, and
the second one is a string. The function doesn't do any checking of the
contents of the array.
Ah, yeah, I guess there isn't a way to tell if a method is callable
statically or not unless you check that it contains no references to
instance properties.
So, would it be fair to say this function is intended for debugging the
core? And, if you have the time, could you describe the situation where
this function is useful?
It is useful when you have a function that takes a callback as a
parameter and it needs to check whether that callback is, in fact,
callable.
-Andrei http://www.gravitonic.com/
* We are not a clone. *
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: #20461 [Opn-Bgs]: Unable to access $PHP_AUTH_USERor $PHP_AUTH_PW
On Mon, 18 Nov 2002, Edin Kadribasic wrote: On Sun, 17 Nov 2002, Rasmus Lerdorf wrote: But why do you assume that the documentation was right and the code was wrong and not the other way around? Because it was working like documented before. (When the documentation was written). Anyway, not sure what to do with this one... I don't have the energy to do a cvs check, but I remember adding this restriction years ago (php2 days) and then removing it (by commenting out the check) ages ago as well. I'm not sure PHP4 ever had this check turned on (the commented out check was ported to php4), so the documentation has not reflected reality in a very long time. I agree that this change is going to break a lot of code. Some of it is my own :) I suggest that we always populate $PHP_AUTH_USER since that one has no security consequences and the information is awailable elsewhere ($_SERVER['REMOTE_USER']). $PHP_AUTH_PW should be set when there are no safe_mode/open_basedir restrctions in effects. Would this solution be satisfactory to everyone? No, it would break my scripts. :-p Use the $_SERVER['REMOTE_USER'] as it's been documented for ages in the http auth docs.. --Jani -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PHP/MySQL memory leak?
I have a PHP script that runs as a standalone process. I'm using 4.3-dev on openBSD 3.1-stable. I pop some values in a DB through a web interface, the back-end process picks it up and processes it, and posts results back to the db. Everything works as expected up to this point. When there is nothing to process, it just spins in a loop looking for new jobs. After a few minutes, I start getting page/chunk is already free errors on the console, and after a couple of hundred of those, the process dies. I get no scripting errors or unexpected results. This sounds to me like a memory leak of some kind. It's nearly impossible to run it with most debuggers as it's not called through a web server, and I'm not running it in an environment that I can use the Zend debugger in. As it's a very vague error, I can't make a meaningful bug report, so I thought I'd ask on here. Anyone got any ideas? I saw recently that some were suggesting there were problems with the mysql extension relating to persistent connections. Is this likely to be what's affecting me? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] problem with GPL code in PHP4
On Mon, 18 Nov 2002, Harrie Hazewinkel wrote: On Monday, November 18, 2002, at 04:35 PM, Derick Rethans wrote: On Mon, 18 Nov 2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. image.c only uses very little original code, so I think we can just IMHO, little is already to much. Please point me to the GPL'ed code in there then. 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] problem with GPL code in PHP4
On Mon, 18 Nov 2002, Marcus Börger wrote: At 17:36 18.11.2002, Harrie Hazewinkel wrote: On Monday, November 18, 2002, at 04:35 PM, Derick Rethans wrote: On Mon, 18 Nov 2002, Henri Gomez wrote: Hi to all, I take a look at PHP4 license information, I see that PHP4 is licensed under an Apache Style license. I see at least 2 files, rand.c and image.c which are under GPL licence, and sus break the ASF like licence of PHP4. image.c only uses very little original code, so I think we can just IMHO, little is already to much. No problem - as far as i know i completley everything but swf/swc code which did not came from imageinfo.c. So it is leagal to remove the note. Yup, and I wrote the swf part, and the initial swc stuff. 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] htmlspecialchars iso-2022-jp patch
Hi,
Excuse me for the late reply.
I reviewed the patch and adjusted the style to the coding standards.
Attached is the revised version diff'ed against HEAD. Please verify it.
And please be sure to check out CODING_STANDARDS included in the source
package before submitting the patch from now on.
BTW, your code doesn't seem to handle the string that might result in a
string longer than 256 bytes. IMO erealloc() is lacking somewhere. As for
the other part, I see no obvious problems.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
New patch applied against the current php4-latest.tar.gz,
same location:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On 11 Nov 02, Moriyoshi Koizumi [EMAIL PROTECTED] wrote:
Could you make a patch diff'ed against the latest version of html.c in HEAD
branch? determine_charset() issue which you pointed out seems to have been
fixed already.
Moriyoshi
Adrian Gartland [EMAIL PROTECTED] wrote:
http://support.oregan.net/php/php_htmlspecialchars_iso_2022-jp.patch
On 11 Nov 02, Jan Schneider [EMAIL PROTECTED] wrote:
Zitat von Adrian Gartland [EMAIL PROTECTED]:
Attached is a patch which allows iso-2022-jp (jis) encoded text to be
passed through htmlspecialchars when the character set is
set to ISO-2022-JP.
It should also fix a tiny bug I found in determine_charset
code where len hadn't been set and then doing its
charset map walk.
Your attachment didn't go through the mailing list filters. Please post a
link where the patch can be downloaded.
Jan.
--
http://www.horde.org - The Horde Project
http://www.ammma.de - discover your knowledge
http://www.tip4all.de - Deine private Tippgemeinschaft
--
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
--
Adrian Gartland - Senior Systems Engineer - TV Portal Team
Oregan Networks UK Ltd Tel: +44 (0) 20 8846 0990
The White Building, 52-54 Glentham RoadFax: +44 (0) 20 8646 0999
Barnes, London. SW13 9JJ, United Kingdom WWW: http://www.oregan.net/
--- html.c Mon Nov 18 04:11:27 2002
+++ html.c.next Tue Nov 19 05:51:43 2002
@@ -18,7 +18,7 @@
+--+
*/
-/* $Id: html.c,v 1.65 2002/11/16 08:30:31 sebastian Exp $ */
+/* $Id: html.c,v 1.63 2002/11/11 13:31:08 moriyoshi Exp $ */
#include php.h
#if PHP_WIN32
@@ -43,7 +43,7 @@
#endif
enum entity_charset { cs_terminator, cs_8859_1, cs_cp1252,
- cs_8859_15, cs_utf_8, cs_big5, cs_gb2312,
+ cs_8859_15, cs_2022_jp, cs_utf_8, cs_big5,
+cs_gb2312,
cs_big5hkscs, cs_sjis, cs_eucjp};
typedef const char *entity_table_t;
@@ -288,6 +288,7 @@
} charset_map[] = {
{ ISO-8859-1, cs_8859_1 },
{ ISO8859-1, cs_8859_1 },
+ { ISO-2022-JP,cs_2022_jp },
{ ISO-8859-15,cs_8859_15 },
{ ISO8859-15, cs_8859_15 },
{ utf-8, cs_utf_8 },
@@ -728,8 +729,138 @@
}
/* }}} */
+/* {{{ next_iso2022_segment
+ * updates whatever psIn is pointing to the end of the multi-byte run
+ * esc$bxesc(by ; psIn =
+ */
+static const char *next_iso2022_segment(const unsigned char **psIn, int iInLen, const
+char *pcEscapeSafeEnd)
+{
+ const char *sIn = *psIn;
+ const char *pcNextEsc;
+ static const char cEsc = 033;
+ int iSegmentLength;
+ int iRemaining = iInLen;
+
+ pcNextEsc = sIn;
+ if (sIn pcEscapeSafeEnd) {
+ /* Buffer overrun if we try and spot the escape chars */
+ *psIn = sIn + iInLen;
+ return sIn;
+ } else {
+ while(1) {
+ pcNextEsc++; /* step past the current escape */
+
+ /* search for the closing escape sequence */
+ while (cEsc != *pcNextEsc iRemaining) {
+ iRemaining--;
+ pcNextEsc++;
+ }
+
+ if (cEsc != *pcNextEsc) {
+ pcNextEsc = NULL;
+ }
+
+
+ if (NULL == pcNextEsc || pcNextEsc pcEscapeSafeEnd) {
+ *psIn = sIn + iInLen;
+ return sIn;
+ } else {
+ if ('(' == pcNextEsc[1]) {
+ /*End of multi-byte run. */
+
Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine
Thanks James, And also thanks for the 'confusing' comment. ;) I've been looking through the code and have found a few places where things can be made a little more clear. If we actually push forward with the module, I've also got some ideas for adding some nice functionality to the module as well (see initial post). Diggy James Cox [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... fwiw, i have also meddled with birdstep slightly, by making the namechange from velocis to birdstep. I agree with Dan -- i think it should be pecl'ed, and perhaps not so reliant on the odbc stuff -- that whole extension is just confusing. That said, Dan is the best person to work on with this. -- james -Original Message- From: Diggy Bell [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 3:49 AM To: Dan Kalowsky Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine Thanks Dan, From looking at the module that was in ./ext/odbc, it was created using a somewhat earlier release of the RDM Server/Velocis (circa Velocis v2.x). I had to make a number of changes related to API changes in Birdstep's libraries to support ODBC 3.51. I've also started laying the groundwork to take advantage of scrollable cursors (a painful omission from the current version of RDM Server). Since there doesn't seem to be anyone familiar with Birdstep, I guess I could volunteer to be the 'expert'. In reality, I was the first beta and deployed customer back in '92, and later went to work for the company (then Raima) in '94. I was a Sr. Proj. Lead and Eng. Mgr. for their consulting subsidiary (Vista Development) until late 2000. These days I'm running my own business and use PHP for a variety of needs. But with Birdstep wanting this module, I became interested in being able to give back to the community more directly. Supporters are great, but sometimes someone needs to get in the trenches and I guess I'm silly enough to want to do it. ;) With respect to the changes, I listed the changes that I've already made in the original post, but there are some additional mods that are needed. 1. There is currently no way to ensure that connections are closed properly. If a script doesn't call birdstep_close() the module will leak connection handles and will eventually exhaust available connections on the server. 2. Birdstep's support for LONG VARCHAR columns has some limitations surrounding use of SQLFetch vs. SQLFetchScroll. To meet Birdstep's needs, I am using fixed buffers for these columns in the module. I'm looking at the possibility of using RDM Server's BLOB handling functions (the 'd_' API) to allow for more efficient handling of these columns. 3. There are some significant improvements that could be made to the error handling. The module currently has no access to error information returned from the server. There are also a few places in the code that could be handled a little more gracefully if an error occurs. As for the PECL module, I'll have to do a little more investigation into what would be required. I got started with the standard extension architecture and worked from there. If the change to PECL is straightfoward, I'll go ahead and start looking at getting that done. If you can point at any good reference sources, I'd be most thankful! :-D Diggy - Original Message - From: Dan Kalowsky [EMAIL PROTECTED] To: Diggy Bell [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Sunday, November 17, 2002 12:42 PM Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine Hello Diggy, Birdstep was rolled into the ODBC functionality, and has really not seen any support since. I don't believe anyone currently on the PHP staff is really familiar with the way the Birdstep systems work. The reality is though that I don't see many PHP users using Birdstep/Velocis support. This could of course be a chicken/egg problem, where the PHP support is lacking etc etc... What are the changes you're planning to do? If you'd like to make birdstep it's own module, I'd suggest looking at creating it as a PECL module, and working from there. Typically we don't discourage integration with systems/API's, especially if the author is willing to maintain it :) On Sunday, November 17, 2002, at 03:30 PM, Diggy Bell wrote: Hello again, I've not heard anything from anybody regarding my previous post. My first thought is that everyone is caught up in the release activities, but I would appreciate any comments that anyone might be able to offer. Thanks, Diggy Diggy Bell [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hello All, I have recently been approached
[PHP-DEV] leak() crash()
Shouldn't leak() and crash() be disabled or without functionality for normal use and instead have to be enabled with a configure option? marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Memory persistence with apache question
Problems that could arise: The sytem tries to open images and does not unset the variables...and such. I guess when everything is working you cannot do anything against. If you want to investigate more you would need a debug version from php to verify if all memory is freed. But this is the post from the developer who is assigned to the bug on Sourceforge: Date: 2002-10-23 17:59 Sender: bharat Logged In: YES user_id=42211 This is fixed in v1.3.2 marcus At 04:33 19.11.2002, Mike Leddy wrote: Hello, I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP. Recently some clients started using a gallery php script: http://gallery.sf.net that causes excessive memory utilization on the server: http://sourceforge.net/tracker/index.php?func=detailaid=498028group_id=7130atid=107130 So here goes the question: In what situations will memory allocated to a script remain with the apache process after the script has terminated ? I always thought that memory allocated would be released on script termination - Am I wrong in this assumption ? Could it be that the heap in the apache process stays at the maximally used level ? Thanks for any pointers or how I should approach resolving this problem. (I am already using 'MaxRequestsPerChild 5' in apache as a stopgap measure) Mike -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] ZE2 and classes
I have experimented with the code below.
The main thing is to introduce a function that can return a list of
all available functions (this is a first step to something bigger...).
At this point i have three problems:
1) When i create a function it is shown in the result :-)
2) When i create a class it is shown twice (same goes with methods) :-(
3) When i look for internal classes there is the problem that the the
function entries
do not know there scope (class). In other words the connection between
zend_class_entry.function_table - zend_function is a one way link
because zend_function.scope==NULL :-((
For the moment:
I know that i can fetch the scop easily if it is missing by using
apply_func_args_t type functions instead of apply_func_arg_t
and passing the scope to add_function_info.
But for me it seems to be a problem in the zend engine.
Example 1:
[marcus@zaphod php4-HEAD]$ php -r 'class zz_c { function zz_c()
{echozz_inst\n;}; static function zz_sf() {};};$o=new
zz_c();$l=function_list();sort($l);var_dump($l);' | grep zz
zz_inst
string(10) class zz_c
string(10) class zz_c
string(18) static zz_c::zz_sf
string(18) static zz_c::zz_sf
string(2) zz
string(10) zz_c::zz_c
string(10) zz_c::zz_c
Example 2: searching for methods of class defined in ext/xslt
[marcus@zaphod php4-HEAD]$ php -r 'var_dump(function_list());' | grep domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
string(7) domnode
/* {{{ add_function_info */
static int add_function_info(zend_function *func, zval *return_value TSRMLS_DC)
{
char *f;
if (func-internal_function.handler !=
zif_display_disabled_function) {
/* ?? internal_function-type = ZEND_INTERNAL_FUNCTION; */
if (func-common.scope) {
if (func-common.is_static) {
spprintf(f, 0, static %s::%s,
func-common.scope-name, func-common.function_name);
} else {
spprintf(f, 0, %s::%s,
func-common.scope-name, func-common.function_name);
}
} else {
f = estrdup(func-common.function_name);
}
add_next_index_string(return_value, f, 0);
}
return 0;
}
/* }}} */
/* {{{ add_class_info */
static int add_class_info(zend_class_entry **zclass, zval *return_value
TSRMLS_DC)
{
char *f;
spprintf(f, 0, class %s, (*zclass)-name);
add_next_index_string(return_value, f, 0);
zend_hash_apply_with_argument((*zclass)-function_table,
(apply_func_arg_t)add_function_info, return_value TSRMLS_CC);
return 0;
}
/* }}} */
/* {{{ proto array function_list()
Returns an array of all php functions */
PHP_FUNCTION(function_list)
{
if (ZEND_NUM_ARGS()) {
WRONG_PARAM_COUNT;
}
if (array_init(return_value) == FAILURE) {
php_error_docref(NULL TSRMLS_CC, E_ERROR, Unable to
initialize array);
RETURN_FALSE;
}
zend_hash_apply_with_argument(EG(function_table),
(apply_func_arg_t)add_function_info, return_value TSRMLS_CC);
zend_hash_apply_with_argument(EG(class_table),
(apply_func_arg_t)add_class_info,return_value TSRMLS_CC);
}
/* }}} */
--- mailto:[EMAIL PROTECTED] --
We are animals among animals, all children of matter,
save that we are the more disarmed. But since, unlike animals,
we know that we must die, let us prepare for that moment
by enjoying the life that has been given us by chance and for chance.
Umberto Eco, The island of the day before
- http://marcus-boerger.de -
[PHP-DEV] Error Handler
Did we ever come to some sort of agreement on the error handler thing? I'd like to maybe look into working on maybe putting together the redirect-on-error system we discussed (implementing a new directive which if set will re-direct the user to another web page if PHP errors out). Someone grunt in my direction in approval :) John |-Original Message- |From: Marcus Börger [mailto:[EMAIL PROTECTED]] |Sent: Monday, November 18, 2002 10:53 PM |To: Mike Leddy |Cc: [EMAIL PROTECTED] |Subject: Re: [PHP-DEV] Memory persistence with apache question | | |Problems that could arise: |The sytem tries to open images and does not unset the |variables...and such. I guess when everything is working you |cannot do anything against. If you want to investigate more |you would need a debug version from php to verify if all |memory is freed. | |But this is the post from the developer who is assigned to the bug on |Sourceforge: | | Date: 2002-10-23 17:59 | Sender: bharat | Logged In: YES | user_id=42211 | | This is fixed in v1.3.2 | |marcus | |At 04:33 19.11.2002, Mike Leddy wrote: |Hello, | |I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP. | |Recently some clients started using a gallery php script: |http://gallery.sf.net | |that causes excessive memory utilization on the server: |http://sourceforge.net/tracker/index.php?func=detailaid=49802 |8group_i |d=7130atid=107130 | |So here goes the question: | |In what situations will memory allocated to a script remain with the |apache process after the script has terminated ? | |I always thought that memory allocated would be released on script |termination - Am I wrong in this assumption ? | |Could it be that the heap in the apache process stays at the |maximally |used level ? | |Thanks for any pointers or how I should approach resolving this |problem. (I am already using 'MaxRequestsPerChild 5' in apache as a |stopgap |measure) | |Mike | | | |-- |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] leak() crash()
On Tue, 19 Nov 2002, Marcus Börger wrote: Shouldn't leak() and crash() be disabled or without functionality for normal use and instead have to be enabled with a configure option? --enable-debug is this switch AFAIK. 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] Memory persistence with apache question
At 10:33 PM 11/18/02 -0500, Mike Leddy wrote: Hello, In what situations will memory allocated to a script remain with the apache process after the script has terminated ? I always thought that memory allocated would be released on script termination - Am I wrong in this assumption ? Could it be that the heap in the apache process stays at the maximally used level ? My understanding is that once an Apache process increases its stack space, that stack space stays allocated until the process dies. For a short term fix lower the MaxRequestsPerChild so the big stack processes die off sooner. Long term fix is to upgrade the script causing the problem, assuming it has actually been fixed per Marcus' message. If there are only a few, kill them off by hand. Apache will start a new one. Rick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [PATCH] php4/win32/install.txt
Hello all- Here's a small patch that mentions apache2 for windows users. Related bugs on this issue can be seen here: * http://bugs.php.net/bug.php?id=16744 * http://bugs.php.net/bug.php?id=18129 Bug #18129 virtually became a support thread for this topic. The following patch doesn't go into detail as I don't feel comfortable with the subject but it at least gives an idea on what to do. Anyone feel free to go into more detail or adjust the words below before commit :) --- win32/install.txt 26 Sep 2002 19:49:34 - 1.16 +++ win32/install.txt 19 Nov 2002 07:27:53 - @@ -48,6 +48,7 @@ Personal Web Server 3 and 4 or newer Internet Information Server 3 and 4 or newer Apache 1.3.x + Apache 2.0.x (experimental) OmniHTTPd 2.0b1 and up Oreilly Website Pro Xitami @@ -201,6 +202,21 @@ Installing PHP on Windows with Apache 1.3.x + + + ATTENTION: Apache 2 Users + +At this time, support for Apache2 is experimental. It's +highly recommended you use PHP with Apache 1.3.x and not +Apache2. Documentation for installing Apache2 on windows +can be seen here: + + http://www.php.net/manual/en/install.apache2.php + +With the basic difference being that when installing as a +module you'll use php4apache2.dll instead of php4apache.dll +Both files are included within this release. + + -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
