[PHP-DEV] Re: persistent java virtual machine under PHP
Ivan Ristic wrote: How is a persistent database connection handled then? e.g. in the mysql module? Apache 1.x pre-creates a number of server processes. Each process handles a certain number of requests (one at a time), and then dies. It is then replaced with an another server process. The number of processes can vary depending on the load and the configuration. Database connections (and other resources) are persistent on the per-server-process level. What this means that an open connection in one server process cannot be reused from within another server process. I see. This is sad news indeed. But is this really a closest one can get with apache? None of the other extension libraries for apache, like nsapi, provides the notion of persistent resources shared among all apache requestst? Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
Ivan Ristic wrote: From the web serving point of view it isn't. Since Apache usually interfaces to all kinds of modules and programs, the fact that processes die naturally from time to time helps remove cumulative errors. IMHO this is a last-resort safeguard to prevent a system from falling due to badly written applications. But this can not be a reason for deciding on the architecture. From the PHP point of view, you can get problems with persistent database connections on a very high load site, that's true. But that's about the only problem. Sure, you can't build a persistent storage of information in the server but that's a minor issue. It's not a minor issue. Using persistent objects that are expensive to aquire is a common pattern, which can improve performance significantly. The above scenario prevents exactly that. I guess this is more of an apache issue then a PHP issue. I'd have to look more closely at the apache sources to investigate further. correctly and handle multithreading - is simply not worth it. By my measurements, it is worth it. (BTW, isn't nsapi the API for the Netscape web server?) Yes, it is. Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
From the PHP point of view, you can get problems with persistent database connections on a very high load site, that's true. But that's about the only problem. Sure, you can't build a persistent storage of information in the server but that's a minor issue. It's not a minor issue. Using persistent objects that are expensive to aquire is a common pattern, which can improve performance significantly. The above scenario prevents exactly that. Right, but you can still use shared memory, or, you can store persistent objects onto the filesystem. We've done the later with satisfactory results. I guess this is more of an apache issue then a PHP issue. I'd have to look more closely at the apache sources to investigate further. Apache 2 resolves this problem. You can configure it to run multithreaded. Still, the issue of having a stable PHP remains. Plus, PHP has no mechanisms to handle multithreaded access from user space, you would have to use shared memory locks or file system locks. Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
Ivan Ristic wrote: Right, but you can still use shared memory, or, you can store persistent objects onto the filesystem. We've done the later with satisfactory results. Point taken. But this only allows to share resources that can be copied into and from IPC shared memory. Some resources (like open database connections, or a JVM) are not like that, even though they are expensive to create. Apache 2 resolves this problem. You can configure it to run multithreaded. Still, the issue of having a stable PHP remains. Interesting. Does PHP run with apache 2? Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: persistent java virtual machine under PHP
On Thu, 5 Dec 2002, Maróy Ákos wrote: Ivan Ristic wrote: Right, but you can still use shared memory, or, you can store persistent objects onto the filesystem. We've done the later with satisfactory results. Point taken. But this only allows to share resources that can be copied into and from IPC shared memory. Some resources (like open database connections, or a JVM) are not like that, even though they are expensive to create. Have a look at www.vl-srm.net, and more even the article about it @ http://www.vl-srm.net/doc/articles/php-almanac-2002.php (the part about Bananas might be th emost relevant thing). Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI patch
ahem...yes i'd agree on that...i changed it to something more meaningful and attached a new patch..ah the switching between c and php programming..;) the patch is already being used for 2,5 months on an extremly big, extremly heavy-load 24x7 platform here at hp europe. basically all european hp sites rely on it. so i guess it's being tested :) cheers, Abdul - Original Message - From: Thies C. Arntzen [EMAIL PROTECTED] To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 9:10 AM Subject: Re: [PHP-DEV] OCI patch On Mon, Dec 02, 2002 at 02:27:12PM +0100, Abdul-Kareem Abo-Namous wrote: sure, here's thecode, diff'd against the latest cvs (from today). hope it's ok! sorry for beeing late. the line if (charset != \0) looks bogus to me... you probably meant if (*charset) or if (charset[ 0 ] != '\0')? besides that it looks OK to me. how well tested is that patch? if it really works for you i think we are save to commit it to HEAD onece the if thingie is fixed. re, tc oci8_charsets_oci8c.diff is for oci8.c oci8_charsets_configm4.diff for config.m4 and guess what oci8_charsets_phpoci8h.diff is for ;-))) cheers, Abdul - Original Message - From: Maxim Maletsky [EMAIL PROTECTED] To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 1:27 PM Subject: Re: [PHP-DEV] OCI patch Thies was on it. But, I think he is pretty busy right now. Resubmit it to me and I will look instead of him. Meanwhile, if Thies has time he will spare the light on the issue. -- Maxim Maletsky [EMAIL PROTECTED] Abdul-Kareem Abo-Namous [EMAIL PROTECTED] wrote... : hi everyone what happened to the patch i submitted? is it of such bad quality? ;-) maybe someone can tell me more..? :-) thanks, Abdul - Original Message - From: [EMAIL PROTECTED] To: MaximMaletsky [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 12:55 PM Subject: Re: Re: [PHP-DEV] OCI patch Ok, I've attached a pretty ok version. I had to update the config.m4 to inculde a HAVE_OCI9 define, but since I'm not really good in this kind of thing, buildconf now reports a warning autoheader: No template for symbol `HAVE_OCI9' don't know what to do about it. otherwise everything compiles and runs smoothly, so I hope you'll enjoy :-). Abdul Maxim Maletsky [EMAIL PROTECTED] schrieb am 17.10.02 12:45:57: OK, then. -- Maxim Maletsky [EMAIL PROTECTED] [EMAIL PROTECTED] wrote... : Thies, Maxim, if you could hang on for a few hours I'll be back with a few ideas and a cleaned up version of the patches + a switch for oracle 9+ to enable the new nls functions. Abdul -- -- --- oci8.c Wed Oct 9 16:55:16 2002 +++ oci8.c Thu Oct 17 13:32:09 2002 @@ -20,7 +20,7 @@ +--+ */ -/* $Id: oci8.c,v 1.176 2002/09/12 09:48:02 thies Exp $ */ +/* $Id: oci8.c,v 1.175 2002/08/20 07:26:50 edink Exp $ */ /* TODO list: * @@ -199,7 +199,7 @@ static oci_server *_oci_open_server(char *dbname,int persistent); static void _oci_close_server(oci_server *server); -static oci_session *_oci_open_session(oci_server* server,char *username,char *password,int persistent,int exclusive); +static oci_session *_oci_open_session(oci_server* server,char *username,char *password,int persistent,int exclusive,char *charset); static void _oci_close_session(oci_session *session); static sb4 oci_bind_in_callback(dvoid *, OCIBind *, ub4, ub4, dvoid **, ub4 *, ub1 *, dvoid **); @@ -451,7 +451,7 @@ OCI_DEFAULT, 0, NULL)); - + CALL_OCI(OCIHandleAlloc( OCI(pEnv), (dvoid **)OCI(pError), @@ -631,7 +631,7 @@ php_info_print_table_start(); php_info_print_table_row(2, OCI8 Support, enabled); - php_info_print_table_row(2, Revision, $Revision: 1.176 $); + php_info_print_table_row(2, Revision, $Revision: 1.175 $); #ifndef PHP_WIN32 php_info_print_table_row(2, Oracle Version, PHP_OCI8_VERSION ); php_info_print_table_row(2, Compile-time ORACLE_HOME, PHP_OCI8_DIR ); @@ -1158,9 +1158,9 @@ php_error(E_WARNING, Unknown descriptor type %d.,Z_TYPE_P(descr)); return 0; } - + CALL_OCI_RETURN(OCI(error), OCIDescriptorAlloc( - OCI(pEnv), +
Re: [PHP-DEV] Re: persistent java virtual machine under PHP
Derick Rethans wrote: Have a look at www.vl-srm.net, and more even the article about it @ http://www.vl-srm.net/doc/articles/php-almanac-2002.php (the part about Bananas might be th emost relevant thing). Thanks for the info. Though I could implement a similar deamon in java, and call it through XML PRC or other similar way via a network socket. (As my original intention was to fire up a JVM and call java functions from there.) But using network sockets is far mor expensive than calling through JNI. In my case, it seems that such a solution would not worth it. Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New SNMP function names
On Thu, 5 Dec 2002, Harrie Hazewinkel wrote: On Wednesday, December 4, 2002, at 02:49 PM, Derick Rethans wrote: Hello, while browsing the CVS I found that the following functions were added to the CVS recently: + PHP_FE(snmpv3get, NULL) + PHP_FE(snmpv3walk, NULL) + PHP_FE(snmpv3realwalk, NULL) + PHP_FALIAS(snmpv3walkoid, snmpv3realwalk, NULL) + PHP_FE(snmpv3set, NULL) But those functionnames don't adhere to our nameing guidelines. Naming guidelines?? Which I look the last time at some pointers given for this, but I could not find naming guidelines. It would help if you can point me to the precise part defining this. I quote: (from php4/CODING_STANDARDS) [1] Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words underscore delimited, with care taken to minimize the letter count. Abbreviations should not be used when they greatly decrease the readability of the function name itself. Good: 'mcrypt_enc_self_test' 'mysql_list_fields' ... [2] If they are part of a parent set of functions, that parent should be included in the user function name, and should be clearly related to the parent program or function family. This should be in the form of parent_*. A family of 'foo' functions, for example: Good: 'foo_select_bar' 'foo_insert_baz' 'foo_delete_baz' ... [5] Variable names should be in lowercase. Use underscores to separate between words. more of all, it's common practise with all extensions. If you find some which do not adhere to this standard, then there was taken into account a BC problem. This is not the case with new functions, like you added, and thus they should stick to the guide lines. As those are new functions I propose to change them to the following, to be more consistent with all other functions: snmpv3get - snmp3_get snmpv3walk - snmp3_walk snmpv3realwalk - snmp3_real_walk (or snmp3_walk_oid) snmpv3set - snmp3_get I have mentioned this some time ago already on the list. (See archive) I believe it is way easier for people to recognise the SNMPv3 version by people with the current naming. On top of that I can understand all of your concerns, but it is my opinion we have to think what is the easiest for the users/programmers of PHP. the proposed names are much more readable, and they follow the oci8_ convention of only using the verison number, the 'v' in your names don't add anything useful. IMHO, the current naming refers quite clearly to SNMP version 3 or SNMPv3. Many people know this version of the protocol as SNMPv3. I beleive that the original functions did neither have an '_' character. Why is that required suddenly?? Backward compatibility for those. Maybe you noticed that we added some aliases to other extensions because of this, but the snmp extension was left alone in that. AFAIK, changing or aliasing names is on the PHP 5 todo. (This states more or less the same opinion as expressed last time) I also would like to mention that I am looking into the usage of an SNMP-session creation and then use a single variable to provide all SNMP-session info in a single variable for the 'data retrieval' functions. Therefore, I would like to reserve the use of the underscore and then without a version number. As long as you don't break BC it's fine with me. also, there is no need to introduce an alias for a newly created function so I guess we just should drop it. I have created a similar set of functions as exist for SNMPv1. That includes the alias. That makes it easier for existing scripts to be updated with the new security featres of SNMPv3. We only add aliases if it is absolutely necesary, which is really not the case here. I'd like to make those proposed changes ASAP as they are also added in the PHP_4_3 branch which gets closer to release everyday. Personally, I do not prefer and like the name change suggested. The name snmp3_ looks to me quite weird, since the world knows this as SNMPv3. Therefore, the use of snmpv3 is preferred. yeah, and oci is really called oraclecinterface, so let's fix that too! I am even tending to give it a -1, but there is not technical reason. But there is neither a good technical reason in favour of the name change. It has little to do with a techincal reason, but more of a logical one. As all functions in PHP extensions follow the same nameing style this makes it easier for users to work with it; that's the main concern here, and that's why I'd like to change the names. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/
[PHP-DEV] Re: persistent java virtual machine under PHP
There is a servlet which accepts requests and uses native code from libphp4.so to execute them. At the same time, the Java extension is used to provide access to Java objects from PHP itself. but the ext/java as it is would not be suitable, as it would spawn new JVMs every once in a while (thus it would use a different JVM then the one that called the PHP page). No, I have been told (by someone, I do not remember) that if you use PHP as a servlet ext/java would use the same JVM. I haven't check to see whether that is correct. Where can I find documentation for calling libphp4.so? How do I execute a PHP script by calling some functions in libphp4.so? /sapi/servlet Bye, Ivan -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
Ivan Ristic wrote: No, I have been told (by someone, I do not remember) that if you use PHP as a servlet ext/java would use the same JVM. I haven't check to see whether that is correct. sound good, I'll take a look. Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] New SNMP function names
On Thursday, December 5, 2002, at 12:17 PM, Derick Rethans wrote: On Thu, 5 Dec 2002, Harrie Hazewinkel wrote: On Wednesday, December 4, 2002, at 02:49 PM, Derick Rethans wrote: Hello, while browsing the CVS I found that the following functions were added to the CVS recently: + PHP_FE(snmpv3get, NULL) + PHP_FE(snmpv3walk, NULL) + PHP_FE(snmpv3realwalk, NULL) + PHP_FALIAS(snmpv3walkoid, snmpv3realwalk, NULL) + PHP_FE(snmpv3set, NULL) But those functionnames don't adhere to our nameing guidelines. Naming guidelines?? Which I look the last time at some pointers given for this, but I could not find naming guidelines. It would help if you can point me to the precise part defining this. I quote: (from php4/CODING_STANDARDS) [1] Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words underscore delimited, with care taken to minimize the letter count. OK, I will admit the '_' is then OK, but I rather do not use it in this case, since I would like to use that for a more session oriented functions. As an example: $sess_v1 = snmp_session(1, localhost:161, public); $sess_v3 = snmp_session(3, otherhost:161, username, seclevel, auth_protocol, auth_passphrase, priv_protocol, priv_passphrase); $vara = snmp_get($sess_v1, sysUpTime.0); $varb = snmp_get($sess_v3, sysUpTime.0); Abbreviations should not be used when they greatly decrease the readability of the function name itself. Good: 'mcrypt_enc_self_test' 'mysql_list_fields' ... [2] If they are part of a parent set of functions, that parent should be included in the user function name, and should be clearly related to the parent program or function family. This should be in the form of parent_*. A family of 'foo' functions, for example: Good: 'foo_select_bar' 'foo_insert_baz' 'foo_delete_baz' ... [5] Variable names should be in lowercase. Use underscores to separate between words. more of all, it's common practise with all extensions. If you find some which do not adhere to this standard, then there was taken into account a BC problem. For that alias could have been made to assist people in a migration phase. This is not the case with new functions, like you added, and thus they should stick to the guide lines. I do not see any problem with the usage of 'v3'. As those are new functions I propose to change them to the following, to be more consistent with all other functions: snmpv3get - snmp3_get snmpv3walk - snmp3_walk snmpv3realwalk - snmp3_real_walk (or snmp3_walk_oid) snmpv3set - snmp3_get I have mentioned this some time ago already on the list. (See archive) I believe it is way easier for people to recognise the SNMPv3 version by people with the current naming. On top of that I can understand all of your concerns, but it is my opinion we have to think what is the easiest for the users/programmers of PHP. the proposed names are much more readable, and they follow the oci8_ convention of only using the verison number, the 'v' in your names don't add anything useful. I think it will create confusion when I am done with the new more session oriented approach. That I believe is neither something needed if can be avoided. IMHO, the current naming refers quite clearly to SNMP version 3 or SNMPv3. Many people know this version of the protocol as SNMPv3. I beleive that the original functions did neither have an '_' character. Why is that required suddenly?? Backward compatibility for those. Maybe you noticed that we added some aliases to other extensions because of this, but the snmp extension was left alone in that. AFAIK, changing or aliasing names is on the PHP 5 todo. So, are you saying you should have renamed them all and keeping an alias for the BC?? (This states more or less the same opinion as expressed last time) I also would like to mention that I am looking into the usage of an SNMP-session creation and then use a single variable to provide all SNMP-session info in a single variable for the 'data retrieval' functions. Therefore, I would like to reserve the use of the underscore and then without a version number. As long as you don't break BC it's fine with me. That is why I would like to keep it as is and how I propose it. It would be less confusing for PHP-coders. But I know this is a personal opinion. also, there is no need to introduce an alias for a newly created function so I guess we just should drop it. I have created a similar set of functions as exist for SNMPv1. That includes the alias. That makes it easier for existing scripts to be updated with the new security featres of SNMPv3. We only add aliases if it is absolutely necesary, which is really not the case here. I'd like to make those proposed changes ASAP as they are also added in the
[PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
Here's the patch (again, this makes all getimagesize() failures return
false instead of some of them returning NULL, and turns off error
reporting if the file fails to open.
John
--- image.org.c Thu Dec 5 06:06:48 2002
+++ image.c Wed Dec 4 22:54:16 2002
@@ -908,7 +908,7 @@
zval_dtor(*info);
if (array_init(*info) == FAILURE) {
- return;
+ RETURN_FALSE;
}
convert_to_string_ex(arg1);
@@ -919,7 +919,7 @@
break;
}
- stream = php_stream_open_wrapper(Z_STRVAL_PP(arg1), rb,
REPORT_ERRORS|IGNORE_PATH|ENFORCE_SAFE_MODE, NULL);
+ stream = php_stream_open_wrapper(Z_STRVAL_PP(arg1), rb,
IGNORE_PATH|ENFORCE_SAFE_MODE, NULL);
if (!stream) {
RETURN_FALSE;
@@ -976,7 +976,8 @@
if (array_init(return_value) == FAILURE) {
php_error_docref(NULL TSRMLS_CC, E_ERROR,
Unable to initialize array);
efree(result);
- return;
+RETURN_FALSE;
+
}
add_index_long(return_value, 0, result-width);
add_index_long(return_value, 1, result-height);
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 1:39 AM
To: John Coggeshall
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [PHP-DOC] #20822 [Com]: getimagesize() returning
null instead of false
On Wed, 4 Dec 2002, John Coggeshall wrote:
I've changed the getimagesize() function so that it RETURN_FALSE on
every error, and disables the error reporting if the file fails to
open (it still returns RETURN_FALSE)
If no one has a problem, I'll commit.
Where is the patch?
Derick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 04, 2002 9:54 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DOC] #20822 [Com]: getimagesize() returning null
instead of false
ID: 20822
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: linux
PHP Version: 4.2.3
New Comment:
maybe its also worth mentioning that getimagesize() spews out
an error if the filesize() of the file is 0 bytes :/ - this
isnt so nice :/
Previous Comments:
---
-
[2002-12-04 20:47:55] [EMAIL PROTECTED]
cutting out from the php manual:
If accessing the filename image is impossible, or if it isn't
a valid picture, getimagesize() will return FALSE and generate
a warning.
... when getimagesize() in fact returns NULL (atleast in 4.2.3
(debian unstable tree))
---
-
--
Edit this bug report at http://bugs.php.net/?id=20822edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
--
Derick Rethans
http://derickrethans.nl/
PHP Magazine - PHP Magazine for
Professionals http://php-mag.net/
---
--
--
PHP Documentation 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] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
The return false part is ok but why not showing the warnings from fopen?
marcus
At 13:16 05.12.2002, John Coggeshall wrote:
Here's the patch (again, this makes all getimagesize() failures return
false instead of some of them returning NULL, and turns off error
reporting if the file fails to open.
John
--- image.org.c Thu Dec 5 06:06:48 2002
+++ image.c Wed Dec 4 22:54:16 2002
@@ -908,7 +908,7 @@
zval_dtor(*info);
if (array_init(*info) == FAILURE) {
- return;
+ RETURN_FALSE;
}
convert_to_string_ex(arg1);
@@ -919,7 +919,7 @@
break;
}
- stream = php_stream_open_wrapper(Z_STRVAL_PP(arg1), rb,
REPORT_ERRORS|IGNORE_PATH|ENFORCE_SAFE_MODE, NULL);
+ stream = php_stream_open_wrapper(Z_STRVAL_PP(arg1), rb,
IGNORE_PATH|ENFORCE_SAFE_MODE, NULL);
if (!stream) {
RETURN_FALSE;
@@ -976,7 +976,8 @@
if (array_init(return_value) == FAILURE) {
php_error_docref(NULL TSRMLS_CC, E_ERROR,
Unable to initialize array);
efree(result);
- return;
+RETURN_FALSE;
+
}
add_index_long(return_value, 0, result-width);
add_index_long(return_value, 1, result-height);
-Original Message-
From: Derick Rethans [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 05, 2002 1:39 AM
To: John Coggeshall
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: RE: [PHP-DOC] #20822 [Com]: getimagesize() returning
null instead of false
On Wed, 4 Dec 2002, John Coggeshall wrote:
I've changed the getimagesize() function so that it RETURN_FALSE on
every error, and disables the error reporting if the file fails to
open (it still returns RETURN_FALSE)
If no one has a problem, I'll commit.
Where is the patch?
Derick
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, December 04, 2002 9:54 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DOC] #20822 [Com]: getimagesize() returning null
instead of false
ID: 20822
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Documentation problem
Operating System: linux
PHP Version: 4.2.3
New Comment:
maybe its also worth mentioning that getimagesize() spews out
an error if the filesize() of the file is 0 bytes :/ - this
isnt so nice :/
Previous Comments:
---
-
[2002-12-04 20:47:55] [EMAIL PROTECTED]
cutting out from the php manual:
If accessing the filename image is impossible, or if it isn't
a valid picture, getimagesize() will return FALSE and generate
a warning.
... when getimagesize() in fact returns NULL (atleast in 4.2.3
(debian unstable tree))
---
-
--
Edit this bug report at http://bugs.php.net/?id=20822edit=1
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
---
--
Derick Rethans
http://derickrethans.nl/
PHP Magazine - PHP Magazine for
Professionals http://php-mag.net/
---
--
--
PHP Documentation Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
The return false part is ok but why not showing the warnings from fopen? Well, the issue here is in the bugreport... It's not an issue of PHP throwing a warning when a file doesn't exist and is attempted to be opened, but it was throwing the error if the filesize was zero.. I could see that being annoying. I've got no problem leaving the warning in I just feel that the function should consistently return false on error. John -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
At 13:34 05.12.2002, John Coggeshall wrote: The return false part is ok but why not showing the warnings from fopen? Well, the issue here is in the bugreport... It's not an issue of PHP throwing a warning when a file doesn't exist and is attempted to be opened, but it was throwing the error if the filesize was zero.. I could see that being annoying. I've got no problem leaving the warning in I just feel that the function should consistently return false on error. John Ok, i just commited a patch that made *all* return values FALSE but left the messages in which i think should be discussed a little bit more. From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. marcus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OCI patch
On Thu, Dec 05, 2002 at 11:26:28AM +0100, Abdul-Kareem Abo-Namous wrote: ahem...yes i'd agree on that...i changed it to something more meaningful and attached a new patch..ah the switching between c and php programming..;) the patch is already being used for 2,5 months on an extremly big, extremly heavy-load 24x7 platform here at hp europe. basically all european hp sites rely on it. so i guess it's being tested :) cool, so: why not go-ahead and commit it yourself? if you don't already have a CVS-Acoout it's now time to apply for one;-) re, tc cheers, Abdul - Original Message - From: Thies C. Arntzen [EMAIL PROTECTED] To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 9:10 AM Subject: Re: [PHP-DEV] OCI patch On Mon, Dec 02, 2002 at 02:27:12PM +0100, Abdul-Kareem Abo-Namous wrote: sure, here's thecode, diff'd against the latest cvs (from today). hope it's ok! sorry for beeing late. the line if (charset != \0) looks bogus to me... you probably meant if (*charset) or if (charset[ 0 ] != '\0')? besides that it looks OK to me. how well tested is that patch? if it really works for you i think we are save to commit it to HEAD onece the if thingie is fixed. re, tc oci8_charsets_oci8c.diff is for oci8.c oci8_charsets_configm4.diff for config.m4 and guess what oci8_charsets_phpoci8h.diff is for ;-))) cheers, Abdul - Original Message - From: Maxim Maletsky [EMAIL PROTECTED] To: Abdul-Kareem Abo-Namous [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, November 28, 2002 1:27 PM Subject: Re: [PHP-DEV] OCI patch Thies was on it. But, I think he is pretty busy right now. Resubmit it to me and I will look instead of him. Meanwhile, if Thies has time he will spare the light on the issue. -- Maxim Maletsky [EMAIL PROTECTED] Abdul-Kareem Abo-Namous [EMAIL PROTECTED] wrote... : hi everyone what happened to the patch i submitted? is it of such bad quality? ;-) maybe someone can tell me more..? :-) thanks, Abdul - Original Message - From: [EMAIL PROTECTED] To: MaximMaletsky [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 12:55 PM Subject: Re: Re: [PHP-DEV] OCI patch Ok, I've attached a pretty ok version. I had to update the config.m4 to inculde a HAVE_OCI9 define, but since I'm not really good in this kind of thing, buildconf now reports a warning autoheader: No template for symbol `HAVE_OCI9' don't know what to do about it. otherwise everything compiles and runs smoothly, so I hope you'll enjoy :-). Abdul Maxim Maletsky [EMAIL PROTECTED] schrieb am 17.10.02 12:45:57: OK, then. -- Maxim Maletsky [EMAIL PROTECTED] [EMAIL PROTECTED] wrote... : Thies, Maxim, if you could hang on for a few hours I'll be back with a few ideas and a cleaned up version of the patches + a switch for oracle 9+ to enable the new nls functions. Abdul -- -- --- oci8.c Wed Oct 9 16:55:16 2002 +++ oci8.c Thu Oct 17 13:32:09 2002 @@ -20,7 +20,7 @@ +--+ */ -/* $Id: oci8.c,v 1.176 2002/09/12 09:48:02 thies Exp $ */ +/* $Id: oci8.c,v 1.175 2002/08/20 07:26:50 edink Exp $ */ /* TODO list: * @@ -199,7 +199,7 @@ static oci_server *_oci_open_server(char *dbname,int persistent); static void _oci_close_server(oci_server *server); -static oci_session *_oci_open_session(oci_server* server,char *username,char *password,int persistent,int exclusive); +static oci_session *_oci_open_session(oci_server* server,char *username,char *password,int persistent,int exclusive,char *charset); static void _oci_close_session(oci_session *session); static sb4 oci_bind_in_callback(dvoid *, OCIBind *, ub4, ub4, dvoid **, ub4 *, ub1 *, dvoid **); @@ -451,7 +451,7 @@ OCI_DEFAULT, 0, NULL)); - + CALL_OCI(OCIHandleAlloc( OCI(pEnv), (dvoid **)OCI(pError), @@ -631,7 +631,7 @@ php_info_print_table_start(); php_info_print_table_row(2, OCI8 Support, enabled); - php_info_print_table_row(2, Revision, $Revision: 1.176 $); + php_info_print_table_row(2, Revision, $Revision: 1.175
RE: [PHP-DEV] New SNMP function names
For what it's worth, I am in agreement with Derick... Consistency is important.. Besides... A rose is still a rose, even if it's called sweet_smelling_flower ;) OK, I will admit the '_' is then OK, but I rather do not use it in this case, since I would like to use that for a more session oriented functions. I'm As an example: $sess_v1 = snmp_session(1, localhost:161, public); $sess_v3 = snmp_session(3, otherhost:161, username, seclevel, auth_protocol, auth_passphrase, priv_protocol, priv_passphrase); $vara = snmp_get($sess_v1, sysUpTime.0); $varb = snmp_get($sess_v3, sysUpTime.0); Abbreviations should not be used when they greatly decrease the readability of the function name itself. Good: 'mcrypt_enc_self_test' 'mysql_list_fields' ... [2] If they are part of a parent set of functions, that parent should be included in the user function name, and should be clearly related to the parent program or function family. This should be in the form of parent_*. A family of 'foo' functions, for example: Good: 'foo_select_bar' 'foo_insert_baz' 'foo_delete_baz' ... [5] Variable names should be in lowercase. Use underscores to separate between words. more of all, it's common practise with all extensions. If you find some which do not adhere to this standard, then there was taken into account a BC problem. For that alias could have been made to assist people in a migration phase. This is not the case with new functions, like you added, and thus they should stick to the guide lines. I do not see any problem with the usage of 'v3'. As those are new functions I propose to change them to the following, to be more consistent with all other functions: snmpv3get - snmp3_get snmpv3walk - snmp3_walk snmpv3realwalk - snmp3_real_walk (or snmp3_walk_oid) snmpv3set - snmp3_get I have mentioned this some time ago already on the list. (See archive) I believe it is way easier for people to recognise the SNMPv3 version by people with the current naming. On top of that I can understand all of your concerns, but it is my opinion we have to think what is the easiest for the users/programmers of PHP. the proposed names are much more readable, and they follow the oci8_ convention of only using the verison number, the 'v' in your names don't add anything useful. I think it will create confusion when I am done with the new more session oriented approach. That I believe is neither something needed if can be avoided. IMHO, the current naming refers quite clearly to SNMP version 3 or SNMPv3. Many people know this version of the protocol as SNMPv3. I beleive that the original functions did neither have an '_' character. Why is that required suddenly?? Backward compatibility for those. Maybe you noticed that we added some aliases to other extensions because of this, but the snmp extension was left alone in that. AFAIK, changing or aliasing names is on the PHP 5 todo. So, are you saying you should have renamed them all and keeping an alias for the BC?? (This states more or less the same opinion as expressed last time) I also would like to mention that I am looking into the usage of an SNMP-session creation and then use a single variable to provide all SNMP-session info in a single variable for the 'data retrieval' functions. Therefore, I would like to reserve the use of the underscore and then without a version number. As long as you don't break BC it's fine with me. That is why I would like to keep it as is and how I propose it. It would be less confusing for PHP-coders. But I know this is a personal opinion. also, there is no need to introduce an alias for a newly created function so I guess we just should drop it. I have created a similar set of functions as exist for SNMPv1. That includes the alias. That makes it easier for existing scripts to be updated with the new security featres of SNMPv3. We only add aliases if it is absolutely necesary, which is really not the case here. I'd like to make those proposed changes ASAP as they are also added in the PHP_4_3 branch which gets closer to release everyday. Personally, I do not prefer and like the name change suggested. The name snmp3_ looks to me quite weird, since the world knows this as SNMPv3. Therefore, the use of snmpv3 is preferred. yeah, and oci is really called oraclecinterface, so let's fix that too! You also could have named it with the 'o' prefix. Do I have to laugh here?? I am even tending to give it a -1, but there is not technical reason. But there is neither a good technical reason in favour of the name change. It has little to do with a techincal reason, but more of a logical one. As all functions in PHP extensions follow the same nameing style this makes it easier for users to work
Re: [PHP-DEV] New SNMP function names
On Thu, 5 Dec 2002, Harrie Hazewinkel wrote: [1] Function names for user-level functions should be enclosed with in the PHP_FUNCTION() macro. They should be in lowercase, with words underscore delimited, with care taken to minimize the letter count. OK, I will admit the '_' is then OK, but I rather do not use it in this case, since I would like to use that for a more session oriented functions. As an example: $sess_v1 = snmp_session(1, localhost:161, public); $sess_v3 = snmp_session(3, otherhost:161, username, seclevel, auth_protocol, auth_passphrase, priv_protocol, priv_passphrase); $vara = snmp_get($sess_v1, sysUpTime.0); $varb = snmp_get($sess_v3, sysUpTime.0); Why didn't you introduce this right away then, if this would be the recommend way then we don't even need the snmpv3* functions. more of all, it's common practise with all extensions. If you find some which do not adhere to this standard, then there was taken into account a BC problem. For that alias could have been made to assist people in a migration phase. but adding an alias, because there was an alias for another function just doesn't compute to me. This is not the case with new functions, like you added, and thus they should stick to the guide lines. I do not see any problem with the usage of 'v3'. I do. IMHO, the current naming refers quite clearly to SNMP version 3 or SNMPv3. Many people know this version of the protocol as SNMPv3. I beleive that the original functions did neither have an '_' character. Why is that required suddenly?? Backward compatibility for those. Maybe you noticed that we added some aliases to other extensions because of this, but the snmp extension was left alone in that. AFAIK, changing or aliasing names is on the PHP 5 todo. So, are you saying you should have renamed them all and keeping an alias for the BC?? Actually, yes. But there are no aliases needed for the new functions of course. I also would like to mention that I am looking into the usage of an SNMP-session creation and then use a single variable to provide all SNMP-session info in a single variable for the 'data retrieval' functions. Therefore, I would like to reserve the use of the underscore and then without a version number. As long as you don't break BC it's fine with me. That is why I would like to keep it as is and how I propose it. It would be less confusing for PHP-coders. But I know this is a personal opinion. argh, how can hardly readable functoin names be _more_ confusing then nicely readable function names? I am even tending to give it a -1, but there is not technical reason. But there is neither a good technical reason in favour of the name change. It has little to do with a techincal reason, but more of a logical one. As all functions in PHP extensions follow the same nameing style this makes it easier for users to work with it; that's the main concern here, and that's why I'd like to change the names. I am now really curious as what is seen as easier to work with?? In to many cases I have seen that 'easier' is dictated by the developers of the tools. In this case the C-coders not the PHP coder/developer. But not thinking of users is kinda weird, and I like an example of your statement that 'easier' is dedicated by the developers as I can't think of one. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: abonamous
ext/OCI8 patches -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: persistent java virtual machine under PHP
Ivan Ristic wrote: No, I have been told (by someone, I do not remember) that if you use PHP as a servlet ext/java would use the same JVM. I haven't check to see whether that is correct. My experiences: using php-4.2.3, calling plain php pages from Tomcat seem to be OK. But when calling java code from within the PHP code, I get a native mode exception: Unexpected Signal : 11 occurred at PC=0x4DAD935E Function=zend_hash_index_update_or_next_insert+0x3A Library=/.../php-4.2.3/libs/libphp4.so Current Java thread: at net.php.reflect.setResultFromObject(Native Method) at net.php.reflect.setResult(reflect.java:105) at net.php.servlet.readCookies(servlet.java:92) at net.php.servlet.send(Native Method) at net.php.servlet.service(servlet.java:188) at net.php.servlet.service(servlet.java:212) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) I also tried the CVS version, but I can't even compile it: /.../php4/sapi/servlet/servlet.c: In function Java_net_php_servlet_startup': /.../php4/sapi/servlet/servlet.c:261: warning: passing arg 2 of `php_module_startup' from incompatible pointer type make: *** No rule to make target `sapi/servlet/java.c', needed by `sapi/servlet/java.lo'. Stop. What java.c is expected here? The same as in ext/java ? Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
On Thu, 5 Dec 2002, Tit Black Petric wrote: From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. I agree. Absolutely. Masking bona fide file operation errors would be a huge mistake, IMHO. I personally dissagree here - an error is a bit harsh if it doesn't hinder execution - I dont see anything in getimagesize() which should return E_ERROR - only E_NOTICE if the file is corrupt, unless I'm missing something. I'd go for an E_WARNING in case the file is corrupt. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
At 15:10 05.12.2002, Derick Rethans wrote: On Thu, 5 Dec 2002, Tit Black Petric wrote: From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. I agree. Absolutely. Masking bona fide file operation errors would be a huge mistake, IMHO. I personally dissagree here - an error is a bit harsh if it doesn't hinder execution - I dont see anything in getimagesize() which should return E_ERROR - only E_NOTICE if the file is corrupt, unless I'm missing something. I'd go for an E_WARNING in case the file is corrupt. Derick image.c uses E_ERROR only if the resulting array cannot be initialized. streams.c returns E_WARNING and one E_NOTICE (in case of a wrapper failure) So GetImageSize() returns mostly E_WARNING and i assume the other two messages beeing correct. marcus -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize()returning null instead of false
On Thu, 5 Dec 2002, Marcus Börger wrote: At 15:10 05.12.2002, Derick Rethans wrote: On Thu, 5 Dec 2002, Tit Black Petric wrote: From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. I agree. Absolutely. Masking bona fide file operation errors would be a huge mistake, IMHO. I personally dissagree here - an error is a bit harsh if it doesn't hinder execution - I dont see anything in getimagesize() which should return E_ERROR - only E_NOTICE if the file is corrupt, unless I'm missing something. I'd go for an E_WARNING in case the file is corrupt. Derick image.c uses E_ERROR only if the resulting array cannot be initialized. streams.c returns E_WARNING and one E_NOTICE (in case of a wrapper failure) So GetImageSize() returns mostly E_WARNING and i assume the other two messages beeing correct. Sounds fine then. Derick -- - Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] register_shutdown_function = register_offline_function
Has the new function been created yet and if not when? We have just spent 2 weeks investigating why our pages started dragging to find out that register_shutdown_function is BROKE. I am a little discouraged from what I have read on this. It seems that BC is only a concern when the right person likes the old way it worked. When the right people don't like the way things work, BC is thrown out the window and code is broken. fgetcsv is broke and has been broke IMO. It causes segfaults. Read the archives. But because it would break BC (and the orig author likes the way it workds) it stays unchanged. As for the new function,If we are creating a new function, we should create a new one for the NEW behavior. This is the same thing that happened with mysql_fetch_array. At first, it returned an associative array and mysql_fetch_row returned a numerical array. Then someone said, I want both in one call, so, someone decided that mysql_fetch_array should return both. Well, people complained (me included) and the solution was make it take an optional param to designate the array type with both being the default. Now, we all know that assoc should have been the default. So, i wrote mysql_fetch_assoc, got it commited and never looked back on that one. Thanks for the time. Brian Moon dealnews.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
Marcus Börger wrote: From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. I agree. Absolutely. Masking bona fide file operation errors would be a huge mistake, IMHO. Regards Mike Robinson -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_shutdown_function = register_offline_function
Ok, I reopened the bug. It fails with latest CVS. [root@dealnews php4-200212051430]# ./sapi/cgi/php-cgi csv.php Content-type: text/html X-Powered-By: PHP/4.4.0-dev Array ( [0] = 6 [1] = 7 [2] = 8 [3] = line1 ) Segmentation fault Brian Moon dealnews.com - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 10:00 AM Subject: Re: [PHP-DEV] register_shutdown_function = register_offline_function | Hey Brain, | | watch your attitude, we're not here to solve your problems. fgetcvs is | not broken at all, it has been fixed recently. If you still think it's | broken file a bugreport. | | Derick | | | On Thu, 5 Dec 2002, Brian Moon wrote: | | Has the new function been created yet and if not when? | | We have just spent 2 weeks investigating why our pages started dragging to | find out that register_shutdown_function is BROKE. I am a little | discouraged from what I have read on this. It seems that BC is only a | concern when the right person likes the old way it worked. When the right | people don't like the way things work, BC is thrown out the window and code | is broken. fgetcsv is broke and has been broke IMO. It causes segfaults. | Read the archives. But because it would break BC (and the orig author likes | the way it workds) it stays unchanged. | | As for the new function,If we are creating a new function, we should create | a new one for the NEW behavior. This is the same thing that happened with | mysql_fetch_array. At first, it returned an associative array and | mysql_fetch_row returned a numerical array. Then someone said, I want both | in one call, so, someone decided that mysql_fetch_array should return both. | Well, people complained (me included) and the solution was make it take an | optional param to designate the array type with both being the default. | Now, we all know that assoc should have been the default. So, i wrote | mysql_fetch_assoc, got it commited and never looked back on that one. | | Thanks for the time. | | Brian Moon | dealnews.com | | | | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, visit: http://www.php.net/unsub.php | | | -- | | - | Derick Rethans http://derickrethans.nl/ | PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ | - | | | -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] register_shutdown_function = register_offline_function
Known issue, the original patch for this problem had to be reveted since it broke the handling of mulit-line CVS fields that are quoted. I am now working on a more permanent fix. Ilia On December 5, 2002 11:39 am, Brian Moon wrote: Ok, I reopened the bug. It fails with latest CVS. [root@dealnews php4-200212051430]# ./sapi/cgi/php-cgi csv.php Content-type: text/html X-Powered-By: PHP/4.4.0-dev Array ( [0] = 6 [1] = 7 [2] = 8 [3] = line1 ) Segmentation fault Brian Moon dealnews.com - Original Message - From: Derick Rethans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 10:00 AM Subject: Re: [PHP-DEV] register_shutdown_function = register_offline_function | Hey Brain, | | watch your attitude, we're not here to solve your problems. fgetcvs is | not broken at all, it has been fixed recently. If you still think it's | broken file a bugreport. | | Derick | | On Thu, 5 Dec 2002, Brian Moon wrote: | Has the new function been created yet and if not when? | | We have just spent 2 weeks investigating why our pages started dragging to | find out that register_shutdown_function is BROKE. I am a little | discouraged from what I have read on this. It seems that BC is only a | concern when the right person likes the old way it worked. When the right | people don't like the way things work, BC is thrown out the window and code | is broken. fgetcsv is broke and has been broke IMO. It causes segfaults. | Read the archives. But because it would break BC (and the orig author likes | the way it workds) it stays unchanged. | | As for the new function,If we are creating a new function, we should create | a new one for the NEW behavior. This is the same thing that happened with | mysql_fetch_array. At first, it returned an associative array and | mysql_fetch_row returned a numerical array. Then someone said, I want both | in one call, so, someone decided that mysql_fetch_array should return both. | Well, people complained (me included) and the solution was make it take an | optional param to designate the array type with both being the default. | Now, we all know that assoc should have been the default. So, i wrote | mysql_fetch_assoc, got it commited and never looked back on that one. | | Thanks for the time. | | Brian Moon | dealnews.com | | | | | -- | PHP Development Mailing List http://www.php.net/ | To unsubscribe, visit: http://www.php.net/unsub.php | | -- | | - | Derick Rethans http://derickrethans.nl/ | PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ | - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] fgetcsv problems was: register_shutdown_function = register_offline_function
Well, this goes back to my original problem with fgetcsv then. I can not find another application that will accept a CSV file that will allow mutliline quoted fields. They stop at the newline regardless. Brian Moon dealnews.com - Original Message - From: Ilia A. [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Derick Rethans [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 10:52 AM Subject: Re: [PHP-DEV] register_shutdown_function = register_offline_function | Known issue, the original patch for this problem had to be reveted since it | broke the handling of mulit-line CVS fields that are quoted. I am now working | on a more permanent fix. | | Ilia | | On December 5, 2002 11:39 am, Brian Moon wrote: | Ok, I reopened the bug. It fails with latest CVS. | | [root@dealnews php4-200212051430]# ./sapi/cgi/php-cgi csv.php | | Content-type: text/html | X-Powered-By: PHP/4.4.0-dev | | Array | ( | [0] = 6 | [1] = 7 | [2] = 8 | [3] = line1 | ) | Segmentation fault | | Brian Moon | dealnews.com | | | - Original Message - | From: Derick Rethans [EMAIL PROTECTED] | To: Brian Moon [EMAIL PROTECTED] | Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] | Sent: Thursday, December 05, 2002 10:00 AM | Subject: Re: [PHP-DEV] register_shutdown_function = | register_offline_function | | | Hey Brain, | | | | watch your attitude, we're not here to solve your problems. fgetcvs is | | not broken at all, it has been fixed recently. If you still think it's | | broken file a bugreport. | | | | Derick | | | | On Thu, 5 Dec 2002, Brian Moon wrote: | | Has the new function been created yet and if not when? | | | | We have just spent 2 weeks investigating why our pages started dragging | | to | | | find out that register_shutdown_function is BROKE. I am a little | | discouraged from what I have read on this. It seems that BC is only a | | concern when the right person likes the old way it worked. When the | | right | | | people don't like the way things work, BC is thrown out the window and | | code | | | is broken. fgetcsv is broke and has been broke IMO. It causes | | segfaults. | | | Read the archives. But because it would break BC (and the orig author | | likes | | | the way it workds) it stays unchanged. | | | | As for the new function,If we are creating a new function, we should | | create | | | a new one for the NEW behavior. This is the same thing that happened | | with | | | mysql_fetch_array. At first, it returned an associative array and | | mysql_fetch_row returned a numerical array. Then someone said, I want | | both | | | in one call, so, someone decided that mysql_fetch_array should return | | both. | | | Well, people complained (me included) and the solution was make it take | | an | | | optional param to designate the array type with both being the default. | | Now, we all know that assoc should have been the default. So, i wrote | | mysql_fetch_assoc, got it commited and never looked back on that one. | | | | Thanks for the time. | | | | Brian Moon | | dealnews.com | | | | | | | | | | -- | | PHP Development Mailing List http://www.php.net/ | | To unsubscribe, visit: http://www.php.net/unsub.php | | | | -- | | | | - | | Derick Rethans http://derickrethans.nl/ | | PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ | | - | | | -- | 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] sapi/servlet configuration error
I am trying to configure php with the servlet and i am getting the following errors: /home/rhunter/src/php4/sapi/servlet/servlet.c: In function `Java_net_php_servlet_startup': /home/rhunter/src/php4/sapi/servlet/servlet.c:261: warning: passing arg 2 of `php_module_startup' from incompatible pointer type make: *** No rule to make target `sapi/servlet/java.c', needed by `sapi/servlet/java.lo'. Stop. Additional info: /bin/sh libtool --silent --mode=compile gcc -Isapi/servlet/ -I/home/rhunter/src/php4/sapi/servlet/ -DPHP_ATOM_INC -I/home/rhunter/src/php4/include -I/home/rhunter/src/php4/main -I/home/rhunter/src/php4 -I/home/rhunter/src/php4/Zend -I/usr/include/libxml2 -I/usr/include/imap -I/usr/include/mysql -I/usr/local/sablot/include -I/usr/local/j2sdk1.4.0_03/include #include 4 jni.h jni_md.h -D_REENTRANT -I/home/rhunter/src/php4/TSRM -g -O2 -pthread -DZTS -prefer-pic -c /home/rhunter/src/php4/sapi/servlet/servlet.c -o sapi/servlet/servlet.lo System:Redhat 7.3 PHP: cvs Java: jsdk 1.4.0_03 Servlet: Tomcat 4.1.12 Does anyone have an idea about what i need to do to fix this? -- Ray Hunter email: [EMAIL PROTECTED] www:http://venticon.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Java extension fixes
On Wed, 4 Dec 2002, Ray Hunter wrote: Will this fix the errors that occur with running PHP as a servlet in tomcat? Basically, if you were using ini_set() anywhere, or using .htaccess files to change any php settings, this patch should prevent errors/crashing. -Tony -- Ray On Wed, 2002-12-04 at 01:20, Sebastian Bergmann wrote: Tony J. White wrote: Can someone please add this to CVS or should I contact Sam Ruby (the orignal author) to do it? Committed, Sebastian -- 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 Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] persistent java virtual machine under PHP
On Wed, 4 Dec 2002, [ISO-8859-2] Maróy Ákos wrote: What happens is that the function jvm_create() gets called regularly when requesting new pages using the Java extension, from the function java_call_function_handler(): if (!JG(jenv)) jvm_create(TSRMLS_C); Actually, the JVM is unloaded by php. In the latest CVS the code from destroy_jvm() has been removed that tried to dlclose() the JVM. This was done because it is impossible to dlclose() a JVM because DestroyJavaVM() is broken in all JNI implementations. It the code you reference JG(env) is a global variable that is the jenv of the currently running JVM. Of course a new JVM needs to be created by every instance of PHP (so every httpd child in apache). The code is misleading because in past versions of PHP, the module tried to unload the JVM and load it again every time a ini setting was changed. This code should be removed and jvm_create() should be instead placed in the PHP_MINIT() function, that way the JVM will be loaded when apache is started instead of the first time java() is used by PHP. I'll get to it eventually unless someone beats me to it. -Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] persistent java virtual machine under PHP
Tony J. White wrote: Actually, the JVM is unloaded by php. In the latest CVS the code from destroy_jvm() has been removed that tried to dlclose() the JVM. This was done because it is impossible to dlclose() a JVM because DestroyJavaVM() is broken in all JNI implementations. I see. But if you dlclose()-it, what happens to open resources, like open file descriptors, network sockets, etc? It seems to be a crude way of unloading the JVM... Akos -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Java Extension Build Method
The /ext/java module is an odd duck compared to other php extentions in that it uses DL_LOAD() to load libjava instead of being linked and that it is always built as a module (.so) instead of being built static into php. I've spent some time over the past couple weeks investigating why this is done and experimenting with different build methods. Although, i haven't come up with any breakthroughs in makeing the java extension build any other way, I've compiled some notes on the subject: http://tjw.org/php_java/build_notes.php I think I have a pretty good handle on why things are the way they are, but am I missing something? -Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/servlet configuration error
On Thu, 5 Dec 2002, Ray Hunter wrote: make: *** No rule to make target `sapi/servlet/java.c', needed by `sapi/servlet/java.lo'. Stop. It looks like the sapi/servlet/Makefile.frag is not being added to your Makefile. Can you verify that there is no line in your main Makefile that starts with sapi/servlet/java.c : ? Perhaps you could try changing the line (from sapi/servlet/config.m4) PHP_ADD_MAKEFILE_FRAGMENT(sapi/servlet/Makefile.frag) to just PHP_ADD_MAKEFILE_FRAGMENT In case $ext_srcdir is something other than 'sapi/servlet' for some reason. -Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/servlet configuration error
This is the line in my Makefile: sapi/servlet/java.lo: sapi/servlet/java.c $(LIBTOOL) --mode=compile $(CC) -Isapi/servlet/ -I/home/rhunter/src/php4/sapi/servlet/ $(COMMON_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) -prefer-pic -c sapi/servlet/java.c -o sapi/servlet/java.lo Is that correct? On Thu, 2002-12-05 at 12:36, Tony J. White wrote: On Thu, 5 Dec 2002, Ray Hunter wrote: make: *** No rule to make target `sapi/servlet/java.c', needed by `sapi/servlet/java.lo'. Stop. It looks like the sapi/servlet/Makefile.frag is not being added to your Makefile. Can you verify that there is no line in your main Makefile that starts with sapi/servlet/java.c : ? Perhaps you could try changing the line (from sapi/servlet/config.m4) PHP_ADD_MAKEFILE_FRAGMENT(sapi/servlet/Makefile.frag) to just PHP_ADD_MAKEFILE_FRAGMENT In case $ext_srcdir is something other than 'sapi/servlet' for some reason. -Tony -- Ray Hunter email: [EMAIL PROTECTED] www:http://venticon.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/servlet configuration error
On Thu, 5 Dec 2002, Ray Hunter wrote: This is the line in my Makefile: sapi/servlet/java.lo: sapi/servlet/java.c $(LIBTOOL) --mode=compile $(CC) -Isapi/servlet/ -I/home/rhunter/src/php4/sapi/servlet/ $(COMMON_FLAGS) $(CFLAGS_CLEAN) $(EXTRA_CFLAGS) -prefer-pic -c sapi/servlet/java.c -o sapi/servlet/java.lo Is that correct? That chunk is added by the macro PHP_ADD_SOURCES() in sapi/servlet/config.m4. If there is no line that _starts_ with 'sapi/servlet/java.c :', then the sapi/servlet/Makefile.frag is not being included properly. If it's not, try changing the PHP_ADD_MAKEFILE_FRAGMENT like I indicated, then run: make clean rm -r configure autom4te.cache ./buildconf ./configure --with... make You will need to have installed the required packages to do this though (e.g. automake, autoconfig, etc. ) -Tony -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with commit
There seems to be a problem with CVS server: cvs -z3 -q commit -m php_error - php_error_docref xml.c Checking in xml.c; /repository/php4/ext/xml/xml.c,v -- xml.c new revision: 1.112; previous revision: 1.111 done Bad response from SMTP -- 553 (2002/12/04) Open Proxy: http(3128) Mailing the commit email to [EMAIL PROTECTED]
Re: [PHP-DEV] Problem with commit
And it's not just Marcus, I got the same error commiting to phpdoc five minutes ago... The commit DID go through, just not the notification. -Pollita There seems to be a problem with CVS server: cvs -z3 -q commit -m php_error - php_error_docref xml.c Checking in xml.c; /repository/php4/ext/xml/xml.c,v -- xml.c new revision: 1.112; previous revision: 1.111 done Bad response from SMTP -- 553 (2002/12/04) Open Proxy: http(3128) Mailing the commit email to [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Problem with commit
um.. ok.. i'm looking into a few issues with cvs right now... could you send me the full content of any header etc you might have received, anything that suggests what triggered that error... -- james -Original Message- From: Marcus Borger [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 05, 2002 9:49 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Problem with commit There seems to be a problem with CVS server: cvs -z3 -q commit -m php_error - php_error_docref xml.c Checking in xml.c; /repository/php4/ext/xml/xml.c,v -- xml.c new revision: 1.112; previous revision: 1.111 done Bad response from SMTP -- 553 (2002/12/04) Open Proxy: http(3128) Mailing the commit email to [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problem with commit
At 23:20 05.12.2002, Sara Golemon wrote: And it's not just Marcus, I got the same error commiting to phpdoc five minutes ago... The commit DID go through, just not the notification. -Pollita Same for me. Commit is ok and simply no email. Nothing more to see. marcus There seems to be a problem with CVS server: cvs -z3 -q commit -m php_error - php_error_docref xml.c Checking in xml.c; /repository/php4/ext/xml/xml.c,v -- xml.c new revision: 1.112; previous revision: 1.111 done Bad response from SMTP -- 553 (2002/12/04) Open Proxy: http(3128) Mailing the commit email to [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] test, please disregard.
-- James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: sapi/fastcgi
works fine for me without exiting, under mod_fastcgi on win32 and osx and my iis/fastcgi. There was a problem with exiting after each request on windows, but I fixed that a couple weeks ago. Shane Harald Radi wrote: i wasn't able to run it succesfully on windows. i can compile it and the binary actually works, but it exits after each request instead of keep running. but this is on my todo list for the christmas holidays, so stay tuned :) harald -Original Message- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 04, 2002 5:29 PM To: Harald Radi Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Re: sapi/fastcgi HR as neither of them works you can remove both :) What do you mean neither works? I have Zeus/PHP/FastCGI install with PHP 4.2.3 running here, seems working. Am I missing something? -- 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] sapi/fastcgi
sapi/fastcgi should be deprecated. Sebastian Bergmann wrote: What happens to sapi/fastcgi, now that we have FastCGI support in sapi/cgi? IMHO, it should be removed for PHP 4.3.0 already. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] fgetcsv problems was: register_shutdown_function = register_offline_function
Well, this goes back to my original problem with fgetcsv then. I can not find another application that will accept a CSV file that will allow mutliline quoted fields. They stop at the newline regardless. Now that's not true. Excel and other spreadsheet programs happily accept them. They also create multi-line quoted fields when exporting data that has newlines in them. And having PHP parse those correctly is one of the few ways getting data out of those apps. Edin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Core files from apache/PHP without -X
Hi all, I need someone's help. I am trying desperately to find a segfault bug in PHP's output compression. I can not make it happen on a test server as it is just me hitting the site and what I do doesn't cause a segfault. So running it in gdb doesn't work. And using the httpd -X option to create a core file does not work for the same reason. I can, however, for the purpose of finding this bug, run a debug version of PHP on a production site for 3 minutes to get dozens of segfaults (I'll consider it downtime as the server load will pass over 350). But apache only creates a core file with the -X option. So I am stuck with either having lots of people hit it and cause the bug, but not be able to debug, or I can debug but not ever come across the bug I'm looking for. So is there any way to force Apache to dump core files? TIA -steve- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Java Extension Build Method
Under the heading Build java module with -ljava you mention that there were crashing problems because libjava.so was linked agains pthread and apache wasn't. This is not uncommon problem for other libraries such as oci8. You can link apache with pthread which will prevent the segfaults. See oci8 manual page for instructions. Edin - Original Message - From: Tony J. White [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, December 05, 2002 7:35 PM Subject: [PHP-DEV] Java Extension Build Method The /ext/java module is an odd duck compared to other php extentions in that it uses DL_LOAD() to load libjava instead of being linked and that it is always built as a module (.so) instead of being built static into php. I've spent some time over the past couple weeks investigating why this is done and experimenting with different build methods. Although, i haven't come up with any breakthroughs in makeing the java extension build any other way, I've compiled some notes on the subject: http://tjw.org/php_java/build_notes.php I think I have a pretty good handle on why things are the way they are, but am I missing something? -Tony -- 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] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false
At 03:02 PM 12/5/02 +0100, Tit \Black\ Petric wrote: From my point of view accessing a file should result in an error if the file cannot be opened or in case of GetImageSize() a file operation cannot be executed. For example i would expect GetImageSize() to show an error if the information cannot be retrieved due to file corruptions. I agree. Absolutely. Masking bona fide file operation errors would be a huge mistake, IMHO. I personally dissagree here - an error is a bit harsh if it doesn't hinder execution - I dont see anything in getimagesize() which should return E_ERROR - only E_NOTICE if the file is corrupt, unless I'm missing something. If you don't want to see the filesystem error use @ to hide them. Having filesystem errors available makes troubleshooting easier. If GetImageSize never returns them, how do you figure out what is wrong when you it returns false? Rick -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] sapi/fastcgi
Shane Caraveo wrote: sapi/fastcgi should be deprecated. Done, Sebastian -- 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
Re: [PHP-DEV] sapi/servlet configuration error
Ray Hunter wrote: Does anyone have an idea about what i need to do to fix this? I just tested sapi/servlet with Tomcat 4.1.12 on Windows and the segfaults I experienced prior to the Tony's patch are still there: An unexpected exception has been detected in native code outside the VM. Unexpected Signal : EXCEPTION_ACCESS_VIOLATION occurred at PC=0xC34AB15 Function=zend_startup_module+0xD5 Library=E:\home\php\php4\Release_TS_inline\php4ts.dll Current Java thread: at net.php.servlet.startup(Native Method) at net.php.servlet.init(servlet.java:156) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:924) - locked 031B4BF8 (a org.apache.catalina.core.StandardWrapper) at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:658) - locked 031B4BF8 (a org.apache.catalina.core.StandardWrapper) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardContext.invoke(StandardContext.java:2396) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:180) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.valves.ErrorDispatcherValve.invoke(ErrorDispatcherValve.java:170) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:172) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:641) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:174) at org.apache.catalina.core.StandardPipeline$StandardPipelineValveContext.invokeNext(StandardPipeline.java:643) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:480) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:995) at org.apache.coyote.tomcat4.CoyoteAdapter.service(CoyoteAdapter.java:223) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:405) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:380) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:508) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:533) at java.lang.Thread.run(Thread.java:536) Dynamic libraries: 0x0040 - 0x00406000 c:\programme\java\bin\java.exe 0x7788 - 0x77901000 C:\WINNT\System32\ntdll.dll 0x77DA - 0x77DFD000 C:\WINNT\system32\ADVAPI32.dll 0x77E7 - 0x77F33000 C:\WINNT\system32\KERNEL32.DLL 0x77D2 - 0x77D91000 C:\WINNT\system32\RPCRT4.DLL 0x7800 - 0x78046000 C:\WINNT\system32\MSVCRT.dll 0x6D33 - 0x6D45C000 c:\programme\java\jre\bin\client\jvm.dll 0x77E0 - 0x77E65000 C:\WINNT\system32\USER32.dll 0x77F4 - 0x77F7C000 C:\WINNT\system32\GDI32.DLL 0x7754 - 0x77571000 C:\WINNT\System32\WINMM.dll 0x6D1D - 0x6D1D7000 c:\programme\java\jre\bin\hpi.dll 0x6D30 - 0x6D30D000 c:\programme\java\jre\bin\verify.dll 0x6D21 - 0x6D229000 c:\programme\java\jre\bin\java.dll 0x6D32 - 0x6D32D000 c:\programme\java\jre\bin\zip.dll 0x6D2D - 0x6D2DE000 C:\Programme\Java\jre\bin\net.dll 0x74FC - 0x74FC9000 C:\WINNT\System32\WSOCK32.dll 0x74FA - 0x74FB3000 C:\WINNT\System32\WS2_32.DLL 0x74F9 - 0x74F98000 C:\WINNT\System32\WS2HELP.DLL 0x7783 - 0x7783C000 C:\WINNT\System32\rnr20.dll 0x7797 - 0x77994000 C:\WINNT\System32\DNSAPI.DLL 0x7731 - 0x77323000 C:\WINNT\System32\iphlpapi.dll 0x774F - 0x774F5000 C:\WINNT\System32\ICMP.DLL 0x772F - 0x77307000 C:\WINNT\System32\MPRAPI.DLL 0x750C - 0x750D C:\WINNT\System32\SAMLIB.DLL 0x750E - 0x7512F000
