[PHP-DEV] Bug #12432 Updated: not valid mysql ressource
ID: 12432
Updated by: mfischer
Reported By: [EMAIL PROTECTED]
Status: Duplicate
Bug Type: MySQL related
Operating System: GNU Linux
PHP Version: 4.0.6
New Comment:
Right, it's a bug. I mixed it up with some other mysql issue.
If was even myself one who came up with that issue and it was intended to be fixed for
4.0.6 ( http://marc.theaimsgroup.com/?l=php-devm=98721095516809w=4 ), but no .. we
don't blame Zeev that he didn't found time to do it ;-)
Previous Comments:
[2001-07-30 07:38:05] [EMAIL PROTECTED]
I don't think it's a feature, its bug 8634,
sorry I missed that entry.
8634 is a urgent one I think!
[2001-07-30 05:56:44] [EMAIL PROTECTED]
This is still a feature, not a bug.
[2001-07-30 02:59:28] [EMAIL PROTECTED]
The eMail system is not working correctly,
there is some more sourcecode in my message,
please watch it directly
http://www.php.net/bugs.php?id=12432
First I thought it is some sort of scope problem,
but it is also reproducable with different var Names.
I think he ignores the link variable totally. Maybe
closes the default link (first created)
[2001-07-27 20:43:22] [EMAIL PROTECTED]
This is currently a feature. Although you haven't given full source I assume both
'mysql_connect()'s were the same. Two or more connects with the same parameter reuse
the allready established connection and don't create a new one. So, closing one of
them closes all other, too.
Re-Open if my assumption were wrong.
[2001-07-27 13:31:35] [EMAIL PROTECTED]
$eLink = mysql_connect(...);
.
.
.
class test {
function einTest() {
$eLink = mysql_connect();
mysql_close($eLink);
}
}
$aVar = new test();
$aVar-einTest();
mysql_query(...,$eLink);
- not valid mysql ressource
After einTest() it looks like it closes the outside mysql_connection ($eLink) no
matter how the connection
var in einTest() is named!
Serious stuff!
Edit this bug report at http://bugs.php.net/?id=12432edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: midgard, was RE: [PHP-DEV] Legal solution: RE: [PHP-DEV] Non-GPL readline
SL If (a) is true then I could GPL my copy of PHP and then use and SL GPL-non-LGPL code I liked You can not GPL PHP code - that's not your code, you don't hold a copyright on it. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] CVS Account Request
On Mon, Jul 30, 2001 at 10:06:05AM +0200, Ramsi Sras wrote: UNSUBSCRIBE ME PLEASE!! excuse me, but i'm getting really annoyed by these messages all the time. Can someone get this person out of the mailinglist, please? or should i add him to my already-way-too-long-mailfilter? -- Jo Giraerts Computerprutser Life BVBA Interleuvenlaan 15A, 3001 LEUVEN, BELGIUM icq:81939849, email:[EMAIL PROTECTED], ph0ne:+32(0)16 20 89 61 I've got these opium queens that move around my space, I said it's waste not, want not, I think I'll take another, I'm holding all this pain that I'm trying to smother. branvan3000 - Afrodisiac -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12465: posix_* issuing Warnings, no error code.
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: posix_* issuing Warnings, no error code. hi, I tried to use some of the posix_* functions to work with user-accounts on the system, like posix_getpwnam() and posix_getpwuid(). I expected to get an error-code back (like Failed or FALSE) for pwnames or pwuids which do not exist in /etc/passwd. Instead, PHP will write a warning message in my html-output: : Warning: posix_getpwuid(4711) failed with 'Success' in : /data/home/webmaster/admin/admin.php : on line 197 and, what I think is strange, will fail with ´Success´. Could you please modify the posix_getpw* functions in a way that they 1) do not write strange warning-messages and 2) return a NULL-Value or FALSE, where the unix getpw*(3) will return NULL (just like documented in the man-page) thanks in advance, herbert rosmanith [EMAIL PROTECTED] -- Edit bug report at: http://bugs.php.net/?id=12465edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
Zeev Suraski ([EMAIL PROTECTED]) wrote: I don't think we can change the behavior of empty() at this stage... isempty()? -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] TSRM change
Zeev, Since you've been updating TSRM stuff, I've noticed some inconsistencies. For example, php_ldap.h says: # define LDAPG(v) TSRMG(ldap_globals_id, zend_ldap_globals *, v) But ldap_globals_id is not declared anywhere. Should it be? -Andrei Nobody tried to design Windows - it just grew in random directions without any kind of thought behind it. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12466: iPlanet aborts in call to ts_resource in php4_init
From: [EMAIL PROTECTED] Operating system: Solaris 2.6 PHP version: 4.0.6 PHP Bug Type: iPlanet related Bug description: iPlanet aborts in call to ts_resource in php4_init Hi, I have tried to compile PHP 4.0.6 and 4.0.5 with support for iPlanet. Here is the configuration used: ./configure --prefix=/applic/php \ --with-nsapi=/iplanet \ --enable-track-vars \ --enable-libgcc \ --without-mysql PHP compiles just fine, but iPlanet aborts when it tries to initialize PHP by calling the php4_init function. It is the following line in php4_init that causes the abort: core_globals = ts_resource(core_globals_id); Please note that PHP 4.0.2 works fine with the same config parameters and using the same iPlanet config (actually the same iPlanet installation) I use iPlanet version 4.1 SP 5 Svein Olav Bjerkeset [EMAIL PROTECTED] -- Edit bug report at: http://bugs.php.net/?id=12466edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11790 Updated: Error compiling PHP
ID: 11790 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Feedback Bug Type: Compile Failure Operating System: Redhat Linux 5.x PHP Version: 4.0.6 New Comment: Could you please try the latest CVS snapshot from http://snaps.php.net/ to verify if this problem still exists. Previous Comments: [2001-06-30 14:04:22] [EMAIL PROTECTED] let's keep this one open and make the other one duplicate. [2001-06-30 11:50:47] [EMAIL PROTECTED] It is similar to bug report 11776, however, my Redhat Linux install is verified to be a true and correct install. I am wondering now if PHP-4.0.6 has now become not usable on older RH5.x LIBC5 platforms. Thanks. [2001-06-30 04:28:24] [EMAIL PROTECTED] Dup of: 11776 [2001-06-29 14:32:35] [EMAIL PROTECTED] I have /usr/include/sys/mount.h but not statfs.h, and not stavfs.h I tried just adding the header files to the dir. (I know it's not the preferred way) but that did not good. I am running gcc version 2.7.2.1 and libc5.3.12 on RH 5.x. I have successfully compiled php-4.0.4pl1 on this machine. Thanks for any help. [2001-06-29 09:41:44] [EMAIL PROTECTED] Do you have following header files: /usr/include/sys/statvfs.h /usr/include/sys/statfs.h /usr/include/sys/mount.h --Jani The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11790 Edit this bug report at http://bugs.php.net/?id=11790edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] TSRM change
Hi Andrei! On Mon, 30 Jul 2001, Andrei Zmievski wrote: Zeev, Since you've been updating TSRM stuff, I've noticed some inconsistencies. For example, php_ldap.h says: # define LDAPG(v) TSRMG(ldap_globals_id, zend_ldap_globals *, v) But ldap_globals_id is not declared anywhere. Should it be? It may be me, but I think it's related to TSRM: Making all in Zend make[1]: Entering directory `/usr/src/php4-200107300435/Zend' /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main -D_REENTRANT -I../TSRM -I../TSRM -g -O2 -pthread -prefer-pic -c zend_language_scanner_cc.cc c++ -DHAVE_CONFIG_H -I. -I. -I../main -D_REENTRANT -I../TSRM -I../TSRM -g -O2 -pthread -c zend_language_scanner_cc.cc -fPIC -DPIC -o zend_language_scanner_cc.lo zend_language_scanner_cc.cc: In function `int highlight_file(char *, zend_syntax_highlighter_ini *, void ***)': zend_highlight.h:42: too few arguments to function `void zend_highlight(zend_syntax_highlighter_ini *, void ***)' zend_language_scanner_cc.cc:3138: at this point in file zend_language_scanner_cc.cc: In function `int highlight_string(zval *, zend_syntax_highlighter_ini *, char *, void ***)': zend_highlight.h:42: too few arguments to function `void zend_highlight(zend_syntax_highlighter_ini *, void ***)' zend_language_scanner_cc.cc:3162: at this point in file make[1]: *** [zend_language_scanner_cc.lo] Error 1 make[1]: Leaving directory `/usr/src/php4-200107300435/Zend' make: *** [all-recursive] Error 1 teo:/usr/src/php4-200107300435 # cat config.nice #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--enable-debug' \ '--with-xslt-sablot' \ '--with-zlib' \ '--with-dom' \ '--with-mysql=/usr/local' \ '--disable-posix' \ '--enable-trans-sid' \ '--enable-shmop' \ '--enable-sockets' \ '--enable-wddx' \ $@ And this is because of the TSRMLS_DC (which I dunno what it is :) Shall I file a bug report of wait for more work from Zeev w/ his patch? -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] memory leaks in own extension
Hi, I'm writing an own extension in C++, and I have trouble with memoryleaks. I'm using PHP 4.0.6. When I enable debug I don't find my leaks, but I do find some other leaks: nn4itprotocol.cpp(1359) : Freeing 0x081FC38C (19 bytes), script=main.phtml zend_operators.c(441) : Actual location (location was relayed) Last leak repeated 77 times Here I use convert_to_string_ex(), should this leak? html.c(56) : Freeing 0x0819C4B4 (128 bytes), script=main.phtml Last leak repeated 8 times Here I use php_escape_html_entities from within my extension, is that a proper way? Anyway, the real problem is, I can't find out where the memoryleaks are, I've tried to overload new/delete functions to use emalloc/efree instead, but that didn't help me much. So, my question should be, is there any other way to detect memoryleaks within PHP? best regards... -- Robin Ericsson [EMAIL PROTECTED] NoName4Us AB Lack of money is the root of all evil. -- George Bernard Shaw -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
AMEN! I PERSONALLY DO NOT consider it a PIA to have to access the variables via $HTTP_POST... What I USUALLY do is something like this: $fldform_var1 = $HTTP_POST_VARS[form_var1]; etc. This way, I'm GUARENETEED that I got the variable FROM the location that I was expecting. Then, I refer throughout the rest of the script to $fldform_var1. Ok, also, another thing. People have been saying that We can't turn off regsiter_globals because it would require teaching arrays and stuff before we should be getting to them. Bull... ALL you have to do is say If you wish to access the data from the form field titled my_name, you MUST do $my_name = $HTTP_POST_VARS[my_name]. That's it. The student does NOT need to know at that time that $HTTP_POST_VARS is an array. You can get to that later. On Sun, 29 Jul 2001 18:25:52 -0700, [EMAIL PROTECTED] (Zeev Suraski) wrote: What you ignored completely are three facts: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. Zeev [...first part of original message deleted...] The suggestion to turn off register_globals by default is an extremely bad one. It would make using PHP nothing short of a pain in the ass, break vast amounts of code, and not improve a whole lot. I _LIKE_ that I can GET or POST to a page, and the variables will still come from the right place. [...rest of message deleted...] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: TSRM change
are you sure it isn't? There are variables generated by a macro DECLARE_MODULE_GLOBALS, so chances are it is coming from there. I was doing thousands of lines of changes though, so I may have gotten something wrong (well, may is an understatement :) At 06:31 30/07/2001, Andrei Zmievski wrote: Zeev, Since you've been updating TSRM stuff, I've noticed some inconsistencies. For example, php_ldap.h says: # define LDAPG(v) TSRMG(ldap_globals_id, zend_ldap_globals *, v) But ldap_globals_id is not declared anywhere. Should it be? -Andrei Nobody tried to design Windows - it just grew in random directions without any kind of thought behind it. -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] TSRM change
This one should already be fixed (update Zend) At 07:26 30/07/2001, [EMAIL PROTECTED] wrote: Hi Andrei! On Mon, 30 Jul 2001, Andrei Zmievski wrote: Zeev, Since you've been updating TSRM stuff, I've noticed some inconsistencies. For example, php_ldap.h says: # define LDAPG(v) TSRMG(ldap_globals_id, zend_ldap_globals *, v) But ldap_globals_id is not declared anywhere. Should it be? It may be me, but I think it's related to TSRM: Making all in Zend make[1]: Entering directory `/usr/src/php4-200107300435/Zend' /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../main -D_REENTRANT -I../TSRM -I../TSRM -g -O2 -pthread -prefer-pic -c zend_language_scanner_cc.cc c++ -DHAVE_CONFIG_H -I. -I. -I../main -D_REENTRANT -I../TSRM -I../TSRM -g -O2 -pthread -c zend_language_scanner_cc.cc -fPIC -DPIC -o zend_language_scanner_cc.lo zend_language_scanner_cc.cc: In function `int highlight_file(char *, zend_syntax_highlighter_ini *, void ***)': zend_highlight.h:42: too few arguments to function `void zend_highlight(zend_syntax_highlighter_ini *, void ***)' zend_language_scanner_cc.cc:3138: at this point in file zend_language_scanner_cc.cc: In function `int highlight_string(zval *, zend_syntax_highlighter_ini *, char *, void ***)': zend_highlight.h:42: too few arguments to function `void zend_highlight(zend_syntax_highlighter_ini *, void ***)' zend_language_scanner_cc.cc:3162: at this point in file make[1]: *** [zend_language_scanner_cc.lo] Error 1 make[1]: Leaving directory `/usr/src/php4-200107300435/Zend' make: *** [all-recursive] Error 1 teo:/usr/src/php4-200107300435 # cat config.nice #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/apache2/bin/apxs' \ '--enable-debug' \ '--with-xslt-sablot' \ '--with-zlib' \ '--with-dom' \ '--with-mysql=/usr/local' \ '--disable-posix' \ '--enable-trans-sid' \ '--enable-shmop' \ '--enable-sockets' \ '--enable-wddx' \ $@ And this is because of the TSRMLS_DC (which I dunno what it is :) Shall I file a bug report of wait for more work from Zeev w/ his patch? -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12467: Undefined entry point in php4ts.dll
From: [EMAIL PROTECTED] Operating system: NT 4.0 PHP version: 4.0.6 PHP Bug Type: Oracle related Bug description: Undefined entry point in php4ts.dll Environment: NT 4.0, Apache 1.3.14, PHP 4.0.6 (pre-compiled), Oracle Personal DB 8i (8.1.5.0.0), IE 5.0. PHP is running as a 'CGI'. I edit php.ini under c:\winnt to include php_oci8.dll and execute the PHP script below in my browser: ?php $conn = ocilogon(scott, tiger, ); ? I then get the following error message: php.exe: The procedure entry point add_assoc_long_ex could not be located in the dynamic link library php4ts.dll. This is followed by the message: Unable to load dynamic library 'c:\php\extensions/php_oci8.dll' - The specified procedure could not be found. PHP without extensions works find, as does msql. I have searched the FAQs and bulletin boards for a solution but so far nothing has worked. Paths where modules should be have been verified. Anyone have any ideas? Ed Smoot [EMAIL PROTECTED] -- Edit bug report at: http://bugs.php.net/?id=12467edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: TSRM change
On Mon, 30 Jul 2001, Zeev Suraski wrote: are you sure it isn't? There are variables generated by a macro DECLARE_MODULE_GLOBALS, so chances are it is coming from there. I was doing thousands of lines of changes though, so I may have gotten something wrong (well, may is an understatement :) Okay, indeed it's there. I've updated ext/pcre to match the new TSRM changes. -Andrei Freedom comes when you learn to let go. Creation comes when you learn to say no. -madonna -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11790 Updated: Error compiling PHP
ID: 11790 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: Compile Failure Operating System: Redhat Linux 5.x PHP Version: 4.0.6 New Comment: Tried the newest snapshot and received: filestat.c: In function `php_if_disk_total_space': filestat.c:133: storage size of `buf' isn't known filestat.c: In function `php_if_disk_free_space': filestat.c:234: storage size of `buf' isn't known make[3]: *** [filestat.lo] Error 1 Rob M. Previous Comments: [2001-07-30 10:03:21] [EMAIL PROTECTED] Could you please try the latest CVS snapshot from http://snaps.php.net/ to verify if this problem still exists. [2001-06-30 14:04:22] [EMAIL PROTECTED] let's keep this one open and make the other one duplicate. [2001-06-30 11:50:47] [EMAIL PROTECTED] It is similar to bug report 11776, however, my Redhat Linux install is verified to be a true and correct install. I am wondering now if PHP-4.0.6 has now become not usable on older RH5.x LIBC5 platforms. Thanks. [2001-06-30 04:28:24] [EMAIL PROTECTED] Dup of: 11776 [2001-06-29 14:32:35] [EMAIL PROTECTED] I have /usr/include/sys/mount.h but not statfs.h, and not stavfs.h I tried just adding the header files to the dir. (I know it's not the preferred way) but that did not good. I am running gcc version 2.7.2.1 and libc5.3.12 on RH 5.x. I have successfully compiled php-4.0.4pl1 on this machine. Thanks for any help. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11790 Edit this bug report at http://bugs.php.net/?id=11790edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11595 Updated: Error in the migration PHP3 to PHP4 with OpenLink-ODBC drive
ID: 11595 Updated by: ahill Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: ODBC related Operating System: Solaris 2.7 PHP Version: 4.0.4pl1 Assigned To: ahill New Comment: Hi, Please try with 4.0.6 or submit an ODBC trace; I am unable to reproduce. Best regards, Andrew Previous Comments: [2001-07-09 16:08:07] [EMAIL PROTECTED] Nico, Can you please generate a trace? I expect we will see a problem in the SQLPrepare where it's dropping your subquery. To enable tracing, add or uncomment the following line in the $ODBCINI file: DebugFile=/tmp/opl_debug.out and then please paste the resultant trace in. Best regards, Andrew Hill OpenLink Software [2001-06-26 17:59:09] [EMAIL PROTECTED] assigning to ahill as he knows openlink best :) [2001-06-21 11:13:00] [EMAIL PROTECTED] Sorry, message error: Warning: SQL error: [OpenLink][ODBC][Driver]General error, SQL state S1000 in SQLPrepare in /psitio/multihomed/www.elsitio.com/pub/cgi-bin/gl/av/player/test.php3 on line 19 The most strange is that I reduce the query string SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' AND P.ID_PADRE IN ( SELECT ID_HIJO FROM REAL_CAT_HIJO ) to SELECT P.* FROM REAL_CAT_PADRE P WHERE IDIOMA = 'C' it works fine IN PHP4... I don't know is very strange. Nico. [2001-06-21 11:10:52] [EMAIL PROTECTED] marking as feedback until user responds... [2001-06-21 09:50:44] [EMAIL PROTECTED] Nico, What error to you show? Best regards, Andrew Hill OpenLink Software The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=11595 Edit this bug report at http://bugs.php.net/?id=11595edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Latest TSRM patches and ext/gd
gd.c d:\home\php\php4\ext\gd\gd.c(1002) : error C2065: 'tsrm_ls' : Undeclared identifier + lots of warnings -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Security Issues - a bit of my experience
On Mon, 30 Jul 2001, Ramsi Sras wrote: Hey, idiot. you can just send a message to [EMAIL PROTECTED], stop spamming my mailbox, or else you'll be subscribed to alot more mailing lists than you ever wanted. -Sterling UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!!UNSUBSCRIBE ME PLEASE!! Zeev Suraski schrieb: At 21:34 29/07/2001, Stephen van Egmond wrote: Zeev Suraski ([EMAIL PROTECTED]) wrote: - register_globals=on leads to insecure code, which was demonstrated time and time again in the past. - Once it's off, we're going to provide methods of accessing variables which are just as easy, and quite easier in case you access them from functions. Having form variables register as global variables is not the 11th commandment, and it's kind of odd to see people treat it as such. It is quite the handy feature, and it will be a bummer to see it go. It's not going. It's just being turned off by default and flagged as use only if you REALLY know what you're doing feature, and don't really care about portability (the only way to write portable PHP apps is to assume register_globals is off, that's been true for a while now). - E_NOTICE is a runtime issue, one which you would have to check under all possible paths in your logic. That's why leaving security stuff to runtime is always never a good idea. Setting register_globals to off gives you development-time security. I must point out that if we're referring to existing code bases, E_NOTICE and register_globals=off require as much work: all code paths have to be exercised to catch all the old-style idioms. I disagree. For E_NOTICE=off, you have to go through all of the possible logical paths. For register_globals=off, you only have to know your input variables, and a searchreplace would do. It's true that in some apps, where you have no idea or don't remember what the input variables are, it would take some time to figure out what the input vars are, but it's still much easier than going through all of the possible logical paths. I was trying to step back a bit and identify some of the patterns in the attacks identified in the paper. One extremely popular pattern was spoofing variables by overwriting them: GET variables overwriting POST, usually, and I suggested that some SAPI stunt be pulled to catch that. Although this would improve things, it bears noting that: - it deprecates a valid (on Apache) idiom which, at least, Rasmus uses - this only makes it harder to spoof variables, not impossible. But at least that's something. Whatever. The idea hasn't caught on. I recognize it probably wasn't worthy. Protecting POST vars from GET has no serious security viability, even though as I said a few days ago, in practice, a hell of a lot more people know how to spoof GET vars than those who know how to spoof POST or cookie vars. I believe that having $_POST, $_GET, $_COOKIE and $_FORM would give you the best of all worlds, as it would really lead you to use the right variable for the job. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10166 Updated: read_exif_data loads whole image into memory
ID: 10166
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: *Graphics related
Operating System: Linux 2.2
PHP Version: 4.0 Latest CVS (04/04/2001)
New Comment:
In latest CVS there I have added an optional parameter
for read_exif_data():
proto read_exif_data(string filename [, int readall])
By setting 'readall' to 0 you can prevent it from
loading all of the file into memory.
Please test this.
--Jani
Previous Comments:
[2001-04-04 13:48:56] [EMAIL PROTECTED]
Some users observed that read_exif_data is too slow with 1MB image files, which is a
typical size for digital camera output. I looked into the implementation
(ext/exif/exif.c) and it looks like the whole compressed image data is always read
into memory, even though read_exif_data should be concerned with just the file header.
Here's a line from function read_exif_data:
PRE
ret = php_read_jpeg_exif(ImageInfo, (*p_name)-value.str.val,1);
/PRE
The last parameter (ReadAll=1), causes the whole image data loaded into memory inside
function scan_JPEG_header:
PRE
if (ReadAll) {
int cp, ep, size;
/* Determine how much file is left. */
cp = ftell(infile);
fseek(infile, 0, SEEK_END);
ep = ftell(infile);
fseek(infile, cp, SEEK_SET);
size = ep-cp;
Data = (uchar *)malloc(size);
if (Data == NULL) {
php_error(E_ERROR,could not allocate data for entire image);
}
got = fread(Data, 1, size, infile);
if (got != size) {
php_error(E_ERROR,could not read the rest of the image);
}
Sections[*SectionsRead].Data = Data;
Sections[*SectionsRead].Size = size;
Sections[*SectionsRead].Type = PSEUDO_IMAGE_MARKER;
(*SectionsRead)++;
/*
*HaveAll = 1;
*/
}
return TRUE;
/PRE
I believe the line above should be changed to feed 0 as value of parameter ReadAll.
Thanks.
V
Edit this bug report at http://bugs.php.net/?id=10166edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12468: --enable-gd-native-ttf option not detected
From: [EMAIL PROTECTED] Operating system: RedHat 6.2 PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: --enable-gd-native-ttf option not detected the --enable-gd-native-ttf as described in ./configure --help is not recognized because configure looks for --enable-gd-native-tt (without the 'f'). -- Edit bug report at: http://bugs.php.net/?id=12468edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12469: crash on die() from inside a class thats included
From: [EMAIL PROTECTED] Operating system: win2k PHP version: 4.0.5 PHP Bug Type: Reproducible crash Bug description: crash on die() from inside a class thats included had some ugly crashes without any output, by terminating a class-function with die(). the class was defined inside an included *.php . i think to remember same crashes with includes, that had an error (like unmatched brackets }) system: win2k + php 4.05 + apache -- Edit bug report at: http://bugs.php.net/?id=12469edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12468 Updated: --enable-gd-native-ttf option not detected
ID: 12468 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Unknown/Other Function Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: Fixed in CVS a while ago Previous Comments: [2001-07-30 13:20:10] [EMAIL PROTECTED] the --enable-gd-native-ttf as described in ./configure --help is not recognized because configure looks for --enable-gd-native-tt (without the 'f'). Edit this bug report at http://bugs.php.net/?id=12468edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12468 Updated: --enable-gd-native-ttf option not detected
ID: 12468 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Bogus Old Bug Type: Unknown/Other Function Bug Type: GD related Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: This has been reported dozens of times now and it has already been fixed too. Next time, search the bug database first before submitting bug reports.. Previous Comments: [2001-07-30 13:24:58] [EMAIL PROTECTED] Fixed in CVS a while ago [2001-07-30 13:20:10] [EMAIL PROTECTED] the --enable-gd-native-ttf as described in ./configure --help is not recognized because configure looks for --enable-gd-native-tt (without the 'f'). Edit this bug report at http://bugs.php.net/?id=12468edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12470: pg_close(); causes printf();
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.5 PHP Bug Type: PostgreSQL related Bug description: pg_close(); causes printf(); pg_close(); /exts/pgsql/pgsql.c ?? printf(\npg_close %d\n,id); -- Edit bug report at: http://bugs.php.net/?id=12470edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] TSRM compatibility note
Just FYI - code working with the old-style TSRM should still go on working. It just wouldn't take advantage of the faster single fetch approach we switched to. We should probably change ext_skel to generate new-style fetches and macros, so that new extensions take advantage of the faster approach. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #12425 Updated: apache core dumps when started with a php.ini in /usr/local/lib
Warning Could not process message with given Content-Type: multipart/mixed;boundary=3b659b4aa48fa
[PHP-DEV] Bug #12470 Updated: pg_close(); causes printf();
ID: 12470 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: PostgreSQL related Operating System: PHP Version: 4.0.5 New Comment: This has been removed in 4.0.6 Previous Comments: [2001-07-30 13:32:07] [EMAIL PROTECTED] pg_close(); /exts/pgsql/pgsql.c ?? printf(\npg_close %d\n,id); Edit this bug report at http://bugs.php.net/?id=12470edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12471: DCOM don't running
From: [EMAIL PROTECTED]
Operating system:
PHP version: 4.0.5
PHP Bug Type: COM related
Bug description: DCOM don't running
Teste PHP COM/DCOM
Warning: Unable to obtain IDispatch interface for CLSID
{B3017363-43C6-11D5-9848-00E04C3919F8}: O servidor de RPC não está
disponível. in C:\Inetpub\wwwroot\Dcom_remote.php on line 22
Objeto COM não instânciado!
--
Edit bug report at: http://bugs.php.net/?id=12471edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: TSRM compatibility note
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi zeev, is there a short explanation of this tsrm stuff somewhere ? i'd like to know which kind of functions should take use of the tsrm features. while reviewing your changes to the ext/com module i'm stumbled into a few inconsistencies (as far as i can follow). where on one hand you exaggerated in adding TSRM_* macros you left out very important functions on the other hand. maybe i'm wrong and i misunderstood the function of these macros, so a short HOWTO would be essentially. - -harald. Zeev Suraski [EMAIL PROTECTED] schrieb im Newsbeitrag news:5.1.0.14.2.20010730101740.050bb618@localhost... Just FYI - code working with the old-style TSRM should still go on working. It just wouldn't take advantage of the faster single fetch approach we switched to. We should probably change ext_skel to generate new-style fetches and macros, so that new extensions take advantage of the faster approach. Zeev -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBO2Wt5a1+myS9SSHxEQK2rACfYQ9FrNoszFW4pHL1y/iE3bRb1HUAn1Jy W4GO6+3JUAeUgYNFsb7LB8y+ =PdxQ -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] gmp_init with a base argument
Hello,
Because decbin is limited to 31 bit values, I thought that the gmp
extension might be expanded a bit: If you add an optional base argument
to gmp, then we actually have a large number-bit decbin. I think that
would be nice.
Proposed patch below.
(The patch is for php 4.0.6; I can easily make one for php-cvs if
wanted.)
diff -u php-4.0.6-orig/ext/gmp/gmp.c php-4.0.6/ext/gmp/gmp.c
--- php-4.0.6-orig/ext/gmp/gmp.cThu May 24 14:41:52 2001
+++ php-4.0.6/ext/gmp/gmp.c Mon Jul 30 22:01:55 2001
@@ -160,7 +160,7 @@
if(Z_TYPE_PP(zval) == IS_RESOURCE) { \
ZEND_FETCH_RESOURCE(gmpnumber, mpz_t *, zval, -1, GMP_RESOURCE_NAME, le_gmp);\
} else {\
- if(convert_to_gmp(gmpnumber,zval) == FAILURE) {\
+ if(convert_to_gmp(gmpnumber,zval,0) == FAILURE) {\
RETURN_FALSE;\
}\
ZEND_REGISTER_RESOURCE(NULL, gmpnumber, le_gmp);\
@@ -170,8 +170,8 @@
#define INIT_GMP_NUM(gmpnumber) { gmpnumber=emalloc(sizeof(mpz_t));
mpz_init(*gmpnumber); }
#define FREE_GMP_NUM(gmpnumber) { mpz_clear(*gmpnumber); efree(gmpnumber); }
-/* Convert zval to be gmp number */
-static int convert_to_gmp(mpz_t * *gmpnumber, zval **val)
+/* Convert string to be gmp number */
+static int convert_to_gmp(mpz_t * *gmpnumber, zval **val, int base)
{
int ret = 0;
@@ -188,11 +188,14 @@
case IS_STRING:
{
char *numstr = Z_STRVAL_PP(val);
- if(numstr[0] == '0' (numstr[1] == 'x' || numstr[1] == 'X'))
{
- ret = mpz_init_set_str(**gmpnumber, numstr+2, 16);
- } else {
- ret = mpz_init_set_str(**gmpnumber, numstr, 10);
+ if (base==0) {
+ if(numstr[0] == '0' (numstr[1] == 'x' || numstr[1]
+== 'X')) {
+ base=16;
+ } else {
+ base=10;
+ }
}
+ ret = mpz_init_set_str(**gmpnumber, numstr, base);
}
break;
default:
@@ -391,22 +394,31 @@
}
-/* Remove the following function when you have succesfully modified config.m4
- so that your module can be compiled into PHP, it exists only for testing
- purposes. */
-
-/* {{{ proto resource gmp_init(mixed number)
+/* {{{ proto resource gmp_init(mixed number [, int base ])
Initializes GMP number */
ZEND_FUNCTION(gmp_init)
{
- zval **number_arg;
+ zval **number_arg, **base_arg;
mpz_t * gmpnumber;
+ int argc;
+ int base=0;
- if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, number_arg) == FAILURE){
+ argc = ZEND_NUM_ARGS();
+ if (argc 1 || argc 2 || zend_get_parameters_ex(argc, number_arg,
+base_arg) == FAILURE){
WRONG_PARAM_COUNT;
}
- if(convert_to_gmp(gmpnumber,number_arg) == FAILURE) {
+ if (argc==2) {
+ convert_to_long_ex(base_arg);
+ base = Z_LVAL_PP(base_arg);
+ }
+
+ if(base 2 || base 36) {
+ zend_error(E_WARNING, Bad base for conversion: %d (should be between
+2 and 36), base);
+ RETURN_FALSE;
+ }
+
+ if(convert_to_gmp(gmpnumber,number_arg,base) == FAILURE) {
RETURN_FALSE;
}
--
Greetings from Troels Arvin, Copenhagen, Denmark
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12472: cannot install pear
From: [EMAIL PROTECTED] Operating system: Slackware Linux 8.0 / 2.4.7 PHP version: 4.0.6 PHP Bug Type: *Compile Issues Bug description: cannot install pear doing a 'make install' dies when attempting to install pear. configure options: --with-gettext --enable-sysvshm --enable-sysvsem --with-apxs --enable-ftp --with-mcrypt --with-mcal --with-imap --with-pear Everything compiles and installs fine without the --with-pear option, but adding it causes the following: ...snip... make[1]: Leaving directory '/root/php-4.0.6' Making install in pear make[1]: Entering directory '/root/php-4.0.6/pear' make[2]: Entering directory '/root/php-4.0.6/pear' shtool:mkdir:Error: invalid number of arguments (at least 1 expected) shtool:mkdir:Hint: run '/root/php-4.0.6/build/shtool mkdir -h' or 'man shtool' for details ...endsnip... Any ideas? I have tried specifying a directory for pear, and also compiled the newest shtool and placed it in the build dir, but I know that isn't the problem.. -- Edit bug report at: http://bugs.php.net/?id=12472edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12433 Updated: Curl Crush, CURLOPT_WRITEHEADER
ID: 12433 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: GNU Linux PHP Version: 4.0.6 New Comment: fixed in cvs. Previous Comments: [2001-07-27 13:35:23] [EMAIL PROTECTED] After using curl_setopt - CURLOPT_WRITEHEADER to a valid filepointer curl somehow crushes. Excerpt from apache error_log [notice] child pid 14646 exit signal Segmentation fault (11) Bad Stuff! Edit this bug report at http://bugs.php.net/?id=12433edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11856 Updated: CURLOPT_HEADER
ID: 11856 Updated by: sterling Reported By: [EMAIL PROTECTED] Status: Open Bug Type: cURL related Operating System: i686-pc-linux-gnu PHP Version: 4.0 Latest CVS (2001-07-03) New Comment: fixed in cvs. Previous Comments: [2001-07-03 11:08:24] [EMAIL PROTECTED] Hi Sterling Hughes, the follow code from php doku doesnt work with the current cvs version: - $ch = curl_init (http://www.php.net/;); $fp = fopen (php_homepage.txt, w); curl_setopt ($ch, CURLOPT_FILE, $fp); curl_setopt ($ch, CURLOPT_HEADER, 0); curl_exec ($ch); curl_close ($ch); fclose ($fp); - ... produce an output like HTTP/1.1 200 OK !without! any print or echo and the file php_homepage.txt is empty. I think it's a problem with CURLOPT_WRITEHEADER, because if i set this option, the script work fine. my config: libcurl 7.8 (OpenSSL 0.9.6a) (ipv6 enabled) Regards, -- Steve Alberty Edit this bug report at http://bugs.php.net/?id=11856edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11856 Updated: CURLOPT_HEADER
ID: 11856 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: i686-pc-linux-gnu PHP Version: 4.0 Latest CVS (2001-07-03) New Comment: close Previous Comments: [2001-07-30 17:05:12] [EMAIL PROTECTED] fixed in cvs. [2001-07-03 11:08:24] [EMAIL PROTECTED] Hi Sterling Hughes, the follow code from php doku doesnt work with the current cvs version: - $ch = curl_init (http://www.php.net/;); $fp = fopen (php_homepage.txt, w); curl_setopt ($ch, CURLOPT_FILE, $fp); curl_setopt ($ch, CURLOPT_HEADER, 0); curl_exec ($ch); curl_close ($ch); fclose ($fp); - ... produce an output like HTTP/1.1 200 OK !without! any print or echo and the file php_homepage.txt is empty. I think it's a problem with CURLOPT_WRITEHEADER, because if i set this option, the script work fine. my config: libcurl 7.8 (OpenSSL 0.9.6a) (ipv6 enabled) Regards, -- Steve Alberty Edit this bug report at http://bugs.php.net/?id=11856edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11901 Updated: CURLOPT_HEADERFUNCTION result wrong header
ID: 11901
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: cURL related
Operating System: i686-pc-linux-gnu
PHP Version: 4.0 Latest CVS (2001-07-05)
New Comment:
fixed in cvs.
Previous Comments:
[2001-07-05 06:16:45] [EMAIL PROTECTED]
Hi,
the code:
function get_header($tmp1,$tmp2){
echo R1:$tmp1brR2:$tmp2br;
return false;
}
curl_setopt ($ch, CURLOPT_HEADERFUNCTION, get_header);
results only: HTTP/1.1 200 OK and not the complete header.
also the function get_header was not called for each header line.
Regards,
Steve
Edit this bug report at http://bugs.php.net/?id=11901edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11901 Updated: CURLOPT_HEADERFUNCTION result wrong header
ID: 11901
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: cURL related
Operating System: i686-pc-linux-gnu
PHP Version: 4.0 Latest CVS (2001-07-05)
New Comment:
fixed in cvs.
Previous Comments:
[2001-07-30 17:06:24] [EMAIL PROTECTED]
fixed in cvs.
[2001-07-05 06:16:45] [EMAIL PROTECTED]
Hi,
the code:
function get_header($tmp1,$tmp2){
echo R1:$tmp1brR2:$tmp2br;
return false;
}
curl_setopt ($ch, CURLOPT_HEADERFUNCTION, get_header);
results only: HTTP/1.1 200 OK and not the complete header.
also the function get_header was not called for each header line.
Regards,
Steve
Edit this bug report at http://bugs.php.net/?id=11901edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11908 Updated: Post not binary safe
ID: 11908
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: cURL related
Operating System: i686-pc-linux-gnu
PHP Version: 4.0 Latest CVS (2001-07-05)
New Comment:
CURLOPT_BINARYTRANSFER is only for use with
CURLOPT_RETURNTRANSFER.
Previous Comments:
[2001-07-05 10:36:13] [EMAIL PROTECTED]
Hi,
the code:
$ch = curl_init (http://www.php.net/;);
$fp = fopen (php_homepage.txt, w);
for ($str[field1]=,$i=0;$i256;$i++,$str[field1].=chr($i)){}
curl_setopt ($ch, CURLOPT_POSTFIELDS, $str);
curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 1);
//curl_setopt ($ch, CURLOPT_BINARYTRANSFER, 1);
curl_exec ($ch);
curl_close ($ch);
fclose ($fp);
-
are not binary safe.
if the CURLOPT_BINARYTRANSFER set to 1,
cURL results:
Warning: Cannot call the CURLOPT_WRITEFUNCTION
Regards,
--
Steve
Edit this bug report at http://bugs.php.net/?id=11908edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11908 Updated: Post not binary safe
ID: 11908
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: cURL related
Operating System: i686-pc-linux-gnu
PHP Version: 4.0 Latest CVS (2001-07-05)
New Comment:
close, sorry guys, its been awhile.
Previous Comments:
[2001-07-30 17:07:44] [EMAIL PROTECTED]
CURLOPT_BINARYTRANSFER is only for use with
CURLOPT_RETURNTRANSFER.
[2001-07-05 10:36:13] [EMAIL PROTECTED]
Hi,
the code:
$ch = curl_init (http://www.php.net/;);
$fp = fopen (php_homepage.txt, w);
for ($str[field1]=,$i=0;$i256;$i++,$str[field1].=chr($i)){}
curl_setopt ($ch, CURLOPT_POSTFIELDS, $str);
curl_setopt ($ch, CURLOPT_FILE, $fp);
curl_setopt ($ch, CURLOPT_HEADER, 1);
//curl_setopt ($ch, CURLOPT_BINARYTRANSFER, 1);
curl_exec ($ch);
curl_close ($ch);
fclose ($fp);
-
are not binary safe.
if the CURLOPT_BINARYTRANSFER set to 1,
cURL results:
Warning: Cannot call the CURLOPT_WRITEFUNCTION
Regards,
--
Steve
Edit this bug report at http://bugs.php.net/?id=11908edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10673 Updated: CURL/PHP causes lengthy Apache Keepalive
ID: 10673 Updated by: sterling Reported By: [EMAIL PROTECTED] Status: Open Bug Type: cURL related Operating System: Linux PHP Version: 4.0.6 New Comment: I'm gonna close this one. its been awhile, and no one else seems to have this problem and I certainly can't reproduce it. Previous Comments: [2001-06-26 16:35:19] [EMAIL PROTECTED] Same problem still exists with CURL 7.8 and PHP 4.0.6. Any more ideas? [2001-06-22 12:46:58] [EMAIL PROTECTED] Updated version. [2001-06-05 17:27:51] [EMAIL PROTECTED] Ok, I updated to curl-7.8-pre4 and PHP-4.0.6RC2 and tested with the same results. :-( Anything else I should try? -Dave [2001-06-03 17:49:32] [EMAIL PROTECTED] First of all, try the latest release candidate for PHP 4.0.6: http://www.php.net/~andi/php-4.0.6RC2.tar.gz Note: You have to get the latest and greatest Curl from CVS to get this work. --Jani [2001-05-04 13:31:59] [EMAIL PROTECTED] Greetings. I have Apache/1.3.14 (Unix) running with PHP/4.0.4pl1 installed as a module and CURL 7.7.1 added to that. Our web sites need to fetch a request from a remote ad server in real-time as each page is generated. If $adr is the request, I used to use: $success = @readfile($adr); But then I found CURL and saw that is (a) was more robust and (b) seems to be more efficient than readfile. So I now use CURL in he following way: $aje_ch = @curl_init($adr); @curl_setopt ($aje_ch, CURLOPT_TIMEOUT, 1); @curl_setopt ($aje_ch, CURLOPT_MUTE, 1); @curl_exec ($aje_ch); @curl_close ($aje_ch); This works great, except that if I have Keepalive on in my Apache configuration file, the httpd server sits in keepalive state for FAR longer when using CURL than it does when using readfile. In the course of 2 or 3 hours, my server would normally be at about 150 httpd processes running at any given point in time. But when using CURL, it jumps to 650 httpd processes, with the lions share (99%) of those sitting in the keepalive state for very long. It seems like the CURL requests are causing Apache to set its Keepalive timeout to something much higher than it should be. Setting keepalive off in Apache's conf file works around this problem, but decreases server efficiency. I'd love to solve this problem. Please help! :-) For the record, this was posted to the cURL bug tracker over on SourceForge (http://sourceforge.net/tracker/?func=detailatid=100976ai d=418860group_id=976), and we went through quite a few gyrations with no success. Specifically, we tried disabling KeepAlive on the REMOTE server to see if that had any affect, and it did not. It seems not to matter what we request from, rather that any requests using PHP/cURL/Apache result in the LOCAL Apache bloating out of control with KeepAlive requests. Reverting back to readfile() based requests solves this problem but, well, cURL is better. ;-) All help would be appreciated, and I am available and willing to test anything on our servers. Thanks! -Dave Edit this bug report at http://bugs.php.net/?id=10673edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10673 Updated: CURL/PHP causes lengthy Apache Keepalive
ID: 10673 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: Linux PHP Version: 4.0.6 New Comment: *arggghh* close. Mozilla sucks! Previous Comments: [2001-07-30 17:09:07] [EMAIL PROTECTED] I'm gonna close this one. its been awhile, and no one else seems to have this problem and I certainly can't reproduce it. [2001-06-26 16:35:19] [EMAIL PROTECTED] Same problem still exists with CURL 7.8 and PHP 4.0.6. Any more ideas? [2001-06-22 12:46:58] [EMAIL PROTECTED] Updated version. [2001-06-05 17:27:51] [EMAIL PROTECTED] Ok, I updated to curl-7.8-pre4 and PHP-4.0.6RC2 and tested with the same results. :-( Anything else I should try? -Dave [2001-06-03 17:49:32] [EMAIL PROTECTED] First of all, try the latest release candidate for PHP 4.0.6: http://www.php.net/~andi/php-4.0.6RC2.tar.gz Note: You have to get the latest and greatest Curl from CVS to get this work. --Jani The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/?id=10673 Edit this bug report at http://bugs.php.net/?id=10673edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] TSRM compatibility note
On Mon, 30 Jul 2001, Zeev Suraski wrote: We should probably change ext_skel to generate new-style fetches and macros, so that new extensions take advantage of the faster approach. Ok. Will fix later this week. Have to first catch up on what this actually means. (I lost my home connection to the net at the beginning of April, haven't followed most of the discussion going on, got a new connection 12 days ago, and now gone through mails to 3. July...) -- Jouni -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] AW: fortunately it works now ..
Multithreaded: CoInitialize() is actually in basic_functions.c not in COM.c - interestingly. i.e. the code in COM.c is called, but is the second call to CoInitialize(). CoInitializeEx() would need to be callsed if we plan to be multi-threaded. wouldn't it be evident that CoInitialize[Ex]() and CoUninitialize() are called from the ext/com module constructor and destructor functions instead of the basic_functions ones ? which concurrency model should be chosen ? i would suggest to default to apartment-threaded and let users switch to multi-threaded by an ini setting. -harald. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12099 Updated: SIGSEGV bug in module sablotron
ID: 12099 Updated by: sterling Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Sablotron XSL Operating System: Debian Linux (testing) PHP Version: 4.0CVS-2001-07-12 New Comment: All current development is being focused on the XSLT module (--enable-xslt --with-xslt-sablot). Please upgrade to the latest CVS and use that extension. Previous Comments: [2001-07-12 08:11:26] [EMAIL PROTECTED] SIGSEGV in sablotron module gdb ./httpd -X (gdb) run -X Starting program: ./httpd -X Program received signal SIGSEGV, Segmentation fault. 0x811824c in _efree (ptr=0x5a5a5a5a, __zend_filename=0x81a6560 sablot.c, __zend_lineno=1380, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:212 212 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size); #0 0x811824c in _efree (ptr=0x5a5a5a5a, __zend_filename=0x81a6560 sablot.c, __zend_lineno=1380, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:212 #1 0x80a352d in _php_sablot_error (userData=0x0, p=0x82b2280, code=76, level=MH_LEVEL_INFO, fields=0x8348b38) at sablot.c:1380 #2 0x4009c47d in Situation::generateMessage (this=0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050, theMessage=@0xbfffdf80) at situa.cpp:278 #3 0x4009c952 in Situation::message (this=0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050) at situa.cpp:343 #4 0x4009f406 in Tree::report (this=0x829c380, S=@0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050) at tree.cpp:458 #4 0x4009f406 in Tree::report (this=0x829c380, S=@0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050) at tree.cpp:458 #5 0x4009fb8d in Tree::parse (this=0x829c380, S=@0x82b2218, d=0x82dad60) at tree.cpp:563 #6 0x400939c8 in Processor::addLineParse (this=0x82b2280, S=@0x82b2218, newTree=@0x82b2284, absolute=@0xbfffe0e0, isXSL=1) at proc.cpp:549 #7 0x40093f7f in Processor::readTreeFromURI (this=0x82b2280, S=@0x82b2218, newTree=@0x82b2284, location=@0xbfffe180, base=@0xbfffe168, isXSL=1) at proc.cpp:594 #8 0x40091f71 in Processor::open (this=0x82b2280, S=@0x82b2218, sheetURI=0x82d2434 /rscr/www/base/rscr/style/rz-program.xsl, inputURI=0x82d267c arg:/input) at proc.cpp:270 #9 0x4009752f in SablotRunProcessor (processor_=0x82b2280, sheetURI=0x82d2434 /rscr/www/base/rscr/style/rz-program.xsl, inputURI=0x82d267c arg:/input, resultURI=0x82d26fc arg:/_result, params=0x0, arguments=0x82d285c) at sablot.cpp:399 #10 0x80a0cfe in php_if_xslt_transform (ht=6, return_value=0x82d281c, this_ptr=0x0, return_value_used=0) at sablot.c:458 #11 0x814c57a in execute (op_array=0x82461cc) at ./zend_execute.c:1573 #12 0x8128ee4 in zend_execute_scripts (type=8, file_count=3) at zend.c:750 #13 0x807b86f in php_execute_script (primary_file=0xb818) at main.c:1277 #14 0x813ae5c in apache_php_module_main (r=0x8288824, display_source_mode=0) at sapi_apache.c:90 #15 0x80783f2 in send_php () #16 0x807842a in send_parsed_php () #17 0x8162169 in ap_invoke_handler () #18 0x8176acf in process_request_internal () #19 0x8176b36 in ap_process_request () #20 0x816da56 in child_main () #21 0x816dc11 in make_child () #22 0x816dd8c in startup_children () #23 0x816e3fc in standalone_main () #24 0x816ec2c in main () #25 0x4027a2db in __libc_start_main () from /lib/libc.so.6 --- php-error.log --- Last leak repeated 23 times zend_hash.c(1027) : Freeing 0x0834A5E4 (7 bytes), script=/rscr/www/appserv/schema.html sablot.c(1397) : Freeing 0x08328244 (12 bytes), script=/rscr/www/appserv/schema.html Last leak repeated 23 times zend_hash.c(1027) : Freeing 0x082E1DDC (7 bytes), script=/rscr/www/appserv/schema.html --- apache Server version: Apache/1.3.20 (Unix) Server built: Jul 12 2001 13:23:37 ./src/httpd -l Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_status.c mod_alias.c mod_rewrite.c mod_access.c mod_auth.c mod_php4.c mod_gzip.c --- php --- PHP4.0.7-dev (last CVS) ./configure --prefix=/rscr/appserv \ --with-apache=../apache_1.3.20 \ --with-config-file-path=/rscr/appserv/conf \ --with-regex=system \ --enable-debug \ --without-pcre-regex \ --disable-rpath \ --disable-session \ --enable-memory-limit \ --enable-sysvsem \ --enable-sysvshm \ --enable-shmop \ --enable-track-vars \ --enable-ctype \ --enable-sockets \ --without-pgsql \ --with-sablot=/usr \ --with-dom=/usr \ --with-mysql=/usr \--with-iconv=/usr \ --with-ming=/usr
Re: [PHP-DEV] Bug #12464: IIS5.0 header problems
hiyya people [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Hi j.gray! On Mon, 30 Jul 2001, [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: win 2k PHP version: 4.0.6 PHP Bug Type: Session related Bug description: IIS5.0 header problems The below message is getting spewed from an IIS5.0 win2k PHP 4.06 MySQL 3.23.39a App. when it shouldn't HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Date: Mon, 30 Jul 2001 10:24:55 GMT Content-type: text/html X-Powered-By: PHP/4.0.6 Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache to me this looks like you have activated something like anticaching or nocache in IIE. (and that's why it's sending out an expire date with a date dating back some years) but it's just a guess. / d See the line PHP/4.0.6 Expires: Thu, 19 Nov 1981 what is with that. To me it looks like it is sending expired headings If I turn off keep alives all is well. This isn't caused by proxies or firewalls. I can confirmed it happened to me several times: Linux/Apache 1.3.17/PHP4.0.6 (using output buffering)/Netscape4.7 namely, some headers of the response appeared on the page in NS. -- teodor -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12099 Updated: SIGSEGV bug in module sablotron
ID: 12099 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sablotron XSL Operating System: Debian Linux (testing) PHP Version: 4.0CVS-2001-07-12 New Comment: I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. I will remember to change the status. Previous Comments: [2001-07-30 17:21:47] [EMAIL PROTECTED] All current development is being focused on the XSLT module (--enable-xslt --with-xslt-sablot). Please upgrade to the latest CVS and use that extension. [2001-07-12 08:11:26] [EMAIL PROTECTED] SIGSEGV in sablotron module gdb ./httpd -X (gdb) run -X Starting program: ./httpd -X Program received signal SIGSEGV, Segmentation fault. 0x811824c in _efree (ptr=0x5a5a5a5a, __zend_filename=0x81a6560 sablot.c, __zend_lineno=1380, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:212 212 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p-size); #0 0x811824c in _efree (ptr=0x5a5a5a5a, __zend_filename=0x81a6560 sablot.c, __zend_lineno=1380, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:212 #1 0x80a352d in _php_sablot_error (userData=0x0, p=0x82b2280, code=76, level=MH_LEVEL_INFO, fields=0x8348b38) at sablot.c:1380 #2 0x4009c47d in Situation::generateMessage (this=0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050, theMessage=@0xbfffdf80) at situa.cpp:278 #3 0x4009c952 in Situation::message (this=0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050) at situa.cpp:343 #4 0x4009f406 in Tree::report (this=0x829c380, S=@0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050) at tree.cpp:458 #4 0x4009f406 in Tree::report (this=0x829c380, S=@0x82b2218, type=MT_LOG, code=L1_PARSING, arg1=@0x829c388, arg2=@0xbfffe050) at tree.cpp:458 #5 0x4009fb8d in Tree::parse (this=0x829c380, S=@0x82b2218, d=0x82dad60) at tree.cpp:563 #6 0x400939c8 in Processor::addLineParse (this=0x82b2280, S=@0x82b2218, newTree=@0x82b2284, absolute=@0xbfffe0e0, isXSL=1) at proc.cpp:549 #7 0x40093f7f in Processor::readTreeFromURI (this=0x82b2280, S=@0x82b2218, newTree=@0x82b2284, location=@0xbfffe180, base=@0xbfffe168, isXSL=1) at proc.cpp:594 #8 0x40091f71 in Processor::open (this=0x82b2280, S=@0x82b2218, sheetURI=0x82d2434 /rscr/www/base/rscr/style/rz-program.xsl, inputURI=0x82d267c arg:/input) at proc.cpp:270 #9 0x4009752f in SablotRunProcessor (processor_=0x82b2280, sheetURI=0x82d2434 /rscr/www/base/rscr/style/rz-program.xsl, inputURI=0x82d267c arg:/input, resultURI=0x82d26fc arg:/_result, params=0x0, arguments=0x82d285c) at sablot.cpp:399 #10 0x80a0cfe in php_if_xslt_transform (ht=6, return_value=0x82d281c, this_ptr=0x0, return_value_used=0) at sablot.c:458 #11 0x814c57a in execute (op_array=0x82461cc) at ./zend_execute.c:1573 #12 0x8128ee4 in zend_execute_scripts (type=8, file_count=3) at zend.c:750 #13 0x807b86f in php_execute_script (primary_file=0xb818) at main.c:1277 #14 0x813ae5c in apache_php_module_main (r=0x8288824, display_source_mode=0) at sapi_apache.c:90 #15 0x80783f2 in send_php () #16 0x807842a in send_parsed_php () #17 0x8162169 in ap_invoke_handler () #18 0x8176acf in process_request_internal () #19 0x8176b36 in ap_process_request () #20 0x816da56 in child_main () #21 0x816dc11 in make_child () #22 0x816dd8c in startup_children () #23 0x816e3fc in standalone_main () #24 0x816ec2c in main () #25 0x4027a2db in __libc_start_main () from /lib/libc.so.6 --- php-error.log --- Last leak repeated 23 times zend_hash.c(1027) : Freeing 0x0834A5E4 (7 bytes), script=/rscr/www/appserv/schema.html sablot.c(1397) : Freeing 0x08328244 (12 bytes), script=/rscr/www/appserv/schema.html Last leak repeated 23 times zend_hash.c(1027) : Freeing 0x082E1DDC (7 bytes), script=/rscr/www/appserv/schema.html --- apache Server version: Apache/1.3.20 (Unix) Server built: Jul 12 2001 13:23:37 ./src/httpd -l Compiled-in modules: http_core.c mod_log_config.c mod_mime.c mod_status.c mod_alias.c mod_rewrite.c mod_access.c mod_auth.c mod_php4.c mod_gzip.c --- php --- PHP4.0.7-dev (last CVS) ./configure --prefix=/rscr/appserv \ --with-apache=../apache_1.3.20 \ --with-config-file-path=/rscr/appserv/conf \ --with-regex=system \ --enable-debug \ --without-pcre-regex \
[PHP-DEV] phpinfo output
Anyone else here notice that the additional information blocks for modules compiled into PHP is pretty much sorted in reverse alphabetically order? Just wondering if we could switch it to forward alpha order, if possible. And why zlib seems to come up in the wrong location. - Colin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12149 Updated: PHP 4.0.6 upgrade seems to break cURL https
ID: 12149
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: cURL related
Operating System: WinNT4sp6a
PHP Version: 4.0.6
New Comment:
can you try this with the latest cvs on a windows system
and let me know if it still happens?
Thanks.
Previous Comments:
[2001-07-13 14:17:02] [EMAIL PROTECTED]
After reverting to 4.0.5, https works fine.
?
$curl= curl_init('https://www.thawte.com/');
curl_exec($curl);
curl_close($curl);
?
Edit this bug report at http://bugs.php.net/?id=12149edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12205 Updated: https not working
ID: 12205 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: RedHat 7 PHP Version: 4.0.6 New Comment: please try the latest cvs of PHP and cURL and re-open if the problem still exists. Previous Comments: [2001-07-17 09:45:10] [EMAIL PROTECTED] When using curl to https:// reciving an SSL error . after downgrading to php 4.0.5 it work fine !!! Edit this bug report at http://bugs.php.net/?id=12205edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12211 Updated: cURL (OpenSSL) https:// calls do not function
ID: 12211 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: Mandrake/Slackware PHP Version: 4.0.6 New Comment: Can you try the latest CVS of PHP and let re-open the bug if it still happens. Previous Comments: [2001-07-17 12:36:22] [EMAIL PROTECTED] In php4.0.5 cURL w/OpenSSL is fully functional without problems; although, in php4.0.6, When cURL w/OpenSSL is installed it all works but not with https:// calls. -- Errors -- When you use curl_error(): SSL: Couldn't create a context! When you use curl_errno(): 27 Which points explains it as an out of memory error Although through bash perl curl works fine with the SSL pages. This error has been reported on a variety of sites related to cURL but the question have never been responded to accurately. Edit this bug report at http://bugs.php.net/?id=12211edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12216 Updated: 4.0.6 + curl 7.8 Do not properly support https
ID: 12216 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: FreeBSD 4.3 PHP Version: 4.0.6 New Comment: It works fine for me with the latest CVS. can you upgrade and re-open if the bug still exists (also, when you use CURLOPT_RETURNTRANSFER, expect curl_exec() to return the data not output it.) Previous Comments: [2001-07-17 16:33:18] [EMAIL PROTECTED] Compiled php4.0.6 with curl 7.8 and open ssl. using this small script, the data properly returns: [(root)dave@sentinel goto]# cat test.php #!/usr/bin/php -q ? $ch = curl_init (); curl_setopt ($ch, CURLOPT_URL,http://www.thedatasource.net/;); curl_setopt ($ch, CURLOPT_HEADER, 1); curl_setopt ($ch, CURLOPT_VERBOSE, 1); curl_setopt ($ch, CURLOPT_USERAGENT, Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)); curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1); curl_exec ($ch); curl_close ($ch); ? [(root)dave@sentinel goto]# ./test.php * Connected to www.thedatasource.net (207.91.108.69) GET / HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Host: www.thedatasource.net Pragma: no-cache Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */* * Connection (#0) left alive * Closing live connection (#0) [(root)dave@sentinel goto]# I switch to https: [(root)dave@sentinel goto]# ./test.php * Closing live connection (#0) [(root)dave@sentinel goto]# I put phpinfo() in another small function to verify curl: [(root)dave@sentinel goto]# ./test2.php | grep curl H2 align=centerA NAME=module_curlcurl/A/H2 TR VALIGN=baseline BGCOLOR=#CCTD BGCOLOR=#FF BCURL Information/B/tdTD ALIGN=leftlibcurl 7.8 (SSL 0.9.5)/td/TR [(root)dave@sentinel goto]# Commandline, i test curls use of SSL: [(root)dave@sentinel goto]# curl https://www.thedatasource.net | more % Total% Received % Xferd Average Speed Time Curr. Dload Upload TotalCurrent LeftSpeed 100 102020 102020 0 30786 0 --:--:-- 0:00:00 --:--:-- 6484 html works fine. If i downgrade to: curl 7.7.3 (i386--freebsd4.3) libcurl 7.7.3 (OpenSSL 0.9.6) (ipv6 enabled) and php4.0.5 everything works as advertised. php 4.0.6 requires curl 7.8 to compile, i cant test with downgraded curl only. Edit this bug report at http://bugs.php.net/?id=12216edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12045 Updated: no content=cURL crashes sometimes
ID: 12045 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: cURL related Operating System: i686 PHP Version: 4.0.6 New Comment: I've tried reproduce this with the latest CVS of php to no avail, can you try the latest CVS and re-open the report if the problem persists? Previous Comments: [2001-07-11 07:34:36] [EMAIL PROTECTED] Hi, sometimes cURL crashes when Server gives correct headers but no content. unfortunately the problem is difficult to reproduce. a access with curl to a php script like: --- ?php ? --- produces sometimes the problem. Regards, -- Steve Edit this bug report at http://bugs.php.net/?id=12045edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #7631 Updated: Log file created but not written to.
ID: 7631
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Sablotron XSL
Operating System: Mandrake 7.0
PHP Version: 4.0 Latest CVS (03/11/2000)
New Comment:
Please upgrade to the new XSLT extension (--enable-xslt
--with-xslt-sablot) as development is no longer focused on
the sablot extension.
Previous Comments:
[2000-11-03 18:32:34] [EMAIL PROTECTED]
The following script causes the requested logfile to be
created, but it is never written to:
?php
error_reporting(E_ALL);
/* Intentionally introduce an extra space into file name. */
$xml_file = 'slashdot.xml';
$xsl_file = 'slashdot.xsl';
$xslt = xslt_create();
if (!xslt_openlog($xslt, '/tmp/sablot.log')) {
echo Failed to set up log file.\n;
}
if (!xslt_run($xslt, $xsl_file, $xml_file)) {
echo prexslt_run() failed\n;
echo Description: . xslt_error() . \n;
echo All information:\n;
print_r(xslt_error($xslt));
echo /pre\n;
} else {
echo xslt_fetch_result($xslt);
}
xslt_closelog($xslt);
xslt_free($xslt);
?
When I remove the logfile and do this from the command
line, it works:
~/public_html/phptest
shanna% tail /tmp/sablot.log
tail: /tmp/sablot.log: No such file or directory
~/public_html/phptest
shanna% sabcmd --log-file=/tmp/sablot.log slashdot.xsl slashdot.xml
Error [code:2] [URI:file:/home/torben/public_html/phptest/slashdot.xml] [line:5]
XML parser error 4: not well-formed
~/public_html/phptest
shanna% tail /tmp/sablot.log
Parsing 'file:/home/torben/public_html/phptest/slashdot.xsl'...
Parse done in 0.089 seconds
Parsing 'file:/home/torben/public_html/phptest/slashdot.xml'...
XML parser error 4: not well-formed
Destroying the hash table: 28 items in 2048 buckets
Destroying the arena: 6339 B asked, 65536 B allocated
Edit this bug report at http://bugs.php.net/?id=7631edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10569 Updated: xslt_error handling
ID: 10569
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Sablotron XSL
Operating System: BSD
PHP Version: 4.0.4pl1
New Comment:
1. Your attitude won't get you anywhere
2. The new extension doesn't throw fatal errors and
provides ample error handling (--enable-xslt
--with-xslt-sablot).
Previous Comments:
[2001-04-30 19:37:41] [EMAIL PROTECTED]
Hi,
again - the error handling issue.
I read the closed bugs and am surprised at the speed at which they are closed.
First of all - a documentation issue:
xslt_set_error_handler isn't documented. Thank you for mentioning it briefly, and then
letting me figure out the arguments the called function needs.
Secondly - dying with a Fatal error, DOES occur, when the error handler isn't set!
Even when using @xslt_process.
Try this one:
?php
$xslData = 'xsl:stylesheet
version=1.0
xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
xsl:template match=article
table border=1 cellpadding=2 cellspacing=1
tr
td width=20%
#160;
/td
td width=80%
h2xsl:value-of select=title//h2
h3xsl:value-of select=author//h3
br/
xsl:copy-of select=p/
/td
/tr
/table
/xsl:template
/xsl:stylesheet';
$xmlData = '?xml version=1.0?
article
titleLearning German/title
authorSterling Hughes/author
p
Essential phrases:
br
K#246;nnen Sie mir sagen, wo die Toilette ist?br/
Ein grosses Bier, bitte!br/
Noch eins, bitte.br/
/p
/article';
function xsl_error($errno, $errstr)
{
echo \$errorstr: $errstrBR;
return false;
}
//xslt_set_error_handler(xsl_error);
if (@xslt_process($xslData, $xmlData, $result)) {
echo Here is the brilliant in-depth article on learning;
echo German: ;
echo br\nbr;
echo $result;
} else {
echo There was an error that occurred in the XSL transformation...\n;
echo \tError number: . xslt_errno() . \n;
echo \tError string: . xslt_error() . \n;
//exit;
}
?
/BODY
/HTML
You won't see the closing body and html tags.
Uncommenting the xslt_set_error_handler() will. The errorstr output, however - is
numeric.
So can we at least have updated documentation on how to trap errors? And how
xslt_set_error_handler() must be used?
Edit this bug report at http://bugs.php.net/?id=10569edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11849 Updated: random duplicit rule name error
ID: 11849 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sablotron XSL Operating System: Linux PHP Version: 4.0.5 New Comment: please upgrade to the new xslt extension (--enable-xslt --with-xslt-sablot) as all development is now focused on that extension. Previous Comments: [2001-07-05 12:14:24] [EMAIL PROTECTED] This appears not to be random, after all. It way be an xsl error which triggers this bug. I'll upload a change to an xsl document, and it will either display the proper error, or this error. Once that has happened, however, I can't get any other (unchanged) xsl documents to parse, in any other pages on the server, Even if I change the xsl back to the way it was before. [2001-07-02 19:28:20] [EMAIL PROTECTED] Randomly, any pages that normally work fine (all pages on the site), die with: Fatal error: duplicit rule name 'nav_new' nav_new is the name of the first named template in the xsl document. Other pages report different ones, whichever is first in the document. If I go get a cup of coffee, they'll usually work again by the time I come back. I can't see any pattern as to what triggers the problem. Here's my config: './configure' '--prefix=/usr' '--with-apxs=/usr/sbin/apxs' '--with-gd' '--enable-safe-mode' '--with-config-file-path=/etc/httpd' '--with-exec-dir=/usr/bin' '--enable-magic-quotes' '--with-regex=system' '--with-ttf=/usr/lib/libttf.so' '--enable-track-vars' '--enable-xml' '--with-mysql=/usr' '--with-pgsql' '--with-trans-sid' '--with-dom=/usr' '--with-zlib=/usr' '--with-java=/usr/java/jdk1.3' '--with-sablot=/usr/local/lib' '--with-expat=/usr/local/lib' '--with-pdflib=/usr/local/lib' '--with-cpdflib=/usr/local/include' '--with-fdf=/usr/lib' I'm using Sablotron 0.60 Edit this bug report at http://bugs.php.net/?id=11849edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #8412 Updated: transformations hang
ID: 8412 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sablotron XSL Operating System: Linux 2.2.17, 2.4.5 PHP Version: 4.0.4, 4.0.5 Assigned To: sterling New Comment: please upgrade to the new XSLT extension (--enable-xslt --with-xslt-sablot) as all new development is focused there. Previous Comments: [2001-05-29 05:37:47] [EMAIL PROTECTED] There is still a problem, but I've narrowed it down a bit. I'm using the newest Sablotron as you suggested. The problem still occurs when MySQL and XSL transformations are in the same script, but my httpd process only hangs when I do mysql stuff like this: $xsl_resource = xslt_create(); // insert mysql stuff here xslt_output_begintransform($xslfile); xslt_process($xsl, $xml, $outcome); xslt_free($xsl_resource); If I do all the MySQL stuff before I call xslt_create(), it doesn't seem to hang. [2001-04-24 17:50:24] [EMAIL PROTECTED] Ok, try it and re-open the report if it happens. I've used MySQL and Sablotron together fine... [2001-04-09 19:42:27] [EMAIL PROTECTED] I don't have that machine available anymore to help test if it works or not... at least not in a reasonable amount of time before 4.0.5 gets out. [2001-04-05 14:29:32] [EMAIL PROTECTED] try this with the newest sablotron and php and let me know what happens... [2000-12-25 03:56:59] [EMAIL PROTECTED] My install hangs when hitting reload a lot and my httpd processes suck up my resources until the script times out. It takes between 5-15 quick reloads before it hangs. This seems to only happen when I grab stuff from MySQL in the same script as when I'm doing a transformation. ' ./configure' '--with-mysql' '--enable-track-vars' '--with-mcrypt' '--enable-ftp' '--enable-sockets' '--with-sablot' '--enable-sablot-errors-descriptive' '--with-apache=../apache_1.3.14' '--with-zlib' I'm using Sablotron 0.44.1 and Expat 1.1.2. A script with just MySQL works fine, and a script with just a transformation works fine. I don't see anything additionally descriptive about --enable-sablot-errors-descriptive either Edit this bug report at http://bugs.php.net/?id=8412edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11777 Updated: php apache dso coredumps using die() inside function for xslt_set_error_handler
ID: 11777
Updated by: sterling
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Sablotron XSL
Operating System: NetBSD/Alpha 1.5W-current
PHP Version: 4.0 Latest CVS (2001-06-28)
New Comment:
please try the new XSLT extension (use the CVS version,
--enable-xslt --with-xslt-sablot) and let me know if this
still happens.
Previous Comments:
[2001-06-28 09:36:26] [EMAIL PROTECTED]
function xsl_error($parser, $code, $level, $errors)
{
...
die(this will cause a coredump or fatal trap);
}
xslt_set_error_handler($parser, xsl_error);
by calling die() inside a function for xslt_set_error_handler will cause my
NetBSD/Alpha system to either coredump or go to a fatal user trap. it coredumps if i
didn't compile with '--enable-debug'. with debug compiled in, it usually reports a
fatal user trap. this only happens with the PHP Apache DSO. as a cgi, it exits just
fine.
i've verified and repeated this on PHP 4.0.5 and the latest cvs.
---cut---
Jun 28 08:17:06 ns01 /netbsd: CPU 0: fatal user trap:
Jun 28 08:17:08 ns01 /netbsd:
Jun 28 08:17:08 ns01 /netbsd: CPU 0trap entry = 0x4 (unaligned access fault)
Jun 28 08:17:08 ns01 /netbsd: CPU 0a0 = 0x2b5d3f5c5e5b5e27
Jun 28 08:17:08 ns01 /netbsd: CPU 0a1 = 0x28
Jun 28 08:17:08 ns01 /netbsd: CPU 0a2 = 0x1
Jun 28 08:17:08 ns01 /netbsd: CPU 0pc = 0x1606b9c24
Jun 28 08:17:08 ns01 /netbsd: CPU 0ra = 0x160731664
Jun 28 08:17:09 ns01 /netbsd: CPU 0curproc= 0xfc00356af400
Jun 28 08:17:09 ns01 /netbsd: CPU 0pid = 6108, comm = httpd
Jun 28 08:17:09 ns01 /netbsd:
Jun 28 08:17:09 ns01 /netbsd: pid 6108 (httpd), uid 71: exited on signal 11 (core not
dumped, err
= 1)
---cut---
Edit this bug report at http://bugs.php.net/?id=11777edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12473: mail() sended mail is timestamped 15 hours late
From: [EMAIL PROTECTED] Operating system: win2k PHP version: 4.0.6 PHP Bug Type: Mail related Bug description: mail() sended mail is timestamped 15 hours late mail() sended email is time stamped 15 hours back. Like say send a email to my yahoo address, the new mail is listed asof received yesterday. I use php.exe to run a php script from DOS command prompt. But when I use MS Outlook,using the same smtp server, it is OK. Thanks, -- Edit bug report at: http://bugs.php.net/?id=12473edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11440 Updated: PHP Seg faults with xslt_output_begintransform(xsl_file);
ID: 11440 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sablotron XSL Operating System: Linux Mandrake 8.0 PHP Version: 4.0 Latest CVS (2001-06-12) New Comment: This is fixed by omission in the new XSLT extension (we no longer have the xslt_output_*() functions). Please upgrade to that extension as that is where all new development is focused. Thanks. Previous Comments: [2001-06-12 13:08:37] [EMAIL PROTECTED] --- System: --- Linux Mandrake 8.0 Apache 1.3.19 PHP 4.0.6 RC3 (as DSO) Sablot 0.52 libxml2.3.10 expat 1.95.1 Compile options ./configure \ --mandir=/usr/share/man \ --with-apxs=/usr/local/apache/bin/apxs \ --with-config-file-path=/etc/httpd \ --enable-magic-quotes \ --enable-bcmath \ --enable-calendar \ --with-dom=/usr/local \ --with-zlib-dir \ --enable-ftp \ --enable-gd-native-ttf \ --with-mysql=/usr/local/mysql \ --with-pgsql=/usr/local/pgsql \ --with-expat-dir=/usr/local \ --with-sablot=/usr/local \ --enable-trans-sid \ --with-regex=system \ --with-swf=/usr/local/openswf \ --enable-wddx \ --enable-memory-limit \ --with-gnu-ld \ --with-gd=/usr/local \ --with-jpeg-dir=/usr/local \ --with-png=/usr/local \ --with-freetype=/usr/local/include/freetype2 -- Back Trace -- (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x403c3ee2 in Processor::useArg (this=0x8121f68, name=0xcc4a090 Address 0xcc4a090 out of bounds, val=0x40322b84 ¨A\024) at proc.cpp:1077 1077if (*name != '/') Current language: auto; currently c++ (gdb) bt #0 0x403c3ee2 in Processor::useArg (this=0x8121f68, name=0xcc4a090 Address 0xcc4a090 out of bounds, val=0x40322b84 ¨A\024) at proc.cpp:1077 #1 0x403c4954 in SablotRunProcessor (processor_=0x8121f68, sheetURI=0x80d9b1c index.xsl, inputURI=0x402ee293 arg:/_xmlinput, resultURI=0x402ee286 arg:/_output, params=0x0, arguments=0xbfffdbd0) at sablot.cpp:144 #2 0x4026de47 in php_if_xslt_output_endtransform (ht=0, return_value=0x8120afc, this_ptr=0x0, return_value_used=0) at sablot.c:322 #3 0x4021a10c in execute (op_array=0x811e51c) at ./zend_execute.c:1504 #4 0x40228a4d in zend_execute_scripts (type=8, file_count=3) at zend.c:749 #5 0x4023af64 in php_execute_script (primary_file=0xb560) at main.c:1206 #6 0x4023757e in apache_php_module_main (r=0x8119684, display_source_mode=0) at sapi_apache.c:89 #7 0x40237fbc in send_php (r=0x8119684, display_source_mode=0, filename=0x0) at mod_php4.c:536 #8 0x40237ff3 in send_parsed_php (r=0x8119684) at mod_php4.c:547 #9 0x0805b797 in ap_invoke_handler () #10 0x0807029b in process_request_internal () #11 0x08070310 in ap_process_request () #12 0x080673b2 in child_main () #13 0x08067564 in make_child () #14 0x080676d8 in startup_children () #15 0x08067d57 in standalone_main () #16 0x0806858f in main () #17 0x400970de in __libc_start_main () from /lib/libc.so.6 -- All files PHP has contact with -- index.php ?php $xmlData2 = '?xml version=1.0? page html_header html_titleThis is a test of the multi-template/html_title html_body bgcolor=bgcolor=\'#66\' / /html_header article titleHow #60;uNOT#60;/u to a B millionare/title authorMicah Almond/author firstMicah/first secondAlmond/second bodyThis is the body of the document/body form#60;input type=text value=Test of form //form form2Test of Form 2/form2 auction_state state_abbrev=VAVirginia/auction_state /article /page'; $xsl_file = index.xsl; xslt_output_begintransform($xsl_file); print($xmlData2); xslt_output_endtransform(); ? index.xsl ?xml version='1.0'? xsl:stylesheet version='1.0' xmlns:xsl='http://www.w3.org/1999/XSL/Transform' xsl:output method='html' / xsl:include href='form.xsl' / xsl:template name='prod_cells' xsl:param name='count' / xsl:if test='$count != 0' tdTable Cell/td xsl:call-template name='prod_cells' xsl:with-param name='count' select='$count - 1' / /xsl:call-template /xsl:if /xsl:template xsl:template match='page' html body form method='post' xsl:apply-templates / /form /body /html /xsl:template xsl:template match='article' table border='1' cellpadding='2' cellspacing='1' tr td width='40%' h2xsl:value-of select='title'//h2 /td td width='60%' h3xsl:value-of select='author'//h3 br/ xsl:value-of select='body'/
[PHP-DEV] Bug #9398 Updated: Apache SIGTERM when loading php with pspell AND sablotron
ID: 9398 Updated by: sterling Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Sablotron XSL Operating System: Linux Redhat 6.2 PHP Version: 4.0.4pl1 New Comment: This is a Sablotron patch and problem, please send this to [EMAIL PROTECTED] thanks! Previous Comments: [2001-02-23 04:42:23] [EMAIL PROTECTED] The problem appears to be between pspell and sablotron modules which are using both C++ shared libs. If we change the load, first sablot and after pspell, that's works. I attached two logs for httpd -DSSL -DHAVE_PHP4 -X, one works, one failed: Here is what ldd -v return for pspell.so and original sablot.so --- PSPELL Version information: /usr/lib/libpspell.so: libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /usr/lib/libltdl.so.0: libdl.so.2 (GLIBC_2.1) = /lib/libdl.so.2 libdl.so.2 (GLIBC_2.0) = /lib/libdl.so.2 libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /usr/lib/libpspell-modules.so.1: libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /usr/lib/libstdc++-libc6.2-2.so.3: libm.so.6 (GLIBC_2.0) = /lib/libm.so.6 libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /lib/libc.so.6: ld-linux.so.2 (GLIBC_2.1.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) = /lib/ld-linux.so.2 /lib/libdl.so.2: libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/libc.so.6 libc.so.6 (GLIBC_2.2) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /lib/libm.so.6: libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 libstdc++-libc6.2-2.so.3 = /usr/lib/libstdc++-libc6.2-2.so.3 (0x4007c000) libc.so.6 = /lib/libc.so.6 (0x400bf000) libm.so.6 = /lib/libm.so.6 (0x401e8000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) --- SABLOT Version information: /usr/lib/libsablot.so: libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /usr/lib/libstdc++-libc6.2-2.so.3: libm.so.6 (GLIBC_2.0) = /lib/libm.so.6 libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.1) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 /lib/libc.so.6: ld-linux.so.2 (GLIBC_2.1.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.1) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.2) = /lib/ld-linux.so.2 ld-linux.so.2 (GLIBC_2.0) = /lib/ld-linux.so.2 /lib/libm.so.6: libc.so.6 (GLIBC_2.1.3) = /lib/libc.so.6 libc.so.6 (GLIBC_2.0) = /lib/libc.so.6 I'm not a specialist in C++ or lib loader problem but a quick fix was to rebuild sablot.so with -lexpat (just missing) and -lstdc++ With that patch you could load pspell and sablot in any orders. --- --- Sablot/engine/Makefile.in.orig Thu Feb 22 23:09:37 2001 +++ Sablot/engine/Makefile.in Thu Feb 22 23:10:30 2001 @@ -96,7 +96,7 @@ DEFS = @DEFS@ -I. -I$(srcdir) -I../../autocfg LDFLAGS = @LDFLAGS@ -LIBS = @LIBS@ +LIBS = @LIBS@ $(EXPAT_LIBS) -lstdc++ libsablot_la_LIBADD = libsablot_la_OBJECTS = arena.lo base.lo context.lo datastr.lo error.lo \ expr.lo hash.lo output.lo parser.lo platform.lo proc.lo sablot.lo \ --- [2001-02-22 05:08:34] [EMAIL PROTECTED] I've got Apache (1.3.17 + mod_ssl 2.8.0) SIGTERM when using a php 4.04pl1 and mod_php 4.04pl1 with sablotron and pspell. There are both present as extension loaded via php.ini. If I remove sablotron (or pspell), apache with mod_php4 start and works correctly. The problem DIDN'T appears when using php in standalone It seems that Apache got a problem when loading more than one external modules using libstdc++. I've got a similar error when trying to run apache with the mod_xslt from Xalan-C Project --- ;; EXTENSION LOADING extension_dir = /usr/lib/php4 ;; Global PHP defaults warn_plus_overloading = On ; warn if the + operator is
[PHP-DEV] CVS Account Request
Full name: MaBeL Email: [EMAIL PROTECTED] ID:mabel Purpose: I Want to translate PHP documentation -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #11892 Updated: crypt gone without a trace
ID: 11892
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Encryption and hash functions
Operating System: BSD
PHP Version: 4.0.6
New Comment:
Crypt failes because libcrypt is searched for. This isn't necessary on BSD systems,
because it's part of libc. So, this simple conftest.c below, will already work:
int main()
{
char *pw, salt[3];
extern char *crypt(const char *, const char *);
crypt(pw, salt);
return 1;
}
please incorporate this in the configure script and set HAVE_CRYPT in
main/php_config.h accordingly.
People using php on these systems, simply edit main/php_config.h and change /* #undef
HAVE_CRYPT */ to #define HAVE_CRYPT 1 in the appropriate place.
Previous Comments:
[2001-07-04 19:26:14] [EMAIL PROTECTED]
Any call to crypt() creates an empty string. Downgrade to 4.0.5 fixes the problem.
I also tried putting the '4.0.5' crypt.c in the '4.0.6' build and recompiled after a
make clean, but that didn't make a difference.
Edit this bug report at http://bugs.php.net/?id=11892edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12474: possible incorrect strtotime handling of -1Month
From: [EMAIL PROTECTED] Operating system: Linux (should happen on any) PHP version: 4.0.4pl1 PHP Bug Type: Date/time related Bug description: possible incorrect strtotime handling of -1Month when running ?PHP print date(d/m/Y, strtotime(31 July 2001)).\n; print date(d/m/Y, strtotime(-1 month, strtotime(31 July 2001))).\n; ? it replies with X-Powered-By: PHP/4.0.3pl1 Content-type: text/html 31/07/2001 01/07/2001 of course what it's doing is turning it into 31 june which is then being considered to be the 1 of july.. Should this be right or should strtotime realise that there are 30 days in june and truncate the 31st day? -- Edit bug report at: http://bugs.php.net/?id=12474edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12475: the variable $PHP_SELF is not set.
From: [EMAIL PROTECTED] Operating system: Windows 2000 Server PHP version: 4.0.6 PHP Bug Type: Variables related Bug description: the variable $PHP_SELF is not set. if I open a script containing only the phpinfo() function, the $PHP_SELF field is not filled in. In my own scripts it's not setted at all. I'm using the zipped version of php4.06 with cgi wrapper using xitami 2.4d6 running as a windows service. -- Edit bug report at: http://bugs.php.net/?id=12475edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: TSRM compatibility note
The new API no longer requires separate fetch's for the different TLS's. This has two implications: - Code that requires several TLS's is quicker, since at most, you only call one fetch, instead of several (you also pass less info on the stack when you send TLS's to functions) - Since there's only one pointer to move around now, it makes more sense to pass it around between the different functions. There's no notion of inconsistency. The more places you can pass the TSRMLS, the better, as it's faster. I did lots of work on it, there's still lots of work that remains to be done. Zeev At 11:56 30/07/2001, Harald Radi wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi zeev, is there a short explanation of this tsrm stuff somewhere ? i'd like to know which kind of functions should take use of the tsrm features. while reviewing your changes to the ext/com module i'm stumbled into a few inconsistencies (as far as i can follow). where on one hand you exaggerated in adding TSRM_* macros you left out very important functions on the other hand. maybe i'm wrong and i misunderstood the function of these macros, so a short HOWTO would be essentially. - -harald. Zeev Suraski [EMAIL PROTECTED] schrieb im Newsbeitrag news:5.1.0.14.2.20010730101740.050bb618@localhost... Just FYI - code working with the old-style TSRM should still go on working. It just wouldn't take advantage of the faster single fetch approach we switched to. We should probably change ext_skel to generate new-style fetches and macros, so that new extensions take advantage of the faster approach. Zeev -BEGIN PGP SIGNATURE- Version: PGP 7.0.4 iQA/AwUBO2Wt5a1+myS9SSHxEQK2rACfYQ9FrNoszFW4pHL1y/iE3bRb1HUAn1Jy W4GO6+3JUAeUgYNFsb7LB8y+ =PdxQ -END PGP SIGNATURE- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12476: a function that splits a string into equal parts while retaining whole words
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.4pl1 PHP Bug Type: Feature/Change Request Bug description: a function that splits a string into equal parts while retaining whole words //perhaps a function like this ?php $str = blah blah blah blah blah blah; $columns = str_seperate($str,2); echo $columns[0].'brbr'.$columns[1]; ? //outputting blah blah blah blah blah blah -- Edit bug report at: http://bugs.php.net/?id=12476edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #12477: preg_replace evaluates dollar signs as variables (eg $1,000 becomes ,000)
From: [EMAIL PROTECTED]
Operating system: Linux and SCO
PHP version: 4.0.6
PHP Bug Type: PCRE related
Bug description: preg_replace evaluates dollar signs as variables (eg $1,000 becomes
,000)
The setup for my templating system:
$template=array(
/({PAGETOP})/,
/({PAGENAVBAR})/,
/({PAGEMAIN})/,
/({PAGELINKS})/,
/({PAGESPACE})/,
/({PAGETEXT})/,
/({PAGENEWS})/,
/({PAGEBOTTOM})/,
/({PAGEDATA})/
);
$pagevars=array(
PAGETOP = get_page($site-page_top),
PAGENAVBAR = get_page($site-page_top),
PAGEMAIN = get_page($site-page_main),
PAGELINKS = get_page($site-page_links),,
PAGESPACE = get_page($site-page_space),
PAGETEXT = get_page($site-page_text),
PAGENEWS = get_page($site-page_news),,
PAGEBOTTOM = get_page($site-page_bottom),
PAGEDATA =
);
$page = {PAGETOP}{PAGENAVBAR}{PAGEMAIN}{PAGEBOTTOM};
$page = preg_replace($template,$pagevars,$page);
echo $page;
Basically each physical page referenced via the get_page function is a text
template that may contain HTML, text or variables in the form {VAR}.
Eventually content from a database ends up in a variable called PAGEDATA
which is in the template stored in the page main variable.
The problem:
PAGEDATA ends up containing page text and it has something like would cost
around $16,000 to complete in that text.
When the preg_replace is performed, something somewhere is assuming that
$16 is a variable (which doesn't exist) and the text ends up as would cost
around ,000 to complete
--
Edit bug report at: http://bugs.php.net/?id=12477edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] print_r
Hi,
Is there a posibility to print an object but to not print some fields.
If I use print_r he will print all variabiles from my object, but I want on
variabile to not be printed. I do not want to write my own function.
Ex.
class Node {
var $name;
var $parent = '/'
var $children = array();
function Node($name, $parent) {
$this-parent = $parent;
$this-name = $name;
}
}
$rootNode = new Node('root', '');
array_push($rootNode-children, new Node('child1', $rootNode));
$child1Node = $rootNode-children[0];
array_push($child1Node-children, new Node('child1', $child1Node));
print_r($rootNode);
will print make a recursivity. What will be nice is to allow that some
variabiles to not
be printed like this:
class Node {
var $name;
var $__parent = '/'
var $children = array();
function Node($name, $parent) {
$this-__parent = $parent;
$this-name = $name;
}
}
. /* add the root and childrens */
print_r($rootNode);
will print now the corret tree.
Bellow you find the only modification that need to be done for this to work.
Best regards,
Emanuel Dejanu
File: Zend/zend.c
static void print_hash(HashTable *ht, int indent)
{
zval **tmp;
char *string_key;
HashPosition iterator;
unsigned long num_key, str_len;
int i, key_type; /** HERE */
for (i=0; iindent; i++) {
ZEND_PUTS( );
}
ZEND_PUTS((\n);
indent += PRINT_ZVAL_INDENT;
zend_hash_internal_pointer_reset_ex(ht, iterator);
while (zend_hash_get_current_data_ex(ht, (void **) tmp, iterator) ==
SUCCESS) {
/ HERE **/
key_type = zend_hash_get_current_key_ex(ht, string_key, str_len,
num_key, 0, iterator);
if (key_type == HASH_KEY_IS_STRING)
if (string_key[0] == '_' string_key[1] == '_') continue;
/*** HERE **/
for (i=0; iindent; i++) {
ZEND_PUTS( );
}
ZEND_PUTS([);
switch (key_type) {
case HASH_KEY_IS_STRING:
ZEND_PUTS(string_key);
break;
case HASH_KEY_IS_LONG:
zend_printf(%ld,num_key);
break;
}
ZEND_PUTS(] = );
zend_print_zval_r(*tmp, indent+PRINT_ZVAL_INDENT);
ZEND_PUTS(\n);
zend_hash_move_forward_ex(ht, iterator);
}
indent -= PRINT_ZVAL_INDENT;
for (i=0; iindent; i++) {
ZEND_PUTS( );
}
ZEND_PUTS()\n);
}
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
