[PHP-DEV] PHP 4.0 Bug #6990 Updated: loading dynamic extensions in system config causes loss of ini settings
ID: 6990 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: PHP options/info functions Assigned To: Comments: By the way - this was not a bug, but a missing feature. This behavior was the intended (and AFAIK documented) behavior - INI entries referring to dynamic modules had to be written before the line that loaded the module. Previous Comments: --- [2001-01-15 09:43:26] [EMAIL PROTECTED] Fixed in CVS. Thanks for your very detailed report! --- [2000-10-04 04:46:21] [EMAIL PROTECTED] Digging deeper, I find that if REGISTER_INI_ENTRIES() and UNREGISTER_INI_ENTRIES() are called from the RINIT and RSHUTDOWN functions respectively, there's no problem with the handling of ini entries. But all of the extensions that ship with PHP which use these functions call them from the MINIT and MSHUTDOWN functions instead! Is this a bug with the handling of the ini file, or is it a bug that's common to all of the existing PHP extensions? :) --- [2000-10-03 06:53:15] [EMAIL PROTECTED] There is a bug in the ini setting handling that surfaces when dynamic extensions are loaded in the system php.ini file. It can be reproduced with php/apxs and any extension which is built as a shared module. After the first request handled by a given process, PHP resets all ini values to the compiled-in defaults, and subsequently fails to reload the module-specific ini values from php.ini when further requests arrive. This bug ONLY affects module-specific ini values configured at the system level, and only when used with extensions that are loaded via php.ini. It does NOT affect ini settings configured at the per-directory or user level (PHP_INI_PERDIR, PHP_INI_USER), nor does it appear when the extension is built-in or loaded by the user with the dl() function. Here is a basic PHP configuration that can be used to reproduce the problem. This is not a real-world example, but it's sufficient for debugging :) ./configure --with-apxs=/usr/sbin/apxs --with-config-file-path=/etc/httpd --enable-session=shared Install libphp4.so and the session.so module in the appropriate directories, and add these lines to /etc/httpd/php.ini: extension=session.so session.save_path = /tmp/blee Run Apache in single-process mode (httpd -X), and create a php script that calls phpinfo(). The first time phpinfo is loaded, session.save_path will have a local value of /tmp/blee and a master value of /tmp. After that, it will always show the local and master value as /tmp. --- Full Bug description available at: http://bugs.php.net/?id=6990 -- 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] PHP 4.0 Bug #1531 Updated: require() causes flex scanner error
ID: 1531 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem Assigned To: Comments: intended behavior Previous Comments: --- [2001-02-10 13:25:00] [EMAIL PROTECTED] 4.0 still gives the same message. --- [2000-08-17 11:48:09] [EMAIL PROTECTED] BD>> still it should not result in a parse error > It's not parse error, please read the message. > It didn't failed opening, it failed reading. > And require is not allowed to fail. > That's not unknown file, that's known non-file. >-- >Stanislav Malyshev [EMAIL PROTECTED] ok, got it now, i thought it was related to just ./, not directories in general but it fails for include to, while including for example a non-existing file produces the message i cited above and the error message is very misleading so i move this on to feature requests: 1) should give clearer error-message 2) at least include should treat directories like nonexistant (or empty?) files and issue a warning instead of a fatal error --- [2000-08-17 11:21:40] [EMAIL PROTECTED] still it should not result in a parse error it should produce a warning PHP Warning: Failed opening './' for inclusion as with other unknown files --- [2000-08-17 11:07:48] [EMAIL PROTECTED] I don't see problem here. ./ is not a file, and reading it as a file fails. So it should be. --- [2000-08-17 10:57:52] [EMAIL PROTECTED] still there even in 4.0.1 --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=1531&edit=2 -- 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] PHP 4.0 Bug #9186 Updated: string compare with "==" does not work correctly
ID: 9186 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Documentation problem Assigned To: Comments: This is a defined behavior (and does have strong reasons). It's not a bug. If you're interested in a byte-by-byte string comparison, you should use strcmp(). Previous Comments: --- [2001-02-09 11:10:17] [EMAIL PROTECTED] Incorrectly flagged as bogus. --- [2001-02-09 10:59:10] [EMAIL PROTECTED] I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. I can not see any description of this behavior in the manual. The string type section descibes only what is happen if a string is converted. --- [2001-02-09 10:27:46] [EMAIL PROTECTED] Actually, this is a feature - it is described in the manual. Strings that look like numbers are converted to numbers. Large numbers - like the ones below may not convert perfectly from a string to a number. Review the manual section on PHP types in general and strings in particular (http://uk.php.net/manual/en/language.types.string.php) While this is a relatively subtle bug, you can ensure that you are dealing with strings by quoting the variables being compared or by using the === operator. This behavior is exploited quite often in PHP scripts. However, perhaps it would be nice if PHP generated an notice level error when it occured so that users have some recourse when it happens unexpectedly. If you feel strongly about this, propose it to the developers as a feature request. Post your request on the [EMAIL PROTECTED] list (sub at [EMAIL PROTECTED]) - if you get no response, be polite but persistant. :) --- [2001-02-09 03:25:24] [EMAIL PROTECTED] First the test script: and its output: a equal b a not equal b as string: a=012345678901234567 b=012345678901234568 as float: a=12345678901234567 b=12345678901234567 as int: a=2147483647 b=2147483647 Zend trys to convert the arguments to numbers if both arguments are strings. This is not good and its not a feature. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9186&edit=2 -- 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] PHP 4.0 Bug #9186 Updated: string compare with "==" does not work correctly
ID: 9186 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Closed Status: Analyzed Bug Type: Documentation problem Assigned To: Comments: Ok, it should remain open as a documentation problem... Previous Comments: --- [2001-02-15 04:31:01] [EMAIL PROTECTED] This is a defined behavior (and does have strong reasons). It's not a bug. If you're interested in a byte-by-byte string comparison, you should use strcmp(). --- [2001-02-09 11:10:17] [EMAIL PROTECTED] Incorrectly flagged as bogus. --- [2001-02-09 10:59:10] [EMAIL PROTECTED] I think there is no reason to convert any type if both operands of the comparision are of the same type. It costs time and it's completely not necessary. This is a bug. I can not see any description of this behavior in the manual. The string type section descibes only what is happen if a string is converted. --- [2001-02-09 10:27:46] [EMAIL PROTECTED] Actually, this is a feature - it is described in the manual. Strings that look like numbers are converted to numbers. Large numbers - like the ones below may not convert perfectly from a string to a number. Review the manual section on PHP types in general and strings in particular (http://uk.php.net/manual/en/language.types.string.php) While this is a relatively subtle bug, you can ensure that you are dealing with strings by quoting the variables being compared or by using the === operator. This behavior is exploited quite often in PHP scripts. However, perhaps it would be nice if PHP generated an notice level error when it occured so that users have some recourse when it happens unexpectedly. If you feel strongly about this, propose it to the developers as a feature request. Post your request on the [EMAIL PROTECTED] list (sub at [EMAIL PROTECTED]) - if you get no response, be polite but persistant. :) --- [2001-02-09 03:25:24] [EMAIL PROTECTED] First the test script: and its output: a equal b a not equal b as string: a=012345678901234567 b=012345678901234568 as float: a=12345678901234567 b=12345678901234567 as int: a=2147483647 b=2147483647 Zend trys to convert the arguments to numbers if both arguments are strings. This is not good and its not a feature. --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9186&edit=2 -- 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] PHP 4.0 Bug #8899 Updated: crash when include_once("") contains empty string
ID: 8899
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
Assigned To:
Comments:
Fixed, thanks!
Previous Comments:
---
[2001-01-25 05:41:52] [EMAIL PROTECTED]
The bug seems simple to reproduce:
if I write:
include_once("");
near the top of a file, i get the following errors:
[Thu Jan 25 11:34:39 2001] [notice] Apache/1.3.14 (Unix) PHP/4.0.4pl1 configured --
resuming normal operations
[Thu Jan 25 11:35:00 2001] [notice] caught SIGTERM, shutting down
[Thu Jan 25 11:35:05 2001] [notice] Apache/1.3.14 (Unix) PHP/4.0.4pl1 configured --
resuming normal operations
[Thu Jan 25 11:35:25 2001] [notice] child pid 50507 exit signal Bus error (10)
[Thu Jan 25 11:35:25 2001] [notice] child pid 50506 exit signal Bus error (10)
[Thu Jan 25 11:40:19 2001] [notice] caught SIGTERM, shutting down
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8899&edit=2
--
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] PHP 4.0 Bug #8565 Updated: parent:: doesn't work with nested include/require
ID: 8565
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: Scripting Engine problem
Assigned To:
Comments:
Fixed in the latest CVS - thanks!
Previous Comments:
---
[2001-01-08 14:10:56] [EMAIL PROTECTED]
The reason for this is simple - parent:: is the compile-time
definition and require/include is run-time, so when it meets
parent:: it does not know yet who it's parent is. I am not
sure it's resolvable now, but I'm leaving it for Zeev/Andi's
attention.
---
[2001-01-08 10:00:11] [EMAIL PROTECTED]
it will work if you include/require/require_once both
.inc files from the file but not for nested includes
(extended class including base class to be extended)
:(
---
[2001-01-05 14:37:23] [EMAIL PROTECTED]
The following code gives the error:
file: base.inc
doit()n";
}
}
?>
file: a.inc
doit()n";
}
}
?>
file: extend-test.php
doit();
?>
x:>php -f extend-test.php
Fatal error: No parent class available in this context in a.inc on line 6
---
[2001-01-05 12:42:19] [EMAIL PROTECTED]
sorry, but i can't believe this as i
use this feature almost daily
can you pleas provide an example of
code _not_ working ?
---
[2001-01-05 12:22:36] [EMAIL PROTECTED]
the parent:: operator will work if both the parent and sub class are in the same
physical file, but not if they are in a separate file.
This works:
doit()n";
}
}
class A extends Base {
function doit() {
parent::doit();
echo "Class A->doit()n";
}
}
?>
but if the two classes are in separate files, the following error is reported:
Fatal error: No parent class available in this context in a.inc on line 6
Of course, this may be an undocumented feature, but I can see no reason for it.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8565&edit=2
--
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] PHP 4.0 Bug #9005 Updated: Static classes sometimes have a $this pointer
ID: 9005
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Assigned To:
Comments:
class::method() isn't a static call in PHP (it isn't always a static call in C++
either).
The primary use for class::method() is actually calling methods from your parent
class, not calling 'static methods' (the ability to create static classes and call
their methods is pretty much a positive 'side effect').
So, this is the intended behavior.
Previous Comments:
---
[2001-01-30 13:39:15] [EMAIL PROTECTED]
If you call a static method from within an object, the static method will inherit the
$this pointer of the calling object. This script demonstrates the problem:
data;
}
}
class Instantiated {
var $data;
function Instantiated($data) {
$this->data = $data;
StaticClass::doSomething();
}
}
$ob = new Instantiated('foo');
?>
This is rather confusing behavior - $this should be out of scope inside static methods
no matter what.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9005&edit=2
--
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] PHP 4.0 Bug #10002 Updated: sprintf() and floating point
ID: 10002
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Strings related
Assigned To:
Comments:
I can't reproduce it under RH 6.2. Generally the fix isn't supposed to do anything
(since arg is a double, 10 should be converted to a double automatically), but the fix
can't hurt anything so if it works around a compiler bug, it's fine.
PHP cannot use sprintf() because sprintf() works with C types with predefined types
for the arguments, whether PHP has its own types, and autoconverts arguments to match
the format string.
Previous Comments:
---
[2001-03-26 17:19:30] [EMAIL PROTECTED]
This bug is in 4.0.5RC2 too, just confirmed it
---
[2001-03-26 14:13:27] [EMAIL PROTECTED]
produces '0.0:' instead of '0.10'
I'm really curious as to why PHP just doesn't use libc's sprintf().
./configure --with-oracle=/usr/local/oracle/product/8.1.7
--with-oci8=/usr/local/oracle/product/8.1.7 --enable-force-cgi-redirect
--enable-track-vars --with-posix --enable-sockets --enable-sigchild
--with-gd=/usr/local
gcc version 2.95.2 19991024 (release)
This is not exactly a fix...
--- ext/standard/formatted_print.c Mon Mar 26 14:01:31 2001
+++ ext/standard/formatted_print.c-fixedMon Mar 26 14:02:26 2001
@@ -92,7 +92,7 @@
while (p1 < &cvt_buf[NDIG])
*p++ = *p1++;
} else if (arg > 0) {
- while ((fj = arg * 10) < 1) {
+ while ((fj = arg * 10.0) < 0.999) {
arg = fj;
r2--;
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10002&edit=2
--
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 #5661 Updated: undeclared function
ID: 5661 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Assigned Status: Closed Bug Type: Compile Failure PHP Version: 4.0.1pl2 Assigned To: zeev Comments: Previous Comments: --- [2000-11-23 18:14:13] [EMAIL PROTECTED] Is this still a problem when using PHP 4.0.3pl1 ? It shouldn't be..you're using linux which should have limits.h. Or your system is somehow messed up. --Jani --- [2000-07-28 23:01:33] [EMAIL PROTECTED] in php.h we have: #ifndef LONG_MAX #define LONG_MAX 2147483647L #endif #ifndef LONG_MIN #define LONG_MIN (- LONG_MAX - 1) #endif just in cas limits.h is not there or does not define LONG_MAX maybe this should be done in zend.h to ? --- [2000-07-18 10:56:45] [EMAIL PROTECTED] linux:/mnt/files/programs/php4/php-4.0.1pl2# make Making all in Zend make[1]: Entering directory `/mnt/files/programs/php4/php-4.0.1pl2/Zend' /bin/sh ../libtool --silent --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.. -DXML_BYTE_ORDER=12 -g -O2 -c zend_hash.c zend_hash.c: In function `zend_hash_add_or_update': zend_hash.c:237: `LONG_MAX' undeclared (first use in this function) zend_hash.c:237: (Each undeclared identifier is reported only once zend_hash.c:237: for each function it appears in.) zend_hash.c: In function `zend_hash_del_key_or_index': zend_hash.c:482: `LONG_MAX' undeclared (first use in this function) zend_hash.c: In function `zend_hash_find': zend_hash.c:801: `LONG_MAX' undeclared (first use in this function) zend_hash.c: In function `zend_hash_exists': zend_hash.c:851: `LONG_MAX' undeclared (first use in this function) make[1]: *** [zend_hash.lo] Error 1 make[1]: Leaving directory `/mnt/files/programs/php4/php-4.0.1pl2/Zend' make: *** [all-recursive] Error 1 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5661&edit=2 -- 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 #10540 Updated: ini_set doesn't work
ID: 10540 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: PHP options/info functions PHP Version: 4.0 Latest CVS (28/04/2001) Assigned To: Comments: ini_set() cannot affect the behavior of PHP that takes place before the script execution begins. Variable registration occurs before the execution of the script begins (the variables are available and accessible right from the 1st line in the script). So by the time you call ini_set(), variable registration is already done. Affecting it in any way (global registration, automated quotes) is not possible. Previous Comments: --- [2001-04-28 16:43:31] [EMAIL PROTECTED] ini_set does not seem to work with register_globals and magic_quotes. Example: You call a file and include the query string "test=hmm". Here is the code for the file: "; echo "$test value: $test"; ?> This will generate the following output: register_globals setting: 0 $test value: hmm Notice that the value "hmm" is still there even though register_globals is off according to the ini_get line. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10540&edit=2 -- 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 #9562 Updated: Memory leak in ext/pgsql/pgsql.c
ID: 9562
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproduceable crash
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Your fix was incorporated to the CVS, and will be a part of PHP 4.0.6. Thanks!
Previous Comments:
---
[2001-03-05 10:11:09] [EMAIL PROTECTED]
Script for reproducing bug:
while(!($con=@pg_pconnect("dbname=web")))
{
sleep(1);
}
The system must be under heavy load for bug to become apparent.
Suggested correction in ext/pgsql/pgsql.c (added lines are marked with ***):
if (pgsql==NULL || PQstatus(pgsql)==CONNECTION_BAD) {
*** if(pgsql) {
*** PQfinish(pgsql);
*** pgsql=0;
*** }
php_error(E_WARNING,"Unable to connect to PostgreSQL server:
%s",PQerrorMessage(pgsql));
efree(hashed_details);
RETURN_FALSE;
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9562&edit=2
--
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 #8889 Updated: Memory is not being freed.
ID: 8889
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
PHP Version: 4.0.4
Assigned To:
Comments:
What kind of sizes are we talking about here? the Zend memory manager holds a memory
cache, but we're talking at around 1MB per process max.
Previous Comments:
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-dev&m=97923602322593&w=2 which contains a hacked
up solution. It looks like it should be able to turn into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory is growing by
the minute. If I start a separate server on another port and serve only static pages
and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with anything. I know I
need to attach to a process and it seems I can `gdb {pid}` but that gives me nothing.
How can I get some info for you guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8889&edit=2
--
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 #10029 Updated: zend_list_do_delete() ignores HashTable* param. Potential mem leak.
ID: 10029
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Unknown/Other Function
PHP Version: 4.0.4pl1
Assigned To:
Comments:
zend_plist_delete() was redundant and removed from the CVS a few weeks ago (it didn't
make it for 4.0.5, but will be in 4.0.6)
Previous Comments:
---
[2001-03-27 13:54:23] [EMAIL PROTECTED]
from Zend/zend_list.c
Note that list is passed in, but &EG(regular_list) is used wherever list should be
used.
static inline int zend_list_do_delete(HashTable *list,int id)
{
zend_rsrc_list_entry *le;
ELS_FETCH();
if (zend_hash_index_find(&EG(regular_list), id, (void **) &le)==SUCCESS) {
/* printf("del(%d): %d->%dn", id, le->refcount, le->refcount-1); */
if (--le->refcount<=0) {
return zend_hash_index_del(&EG(regular_list), id);
} else {
return SUCCESS;
}
} else {
return FAILURE;
}
}
.
.
.
Scroll down, and we see that both zend_list_delete and zend_plist_delete are calling
this with different hashtable args. It looks as though we must be leaking memory
whenever zend_plist_delete is called.
ZEND_API int zend_list_delete(int id)
{
ELS_FETCH();
return zend_list_do_delete(&EG(regular_list), id);
}
ZEND_API int zend_plist_delete(int id)
{
ELS_FETCH();
return zend_list_do_delete(&EG(persistent_list), id);
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10029&edit=2
--
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 #8414 Updated: set_time_out() is acting inconsistantly
ID: 8414
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Performance problem
PHP Version: 4.0.4
Assigned To:
Comments:
Note that under UNIX, execution time relates to the actual CPU time consumed by PHP,
which may be very different (less) than the actual time that passed. sleep(), for
instance, does not consume any CPU time, so it will never trigger the execution
timeout.
Previous Comments:
---
[2001-04-29 22:03:53] [EMAIL PROTECTED]
I can't reproduce this with latest CVS. If problem
still persist with PHP 4.0.5 or with latest CVS snapshot
from http://snaps.php.net/ reopen this bug report.
--Jani
---
[2001-04-07 02:10:02] [EMAIL PROTECTED]
I'm re-filing this as a bug report.
It appears that set_time_out() is acting inconsistant.
The following code stops after 5 seconds as you would expect:
set_time_limit(5);
while(1) {
$i++;
}
While this code continues executing indefinitely:
set_time_limit(5);
while(1) {
$i++;
echo "$in";
}
---
[2000-12-25 05:55:38] [EMAIL PROTECTED]
documentation is not clear enough on what "excecution time"
the max_execution_parameter does limit.
try the following:
on my machine that runs much more then one second, while:
stops after 1 second as expected.
That difference is never mentioned in documentaion.
While the usage of PROF timer make sence sometimes the parameter name
"max_execution_time" suggests the "real" time limit so that
should be terminated on timeout after 30 seconds.
oleg
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8414&edit=2
--
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 #10682 Updated: php -l display the same errors
ID: 10682 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem PHP Version: 4.0 Latest CVS (05/05/2001) Assigned To: Comments: As funny as it may sound, it's the intended behavior, if: - You have a debug build (an error goes to stderr) - You have display_errors set to on (an error goes to the standard output, HTML format) - You have error logging enabled (default goes to stderr) Previous Comments: --- [2001-05-05 19:44:01] [EMAIL PROTECTED] If I execute CGI php binary with "-l" option, I see the same error message 3 times in different formats. === PHP Parse error: parse error, expecting `T_VARIABLE' or `'$'' in php_lint.php on line 5 Parse error: parse error, expecting `T_VARIABLE' or `'$'' in php_lint.php on line 5 php_lint.php(5) : Parse error - parse error, expecting `T_VARIABLE' or `'$'' [www@dev language]$ php -ql php_lint.php PHP Parse error: parse error, expecting `T_VARIABLE' or `'$'' in php_lint.php on line 5 Parse error: parse error, expecting `T_VARIABLE' or `'$'' in php_lint.php on line 5 php_lint.php(5) : Parse error - parse error, expecting `T_VARIABLE' or `'$'' = ./configure --disable-short-tags --disable-mysql --without-pear --without-mysql --enable-debug --enable-bcmath --enable-ftp --enable-shmop --enable-sysvsem --enable-sysvshm --enable-sockets --enable-mbstring --enable-mbstr-enc-trans --enable-debug --enable-memory-limit --with-regex=system --with-openssl --with-iconv --with-imap --with-mhash --with-mcrypt --with-pgsql --with-swf --with-zlib --with-bz2 --with-gd --with-jpeg-dir=/usr --with-xpm-dir=/usr/X11R6 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10682&edit=2 -- 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 #5404 Updated: String conversion to integer is incorrect
ID: 5404 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.1 Assigned To: Comments: Fixed at last - thanks for the report! Previous Comments: --- [2000-08-05 12:27:47] [EMAIL PROTECTED] Yes, strtod makes mess from 0x-numbers (I suspect it being libc bug, but maybe they intended it to be so), so we should catch them in strtol. --- [2000-08-05 04:28:40] [EMAIL PROTECTED] Yes, of course, sorry about the typo. It seems to me that the place where this is done in such a way is in the function is_numeric_string() in the file zend_operators.* --- [2000-08-04 23:36:30] [EMAIL PROTECTED] you're talking about strtol() here, not strtod(), aren't you? --- [2000-08-04 01:50:38] [EMAIL PROTECTED] No, it is not necessary to create a new strtod function, because when php checks if the string is a number or not it explicitly tells strtod, that the string is a base 10 number, instead of letting strtod determine the base itself, which would result in the correct behaviour. --- [2000-08-03 21:52:51] [EMAIL PROTECTED] so maybe we should add some kind of strtod-wrapper to get around this libc 'feature'? --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=5404&edit=2 -- 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 #6385 Updated: __FILE__ returns lowercased filenames
ID: 6385
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Feedback
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0 Latest CVS (27/08/2000)
Assigned To:
Comments:
Does this still happen with 4.0.5 or latest CVS? I can't reproduce it.
Previous Comments:
---
[2001-01-08 15:40:35] [EMAIL PROTECTED]
not IIS-specific, reclassifying
---
[2000-11-04 06:34:12] [EMAIL PROTECTED]
tested on CGI+ApacheMod, both return lowercased
---
[2000-08-31 09:02:16] [EMAIL PROTECTED]
Does this happen with CGI version? I suspect it might be just IIS which sets your
filename lowercase...
---
[2000-08-27 21:28:47] [EMAIL PROTECTED]
if I´m calling a file "FooBar.php", echo __FILE__; will
output "foobar.php".
Although w32 allows files only in-sensitive (no FooBar.php
and foobar.php concurrently) it saves the case information
and thus __FILE__ (and related) should contain this cased
information too.
This will bug will also cause scripts not to be platform
independend:
// filename lowercased
$filename=basename(__FILE__);
// HTTP REQUEST, w cased filename
$fullpage=substr($tmp=strtolower(getenv('SERVER_PROTOCOL')),0,strpos($tmp,'/')).'://'.getenv('HTTP_HOST').getenv('REQUEST_URI');
$pageonly=substr($fullpage,0,strpos($fullpage,$filename)+strlen($filename));
hile this script should work on *nix calling "foobar.php" it
does not on w32
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6385&edit=2
--
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 #2892 Updated: php -a (interactive mode) doesn't call functions
ID: 2892 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Assigned Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0 Beta 3 Assigned To: Andi Comments: Beat ya to it, Andi :) Fixed in the CVS Previous Comments: --- [2001-04-29 13:39:24] [EMAIL PROTECTED] Interactive mode is very limited and only meant to check simple things with. We can keep it as an assigned bug but I don't think it'll ever be fixed. --- [2000-07-23 11:06:27] [EMAIL PROTECTED] Yes it does. --- [2000-07-23 02:54:18] [EMAIL PROTECTED] Is this problem still occuring in the most recent release? --- [1999-12-02 06:43:12] [EMAIL PROTECTED] Script set.php3: a = $b; echo "$bn"; } } $y = new x(); echo $y->a,"n"; $y->seta(10); echo $y->a,"n"; ?> Run: php -f set.php3 get: 2 10 10 still OK. Now run php -a < set.php3: Interactive mode enabled Content-Type: text/html 2 2 Huh? where's my method call? Or interactive mode isn't what I thought it is? Strange thing is that php < set.php3 does work, so what "interactive mode" is in fact? --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=2892&edit=2 -- 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 #6662 Updated: array keys of type real not allowed?
ID: 6662
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Analyzed
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.2
Assigned To:
Comments:
Fixed in the CVS - thanks for your report!
Previous Comments:
---
[2000-09-16 17:00:56] [EMAIL PROTECTED]
Float keys don't work, the variable gets converted to integer. This, however, doesn't
work with array initializers - this should be fixed.
---
[2000-09-11 22:06:25] [EMAIL PROTECTED]
It seems that array keys of type real are not allowed in class declaration:
class MyClass {
var $a = array( 1.5=>1, 3.5=>2, 7.5=>5, 99=>10);
...
}
Results in only one item 99=>10 in array.
Above is accepted in PHP3.
Workaround:
var $a = array( '1.5'=>1, '3.5'=>2, '7.5'=>5, '99'=>10);
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=6662&edit=2
--
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 #7342 Updated: Different config-op parsing in php.ini and http.conf
ID: 7342 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.3pl1 Assigned To: Comments: This is the intended behavior. The special notations that are supported in php.ini are features of the php.ini parser, and thus, are not available in other configuration options, such as ini_set() or httpd.conf. Previous Comments: --- [2001-01-09 23:35:55] [EMAIL PROTECTED] The same applies to the php function ini_set(). It looks like the onmodify entry is being not found/called from zend_alter_ini_entry and it's using the 'estrndup/value=duplicate' instead --- [2000-10-19 11:20:06] [EMAIL PROTECTED] In php.ini for setting the upload_max_filesize one can use abbrevations for certain amounts of bytes (e.g. M for 'Megabytes'). The line upload_max_filesize = 15M means 15 * 1024 * 1024 Bytes are allowed. When using the php_value upload_max_filesize 15M directive in apache httpd.conf the 'M' modifyer is *NOT* used, leading to actually setting the max. file size for uploads to only 15 Bytes, not 15 MB. One has to use 15728640 (i.e. 15 * 1024^2) to set the value to 15 MB. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7342&edit=2 -- 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 #10599 Updated: background attribute in the body tag causes a double insert
ID: 10599 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: MySQL related Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Actually, it's a bug in your HTML (although you did confuse me for a few minutes...) The attribute you're looking for is bgcolor; background loads a background image, and expects a URL argument. When you feed it with #FF, it tries to access http://www.dukemarket.com/bug.php#FF to load it as a background image, access the page again, and causes a second insert. It was a good challenge though :) Previous Comments: --- [2001-05-02 03:45:48] [EMAIL PROTECTED] I have documented the problem at http://www.dukemarket.com/bug.php";>http://www.dukemarket.com/bug.php. If you have any questions, email me at mailto:[EMAIL PROTECTED]";>[EMAIL PROTECTED]. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10599&edit=2 -- 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 #8663 Updated: Script with incorrect syntax crashes php4ts.dll (seems similar to #8521)
ID: 8663 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Reproduceable crash Operating system: PHP Version: 4.0.4 Assigned To: Comments: Fixed in the CVS - thanks for the accurate and easily reproducible bug report! Previous Comments: --- [2001-04-26 15:08:45] [EMAIL PROTECTED] heh trying a modified script didnt work but trying your script again crashses. Backtrace: _zval_ptr_dtor(_zval_struct * * 0x00e00b8c, char * 0x1022188c `string', unsigned int 236) line 259 + 5 bytes zend_switch_free(_zend_op * 0x00dae5c0, _temp_variable * 0x00e00b88, _zend_executor_globals * 0x00db21e0) line 236 + 38 bytes execute(_zend_op_array * 0x00e00c28, _zend_executor_globals * 0x00db21e0) line 1831 + 17 bytes execute(_zend_op_array * 0x00dff2f8, _zend_executor_globals * 0x00db21e0) line 2039 + 19 bytes zend_execute_scripts(int 8, _zend_compiler_globals * 0x00db28f0, _zend_executor_globals * 0x00db21e0, int 3) line 743 + 22 bytes php_execute_script(_zend_file_handle * 0x0012ff48, _zend_compiler_globals * 0x00db28f0, _zend_executor_globals * 0x00db21e0, _php_core_globals * 0x00db52c0) line 1205 + 29 bytes main(int 3, char * * 0x00db18c0) line 735 + 22 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e992a6() --- [2001-04-26 14:53:41] [EMAIL PROTECTED] THis has been fixed in latest CVS, and will be included in 4.0.6 thanks for your report. - James --- [2001-04-26 14:25:50] [EMAIL PROTECTED] Reproduced under Apache and ISAPI under win2k. - James --- [2001-01-11 16:59:07] [EMAIL PROTECTED] I have three php files as follows: --f1.php-- -- --f2.php-- -- --f3.php-- -- When running f1.php through php.exe I get PHP caused an invalid page fault in module PHP4TS.DLL at 015f:1008e147. Registers: EAX=0001 CS=015f EIP=1008e147 EFLGS=00010206 EBX=006601ec SS=0167 ESP=0063f410 EBP=00791710 ECX= DS=0167 ESI=00791714 FS=541f EDX=007910dc ES=0167 EDI=006601e4 GS= Bytes at CS:EIP: 66 ff 48 0a 8b 06 66 8b 48 0a 66 85 c9 75 40 50 Stack dump: 007612f0 100a46bb 00791714 00791990 007612f0 007918e0 0065ea04 006601c4 006601c4 0001 007910dc 006601ec 81709050 0063f470 Couldn't generate a backtrace, the borland debugger refused to work on this error. It seems to be similar to the problem described in bug #8521. In both cases a simple syntax error crashes the DLL. In this case, however, the include directives seem to have something to do with the bug. Simply copying the contents of f2 and f3 into f1 does not cause a crash. PHP is 4.0.4 windows installer from your website. Bye, Paul --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8663&edit=2 -- 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 #9827 Updated: Floating point exception when starting apache
ID: 9827 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Old-Bug Type: Reproducible Crash Bug Type: *General Issues Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Can you please see if this still happens in PHP 4.0.5? It's supposed to be fixed. Previous Comments: --- [2001-03-18 21:51:48] [EMAIL PROTECTED] The calculation itself does not lead to the overflow. I inserted this line right before the error happens: fprintf (stdout, "Value: %f", ..calculation comes here ...); So I guess the function accepts only numbers to a certain size. (values over approx. 2^34 or under 2^-34 makes apache hurl) --- [2001-03-18 21:43:26] [EMAIL PROTECTED] - HW: Cobalt Raq2 (MIPS R3000) - OS: Linux - Apache: 1.3.19 - PHP built with these arguments: --with-apxs --enable-trans-sid - PHP release: 4.0.4pl1 and the latest CVS snapshot (date 18/03/2001) when starting apache with "./httpd", a core is dumped. The message is: Floating point exception (core dumped) I played around with gdb, the exception occurs in: ext/standard/crypt.c:105 php_srand(time(0) * getpid() * php_combined_lcg() * 1.0 ); I played around with this line. When I replace the value 1.0 with 1.0 and recompile the stuff, it works. I'm no C programmer, but I think this is due to an overflow problem. If you need more informations, tell me! Best regards Matti Weiersmueller --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9827&edit=2 -- 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 #10708 Updated: modphp crashes if cascaded includes occur
ID: 10708 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Can you check if the problem persists in the latest CVS? Previous Comments: --- [2001-05-07 11:27:59] [EMAIL PROTECTED] I maintain a WebSite with mixed php and SSI pages. SSI is used to maintain a corporated design for all Pages. So all php Pages include the standard ssi framework. So far everything works fine Now i have tried to include a php script from the ssi framework with if i Do this mod php crashes after the subrequest for the ssi framework is finished and control is returnd to mod php. As far as I can tell the included php script is executed without errors. gdb backtrace says #0 0x816086a in execute (op_array=0x82c9a00) at ./zend_execute.c:1523 #1 0x8160a35 in execute (op_array=0x82c928c) at ./zend_execute.c:1559 #2 0x812392b in zend_execute_scripts (type=8, file_count=3) at zend.c:729 #3 0x80904ac in php_execute_script (primary_file=0xbfbfda14) at main.c:1221 #4 0x81360f7 in apache_php_module_main (r=0x82bd3e4, display_source_mode=0) at sapi_apache.c:89 #5 0x808cea6 in send_php (r=0x82bd3e4, display_source_mode=0, filename=0x82bd9a4 "/usr/local/www/virt/inga/htdocs/termine/index.php3") at mod_php4.c:516 #6 0x808cee0 in send_parsed_php (r=0x82bd3e4) at mod_php4.c:527 #7 0x816c553 in ap_invoke_handler (r=0x82bd3e4) at http_config.c:517 #8 0x8182a19 in process_request_internal (r=0x82bd3e4) at http_request.c:1303 #9 0x8182e94 in ap_internal_redirect ( new_uri=0x82bd3a4 "/termine/index.php3", r=0x82bc034) at http_request.c:1427 #10 0x807943d in handle_dir (r=0x82bc034) at mod_dir.c:174 #11 0x816c553 in ap_invoke_handler (r=0x82bc034) at http_config.c:517 #12 0x8182a19 in process_request_internal (r=0x82bc034) at http_request.c:1303 #13 0x8182a7c in ap_process_request (r=0x82bc034) at http_request.c:1319 #14 0x8178cc9 in child_main (child_num_arg=0) at http_main.c:4208 #15 0x8178e88 in make_child (s=0x820e034, slot=0, now=989249079) at http_main.c:4312 #16 0x8179013 in startup_children (number_to_start=1) at http_main.c:4394 #17 0x8179664 in standalone_main (argc=2, argv=0xbfbfdc28) at http_main.c:4682 #18 0x8179fd3 in main (argc=2, argv=0xbfbfdc28) at http_main.c:5009 --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10708&edit=2 -- 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 #10076 Updated: NULL entry calling
ID: 10076
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Old-Bug Type: Reproducible Crash
Bug Type: *General Issues
Operating system:
PHP Version: 4.0 Latest CVS (30/03/2001)
Assigned To:
Comments:
Can you please check if this still happens in the latest CVS?
Previous Comments:
---
[2001-03-30 10:25:35] [EMAIL PROTECTED]
File output.c
No checks whether it is possible to call this php_body_write or not. During shutdown
of server calling from oci_debug( ... ) causes crash on the Win32 system by coalling
NULL entry.
PHPAPI int php_body_write(const char *str, uint str_length)
{
OLS_FETCH();
return OG(php_body_write)(str, str_length);
}
sugest to change it to:
if( OG(php_body_write) )
{
return OG(php_body_write)(str, str_length);
}
return 0;
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10076&edit=2
--
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 #8725 Updated: Fun with putenv
ID: 8725
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Critical
Status: Open
Bug Type: Apache related
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
This apperas to be SCO specific so it's not very fixable. Remarking as 'Open'.
[EMAIL PROTECTED], will it be possible to have a temporary account on your machine to
debug this? Or does anybody else have access to this platform?
Previous Comments:
---
[2001-05-07 12:47:14] [EMAIL PROTECTED]
Marking as "fix-before-4.0.6"
---
[2001-03-09 21:09:23] [EMAIL PROTECTED]
User feedback:
--
The latest snapshot made no difference. The behavior I
describe persists. It's always the third execution of the
script (second page reload) that produces the failure. By
the way, at that point not only "exec" stops working, but
"system" and "passthru" as well. It appears that "putenv" is
the cause, since removing it from the script remedies the
problem (after apache restart there is).
It's quite possible that the problem is unique to my
environment:
SCO Opendesktop 5.05
Apache/1.3.14 with mod_php4
but that doesn't make the situation any easier.
Couple of more points:
-- the same script works fine when executed on the shell level
-- every time phtml script fails, the following message is left in access_log: ": is
not an identifier".
If this matter is of any interest to the developers, I'll be
more than happy to investigate (with proper guidance :-))
further.
Thanks.
-mk
---
[2001-01-15 18:04:25] [EMAIL PROTECTED]
I tried your script in my system (Linux) and with the latest CVS of PHP 4
and it works just fine. Could you try the latest snapshot from http://snaps.php.net/
to verify if this is fixed or if it is your system that causes this.
--Jani
---
[2001-01-15 15:53:11] [EMAIL PROTECTED]
[this is a re-sent of my message, I accidentally inserted php config options in
the wrong place of my previous message]
Apache: 1.3.14 (with mod_php4 among other)
test.phtml:
");
print("2: $two[0] ($ret)");
?>
Browser shows:
1: one
2: two (0)
After hitting Reload, browser shows:
1: one
2: two (0)
After hitting Reload again, browser shows:
1: one
Warning: Undefined index: 0 in /u/local/apache/htdocs/test.phtml on line 6
2: (1)
After "apachectl restart" the above repeats...
Config options:
configure --with-gd=/usr/local/gd --with-mysql --with-jpeg-dir=/tmp/jpeg-6b
--with-apache=../apache_1.3.14
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=8725&edit=2
--
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 #10690 Updated: pdf_open_memory_image() not implemented in Windows version
ID: 10690 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Critical Status: Closed Bug Type: PDF related Operating system: PHP Version: 4.0.5 Assigned To: Comments: No idea why it was Critical, but it sure did draw attention :) Fixed in the latest CVS (warns about its inavailability, it only exists in newer GD versions) Previous Comments: --- [2001-05-07 12:49:12] [EMAIL PROTECTED] Marking as fix before 4.0.6 --- [2001-05-06 16:05:45] [EMAIL PROTECTED] pdf_open_memory_image() is not implemented in PHP 4.0.5 and all previous versions - for Win32. Other platforms have this function since v4.0. NB: same as #10606, but it appears on all versions of windows. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10690&edit=2 -- 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 #10690 Updated: pdf_open_memory_image() not implemented in Windows version
ID: 10690 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: PDF related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Newer pdflib versions that is Previous Comments: --- [2001-05-07 20:16:55] [EMAIL PROTECTED] No idea why it was Critical, but it sure did draw attention :) Fixed in the latest CVS (warns about its inavailability, it only exists in newer GD versions) --- [2001-05-07 12:49:12] [EMAIL PROTECTED] Marking as fix before 4.0.6 --- [2001-05-06 16:05:45] [EMAIL PROTECTED] pdf_open_memory_image() is not implemented in PHP 4.0.5 and all previous versions - for Win32. Other platforms have this function since v4.0. NB: same as #10606, but it appears on all versions of windows. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10690&edit=2 -- 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 #9289 Updated: Command line argument list inaccurate
ID: 9289 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Critical Status: Closed Bug Type: Unknown/Other Function Operating system: PHP Version: 4.0.4pl1 Assigned To: Comments: Fixed in the CVS - thanks for the report! Note that ./php -f foo.php sets $argc to 1, like ./php foo.php does. Old versions of PHP erroneously set it to 0. Previous Comments: --- [2001-05-07 20:30:31] [EMAIL PROTECTED] Reproducable under Win2k. - James --- [2001-02-15 14:48:09] [EMAIL PROTECTED] PHP, when being run from the command line, has been mangling the command line arguments badly for some while. It would be nice if they mapped to the same usage as C programs. PHP4.04pl1 is particularly bad - argc is completely broken: Consider the script Here's the output from php4.01, and then from php4.04pl1 $ php -f test.php 0 $ php -f test.php a 1 $ php -f test.php a b 2 $ php -f test.php a b c 3 $ /home/webapps/webserver/bin/php404pl1 -f test.php 2 $ /home/webapps/webserver/bin/php404pl1 -f test.php a 2 $ /home/webapps/webserver/bin/php404pl1 -f test.php a b 3 $ /home/webapps/webserver/bin/php404pl1 -f test.php a b c 4 As you can see, argc is never less than 2, and in fact is a value of 2 with zero args or one arg (bad bad bad!). Sort of important for us - we find PHP SO EASY to program in, that we actually use it as the language of choice, even for batch programming, when performance is not absolutely critical. But it sort of makes it tough to pass in cmd line arguments... --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9289&edit=2 -- 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 #9154 Updated: HTTPD Memory Utilization Spike
ID: 9154
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Is this fairly reproducible?
If it is, any chance you could build Apache with debug information (--enable-debug in
configure), attach to an offending process (gdb /path/to/httpd ), and run a
backtrace ('bt')?
Previous Comments:
---
[2001-02-07 11:55:47] [EMAIL PROTECTED]
Using ezxmlrpc 1.0 library from ez systems to write web services. Ezxmlrpc uses the
qtdom option to process XML. Web services are reading from and writing to Postgres
7.0.3 database. Web services are working properly, but when they are called
repeatedly (anywhere from 6 to 25 times in a row), one of the httpd processes eats all
of the CPU and memory utilization spikes to over 100MB. PHP interpreter eventually
stops because max execution time of 30 secs is exceeded. Then, memory utilization for
that process drops back down to around 3MB.
I am using apache 1.3.14 and have php built as a DSO. I do not seem to get a core
dump, so I can not include a backtrace.
My configure line follows:
./configure --with-apxs=/usr/local/apache/bin/apxs --with-magic_quotes --with-dom
--with-qtdom --with-pgsql --enable-debug
I am classifying this as a performance problem, even though I know it is not. Don't
know how else to clasify it. I know this is not enough info to begin debugging this
problem. Can someone give me some tips on how I can narrow this down?
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9154&edit=2
--
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 #10299 Updated: CPU and Memory Spike
ID: 10299
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Performance problem
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Is this fairly reproducible?
If it is, any chance you could build Apache with debug information (--enable-debug in
configure), attach to an offending process (gdb /path/to/httpd ), and run a
backtrace ('bt')?
Previous Comments:
---
[2001-05-07 12:44:51] [EMAIL PROTECTED]
marking critical for php 4.0.6
---
[2001-04-14 09:00:57] [EMAIL PROTECTED]
I found the problem. since the script I use have a lot of include and require
statement. just a script include a bunch of files and keep reloading the page will
kill the server in no time. I attach a sample config file I usually include, just
make a test.php and include this file like 10 times to simulate a lot of include
files. And then, just keep reloading test.php. You should see the script take a lot
of CPU time and eventually the httpd eat all the CPU time and the process hang. From
command "top", one of the httpd process keep eating up CPU time.
The following is the sample config file
http://www.test.net/";;
// Cookie Setting
$config[cookie_path] = "/"; # web root directory
$config[CookieURL] = ".test.net";
$config[cookieTTL] = 7200; // in seconds
$config[minpass]= 3; # Minimum user password length in characters
/* language and locale */
$config[language] = "english";# [english] english, [big5] BIG5 code
$config[locale] = "english";# Used for translation of date-related stuff
/* story control */
$config[commentmax] = 4096;
$config[abstractlen]= 4996; #length of abstract show on first page
$config[icon_width] = 100; # Topic icons width
$config[timezone] = "HKT"; #Time zone
$config[limitnews] = 10; # default number of stories per page
$config[older_story_num]= 10; # number of older stories to display
$config[anon_users] = 0; # 1 to allow anonymous postings
# 0 to disable
/* theme control */
$config[def_theme] = "Main"; # name of default theme (see themes/ directory for
list)
/* mail settings */
$config[use_fake_email] = 1; # Displays fake email addresses for users instead of the
real ones
$config[notifyEmail]= "[EMAIL PROTECTED]"; #address where you want to
receive notice
//$config[CensorList] =
array('fuck','cunt','fucker','fucking','pussy','cock','c0ck','cum','bitch','shit');
$config[CensorList] = array("/fuck/s","/fuck/s","/fuck/s",
"/[a-z]*fuck[a-z]*/is",
"/[a-z]*cunt[a-z]*/is",
"/[a-z]*pussy[a-z]*/is",
"/[a-z]*cock[a-z]*/is",
"/[a-z]*c0ck[a-z]*/is",
"/[a-z]*shit[a-z]*/is",
"/[a-z]*bitch[a-z]*/is",
"/[a-z]*diu[a-z]*/is"
);
# See also specific LOCALE definitions
$config[CensorMode] = 3; # 0: no filtering
# 1: exact match
# 2: match word beginnings
# 3: match string anywhere in words
$config[CensorReplace] = "[CENSORED]" ;
/* allowable HTML tags. Used by check_html()
Happily lifted (with mods) from phpslash */
$config[AllowableHTML] = array("p"=>1, # 2 means accept all qualifiers:
"b"=>1,# 1 means accept the tag only:
"i"=>1,
"a"=>2,
"em"=>1,
"br"=>1,
"strong"=>1,
"blockquote"=>1,
"img"=>2,
"tt"=>1,
"hr"=>1,
"li"=>1,
"ol"=>1,
"div"=>1,
"ul"=>1);
$config[AllowableHTMLtag] =
"";
/* poll settings */
$config[maxOptions] = 12; # maximal number of options allowed
$config[BarScale] = 1;# scale of result bar (in multiple
[PHP-DEV] Bug #10734 Updated: Strange conversion string->numbers
ID: 10734 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *General Issues Operating system: PHP Version: 4.0.5 Assigned To: Comments: Fixed in the CVS. Thanks for the report! Previous Comments: --- [2001-05-08 11:44:43] [EMAIL PROTECTED] AFAIR this is some strange magic borrowed from perl the deeper sense in this is that you can use it to increment/decrement the numerical part of serial numbers and such IMHO this is more confusing then helpfull and should be nuked --- [2001-05-08 11:26:43] [EMAIL PROTECTED] Here is a simple code And here results -5 -4 -5 -- -5 -6 <-- ? -7 It looks like "++" operator do not work properly on variables enclosed in double-quotes. Other operators (ie $num = $num +1) woks properly. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10734&edit=2 -- 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 #10591 Updated: magic_quotes_runtime being randomly set?
ID: 10591
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: PHP options/info functions
Operating system:
PHP Version: 4.0 Latest CVS (01/05/2001)
Assigned To:
Comments:
Do you have any settings for magic_quotes_runtime in your httpd.conf or .htaccess
files?
Previous Comments:
---
[2001-05-09 11:12:01] [EMAIL PROTECTED]
Marked as to be fixed before 4.0.6
---
[2001-05-01 23:07:35] [EMAIL PROTECTED]
Hmmm... maybe we do have a bug here...
There are no calls to magic_quotes_runtime().
There are no includes, requires or auto_(pre|ap)pend_files.
The php.ini files and apache conf files don't set magic_quotes_runtime.
And there are no other scripts on the box that call magic_quotes_runtime() or set_ini
('magic_quotes_runtime', 'On');
So, right now it does seem that magic_quotes_runtime does to randomly turn on and off.
Calls to get_magic_quotes_runtime() accurately report whether magic_quotes_runtime is
active, while phpinfo() reports that magic_quotes_runtime is off - both locally and
the master value.
Initial reports indicated that the bug may have been related to file(), however, the
problem can be reproduced using fopen() as well - see
http://airbag.tss.peachnet.edu/~sam/fopen.php and
http://airbag.tss.peachnet.edu/~sam/fopen.txt.
Anyone have any ideas here - I am coming up blank.
---
[2001-05-01 21:19:23] [EMAIL PROTECTED]
Damn... misread last comment. Have asked user to send me relevant code. I would guess
that something simple to fix on here...
---
[2001-05-01 21:05:19] [EMAIL PROTECTED]
Semi-randomly?
There are no odd lines in my php.ini...
I need this to work for my app! :)
---
[2001-05-01 20:54:05] [EMAIL PROTECTED]
The php.ini parser may behave strangely when presented with broken lines,
semi-randomly turning features on and off.
IMHO not a giant issue - if I get a chance, I will take a closer look at it.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10591&edit=2
--
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 #10591 Updated: magic_quotes_runtime being randomly set?
ID: 10591
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: PHP options/info functions
Operating system:
PHP Version: 4.0 Latest CVS (01/05/2001)
Assigned To:
Comments:
Also, has anybody managed to reproduce it? I can't.
Previous Comments:
---
[2001-05-10 09:27:52] [EMAIL PROTECTED]
Do you have any settings for magic_quotes_runtime in your httpd.conf or .htaccess
files?
---
[2001-05-09 11:12:01] [EMAIL PROTECTED]
Marked as to be fixed before 4.0.6
---
[2001-05-01 23:07:35] [EMAIL PROTECTED]
Hmmm... maybe we do have a bug here...
There are no calls to magic_quotes_runtime().
There are no includes, requires or auto_(pre|ap)pend_files.
The php.ini files and apache conf files don't set magic_quotes_runtime.
And there are no other scripts on the box that call magic_quotes_runtime() or set_ini
('magic_quotes_runtime', 'On');
So, right now it does seem that magic_quotes_runtime does to randomly turn on and off.
Calls to get_magic_quotes_runtime() accurately report whether magic_quotes_runtime is
active, while phpinfo() reports that magic_quotes_runtime is off - both locally and
the master value.
Initial reports indicated that the bug may have been related to file(), however, the
problem can be reproduced using fopen() as well - see
http://airbag.tss.peachnet.edu/~sam/fopen.php and
http://airbag.tss.peachnet.edu/~sam/fopen.txt.
Anyone have any ideas here - I am coming up blank.
---
[2001-05-01 21:19:23] [EMAIL PROTECTED]
Damn... misread last comment. Have asked user to send me relevant code. I would guess
that something simple to fix on here...
---
[2001-05-01 21:05:19] [EMAIL PROTECTED]
Semi-randomly?
There are no odd lines in my php.ini...
I need this to work for my app! :)
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10591&edit=2
--
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 #7822 Updated: system crash
ID: 7822 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Critical Status: Closed Bug Type: Apache related Operating system: PHP Version: 4.0.4 Assigned To: Comments: Fixed in the CVS. Thanks for the report! Previous Comments: --- [2001-05-09 11:22:56] [EMAIL PROTECTED] System security bugs are quite critical. This has to be addressed before 4.0.6 --Jani --- [2001-05-07 12:52:28] [EMAIL PROTECTED] I guess the point is to prevent malicious users from crashing the server. --- [2001-05-07 12:35:23] [EMAIL PROTECTED] I don't see the point in accessing http://localhost/php/php.exe. So, why do you want to do that? --- [2001-05-04 03:41:23] [EMAIL PROTECTED] Now I use Apache/1.3.19 with PHP/4.0.5 for Windows 98 this problem still exists. Default setting will make system crash in Windows 98 if accessing something like http://localhost/php/php.exe I guess PHP at least should announce this problem (and I've made two of my friends crashed, sorry if they see this.). --- [2001-01-12 12:27:08] [EMAIL PROTECTED] cynic: This is a Great Idea! --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7822&edit=2 -- 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 #2220 Updated: dynamic module memory leaks cause SIGSEGV under DEBUG mode
ID: 2220 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Dynamic loading Operating system: PHP Version: 4.0 Latest CVS (02/09/1999) Assigned To: zeev Comments: There haven't been any changes, so there's no need to test it in 4.0.5. The problem is still there. Updated the description to reflect it only occurs in debug mode. Previous Comments: --- [2001-05-14 02:42:06] [EMAIL PROTECTED] i'm not involved in PHP development anymore. i can test it for you in a week. but a quick glance at the newest source hints me, it does. --- [2001-05-11 08:05:46] [EMAIL PROTECTED] Does this bug still exists with the latest release? (php 4.0.5)? --- [2000-11-27 05:41:24] [EMAIL PROTECTED] reclassify --- [2000-07-23 22:11:05] [EMAIL PROTECTED] Information from Zeev / 2000-07-23: "We have no fix for this bug at this time. It's not too urgent, as it only affects DEBUG builds." --- [2000-07-23 00:41:02] [EMAIL PROTECTED] Contacted Zeev on 00-08-22 --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=2220&edit=2 -- 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 #10299 Updated: CPU and Memory Spike
ID: 10299
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Performance problem
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
I'm unable to reproduce a fd leak using require_once() or include_once().
Do you have any script that reproduces this problem?
We can't really replicate your problem in general, but if somehow there's a resource
leak in your setup, lots of different weird things could end up happening.
Previous Comments:
---
[2001-05-09 01:08:11] [EMAIL PROTECTED]
What I found out is that using a lot of include_once, require_once + session will
trigger the CPU and memory spike. Add database access to the script can speed up the
frequency of the spike. And I also found out require_once DO leak memory. pstat -T
show that file in use will always increase. Somehow require_once forgot to close the
file after use. lsof can give you a clear picture when you use require_once()
I changed my code using cookie and require() statement now. And I delete all
sess_files in /tmp seems to correct the problem. This is the only change I made to
eliminate the problem.
I can't reproduce the error now because the code that have problems have been changed
and I don't have the backup. But the combination of A lot of include_once,
require_once, and session will trigger the spike, I am pretty sure because after I
changed all that, the problem disappear. Old session file in /tmp also contribute to
the problem as well.
BTW, the last time I checked, CVS version 4.06 in late April still have the problem.
---
[2001-05-08 19:26:01] [EMAIL PROTECTED]
Is this fairly reproducible?
If it is, any chance you could build Apache with debug information (--enable-debug in
configure), attach to an offending process (gdb /path/to/httpd ), and run a
backtrace ('bt')?
---
[2001-05-07 12:44:51] [EMAIL PROTECTED]
marking critical for php 4.0.6
---
[2001-04-14 09:00:57] [EMAIL PROTECTED]
I found the problem. since the script I use have a lot of include and require
statement. just a script include a bunch of files and keep reloading the page will
kill the server in no time. I attach a sample config file I usually include, just
make a test.php and include this file like 10 times to simulate a lot of include
files. And then, just keep reloading test.php. You should see the script take a lot
of CPU time and eventually the httpd eat all the CPU time and the process hang. From
command "top", one of the httpd process keep eating up CPU time.
The following is the sample config file
http://www.test.net/";;
// Cookie Setting
$config[cookie_path] = "/"; # web root directory
$config[CookieURL] = ".test.net";
$config[cookieTTL] = 7200; // in seconds
$config[minpass]= 3; # Minimum user password length in characters
/* language and locale */
$config[language] = "english";# [english] english, [big5] BIG5 code
$config[locale] = "english";# Used for translation of date-related stuff
/* story control */
$config[commentmax] = 4096;
$config[abstractlen]= 4996; #length of abstract show on first page
$config[icon_width] = 100; # Topic icons width
$config[timezone] = "HKT"; #Time zone
$config[limitnews] = 10; # default number of stories per page
$config[older_story_num]= 10; # number of older stories to display
$config[anon_users] = 0; # 1 to allow anonymous postings
# 0 to disable
/* theme control */
$config[def_theme] = "Main"; # name of default theme (see themes/ directory for
list)
/* mail settings */
$config[use_fake_email] = 1; # Displays fake email addresses for users instead of the
real ones
$config[notifyEmail]= "[EMAIL PROTECTED]"; #address where you want to
receive notice
//$config[CensorList] =
array('fuck','cunt','fucker','fucking','pussy','cock','c0ck','cum','bitch','shit');
$config[CensorList] = array("/fuck/s","/fuck/s","/fuck/s",
"/[a-z]*fuck[a-z]*/is",
"/[a-z]*cunt[a-z]*/is",
"/[a-z]*pussy[a-z]*/is",
"/[a-z]*cock[a-z]*/is",
"/[a-z]*c0ck[a-z]*/is",
[PHP-DEV] Bug #10575 Updated: installation of 4.0.5 as apxs module broke xbithack apache option
ID: 10575 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Apache related Operating system: PHP Version: 4.0.5 Assigned To: Comments: Unable to reproduce (xbithack works fine with the current CVS, and there haven't been any changes in that code for a while). Jani - were you able to reproduce it? Previous Comments: --- [2001-05-14 07:13:13] [EMAIL PROTECTED] This is confirmed. Must be fixed before 4.0.6!! --- [2001-05-10 10:27:36] [EMAIL PROTECTED] Yes. It works. I have downgraded. --- [2001-05-10 05:05:15] [EMAIL PROTECTED] Did it work with 4.0.4pl1? --Jani --- [2001-05-01 06:59:48] [EMAIL PROTECTED] installation of 4.0.5 as apxs module broke xbithack apache option --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10575&edit=2 -- 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 #3284 Updated: Add syntax extension to allow "htmlspecialchars($foo)" inside quoted strings
ID: 3284 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Feature/Change Request Operating system: PHP Version: 4.0 Assigned To: Comments: This is quite against the spirit of PHP - we don't want to add arbitrary modifiers that perform arbitrary/unexpected behavior. We could and probably should find a better name for htmlspecialchars() - perhaps to_html() or htmlize() or something along these lines. Previous Comments: --- [2001-05-20 23:57:44] [EMAIL PROTECTED] This looks cool... I vote for it! The syntax causes no broken things or whatever: currently, these syntaxes cause either parse-errors, or just print the $|foo literally, both not very likely to occur in current scripts ;) --- [2001-02-10 14:00:03] [EMAIL PROTECTED] refiling against 4.0. --- [2000-01-22 16:00:05] [EMAIL PROTECTED] This would be super, SUPER useful for everyone: a way to automatically expand (both in regular code AND in quoted strings): $|foo [where "|" might be some other special punctuation character; you decide what character would work best] to: htmlspecialchars($foo) Here's why. One of the most common bugs in CGI programming -- in PHP or any other language -- is constructs such as this: echo " "; In this case, "$foo" will be expanded. However, there's a serious problem here: if $foo contains any of the special characters (< > & "), those characters will NOT be escaped, and thus the resulting HTML is broken! The correct way to do this is the following mess: echo ""; This is a big pain in the neck. Basically, it means that the automatic expansion of variables inside quoted strings is WAY less useful than it would be otherwise. My proposed syntax extension would make this way, way easier. Here's how you would be able to write the above example: echo " "; This is MUCH cleaner. Also, this feature would encourage correct code, because without this feature, many programmers frequently forget to call htmlspecialchars() because of the convenience of relying on string-expansion. This extension would also help in other situations, such as these: // if $name == "A&J Market", some browsers // will not display what you want: echo "Company name: $name"; // This is WRONG! echo "Company name: $|name"; // This would be okay // if $email == "Joe Smith <[EMAIL PROTECTED]>", // most browsers will not display what you want: echo "Reply to $email"; // This is WRONG! echo "Reply to $|email"; // This would be okay Also, an example when escaping from HTML mode: Note that in any context, $|foo would be an r-value, NOT an l-value (that is, you can't assign to it or pass it by reference). For example, this is illegal: $|foo = "hi"; // illegal --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=3284&edit=2 -- 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 #11249 Updated: Long here files fail silently
ID: 11249 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.5 Assigned To: Comments: Where PHP reports its errors depends on the way you configure it. By default, an out-of-memory error would be trapped and reported to the standard output (browser). Depending on your configuration of error_reporting, this level of errors (E_ERROR) may not be reported at all, and depending on other configuration directives (display_errors, log_errors, etc.) it may or may not be displayed or logged. I made sure that this error is indeed properly reported with the default configuration, and as expected, it is. Previous Comments: --- [2001-06-01 22:35:53] [EMAIL PROTECTED] Given a large <<< here file (say a few thousand lines) and PHP 4.0.5 or current CVS versions, and a memory_limit set too low (in my case under 32Meg), trying to load the page will fail silently. The TCP connection will be dropped, no data will be returned and there will be no message filed in the system logs. Bad. There should at least be a log entry on such failure. J C Lawrence --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11249&edit=2 -- 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 #11449 Updated: it is not possible to declare a static variable variable
ID: 11449
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Previous Comments:
---
[2001-06-12 20:23:22] [EMAIL PROTECTED]
this script produces a parse error:
function test(){
$a="a";
static $$a;
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11449&edit=2
--
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 #11449 Updated: it is not possible to declare a static variable variable
ID: 11449
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Static variables are a 'feature' of the function, and are declared in compile-time.
Since it's impossible to know their name in compile-time, it's not possible to use
varying expression as the static variable name.
Previous Comments:
---
[2001-06-12 20:23:22] [EMAIL PROTECTED]
this script produces a parse error:
function test(){
$a="a";
static $$a;
}
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11449&edit=2
--
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 #11344 Updated: Memory not being reused.
ID: 11344
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0 Latest CVS (2001-06-08)
Assigned To:
Comments:
Could you try to build PHP with fast_cache disabled and see what happens?
Edit Zend/zend_fast_cache.h, and change
# define ZEND_ENABLE_FAST_CACHE 1
to
# define ZEND_ENABLE_FAST_CACHE 0
Previous Comments:
---
[2001-06-08 00:52:36] [EMAIL PROTECTED]
This is a follow up of sorts to: http://www.php.net/bugs.php?id=8889
I have been running some tests that do simple things to see what happens with the
memory PHP uses in scripts.
The simplest of these tests was a page with no PHP on it other than the code that
logged the process memory usage:
$PHP_PID = exec("echo $PPID");
$fp=fopen("/www/logs/user_log.20010607", "a");
fputs($fp, "memusaget$PHP_PID,".exec("ps -v -p $PHP_PID | awk '{print
$8}'").",".time().",$HTTP_HOST,$REQUEST_URIn");
fclose($fp);
I got interesting results. Although the growth of the process was small, it was
obvoius that the memory was growing. Here is some sample data:
PID MEM TIME
3019 3272 991952835
3019 3420 991952835
3019 3428 991952836
3019 3448 991952836
3019 3480 991952837
3019 3488 991952838
3019 3500 991952839
3019 3504 991952840
3019 3516 991952899
3019 3520 991952843
3019 3520 991952844
3019 3524 991952847
3019 3524 991952851
3019 3524 991952854
3019 3524 991952858
3019 3524 991952862
3019 3532 991952868
3019 3532 991952910
3019 3544 991952879
3019 3552 991952888
As I said it is not a large growth, but it is there.
Now here is a script that creates an array over and over:
for($x=0;$x<1000;$x++){
$arr[]=str_repeat("r", $x);
}
plus the code above that writes the log. Here are the results:
PID MEM TIME
7322 3272 991953793
7322 3420 991953794
7322 3428 991953794
7322 3448 991953795
7322 3480 991953796
7322 3488 991953797
7322 3500 991953797
7322 3504 991953799
7322 3520 991953800
7322 3520 991953804
7322 3524 991953806
7322 3524 991953808
7322 3524 991953813
7322 3524 991953816
7322 3524 991953820
7322 3532 991953825
7322 3544 991953832
7322 3568 991953851
7322 3572 991953841
7322 3584 991953862
Again, a gradual growth occurs. Now, we put this into our production environment
where we are running applications and we end up with:
PIDMEMTIME
31655 2656 991953822
31655 3124 991953826
31655 4012 991953833
31655 4560 991953839
31655 4956 991953858
31655 5020 991953877
31655 5256 991953879
31655 5312 991953880
31655 5348 991953889
31655 5900 991953903
31655 6132 991953904
31655 6392 991953904
31655 6664 991953917
31655 6944 991953933
31655 7204 991953938
31655 7256 991953940
31655 7556 991953941
31655 8404 991953943
31655 8548 991953950
31655 8692 991953968
31655 8880 991953976
31655 8880 991953981
31655 9148 991953990
31655 9400 991953992
31655 9608 991953994
31655 9608 991954006
31655 9788 991954021
31655 10156 991954023
31655 10424 991954029
Is there any explanation for any of this? I can live with PHP keeping and REUSING
memory, but I don't want to have to think about how much memory my scripts take up
because it never gets a)reused or b) returned to the system. If I wanted to worry
about that stuff I would write in Perl or C.
Brian.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11344&edit=2
--
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 #11432 Updated: crash when restoring references to objects
ID: 11432
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Old-Bug Type: Scripting Engine problem
Bug Type: *Session related
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Reclassifying (I don't think it can be reproduced with 'pure scripting' alone, so it's
probably a session module bug
Previous Comments:
---
[2001-06-12 13:40:40] [EMAIL PROTECTED]
reproduced with 4.0.6RC3
---
[2001-06-12 08:29:39] [EMAIL PROTECTED]
Here are two scripts that operates on referenced objects. make.php creates object $b
with reference to object $a as argument.
After serialize/unserialize show.php checks if the reference still exists.
PHP 4.0.1pl1 lost references.
PHP 4.0.4pl1 segfaults on show.php
PHP 4.0.5segfaults on show.php and(!) sometimes on make.php
Config line:
./configure --with-pgsql=shared --with-apxs --sysconfdir=/etc --prefix=/usr
--localstatedir =/var --with-config-file-path=/etc/httpd/conf/
--with-gettext=/usr/share/gettext
make.php:
arg_b = &$a;
}
};
session_start();
session_destroy();
session_register("b");
session_register("a");
$a = new ClassA();
$a -> arg_a = 4;
$b = new ClassB($a);
echo "done. Click here";
?>
show.php:
arg_b = &$a;
}
};
session_start();
$a -> arg_a = 6;
echo $b -> arg_b -> arg_a;
?>
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11432&edit=2
--
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 #11326 Updated: Troubles with nested include()'s (bug #9673 revisited)
ID: 11326
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Just to see that I understand correctly, will the following userland function solve
the problem?
function my_include($file)
{
$orig_dir = getcwd();
chdir(dirname($file));
$retval = include("./".basename($file));
chdir($orig_dir);
return $retval;
}
If so, you can simply use this solution in the meantime. We may want to change PHP to
use this behavior, but if we do, it'd have to happen in a major version, because it's
a major change.
Previous Comments:
---
[2001-06-14 14:33:30] [EMAIL PROTECTED]
*OOPS* After submitting this bug, the next day I realized
my argument flaw about what I called "the server side
path" (which is actually the client side path, as
[EMAIL PROTECTED] pointed out). Please disregard it, I
don't know what I was thinking ;-)
However, I still stand very firm on the idea that php
needs to change its implementation of included files.
---
[2001-06-13 17:26:48] [EMAIL PROTECTED]
Without addressing the server-side issues, I'll point out
why the client side ones are almost certain not to change.
[PHP-DEV] Bug #11590 Updated: Segmentation fault when using an empty string as an array
ID: 11590
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Reproducible crash
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
Should be fixed in the latest CVS (and probably merged into 4.0.6).
Thanks for the report!
Previous Comments:
---
[2001-06-20 22:54:03] [EMAIL PROTECTED]
Crashes with current cvs for me too - needs to be fixed
---
[2001-06-20 17:41:49] [EMAIL PROTECTED]
- Linux 2.4.4 i686 / PHP 4.0.7-dev (21.05.01) / Apache
2.0.19-dev (21.05.01) -- crashes too
- Linux 2.2.16-22 i686 / PHP 4.0.3pl1 / Apache 1.3.14 -- works
---
[2001-06-20 17:20:19] [EMAIL PROTECTED]
When i try this Script under FreeBSD 4.3-STABLE with PHP
4.0.5, and Apache 1.3.20 it run's without errors, or
segfaults...
---
[2001-06-20 17:13:37] [EMAIL PROTECTED]
Script:
parse($a);
}
function parse($string,$result="") {
for($i=0;$i<50;$i++) {
$result_[$i]["threadid"]=
$result[$i]["threadid"];
$result_[$i]["readcount"] =
$result[$i]["readcount"];
}
return $result_;
}
}
class test2 {
function output() {
echo "hi";
$test = new test;
return $test->call();
}
}
$test2 = new test2;
print_r($test2->output());
?>
And Apache crashes with a Segfault:
Wed Jun 20 23:12:17 2001] [notice] child pid 28682 exit
signal Segmentation fault (11)
[Wed Jun 20 23:12:47 2001] [notice] child pid 28692 exit
signal Segmentation fault (11)
Greetings Olli
---
[2001-06-20 16:54:03] [EMAIL PROTECTED]
Please include a complete but short script into this report
which demonstrates this problem.
---
The remainder of the comments for this report are too long. To view the rest of the
comments, please view the bug report online.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11590&edit=2
--
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 #9154 Updated: HTTPD Memory Utilization Spike
ID: 9154
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Performance problem
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Reassign status
Previous Comments:
---
[2001-05-08 19:25:33] [EMAIL PROTECTED]
Is this fairly reproducible?
If it is, any chance you could build Apache with debug information (--enable-debug in
configure), attach to an offending process (gdb /path/to/httpd ), and run a
backtrace ('bt')?
---
[2001-02-07 11:55:47] [EMAIL PROTECTED]
Using ezxmlrpc 1.0 library from ez systems to write web services. Ezxmlrpc uses the
qtdom option to process XML. Web services are reading from and writing to Postgres
7.0.3 database. Web services are working properly, but when they are called
repeatedly (anywhere from 6 to 25 times in a row), one of the httpd processes eats all
of the CPU and memory utilization spikes to over 100MB. PHP interpreter eventually
stops because max execution time of 30 secs is exceeded. Then, memory utilization for
that process drops back down to around 3MB.
I am using apache 1.3.14 and have php built as a DSO. I do not seem to get a core
dump, so I can not include a backtrace.
My configure line follows:
./configure --with-apxs=/usr/local/apache/bin/apxs --with-magic_quotes --with-dom
--with-qtdom --with-pgsql --enable-debug
I am classifying this as a performance problem, even though I know it is not. Don't
know how else to clasify it. I know this is not enough info to begin debugging this
problem. Can someone give me some tips on how I can narrow this down?
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=9154&edit=2
--
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 #11589 Updated: classes and includes
ID: 11589
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
This has been fixed in CVS (it will be a part of 4.0.7, 4.0.6 has already been
packaged).
Thanks for the report!
Previous Comments:
---
[2001-06-21 08:24:33] [EMAIL PROTECTED]
The bug exists in 4.0.6 RC3
---
[2001-06-20 14:59:26] [EMAIL PROTECTED]
First, my stripped down code that works:
make("whatever");
?>
now, when i remove the definition of class 'a' to another file and include
the file like this:
file1.php:
file2.php:
make("whatever");
?>
then i get message 'Warning: Missing argument 1 for make()' ... the code is same ...
but working differently. at least with my php 4.0.5. so i think this is a bug.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11589&edit=2
--
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 #10911 Updated: Accessing null string as array in loop causes infinite spooling.
ID: 10911 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.5 Assigned To: Comments: Fixed in the latest CVS. Thanks for the report! Previous Comments: --- [2001-06-05 17:31:04] [EMAIL PROTECTED] I noticed bug id #11218 is almost definately the same bug... the key is that we're accessing an array, looking for indexes where the whole layer of indexes is unset... http://www.php.net/bugs.php?id=11218 The submitter of bug 11218 said: >I just ran your test script on my system from the >command line. Obtained the same behavior you reported. >My system is NT 4.0 SP 6a, PHP 4.0.5. --- [2001-05-16 18:36:16] [EMAIL PROTECTED] Whoops I accidentally selected latest CVS when I should've said 4.0.5 --- [2001-05-16 18:28:54] [EMAIL PROTECTED] Accessing null string as array in loop causes infinite spooling. The following code causes php to loop forever. It appears a memory leak unsets the $i variable, although I'm not certain. If allowed to run long enough, error logs appear, such as: child pid 14467 exit signal Segmentation fault (11) FATAL: emalloc(): Unable to allocate 1313818981 bytes Output is as follows HTTP/1.1 200 OK Date: Wed, 16 May 2001 22:20:07 GMT Server: Apache/1.3.19 (Unix) mod_ssl/2.8.3 OpenSSL/0.9.6a Connection: close Content-Type: text/html 1.. 2.. .. .. .. .. After that, it repeats forever... --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10911&edit=2 -- 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 #11218 Updated: isset() inside for() loops can crash
ID: 11218
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.5
Assigned To:
Comments:
I was unable to reproduce that problem, however, I did fix bug #10911 which appears to
be based on the same issue. Can you please test the latest CVS and see whether it
solves your problem (note, this fix may not be a part of 4.0.6, since 4.0.6 has
already been packaged; It'll definitely be in 4.0.7)
Previous Comments:
---
[2001-06-05 17:20:08] [EMAIL PROTECTED]
Bug 10911, http://www.php.net/bugs.php?id=10911, was brought to my attention. Both my
report above and this other one may be based on the same bug.
---
[2001-05-31 12:33:40] [EMAIL PROTECTED]
in for ';
if ( isset($Col['SC']['hide']) ) {
echo 'in if';
}
}
}
Test(__FILE__,__LINE__);
# NOW, funny things happen if I change the number of times
# the for loop runs...
# $Counter < 1...
# Everything is fine.
# $Counter < 2...
# Dr Watson notifys of PHP crash, hit OK
# (SeeDr Watson report at end of this posting.)
# Text is displayed in browser.
# PHP no longer running.
# $Counter < 3...
# Nothing returned to browser.
# No Dr Watson reports.
# PHP won't stop executing, takes up 99% of processor time.
# Can't "End Process" in Task Manger.
# Doesn't stop after max execution time.
# Need to reboot to kill PHP process.
#
# Though, if I execute from command line...
# winds up in same infinite loop, but I can
# kill the PHP process from the task manager.
# So, if that's not strange enough, altering the
# test code in small ways eliminates the problem...
# remove if / isset segment...
# okay
/*
function Test($FileName, $FileLine, $Opt='', $Col='') {
for ($Counter = 0; $Counter < 3; $Counter++) {
echo 'in for ';
}
}
Test(__FILE__,__LINE__);
*/
# put the if / isset segment back
# BUT remove the for loop
# okay
/*
function Test($FileName, $FileLine, $Opt='', $Col='') {
if ( isset($Col['SC']['hide']) ) {
echo 'in if';
}
}
Test(__FILE__,__LINE__);
*/
# put the for loop back
# BUT do isset on a single dimensional array...
# okay
/*
function Test($FileName, $FileLine, $Opt='', $Col='') {
for ($Counter = 0; $Counter < 3; $Counter++) {
echo 'in for ';
if ( isset($Col['SC']) ) {
echo 'in if';
}
}
}
Test(__FILE__,__LINE__);
*/
# perform tasks outside a function.
# okay
/*
for ($Counter = 0; $Counter < 3; $Counter++) {
echo 'in for ';
if ( isset($Col['SC']['hide']) ) {
echo 'in if';
}
}
*/
# set the array before running function
# okay
/*
$Var['SC']['hide'] = 'y';
function Test($FileName, $FileLine, $Opt='', $Col='') {
for ($Counter = 0; $Counter < 3; $Counter++) {
echo 'in for ';
if ( isset($Col['SC']['hide']) ) {
echo 'in if';
}
}
}
Test(__FILE__,__LINE__,'',$Var);
*/
# Set a single dimensional array,
# though continue to perform isset on a two dimensional
# Doesn't crash
# --> _BUT_ the "if isset()" test comes out as TRUE
# --> even when it's actually FALSE!
/*
unset($Var);
$Var['SC'] = 'y';
function Test($FileName, $FileLine, $Opt='', $Col='') {
for ($Counter = 0; $Counter < 3; $Counter++) {
echo 'in for ';
if ( isset($Col['SC']['hide']) ) {
echo 'in if';
}
}
}
Test(__FILE__,__LINE__,'',$Var);
*/
# Set variable to a string...
# okay
/*
$Var = 'y';
function Test($FileName, $FileLine, $Opt='', $Col='') {
for ($Counter = 0; $Counter < 3; $Counter++) {
echo 'in for ';
if ( isset($Col['SC']['hide']) ) {
echo 'in if';
}
}
}
Test(__FILE__,__LINE__,'',$Var);
*/
/*
Application exception occurred:
App: (pid=212)
When: 5/31/2001 @ 11:59:23.314
Exception number: c005 (access violation)
*> S
[PHP-DEV] Bug #11476 Updated: Weird random chars are generated in the script!
ID: 11476 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.6RC3 Assigned To: Comments: I managed to reproduce it (and cut it down to 7 lines, take that as a challenge ;) No fix yet, though - it's a bit of a complex issue. Previous Comments: --- [2001-06-14 20:23:18] [EMAIL PROTECTED] Here's the GDB backtrace I got: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (runnable)] 0x400de1c1 in __kill () from /lib/libc.so.6 (gdb) bt #0 0x400de1c1 in __kill () from /lib/libc.so.6 #1 0x40693cf6 in _emalloc (size=1515870813, __zend_filename=0x40a4bfc8 "zend_operators.c", __zend_lineno=1028, __zend_orig_filename=0x0, __zend_orig_lineno=0) at zend_alloc.c:163 #2 0x406af10b in concat_function (result=0xbfffdfec, op1=0x80e51c4, op2=0xbfffd638) at zend_operators.c:1028 #3 0x4069e735 in execute (op_array=0x8304dec) at ./zend_execute.c:1015 #4 0x406b33b0 in zend_execute_scripts (type=8, file_count=3) at zend.c:752 #5 0x406cbdb3 in php_execute_script (primary_file=0xb56c) at main.c:1206 #6 0x406c713e in apache_php_module_main (r=0x830fe2c, display_source_mode=0) at sapi_apache.c:89 #7 0x406c7ee9 in send_php (r=0x830fe2c, display_source_mode=0, filename=0x83118f4 "/www/apache/htdocs/11476.php") at mod_php4.c:536 #8 0x406c7f32 in send_parsed_php (r=0x830fe2c) at mod_php4.c:547 #9 0x80554f9 in ap_invoke_handler () at md4.c:255 #10 0x806a44f in process_request_internal () at md4.c:255 #11 0x806a4ba in ap_process_request () at md4.c:255 #12 0x8061306 in child_main () at md4.c:255 #13 0x80614e1 in make_child () at md4.c:255 #14 0x806165c in startup_children () at md4.c:255 #15 0x8061ccc in standalone_main () at md4.c:255 #16 0x806251c in main () at md4.c:255 #17 0x400d6c03 in __libc_start_main (main=0x8062164 , argc=2, argv=0xb81c, init=0x804f3e0 <_init>, fini=0x8099f94 <_fini>, rtld_fini=0x4000bbc0 <_dl_fini>, stack_end=0xb814) at ../sysdeps/generic/libc-start.c:92 --- [2001-06-14 04:28:03] [EMAIL PROTECTED] When I generate some hex-color code the outcome is fare from expected. The best way to explain it would be by an example: http://www.edimag.dk/bug/backup_index.php and the source: http://www.edimag.dk/bug/backup_index.phps My compile command: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql=/usr' '--enable-trans-sid' '--with-gd' '--with-pdflib=/usr/local' '--with-ttf' '--with-sybase=/usr/local/freetds/' '--with-jpeg' (Update 2001-06-14: I tried it on a Linux 2.2.5 with PHP 4.0.4pl1 installed with the same error) /watson --- [2001-06-14 00:44:46] [EMAIL PROTECTED] Reproduced under 4.0.6RC3. I get segfault with this. --- [2001-06-13 19:35:23] [EMAIL PROTECTED] When I generate some hex-color code the outcome is fare from expected. The best way to explain it would be by an example: http://www.edimag.dk/bug/backup_index.php and the source: http://www.edimag.dk/bug/backup_index.phps My compile command: './configure' '--with-apxs=/usr/local/apache/bin/apxs' '--with-mysql=/usr' '--enable-trans-sid' '--with-gd' '--with-pdflib=/usr/local' '--with-ttf' '--with-sybase=/usr/local/freetds/' '--with-jpeg' /watson --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11476&edit=2 -- 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 #11676 Updated: A few apache children consume all memory and CPU.
ID: 11676 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Closed Status: Open Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0 Latest CVS (2001-06-25) Assigned To: Comments: Ignore the last comment, wrong bug report :) Previous Comments: --- [2001-06-26 14:31:52] [EMAIL PROTECTED] Output buffering indeed cannot be used inside output handler functions. However, the code that handled that error situation contained a bug that caused PHP to enter an infinite loop. This bug is now fixed (although the limitation of not being able to use output buffering inside output handlers still applies) --- [2001-06-26 07:32:26] [EMAIL PROTECTED] Well, the problem is that we have many virtual hosts on that server, each using it's own log file... I can confirm that the gdb trace for ALL the many dead process, which are in running state, gives the three lines: #0 0x4012c23e in chunk_free () #1 0x4012bfaa in __cfree () #2 0x80fbcbf in shutdown_memory_manager () (it happened this morning too) Is there some way to know which script was executing just before the child died, please tell me! --- [2001-06-26 07:04:06] [EMAIL PROTECTED] It would help a lot to track this down if you could find out if this happens by running some script. --- [2001-06-25 17:40:15] [EMAIL PROTECTED] I'm using php 4.0.7-dev (downloaded from the CVS tree), Apache 1.3.20 on a P3 600 1 Gig RAM. After some hours that the server is running, in no particularly loaded confdition, CPU and memory utilization grows abnormally, making the server unusable. "top" shows that 4 o 5 httpd processes are eating 20% CPU each, and are all in "running" state. I managed to attach a gdb to one of these processes, and here's the result: Attaching to program `/usr/local/apache/bin/httpd', Pid 21784 Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_compat.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. 0x4012c23e in chunk_free () (gdb) bt #0 0x4012c23e in chunk_free () #1 0x4012bfaa in __cfree () #2 0x80fbcbf in shutdown_memory_manager () This is all I get. I saw MANY MANY bug reports with similarities to this one in the db. The only solution is stopping and restarting apache. In apache's error_log i get many lines with "child xxx still did not exit...sending a SIGTERM" and "child xxx still did not exit...sending a SIGKILL" as soon as i stop it. Let me know if I can make something to help you out more! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11676&edit=2 -- 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 #11678 Updated: ob_get_contents in ob_start() callback causes infinite loop
ID: 11678
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating system:
PHP Version: 4.0.4pl1
Assigned To:
Comments:
Output buffering indeed cannot be used inside output handler functions. However, the
code that handled that error situation contained a bug that caused PHP to enter an
infinite loop. This bug is now fixed (although the limitation of not being able to
use output buffering inside output handlers still applies)
Previous Comments:
---
[2001-06-25 20:57:06] [EMAIL PROTECTED]
The occurrence of $baz should be $bar in function my_callback (this doesn't change the
bug, just points out my mad typ1ng skillz, etc.).
---
[2001-06-25 20:54:06] [EMAIL PROTECTED]
SCRIPT:
ob_start("my_callback");
echo "foon";
ob_end_flush();
function my_callback($buffer)
{
ob_start();
echo "barn";
$bar = ob_get_contents();
ob_end_clean();
$buffer .= $baz;
}
BEHAVIOR:
PHP (static command-line, or as an Apache module) goes
into some sort of loop (I can guess which sort, see below)
and begins sucking CPU like a cyber-hooker.
CONFIGURE:
'./configure' '--prefix=/d/test_make/php'
'--with-config-file-path=/d/test_make/php'
'--with-apache=/home/rick/corengine-2.0.1pre1/src/apache_1.3.12'
'--with-mysql=/usr'
Looks to me like some sort of scoping/context issue (can't
start a new buffer inside the callback) -- in the callback
ob_start is getting called but when ob_end_clean is
called I'd guess that the state (the callback == "my_callback") has not been properly
restricted to the
enclosing buffering (does that sentence parse?) and the
callback from the outer buffering is applied to the inner.
When that happens... infinite loop (and depending upon how
it's implemented it may not even be grabbing stack space
which would make it truly a CPU-sucker).
Why did this come up?
I had some object functionality with a "render" method
which simply printed out its output. I moved a system to
using buffered output and found that it would be more
efficient to call the object->render() method after the
buffering was done (with a search & replace) since I then
had more information and could do less computation. So,
rather than rewrite the render method to return its output
I decided to nest a buffer and just capture the output (the
render method delegates to other objects which makes buffering even more attractive in
this case). Since the
best time to capture the buffer is when I'm cleaning up the
other one... boom I hit this bug.
I currently do not have PHP > 4.0.4pl1 installed so this
bug may be present in later releases I just haven't been
able to check yet.
---
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=11678&edit=2
--
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 #11676 Updated: A few apache children consume all memory and CPU.
ID: 11676 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0 Latest CVS (2001-06-25) Assigned To: Comments: Output buffering indeed cannot be used inside output handler functions. However, the code that handled that error situation contained a bug that caused PHP to enter an infinite loop. This bug is now fixed (although the limitation of not being able to use output buffering inside output handlers still applies) Previous Comments: --- [2001-06-26 07:32:26] [EMAIL PROTECTED] Well, the problem is that we have many virtual hosts on that server, each using it's own log file... I can confirm that the gdb trace for ALL the many dead process, which are in running state, gives the three lines: #0 0x4012c23e in chunk_free () #1 0x4012bfaa in __cfree () #2 0x80fbcbf in shutdown_memory_manager () (it happened this morning too) Is there some way to know which script was executing just before the child died, please tell me! --- [2001-06-26 07:04:06] [EMAIL PROTECTED] It would help a lot to track this down if you could find out if this happens by running some script. --- [2001-06-25 17:40:15] [EMAIL PROTECTED] I'm using php 4.0.7-dev (downloaded from the CVS tree), Apache 1.3.20 on a P3 600 1 Gig RAM. After some hours that the server is running, in no particularly loaded confdition, CPU and memory utilization grows abnormally, making the server unusable. "top" shows that 4 o 5 httpd processes are eating 20% CPU each, and are all in "running" state. I managed to attach a gdb to one of these processes, and here's the result: Attaching to program `/usr/local/apache/bin/httpd', Pid 21784 Reading symbols from /lib/libpam.so.0...done. Reading symbols from /lib/libdl.so.2...done. Reading symbols from /lib/libcrypt.so.1...done. Reading symbols from /lib/libresolv.so.2...done. Reading symbols from /lib/libm.so.6...done. Reading symbols from /lib/libnsl.so.1...done. Reading symbols from /lib/libdb.so.3...done. Reading symbols from /lib/libc.so.6...done. Reading symbols from /lib/ld-linux.so.2...done. Reading symbols from /lib/libnss_compat.so.2...done. Reading symbols from /lib/libnss_files.so.2...done. 0x4012c23e in chunk_free () (gdb) bt #0 0x4012c23e in chunk_free () #1 0x4012bfaa in __cfree () #2 0x80fbcbf in shutdown_memory_manager () This is all I get. I saw MANY MANY bug reports with similarities to this one in the db. The only solution is stopping and restarting apache. In apache's error_log i get many lines with "child xxx still did not exit...sending a SIGTERM" and "child xxx still did not exit...sending a SIGKILL" as soon as i stop it. Let me know if I can make something to help you out more! --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11676&edit=2 -- 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 #11685 Updated: Bad Auto-Cast
ID: 11685 Updated by: zeev Reported By: Hot Soon<[EMAIL PROTECTED]> Old-Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.6 Assigned To: jeroen Comments: Fixed in the latest CVS (will be fixed in 4.0.7) Previous Comments: --- [2001-06-26 07:55:20] [EMAIL PROTECTED] Indeed, +, -, and * 'autocasting' doesn't work in negative direction, only positive. --- [2001-06-26 01:30:13] Hot Soon<[EMAIL PROTECTED]> Just run this program: It will print out "int(0)". but I believe it should print out"int(-2147483648)" or "float(-2147483648)" like this program: --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11685&edit=2 -- 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 #11673 Updated: UNC paths not working when used in include_path
ID: 11673 Updated by: zeev Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: Scripting Engine problem Operating system: PHP Version: 4.0.6 Assigned To: Comments: Should be fixed in the latest CVS (will be a part of 4.0.7) - thanks for the report! Previous Comments: --- [2001-06-25 14:12:27] [EMAIL PROTECTED] Using a UNC path in as the home directory under IIS 5.0 and Windows 2000 Server using the PHP ISAPI module does not seem to work. If I set the Network Directory to "\naswebcustomer" I get the following error from PHP: Warning: Failed opening '\naswebcustomerindex.php' for inclusion If I map a drive then there is not a problem opening the file but drives are not mapped until a user logs in so this cannot be used on the web server. Also, in the php.ini file, if I use include_dir = "\nasinetpubphpinclude" or include_dir = "\\nas\inetpub\phpinclude" both give the error that the included files cannot be found. If I use include_dir = "//nas/inetpub/phpinclude" then there is no problem. Also, if I run the php.exe program with a UNC path it does not work, but if I map a drive then all is well. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11673&edit=2 -- 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 #11823 Updated: bad constructor name for IT_Error class
ID: 11823 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Reproducible crash Operating System: FreeBSD-4.1 PHP Version: 4.0 Latest CVS (2001-07-01) New Comment: Fixed in the latest CVS. Thanks for reporting! Previous Comments: [2001-07-01 10:20:27] [EMAIL PROTECTED] In pear/HTML/IT_Error.php, it's defined IT_Error class. In this class, class name is 'IT_Error', but constructor name is 'Cache_Error()'. ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=11823&edit=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 #11806 Updated: Using $string = md5($string); crashed HTTP child processes
ID: 11806
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: Reproducible crash
Operating System: Linux 2.2.16
PHP Version: 4.0.6
Assigned To: derick
New Comment:
This should be fixed in the latest CVS - please let me know if the problem still
occurs.
Previous Comments:
[2001-07-01 12:14:57] [EMAIL PROTECTED]
Derick,
Thanks I did not think to check there this time. I see the following, even with the
the $cipher = md5() and CleanString functions disabled:
[Sun Jul 1 09:11:55 2001] Script: '/home/nerdwww/compose.php'
---
mcrypt.c(1322) : Block 0x08429258 status:
Beginning: OK (allocated on mcrypt.c:1252, 24 bytes)
End: Overflown (magic=0x35653364 instead of 0x2A8FCC84)
At least 4 bytes overflown
---
Here are the calls I make using mcrypt outside of the compose.php script you have
already seen:
http://www.nerdnet.com/functions.phps
Thanks again!
Joe
[2001-07-01 06:45:31] [EMAIL PROTECTED]
Hello,
with debug enabled, do you see any errors in either your httpd errorlog or in
/var/log/zenderrors ?
Derick
[2001-06-30 21:52:11] [EMAIL PROTECTED]
Update:
I have compiled php-4.0.6 with --enable-debug to try and get a backtrace, but when I
do, the bug vanishes and the same code no longer crashed my httpd child process..
Here is some detailed info:
PHP 4.0.6 config line:
./configure --with-mysql --with-gd --enable-track-vars --with-jpeg-dir=/usr/local/lib
--enable-bcmath --with-apache=../apache_1.3.20 --enable-ftp --enable-sockets
--with-mcrypt --enable-debug
and for Apache 1.3.20
EAPI_MM="../mm-1.1.3" \
SSL_BASE="../openssl-0.9.6a" \
./configure \
"--enable-module=ssl" \
"--with-layout=RedHat" \
"--activate-module=src/modules/php4/libphp4.a" \
"--enable-module=rewrite" \
The script that is causing this error is:
http://www.nerdnet.com/compose.phps
As you can see, a use submits a form, which is the source of $cipher, an alphanumeric
string, which is then encrypted and other actions take place after.
I am not using the Zend Optimizer or anything unusual here at all... If I run the
httpd thru gdb and reproduce the crash it gives me an error in
shutdown_memory_manager() when it crashes, but not much else since the bug disappears
when I compile in debug into PHP... If any more info is needed let me know... Thanks
PHP team, you guys rule!!!
Joe
[2001-06-30 05:10:11] [EMAIL PROTECTED]
Can you please post your script as .txt file on the web, so that I can check how the
$cipher is generated?
And is it possibly for you to make a backtrace of this crash
(http://www.php.net/bugs-generating-backtrace.php) as I couldn't reproduce it.
Derick
[2001-06-29 14:04:25] [EMAIL PROTECTED]
PHP Options:
'./configure' '--with-mysql' '--with-gd' '--enable-track-vars'
'--with-jpeg-dir=/usr/local/lib' '--enable-bcmath' '--with-apache=../apache_1.3.20'
'--enable-ftp' '--enable-sockets' '--with-mcrypt'
The problem I am having is:
When using the code:
$cipher = md5($cipher); httpd crashes the current child process with:
[Fri Jun 29 10:54:49 2001] [notice] child pid 9766 exit signal Segmentation fault (11)
[Fri Jun 29 10:54:50 2001] [notice] child pid 9920 exit signal Segmentation fault (11)
The page then fails to load, returning nothing to the browser.
Also, I have another function called CleanSring($string); which looks like:
function CleanString($string)
{
$string = strip_tags($string);
$string =
preg_replace("/<\/?(html|head|meta|title|body|font|img|.jpg|.gif|.vbs|script|tr|table|text).*>/","",$string);
$string =
preg_replace("/<\/?(HTML|HEAD|META|TITLE|BODY|FONT|IMG|.JPG|.GIF|.VBS|SCRIPT|TR|TABLE|TEXT).*>/","",$string);
$string = preg_replace("/<[^>]*>/","",$string);
return $string;
}
Calling this function like:
$string = CleanString($string); causes the same problem.
Whats weird is I call md5() again below the problem code:
$now = date("r");
$thisID = md5(substr(makeID(), 0, 16));
$onetimepass = substr(md5($thisID), 0, 8);
And neither of these causes the same problem, even when being used in the same
document.
-
[PHP-DEV] Bug #12008 Updated: mysql_fetch_* inconsistent with MySQL C API
ID: 12008 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: RedHat 6.2 PHP Version: 4.0.6 New Comment: fetch_array, in recent versions (4.0.6 inclusive) should actrually populate NULL values in the array. Are you sure you tested it with 4.0.6? How did you arrive to the conlusion they're not there? Previous Comments: [2001-07-10 09:08:13] [EMAIL PROTECTED] The handling of NULL values in mysql_fetch_* function seems to be inconsistent with MySQL C API: in C, mysql_fetch_row() would put nil values in the row array if corresponding value in the select statement is NULL. In PHP it seems, as dicussed on mysql_fetch_array() page, the NULL values would not be stored in the array at all. This poses some problems when migrating from C to PHP. Would it be possible to introduce another function that would be consistent with MySQL C API? ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=12008&edit=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 #7730 Updated: unresolved text symbol (s) during final link (php creation)
ID: 7730 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Scripting Engine problem Operating System: IRIX 6.5 (6.5.8m) PHP Version: 4.0.3pl1 Assigned To: zeev New Comment: C doesn't really have a standard inline declaration (well, the old standard doesn't, C9X does, but I don't think it's supported by all compilers yet). At any rate, I'll take the opportunity to remove the inline declaration from some of the functions. Jani - BTW - it's not just a Zend problem :) Previous Comments: [2001-05-23 06:17:23] [EMAIL PROTECTED] Zend problem. [2000-11-09 12:03:32] [EMAIL PROTECTED] With mipsPRO 7.2.1 (the C++/C IRIX compiler) it is not possible to declare a function in an header, define this as an __inline in a module (please use the standard C inline declaration instead of a very dangerous #define inline ) and use the same in another module (this is only possible with some rad which see and compile all code in one step). I experienced some unresolved symbols due to bad inlining policy. Following there is a list of removed inline (this is neither a definitive list, cos i do not configure all modules, nor the better one, but simply the list of my personal fixes which let me successfully link my first php executable): ext/standard/scanf.c(1233, scan_set_error_return) Zend/zend_API.c(186, _array_init) Zend/zend_API.c(199, _object_init_ex) Zend/zend_API.c(217, _object_init) Zend/zend_API.c(230, add_assoc_long) Zend/zend_API.c(242, add_assoc_unset) Zend/zend_API.c(252, add_assoc_bool) Zend/zend_API.c(276, add_assoc_double) Zend/zend_API.c(288, add_assoc_string) Zend/zend_API.c(305, add_assoc_stringl) Zend/zend_API.c(322, add_index_long) Zend/zend_API.c(334, add_index_unset) Zend/zend_API.c(345, add_index_bool) Zend/zend_API.c(369, add_index_double) Zend/zend_API.c(381, add_index_string) Zend/zend_API.c(398, add_index_stringl) Zend/zend_API.c(415, add_next_index_long) Zend/zend_API.c(427, add_next_index_unset) Zend/zend_API.c(474, add_next_index_string) Zend/zend_API.c(491, add_next_index_stringl) Zend/zend_API.c(542, add_get_index_long) Zend/zend_API.c(566, add_get_index_string) Zend/zend_API.c(632, add_property_resource) Zend/zend_API.c(656, add_property_string) Zend/zend_API.c(673, add_property_stringl) Zend/zend_variables.c(36, var_reset) Zend/zend_ptr_stack.c(35, zend_ptr_stack_push) Zend/zend_ptr_stack.c(82, zend_ptr_stack_pop) ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7730&edit=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 #7730 Updated: unresolved text symbol (s) during final link (php creation)
ID: 7730 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Open Bug Type: Scripting Engine problem Operating System: IRIX 6.5 (6.5.8m) PHP Version: 4.0.3pl1 Old Assigned To: zeev Assigned To: Previous Comments: [2001-05-23 06:17:23] [EMAIL PROTECTED] Zend problem. [2000-11-09 12:03:32] [EMAIL PROTECTED] With mipsPRO 7.2.1 (the C++/C IRIX compiler) it is not possible to declare a function in an header, define this as an __inline in a module (please use the standard C inline declaration instead of a very dangerous #define inline ) and use the same in another module (this is only possible with some rad which see and compile all code in one step). I experienced some unresolved symbols due to bad inlining policy. Following there is a list of removed inline (this is neither a definitive list, cos i do not configure all modules, nor the better one, but simply the list of my personal fixes which let me successfully link my first php executable): ext/standard/scanf.c(1233, scan_set_error_return) Zend/zend_API.c(186, _array_init) Zend/zend_API.c(199, _object_init_ex) Zend/zend_API.c(217, _object_init) Zend/zend_API.c(230, add_assoc_long) Zend/zend_API.c(242, add_assoc_unset) Zend/zend_API.c(252, add_assoc_bool) Zend/zend_API.c(276, add_assoc_double) Zend/zend_API.c(288, add_assoc_string) Zend/zend_API.c(305, add_assoc_stringl) Zend/zend_API.c(322, add_index_long) Zend/zend_API.c(334, add_index_unset) Zend/zend_API.c(345, add_index_bool) Zend/zend_API.c(369, add_index_double) Zend/zend_API.c(381, add_index_string) Zend/zend_API.c(398, add_index_stringl) Zend/zend_API.c(415, add_next_index_long) Zend/zend_API.c(427, add_next_index_unset) Zend/zend_API.c(474, add_next_index_string) Zend/zend_API.c(491, add_next_index_stringl) Zend/zend_API.c(542, add_get_index_long) Zend/zend_API.c(566, add_get_index_string) Zend/zend_API.c(632, add_property_resource) Zend/zend_API.c(656, add_property_string) Zend/zend_API.c(673, add_property_stringl) Zend/zend_variables.c(36, var_reset) Zend/zend_ptr_stack.c(35, zend_ptr_stack_push) Zend/zend_ptr_stack.c(82, zend_ptr_stack_pop) ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=7730&edit=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 #12049 Updated: Crash in Zend Engine
ID: 12049
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status:
Status: Analyzed
Bug Type: Reproducible crash
Operating System: Debian GNU/Linux
PHP Version: 4.0.6
New Comment:
The code snippet you supplied doesn't work - it dies with
Fatal error: Call to undefined function: zoom() in test.php on line
9
test.php(9) : Fatal error - Call to undefined function: zoom()
At any rate - the backtrace appears to suggest you have some endless recursive call.
This is most probably the problem.
Previous Comments:
[2001-07-11 10:32:12] [EMAIL PROTECTED]
This code reproduces the crash:
class A{}
class B extends A {}
class D extends C
{
function zoom()
{
return (parent::zoom());
}
}
class E extends D {}
class C extends B
{
function C()
{
$this->x = 5;
}
}
class Storage
{
var $items;
function Storage()
{
$this->items=array();
}
function add()
{
$foo = new E();
$this->items[] = $foo;
end($this->items);
return key($this->items);
}
function get($who)
{
return $this->items[$who];
}
}
$Store = new Storage();
$ID = $Store->add();
$Obj = $Store->get($ID);
//Segfaults here
$Obj->zoom();
[2001-07-11 09:28:48] [EMAIL PROTECTED]
PHP is crashing on a call to an object method. Currently,
the code is too complex to paste here. Will try to create
simpler example. Here's a gdb backtrace:
# gdb /usr/sbin/apache.dbg
GNU gdb 19990928
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show
warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) run -X
Starting program: /usr/sbin/apache.dbg -X
Program received signal SIGSEGV, Segmentation fault.
0x40267713 in execute (op_array=0x8237f04) at
../../Zend/zend_execute.c:1140
1140
zend_fetch_var_address(&opline->result, &opline->op1,
&opline->op2, Ts, BP_VAR_W ELS_CC);
(gdb) bt
#0 0x40267713 in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1140
#1 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#2 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#3 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#4 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#5 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#6 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#7 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#8 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#9 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#10 0x40269f0f in execute (op_array=0x8237f04)
at ../../Zend/zend_execute.c:1544
#11 0x40269f0f in execute (op_array=0x8237f04)
---Type to continue, or q to quit---q
at ../../Zend/zend_execute.c:1544Quit
(gdb) p opline
$1 = (zend_op *) 0x823de5c
(gdb) p *optline
$2 = {opcode = 83 'S', result = {op_type = 4, u = {constant
= {value = {
lval = 0, dval = 0, str = {val = 0x0, len = 0}, ht
= 0x0, obj = {
ce = 0x0, properties = 0x0}}, type = 0 '\000',
is_ref = 0 '\000',
refcount = 0}, var = 0, opline_num = 0, fetch_type = 0,
op_array = 0x0, EA = {var = 0, type = 0}}}, op1 =
{op_type = 1, u = {
constant = {value = {lval = 136544148, dval =
1.0677440727493824e-313,
str = {val = 0x8237f94 "other", len = 5}, ht =
0x8237f94, obj = {
ce = 0x8237f94, properties = 0x5}}, type = 3
'\003',
is_ref = 1 '\001', refcount = 2}, var = 136544148,
opline_num = 136544148, fetch_type = 136544148,
op_array = 0x8237f94,
EA = {var = 136544148, type = 5}}}, op2 = {op_type =
8, u = {constant = {
value = {lval = 1, dval = 4.9406564584124654e-324,
str = {
val = 0x1 , len = 0},
ht = 0x1, obj = {
ce = 0x1, properties = 0x0}}, type = 0 '\000',
is_ref = 0 '\000',
refcount = 0}, var = 1, opline_num = 1, fetch_type = 1,
op_array = 0x1, EA = {var = 1, type = 0}}},
extended_value = 0,
lineno = 1056}
(gdb)
ATTENTION! Do NOT reply to t
[PHP-DEV] Bug #11008 Updated: exit() should return an exit status if passed, not send to stdout
ID: 11008 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.0 Latest CVS (2001-05-21) New Comment: Simply put - no, it should not. exit's optional argument is a termination message, not a shell status. Previous Comments: [2001-05-23 11:24:22] [EMAIL PROTECTED] Anyone in the Zend core want to comment on this? I know where the code is that does it. But it is in the Zend code. Is there a good reason to put this exit status to stdout? [2001-05-22 01:59:53] [EMAIL PROTECTED] indeed it does both: if php; then echo yes; fi X-Powered-By: PHP/4.0.5 Content-type: text/html 0yes if php; then echo yes; fi X-Powered-By: PHP/4.0.5 Content-type: text/html 1 i don't see a real reason for the echoed exit status though [2001-05-21 21:34:23] [EMAIL PROTECTED] Working with a shell script here. I hoped that exit() would work like perl and return the passed status as and exist status. As it stands now, it sends it to stdout. This is unexpected. It would be much more useful if exit() could be used to enable the use of PHP in shell scripts by returning the passed value as an exit status. Edit this bug report at http://bugs.php.net/?id=11008&edit=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 #11447 Updated: Switch statement sensible for white-space
ID: 11447
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Linux (RedHat 6.2)
PHP Version: 4.0.4pl1
New Comment:
Spaces are indeed significant. Here's why.
Is equivalent to
The two spaces outside the PHP blocks are a valid two character HTML block!
Whereas:
is equivalent to:
which is valid.
Vlad was wrong, the bug is not valid :)
Previous Comments:
[2001-06-19 17:16:53] [EMAIL PROTECTED]
Observe that the spaces are significant.
This doesn't work:
This does!:
I suppose that the interpreter converts text outside to echo statements, so that
the first code block is equivalent to:
This code block gave the same parse error as the first one!
(Expecting T_CASE or T_DEFAULT or '}')
[2001-06-19 12:29:47] [EMAIL PROTECTED]
The bug is valid - if you close and reopen the PHP tags between the switch and the
case statement, it is going to bark at you. It shouldn't.
This does not work:
This does:
Why in the world would anyone do that, is a whole other issue, still they probably
expect to be able to do just that. If they can't, we either need to document it as
such, (thus re-classify this as documentation problem) or fix it. I do not know what
it takes to fix that, but it is a valid report nevertheless.
Unbogusifying...
[2001-06-13 14:58:29] [EMAIL PROTECTED]
Which style I use, the "classical" style (using {}) or the "alternative" style (using
: and endswitch), doesn't matter; the problem is the same.
Sniper's comment about using several times is surely justified when having
one-line code as in his example, but when it comes to multi-line code, there is an
issue of readability. I think that script A below is easier to read than script B.
Don't you?
--- begin script A ---
Alpha
Beta
Default
--- end script A ---
--- begin script B ---
Alpha
Beta
Default
--- end script B ---
[2001-06-13 10:18:56] [EMAIL PROTECTED]
Use the {} instead of the : / endswitch;
ie.
Alpha
And anyway, using too much is really not good idea.
This is just stupid:
[2001-06-12 19:13:44] [EMAIL PROTECTED]
Section 7.4 in the FAQ is a little bit related.
Should perhaps the ending for a block of PHP-code be "?>" followed by any number of
white-space characters?
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=11447
Edit this bug report at http://bugs.php.net/?id=11447&edit=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 #10467 Updated: static array doesn't evaluate defined keys
ID: 10467
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Solaris
PHP Version: 4.0.4pl1
New Comment:
This is now fixed in CVS, and will be a part of 4.0.7. Thanks for the reproducing
script!
Previous Comments:
[2001-04-23 17:19:49] [EMAIL PROTECTED]
The following script doesn't work correctly. It should
print "My Message: Hello World\nArray ( [1] => Hello [2] =>
World )". Instead it prints "My Message: \nArray ( [FIRST]
=> Hello [SECOND] => World )".
"Hello", SECOND => "World");
print("My Message:". $myArray[FIRST] ." ".
$myArray[SECOND] ."\n");
print_r($myArray);
?>
Edit this bug report at http://bugs.php.net/?id=10467&edit=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 #11684 Updated: Header() causes PHP to hang
ID: 11684 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000/IIS4 PHP Version: 4.0.5 New Comment: Is anybody else able to reproduce this? I'm not. BTW, I assume you're using IIS 5... Previous Comments: [2001-06-25 22:58:17] [EMAIL PROTECTED] http://foo.com/bar.html";); ob_end_flush(); ?> Win2k/IIS4/CGI mode/Standard setup, standard modules + image modules calls to the header() function cause that instance of PHP to hang (infinite loop?). Timeout occurs 4 or 5 times longer than max_execution_time allows. Can continue to run scripts in a seperate browser session. Executable memory footprint is 4-5 MB. I have not been able to reproduce this on a Win98 machine with an identical PHP environment. [2001-06-25 22:55:02] [EMAIL PROTECTED] http://foo.com/bar.html";); ob_end_flush; ?> Win2k/IIS4/CGI mode/Standard setup, standard modules + image modules calls to the header() function cause that instance of PHP to hang (infinite loop?). Timeout occurs 4 or 5 times longer than max_execution_time allows. Can continue to run scripts in a seperate browser session. Executable memory footprint is 4-5 MB. I have not been able to reproduce this on a Win98 machine with an identical PHP environment. Edit this bug report at http://bugs.php.net/?id=11684&edit=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 #12157 Updated: copying a single quote from MS word causes form variable to disappear.
ID: 12157 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: red hat linux 6.1 PHP Version: 4.0.6 New Comment: Do you have a big script (but self-contained) that causes this problem? Without some kind of a reproducing script, we can't do much about it. Previous Comments: [2001-07-13 20:10:04] [EMAIL PROTECTED] When copying a single quote from MS Word into a form field, with Content-Type set as ISO-8859-1 will cause some random form variables to disappear on the submission page. I haven't been able to find a pattern to why this has happened. There are several pages where it happens consistently, and some that it doesn't happen on. The quote gets encoded as ’ when run through htmlspecialchars. Each page has several hidden fields a couple text fields and text areas. I couldn't write a small script to duplicate the problem. Edit this bug report at http://bugs.php.net/?id=12157&edit=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 #10721 Updated: odd output in create_function()
ID: 10721
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: Scripting Engine problem
Operating System: GNU/Linux
PHP Version: 4.0.6
Assigned To: jeroen
New Comment:
This odd character is quite intentional, and is there in order to ensure that any
functions created don't clash with user-defined functions. You can see in the code
that this extra NULL byte is accounted for and deliberately being added, it's not a
coincidence :)
Jereon - please don't submit this patch.
Previous Comments:
[2001-07-09 09:45:11] [EMAIL PROTECTED]
Fixed the patch, only waiting for it to get committed.
[2001-06-27 16:21:20] [EMAIL PROTECTED]
Any word on this? Still exists in 4.0.6.
[2001-05-07 23:10:15] [EMAIL PROTECTED]
An odd character seems to appear in the return value of
create_function() (which should be of 'lambda_x' format
where x is an integer). This character is causing eval() to
crap out when trying to evaluate the created function. Just
before the 'l' is a character that looks like Pi in the
browser. The only way I knew to find out what it was was to
urlencode() the return value and the strange character was
encoded to '%00'. I'm no C coder, but the changes below
seemed to fix things.
*** /tmp/zend_builtin_functions.c Mon May 7 22:09:45 2001
--- /usr/local/src/php-4.0.5/Zend/zend_builtin_functions.c Mon May 7 22:03:31
2001
***
*** 965,974
}
function_add_ref(func);
! function_name = (char *)
emalloc(sizeof("0lambda_")+MAX_LENGTH_OF_LONG);
do {
!
sprintf(function_name, "%clambda_%d", 0, ++EG(lambda_count));
function_name_length = strlen(function_name+1)+1;
} while (zend_hash_add(EG(function_table), function_name,
function_name_length+1, func, sizeof(zend_function),
NULL)==FAILURE);
zend_hash_del(EG(function_table), LAMBDA_TEMP_FUNCNAME,
sizeof(LAMBDA_TEMP_FUNCNAME));
--- 965,974
}
function_add_ref(func);
! function_name = (char *)
emalloc(sizeof("lambda_")+MAX_LENGTH_OF_LONG);
do {
!
sprintf(function_name, "lambda_%d", ++EG(lambda_count));
function_name_length = strlen(function_name+1)+1;
} while (zend_hash_add(EG(function_table), function_name,
function_name_length+1, func, sizeof(zend_function),
NULL)==FAILURE);
zend_hash_del(EG(function_table), LAMBDA_TEMP_FUNCNAME,
sizeof(LAMBDA_TEMP_FUNCNAME));
Edit this bug report at http://bugs.php.net/?id=10721&edit=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 #11511 Updated: _array_init and other functions are inlined
ID: 11511 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: IRIX 6.5.11 PHP Version: 4.0.5 New Comment: The inline issue has been fixed in the CVS. Previous Comments: [2001-06-18 14:38:40] [EMAIL PROTECTED] On the SGI it is defined as __inline with the 7.3.1.2m compilers (the latest). Just to get it up and running I edited the php_config.h to define it as empty. [2001-06-16 12:34:52] [EMAIL PROTECTED] Can you please check what is in your main/php_config.h for inline ? it should be defined as empty. [2001-06-16 12:02:26] [EMAIL PROTECTED] Reclassified as this is problem with Zend engine. [2001-06-15 20:59:22] [EMAIL PROTECTED] In the file Zend/zend_API.c _array_init and some other functions are declared as inline. Within the zend_API.h file some of the inlines are sort of "aliased" away making them non-inlined functions. #define array_init(arg) _array_init((arg) ZEND_FILE_LINE_CC) #define object_init(arg)_object_init((arg) ZEND_FILE_LINE_CC) #define object_init_ex(arg, ce) _object_init_ex((arg), (ce) ZEND_FILE_LINE_CC) ZEND_API int _array_init(zval *arg ZEND_FILE_LINE_DC); ZEND_API int _object_init(zval *arg ZEND_FILE_LINE_DC); ZEND_API int _object_init_ex(zval *arg, zend_class_entry *ce ZEND_FILE_LINE_DC); Since these functions are declared inline in the zend_API.c file no global symbol is made. These functions should be either be put in the header file or not declared as inlined. As a result, on IRIX, php is created missing these global symbols. I do not have a complete list of symbols as of yet. Please feel free to contact me for more information. Edit this bug report at http://bugs.php.net/?id=11511&edit=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 #11326 Updated: Troubles with nested include()'s (bug #9673 revisited)
ID: 11326
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Scripting Engine problem
Operating System: Debian GNU/Linux
PHP Version: 4.0.5
New Comment:
>From now on (CVS/4.0.7), include() will also look in the directory of the currently
>executing file. This should give you the functionality you asked for.
Previous Comments:
[2001-06-15 07:05:07] [EMAIL PROTECTED]
Just to see that I understand correctly, will the following userland function solve
the problem?
function my_include($file)
{
$orig_dir = getcwd();
chdir(dirname($file));
$retval = include("./".basename($file));
chdir($orig_dir);
return $retval;
}
If so, you can simply use this solution in the meantime. We may want to change PHP to
use this behavior, but if we do, it'd have to happen in a major version, because it's
a major change.
[2001-06-14 14:33:30] [EMAIL PROTECTED]
*OOPS* After submitting this bug, the next day I realized
my argument flaw about what I called "the server side
path" (which is actually the client side path, as
[EMAIL PROTECTED] pointed out). Please disregard it, I
don't know what I was thinking ;-)
However, I still stand very firm on the idea that php
needs to change its implementation of included files.
[2001-06-13 17:26:48] [EMAIL PROTECTED]
Without addressing the server-side issues, I'll point out
why the client side ones are almost certain not to change.
[PHP-DEV] Bug #10287 Updated: php parser error
ID: 10287 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: win nt + linux (debian) PHP Version: 4.0.4pl1 New Comment: This crash is fixed. Note, however, that it still doesn't behave in the way you seem to expect it to behave, due to precedence rules. if (list($ar1_val)=each($ar1)&&list($ar2_val)=each($ar2)) is equivalent to if (list($ar1_val) = (each($ar1)&&list($ar2_val)=each($ar2))) Previous Comments: [2001-04-11 08:25:06] [EMAIL PROTECTED] hi, i'm afraid i found (by chance :-) ) a parser error. look at this code: php simply hangs by parsing that (i tried it on both win and linux - last release, 4.0.4pl1). the cure is to add more parenthesis, like this: if((list($ar1_val)=each($ar1))&&(list($ar2_val)=each($ar2))) but anyway, php should not hang in the first case... bye Edit this bug report at http://bugs.php.net/?id=10287&edit=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 #9673 Updated: Relative paths in require(), require_once(), include(), include_once()
ID: 9673 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating System: RedHat Linux 7.0 PHP Version: 4.0.1pl2 New Comment: include() (and the other functions in its family) will now also look in the current executing file's directory, so this issue should be resolved. Previous Comments: [2001-03-15 10:09:07] [EMAIL PROTECTED] We are talking about all four functions here, not just include(). The resemblance of require() to the #include directive, as documented: The require() statement replaces itself with the specified file, much like the C preprocessor's #include works. If it's a "known issue", are there any plans to fix it? Thanks. [2001-03-15 09:08:11] [EMAIL PROTECTED] First, PHP include() is in no way related or was promised to relate to C preprocessor directives, so no wonder it behaves differently. Now, all relative pathes are resolved against the current directory of the including script (which is the directory where it's located). This is a known issue. Use include_pathes in the meantime. [2001-03-10 16:45:48] [EMAIL PROTECTED] Here is an example of how relative paths are currently resolved with cascading inclusions (command line is 'php /home/joe/a.php'): File '/home/joe/a.php': File '/home/joe/include/b.inc': File '/home/joe/include/c.inc': The way all four functions [require(), require_once(), include(), include_once()] resolve relative paths is counter-intuitive and unproductive with large directory structures, because some trickery is required to fix this problem. Not to mention that it hurts to see a different behavior from C-preprocessor #include directives. If you don't believe me, then see comments to the include() function... Edit this bug report at http://bugs.php.net/?id=9673&edit=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 #12193 Updated: nested loops using each don't work
ID: 12193
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Arrays related
Operating System: windows
PHP Version: 4.0.6
New Comment:
list() = each() is not a loop. each() is a simple function, that returns a key,value
pair, and advances the internal array pointer to the next pair. It has no idea it's
being used inside a loop, and thus, nothing makes this internal pointer go back to the
beginning of the array when the loop ends.
Solutions:
- Use foreach()
or
- Call reset() on the array at the end of the loop.
Previous Comments:
[2001-07-16 16:27:46] [EMAIL PROTECTED]
when tho loops using each are nested, the outer while loop stops after the first
iteration.
For instance, the output of the following script :
$outer=array("o1", "o2");
$inner=array("i1","i2");
while (list($o_index, $o) = each($outer))
while (list($i_index, $i) = each($inner))
echo $o, $i, "";
is
o1i1
o1i2
instead of
o1i1
o1i2
o2i1
o2i2
Edit this bug report at http://bugs.php.net/?id=12193&edit=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 #11970 Updated: SEPARATE_ZVAL_TO_MAKE_IS_REF doesn't like 0x0
ID: 11970
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: SuSE7.0
PHP Version: 4.0.6
New Comment:
My initial fix was bogus, as I misdiagnosed what was going on. The current fix is to
allow returning of plain variables only (i.e., you can return $arr[$key], but you
can't return @$arr[$key]). This means that your script will not work (it'll error
out), but won't crash either...
Previous Comments:
[2001-07-15 12:48:52] [EMAIL PROTECTED]
Fixed in CVS - thanks for the tiny reproducing script!
[2001-07-09 06:27:49] [EMAIL PROTECTED]
function &erm($key) {
return @$arr[$key];
}
$foo = erm('foo');
$bar = erm('bar');
(gdb) run bug3.php
Starting program: /usr/local/bin/php bug3.php
Program received signal SIGSEGV, Segmentation fault.
0x80a29e9 in execute (op_array=0x81d3348) at ./zend_execute.c:1592
1592 SEPARATE_ZVAL_TO_MAKE_IS_REF(retval_ptr_ptr);
(gdb) p retval_ptr_ptr
$1 = (zval **) 0x0
(gdb) bt
#0 0x80a29e9 in execute (op_array=0x81d3348) at ./zend_execute.c:1592
#1 0x80a26a8 in execute (op_array=0x81cdf5c) at ./zend_execute.c:1544
#2 0x8097234 in zend_execute_scripts (type=8, file_count=3) at zend.c:752
#3 0x8065b4f in php_execute_script (primary_file=0xb694) at main.c:1206
#4 0x8061173 in main (argc=2, argv=0xb724) at cgi_main.c:718
(gdb) list
1587(opline->op1.op_type != IS_CONST) &&
1588(opline->op1.op_type != IS_TMP_VAR)) {
1589
1590retval_ptr_ptr = get_zval_ptr_ptr(&opline->op1, Ts, BP_VAR_W);
1591
1592SEPARATE_ZVAL_TO_MAKE_IS_REF(retval_ptr_ptr);
1593
1594(*retval_ptr_ptr)->refcount++;
1595(*EG(return_value_ptr_ptr)) = (*retval_ptr_ptr);
1596 } else {
notice that the second call [ erm('bar')] actually trigger the segfault.
patch: I dunno, Zeev somebody? :)
Edit this bug report at http://bugs.php.net/?id=11970&edit=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 #11970 Updated: SEPARATE_ZVAL_TO_MAKE_IS_REF doesn't like 0x0
ID: 11970
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Closed
Status: Open
Bug Type: Scripting Engine problem
Operating System: SuSE7.0
PHP Version: 4.0.6
New Comment:
The fixes so far were bad; They were reverted, and this bug is no reopened.
Previous Comments:
[2001-07-19 12:05:04] [EMAIL PROTECTED]
My initial fix was bogus, as I misdiagnosed what was going on. The current fix is to
allow returning of plain variables only (i.e., you can return $arr[$key], but you
can't return @$arr[$key]). This means that your script will not work (it'll error
out), but won't crash either...
[2001-07-15 12:48:52] [EMAIL PROTECTED]
Fixed in CVS - thanks for the tiny reproducing script!
[2001-07-09 06:27:49] [EMAIL PROTECTED]
function &erm($key) {
return @$arr[$key];
}
$foo = erm('foo');
$bar = erm('bar');
(gdb) run bug3.php
Starting program: /usr/local/bin/php bug3.php
Program received signal SIGSEGV, Segmentation fault.
0x80a29e9 in execute (op_array=0x81d3348) at ./zend_execute.c:1592
1592 SEPARATE_ZVAL_TO_MAKE_IS_REF(retval_ptr_ptr);
(gdb) p retval_ptr_ptr
$1 = (zval **) 0x0
(gdb) bt
#0 0x80a29e9 in execute (op_array=0x81d3348) at ./zend_execute.c:1592
#1 0x80a26a8 in execute (op_array=0x81cdf5c) at ./zend_execute.c:1544
#2 0x8097234 in zend_execute_scripts (type=8, file_count=3) at zend.c:752
#3 0x8065b4f in php_execute_script (primary_file=0xb694) at main.c:1206
#4 0x8061173 in main (argc=2, argv=0xb724) at cgi_main.c:718
(gdb) list
1587(opline->op1.op_type != IS_CONST) &&
1588(opline->op1.op_type != IS_TMP_VAR)) {
1589
1590retval_ptr_ptr = get_zval_ptr_ptr(&opline->op1, Ts, BP_VAR_W);
1591
1592SEPARATE_ZVAL_TO_MAKE_IS_REF(retval_ptr_ptr);
1593
1594(*retval_ptr_ptr)->refcount++;
1595(*EG(return_value_ptr_ptr)) = (*retval_ptr_ptr);
1596 } else {
notice that the second call [ erm('bar')] actually trigger the segfault.
patch: I dunno, Zeev somebody? :)
Edit this bug report at http://bugs.php.net/?id=11970&edit=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 #11990 Updated: defined constants getting corrupted
ID: 11990
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: RedHat Linux 6.2
PHP Version: 4.0.5, 4.0.6
New Comment:
Fixed in the CVS!
Previous Comments:
[2001-07-17 12:33:59] [EMAIL PROTECTED]
free -m reports 251MB total on our production box, and 125MB on my dev box. If it is
running out of memory, a more gracelful handling of it is necessary...
[2001-07-17 12:27:58] [EMAIL PROTECTED]
I get a crash too, but in different place. I fear it might be just you getting out of
memory. The script like this has pretty aggressive memory requirements. How much
memory do you have?
[2001-07-16 19:08:56] [EMAIL PROTECTED]
I've spent a better part of the last week trying to dig into this problem.
What I've come up with is rather interesting. The source of the problem
seems to be that after the first request handled by an Apache child
process, PHP doesn't properly clean up, and much of the memory space is
polluted. I don't know enough about the Zend internals to be able to
figure out exactly happens, but I've deduced that after the first request
handled by a process, some defines (entries in the zend_constants hash
table) already have some data associated with them. When
zend_register_constant() is called, it finds data for a given key and
doesn't reassign it. Typically, when a process starts having problems
with defines, it segfaults after processing the script.
The following is a snippet from /var/log/httpd/error_log with the patch below
applied:
[11074] Registering string constant HREF_SEC_BASE:
https://webtech13.hq.insight.com/web
[11074] Constant HREF_SEC_BASE already defined: gnome-terminal
[11074] Constant href_sec_base already defined
[11074] Beginning compare of data
[11074] data1: https://webtech13.hq.insight.com/web
[11074] pData(...).val: gnome-terminal
[11074] *** Match failed! Data for HREF_SEC_BASE corrupted!
As the script is invoked, HREF_SEC_BASE already has (bad) data, in this case
"gnome-terminal".
diff -urb php-4.0.6.orig/Zend/zend_constants.c php-4.0.6/Zend/zend_constants.c
--- php-4.0.6.orig/Zend/zend_constants.cSun Feb 25 22:43:26 2001
+++ php-4.0.6/Zend/zend_constants.c Mon Jul 16 13:29:21 2001
@@ -23,7 +23,7 @@
#include "zend_variables.h"
#include "zend_operators.h"
#include "zend_globals.h"
-
+#include
void free_zend_constant(zend_constant *c)
{
@@ -243,17 +243,82 @@
{
char *lowercase_name = zend_strndup(c->name, c->name_len);
int ret = SUCCESS;
+zend_constant *pData = NULL;
+char *data1 = NULL;
+int data1_len;
#if 0
printf("Registering constant for module %d\n",c->module_number);
#endif
zend_str_tolower(lowercase_name, c->name_len);
+
+switch(c->value.type) {
+case IS_STRING:
+data1_len = c->value.value.str.len;
+data1 = zend_strndup(c->value.value.str.val, data1_len);
+
+fprintf(stderr, "[%d] Registering string constant %s: %s\n",
+getpid(), c->name, c->value.value.str.val);
+
+if(zend_hash_find(EG(zend_constants), lowercase_name, c->name_len, (void
+*)&pData) == SUCCESS) {
+fprintf(stderr, "[%d] Constant %s already defined: %s\n",
+getpid(),
+c->name,
+pData->value.value.str.val);
+
+pData = NULL;
+}
+break;
+
+default:
+if(zend_hash_find(EG(zend_constants), lowercase_name, c->name_len, (void
+*)&pData) == SUCCESS) {
+fprintf(stderr, "[%d] Constant %s already defined\n",
+getpid(),
+c->name);
+
+pData = NULL;
+}
+break;
+}
+
if (zend_hash_add(EG(zend_constants), lowercase_name, c->name_len, (void *) c,
sizeof(zend_constant), NULL)==FAILURE) {
zval_dtor(&c->value);
zend_error(E_NOTICE,"Constant %s already defined",lowercase_name);
ret = FAILURE;
}
+
+// retrieve data and compare data
+if(c->value.type == IS_STRING) {
+if(data1 != NULL) {
+if(zend_hash_find(EG(zend_constants), lowercase_name, c->name_len, (void
+*)&pData) == SUCCESS) {
+// compare data
+fprintf(stderr, "[%d] Beginning compare of data\n", getpid());
+fprintf(stderr, "[%d] data1:
[PHP-DEV] Bug #11990 Updated: defined constants getting corrupted
ID: 11990
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Scripting Engine problem
Operating System: RedHat Linux 6.2
PHP Version: 4.0.5, 4.0.6
New Comment:
BTW, the crash had nothing to do with the test case, which was causing an
out-of-memory problem. It's not very possible to handle this situation, other than
enabling memory_limit.
Previous Comments:
[2001-07-20 10:17:20] [EMAIL PROTECTED]
Fixed in the CVS!
[2001-07-17 12:33:59] [EMAIL PROTECTED]
free -m reports 251MB total on our production box, and 125MB on my dev box. If it is
running out of memory, a more gracelful handling of it is necessary...
[2001-07-17 12:27:58] [EMAIL PROTECTED]
I get a crash too, but in different place. I fear it might be just you getting out of
memory. The script like this has pretty aggressive memory requirements. How much
memory do you have?
[2001-07-16 19:08:56] [EMAIL PROTECTED]
I've spent a better part of the last week trying to dig into this problem.
What I've come up with is rather interesting. The source of the problem
seems to be that after the first request handled by an Apache child
process, PHP doesn't properly clean up, and much of the memory space is
polluted. I don't know enough about the Zend internals to be able to
figure out exactly happens, but I've deduced that after the first request
handled by a process, some defines (entries in the zend_constants hash
table) already have some data associated with them. When
zend_register_constant() is called, it finds data for a given key and
doesn't reassign it. Typically, when a process starts having problems
with defines, it segfaults after processing the script.
The following is a snippet from /var/log/httpd/error_log with the patch below
applied:
[11074] Registering string constant HREF_SEC_BASE:
https://webtech13.hq.insight.com/web
[11074] Constant HREF_SEC_BASE already defined: gnome-terminal
[11074] Constant href_sec_base already defined
[11074] Beginning compare of data
[11074] data1: https://webtech13.hq.insight.com/web
[11074] pData(...).val: gnome-terminal
[11074] *** Match failed! Data for HREF_SEC_BASE corrupted!
As the script is invoked, HREF_SEC_BASE already has (bad) data, in this case
"gnome-terminal".
diff -urb php-4.0.6.orig/Zend/zend_constants.c php-4.0.6/Zend/zend_constants.c
--- php-4.0.6.orig/Zend/zend_constants.cSun Feb 25 22:43:26 2001
+++ php-4.0.6/Zend/zend_constants.c Mon Jul 16 13:29:21 2001
@@ -23,7 +23,7 @@
#include "zend_variables.h"
#include "zend_operators.h"
#include "zend_globals.h"
-
+#include
void free_zend_constant(zend_constant *c)
{
@@ -243,17 +243,82 @@
{
char *lowercase_name = zend_strndup(c->name, c->name_len);
int ret = SUCCESS;
+zend_constant *pData = NULL;
+char *data1 = NULL;
+int data1_len;
#if 0
printf("Registering constant for module %d\n",c->module_number);
#endif
zend_str_tolower(lowercase_name, c->name_len);
+
+switch(c->value.type) {
+case IS_STRING:
+data1_len = c->value.value.str.len;
+data1 = zend_strndup(c->value.value.str.val, data1_len);
+
+fprintf(stderr, "[%d] Registering string constant %s: %s\n",
+getpid(), c->name, c->value.value.str.val);
+
+if(zend_hash_find(EG(zend_constants), lowercase_name, c->name_len, (void
+*)&pData) == SUCCESS) {
+fprintf(stderr, "[%d] Constant %s already defined: %s\n",
+getpid(),
+c->name,
+pData->value.value.str.val);
+
+pData = NULL;
+}
+break;
+
+default:
+if(zend_hash_find(EG(zend_constants), lowercase_name, c->name_len, (void
+*)&pData) == SUCCESS) {
+fprintf(stderr, "[%d] Constant %s already defined\n",
+getpid(),
+c->name);
+
+pData = NULL;
+}
+break;
+}
+
if (zend_hash_add(EG(zend_constants), lowercase_name, c->name_len, (void *) c,
sizeof(zend_constant), NULL)==FAILURE) {
zval_dtor(&c->value);
zend_error(E_NOTICE,"Constant %s already defined",lowercase_name);
ret = FAILURE;
}
+
+// retrieve data and compare data
+if(c->value.type == IS_STRING) {
+if(data1 != NULL) {
+if(zend_hash_find(EG(
[PHP-DEV] Bug #12270 Updated: php4ts.dll crashes due to null-pointer assignment on shutdown
ID: 12270
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Analyzed
Bug Type: Reproducible crash
Operating System: Win32
PHP Version: 4.0.6
New Comment:
The fix is not valid - p->pLast cannot be NULLif everything works right - i.e., the
bug is elsewhere.
Do you have a script that reproduces this problem (preferably with the CGI version of
PHP)?
Previous Comments:
[2001-07-20 03:02:45] [EMAIL PROTECTED]
The crash may be only reproducible in release builds with activated bcmath. (In debug
builds
the Zend efree() function returns prior actual freeing something, if the thread which
calls efree()
isn't the thread which original allocated the resource).
The "call stack" of this issue is:
php_module_shutdown_wrapper() // pi3web_sapi.c
php_module_shutdown() // main.c
zend_shutdown()// zend.c
zend_hash_destroy(&module_registry) // zend_hash.c
pefree(ht->arBuckets, ht->persistent) // zend_hash.c
...
PHP_MSHUTDOWN_FUNCTION(bcmath) // bcmath.c
bc_free_num (num) // init.c, the global bcnum value is _two_
efree ((*num)->n_ptr); // zend_alloc.c
In efree() the code in macro REMOVE_POINTER_FROM_LIST() crashes
#define REMOVE_POINTER_FROM_LIST(p) \
if (!p->persistent && p==AG(head)) {\
AG(head) = p->pNext;\
} else if (p->persistent && p==AG(phead)) { \
AG(phead) = p->pNext; \
} else {\
p->pLast->pNext = p->pNext; \
} \
if (p->pNext) { \
p->pNext->pLast = p->pLast; \
}
The reason of the crash is
} else {\
p->pLast->pNext = p->pNext; \
if the pointer pLast == NULL. This is true for the last allocated persistent
resource. This code is only called when bcmath performs shutdown,
because in other calls of efree() the condition p==AG(head) seems to
be always true.
A probable fix is:
} else if (p->pLast) { \
p->pLast->pNext = p->pNext; \
---
regards,
Holger Zimmermann
Edit this bug report at http://bugs.php.net/?id=12270&edit=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 #12198 Updated: Problem with recursive function - only works if I echo something in it
ID: 12198
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproducible crash
Operating System: WINDOWS NT
PHP Version: 4.0.6
New Comment:
Are you sure that when you print out something, does the script run all the way and
terminate properly? Printing may just give you a 'sign of life', but it may time-out
eventually still.
Previous Comments:
[2001-07-17 05:16:27] [EMAIL PROTECTED]
I've written this class to scan through a remote directory using FTP functions. A
recursive function is used to do the job, but it only works if I print something to
screen, else it hangs and the the script eventually times out.
Here's the code, notice the first line of function readDir():
class SiteScan {
var $_sSite;
var $_iPort;
var $_sUsername;
var $_sPassword;
var $_bDebug;
var $_aErrors;
//ftp
var $_iConnectionStream;
var $_sSystemType;
var $_aFileStructure;
function SiteScan($site='localhost',$u='Administrator',$p='',$port=21) {
//init connection
$this->_iPort = $port;
$this->_sSite = $site;
$this->_sUsername = $u;
$this->_sPassword = $p;
$this->_bDebug = true;
$this->_aErrors = array();
//try to obtein an ftp stream
if ($stream = ftp_connect($this->_sSite,$this->_iPort)) {
$this->_iConnectionStream = $stream;
//FileSystem successfully determined, now try to log in
if
(!ftp_login($this->_iConnectionStream,$this->_sUsername,$this->_sPassword)) {
$this->_aErrors[] = 'ERROR 002: Username ' .$this->_sUsername.
' and password ' .$this->_sPassword. ' rejected';
} else {
//connection successful! Now try to determine operating system
if (!$this->_sSystemType = ftp_systype($stream)) {
$this->_aErrors[] = 'ERROR 003: File system type could not
be determined';
}
}
} else {
$this->_aErrors[] = 'ERROR 001: Could not connect to ' .
$this->_sSite . ':' . $this->_iPort;
}
if ($this->_bDebug) {
$this->_onError();
}
}
function _analyseDir($aDirLine) {
$aDirInfo = array();
if(ereg("([-dl])[rwxst-]{9}",substr($aDirLine,0,10))) {
$this->_sSystemType = "UNIX";
}
if (substr($aDirLine,0,5) == "total") {
$aDirInfo[0] = -1;
} elseif ($this->_sSystemType == "Windows_NT") {
if (ereg("[-0-9]+ *[0-9:]+[PA]?M? + {10}(.*)",$aDirLine,$aRegExp)) {
$aDirInfo[0] = 1;
$aDirInfo[1] = 0;
$aDirInfo[2] = $aRegExp[1];
} elseif(ereg("[-0-9]+ *[0-9:]+[PA]?M? +([0-9]+)
(.*)",$aDirLine,$aRegExp)) {
$aDirInfo[0] = 0;
$aDirInfo[1] = $aRegExp[1];
$aDirInfo[2] = $aRegExp[2];
}
} elseif ($this->_sSystemType == "UNIX") {
if (ereg("([-d])[rwxst-]{9}.* ([0-9]*) [a-zA-Z]+ [0-9: ]*[0-9]
(.+)",$aDirLine,$aRegExp)) {
if ($aRegExp[1]=="d") $aDirInfo[0] = 1;
$aDirInfo[1] = $aRegExp[2];
$aDirInfo[2] = $aRegExp[3];
}
}
if (($aDirInfo[2] == ".") || ($aDirInfo[2] == "..")) {
$aDirInfo[0] = 0;
}
return $aDirInfo;
}
function readDir($sDir) {
//if this echo statement is removed, then the whole script hangs!!!
echo ' ';
//get an array of files from the base directory
$aDirList = ftp_rawlist($this->_iConnectionStream,"");
for ($iCount=0;$iCount_analyseDir($aDirList[$iCount]);
//if current file is a directory
if ($aDirInfo[0] == 1) {
$sNewDir = "$sDir/$aDirInfo[2]";
if (($aDirInfo[2] == "~") || (substr($aDirInfo[2],0,1) == " ")) {
$chdir=ftp_chdir($this->_iConnectionStream,$sNewDir);
} else {
$chdir=ftp_chdir($this->_iConnectionStream,$aDirInfo[2]);
}
$stop = 0;
if (!$stop && $chdir) {
$this->readDir($sNewDir);
}
if (!ftp_chdir($this->_iConnectionStream,$sDir)) {
ftp_cdup($this->_iConnectionStream);
[PHP-DEV] Bug #14136 Updated: Segfaults when forget xslt_free()
ID: 14136
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Status: Critical
Bug Type: Scripting Engine problem
Operating System: Debian/Linux
PHP Version: 4.0CVS-2001-11-20
New Comment:
Doesn't look like a Zend problem to me. Apparently the table ends up containing the
wrong entries (i.e., the same entry more than once) or, if the analysis is accurate,
then the dependencies aren't properly implemented, and a resource (the parser) is
freed prematurely.
Previous Comments:
[2001-11-20 07:34:40] [EMAIL PROTECTED]
Seems a Zend problem...
[2001-11-20 03:59:03] [EMAIL PROTECTED]
Tested this with php compiled as cgi.
Everything works ok when after doing transformation
you use xslt_free() in your script.
When you forget to do so php may segfault.
This happens when there were a scheme/sax handler defined
with object reference:
xslt_set_sax_handlers($xslt, array("characters" =>
array(&$this, "func")));
Now when php shuts down it calls free_processor() which
after some recursive *_ptr_dtor() and alike calls reaches
again free_processor() with same zval handle. Since
sablotron processor is already destroyed it eventually
comes to segfault.
This doesn't happen when ordinary function is used as
callback handler.
Backtrace:
#0 0x in ?? ()
#1 0x400d8432 in Situation::generateMessage
(this=0x81c4bb8, type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08,
arg2=@0xbfffedfc, theMessage=@0xbfffed70) at
situa.cpp:267
#2 0x400d8ae2 in Situation::message (this=0x81c4bb8,
type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08, arg2=@0xbfffedfc)
at situa.cpp:348
#3 0x400cfb63 in Processor::report (this=0x81c4c58,
S=@0x81c4bb8, type=MT_WARN, code=W1_HLR_NOT_REGISTERED,
arg1=@0xbfffee08,
arg2=@0xbfffedfc) at proc.cpp:991
#4 0x400ce583 in Processor::setHandler (this=0x81c4c58,
S=@0x81c4bb8, type=HLR_MESSAGE, handler=0x0, userData=0x0)
at proc.cpp:741
#5 0x400d1a8c in SablotUnregHandler
(processor_=0x81c4c58, type=HLR_MESSAGE, handler=0x0,
userData=0x0) at sablot.cpp:728
#6 0x0811adc1 in free_processor (rsrc=0x81c0a8c) at
sablot.c:613
#7 0x080c3a2a in list_entry_destructor (ptr=0x81c0a8c) at
zend_list.c:177
#8 0x080c128e in zend_hash_del_key_or_index
(ht=0x818dc44, arKey=0x0, nKeyLength=0, h=1, flag=1) at
zend_hash.c:512
#9 0x080c378b in _zend_list_delete (id=1) at
zend_list.c:56
#10 0x080d9581 in _zval_dtor (zvalue=0x81c4574,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:64
#11 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c0ad8,
__zend_filename=0x8149313 "zend_variables.c",
__zend_lineno=189)
at zend_execute_API.c:274
#12 0x080d98b4 in _zval_ptr_dtor_wrapper
(zval_ptr=0x81c0ad8) at zend_variables.c:189
#13 0x080c13ba in zend_hash_destroy (ht=0x81c101c) at
zend_hash.c:541
#14 0x080d9551 in _zval_dtor (zvalue=0x81c4a34,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:57
#15 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c0b90,
__zend_filename=0x8149313 "zend_variables.c",
__zend_lineno=189)
at zend_execute_API.c:274
#16 0x080d98b4 in _zval_ptr_dtor_wrapper
(zval_ptr=0x81c0b90) at zend_variables.c:189
#17 0x080c13ba in zend_hash_destroy (ht=0x81c0b24) at
zend_hash.c:541
#18 0x080d9521 in _zval_dtor (zvalue=0x81c0c5c,
__zend_filename=0x813d01c "zend_execute_API.c",
__zend_lineno=274)
at zend_variables.c:51
#19 0x080c66ab in _zval_ptr_dtor (zval_ptr=0x81c4b9c,
__zend_filename=0x81672fb "sablot.c", __zend_lineno=633)
at zend_execute_API.c:274
#20 0x0811b00e in free_processor (rsrc=0x81c0a8c) at
sablot.c:633
#21 0x080c3a2a in list_entry_destructor (ptr=0x81c0a8c) at
zend_list.c:177
#22 0x080c3c15 in zend_destroy_rsrc_list (ht=0x818dc44) at
zend_list.c:248
#23 0x080c64a7 in shutdown_executor () at
zend_execute_API.c:196
#24 0x080c8e36 in zend_deactivate () at zend.c:600
#25 0x080637cf in php_request_shutdown (dummy=0x0) at
main.c:736
#26 0x0805f023 in main (argc=2, argv=0xbb34) at
cgi_main.c:785
#27 0x401e965f in __libc_start_main () from /lib/libc.so.6
Edit this bug report at http://bugs.php.net/?id=14136&edit=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 #9884 Updated: Using a return in an included file causes a major abnormality.
ID: 9884 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Closed Status: Open Bug Type: Scripting Engine problem Operating System: NT/Freebsd PHP Version: 4.0.4pl1 New Comment: The fix was reverted, so the bug is reopened. We'll have to try and find a better solution, if one exists. Previous Comments: [2001-07-15 12:19:54] [EMAIL PROTECTED] Fixed in CVS [2001-03-29 07:00:18] [EMAIL PROTECTED] reopened - double function definition still there. [2001-03-29 06:26:35] [EMAIL PROTECTED] Using return stops _running_ the script. However, in PHP 4, scrips are _compiled_ in full before running. That means, all functions, which are defined on the compile stage, will be defined no matter what happened when the script was run. [2001-03-20 20:03:16] [EMAIL PROTECTED] in my stupidity, i spelt weird.inc wrong... but you guys are smart, so i'll assume you can correct it.. =) (sorry) [2001-03-20 20:00:01] [EMAIL PROTECTED] Sorry, i forgot to include the output of test.php, here' you go: output Hi From weird.inc... 1 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=9884 Edit this bug report at http://bugs.php.net/?id=9884&edit=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 #14474 Updated: Apache PHP Module cannot seem to handle large amounts of output
ID: 14474 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem Operating System: Windows XP Pro/Linux PHP Version: 4.1.0 New Comment: I don't think that our current analysis is correct. Take a look at the access log - I'm pretty sure you'd see that the page is being repeatedly requested by IE, and not requested only once. Something about the way the server disconnects may cause IE to think that the page was not properly fetched, and make it try to reload it. That would be my guess... Previous Comments: [2001-12-14 12:57:09] [EMAIL PROTECTED] I think this is critical [2001-12-12 20:33:45] [EMAIL PROTECTED] This problem reveals a memory limit bailout problem. Even if PHP exhsusted memory, script does not exit. PHP logs following logs many times. (Linux/PHP4.1.0, without output buffering) [13-Dec-2001 10:27:52] PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 10240 bytes) in /home/yohgaki/public_html/bugs/14474/bug.php on line 4 Type is changed to Scripting Engine Problem. [2001-12-12 19:28:49] [EMAIL PROTECTED] Note: this seems to be the same problem as #14222, but I can't seem to append stuff to someone elses bug so... This is something I first noticed when I upgraded from XP RC1 to WinXP Final, when using PHP 4.0.6. I upgraded to 4.1.0 today, and it doesn't solve the problem. The php apache module doesn't seem able to handle outputting moderate to large sized pages. I have been able to reliably reproduce the problem with the following script: "; } ?> Viewing this page with internet explorer causes it to go into an almost endless loop of relaoding the page. It will display the first few 'this line is number...' and then will reload the page over and over. On some sessions IE will eventually show it's 'The page cannot be displayed' page, and sometimes it will just reload indefinitly. Viewing this page with Mozilla/Netscape doesn't have the same effect. Mozilla doesn't go through the reload loop, but will not show the page as it should either. There will be unexplained (no errors) jumps in numbers/missing output such as: This is line number 2368 This is line number 2369This is line number 2517 This is line number 2518 But the errors in output don't occur in the same spot each time. And evenutally (well short of 1,000,000 lines) the output will just stop with no error, often in mid line. I have found that adding 'flush();' just after the 'print "This is line...' seems to fix the problem. Edit this bug report at http://bugs.php.net/?id=14474&edit=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 #14518 Updated: --enable-trans-id doesn't work
ID: 14518 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Session related Operating System: LInux 2.4.16 (RH7.2 based) PHP Version: 4.1.0 New Comment: Can anybody else reproduce this on *4.1.0*? Previous Comments: [2001-12-14 20:38:46] [EMAIL PROTECTED] Just note: I can not reproduce this with latest CVS. [2001-12-14 12:48:23] [EMAIL PROTECTED] I suppose you've verified problem ;) Type = Critical [2001-12-14 11:35:41] [EMAIL PROTECTED] I compiled php4.1.0 with --enable-trans-id, configured to use no cookies for sessions. Verifiying with phpinfo() shows the correct settings for cookies and enable-trans-id but php fails to add the session-id to any tag. Passing a session-id manually works though. Edit this bug report at http://bugs.php.net/?id=14518&edit=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 #14538 Updated: dirname fix broke behaviour that it had since PHP 3
ID: 14538
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: Unknown/Other Function
Operating System: Any
PHP Version: 4.1.0
New Comment:
Manuel,
This behavior is not going to change, and we're not going to introduce a new
headache-causing INI option to toggle this behavior.
If you really can't fix the code, you can create my_dirname() that wraps around
dirname, and returns "" if the result is "". Then, all you have to do is a
search&replace of dirname -> my_dirname.
You use this 'threat' of being accused in unprofessionalism a bit too often, in my
humble opinion :)
Previous Comments:
[2001-12-15 18:41:16] [EMAIL PROTECTED]
I was trying to test PHP 4.1.0 in a production site that I have that is made of large
code base and realized that dirname original behaviour was broken severely.
The site exists for more than 2 years and always relied on the behaviour that
dirname("/index.php") would return "" as it has been since PHP 3.
The site has 4.0.0 and was never upgraded since because I have this policy of not
installing minor versions to avoid spending a lot of time maintaining changes that are
caused by bugs that may have been introduced.
I investigated and it seems that in PHP 4.0.3, Andi fixed dirname so that
dirname("/index.php") now returns "/" instead of "" as before.
Although this should have been probably the original behaviour of the function, the
fact is that it wasn't not even in PHP 3 days.
My site heavily relies on this feature to let scripts realize in which directory they
are relatively to the server document root using dirname(GetEnv("SCRIPT_NAME")) . So,
my site is seriously broken because I use this everywhere in the site.
I talked with Andi and he is not willing to restore the original behaviour because the
fix was done more than 1 year ago.
So, I propose that some option be added to php.ini that lets developers restore the
original behaviour so that their sites don't break because of this change.
I also would like to recommend PHP developers to take more care when making these
changes that break the existing PHP code base of PHP users because many ISP are
refusing to upgrade to more recent versions because it breaks their clients PHP code
and they would be loosing business if they would upgrade to a newer version.
Please consider this proposal carefully to avoid being accused of unprofessionalism of
not assuring backwards compatibility of PHP functions behaviour.
Edit this bug report at http://bugs.php.net/?id=14538&edit=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 #14687 Updated: Ignoring @'s after set_error_handler() is used
ID: 14687 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Scripting Engine problem Operating System: Redhat 7.0, Solaris 7 PHP Version: 4.0.6 New Comment: It's the programmer's responsibility to honor error_reporting in the error handler. The error handler will be called even if the error that occured is not inside the error_reporting mask - to allow you to conduct logging, recovery, etc. You can easily honor it by using the return value of error_reporting(), and compare it (using &) with the error level that you got. Previous Comments: [2001-12-24 10:16:05] [EMAIL PROTECTED] This echos: 8 Yet according to: http://www.php.net/manual/en/function.set-error-handler.php "Of particular note is that this value will be 0 if the statement that caused the error was prepended by the @ error-control operator. " I've tried this on 4.0.4pl1 and 4.0.6 The changelog for 4.1.0 doesn't mention a fix. The @ works fine for lines executed before set_error_handler(). Here's one of the configure lines, though (to me) it doesn't seem likely to be a compiley issue... './configure' '--with-db' '--enable-dba' '--with-gdbm' '--with-xml' '--with-oci8=/usr/local/oracle/' '--with-apxs=/usr/local/apache-1.3.14/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-gd' '--with-sablot' Thanks! Edit this bug report at http://bugs.php.net/?id=14687&edit=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 #10437 Updated: casting is not consistent
ID: 10437 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Analyzed Status: Closed Bug Type: Scripting Engine problem Operating System: win2k PHP Version: 4.0.4pl1 New Comment: Fixed in the CVS (will be a part of 4.0.7). Thanks for the bug report! Previous Comments: [2001-05-19 17:42:44] [EMAIL PROTECTED] >From line 117 of zend_operators.c it says: If the string is nor an exact double, nor >an exact long, do strtol on it. There you should first try strtod, see if it parses more chars that strtol... And I don't know anything about C! [2001-05-19 17:22:30] [EMAIL PROTECTED] Strange indeed. There are explicit casts (either to double or to int) and implicit casts. You can view upon the latter one as a (number) cast, it casts to a number, maybe int, maybe float. In that cast strings like '5.31abc' are not detected as double, (invaled numbers after the dot) so integer parsing takes place, which yields the int 5. This should be corrected in Zend. [2001-04-22 04:06:03] [EMAIL PROTECTED] Casting is not consistent with doubles: $foo = "5.31abc"; $foo2 = (double) $foo; $foo3 = $foo + 0; The first gives 5.31 the second gives 5, although it should notice the full 5.31 number in the string. Edit this bug report at http://bugs.php.net/?id=10437&edit=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 #10263 Updated: Use of istdiostream w/o HAVE_CLASS_ISTDIOSTREAM protection
ID: 10263
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Assigned
Status: Closed
Bug Type: iPlanet related
Operating System: SGI IRIX 6.5.x
PHP Version: 4.0.4pl1
Assigned To: zeev
New Comment:
We no longer use C++ for the thread safe scanner, as of 4.0.7 (due out soon), so this
problem should be gone.
Previous Comments:
[2001-05-23 06:13:50] [EMAIL PROTECTED]
Assigning this to Zeev. He knows the Zend stuff best.
--Jani
[2001-04-10 12:00:43] [EMAIL PROTECTED]
I am trying to build the NSAPI module for use on SGI MIPS/IRIX hardware, using
SGI's MIPSpro compilers (we provide binaries in SGI's "inst" format on our
Freeware web site at http://freeware.sgi.com>). Since NSAPI is built
using the Zend Thread Safety enabled, some stdiostream code is included.
Configure is correctly determining that HAVE_STDIOSTREAM_H should be
defined (include file is found), and that HAVE_CLASS_ISTDIOSTREAM
should be undefined (no class istdiostream exists in the compiler version I am using).
This is correctly being done in the main/php_config.h file. In the source file
zend_language_scanner_cc.cc, there is a section which reads
#if defined(ZTS) && !defined(HAVE_CLASS_ISTDIOSTREAM)
class istdiostream : public istream
{
private:
stdiobuf _file;
public:
istdiostream (FILE* __f) : istream(), _file(__f) { init(&_file); }
stdiobuf* rdbuf()/* const */ { return &_file; }
};
#endif
so that later code in that file will correctly build and work when class istdiostream
is used.
In the source file zend_ini_scanner_cc.cc, though, the class istdiostream is
used in/around line 511, without the protection of HAVE_CLASS_ISTDIOSTREAM.
Since this class doesn't exist, the build fails.
I have been able to work around this by adding a section to the #ifdef ZTS
region starting in/around line 408:
#ifdef ZTS
# ifdef HAVE_STDIOSTR_H
# include
# endif
# ifdef HAVE_STDIOSTREAM_H
# include
# endif
# ifdef ZEND_WIN32
# include
# else
# include
# endif
/* new stuff starts here */
# ifndef HAVE_CLASS_ISTDIOSTREAM
class istdiostream : public istream
{
private:
stdiobuf _file;
public:
istdiostream (FILE* __f) : istream(), _file(__f) { init(&_file); }
stdiobuf* rdbuf()/* const */ { return &_file; }
};
# endif
/* ... and ends here */
#endif
After this change, the NSAPI module successfully builds---I haven't had
the chance to test it yet.
regards,
Steve Crockett
[EMAIL PROTECTED]
P.S. Is there a way to get information on the IRIX build of PHP into your manual?
Edit this bug report at http://bugs.php.net/?id=10263&edit=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 #6827 Updated: End of generated html is truncated on large page
ID: 6827 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: mSQL related Operating System: Sun Solaris 5.7 PHP Version: 4.0.2 Assigned To: zeev New Comment: Fixed in the CVS Previous Comments: [2000-12-13 10:29:04] [EMAIL PROTECTED] A backtrace of the crash, snapshot from yesterday. Program received signal SIGSEGV, Segmentation fault. zend_hash_find (ht=0x1bf5d0, arKey=0x0,nKeyLength=1,pData=0xffbec764) at zend_hash.c:852 852 zend_hash.c: No such file or directory. (gdb) bt #0 zend_hash_find (ht=0x1bf5d0, arKey=0x0, nKeyLength=1,pData=0xffbec764) at zend_hash.c:852 #1 0xf1ac4 in zend_fetch_dimension_address_inner () #2 0xe5828 in zend_fetch_dimension_address () #3 0xe8960 in execute () #4 0xedeb4 in execute () #5 0xb6bb0 in zend_execute_scripts (type=8, file_count=3) at zend.c:729 #6 0x33110 in php_execute_script (primary_file=0xffbef9e8) at main.c:1221 #7 0x31060 in main (argc=1, argv=0xffbefa74) at cgi_main.c:738 (gdb) [2000-12-12 18:31:09] [EMAIL PROTECTED] User feedback: --- I just downloaded and installed the latest snapshot - php 4.0.5-dev, and the result is the same - fails at the same location with a segmentation fault and core dump. Is it possible that there's an overflow of some sort created when msql_result gets a NULL value for a particular column? The NULL value in this case is retrieved much earlier than the point of failure, and that value is not used in the final piece of executed code. However, it does fail processing an msql_result loop when the row pointer is 0, so perhaps the previous msql_result with the NULL value caused an overflow that somehow affected a later msql_result even with a different table. There is another bug report of this, #7301 which is now marked as duplicate for this one. It has example scripts. --Jani [2000-12-07 11:40:38] [EMAIL PROTECTED] Assigning this to me as I'm trying to figure out this one.. --Jani [2000-11-03 20:26:53] [EMAIL PROTECTED] Does this still happen when using latest snapshot from snaps.php.net ?? (and without the optimizer) --Jani [2000-10-10 19:08:58] [EMAIL PROTECTED] User feedback: --- Sorry, but I'm unable to create a short script that reproduces the problem, but it continues to fail consistently when I use php4 to display information from certain rows in a database even though those same rows display fine with php3. I've looked them over and see no special characters or anything else to make the failing rows look unusual. In fact if I change 1 specific column from a NULL to any single character value, the script works fine with php4 as well. Other rows containing even more data display properly, but any row that has a NULL in that 1 specific column displays incorrectly at a point before the data from that column is referenced. If I try to reproduce just that small piece of the script in a test script, it works ok. Any other suggestions? - No suggestions at the moment. --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=6827 Edit this bug report at http://bugs.php.net/?id=6827&edit=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 #7301 Updated: Error in msql_result: reproducible
ID: 7301
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Duplicate
Status: Closed
Bug Type: mSQL related
Operating System: RedHat Linux 6.1
PHP Version: 4.0.3pl1
New Comment:
Fixed in the CVS
Previous Comments:
[2000-12-12 18:28:49] [EMAIL PROTECTED]
This is duplicate of #6827.
--Jani
[2000-10-20 13:22:25] [EMAIL PROTECTED]
I pared down the code and the data to the minium while
still getting the crash. Below is the code and the
msqldump. I think it is the NULL that is causing the
problem and not a blank entry.
Code:
---
";
$result_info = msql($database,$sql_info);
echo "DEBUG_result: $result_info";
$show_info = msql_result($result_info,0,"show_provider_info") ;
$this_provider = msql_result($result_info,0,"provider_serial_id") ;
echo msql_error();
echo "DEBUG: '$show_info', '$this_provider', '$aff'\n";
if ($i == 1) { //In this demo there are 3 entries
exit; //If it gets to the third($i=2) the
} //program crashes w/out fail.
if ($show_info == 1) { //CRASHES HERE
echo "HI";
}
$i++;
}
?>
--
---
Data in database:
#
# mSQL Dump
# Host: localhostDatabase: foobar
#
#
# Table structure for table 'events'
#
DROP TABLE events \g
CREATE TABLE events (
id CHAR(31),
ev_day DATE,
srttm CHAR(8),
endtm CHAR(8),
group_id INT,
typ CHAR(25),
aff CHAR(30),
title CHAR(30),
descr CHAR(200)
) \g
#
# Dumping data for table 'events'
#
INSERT INTO events VALUES ('940868200264760','18-Oct-2000','12:00 pm','1:00
pm',2,'Lunch','Slovak','Learn At Lunch','learn blah blah')\g
INSERT INTO events VALUES ('96463942510743346','18-Oct-2000','','',2,'Other
Event','Celebration Belle','Big Band Cruises','blah blah')\g
INSERT INTO events VALUES ('965228863119070','18-Oct-2000','','',2,'Other
Event','Celebration Belle','Daylong Cruise','blah blah')\g
#
# Table structure for table 'Providers'
#
DROP TABLE Providers \g
CREATE TABLE Providers (
provider_serial_id INT,
user_name CHAR(30),
provider_password CHAR(14),
provider_group_id INT,
provider_email CHAR(35),
permissions INT,
provider_address1 CHAR(30),
provider_address2 CHAR(30),
provider_city CHAR(20),
provider_state CHAR(2),
provider_zip CHAR(10),
provider_phone CHAR(12),
provider_url CHAR(33),
provider_info CHAR(200),
show_provider_info INT
) \g
CREATE UNIQUE INDEX idx_provider_id ON Providers (
provider_serial_id,
user_name
) \g
CREATE SEQUENCE ON Providers STEP 1 VALUE 208 \g
#
# Dumping data for table 'Providers'
#
INSERT INTO Providers VALUES
(53,'Slovak','erased3',2,'',NULL,'','','','','','','','',0)\g
INSERT INTO Providers VALUES (172,'Celebration
Belle','erased4',2,'xxx',NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL)\g
---
[2000-10-17 23:25:45] [EMAIL PROTECTED]
A piece of code worked perfectly with PHP3/Apache1.3.9/msql-2..11
I tried it with PHP4/Apache_1.3.14/msql-2.0.11 and got
sporadic crashes - I found out that:
IF
a) You have an msql database with a value in a row blank,
e.g. ('asdf',1,'',,...)
AND
b) you have a SELECT * statement
$sql="SELECT * from table where ... ORDER BY ..."
$result = msql($DB,$sql)
while ($row = msql_fetch_row($result) ) {
}
AND
c) the FIRST row returned contains a value that is blank
THEN
when php hits the msql_fetch_row($result) line,
PHP returns nothing and gives an error in the log
file like:
child pid 9346 exit signal Segmentation Fault
HOWEVER, if the first row returned does not have a
blank element in the row, then it seems to work ok.
I tried variations with
msql_result(), msql_connect, and msql_pconnect as well
but all gave me the same problem.
-
Relevent facts?:
In running "make" I get
gcc -I/usr/local/Hughes/include -c php_msql.c -fPIC -DPIC -o php_msql.lo
php_msql.c:189 warning: int format, long
[PHP-DEV] Bug #12298 Updated: transparent sid doesn't work with transparent gzip compression
ID: 12298 Updated by: zeev Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Session related Operating System: Linux 2.2.14 PHP Version: 4.0.6 New Comment: This should work in the current CVS. Previous Comments: [2001-07-21 11:24:24] [EMAIL PROTECTED] As already mentioned on PHP-DEV, transparent session-id propagation doesn't work when transparent gzip output compression is enabled. Edit this bug report at http://bugs.php.net/?id=12298&edit=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 #13806 Updated: zlib compression is broken?
ID: 13806 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.14-pre3/glibc 2.2.2 PHP Version: 4.1.0 RC CVS-2001-10-24 New Comment: This is most probably not a bug, at least not in the way you perceive it. With a large output buffer - the script will indeed have to consume lots of memory. If your memory limit does not allow this - you'll get these warnings, and in case of a debug build - those complaints about memory being freed... Now, there could be two authentic bugs: (a) There may be a bug in the memory limit implementation. However, it's the same as it has been for years, and it may be that just output buffering is exploiting it in a way that wasn't thought of before. Generally, if the memory limit is reached, PHP tries to bail out nicely. If somehow, PHP goes on consuming more memory, beyond 1MB above the memory limit - it performs a hard exit(). It's possible that the shutdown sequence causes some loop of memory exhaustion - bailout - memory exhaustion - bailout#2 - etc., which cannot be broken. I'll take a look at it. (b) There might be a memory leak in the zlib output compression code. Please let me know what buffer size you use. You really shouldn't be using more than about 16KB or so. Previous Comments: [2001-10-28 10:28:34] [EMAIL PROTECTED] Problem is appearent if output is larger than output buffer size. httpd exits with code 01 with following script (No output) but it not with (Output is correct) It exits with code 01 with more complex script w/o output, though. [2001-10-28 08:50:56] [EMAIL PROTECTED] Upgraded from apache 1.3.20 to 1.3.22. httpd exited with status code 01 while running under gdb. (gdb) run -X Starting program: /usr/sbin/httpd -X Program exited with code 01. (gdb) [2001-10-28 07:29:53] [EMAIL PROTECTED] via-rihine chipset NIC dvriver seems to be fixed in 2.4.13, finanlly :) I could upgrade kernel from 2.4.4 to 2.4.14-pre3. It seems many *.c files are not modified for new asm/*.h files, yet. (It was the same, when I tried 2.4.13) Therefore, I couldn't use the same config as 2.4.4. I was using 2.4.4 kernel that comes with my distribution. Most of kernel drivers/options are compiled in or compiled as module. I'm using kernel optimized for my test PC now. Kernel may crash with other options/modules... Anyway, PHP behaves much better with newer kernel. New behavior is as follows. * PHP outputs the top part of the test script "" correctly. * PHP sends a lot of garbages with the test script. * Kernel seems to stop freezing. + PHP stopped complaining about many memory leaks at shutdown. Problem: * When memory limit is enabled, PHP do not terminate script execution even if it is already exhausted memory. (I get multiple error message for a single execution as attached apache error log) * PHP can't send proper phpinfo() output. * PHP segfaults with my scripts. I changed bug type form Zlib Related to Reproducible crash. If your PHP does not segfault easily, please let me know. I'll send back trace. == apache error log start == /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhau
[PHP-DEV] Bug #13806 Updated: zlib compression is broken?
ID: 13806 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.14-pre3/glibc 2.2.2 PHP Version: 4.1.0 RC CVS-2001-10-24 New Comment: This issue does not appear to be related in any way to the bug id's 12270 and 13698... Previous Comments: [2001-11-10 11:07:11] [EMAIL PROTECTED] This is most probably not a bug, at least not in the way you perceive it. With a large output buffer - the script will indeed have to consume lots of memory. If your memory limit does not allow this - you'll get these warnings, and in case of a debug build - those complaints about memory being freed... Now, there could be two authentic bugs: (a) There may be a bug in the memory limit implementation. However, it's the same as it has been for years, and it may be that just output buffering is exploiting it in a way that wasn't thought of before. Generally, if the memory limit is reached, PHP tries to bail out nicely. If somehow, PHP goes on consuming more memory, beyond 1MB above the memory limit - it performs a hard exit(). It's possible that the shutdown sequence causes some loop of memory exhaustion - bailout - memory exhaustion - bailout#2 - etc., which cannot be broken. I'll take a look at it. (b) There might be a memory leak in the zlib output compression code. Please let me know what buffer size you use. You really shouldn't be using more than about 16KB or so. [2001-10-28 10:28:34] [EMAIL PROTECTED] Problem is appearent if output is larger than output buffer size. httpd exits with code 01 with following script (No output) but it not with (Output is correct) It exits with code 01 with more complex script w/o output, though. [2001-10-28 08:50:56] [EMAIL PROTECTED] Upgraded from apache 1.3.20 to 1.3.22. httpd exited with status code 01 while running under gdb. (gdb) run -X Starting program: /usr/sbin/httpd -X Program exited with code 01. (gdb) [2001-10-28 07:29:53] [EMAIL PROTECTED] via-rihine chipset NIC dvriver seems to be fixed in 2.4.13, finanlly :) I could upgrade kernel from 2.4.4 to 2.4.14-pre3. It seems many *.c files are not modified for new asm/*.h files, yet. (It was the same, when I tried 2.4.13) Therefore, I couldn't use the same config as 2.4.4. I was using 2.4.4 kernel that comes with my distribution. Most of kernel drivers/options are compiled in or compiled as module. I'm using kernel optimized for my test PC now. Kernel may crash with other options/modules... Anyway, PHP behaves much better with newer kernel. New behavior is as follows. * PHP outputs the top part of the test script "" correctly. * PHP sends a lot of garbages with the test script. * Kernel seems to stop freezing. + PHP stopped complaining about many memory leaks at shutdown. Problem: * When memory limit is enabled, PHP do not terminate script execution even if it is already exhausted memory. (I get multiple error message for a single execution as attached apache error log) * PHP can't send proper phpinfo() output. * PHP segfaults with my scripts. I changed bug type form Zlib Related to Reproducible crash. If your PHP does not segfault easily, please let me know. I'll send back trace. == apache error log start == /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal erro
[PHP-DEV] Bug #13806 Updated: zlib compression is broken?
ID: 13806 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.14-pre3/glibc 2.2.2 PHP Version: 4.1.0 RC CVS-2001-10-24 New Comment: Looks like it may be related to bug #13698 after all. The mbstring-auto-conversion may be the problem here, as without it - I cannot reproduce the bug, and it appears to work fine... Previous Comments: [2001-11-10 11:12:21] [EMAIL PROTECTED] This issue does not appear to be related in any way to the bug id's 12270 and 13698... [2001-11-10 11:07:11] [EMAIL PROTECTED] This is most probably not a bug, at least not in the way you perceive it. With a large output buffer - the script will indeed have to consume lots of memory. If your memory limit does not allow this - you'll get these warnings, and in case of a debug build - those complaints about memory being freed... Now, there could be two authentic bugs: (a) There may be a bug in the memory limit implementation. However, it's the same as it has been for years, and it may be that just output buffering is exploiting it in a way that wasn't thought of before. Generally, if the memory limit is reached, PHP tries to bail out nicely. If somehow, PHP goes on consuming more memory, beyond 1MB above the memory limit - it performs a hard exit(). It's possible that the shutdown sequence causes some loop of memory exhaustion - bailout - memory exhaustion - bailout#2 - etc., which cannot be broken. I'll take a look at it. (b) There might be a memory leak in the zlib output compression code. Please let me know what buffer size you use. You really shouldn't be using more than about 16KB or so. [2001-10-28 10:28:34] [EMAIL PROTECTED] Problem is appearent if output is larger than output buffer size. httpd exits with code 01 with following script (No output) but it not with (Output is correct) It exits with code 01 with more complex script w/o output, though. [2001-10-28 08:50:56] [EMAIL PROTECTED] Upgraded from apache 1.3.20 to 1.3.22. httpd exited with status code 01 while running under gdb. (gdb) run -X Starting program: /usr/sbin/httpd -X Program exited with code 01. (gdb) [2001-10-28 07:29:53] [EMAIL PROTECTED] via-rihine chipset NIC dvriver seems to be fixed in 2.4.13, finanlly :) I could upgrade kernel from 2.4.4 to 2.4.14-pre3. It seems many *.c files are not modified for new asm/*.h files, yet. (It was the same, when I tried 2.4.13) Therefore, I couldn't use the same config as 2.4.4. I was using 2.4.4 kernel that comes with my distribution. Most of kernel drivers/options are compiled in or compiled as module. I'm using kernel optimized for my test PC now. Kernel may crash with other options/modules... Anyway, PHP behaves much better with newer kernel. New behavior is as follows. * PHP outputs the top part of the test script "" correctly. * PHP sends a lot of garbages with the test script. * Kernel seems to stop freezing. + PHP stopped complaining about many memory leaks at shutdown. Problem: * When memory limit is enabled, PHP do not terminate script execution even if it is already exhausted memory. (I get multiple error message for a single execution as attached apache error log) * PHP can't send proper phpinfo() output. * PHP segfaults with my scripts. I changed bug type form Zlib Related to Reproducible crash. If your PHP does not segfault easily, please let me know. I'll send back trace. == apache error log start == /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowed memory size of 8388608 bytes exhausted at zlib.c:995 (tried to allocate 2915587 bytes) /home/yohgaki/public_html/test/phpinfo.php(1) : Fatal error - Allowe
[PHP-DEV] Bug #13698 Updated: CGI version segfaults at shutdown
ID: 13698 Updated by: zeev Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: Linux 2.4.14-pre3/glibc 2.2.2 PHP Version: 4.0CVS-2001-10-29 New Comment: Is this with zlib.output_compression turned off? Previous Comments: [2001-10-29 04:16:12] [EMAIL PROTECTED] It crashes today's CVS source with newer kernel. [2001-10-19 23:17:25] [EMAIL PROTECTED] I'm using 4.1.0RC1 for this comment. I build CGI version, with following configure. './configure' \ '--enable-mbstring' \ '--enable-mbstr-enc-trans' \ '--enable-debug' \ but, I didn't get segfault this time. Therefore, it may not be related to --enable-mbstr-enc-trans after all :) I still get segfault with longer config and backtrace is the same. Anyway, since no one seems to be interested in this bug, I've take look at what is really wrong. The segfualt occurs in this macro def. (zend_API.h) #define CHECK_ZVAL_STRING_REL(z) \ if ((z)->value.str.val[ (z)->value.str.len ] != '\0') zend_error(E_WARNING, "String is not zero-terminated (%s) (source: %s:%d)", (z)->value.str.val ZEND_FILE_LINE_RELAY_CC); (gdb) print zvalue->value.str.val[ zvalue->value.str.len ] Cannot access memory at address 0x0 (gdb) print zvalue->value.str.val $1 = 0x0 (gdb) print zvalue->value.str.len $2 = 0 (gdb) [2001-10-16 19:23:58] [EMAIL PROTECTED] CGI version segfaults at the end of test script.(i.e. at the end of "./php -q run-tests.php") It happens both HAED (4.2.0-dev) and RC (4.1.0RC). It seems --enable-mbstr-enc-trans is the cause. ==CONFIGURE(4.1.0RC)== I cannot reproduce segfault with 4.2.0-dev using this simple configure line I attached more complex configure for 4.2.0-dev that causes segfault. ./configure --enable-mbstring --enable-mbstr-enc-trans --ena ble-debug without --enable-mbstr-enc-trans, php doesn't segfaults. ==BACKTRACE(4.1.0RC)== [yohgaki@dev RC]$ gdb -c core GNU gdb 20010318 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i586-redhat-linux". Core was generated by `/home/yohgaki/cvs/php/RC/php -C -q /home/yohgaki/cvs/php/RC/run-tests.php /home'. Program terminated with signal 11, Segmentation fault. #0 0x0811a453 in ?? () (gdb) file php Reading symbols from php...done. (gdb) bt #0 0x0811a453 in _zval_dtor (zvalue=0x81e9c6c, __zend_filename=0x817d27c "zend_execute_API.c", __zend_lineno=268) at zend_variables.c:43 #1 0x08111c82 in _zval_ptr_dtor (zval_ptr=0x81edd60, __zend_filename=0x817db13 "zend_variables.c", __zend_lineno=192) at zend_execute_API.c:268 #2 0x0811a8ab in _zval_ptr_dtor_wrapper (zval_ptr=0x81edd60) at zend_variables.c:192 #3 0x081211b9 in zend_hash_destroy (ht=0x81e5404) at zend_hash.c:541 #4 0x0811a4d1 in _zval_dtor (zvalue=0x81e53c4, __zend_filename=0x817d27c "zend_execute_API.c", __zend_lineno=268) at zend_variables.c:51 #5 0x08111c82 in _zval_ptr_dtor (zval_ptr=0x81eddf8, __zend_filename=0x817db13 "zend_variables.c", __zend_lineno=192) at zend_execute_API.c:268 #6 0x0811a8ab in _zval_ptr_dtor_wrapper (zval_ptr=0x81eddf8) at zend_variables.c:192 #7 0x081211b9 in zend_hash_destroy (ht=0x81befc8) at zend_hash.c:541 #8 0x08111992 in shutdown_executor () at zend_execute_API.c:172 #9 0x0811b782 in zend_deactivate () at zend.c:600 #10 0x0806243c in php_request_shutdown (dummy=0x0) at main.c:736 #11 0x08060d83 in main (argc=5, argv=0xb89c) at cgi_main.c:775 #12 0x400b91be in ?? () (gdb) ==CONFIGURE(4.2.0-dev)== without --enable-mbstr-enc-trans, php doesn't segfaults. './configure' \ '--disable-short-tags' \ '--without-mysql' \ '--with-bz2' \ '--with-curl' \ '--with-ftp' \ '--with-iconv' \ '--with-mhash' \ '--with-mcrypt' \ '--with-openssl' \ '--with-pgsql' \ '--with-regex=system' \ '--with-zlib' \ '--with-gd=/usr' \ '--enable-gd-native-ttf' \ '--with-freetype-dir=/usr/local' \ '--with-jpeg-dir=/usr' \ '--with-png-dir=/usr' \ '--with-xpm-dir=/usr/X11R6' \ '--enable-bcmath' \ '--enable-ftp' \ '--enable-shmop' \ &#
[PHP-DEV] Bug #14023 Updated: curl does not initialize HTTPS correctly - hence does not work.
ID: 14023
Updated by: zeev
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Closed
Bug Type: cURL related
Operating System: linux debian
PHP Version: 4.0CVS-2001-11-12
New Comment:
Patched in CVS (untested)
Previous Comments:
[2001-11-12 05:44:12] [EMAIL PROTECTED]
filed under correct type (oops)
[2001-11-12 04:17:24] [EMAIL PROTECTED]
also probably a good idea to add WIN32 inititialization as well eg.
curl_global_init(CURL_GLOBAL_SSL && CURL_GLOBAL_WIN32)
[2001-11-12 00:26:30] [EMAIL PROTECTED]
the curl.c file initializes curl with nothing, the curl init library will then skip
the init for ssl, and hence all https connections will fail.
also CURLOPT_SSL_VERIFYHOST is not defined..
patch below..
regards
alan
--- curl.c 18 Oct 2001 19:24:51 - 1.94
+++ curl.c 12 Nov 2001 05:25:05 -
@@ -142,6 +142,7 @@
REGISTER_CURL_CONSTANT(CURLOPT_SSLCERT);
REGISTER_CURL_CONSTANT(CURLOPT_SSLCERTPASSWD);
REGISTER_CURL_CONSTANT(CURLOPT_WRITEHEADER);
+ REGISTER_CURL_CONSTANT(CURLOPT_SSL_VERIFYHOST);
REGISTER_CURL_CONSTANT(CURLOPT_COOKIEFILE);
REGISTER_CURL_CONSTANT(CURLOPT_SSLVERSION);
REGISTER_CURL_CONSTANT(CURLOPT_TIMECONDITION);
@@ -253,7 +254,7 @@
REGISTER_CURL_CONSTANT(CURLE_OBSOLETE);
REGISTER_CURL_CONSTANT(CURLE_SSL_PEER_CERTIFICATE);
- if (curl_global_init(CURL_GLOBAL_NOTHING) != CURLE_OK) {
+ if (curl_global_init(CURL_GLOBAL_SSL) != CURLE_OK) {
return FAILURE;
}
@@ -658,6 +659,7 @@
case CURLOPT_FRESH_CONNECT:
case CURLOPT_FORBID_REUSE:
case CURLOPT_CONNECTTIMEOUT:
+ case CURLOPT_SSL_VERIFYHOST:
case CURLOPT_SSL_VERIFYPEER:
convert_to_long_ex(zvalue);
error = curl_easy_setopt(ch->cp, option, Z_LVAL_PP(zvalue));
Edit this bug report at http://bugs.php.net/?id=14023&edit=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] BCDIV problems
If you could create a self-contained reproducing script (i.e., in addition
to the function code you supplied, also supply anything else that's needed
to illustrate the problem), it should be easy to figure out what's going
on. If you could do it in the shortest manner possible, it'll even make
things easier :)
At 12:21 10/1/2001, Christian Fagerheim wrote:
>Hello!
>
>I have some problems with my PHP script that utilizes the BCDIV function,
>and I was hoping some of you could be so kind as to help me solve it.
>I am sorry for writing in English, but I am afraid my German is not too good
>so this is the best alternative. You may reply in German if you like, but I
>would prefer it in English. Thank you all in advance.
>
>To the problem: I use BCDIV to divide a string to a integer constant and it
>works great, unless the string is no more than 14 digits...
>I have tried to do an echo between each operation to see what happens, and
>then I discovered that BCDIV returned, much to my dismay, a double. Based
>upon further use of the value BCDIV returns I have made some calculations,
>but when BCDIV returned a double with "+E**" at the end the calculations
>fails.
>I have recreated the piece of my code that I am talking about, and I hope it
>will
>be more enlightening than my explenations.
>
>/
>function user_func($input_string) {
> $new_string = "";
> $temp_string = "";
>
> while($input_string) {
> $div_string = 0;
> $div_string = (string) (bcdiv($input_string, 100) * 100);
> $temp_string = bcsub($input_string, $div_string);
> $int_input = bcdiv($input_string, 100);
> $new_string .= call_user_func("string_manip", $temp_string);
> }
>
> return $new_string;
>}
>//
>
>This should return a 2 digit value removed from the end of $input_string,
>but when the problem arises it returns a "0". Everything else works
>perfectly though, even if the problem occurs.
>
>I hope that there are somebody out there that know what the problem is
>caused by, or can help me in any other way. I would like to thank you all in
>advance!
>
>
>
>--
>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] ++$i++ (was Re: [PHP-DEV] call_builtin_function_array() possible?)
Could you explain how this construct is useful? I can't think of any real world situation in which it's useful or even remotely makes sense. What would it even do? Remember, an expression has only one value. Zeev At 14:51 10/1/2001, Cynic wrote: >Well, this would be probably completely useless (at least I >can't think of a meaningful use of this right now), but... is >there a reason this can't be implemented in PHP? I know, time >is a very precious commodity, and I wouldn't ask (or suggest) >for an implementation of this if it would require extra work >besides making pre- and post- increment / decrement in one >statement. But if allowing ++$i++ (which I definitely consider >useful) makes ++$i-- possible without additional effort, why >disable it? It's possible to write completely useless junk >software without this feature too. > >Lack of knowledge of C prevents me from going to try and do >this myself. > > >At 21:51 9.1. 2001, Hartmut Holzgraefe wrote the following: >-- > >Cynic wrote: > >> > >> At 21:16 9.1. 2001, Andrei Zmievski wrote the following: > >> >What color is the sky on your planet? :) > >> > >> I don't know, haven't checked for some time now. :) > >> But seriously: I'm not familiar with C, nor the way this stuff > >> is implemented in PHP, however, whether the sky here is blue or > >> pink doesn't mean I think this wouldn't be useful. > > > >and what's next? > > > >++$i-- ??? > > > >-- > >Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 > > > >-- > >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] >--end of quote-- > > > > >Cynic: > >A member of a group of ancient Greek philosophers who taught >that virtue constitutes happiness and that self control is >the essential part of virtue. > >[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] -- 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] Re: ++$i++ (was Re: [PHP-DEV] call_builtin_function_array() possible?)
At 15:01 10/1/2001, Cynic wrote: >would have saved me one statement. I had to use >for( $i = 0 ; $i < count( $a ) ; $x = $a[ $i++ ] , $i++ ) This is a very weird and uncommon piece of code. If it's indeed correct (which I doubt - do you want to increment it by two?) then a more common & understandable way to write it would have been $x = $a[$i], $i+=2. Saving an extra expression by adding the ultra-obscure ++$i++ is a definite 'no'. There's no logical behavior that would be both pre- and post-increment, which is implied by this weird notation... Zeev >I know, this is an 'issue' so tiny I can laugh at it, but >anyway... > >At 13:49 10.1. 2001, Zeev Suraski wrote the following: >-- > >Could you explain how this construct is useful? I can't think of any > real world situation in which it's useful or even remotely makes > sense. What would it even do? Remember, an expression has only one value. > > > >Zeev > > > >At 14:51 10/1/2001, Cynic wrote: > >>Well, this would be probably completely useless (at least I > >>can't think of a meaningful use of this right now), but... is > >>there a reason this can't be implemented in PHP? I know, time > >>is a very precious commodity, and I wouldn't ask (or suggest) > >>for an implementation of this if it would require extra work > >>besides making pre- and post- increment / decrement in one > >>statement. But if allowing ++$i++ (which I definitely consider > >>useful) makes ++$i-- possible without additional effort, why > >>disable it? It's possible to write completely useless junk > >>software without this feature too. > >> > >>Lack of knowledge of C prevents me from going to try and do > >>this myself. > >> > >> > >>At 21:51 9.1. 2001, Hartmut Holzgraefe wrote the following: > >>-- > >>>Cynic wrote: > >>>> > >>>> At 21:16 9.1. 2001, Andrei Zmievski wrote the following: > >>>> >What color is the sky on your planet? :) > >>>> > >>>> I don't know, haven't checked for some time now. :) > >>>> But seriously: I'm not familiar with C, nor the way this stuff > >>>> is implemented in PHP, however, whether the sky here is blue or > >>>> pink doesn't mean I think this wouldn't be useful. > >>> > >>>and what's next? > >>> > >>>++$i-- ??? > >>> > >>>-- > >>>Hartmut Holzgraefe [EMAIL PROTECTED] http://www.six.de +49-711-99091-77 > >>> > >>>-- > >>>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] > >>--end of quote-- > >> > >> > >> > >> > >>Cynic: > >> > >>A member of a group of ancient Greek philosophers who taught > >>that virtue constitutes happiness and that self control is > >>the essential part of virtue. > >> > >>[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] > > > >-- > >Zeev Suraski <[EMAIL PROTECTED]> > >CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/ > > >--end of quote-- > > > > >Cynic: > >A member of a group of ancient Greek philosophers who taught >that virtue constitutes happiness and that self control is >the essential part of virtue. > >[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]
Re: [PHP-DEV] 4.0.4pl1 RC2 rolled
I don't think it's crucial for 4.0.4pl1... Zeev At 15:46 10/1/2001, Cynic wrote: >4.0.4pl1 RC2 doesn't build as win32 mod_php4, so probably >the patch I bugged you in should be there as well? > >Linking... >Creating library ..\..\Release_TS_inline/php4apache.lib and object > ..\..\Release_TS_inline/php4apache.exp >mod_php4.obj : error LNK2001: unresolved external symbol _zend_ini_rshutdown >..\..\Release_TS_inline/php4apache.dll : fatal error LNK1120: 1 unresolved >externals >Error executing link.exe. > > > >At 22:14 9.1. 2001, Zeev Suraski wrote the following: >-- > >Only one change in this release - Daniel's PDF fixes were merged in. If > all goes well, I want to release pl1 in 48 hours. > > > >Zeev > > > > > >-- > >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] > > >--end of quote-- > > > >____ >Cynic: > >A member of a group of ancient Greek philosophers who taught >that virtue constitutes happiness and that self control is >the essential part of virtue. > >[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]
Re: [PHP-DEV] Could some kind soul review these patches please.
At 14:26 14/12/2000, Hartmut Holzgraefe wrote: >ac not the problem >personally think its of no use anyway I don't understand what you're saying here. >ouo watch your words Perhaps it's a language gap, but this sentence doesn't sound very nice in English... >calling for breaching ohter peeples licenses can fire back really bad >whenever you'll try to enforce your own one I don't recall anybody in the opensource scene ever trying to enforce anything, except for Richard Stallman. He started to watch PHP because he's pissed we dropped the completely incompatible GPL. There are plenty of other opensource, non GPL packages I know of that use/interface with GPL software but are not licensed under the GPL, and I kinda doubt he does anything about them, or even cares. Personally, I'm fed up with this. I don't necessarily represent anybody else, though. Zeev -- 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]
