Re: [PHP-DEV] Re: PHP4.0.7RC1 memory problem
Zeev Suraski wrote:
Do you use dl() anywhere? Is the crash reproducible?
Hi Zeev,
I'm glad you are interested in. I don't use dl(). This crash is
reproducible, but I could not make it reproduce with simpler script, yet.
Anyway, there is other code that crashes PHP which I can report details.
I have Form classes handle HTML form. In the classes, there is a
following method
// Form_Email class
function _validate($val) {
error_log(called _validate()\n,3,'/tmp/php_elog');
if (!$this-required !$val) {
return '';
}
if (!eregi($this-valid_regex, $val, $regs)) {
return ERROR; //$this-valid_e;
}
error_log(regex check done\n,3,'/tmp/php_elog');
$host = $regs[1];
$err = '';
switch ($this-check_lev) {
case hard:
case normal:
if (!checkdnsrr($host,'MX')) {
$err = No MX entry in DNS;
}
break;
}
error_log(return _validate()\n,3,'/tmp/php_elog');
return $err;
}
There is other class called From which has HAS A relationship to
Form_Email class. From object has colletion of form element objects as
array. In the Form class, appropriate elements are selected and
_validate method is called as variable function(method). (i.e.
$object-$method())
Once this method is called, PHP calls this method over and over until
PHP reaches memory limit. I don't get SIGSEGV for this one.
Interesting behavior is, this problem cannot be reproduced with much
simpler Form class test script. It happens when I use these Form classes
within an Application class. (Form object is defined as global) However,
if I comment out checkdnsrr() call, it works as expetecd.
NOTE: I experienced similar behavior when I encountered foreach() bug.
PHP stopped looping when I comment out or move some statements, even if
real problem was in foreach() code.
I'll try to find the cause this afternoon. However, I think I won't find
what's wrong... I needed to spend MANY hours to find out foreach() had a
bug...
Please let me know, if you have anything you need or you want me to do.
Any suggestions are welcome.
Thanks Jani, I tied without dmalloc. It seems dmalloc does not relate to
this problem.
--
Yasuo Ohgaki
At 10:05 04-09-01, Yasuo Ohgaki wrote:
FYI
PHP 4.0.8-dev (updated about 30 min ago) has the same problem.
BTW, I don't enable output compression in PHP. No custom output
handler. I enabled mbstr-enc-trans, but there should be no acutual
translation, since I'm using EUC-JP for both internal/output encoding.
Yasuo Ohgaki
Yasuo Ohgaki wrote:
I got SIGSEGV.
GNU gdb 5.0rh-5 Red Hat Linux 7.1
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 i386-redhat-linux...
(gdb) run -X
Starting program: /usr/sbin/httpd -X
[Tue Sep 4 14:10:25 2001] [warn] Loaded DSO lib/apache/mod_gzip.so
uses plain Apache 1.3 API, this module might crash under EAPI!
(please recompile it with -DEAPI)
Program received signal SIGSEGV, Segmentation fault.
0x40106fb6 in chunk_free (ar_ptr=0x401aff00, p=0x819f1f8) at
malloc.c:3142
3142 malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0 0x40106fb6 in chunk_free (ar_ptr=0x401aff00, p=0x819f1f8) at
malloc.c:3142
#1 0x40106d59 in __libc_free (mem=0x819f200) at malloc.c:3054
#2 0x40597a05 in free_zend_constant (c=0x81bc1a8) at
zend_constants.c:34
#3 0x405b2a59 in zend_hash_del_key_or_index (ht=0x80bfca8,
arKey=0x81bc190 include_path,
nKeyLength=13, h=3932814155, flag=0) at zend_hash.c:512
#4 0x405b3340 in zend_hash_reverse_apply (ht=0x80bfca8,
apply_func=0x40597acc clean_non_persistent_constant) at
zend_hash.c:741
#5 0x40597e86 in clean_non_persistent_constants () at
zend_constants.c:163
#6 0x405a1da8 in shutdown_executor () at zend_execute_API.c:194
#7 0x405ac92f in zend_deactivate () at zend.c:594
#8 0x405bde23 in php_request_shutdown (dummy=0x0) at main.c:736
#9 0x405ba12e in apache_php_module_main (r=0x81993f8,
display_source_mode=0)
at sapi_apache.c:96
#10 0x405baf24 in send_php (r=0x81993f8, display_source_mode=0,
filename=0x819b160
/home/httpd/dev/ygb/support/feedback/question/index.shtml)
at mod_php4.c:575
#11 0x405baf9e in send_parsed_php (r=0x81993f8) at mod_php4.c:590
#12 0x08055927 in ap_invoke_handler () at eval.c:41
#13 0x08069bdb in process_request_internal () at
Re: [PHP-DEV] The rand() can of worms
Replied to Sterling off-list. I really just want to get all of this resolved so those of us who are on the sidelines on this one can get back to work. :) -- 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 #12971 Updated: configure: error: libjpeg not found!
ID: 12971 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: HP-11 PHP Version: 4.0.6 New Comment: Solved! Now it works with the new configure that Jani sent me via e-mail. Will it be added in the future releases (snapshots)? Thanks Matteo Previous Comments: [2001-08-27 07:17:21] [EMAIL PROTECTED] * With the standard make and yacc I had other problems so now I use bison and gmake. export MAKE=/opt/make/bin/gmake CC=cc -Ae CXX=aCC ./configure --prefix=/apps/WEB/php --with-oci8=/oracle/PIRELLI/app/oracle/product/8.0.5 --with-apxs=/apps/WEB/apache/bin/apxs --with-gd=/opt/gd --with-zlib-dir=/opt/zlib --with-freetype-dir=/opt/freetype2 --without-mysql --with-xpm-dir=/opt/xpm --with-png-dir=/opt/libpng --with-jpeg-dir=/opt/jpeg-6 configure: error: libjpeg not found! ** BUT I have the libs: bonnie.root./ $ ls /opt/jpeg-6/lib libjpeg.a libjpeg.la libjpeg.sl * My config.log is: configure:17801: cc -Ae -o conftest -g -DHPUX11 -D_HPUX_SOURCE -DUSE_HSREGEX -D USE_EXPAT -L/opt/zlib/lib -L/opt/zlib/lib conftest.c -ljpeg -L/opt/jpeg-6/lib -lz -lcrypt -lm -lnsl 15 /usr/ccs/bin/ld: Can't find library: jpeg configure: failed program was: #line 17790 configure #include confdefs.h /* Override any gcc2 internal prototype to avoid an error. */ /* We use char because int might match the return type of a gcc2 builtin and then its argument prototype would still apply. */ char jpeg_read_header(); ** In /opt I've installed all the necessary libraries that I've downloaded from http://hpux.connect.org.uk/hppd/search.html: /apps/WEB/sw/binutils-2.11.2-sd-11.00.depot /apps/WEB/sw/bison-1.28-sd-11.00.depot /apps/WEB/sw/gcc-3.0.1-sd-11.00.depot /apps/WEB/sw/gd-1.8.4-sd-11.00.depot /apps/WEB/sw/jpeg-6b-sd-11.00.depot /apps/WEB/sw/libpng-1.0.11-sd-11.00.depot /apps/WEB/sw/make-3.79.1-sd-11.00.depot /apps/WEB/sw/binutils-2.11.2-sd-11.00.depot /apps/WEB/sw/bison-1.28-sd-11.00.depot /apps/WEB/sw/gcc-3.0.1-sd-11.00.depot /apps/WEB/sw/gd-1.8.4-sd-11.00.depot /apps/WEB/sw/jpeg-6b-sd-11.00.depot /apps/WEB/sw/libpng-1.0.11-sd-11.00.depot /apps/WEB/sw/make-3.79.1-sd-11.00.depot /apps/WEB/sw/perl-5.6.1-sd-11.00.depot /apps/WEB/sw/xpm-3.4k-sd-11.00.depot /apps/WEB/sw/zlib-1.1.3-sd-11.00.depot /apps/WEB/sw/xpm-3.4k-sd-11.00.depot *** If I do not include the library in the ./configure options I have configure: error: libpng not found! * No configure errors with GCC but: I tried with gcc but I have other problems (see bug id.12842) that is still opened. Can anyone help me please? Thanks in advance Edit this bug report at http://bugs.php.net/?id=12971edit=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 #13144: Can not set post_max_size in VirtualHost
From: [EMAIL PROTECTED] Operating system: Linux 2.4.4 PHP version: 4.0.6 PHP Bug Type: *Configuration Issues Bug description: Can not set post_max_size in VirtualHost Webserver: apache 1.3.20 I have the following entry in the VirtualHost defenition: php_value post_max_size 12M After a restart, phpinfo() shows the Local value unchanged. It is the same as the Master value (10M). Changing for example the value for upload_max_filesize is no problem. './configure' '--with-apxs=/local/apache/sbin/apxs' '--with-ftp' '--with-mysql=/usr' '--disable-short-tags' '--enable-memory-limit' '--disable-debug' '--enable-track-vars' '--enable-sysvsem' '--enable-sysvshm' '--enable-inline-optimization' '--with-zlib' '--with-gd' Installed: Zend Optimizer v1.1.0 Cheers, Jene -- Edit bug report at: http://bugs.php.net/?id=13144edit=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 #13145: Postgres module ignores php.ini
From: [EMAIL PROTECTED] Operating system: Linux (Redhat 6.2) PHP version: 4.0.6 PHP Bug Type: PostgreSQL related Bug description: Postgres module ignores php.ini Postgres module ignores php.ini pgsql.* directives when compiled and loaded as dso. -- Edit bug report at: http://bugs.php.net/?id=13145edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: Bug #13138 Updated: constants behave weird in static hash arrays
thanks :) I'll try it as soon as I have a couple of minutes.
Bug Database wrote:
ID: 13138
Updated by: joey
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.0.4pl1
New Comment:
Please try a more recent version of PHP. 4.0.7RC1 gives
me:
array(1) {
[1]=
bool(true)
}
array(1) {
[1]=
bool(true)
}
Previous Comments:
[2001-09-04 13:23:25] [EMAIL PROTECTED]
I think the following piece of code behaves sort of weird:
?
define ('A', 1);
function test()
{
$a = array(1 = true);
static $stat_a = array(A = true);
var_dump($a);
var_dump($stat_a);
}
test();
?
result is:
array(1) {
[1]=
bool(true)
}
array(1) {
[A]=
bool(true)
}
I'm not sure whether static variables are supposed to evaluate expressions but even
if they were not, the engine should at least issue a warning.
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=13138edit=2
--
Jan Fedak mailto:[EMAIL PROTECTED]
Linux - the ultimate NT Service Pack.
--
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] Misbehaviour with boolean values
?php $a = true; $b = false; echo 'a: ' . $a . 'br /'; echo 'b: ' . $b; ? outputs a: 1 b: with current HEAD. Is this intended behaviour? -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Misbehaviour with boolean values
Hello, afaik this is normal. A conversation from a boolean to string, makes a 1 out of true and a out of false. Derick - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - JDI Media Solutions - www.jdimedia.nl - [EMAIL PROTECTED] Boulevard Heuvelink 102 - 6828 KT Arnhem - The Netherlands - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP4.0.7RC1 memory problem
Did you try cutting down the script that crashes (as opposed to trying to
create a script that reproduces the problem from scratch)? That's the
easiest way to create a short test case...
Zeev
At 10:03 05-09-01, Yasuo Ohgaki wrote:
Zeev Suraski wrote:
Do you use dl() anywhere? Is the crash reproducible?
Hi Zeev,
I'm glad you are interested in. I don't use dl(). This crash is
reproducible, but I could not make it reproduce with simpler script, yet.
Anyway, there is other code that crashes PHP which I can report details.
I have Form classes handle HTML form. In the classes, there is a following
method
// Form_Email class
function _validate($val) {
error_log(called _validate()\n,3,'/tmp/php_elog');
if (!$this-required !$val) {
return '';
}
if (!eregi($this-valid_regex, $val, $regs)) {
return ERROR; //$this-valid_e;
}
error_log(regex check done\n,3,'/tmp/php_elog');
$host = $regs[1];
$err = '';
switch ($this-check_lev) {
case hard:
case normal:
if (!checkdnsrr($host,'MX')) {
$err = No MX entry in DNS;
}
break;
}
error_log(return _validate()\n,3,'/tmp/php_elog');
return $err;
}
There is other class called From which has HAS A relationship to
Form_Email class. From object has colletion of form element objects as
array. In the Form class, appropriate elements are selected and _validate
method is called as variable function(method). (i.e. $object-$method())
Once this method is called, PHP calls this method over and over until PHP
reaches memory limit. I don't get SIGSEGV for this one.
Interesting behavior is, this problem cannot be reproduced with much
simpler Form class test script. It happens when I use these Form classes
within an Application class. (Form object is defined as global) However,
if I comment out checkdnsrr() call, it works as expetecd.
NOTE: I experienced similar behavior when I encountered foreach() bug. PHP
stopped looping when I comment out or move some statements, even if real
problem was in foreach() code.
I'll try to find the cause this afternoon. However, I think I won't find
what's wrong... I needed to spend MANY hours to find out foreach() had a bug...
Please let me know, if you have anything you need or you want me to do.
Any suggestions are welcome.
Thanks Jani, I tied without dmalloc. It seems dmalloc does not relate to
this problem.
--
Yasuo Ohgaki
At 10:05 04-09-01, Yasuo Ohgaki wrote:
FYI
PHP 4.0.8-dev (updated about 30 min ago) has the same problem.
BTW, I don't enable output compression in PHP. No custom output handler.
I enabled mbstr-enc-trans, but there should be no acutual translation,
since I'm using EUC-JP for both internal/output encoding.
Yasuo Ohgaki
Yasuo Ohgaki wrote:
I got SIGSEGV.
GNU gdb 5.0rh-5 Red Hat Linux 7.1
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 i386-redhat-linux...
(gdb) run -X
Starting program: /usr/sbin/httpd -X
[Tue Sep 4 14:10:25 2001] [warn] Loaded DSO lib/apache/mod_gzip.so
uses plain Apache 1.3 API, this module might crash under EAPI! (please
recompile it with -DEAPI)
Program received signal SIGSEGV, Segmentation fault.
0x40106fb6 in chunk_free (ar_ptr=0x401aff00, p=0x819f1f8) at malloc.c:3142
3142 malloc.c: No such file or directory.
in malloc.c
(gdb) bt
#0 0x40106fb6 in chunk_free (ar_ptr=0x401aff00, p=0x819f1f8) at
malloc.c:3142
#1 0x40106d59 in __libc_free (mem=0x819f200) at malloc.c:3054
#2 0x40597a05 in free_zend_constant (c=0x81bc1a8) at zend_constants.c:34
#3 0x405b2a59 in zend_hash_del_key_or_index (ht=0x80bfca8,
arKey=0x81bc190 include_path,
nKeyLength=13, h=3932814155, flag=0) at zend_hash.c:512
#4 0x405b3340 in zend_hash_reverse_apply (ht=0x80bfca8,
apply_func=0x40597acc clean_non_persistent_constant) at
zend_hash.c:741
#5 0x40597e86 in clean_non_persistent_constants () at zend_constants.c:163
#6 0x405a1da8 in shutdown_executor () at zend_execute_API.c:194
#7 0x405ac92f in zend_deactivate () at zend.c:594
#8 0x405bde23 in php_request_shutdown (dummy=0x0) at main.c:736
#9 0x405ba12e in apache_php_module_main (r=0x81993f8,
display_source_mode=0)
at sapi_apache.c:96
#10 0x405baf24 in send_php (r=0x81993f8, display_source_mode=0,
filename=0x819b160
[PHP-DEV] Bug #13146: installer aborted ,error message corupt I/O file
From: [EMAIL PROTECTED] Operating system: win98se PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: installer aborted ,error message corupt I/O file Error Message An I/O error occured while installing a file. This is normally caused by bad installation media or a corrupt installation file. I downloaded the PHP file and the PHP installation file twice with the same result. Has anybody had this problem also? If so what is the fix Thanks Garuda -- Edit bug report at: http://bugs.php.net/?id=13146edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP4.0.7RC1 memory problem
(gdb) run -X Starting program: /usr/sbin/httpd -X [Tue Sep 4 14:10:25 2001] [warn] Loaded DSO lib/apache/mod_gzip.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) Just a stab in the dark, this wouldn't cause the problem, would it? For the sake of eliminating this as a cause, can you try diabling mod_gzip in your apache conf? --Wez. -- 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 #13146 Updated: installer aborted ,error message corupt I/O file
ID: 13146 Updated by: phildriscoll Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *General Issues Operating System: win98se PHP Version: 4.0.6 New Comment: I've just downloaded and tested the installer - no problems. Maybe your first download was faulty in some way and subsequent downloads have come from your cache? For info/testing, the installer should be 773192 bytes long, and it is in zip format, so if it's ok, you should be able to open it with WinZip. Previous Comments: [2001-09-05 04:22:59] [EMAIL PROTECTED] Error Message An I/O error occured while installing a file. This is normally caused by bad installation media or a corrupt installation file. I downloaded the PHP file and the PHP installation file twice with the same result. Has anybody had this problem also? If so what is the fix Thanks Garuda Edit this bug report at http://bugs.php.net/?id=13146edit=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 #13122 Updated: UDP probs
ID: 13122
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Closed
Bug Type: Sockets related
Operating System: linux red hat 7.1
PHP Version: 4.0.4pl1
New Comment:
the problem is that i cant get the amount of bytes to receive its UDP !
Previous Comments:
[2001-09-04 18:30:54] [EMAIL PROTECTED]
You fread() instead which is binary safe.
--Jani
[2001-09-04 04:38:25] [EMAIL PROTECTED]
well when i send an UDP packet to my halflife server with
fsockopen and fgets, it returns me another packet beginning from the 2nd line instead
of the 1st. it means that if i were supposed to get :
packet #1-hello
packet #2-world
packet #3-its me
i receive :
packet #1-world
packet #2-its me
here's a sample of my code :
//-
function get_pass_player_cs($serverip,$port,$rcon)
{
$get_pass_player_cs .= BRDo .$commande. on
:.$serverip.:.$port.'BRBR';
//Open the network for transmission.
$serverip = udp://.$serverip;
$fp = fsockopen($serverip,$port, $errno, $errstr,10);
if (!$fp)
{
$get_pass_player_cs .= Server not available :.$errno;
}
else
{
//Send statusrequest.
fwrite($fp,challenge rcon.\x00);
$challenge = fgets($fp,50);
$challenge = substr($challenge, 19);
$challenge = trim ($challenge);
$rcontxt=rcon .$challenge. .$rcon. status\x00;
fwrite($fp,$rcontxt);
$tmp = fgets($fp,100);
//debug echo $tmp;
$get_pass_player_cs = $tmp;
fclose($fp);
return $get_pass_player_cs;
}
$get_pass_player_cs .= Erreur;
fclose($fp);
return $get_pass_player_cs;
}
//-
Edit this bug report at http://bugs.php.net/?id=13122edit=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 #12841 Updated: ++, -- operators does not conert the type of variable.
ID: 12841 Updated by: stas Reported By: [EMAIL PROTECTED] Old Status: Assigned Status: Closed Bug Type: Scripting Engine problem Operating System: FreeBSD 4.3 PHP Version: 4.0.6 Assigned To: jeroen New Comment: Fixed in CVS. Previous Comments: [2001-08-31 16:27:45] [EMAIL PROTECTED] Working on it... [2001-08-31 10:34:00] [EMAIL PROTECTED] Please provide a plain diff, gzipped text is a bit hard to read without special specs ;) [2001-08-19 08:14:35] [EMAIL PROTECTED] % cat foo #!/usr/local/bin/php -f ?php $i = 0x7fff; print var_dump( $i ); $j = $i+1; print var_dump( $j ); $i++; print var_dump( $i ); ? % ./foo int(2147483647) float(2147483648) int(-2147483648) I quick hacked. begin 644 zend_operators.c.diff.gz M'XL(`#H?#L``[6276^;,!2K\VO..JD*BD?C8$L*2Q56BV=*J6IU`]I=XB M$ZP1B`QLZJK^]]J)`2R=9N67`3I^#U^SWG\ZKH./TD2NF*,#]/668$1LKH M`CU$!=SXSX![8*G/W0L#:OAQLMZ(I1N@6@``+\_K]4CT@VY: MVD=0^?\`QF,%/M`DB(N0P*L#V/Z9$3G]6*0/Z](H[;T\TB4UTIIDN:9U)7 M4QZ)R8SHJ%FJ#L/Q5#8-DTQ%O]:L9RLA%4/:#YD$$G72%]7,Q2E64!G M!*[OOGM[(NCJ`@!T#ET`*3PNQ\7Q(CY!T8C$!KOYN(KB%XIW9%4M9L='4 MPIEKN.'GV\?+Z61SRDAL(0;\_T869(D]^9%$N0T33JBE7MV*_KF!LU;%35 ME4G1OQO;GVSTLBIZ%A#[4S0L6T-VY*.;-OPH9F7%$O:.!E.:/)HL,__'ZM MOAO3%)-#B.Y=Q6+U;$45[H(H?F3-JMO6JY2H_X[O(:VN5:*G9W!%M+ M,;2KZ'MWK#JV;X+:S]*VK?8,*]ORW0:X3/707*:_==47\\.FNJ0_%.J=?W/ M4CVT)9U^K[AL\O]%4C,P6$=L(;R7XO[;/'Z;0[E5X.34X/8$X319PEH: FWS_5=WD\FFW^7_/?X)#@?Y%[?9W[O:FO4WX#`DBW7,```X ` end Edit this bug report at http://bugs.php.net/?id=12841edit=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] Webmail Problem
Hello, I have installed 6xmailer webmail application and configured it properly. but when i log in it gives following errors.If any body can help me, please mail me at [EMAIL PROTECTED] address. Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 146 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 148 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 215 Warning: Undefined property: disposition in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 216 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 146 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 148 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 154 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 146 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 148 thank you, Siddharth -- 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] Webmail Problem
Hallo, This is not a bug, you should change the errorlevel in php.ini. Please ask on the [EMAIL PROTECTED] for support. Derick On Wed, 5 Sep 2001, Siddharth Paralikar wrote: Hello, I have installed 6xmailer webmail application and configured it properly. but when i log in it gives following errors.If any body can help me, please mail me at [EMAIL PROTECTED] address. Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 146 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 148 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 215 Warning: Undefined property: disposition in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 216 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 146 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 148 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 154 Warning: Undefined property: type in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 126 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 146 Warning: Undefined property: encoding in d:\program files\apache group\apache\htdocs\webmail\functions.php on line 148 thank you, Siddharth -- 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] Derick Rethans - PHP: Scripting the Web - www.php.net - [EMAIL PROTECTED] SRM: Site Resource Manager - www.vl-srm.net - -- 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 #13147: 32bit integer
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: *General Issues Bug description: 32bit integer for ( $i = 0; $i 100; $i++ ) echo crc32(rand(1,10 * $i)).BR; works differently on alpha and intel machines. on intel it outputs values from -2G to 2G, but on alpha 0 to 4G. I dont i`m not sure that its not a feature. I tryd to avoid this by sprintf(%u, crc32(...)) but this doesnt seems to work on alpha (php 4.0.4pl1). Cant upgrade it beacouse thats not my machine to manage. -- Edit bug report at: http://bugs.php.net/?id=13147edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP4.0.7RC1 memory problem
Wez Furlong wrote: (gdb) run -X Starting program: /usr/sbin/httpd -X [Tue Sep 4 14:10:25 2001] [warn] Loaded DSO lib/apache/mod_gzip.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI) Just a stab in the dark, this wouldn't cause the problem, would it? For the sake of eliminating this as a cause, can you try diabling mod_gzip in your apache conf? --Wez. Thanks. I did. I'll try to create script from scrach. (Thanks Zeev) I configured PHP4.0.7RC1 with minimun configuration so that the script runs as is. ./configure --enable-debug -without-mysql --with-apxs --enable-mbstring --enable-memory-limit --with-pgsql I'm taking a look at how PHP is executing the script using gdb ddd to find out how to make a simple script to reproduce the problem. I'm getting better idea (I hope), but I couldn't make simpler one yet... Currently, I set break points to zend_execute.c(1629) ZEND_DO_FCALL zend_execute(EG(active_op_array) TSRMLS_CC); zend_execute.c(1671) ZEND_RETURN if ((EG(active_op_array)-return_reference == ZEND_RETURN_REF) I'm looking at op_array mainly, since PHP keeps executing the same code. If you have suggestion where to set break points or to watch data, I appreciate it. It's pain to run debugger without konwing about source and data structure well. Yasuo Ohgaki _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Bug #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: WINNT SP4 PHP Version: 4.0.5 New Comment: I ported my site to W2K, and as your note indicates the bug does not appear there. I don't care if it is ever fixed for WINNT SP4. Previous Comments: [2001-07-27 12:26:49] [EMAIL PROTECTED] status: open [2001-07-23 10:12:00] [EMAIL PROTECTED] Yes. The little loop script still shows it. Other scripts may or may not show it, but it only appears with the second invocation. It is easy to think it is gone because the first time a script runs it usually doesn't happen. If you haven't backed up the browser and opened the script a second time, it could be hiding. Also, I am running WinNT 4 not w2k. If I can suppress the bug by upgrading to w2k, I might. I have been thinking I might have to move the server to Linux. I am currently running 4.0.4pl because I am not set up to link in the modules I need with 4.0.6. [2001-07-22 09:20:36] [EMAIL PROTECTED] can't repoduce this with the apache module or the cgi (4.0.6) under w2k. is this bug still existant for you? [2001-06-15 09:59:43] [EMAIL PROTECTED] I installed the snapshot from 6/14/2001. I know the installation was successful because PHP issued warnings about not being able to load modules such as GD. I ran it against the small script that demonstrates the defect, and, unfortunately, the defect is still there. [2001-06-14 22:20:21] [EMAIL PROTECTED] please try the latest snapshot from http://www.zend.com/snapshots 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=10904 Edit this bug report at http://bugs.php.net/?id=10904edit=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 #13149: undefined symbol: sasl_set_alloc
From: [EMAIL PROTECTED] Operating system: Linux 2.4.4 PHP version: 4.0.6 PHP Bug Type: Apache related Bug description: undefined symbol: sasl_set_alloc I tried to install Apache 1.3.20 with PHP 4.0.6. Everything compiled without complaining. But if I try to start the httpd the following message occurs: Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: sasl_set_alloc. ldd libphp4.so seems to be ok: libdl.so.2 = /lib/libdl.so.2 (0x40172000) libz.so.1 = /lib/libz.so.1 (0x40176000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0x40186000) libpng.so.2 = /usr/lib/libpng.so.2 (0x401a5000) libtiff.so.3 = /usr/lib/libtiff.so.3 (0x401d7000) libpdf.so.0 = /usr/lib/libpdf.so.0 (0x4021b000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x40246000) libresolv.so.2 = /lib/libresolv.so.2 (0x40274000) libm.so.6 = /lib/libm.so.6 (0x40286000) libnsl.so.1 = /lib/libnsl.so.1 (0x402a5000) libc.so.6 = /lib/libc.so.6 (0x402bc000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x2000) PHP was configured with: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-ldap --with-mysql --enable-track-vars --enable-trans-sid --with-pdflib Apache was configured with: ./configure --prefix=/usr/local/apache --enable-module=most --enable-shared=max Versions of other related packages: openssl-0.9.6a openldap2-devel-2.0.7 Any ideas? -- Edit bug report at: http://bugs.php.net/?id=13149edit=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 #13150: sprintf(%08x,131) generates -80000000
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.0.6 PHP Bug Type: Output Control Bug description: sprintf(%08x,131) generates -8000 sprintf(%08x,131) generates -8000, should generate 8000. That's it! -- Edit bug report at: http://bugs.php.net/?id=13150edit=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 #13150 Updated: sprintf(%08x,131) generates -80000000
ID: 13150 Updated by: stas Reported By: [EMAIL PROTECTED] Status: Open Old Bug Type: Output Control Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.0.6 New Comment: BTW: there's no such interer as 0x8000 in PHP. PHP is limited by signed long. Previous Comments: [2001-09-05 10:09:41] [EMAIL PROTECTED] sprintf(%08x,131) generates -8000, should generate 8000. That's it! Edit this bug report at http://bugs.php.net/?id=13150edit=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] big memory problem with 4.0.6
Hi I have a lot of memory problem with php 4.0.6 ... Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 11520 bytes) with version 4.0.6 I had no problem with my sites moreover I had memory_limit = 8M with php = 4.0.5 with no problem and now I have memory_limit = 16M with 4.0.6 and that even doesn't solve the problem It is very annoying and forced me to keep 4.0.5 on my production servers please forward your advices, comments to [EMAIL PROTECTED] TIA -- Francois-Xavier Bois -- 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 #13151: /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage
From: [EMAIL PROTECTED] Operating system: HP-11 PHP version: 4.0.6 PHP Bug Type: OCI8 related Bug description: /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage Cannot start apache 1.3.20 php 4.0.6 with --with-oci8 enabled: bonnie.root./apps/WEB/sw $ /www/bin/apachectl start /usr/lib/dld.sl: Can't shl_load() a library containing Thread Local Storage: /usr/lib/libcl.2 /usr/lib/dld.sl: Exec format error Syntax error on line 205 of /apps/WEB/apache/conf/httpd.conf: Cannot load /apps/WEB/apache/libexec/libphp4.sl into server: Exec format error my configure options are: CC=/opt/gcc/bin/gcc ./configure --prefix=/apps/WEB/php --with-iconv=/opt/libicon v --with-apxs=/apps/WEB/apache/bin/apxs --with-gd=shared --with-gd=/opt/gd --wit h-zlib-dir=/opt/zlib --with-ttf=/opt/freetype --without-mysql --with-xpm-dir=/op t/xpm --with-png-dir=/opt/libpng --with-gettext=/opt/gettext --with-jpeg-dir=/ opt/jpeg-6 --enable-gd-native-ttf --with-oci8=/oracle/PIRELLI/app/oracle/produc t/8.0.5 --enable-sigchild - without oci8, GD libs are compiled successfully Matteo -- Edit bug report at: http://bugs.php.net/?id=13151edit=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 #13152: odbc_fetch_row uses update cursor on ODBC cursor library
From: [EMAIL PROTECTED] Operating system: WinNT4.0 SP6 PHP version: 4.0.6 PHP Bug Type: ODBC related Bug description: odbc_fetch_row uses update cursor on ODBC cursor library First off: there is no need to. A read-only cursor would do just fine on a PHP. On a PHP-script it is impossible to update any data via a open cursor. This would avoid the infamous SL002: Positioned request could not be performed because result set was created by a join condition. The error can be reproduced by simply executing a SQL-clause with a join in it on a MS SQL 7.x or greater. Joins on a MS SQL (or Sybase) are not updateable so a read-only cursor is required. Also it would be nice to warn users that odbc_fetch_into cannot be used to retrieve any data selected with a join. -- Edit bug report at: http://bugs.php.net/?id=13152edit=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] big memory problem with 4.0.6
Try a snapshot of current CVS from http://snaps.php.net:8000/php4-200109050735.tar.bz2 and let us know if it is still happening. -Rasmus On Wed, 5 Sep 2001, fx wrote: Hi I have a lot of memory problem with php 4.0.6 ... Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 11520 bytes) with version 4.0.6 I had no problem with my sites moreover I had memory_limit = 8M with php = 4.0.5 with no problem and now I have memory_limit = 16M with 4.0.6 and that even doesn't solve the problem It is very annoying and forced me to keep 4.0.5 on my production servers please forward your advices, comments to [EMAIL PROTECTED] TIA -- Francois-Xavier Bois -- 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] big memory problem with 4.0.6
fx wrote: with version 4.0.6 I had no problem with my sites moreover I had memory_limit = 8M with php = 4.0.5 with no problem and now I have memory_limit = 16M with 4.0.6 and that even doesn't solve the problem Wasn't there a patch for 4.06's memory limit on http://php.net/downloads.php ? regards Wagner -- Never attribute to malice what can as easily be the result of incompetence. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: PHP4.0.7RC1 memory problem
Hey, I encounter a similar problem now, albeit intermittently: I have no ideas; I don't think I had this problem before Zeev fixed those two session and output buffering bugs. --Wez. Program received signal SIGSEGV, Segmentation fault. 0x4010922a in chunk_free (ar_ptr=0x401942c0, p=0x8d44bc0) at malloc.c:3049 3049malloc.c: No such file or directory. (gdb) bt #0 0x4010922a in chunk_free (ar_ptr=0x401942c0, p=0x8d44bc0) at malloc.c:3049 #1 0x401091cf in free () at malloc.c:2952 #2 0x40317328 in shutdown_memory_manager () at zend_alloc.c:582 #3 0x403482e5 in php_request_shutdown () at main.c:628 #4 0x4034411a in apache_php_module_main () at sapi_apache.c:100 #5 0x40345038 in send_php (r=0x86cb1f8, display_source_mode=0, filename=0x86cdaf0 /home/CLIENTWEB/worlddo/www/managedo/my/index.php) at mod_php4.c:575 #6 0x403450c3 in send_parsed_php (r=0x86cb1f8) at mod_php4.c:590 #7 0x8054405 in ap_invoke_handler () #8 0x8063dcc in process_request_internal () #9 0x8063e31 in ap_process_request () #10 0x805d539 in child_main () #11 0x805d6cc in make_child () #12 0x805d7f1 in startup_children () #13 0x805dcc0 in standalone_main () #14 0x805e38f in main () #15 0x400cfa8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 -- 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] Zend engine bug
Hi guys, Just looking through some older bugs. #13007 is a bug in the Zend engine. The problem is the zval.value.lval is overflowing. The zendi_convert_to_long() macro converts doubles to unsigned long ints as follows: (l) = (d) LONG_MAX ? (unsigned long) (d) : (long) (d); It cannot do this since l (zval.value.lval) is signed. This also means that other functions using using zendi_convert_to_long() are busted: modulus and rest of the bitwise implementation. What's the solution? Well, certainly not to make lval unsigned or use long long (since some platforms do not support). The main issue is that due to the way variables in PHP are initialised, users are given the impression that integer variables have no maximum sizes. By the same token, it makes no sense to limit bitwise and mod operations to numbers under LONG_MAX. The easiest hack would be to promote the type of the other value to double and return that as the result. But will this break anything? Gavin -- 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] Zend engine bug
This piece of code is pretty new; It was written in that way to make it possible to store IPs. In what cases do you see a problem with that? If (d) is bigger than LONG_MAX, than you're screwed anyway. Zeev At 19:20 05-09-01, Gavin Sherry wrote: Hi guys, Just looking through some older bugs. #13007 is a bug in the Zend engine. The problem is the zval.value.lval is overflowing. The zendi_convert_to_long() macro converts doubles to unsigned long ints as follows: (l) = (d) LONG_MAX ? (unsigned long) (d) : (long) (d); It cannot do this since l (zval.value.lval) is signed. This also means that other functions using using zendi_convert_to_long() are busted: modulus and rest of the bitwise implementation. What's the solution? Well, certainly not to make lval unsigned or use long long (since some platforms do not support). The main issue is that due to the way variables in PHP are initialised, users are given the impression that integer variables have no maximum sizes. By the same token, it makes no sense to limit bitwise and mod operations to numbers under LONG_MAX. The easiest hack would be to promote the type of the other value to double and return that as the result. But will this break anything? Gavin -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend engine bug
On Wed, 5 Sep 2001, Zeev Suraski wrote: In what cases do you see a problem with that? If (d) is bigger than LONG_MAX, than you're screwed anyway. I presume you are refering to my proposed hack? Perhaps a little more detail =). If the type of either operand is greater than long, it cannot be demoted (from double) without overflowing lval and giving unexpected results. Instead, the relevant operations could be performed on unsigned longs, with the result being cast to the most appropriate type (double or long) based on whether op1 op2 = LONG_MAX. Zeev Gavin -- 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] Zend engine bug
At 19:58 05-09-01, Gavin Sherry wrote: On Wed, 5 Sep 2001, Zeev Suraski wrote: In what cases do you see a problem with that? If (d) is bigger than LONG_MAX, than you're screwed anyway. I presume you are refering to my proposed hack? Perhaps a little more detail =). Nope :) I was actually referring to the way the code looks like right now. If the type of either operand is greater than long, it cannot be demoted (from double) without overflowing lval and giving unexpected results. But when you overflow an integer, you get unexpected results. The only thing this code does is that in certain cases, where the lval would have been overflown and populated with meaningless info, instead, it populates it as if it's an unsigned long. If you use this information bitwise, then it's useful. Instead, the relevant operations could be performed on unsigned longs, with the result being cast to the most appropriate type (double or long) based on whether op1 op2 = LONG_MAX. Can you give an example of something that doesn't work with the way the code is currently? Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Zend engine bug
On Wed, 5 Sep 2001, Zeev Suraski wrote: If the type of either operand is greater than long, it cannot be demoted (from double) without overflowing lval and giving unexpected results. But when you overflow an integer, you get unexpected results. The only thing this code does is that in certain cases, where the lval would have been overflown and populated with meaningless info, instead, it populates it as if it's an unsigned long. If you use this information bitwise, then it's useful. This is where the problem is coming in, and this is what would be solved. Numbers over LONG_MAX are treated as doubles and cast to unsigned long. It doesn't solve the problem. That would involved one of two things: people can only perform bitwise/mod on long ints or zval supports precision arithmetic values. The latter would be a fair bit of work and cost plenty of memory unless the BCMath precision support was extended to bitwise (it currently solves the mod problem). Instead, the relevant operations could be performed on unsigned longs, with the result being cast to the most appropriate type (double or long) based on whether op1 op2 = LONG_MAX. Can you give an example of something that doesn't work with the way the code is currently? echo (2147483649 2147483649); echo (2147483649 % 5); etc. Zeev Gavin -- 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 #13153: Some functions calls made Apache Segfault
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Apache related Bug description: Some functions calls made Apache Segfault Hello all, Some weird bugs were found playing with Apache 1.3.20 and PHP 4.0.6. Apache reported that some child process died after a Segfault. I have tracked a little the .php files, not all are crashing Apache. I found the nasty sequences in one of them : this works fine: setcookie(cookie ,$date_now , time()+24*3600 , p.php ); this makes some Apache child process segfault: setcookie(cookie); funny isn't it ? :) I have tried with and without output buffering, removing mysql and mhash modules, nothing changes. After installing 4.0.5 debian packages everything went ok. Other php pages made Apache segfault( without setcookie() calls ). I haven't tracked them. Hope this will help :) Regards, -- Edit bug report at: http://bugs.php.net/?id=13153edit=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 #13153 Updated: Some functions calls made Apache Segfault
ID: 13153 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old Status: Open Status: Closed Bug Type: Apache related Operating System: Linux PHP Version: 4.0.6 New Comment: This has been fixed in CVS and will be in 4.0.7 Previous Comments: [2001-09-05 14:05:06] [EMAIL PROTECTED] Hello all, Some weird bugs were found playing with Apache 1.3.20 and PHP 4.0.6. Apache reported that some child process died after a Segfault. I have tracked a little the .php files, not all are crashing Apache. I found the nasty sequences in one of them : this works fine: setcookie(cookie ,$date_now , time()+24*3600 , p.php ); this makes some Apache child process segfault: setcookie(cookie); funny isn't it ? :) I have tried with and without output buffering, removing mysql and mhash modules, nothing changes. After installing 4.0.5 debian packages everything went ok. Other php pages made Apache segfault( without setcookie() calls ). I haven't tracked them. Hope this will help :) Regards, Edit this bug report at http://bugs.php.net/?id=13153edit=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 #10904 Updated: php.exe accesses unreadable memory and crashes
ID: 10904 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Reproducible crash Operating System: WINNT SP4 PHP Version: 4.0.5 New Comment: So we'll forget about it.. Previous Comments: [2001-09-05 09:57:39] [EMAIL PROTECTED] I ported my site to W2K, and as your note indicates the bug does not appear there. I don't care if it is ever fixed for WINNT SP4. [2001-07-27 12:26:49] [EMAIL PROTECTED] status: open [2001-07-23 10:12:00] [EMAIL PROTECTED] Yes. The little loop script still shows it. Other scripts may or may not show it, but it only appears with the second invocation. It is easy to think it is gone because the first time a script runs it usually doesn't happen. If you haven't backed up the browser and opened the script a second time, it could be hiding. Also, I am running WinNT 4 not w2k. If I can suppress the bug by upgrading to w2k, I might. I have been thinking I might have to move the server to Linux. I am currently running 4.0.4pl because I am not set up to link in the modules I need with 4.0.6. [2001-07-22 09:20:36] [EMAIL PROTECTED] can't repoduce this with the apache module or the cgi (4.0.6) under w2k. is this bug still existant for you? [2001-06-15 09:59:43] [EMAIL PROTECTED] I installed the snapshot from 6/14/2001. I know the installation was successful because PHP issued warnings about not being able to load modules such as GD. I ran it against the small script that demonstrates the defect, and, unfortunately, the defect is still there. 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=10904 Edit this bug report at http://bugs.php.net/?id=10904edit=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 #13154: ODBC query to Openingres 2.0 fail with scs_p_GetTblAttribs: DRV_DDTables failed
From: [EMAIL PROTECTED]
Operating system: Solaris 8
PHP version: 4.0.6
PHP Bug Type: ODBC related
Bug description: ODBC query to Openingres 2.0 fail with scs_p_GetTblAttribs:
DRV_DDTables failed
No queries can be made with PHP 4 and Openlink ODBC to access OpenIngres.
Test program:
? echo Teste de ODBCP ;
$odbc = odbc_connect(Desenv , notes, notes, SQL_CUR_USE_IF_NEEDED
);
echo ODBC_CONNECT return code: $odbc ;
$query = select matrica from srhtb002;
$queryprep = odbc_prepare ($odbc, $query); // This produces the error.
$result = odbc_execute($queryprep );
print ok. result = $result;
$nextrow = odbc_fetch_row($result, 1);
if (! $nextrow ) {
print Nco achou nada...br;
}
else {
print odbc_result($result , 1 );
print br;
print odbc_result($result , 2 );
}
?
The configure line is:
./configure --enable-track-vars --with-yp --with-apxs --with-oci8
--with-iodbc=/software/openlink/odbcsdk
--
Edit bug report at: http://bugs.php.net/?id=13154edit=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 #13150 Updated: sprintf(%08x,131) generates -80000000
ID: 13150 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.0.6 Previous Comments: [2001-09-05 10:09:41] [EMAIL PROTECTED] sprintf(%08x,131) generates -8000, should generate 8000. That's it! Edit this bug report at http://bugs.php.net/?id=13150edit=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 #13150 Updated: sprintf(%08x,131) generates -80000000
ID: 13150 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Scripting Engine problem Operating System: linux PHP Version: 4.0.6 New Comment: Do you have a workaround? Previous Comments: [2001-09-05 10:20:41] [EMAIL PROTECTED] BTW: there's no such interer as 0x8000 in PHP. PHP is limited by signed long. [2001-09-05 10:09:41] [EMAIL PROTECTED] sprintf(%08x,131) generates -8000, should generate 8000. That's it! Edit this bug report at http://bugs.php.net/?id=13150edit=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] any reason this is inline?
I see the following in rand.c, any reason for the inline declaration? static inline php_uint32 randomMT(TSRMLS_D) ?? I just removed it, please object if I've done something wrong here :) -Sterling -- 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 #13138 Updated: constants behave weird in static hash arrays
ID: 13138
Updated by: joey
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Closed
Bug Type: Scripting Engine problem
Operating System: linux
PHP Version: 4.0.4pl1
New Comment:
Great. If you still have problems, please reopen.
Previous Comments:
[2001-09-04 16:51:52] [EMAIL PROTECTED]
Please try a more recent version of PHP. 4.0.7RC1 gives
me:
array(1) {
[1]=
bool(true)
}
array(1) {
[1]=
bool(true)
}
[2001-09-04 13:23:25] [EMAIL PROTECTED]
I think the following piece of code behaves sort of weird:
?
define ('A', 1);
function test()
{
$a = array(1 = true);
static $stat_a = array(A = true);
var_dump($a);
var_dump($stat_a);
}
test();
?
result is:
array(1) {
[1]=
bool(true)
}
array(1) {
[A]=
bool(true)
}
I'm not sure whether static variables are supposed to evaluate expressions but even if
they were not, the engine should at least issue a warning.
Edit this bug report at http://bugs.php.net/?id=13138edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Wed, 05 Sep 2001, Sterling Hughes wrote: sterling Wed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standardrand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) I have to ask once again. Why not use zend_parse_parameters() while you are cleaning up API anyway? -Andrei Complexity in the mind is not caused by learning; learning is caused by complexity in the mind. -- Steven Pinker -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Wed, 5 Sep 2001, Andrei Zmievski wrote: On Wed, 05 Sep 2001, Sterling Hughes wrote: sterlingWed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standard rand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) I have to ask once again. Why not use zend_parse_parameters() while you are cleaning up API anyway? I dunno, I'm not used to it, brain no like new information! Isn't more of an extension thing though? I'm not sure, but I remember Zeev saying that it was slower, so should it be used in the core set of functions? If it is, I'll start use zend_parse_parameters() in future cleanups though... -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Wed, 05 Sep 2001, Sterling Hughes wrote: sterling Wed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standardrand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) I have to ask once again. Why not use zend_parse_parameters() while you are cleaning up API anyway? I dunno, I'm not used to it, brain no like new information! Isn't more of an extension thing though? I'm not sure, but I remember Zeev saying that it was slower, so should it be used in the core set of functions? If it is, I'll start use zend_parse_parameters() in future cleanups though... It is slower in the case of functions that don't take any arguments. For ones that do take arguments I don't see a performance issue. And the error message it produces is more informative. -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Wed, 5 Sep 2001 [EMAIL PROTECTED] wrote: On Wed, 05 Sep 2001, Sterling Hughes wrote: sterlingWed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standard rand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) I have to ask once again. Why not use zend_parse_parameters() while you are cleaning up API anyway? I dunno, I'm not used to it, brain no like new information! Isn't more of an extension thing though? I'm not sure, but I remember Zeev saying that it was slower, so should it be used in the core set of functions? If it is, I'll start use zend_parse_parameters() in future cleanups though... It is slower in the case of functions that don't take any arguments. For ones that do take arguments I don't see a performance issue. And the error message it produces is more informative. Ok, I'm sold... I understand the basics of the format and the function, but is the following possible?:: In the situation of rand() when its that are two arguments are mandatory, or no arguments are mandatory? Ie, rand() is valid and rand(1, 100) is valid, but rand(32) is not valid? -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Wed, 05 Sep 2001, Sterling Hughes wrote: Ok, I'm sold... I understand the basics of the format and the function, but is the following possible?:: In the situation of rand() when its that are two arguments are mandatory, or no arguments are mandatory? I failed to parse this sentence at first, but then I remembered the Bronx clean-up that Rasmus did on your XSLT stuff and it helped. :) Ie, rand() is valid and rand(1, 100) is valid, but rand(32) is not valid? You can use regular ZEND_NUM_ARGS() check for the first case and use zend_parse_parameters() for the second. -Andrei Any sufficiently advanced Operating System is indistinguishable from Linux. - Jim Dennis -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
At 23:35 05-09-01, Sterling Hughes wrote: On Wed, 5 Sep 2001, Andrei Zmievski wrote: On Wed, 05 Sep 2001, Sterling Hughes wrote: sterlingWed Sep 5 16:52:45 2001 EDT Modified files: /php4/ext/standard rand.c Log: a bit of api cleanup... move range stuff into a macro (properly :) I have to ask once again. Why not use zend_parse_parameters() while you are cleaning up API anyway? I dunno, I'm not used to it, brain no like new information! Isn't more of an extension thing though? I'm not sure, but I remember Zeev saying that it was slower, so should it be used in the core set of functions? If it is, I'll start use zend_parse_parameters() in future cleanups though... I don't think I ever said they're slower. I asked Andrei if he ever tested their performance, and he said he didn't. So we don't know :) Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Wed, 5 Sep 2001, Andrei Zmievski wrote: On Wed, 05 Sep 2001, Sterling Hughes wrote: Ok, I'm sold... I understand the basics of the format and the function, but is the following possible?:: In the situation of rand() when its that are two arguments are mandatory, or no arguments are mandatory? I failed to parse this sentence at first, but then I remembered the Bronx clean-up that Rasmus did on your XSLT stuff and it helped. :) da, dat is goot ;) Ie, rand() is valid and rand(1, 100) is valid, but rand(32) is not valid? You can use regular ZEND_NUM_ARGS() check for the first case and use zend_parse_parameters() for the second. done :) -Sterling -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /ext/standard rand.c
On Thu, 06 Sep 2001, Zeev Suraski wrote: I don't think I ever said they're slower. I asked Andrei if he ever tested their performance, and he said he didn't. So we don't know :) Well, obviously they are slower than the simple zend_get_parameters_* functions, due to the simple reason that they perform error checking and conversion for you. How much slower has not been quantified. -Andrei Hacker: Any person who derives joy from discovering ways to circumvent limitations. -- 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 #13155: PEAR HTML/Common.php Warning: Undefined offset
From: [EMAIL PROTECTED]
Operating system: All I guess
PHP version: 4.0CVS-2001-09-05
PHP Bug Type: Unknown/Other Function
Bug description: PEAR HTML/Common.php Warning: Undefined offset
I hope this is the right place for this. Do let me know if it isnt.
Looks like _parseAttributes has a minor warning being generated when
error_reporting (E_ALL);
is on and
$headerStyle = bgcolor=blue nowrap;
and then
$table - addRow($contents=$header_row, $headerStyle, 'TH');
whilst using HTML/Table.php from PEAR.
This diff corrects the problem, but I'm sure the author would produce a
better solution:
121a122,124
if (! isset ($regs[7][$valCounter])) {
$regs[7][$valCounter] = 0;
}
Rickey.
--
Edit bug report at: http://bugs.php.net/?id=13155edit=1
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: The rand() can of worms
Bad points: 1) Leaks 2) Inconsistent style 3) Really bizzare macros, etc. Let's put one thing straigt: I merged it already in this early stage (I KNEW it wasn't yet the way it should be, for example the macro thingy: It started out as 2line-macro's, but went bigger. In the optimization and reflection stage, I certainly whould have converted it to a function, but that stage wasn't yet reached) because I thought I would FINALLY ** get comments on the whole thing (AND NOT ABOUT THE PRECISE IMPLEMENTATION, SINCE I STATED VERY CLEARLY THAT WAS NOT YET WHERE YOU NEEDED TO PAY ATTENTION TO). Maybe you don't understand my way of coding (emphasis on CORRECTNESS, the rest comes in later stages). In fact I was REALLY in fast-coding mode because I wanted to commit/merge it before the big part of that introduction I was co-organising. I thought you would be able to discuss it, so after I had time again, I could react to it (in fact, I even doubted wether I got any reactions, since you all didn't seem to care about rand()). I really dislike the way you are handling with this issue: first silently agree, and when nearly FINISHED, go do difficult. In the Netherlads we have a word for this kind of people, but I'm not going to write it down here... --jeroen (still very angry) -- 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] Rand again
Hm, I notice there has been a huge discussion on php-dev, I think I'm going to read it first... My two previous mails were sent without having read the whole discussion. As I was tought, you shouldn't 'conclude' a discussion before everyone is heard, and I wasn't able to read and/or reply to newsgroup-messages (just mail... that explains occasional replies). --jeroen -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The rand() can of worms
I really dislike the way you are handling with this issue: first silently agree, I keep seeing this thrown around. 'Silent approval' is an interesting concept. How do you distinguish it from 'silent disapproval'? Are you sure you didn't make an assumption about the way people felt? (We have a saying here in the US about what happens when you assume, but I won't write it down here). Also, as has been pointed out numerous times that there is a huge difference between agreeing with someone's idea (although even this much wasn't clear to me), and agreeing to a given implementation. George -- 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 #13156: php segfaults on imap_sort
From: [EMAIL PROTECTED] Operating system: Linux 2.2.16 PHP version: 4.0CVS-2001-09-05 PHP Bug Type: IMAP related Bug description: php segfaults on imap_sort When sorting big folders (4500 msgs) php crashes with a segfault and produces this bt: Program received signal SIGSEGV, Segmentation fault. 0x4010d55c in realloc () at malloc.c:3135 3135malloc.c: No such file or directory. (gdb) bt #0 0x4010d55c in realloc () at malloc.c:3135 #1 0x81de067 in fs_resize (block=0x8559b98, size=2048) at fs_unix.c:46 #2 0x81ef766 in imap_sort (stream=0x84f8e60, charset=0x0, spg=0x851da98, pgm=0x83ca1f0, flags=1) at imap4r1.c:1629 #3 0x81d37d6 in mail_sort (stream=0x84f8e60, charset=0x0, spg=0x851da98, pgm=0x83ca1f0, flags=1) at mail.c:3557 #4 0x80aa5b9 in zif_imap_sort (ht=5, return_value=0x8525594, this_ptr=0x0, return_value_used=1) at php_imap.c:2532 #5 0x817f0ba in execute (op_array=0x8445090) at ./zend_execute.c:1590 #6 0x817f298 in execute (op_array=0x83c6874) at ./zend_execute.c:1630 #7 0x815a274 in zend_execute_scripts (type=8, file_count=3) at zend.c:807 #8 0x80893cf in php_execute_script (primary_file=0xb3c8) at main.c:1310 #9 0x816620c in apache_php_module_main (r=0x831bdac, display_source_mode=0) at sapi_apache.c:90 #10 0x808589e in send_php () #11 0x8085906 in send_parsed_php () #12 0x8189aa9 in ap_invoke_handler () #13 0x819f01f in process_request_internal () #14 0x819f092 in ap_process_request () #15 0x8195c96 in child_main () #16 0x8195e55 in make_child () #17 0x8195fd6 in startup_children () #18 0x819665c in standalone_main () #19 0x8196e8c in main () #20 0x400d3a8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 This is my config line: './configure' \ '--with-mysql=/usr' \ '--with-imap=/home/jan/software/imap-2001' \ '--with-zlib=yes' \ '--with-xml' \ '--with-mcal=/usr' \ '--with-ftp' \ '--with-config-file-path=/etc/httpd' \ '--with-apache=/home/jan/software/apache_1.3.20' \ '--enable-inline-optimization' \ '--enable-track-vars' \ '--enable-magic-quotes' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-ftp' \ '--enable-memory-limit' \ '--enable-wddx' \ '--enable-debug' \ '--with-gettext' \ 'i386-suse-linux-gnu' \ -- Edit bug report at: http://bugs.php.net/?id=13156edit=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 #13156 Updated: php segfaults on imap_sort
ID: 13156 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: Linux 2.2.16 PHP Version: 4.0CVS-2001-09-05 New Comment: This also happened with earlier version at least since the 4.0.7-dev tree. Previous Comments: [2001-09-05 17:40:40] [EMAIL PROTECTED] When sorting big folders (4500 msgs) php crashes with a segfault and produces this bt: Program received signal SIGSEGV, Segmentation fault. 0x4010d55c in realloc () at malloc.c:3135 3135malloc.c: No such file or directory. (gdb) bt #0 0x4010d55c in realloc () at malloc.c:3135 #1 0x81de067 in fs_resize (block=0x8559b98, size=2048) at fs_unix.c:46 #2 0x81ef766 in imap_sort (stream=0x84f8e60, charset=0x0, spg=0x851da98, pgm=0x83ca1f0, flags=1) at imap4r1.c:1629 #3 0x81d37d6 in mail_sort (stream=0x84f8e60, charset=0x0, spg=0x851da98, pgm=0x83ca1f0, flags=1) at mail.c:3557 #4 0x80aa5b9 in zif_imap_sort (ht=5, return_value=0x8525594, this_ptr=0x0, return_value_used=1) at php_imap.c:2532 #5 0x817f0ba in execute (op_array=0x8445090) at ./zend_execute.c:1590 #6 0x817f298 in execute (op_array=0x83c6874) at ./zend_execute.c:1630 #7 0x815a274 in zend_execute_scripts (type=8, file_count=3) at zend.c:807 #8 0x80893cf in php_execute_script (primary_file=0xb3c8) at main.c:1310 #9 0x816620c in apache_php_module_main (r=0x831bdac, display_source_mode=0) at sapi_apache.c:90 #10 0x808589e in send_php () #11 0x8085906 in send_parsed_php () #12 0x8189aa9 in ap_invoke_handler () #13 0x819f01f in process_request_internal () #14 0x819f092 in ap_process_request () #15 0x8195c96 in child_main () #16 0x8195e55 in make_child () #17 0x8195fd6 in startup_children () #18 0x819665c in standalone_main () #19 0x8196e8c in main () #20 0x400d3a8e in __libc_start_main () at ../sysdeps/generic/libc-start.c:93 This is my config line: './configure' \ '--with-mysql=/usr' \ '--with-imap=/home/jan/software/imap-2001' \ '--with-zlib=yes' \ '--with-xml' \ '--with-mcal=/usr' \ '--with-ftp' \ '--with-config-file-path=/etc/httpd' \ '--with-apache=/home/jan/software/apache_1.3.20' \ '--enable-inline-optimization' \ '--enable-track-vars' \ '--enable-magic-quotes' \ '--enable-bcmath' \ '--enable-calendar' \ '--enable-ftp' \ '--enable-memory-limit' \ '--enable-wddx' \ '--enable-debug' \ '--with-gettext' \ 'i386-suse-linux-gnu' \ Edit this bug report at http://bugs.php.net/?id=13156edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: The rand() can of worms
I *NEVER* have anything to say until I have seen the code. Otherwise, it's just a bunch of castles in the air. Okay, that's a point. That is not the custom where I learnwork, actually, there is a saying that design planning is 67% of the job, implementing just 33%. That is if you want a good stable code. (I know, that seems to contradict, but just read on). But, I got no comments at all (except the first time one by Rasmus) on the design. The fact wether something compiles, and how quick it is, is simply irrelevant until the final stage, but people don't seem to agree with me on that point. Compile run is a typical Microsoft approach to programming. In the ideal situation a program won't compile until it is finished, and I'm fine with that. Everybody seems to fall about compile issues and performance problems and leaks. Except for performance problems, which are often related to design, this should have been irrelevant for the discussion (well, not about wether it should already have been merged, but about wether this is the way to go.) And about design, I haven't been given opportunity to discuss about it. I made the mistake to merge it, I shouldn't have done that. But to me it *seemed* the only way to start a discussion. I was really hungry for feedback, which wasn't coming. Apperently because a lot of people go for that compilerun, and discuss afterwards strategy, which is at my place considered the sub-university way of programming. patch that is in such a sorry state by mergeing it to HEAD. Let me know when it is *STABLE*, when it will compile on my machine, and run with a That is the point I make here, I wanted to discuss about the strategy and design. You did have quite some comments on it, and I am of course listening to them. But I didn't get the chance to act according to your remarks/suggestings, rather, it is reverted. Of course, I know now that you really want to have a stable HEAD. But I asked a lot of times to give me feedback on that and other issues, and Zeev even suggested to commit my initial work straight to HEAD. But please you should have let me know that that is an issue with most of you, I only had Zeev's mails as reference, and apperently a lot of people have different feeling about it (or I really misunderstood him of course). --Jeroen PS: it's too much to read all now, so it'll take another day (or two?) before I can get to reply to other mails. -- 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] Fw: [PHP-CVS] cvs: php4 /ext/standard rand_mt.c rand_sys.c
News posts seem to be broken, this is a resent: - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.cvs Sent: Thursday, September 06, 2001 12:03 AM Subject: Re: [PHP-CVS] cvs: php4 /ext/standard rand_mt.c rand_sys.c Andrei Zmievski [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]... On Wed, 05 Sep 2001, Jeroen van Wolffelaar wrote: Just look at the algorithm and you'll see at once it is bogus. Only in the special case that one single key is requested it is correct. Proving it's bogus is trivial, so I'll leave that as an exercise to the reader (I'm serious). There are about 2**31 possibilities for randval. So already when picking 13 elements out of an array, (which can be done in 13! ways), some possibilities are not even possible! Furthermore, it makes simply no sense, just look at the key point, every time r/R, where r and R decrease... that has a really high preference for 'neat' distributions. --Jeroen A little less patronizing, please. I'm very sorry, but this again is an example of simply test things out without reasoning/thinking/proving. Which is IMO very bad. If you simply think about the algorithm, I'm sure you would have seen immediately what was wrong. I must say I didn't do any testing at all with that function, but that's not necessary! -- 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] Fw: The rand() can of worms
Resent - Original Message - From: [EMAIL PROTECTED] Newsgroups: php.dev Sent: Wednesday, September 05, 2001 11:21 PM Subject: Re: The rand() can of worms Bad points: 1) Leaks 2) Inconsistent style 3) Really bizzare macros, etc. Let's put one thing straigt: I merged it already in this early stage (I KNEW it wasn't yet the way it should be, for example the macro thingy: It started out as 2line-macro's, but went bigger. In the optimization and reflection stage, I certainly whould have converted it to a function, but that stage wasn't yet reached) because I thought I would FINALLY ** get comments on the whole thing (AND NOT ABOUT THE PRECISE IMPLEMENTATION, SINCE I STATED VERY CLEARLY THAT WAS NOT YET WHERE YOU NEEDED TO PAY ATTENTION TO). Maybe you don't understand my way of coding (emphasis on CORRECTNESS, the rest comes in later stages). In fact I was REALLY in fast-coding mode because I wanted to commit/merge it before the big part of that introduction I was co-organising. I thought you would be able to discuss it, so after I had time again, I could react to it (in fact, I even doubted wether I got any reactions, since you all didn't seem to care about rand()). I really dislike the way you are handling with this issue: first silently agree, and when nearly FINISHED, go do difficult. In the Netherlads we have a word for this kind of people, but I'm not going to write it down here... --jeroen (still very angry) -- 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 #13157: Sessions created cannotbe red by a bigger script file.
From: [EMAIL PROTECTED] Operating system: Windows - PWS 4 PHP version: 4.0CVS-2001-09-05 PHP Bug Type: Session related Bug description: Sessions created cannotbe red by a bigger script file. When manipulating sessions in short scripts they work but when I try them in a file with more lines the previous session cannot be red and a new one is created. The $PHPSESSID variable is set to the previous session but when I call session_start the old session cannot be re started and the variable ste in it to be red.Can you tell me what is the problem? -- Edit bug report at: http://bugs.php.net/?id=13157edit=1 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] Re: The rand() can of worms
Maybe you don't understand my way of coding (emphasis on CORRECTNESS, the rest comes in later stages). In fact I was REALLY in fast-coding mode because I wanted to commit/merge it before the big part of that introduction I was co-organising. I thought you would be able to discuss it, so after I had time again, I could react to it (in fact, I even doubted wether I got any reactions, since you all didn't seem to care about rand()). Jeroen, I wish you wouldn't take things so personally. You do have to understand that this is a large cooperative project. Committing something that prevents the HEAD branch from building and then disappearing is about the biggest sin you can commit. Yes, it forces *everyone* to notice what you are doing and it sounds like that this was partly the effect you were trying to get. But many of these people are working on their own bits and pieces and by breaking the build you are interrupting everyone from working on their own code. It is not surprising that the reaction was less than positive. If you commit something that breaks the build, which happens, I have done it many times, make sure you will have the time to fix things quickly or if you don't, hold off on committing things that you know might break the build. I have a rather large commit sitting here on my laptop which I would love some comments on, but it is extremely likely to break all sorts of things. I will be adding a temporary configure switch which turns my code on and off and making sure that without the switch nothing changes before I commit this beast. The configure switch may actually be permanent. Need to do a few benchmarks to determine that... -Rasmus -- 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 #13158: When used with sambar, mIrc does not connecy
From: [EMAIL PROTECTED] Operating system: Windoes 98 PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: When used with sambar, mIrc does not connecy Hi! I installed PHP 4.0.6 on a Windows 98 Sambar 5.01 beta 1 web server. When the server is not loading the php DLLs, mIrc can connect very well. when the server is loading the pho DLL'd. mIrc cannot connect on any server. Thanks VB -- Edit bug report at: http://bugs.php.net/?id=13158edit=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 #13157 Updated: Sessions created cannotbe red by a bigger script file.
ID: 13157 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: Session related Operating System: Windows - PWS 4 PHP Version: 4.0CVS-2001-09-05 New Comment: Please ask support questions on the mailing lists: http://www.php.net/support.php Previous Comments: [2001-09-05 20:05:18] [EMAIL PROTECTED] When manipulating sessions in short scripts they work but when I try them in a file with more lines the previous session cannot be red and a new one is created. The $PHPSESSID variable is set to the previous session but when I call session_start the old session cannot be re started and the variable ste in it to be red.Can you tell me what is the problem? Edit this bug report at http://bugs.php.net/?id=13157edit=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 #13159: Dup of 5651 and 8332: Won't load becuase of undefined reference 'uncompress'
From: [EMAIL PROTECTED] Operating system: Linux 7.1 PHP version: 4.0.6 PHP Bug Type: *Compile Issues Bug description: Dup of 5651 and 8332: Won't load becuase of undefined reference 'uncompress' httpd: Cannot load /etc/httpd/modules/libphp4.so into server: /usr/lib/libgd.so: unspecified symbol: uncompress This happend to me with the June 23rd 2001 distribution of 4.0.6 . Adding the --with-zlib to the ./configure resolved the issue. (using DSO modules and --with-mysql=) ((you wanted to know...)) [2001-04-10 09:38:08] [EMAIL PROTECTED] No feedback. If this happens with soon to be released PHP 4.0.5 too, reopen this bug report. --Jani -- Edit bug report at: http://bugs.php.net/?id=13159edit=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 #13159 Updated: Dup of 5651 and 8332: Won't load becuase of undefined reference 'uncompress'
ID: 13159 Updated by: sniper Reported By: [EMAIL PROTECTED] Old Status: Open Status: Bogus Bug Type: *Compile Issues Operating System: Linux 7.1 PHP Version: 4.0.6 New Comment: using --with-zlib is the correct way (for now). Previous Comments: [2001-09-05 21:00:48] [EMAIL PROTECTED] httpd: Cannot load /etc/httpd/modules/libphp4.so into server: /usr/lib/libgd.so: unspecified symbol: uncompress This happend to me with the June 23rd 2001 distribution of 4.0.6 . Adding the --with-zlib to the ./configure resolved the issue. (using DSO modules and --with-mysql=) ((you wanted to know...)) [2001-04-10 09:38:08] [EMAIL PROTECTED] No feedback. If this happens with soon to be released PHP 4.0.5 too, reopen this bug report. --Jani Edit this bug report at http://bugs.php.net/?id=13159edit=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 #13160: Apache fails to start, undefined symbol pg_encoding_to_char
From: [EMAIL PROTECTED] Operating system: Debian Linux - Potato PHP version: 4.0.6 PHP Bug Type: PostgreSQL related Bug description: Apache fails to start, undefined symbol pg_encoding_to_char This looks to be similar/related to http://www.php.net/bugs.php?id=5417 Doing an 'apachectl configtest' with PHP 4.06/Apache 1.3.20/PostgreSQL 7.1.3, I get the following error message. Cannot load /usr/local/apache/libexec/libphp4.so into server: /usr/local/apache/libexec/libphp4.so: undefined symbol: pg_encoding_to_char I fixed it by recompiling PostgreSQL 7.1.3 without '--enable-multibyte', then removing config.cache in PHP and recompiling. ./configure for PHP --- ./configure \ --prefix=/usr/local/apache-1.3.20 \ --with-apxs=/usr/local/apache-1.3.20/bin/apxs \ --with-config-file-path=/usr/local/apache-1.3.20/conf \ --with-gd \ --with-pgsql=/usr/local/pgsql \ --with-mm=/usr/local/lib \ --with-zlib \ --with-zlib-dir=/usr/lib \ --with-xml \ --with-gdbm \ --with-gettext \ --with-openssl=/usr \ --with-ldap=/usr \ --enable--sysvsem \ --enable-sysvshm \ --enable-force-cgi-redirect \ --enable-calendar \ --enable-inline-optimization \ --enable-trans-sid \ --enable-track-vars ./configure for Apache -- EAPI_MM=/usr/local/src/apache/mm-1.1.3 \ SSL_BASE=/usr/local \ ./configure \ --prefix=/usr/local/apache-1.3.20 \ --enable-module=ssl \ --enable-module=most \ --enable-shared=max \ --enable-rule=EAPI \ --enable-rule=SHARED_CORE \ --enable-rule=SHARED_CHAIN \ --enable-module=so ./configure for PostgreSQL -- ./configure --prefix=/usr/local/pgsql \ --enable-multibyte \ --with-openssl=/usr/local/ --enable-syslog (Note: remove '--enable-multibyte' in the above ./configure to eliminate the 'bug') -- Edit bug report at: http://bugs.php.net/?id=13160edit=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 #13161: make delete() as alias of unlink() and unset(), not as just dummy.
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Filesystem function related Bug description: make delete() as alias of unlink() and unset(), not as just dummy. now search by function name, delete() appears. it described: 'this is dummy. for searcher unlink() or unset()'. and on PHP delete() really doesn't work. what about to make it work delete()?, as alias. if arg is file, unlink() refered. or if var, unset() refered. from [ke'izi] : where is [r]? -- Edit bug report at: http://bugs.php.net/?id=13161edit=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] Sybase and Sybase-CT and MSSQL, oh my?
I can't help but notice that MSSQL, Sybase, and Sybase CT-Lib each have their own PHP extension. What I wonder if many people have /not/ noticed is that two of these extensions implement the same C API on different platforms (mssql targetted for Windows systems, sybase targetted for Unix systems), and all three implement the same database protocol on the wire. This was true for MSSQL 4.x and 6.x but the databases and the protocol have evolved different in the two products (MSSQL vs. Sybase) since. Microsoft has not updated DBLibrary since version 6.x so there is a few features available in 7.0 and 2000 there is unsupported in the PHP extension. If Microsoft decides not to update DBLibrary I will start rewriting the extension using a more up to date protocol in order to support all features. I would furthermore prefer to develop the extension to work from both Win32 and *nix clients. In light of this, would it not be to everyone's advantage to consolidate developer efforts and merge the ext/mssql and ext/sybase modules? (Providing appropriate PHP_FALIAS wrappers for backwards compat, of course.) I can't imagine that there is so much difference between these two codebases that we need one extension with a .dsp file and one extension with a config.m4 file. The MSSQL extension (on Win32 only) do have a few functions more but these could be ported into one of the Sybase extensions. Are there other reasons why PHP developers would prefer not to combine these two extensions into one? I dont know muct about Subase and Sybase-ct but I agrre that these extension should be combined into one, with aliases and functionality from the mssql extension to allow access to MSSQL Server 4.x and 6.x from Win32 and *nix clients. - Frank -- 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 #13162: php_value php_admin_value is better to accept (null value)
From: [EMAIL PROTECTED] Operating system: Any PHP version: 4.0.6 PHP Bug Type: Feature/Change Request Bug description: php_value php_admin_value is better to accept (null value) In some cases, I would like to assign null values for some ini entries using php_value or php_admin_value. Currently, php_value auto_prepend_file does not work.I'm not sure if it is acceptable.. -- Edit bug report at: http://bugs.php.net/?id=13162edit=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 #13163: Problems with including from within included files
From: [EMAIL PROTECTED] Operating system: PHP version: 4.0.6 PHP Bug Type: Class/Object related Bug description: Problems with including from within included files There definately seems to be some issues with including or requiring files from within other files that have been included in the same fashion. Say I have a file called test.php in the docroot that includes file1.php. The included file contains some class definitions which inherit from classes defined in file2.php, so at the top of file1.php I have: include_once(file2.php); This does not seem to work. It is finding the file correctly, but I receive Cannot inherit from undefined class errors. If I manually include file2.php within the test.php file along with the file1.php, it works fine. Is this meant to happen, or is it a bug or known issue? -- Edit bug report at: http://bugs.php.net/?id=13163edit=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 #13164: exit function always outputs its status
From: [EMAIL PROTECTED] Operating system: Linux 2.2.19 PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: exit function always outputs its status The 'exit' function always outputs its exit status. This is particularly annoying in command line scripts that need to return an error status like '1', which is printed to stdout before termination. Surely it should not output anything. The programer always can output whatever (s)he likes before calling 'exit'. -- Edit bug report at: http://bugs.php.net/?id=13164edit=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 #13164 Updated: exit function always outputs its status
ID: 13164 Updated by: derick Reported By: [EMAIL PROTECTED] Old Status: Open Status: Analyzed Bug Type: Scripting Engine problem Operating System: Linux 2.2.19 PHP Version: 4.0.6 New Comment: Indeed it does, it's a synonym for die(). I wonder if this is intentional or not. Zeev, Andi? Previous Comments: [2001-09-06 00:48:37] [EMAIL PROTECTED] The 'exit' function always outputs its exit status. This is particularly annoying in command line scripts that need to return an error status like '1', which is printed to stdout before termination. Surely it should not output anything. The programer always can output whatever (s)he likes before calling 'exit'. Edit this bug report at http://bugs.php.net/?id=13164edit=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] CVS Problem
Hello, could someone explain, what this is about? D:\home\php\php4\win32cvs diff cvs server: Diffing . Index: php4dllts.dsp === RCS file: /repository/php4/win32/php4dllts.dsp,v retrieving revision 1.45 diff -u -r1.45 php4dllts.dsp --- php4dllts.dsp 4 Sep 2001 02:20:49 - 1.45 +++ php4dllts.dsp 6 Sep 2001 06:15:18 - @@ -527,14 +527,6 @@ # End Source File # Begin Source File -SOURCE=..\ext\standard\rand_mt.c -# End Source File -# Begin Source File - -SOURCE=..\ext\standard\rand_sys.c -# End Source File -# Begin Source File - SOURCE=..\ext\standard\reg.c # End Source File # Begin Source File D:\home\php\php4\win32cvs commit -mFix Win32 build. cvs commit: Examining . cvs server: sticky tag `HEAD' for file `php4dllts.dsp' is not a branch cvs [server aborted]: correct above errors first! -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: CVS Problem
I probably should have told you that you can fix it by running a cvs update -A (resets sticky tags) (instead of having to checkout again) -Jason From: [EMAIL PROTECTED] Date: 2001/09/06 Thu AM 01:07:53 CDT To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Subject: Re: CVS Problem This problem is usually caused from doing a cvs checkout -r HEAD module instead of cvs checkout module -Jason Hello, could someone explain, what this is about? D:\home\php\php4\win32cvs diff cvs server: Diffing . Index: php4dllts.dsp === RCS file: /repository/php4/win32/php4dllts.dsp,v retrieving revision 1.45 diff -u -r1.45 php4dllts.dsp --- php4dllts.dsp 4 Sep 2001 02:20:49 - 1.45 +++ php4dllts.dsp 6 Sep 2001 06:15:18 - @@ -527,14 +527,6 @@ # End Source File # Begin Source File -SOURCE=..\ext\standard\rand_mt.c -# End Source File -# Begin Source File - -SOURCE=..\ext\standard\rand_sys.c -# End Source File -# Begin Source File - SOURCE=..\ext\standard\reg.c # End Source File # Begin Source File D:\home\php\php4\win32cvs commit -mFix Win32 build. cvs commit: Examining . cvs server: sticky tag `HEAD' for file `php4dllts.dsp' is not a branch cvs [server aborted]: correct above errors first! -- Sebastian Bergmann Measure Traffic Usability http://sebastian-bergmann.de/http://phpOpenTracker.de/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
