Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 / TODO-4.1.txt

[Sterling Hughes]

On Sat, 14 Apr 2001, Andrei Zmievski wrote:

> At 10:10 PM 4/13/01 -0400, you wrote:
> >I don't know, but I'd like to start a branch for the 4.1.0 code in a
> >week or so (or sooner, that's just when I'll have a use for it).  I've
>
> In our model, we start branches for releases and keep working on the main
> trunk.
>

  I think that's in general a good plan.  But I'm loath to commit stuff
  that will break a minor release (and I think there should be a few more
  minor releases before 4.1, even if its just bug fixes).  That's why I
  would suggest for this case a branch might be appropriate, that way work
  and testing, etc. can go on for 4.1 even while minor releases are being
  worked on.

  -Sterling


-- 
PHP Development Mailing List 
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 4.0 Bug #10299 Updated: CPU and Memory Spike

[Chris Adams]

On 14 Apr 2001 20:14:53 -0700, Dan Anderson <[EMAIL PROTECTED]> wrote:
>> 256meg is good for upto about 10 concurrent clients, much more and the
>> server starts to grind, i have 192meg in a box that serves
>> 5000pages/day.
>>
>
>Is this the consensus of the list?  Is PHP THIS much of a hog?  I can't
>really believe this

It's not even remotely true unless you're running PHP as a CGI and using some
particularly resource-intensive code. For reference, I have a development
system with a 500Mhz Athlon and 320MB. This is not a tuned system - somewhat
the opposite, in fact. I have code which queries MySQL to generate some XML and
then uses XSLT to turn it into HTML - this sustains somewhere around 45 hits /
second with 50 simultaneous clients; simple scripts hit ~155 hits / second.

If you were to create a tuned PHP build and run it with a tuned Apache / MySQL
using one of the script caches (Zend, APC, BWare) these numbers would go up
substantially.

Chris

Chris

-- 
PHP Development Mailing List 
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 #10331: configure: test gd functions lacks inclusion of -lpng, -lz

[elkner]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3 i686
PHP version:  4.0.4pl1
PHP Bug Type: GD related
Bug description:  configure: test gd functions lacks inclusion of -lpng, -lz

I'm using shared libgd.so.2.0.0 which supports jpeg, xpm, png and libz. Unfortunately 
php configure does NOT include
libpng and libz in its test, so it gets wrong results.
E.g.:

configure:15759: checking whether to include GD support
configure:16388: checking for gdImageString16 in -lgd
configure:16407: gcc -o conftest -g -O2  -DLINUX=2 -DMOD_SSL=206105 -DEAPI -DUSE
_EXPAT -DSHARED_CORE  -Wl,-rpath,/opt/ssl/lib -L/opt/ssl/lib -Wl,-rpath,/usr/X11
R6/lib -L/usr/X11R6/lib -Wl,-rpath,/usr/local/lib -L/usr/local/lib -L/usr/local/
lib conftest.c -lgd  -lgd -lX11 -lXpm -ljpeg -lcrypto -lssl -lresolv -lm -ldl -l
crypt -lnsl  -lresolv -L/usr/lib -ljpeg -L/usr/X11R6/lib -lXpm -L/usr/X11R6/lib 
-lX11 1>&5
/usr/local/lib/libgd.so: undefined reference to `uncompress'
/usr/local/lib/libgd.so: undefined reference to `png_get_rowbytes'
/usr/local/lib/libgd.so: undefined reference to `png_set_strip_16'
/usr/local/lib/libgd.so: undefined reference to `png_create_read_struct'
...
collect2: ld returned 1 exit status
configure: failed program was:
...


-- 
Edit Bug report at: http://bugs.php.net/?id=10331&edit=1



-- 
PHP Development Mailing List 
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 4.0 Bug #10299 Updated: CPU and Memory Spike

[Goten]

So, I am wondering what will cause the CPU and memory spike?  As I said in 
my previous mesg, include a lot of files and keep reloading the page will 
get the CPU idle time to 0% and then the httpd process hang.


-Original Message-
From: Chris Adams
To: Derek Leung
Sent: 4/15/01 3:21 AM
Subject: Re: [PHP-DEV] RE: PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

In php.dev, you wrote:
 >I did try the snap shot 4/14/2001 4.06dev, it didnt' solve the problem.
 >
 >If 256mb ram , dual 400mhz can only serve around 10 concurrent clients,
this
 >is a MAJOR issue for PHP.  I guess any web language like PERL, Cold
fusion,
 >JSP, servlet can do a LOT more than this with the equipment I am using
right
 >now.

You'd guess wrong. Cold Fusion and, to a lesser degree, Java can't
deliver
anywhere near the performance PHP does (benchmarks on projects I've done
have
had CF at anywhere from 25%-1000% slower than PHP depending on the
operation),
particularly in only 256MB.

Whatever your problem is, it's not intrinsic to PHP. With a single
500Mhz
processor and 320MB of RAM, I have no problem delivering 40-50 hits /
second
sustained with 50 simultaneous clients on pages which are doing MySQL
queries,
returning the results as XML and converting them into HTML with XSLT.
For
simple scripts, that heads north of 360 hits / second.

Note that this is on an unoptimized development system. With a
performance
tuned apache, PHP and MySQL installation and the use of one of the PHP
script
caches, performance usually goes up by at least a factor 3 or so.

Chris


-- 
PHP Development Mailing List 
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 #10330: imap-2001.BETA and imap-ssl support in PHP4

[raul]

From: [EMAIL PROTECTED]
Operating system: i386-slackware-linux-gnu
PHP version:  4.0 Latest CVS (14/04/2001)
PHP Bug Type: IMAP related
Bug description:  imap-2001.BETA and imap-ssl support in PHP4

I've built the imap-2001.BETA toolkit with SSL (OpenSSL 0.9.6a) support and copied the 
c-client header files in a 'standard' location and c-client library files, but when 
compiling PHP4-cvs --with-imap-ssl support I get the following error:

config.nice:

"./configure" \
"--with-apxs" \
"--with-config-file-path=/var/www/conf" \
"--with-gdbm" \
"--with-gettext" \
"--with-imap" \
"--with-imap-ssl" \
"--with-mysql" \
"--with-openssl" \
"--with-regex=system" \
"--with-zlib" \
"--enable-memory-limit" \
"--enable-safe-mode" \
"--enable-track-vars" \
"--enable-bcmath" \
"--enable-wddx" \
"--enable-xml" \

$ make
...
-DTARGET="httpsd" -DUSE_HSREGEX -DUSE_EXPAT -DAPACHE_SSL -DSUPPORT_UTF8 
-DXML_BYTE_ORDER=12 -g -O2  -c php_imap.c
php_imap.c: In function `php_minit_imap':
php_imap.c:450: `auth_ssl' undeclared (first use in this function)
php_imap.c:450: (Each undeclared identifier is reported only once
php_imap.c:450: for each function it appears in.)
make[3]: *** [php_imap.lo] Error 1
make[3]: Leaving directory `/home/raul/src/cvs/php4/ext/imap'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/raul/src/cvs/php4/ext/imap'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/raul/src/cvs/php4/ext'
make: *** [all-recursive] Error 1

~/src/imap-2001.BETA.SNAP-0104140025$ cat c-client/linkage.c
  mail_link (&mboxdriver);  /* link in the mbox driver */
  mail_link (&imapdriver);  /* link in the imap driver */
  mail_link (&nntpdriver);  /* link in the nntp driver */
  mail_link (&pop3driver);  /* link in the pop3 driver */
  mail_link (&mhdriver);/* link in the mh driver */
  mail_link (&mxdriver);/* link in the mx driver */
  mail_link (&mbxdriver);   /* link in the mbx driver */
  mail_link (&tenexdriver); /* link in the tenex driver */
  mail_link (&mtxdriver);   /* link in the mtx driver */
  mail_link (&mmdfdriver);  /* link in the mmdf driver */
  mail_link (&unixdriver);  /* link in the unix driver */
  mail_link (&newsdriver);  /* link in the news driver */
  mail_link (&philedriver); /* link in the phile driver */
  mail_link (&dummydriver); /* link in the dummy driver */
  auth_link (&auth_md5);/* link in the md5 authenticator */
  auth_link (&auth_pla);/* link in the pla authenticator */
  auth_link (&auth_log);/* link in the log authenticator */
  ssl_onceonlyinit ();

Thank you.


Raul


-- 
Edit Bug report at: http://bugs.php.net/?id=10330&edit=1



-- 
PHP Development Mailing List 
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 4.0 Bug #10299 Updated: CPU and Memory Spike

[Dan Anderson]

> I did try the snap shot 4/14/2001 4.06dev, it didnt' solve the problem.
>
> If 256mb ram , dual 400mhz can only serve around 10 concurrent clients,
this
> is a MAJOR issue for PHP.  I guess any web language like PERL, Cold
fusion,
> JSP, servlet can do a LOT more than this with the equipment I am using
right
> now.
>
> 3. more ram
>
> 256meg is good for upto about 10 concurrent clients, much more and the
> server starts to grind, i have 192meg in a box that serves
> 5000pages/day.
>

Is this the consensus of the list?  Is PHP THIS much of a hog?  I can't
really believe this

Dan


-- 
PHP Development Mailing List 
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 4.0 Bug #10299 Updated: CPU and Memory Spike

[Derek Leung]

I did try the snap shot 4/14/2001 4.06dev, it didnt' solve the problem.

If 256mb ram , dual 400mhz can only serve around 10 concurrent clients, this
is a MAJOR issue for PHP.  I guess any web language like PERL, Cold fusion,
JSP, servlet can do a LOT more than this with the equipment I am using right
now. 

-Original Message-
From: Cameron
To: [EMAIL PROTECTED]
Sent: 4/14/01 12:45 PM
Subject: PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

my suggestions

1. update to latest php snap from http://snaps.php.net/

they are "beta" but generally run better than the current release.

2. set your max execution time

change it to as close to possible to the max time any script would
really take, generally something around 3 seconds

3. more ram

256meg is good for upto about 10 concurrent clients, much more and the
server starts to grind, i have 192meg in a box that serves
5000pages/day.

4. try some caching?

http://apc.communityconnect.com/

try it out, it helped me a bit with making a server go a bit faster,
dont use the SHM version with that little ram tho, use the MMAP version.


Cameron Brunner
Senior Web Programmer
inetsalestech.com

[EMAIL PROTECTED] wrote:

> ID: 10299
> User Update by: [EMAIL PROTECTED]
> Status: Open
> Bug Type: Performance problem
> Description: CPU and Memory Spike
>
> This is vmstat show if I keep reloading the script
>
> procs  memory pagedisks faults
cpu
>  r b w avm   fre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us
sy id
>  1 4 0   73860 134324   0   0   0   0   0   2   0  382 3804 258 16
1 83
>  0 4 0   73860 134244   0   0   0   0   0   0   0  357 3789 245 15
4 81
>  1 4 0   73860 134244   0   0   0   0   0   0   0  373 3763 263 14
3 83
>  2 4 0   73860 13416  142   0   0   0 139   0   0   0  402 6155 285 26
4 70
>  0 4 0   73860 134084   0   0   0   4   0  11   0  366 3179 220 11
2 87
>  1 4 0   73860 134004   0   0   0   0   0   0   0  358 3943 257 15
3 82
>  2 4 0   73860 134004   0   0   0   0   0   0   0  340 4201 240 12
42 45
>  2 4 0   73860 134004   0   0   0   0   0   0   0  240 1842  90  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0  19   0  265 1802  98  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  241 1753  93  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  239 1729  96  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  241 1612  94  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  243 1576  97  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  243 1541  98  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  239 1487 102  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  241 1401  93  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  251 1405 100  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  246 1338 101  0
100  0
>  2 4 0   73116 134004   0   0   0   0   0   0   0  238 1297  94  0
100  0
>  2 4 0   73860 134004   0   0   0   0   0   0   2  243 1282 100  0
100  0
>  2 4 0   73860 134004   0   0   0   0   0   0   0  239 1223  89  0
100  0
>  2 4 0   73860 134004   0   0   0   2   0   9  16  300 1180  92  0
100  0
>  procs  memory pagedisks faults
cpu
>  r b w avm   fre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us
sy id
>  3 4 0   73860 134004   0   0   0   0   0   0   0  251 1156  90  0
100  0
>  3 4 0   50296 134004   0   0   0   0   0   6   0  258 1116  93  0
100  0
>  2 4 0   50296 134004   0   0   0   0   0   0   0  240 1108  83  0
100  0
>  3 4 0   50296 134004   0   0   0   0   0   0   0  245 1064  92  0
100  0
>  3 4 0   46988 134004   0   0   0   0   0   0   0  242 1031  83  0
100  0
>  3 4 0   46988 134004   0   0   0   0   0   0   0  242  989  82  0
100  0
>  2 4 0   46988 134004   0   0   0   0   0   0   0  243 1010  85  0
100  0
>  2 4 0   46988 134004   0   0   0   0   0   1   0  241  985  81  0
100  0
>  2 4 0   46988 134004   0   0   0   0   0   0   0  241  971  89  1
99  0
>  2 4 0   46988 134004   0   0   0   0   0   0   0  243  940  74  0
100  0
>  3 4 0   46988 134004   0   0   0   2   0   8   0  250  926  80  0
100  0
>  2 4 0   46988 134004   0   0   0   0   0   1   0  245  930  88  0
100  0
>  3 4 0   46988 134004   0   0   0   0   0   0   0  240  905  80  0
100  0
>  2 4 0   46988 134004   0   0   0   0   0   7   0  253  920 100  0
98  2
>  3 4 0   47332 13056   90   0   0   0   0   0   0   0  239 2113 116  3
97  0
>  2 4 0   46588 130484   0   0   0   0   0   1   0  243 2334 103  1
99  0
>  1 4 0   46244 133924   0   0   0  86   0   8   0  276 4383 140  7
19 74
>  1 4 0   47896 13184   59   0   0   0   0   0   2   0  275  621  56  7
1 92
>  0 4 0   47896 13152   20   0   0   0   0   0   1   0  253  471  46  6
1 93
>  1 4 0   47492 13372   18   0   0   0  64   0   0   0  251  478  

[PHP-DEV] Bug #10329: failed to load module: php4apache.dll under Apache 1.3.19

[gjens]

From: [EMAIL PROTECTED]
Operating system: windows 2000 professionell
PHP version:  4.0.4pl1
PHP Bug Type: Apache related
Bug description:  failed to load module: php4apache.dll under Apache 1.3.19

I installed Apache 1.3.19 and php4.0.4pl1 on Win2k and
tried to load the php4 module into the apache service.
entry in the httpd.conf:
"LoadModule php4_module h:\php\sapi\php4apache.dll"

But the Service cannot start.
error message:
--
Syntax error in line 205 of h:/apache/conf/httpd/conf
Cannot load h:\php\sapi\php4apache.dll into server: (127) The give Procedure wasn´t 
found

(translated)
The German original message:
---
Syntax error in line 205 of h:/apache/conf/httpd/conf
Cannot load h:\php\sapi\php4apache.dll into server: (127) Die angegebene prozedur 
wurde nicht gefunden


I exchanged the php4apache.dll from the distribution "php4.0.4pl1" with the one out of 
"php4.0.4-dev". Then the error message didn't appear, but the service cannot start as 
well!

The same php module is working under Apache 1.3.14 for windows. 

I downloaded the php4.0.4pl1 distribution from php.net, and loaded no modules, the 
php.exe can start without problems as standalone programm.

I'll be very pleased, if someone could help me to fix this Problem

(Before this installation i had running:
apache 1.3.14 and php4.0.4-dev, but had different difficultieswith that release )

Jens Grubert
germany


-- 
Edit Bug report at: http://bugs.php.net/?id=10329&edit=1



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Question about PEAR DB (mysql)

[Chris Newbill]

There are two functions query and simpleQuery...query CAN return a DB_Result
object, simpleQuery returns a resource ID.  When you call fetchRow() with a
DB_Result, it fails because it expects simply a resource and doesn't check
for a DB_Result object.

It's a simple change to make this work.  Is there some magical and
mysterious reason this is so?

Chris Newbill
OneWest.net Inc.,
Programmer/Analyst

406.449.8056
[EMAIL PROTECTED]

/*
Windows crashed.
I am the Blue Screen of Death.
No one hears your screams.
*/


-- 
PHP Development Mailing List 
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 #10328 Updated: install.txt is OUTDATED.

[phildriscoll]

ID: 10328
Updated by: phildriscoll
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Documentation problem
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

It looks ok to me - what's wrong with it?

Previous Comments:
---

[2001-04-14 17:01:41] [EMAIL PROTECTED]
Try and follow the info in install.txt for
setting up PHP4 with Apache on a windows machine.
You can't.

---



ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at http://bugs.php.net/?id=10328&edit=2


-- 
PHP Development Mailing List 
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 #10328: install.txt is OUTDATED.

[armageddon]

From: [EMAIL PROTECTED]
Operating system: Windows 98
PHP version:  4.0.4pl1
PHP Bug Type: Documentation problem
Bug description:  install.txt is OUTDATED.

Try and follow the info in install.txt for
setting up PHP4 with Apache on a windows machine.
You can't.


-- 
Edit Bug report at: http://bugs.php.net/?id=10328&edit=1



-- 
PHP Development Mailing List 
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 Account Request

[CVS Account Request]

Full name: Jeffery Charles Cann
Email: [EMAIL PROTECTED]
ID: jccann
Purpose: PEAR commits

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10327 Updated: "urldecode" decodes url-encoded cyrillic strings incorrectly.

[nikamir]

ID: 10327
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: *URL Functions
Description: "urldecode" decodes url-encoded cyrillic strings incorrectly.

Sorry!
dump of phpinfo() function is here:
http://www.77rus.ru/a.php

Previous Comments:
---

[2001-04-14 13:52:23] [EMAIL PROTECTED]
n";
 //Wrong decoding
 echo "Src-Dst: ".urldecode(urlencode("Çàïèñü óñïåøíî èçìåíåíà"))."n";
 //Write encoding of wrong decoding. See the difference!!!
 echo "Src-Dst-Src: ".urlencode(urldecode(urlencode("Çàïèñü óñïåøíî 
èçìåíåíà")))."n";
?>

'./configure' '--without-x' '--enable-track-vars' 
'--with-apache=../apache_1.3.14rusPL30.0' '--with-mod_charset' '--with-gd' 
'--enable-ftp' '--with-mysql=/usr/local' '--with-pcre-regex'


Here you can see dump of phpinfo() function in our
system.
http://www.77rus.ru/manager/questions/a.php



---


Full Bug description available at: http://bugs.php.net/?id=10327


-- 
PHP Development Mailing List 
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 #10327: "urldecode" decodes url-encoded cyrillic strings incorrectly.

[nikamir]

From: [EMAIL PROTECTED]
Operating system: FreeBSD 4.1-RELEASE
PHP version:  4.0.3pl1
PHP Bug Type: *URL Functions
Bug description:  "urldecode" decodes url-encoded cyrillic strings incorrectly.

\n";
 //Wrong decoding
 echo "Src-Dst: ".urldecode(urlencode("Çàïèñü óñïåøíî èçìåíåíà"))."\n";
 //Write encoding of wrong decoding. See the difference!!!
 echo "Src-Dst-Src: ".urlencode(urldecode(urlencode("Çàïèñü óñïåøíî 
èçìåíåíà")))."\n";
?>

'./configure' '--without-x' '--enable-track-vars' 
'--with-apache=../apache_1.3.14rusPL30.0' '--with-mod_charset' '--with-gd' 
'--enable-ftp' '--with-mysql=/usr/local' '--with-pcre-regex'


Here you can see dump of phpinfo() function in our
system.
http://www.77rus.ru/manager/questions/a.php




-- 
Edit Bug report at: http://bugs.php.net/?id=10327&edit=1



-- 
PHP Development Mailing List 
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 / TODO-4.1.txt

[Anil Madhavapeddy]

> Right, so the 4.0.* code would branch off and the HEAD
> revision would become the 4.1.0 (development) tree.

Exactly - you can branch down from a branch as well, so there's no
problem creating further RC branches from the 4.0.* branches.  If you
re-read that sentence, it'll make sense :-)

Anil


-- 
PHP Development Mailing List 
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 / TODO-4.1.txt

[Jon Parise]

On Sat, Apr 14, 2001 at 12:00:20PM -0500, Andrei Zmievski wrote:

> >I don't know, but I'd like to start a branch for the 4.1.0 code in a
> >week or so (or sooner, that's just when I'll have a use for it).  I've
> 
> In our model, we start branches for releases and keep working on the main 
> trunk.
 
Right, so the 4.0.* code would branch off and the HEAD revision would
become the 4.1.0 (development) tree.

-- 
Jon Parise ([EMAIL PROTECTED])  .  Rochester Inst. of Technology
http://www.csh.rit.edu/~jon/  :  Computer Science House Member

-- 
PHP Development Mailing List 
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 / TODO-4.1.txt

[Andrei Zmievski]

At 10:10 PM 4/13/01 -0400, you wrote:
>I don't know, but I'd like to start a branch for the 4.1.0 code in a
>week or so (or sooner, that's just when I'll have a use for it).  I've

In our model, we start branches for releases and keep working on the main 
trunk.

-Andrei


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP Output stream FILE *

[Brian Foddy]

Debugging question here...
For debugging purposes only, is it possible to obtain the 
value of FILE * that represents the PHP/Zend output stream?

I want to use a library function that would greatly assist in debugging
if I can give it a valid FILE * for the output stream.

Basically the FILE * zend_output eventually uses...
Even if its hardcoded it would help.

And if its stdout, I'll really feel silly.  If not, I'll just open a flat file.

Thanks,
Brian



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 3.0 Bug Summary Report

[php-dev]

 PHP 3.0 Bug Database summary - http://bugs.php.net

 Num Status Summary (532 total including feature requests)
===[*General Issues]==
4180 Open   is_link returns false when target doesnt exist (should return true)
9610 Bogus  Dead link
9820 Open   File upload with any input tag
10101 Bogus  apache + mysqld + php3   == libphp3.so incorrect symbol...
===[*Install and Config]==
7386 Feedback   referenced symbol not found when starting Apache
===[Compile Failure]==
1145 Open   Ypu cannot compile with --with-ldap using the Solaris7 bundled 
ldap-libs/header
1298 Open   need to use -taso with Netscape LDAP libs
1461 Open   won't compile with Stronghold 2.2 or 2.3
1933 Open   Unable to compile PHP3 with Oracle8 support
1997 Open   Compilation Problems
2225 Open   Compile error in ldap.c
2282 Open   Compile failure with Stronghold 2.4.1
2490 Open   Perl regular expression functions not available in windows binary
2585 Open   Error linking Oracle 7.3.2 libraries on SCO OpenServer 5.0.4
2658 Open   error while compiling PHP as apache module
2729 Open   Fatal error: Unable to open ???  in - on line 0
2751 Open   Storage size of "buf isn't known
2823 Open   undefined symbol: SQLParamData
2824 Open   Inconsistent parameter list declaration for...
2903 Open   fails to compile ifx.ec, report a syntax-error
3033 Open   Fatal compile error on functions/ldap.c
3185 Open   Undefined symbol
3217 Open   ld error when compiling as Apache DSO and --with-mysql
3218 Open   Can't compile php_ftp.dll
3426 Open   make with iodbc failed and I've found the problem
3501 Open   Compiling errors with Oracle-Funktions
3528 Open   Can't compile php 3.0.14 with Oracle support
3677 Open   files not found
3766 Open   configure doesn't allow for the Oracle N32 client SDK to be used
3776 Open   functions/db.c:107: parse error before '*'
4028 Open   wrong directories included for oracle 8.1.6
4217 Open   IBM DB2 will not compile.
4233 Open   The Interbase module won't compile.
4266 Open   Undeclared variables in function/imap.c starting ar line 435
4392 Open   Compile failure with GD 1.7, possibly others
4412 Open   xml failure
4417 Open   Informix specific parse error in functions/ifx.ec
4544 Open   Incompatiblility with latest (3.0) version of PDFlib
4899 Open   PHP Core Dumps With Apache 1.3.12
7734 Open   missing php3_ifx.h
===[Compile Warning]==
3151 Open   php.exe compile warnings because of arpa/inet.h
6942 Open   php sockets unusable with irix-OS
===[dBase related]
3091 Open   dbase_replace_record miscounts number of fields
3429 Open   Warning: Unable to open database...
4802 Open   php.exe crashes while trying to execute the get_record function
===[DBM/DBA related]==
2890 Open   DBM extension on win32 does not valid database identifier error
3371 Open   dbmfetch reurns an empty string
3423 Open   dbmopen() not thread-safe
3809 Duplicate  DBM extension for Win32 PHP3 is malfunctioning and/or has a flaw
3862 Open   dbmReplace & dbmDelete return inverse value
6720 Open   persistent "Warning: driver initialization failed" on db_open db2 2.7.7
===[Dynamic loading related]==
1188 Open   Configuration not work
1586 Open   In the compiled Win32 package, the php3_ldap doesn't load.
1993 Open   Startup failure of liphp3.so
2027 Open   Can't dynamicly load any extension dll file
2250 Open   nt-service problem
2414 Open   php3_vmailmgr.so refuses to load
2862 Open   LDAP in Win32 Bin dist is linked to MSVCRTD.DLL
3168 Open   cannot start apache 1.3.9 if mysql is compiled in, but can RESTART 
successfully
3292 Open   MySQL module causes DSO to fail.
3321 Open   Apache Complaining about undefined symbol: dlst_first
3659 Open   mod_php + apache w/mod_so hangs in sched_yield
3680 Open   Apache won't start after install php3
3752 Open   Apache configtest dumps core with DSO & versioning
3781 Open   Cannot load /libexec/libphp3.so
3861 Open   php as a dyn. mod. & configured with IBM db2 support prevents svr 
startup
9565 Open   php3_ldap.dll is compiled as DEBUG
===[IMAP related]=
2816 Open   Imap_open error when user_id length=3 char
2847 Open   imap_search - dates don't work
3040 Duplicate  imap_open
3236 Open   Email message bodies show as mime type application/octet-stream/plain
3843 Open   seg fault when recieving headers
6882 Open   

[PHP-DEV] Bug #10326: Error while inserting cyrillic symbols into database

[flying]

From: [EMAIL PROTECTED]
Operating system: Windows NT4 SP6
PHP version:  4.0.4
PHP Bug Type: InterBase related
Bug description:  Error while inserting cyrillic symbols into database

Environment:
  Windows NT 4.0 SP6
  PHP v4.0.4 (binaries from www.php.net)
  InterBase v6.0.0.627
  Apache v1.3.17

 The following is metadata for simple InterBase database and short script that tries 
to insert a range of symbols into this database.
 All works ok while inserting symbols with codes lower than 128, but for all symbols 
with codes greater than 128 (included cyrillic symbols in windows-1251 code page with 
codes in range 192..255) the following error is received:

Warning: InterBase: arithmetic exception, numeric overflow, or string truncation 
Cannot transliterate character between character sets in d:\web\dom\test\qqq.php on 
line 7

 Note, that nothing is actually inserted into database. Executing the same query 
directly into InterBase causes data to be inserted properly

Database metadata:
==
SET SQL DIALECT 3;

SET NAMES WIN1251;

CREATE DATABASE 'D:\db\base.gdb' USER 'user' PASSWORD 'password'
PAGE_SIZE 4096
DEFAULT CHARACTER SET WIN1251;

CREATE GENERATOR GEN_TEST_ID;
SET GENERATOR GEN_TEST_ID TO 0;

CREATE TABLE TEST (
ID INTEGER NOT NULL,
TEXT VARCHAR(100));


SET TERM ^ ;

CREATE TRIGGER TEST_BI FOR TEST
ACTIVE BEFORE INSERT POSITION 0
AS
BEGIN
  IF (NEW.ID IS NULL) THEN
NEW.ID = GEN_ID(GEN_TEST_ID,1);
END
^

SET TERM ; ^

Test PHP script to reproduce bug:
=
";
$query = ibase_query($ib,$sql);
};
ibase_close($ib);
?>



-- 
Edit Bug report at: http://bugs.php.net/?id=10326&edit=1



-- 
PHP Development Mailing List 
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 / TODO-4.1.txt

[Sebastian Bergmann]

Sterling Hughes wrote:
> got a bunch of stuff to put in, a new XSLT extension (syntax *will*
> change, but speed, stability and memory usage are greatly improved, 
> as well as allowing multiple XSLT backends, initial support for 
> Sablotron and libxslt).

  Sounds good.

> I'd also like to put the ADT stuff in 4.1 (nearing completion, still 
> have to work up a good proposal).

  This is good news! I can't wait to get my hands on your ADT stuff,
Sterling.

> a branch at this time or pretty soon would be a good idea. That way 
> we can start preparing for and stabilizing 4.1.

  +1

  PS: What changes to the ZendEngine could be done for a 4.1 release?
No, I'm not starting another ApplicationServer debate, but during the
last one there were a couple of good ideas that should be considerd,
IMHO.

  Happy Easter,
Sebastian

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] TODO: UNC?

[Sebastian Bergmann]

  The "Zend" section of php4/TODO has an entry 

"* make UNC filenames work with V_CD layer"

  in it. Hasn't Daniel fixed this issue for PHP 4.0.6?

-- 
 sebastian bergmann[EMAIL PROTECTED]
   http://www.sebastian-bergmann.de

 bonn.phpug.de | www.php.net | www.phpOpenTracker.de | www.titanchat.de

-- 
PHP Development Mailing List 
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 / TODO-4.1.txt

[Sterling Hughes]

On Sat, 14 Apr 2001, Sebastian Bergmann wrote:

> Stig Bakken wrote:
> >   Log:
> >   here's a preliminary list of stuff for 4.1
>
>   Is there any timeframe for when PHP 4.1.0 will be released?
>

   I don't know, but I'd like to start a branch for the 4.1.0 code in a
   week or so (or sooner, that's just when I'll have a use for it).  I've
   got a bunch of stuff to put in, a new XSLT extension (syntax *will*
   change, but speed, stability and memory usage are greatly improved, as
   well as allowing multiple XSLT backends, initial support for
   Sablotron and libxslt).  I'd also like to put the ADT stuff in 4.1
   (nearing completion, still have to work up a good proposal).  There are
   also some changes in cURL which don't really change the API but would
   be good to announce along with 4.1 (persistent connections)...  That's
   just my stuff (I think I have a bit more for 4.1 too :)...

   I have a feeling from the todo that other people have a bunch of
   patches or things "todo" for 4.1 as well.  Therefore I think setting up
   a branch at this time or pretty soon would be a good idea.  That way we
   can start preparing for and stabilizing 4.1.

   -Sterling


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt

[kpw]

ID: 10324
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Reproduceable crash
Description: reproducable seg fault during generic script exec with pgsql and mcrypt

here's the back trace (again without db symbols) of the crash when it happens after my 
script has completed execution:

Program received signal SIGSEGV, Segmentation fault.
0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111
3111malloc.c: No such file or directory.
(gdb) bt
#0  0xfe21138 in chunk_free (ar_ptr=0xfebb380, p=0x101f03d8) at malloc.c:3111
#1  0xfe20fb0 in __libc_free (mem=0xfebb380) at malloc.c:3023
#2  0xf01121c in ?? () from /etc/apache/libexec/libphp4.so
#3  0x0 in ?? ()
(gdb) 



Previous Comments:
---

[2001-04-14 09:46:01] [EMAIL PROTECTED]
I've rebuilt php with --enable-debug on (rm config.cache & cleaned the build dirs), 
but the db symbols still don't appear in the back trace.  I am using the standard 
build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this 
isn't working as expected.



---

[2001-04-14 07:38:40] [EMAIL PROTECTED]
Can you  try configuring php with --enable-debug, so that better backtraces can be 
made?

---

[2001-04-14 00:19:26] [EMAIL PROTECTED]
Hi,

I've managed to uncover a reproducable segmentation fault that occurs during execution 
of a script containing a loop of pgsql mcrypt calls.  As best as I can tell mcrypt 
doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the 
segfault (although it does seem to change the time/position) when the crash happens.  
Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, 
however, on several occausions I managed to get the script to crash after my code had 
completed and the send buffer had been flushed (only record of a fault was in the 
error log), so I'm  doubtful that the error is in the db code per se. 

Running gdb seems to show that memory is courupt before the script is run the first 
time (after researting apache) as can be seen in the trace below (this first memory 
error is exposed when executing any other script after an apache restart).  Once the 
script runs for a while (it contains a rather expensive loop of db calls) it fails 
with the seg fault.

I've already rebuilt postgres, libmcrypt and php, to no avail...

Any ideas would be most appricated!

Thanks
Kevin


---
build flags:

'./configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' 
'--with-pgsql' '--with-mcrypt'



gdb session:

This GDB was configured as "ppc-yellowdog-linux"...
(gdb) run -X
Starting program: /etc/apache/bin/httpd -X
Cannot access memory at address 0x34623731.
(gdb) bt
#0  _dl_debug_state () at dl-debug.c:56
#1  0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195
#2  0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt

[kpw]

ID: 10324
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Reproduceable crash
Description: reproducable seg fault during generic script exec with pgsql and mcrypt

I've rebuilt php with --enable-debug on (rm config.cache & cleaned the build dirs), 
but the db symbols still don't appear in the back trace.  I am using the standard 
build environment that ships with yellodog/rh 6.2 (gnu), so I am not sure why this 
isn't working as expected.



Previous Comments:
---

[2001-04-14 07:38:40] [EMAIL PROTECTED]
Can you  try configuring php with --enable-debug, so that better backtraces can be 
made?

---

[2001-04-14 00:19:26] [EMAIL PROTECTED]
Hi,

I've managed to uncover a reproducable segmentation fault that occurs during execution 
of a script containing a loop of pgsql mcrypt calls.  As best as I can tell mcrypt 
doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the 
segfault (although it does seem to change the time/position) when the crash happens.  
Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, 
however, on several occausions I managed to get the script to crash after my code had 
completed and the send buffer had been flushed (only record of a fault was in the 
error log), so I'm  doubtful that the error is in the db code per se. 

Running gdb seems to show that memory is courupt before the script is run the first 
time (after researting apache) as can be seen in the trace below (this first memory 
error is exposed when executing any other script after an apache restart).  Once the 
script runs for a while (it contains a rather expensive loop of db calls) it fails 
with the seg fault.

I've already rebuilt postgres, libmcrypt and php, to no avail...

Any ideas would be most appricated!

Thanks
Kevin


---
build flags:

'./configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' 
'--with-pgsql' '--with-mcrypt'



gdb session:

This GDB was configured as "ppc-yellowdog-linux"...
(gdb) run -X
Starting program: /etc/apache/bin/httpd -X
Cannot access memory at address 0x34623731.
(gdb) bt
#0  _dl_debug_state () at dl-debug.c:56
#1  0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195
#2  0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

[goten]

ID: 10299
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: CPU and Memory Spike

I found the problem.  since the script I use have a lot of include and require 
statement.  just a script include a bunch of files and keep reloading the page will 
kill the server in no time.  I attach a sample config file I usually include, just 
make a test.php and include this file like 10 times to simulate a lot of include 
files.  And then, just keep reloading test.php.  You should see the script take a lot 
of CPU time and eventually the httpd eat all the CPU time and the process hang.  From 
command "top", one of the httpd process keep eating up CPU time.

The following is the sample config file 

http://www.test.net/";


// Cookie Setting
$config[cookie_path]  = "/"; # web root directory 
$config[CookieURL] = ".test.net";
$config[cookieTTL] = 7200; // in seconds


$config[minpass]= 3;  # Minimum user password length in characters



/* language and locale */
$config[language]   = "english";# [english] english, [big5] BIG5 code


$config[locale] = "english";# Used for translation of date-related stuff

/* story control */
$config[commentmax] = 4096;
$config[abstractlen]= 4996; #length of abstract show on first page

$config[icon_width] = 100; # Topic icons width
$config[timezone] = "HKT";  #Time zone


$config[limitnews]  = 10;   # default number of stories per page
$config[older_story_num]= 10;   # number of older stories to display

$config[anon_users] = 0; # 1 to allow anonymous postings
 # 0 to disable


/* theme control */

$config[def_theme]  = "Main"; # name of default theme (see themes/ directory for 
list)

/* mail settings */
$config[use_fake_email] = 1; # Displays fake email addresses for users instead of the 
real ones

$config[notifyEmail]= "[EMAIL PROTECTED]"; #address where you want to 
receive notice


//$config[CensorList]   = 
array('fuck','cunt','fucker','fucking','pussy','cock','c0ck','cum','bitch','shit');
$config[CensorList] = array("/fuck/s","/fuck/s","/fuck/s",
"/[a-z]*fuck[a-z]*/is",
"/[a-z]*cunt[a-z]*/is",
"/[a-z]*pussy[a-z]*/is",
"/[a-z]*cock[a-z]*/is",
"/[a-z]*c0ck[a-z]*/is",
"/[a-z]*shit[a-z]*/is",
"/[a-z]*bitch[a-z]*/is",
"/[a-z]*diu[a-z]*/is"
);
# See also specific LOCALE definitions

$config[CensorMode]   = 3;  # 0: no filtering
# 1: exact match
# 2: match word beginnings
# 3: match string anywhere in words
$config[CensorReplace]   =  "[CENSORED]" ;

/* allowable HTML tags. Used by check_html()
   Happily lifted (with mods) from phpslash */
$config[AllowableHTML] = array("p"=>1,   # 2 means accept all qualifiers: 
  "b"=>1,# 1 means accept the tag only: 
  "i"=>1,
  "a"=>2,
  "em"=>1,
  "br"=>1,
  "strong"=>1,
  "blockquote"=>1,
  "img"=>2,
  "tt"=>1,
  "hr"=>1,
  "li"=>1,
  "ol"=>1,
  "div"=>1,
  "ul"=>1);

$config[AllowableHTMLtag] = 
"";


/* poll settings */

$config[maxOptions] = 12;   # maximal number of options allowed
$config[BarScale]   = 1;# scale of result bar (in multiples of 100 pixels)

$config[warnCheaters]   = 1;# 1 - a notice issued on vote second try
# 0 - silently ignores the vote

$config[maxOptions] = 10;


/* story stuff */

$reasons = array('As is',   # "Normal"
'Offtopic', # Bad Responses
'Flamebait',
'Troll',
'Redundant',
'Insightful',   # Good Responses
'Interesting',
'Informative',
'Funny',
'Overrated',# Last two are "special"
'Underrated');



if ($config[dateString] == "") {
switch ($config[locale]) {
// specifier specs can be found on 
http://www.php.net/manual/function.strftime.php  /menthos
case "english": $config[dateString] = "%a, %b %d,%Y @ %I:%M %p"; 
break;
case "french":  $config[dateString] = "%a %d %B %Y à %H:%M"; 
break;
case "german":  $config[dateString] = "%a, %d. %b %Y %H:%M"; break;
 

[PHP-DEV] PHP 4.0 Bug #10322 Updated: Logical error in fopen-wrappers.c

[php-bugrep]

ID: 10322
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
Description: Logical error in fopen-wrappers.c

Thanks for the response, however, can you confirm that there is a logical coding error 
here?

The DOCUMENT_ROOT patch is secondary and would be nice - but is the bug going to be 
fixed in 4.0.5 ?

Regards,

Paul.

Previous Comments:
---

[2001-04-14 05:34:04] [EMAIL PROTECTED]
This will not make it into 4.0.5 as this was branched a while back but it might well 
make it into 4.0.6. Ill get a developer to look at this patch.

- James

---

[2001-04-13 20:57:35] [EMAIL PROTECTED]
I thought, while I'm here, I'd submit a patch to fix this.

The patch also includes support for an additional special case in php.ini's 
open_basedir.
The current "." allows scripts to access files in the same directory as the script.
"DOCUMENT_ROOT" allows a script to access any other file in the virtualhost's 
directory tree.  DOCUMENT_ROOT is calculated by PATH_TRANSLATED and removing 
SCRIPT_URI from the end - This conveniently works for both full Apache Virtalhosts and 
mod_aliased Mass virtual hosting (I don't know if this is true for the newer mod_vhost 
- just check what PATH_TRANSLATED and SCRIPT_URI is set to in phpinfo() - if removing 
the latter from the former is the sites docroot then you are away).

Anyway, the patch: code shamelessly copied from the "." segment :)

*** main/fopen-wrappers.c.orig  Fri Apr 13 17:50:02 2001
--- main/fopen-wrappers.c   Sat Apr 14 01:46:28 2001
***
*** 141,151 
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
int local_open_basedir_pos;
SLS_FETCH();

/* Special case basedir==".": Use script-directory */
!   if ((strcmp(PG(open_basedir), ".") == 0) &&
SG(request_info).path_translated &&
*SG(request_info).path_translated
) {
--- 141,167 
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+   char *local_open_request_uri;
int local_open_basedir_pos;
SLS_FETCH();

+   /* Special case basedir="DOCUMENT_ROOT": Restrict to directory of the
+* virtualhost itself as calculated by PATH_TRANSLATED - SCRIPT_URI
+* [EMAIL PROTECTED]
+*/
+   if ((strcmp(basedir, "DOCUMENT_ROOT") == 0) &&
+   SG(request_info).path_translated &&
+   *SG(request_info).path_translated ) {
+   /* Copy path_translated to local_open_basedir, the look in
+  this string for where request_uri starts and zero that byte
+  thus leaving local_open_basedir set to the virtualhost's
+  DOCUMENT_ROOT */
+   strlcpy(local_open_basedir, SG(request_info).path_translated, si
zeof(local_open_basedir));
+   local_open_request_uri=strstr(local_open_basedir,SG(request_info
).request_uri);
+   if (local_open_request_uri) *local_open_request_uri = '

-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #10299 Updated: CPU and Memory Spike

[goten]

ID: 10299
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: CPU and Memory Spike

This is vmstat show if I keep reloading the script

procs  memory pagedisks faults  cpu
 r b w avm   fre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us sy id
 1 4 0   73860 134324   0   0   0   0   0   2   0  382 3804 258 16  1 83
 0 4 0   73860 134244   0   0   0   0   0   0   0  357 3789 245 15  4 81
 1 4 0   73860 134244   0   0   0   0   0   0   0  373 3763 263 14  3 83
 2 4 0   73860 13416  142   0   0   0 139   0   0   0  402 6155 285 26  4 70
 0 4 0   73860 134084   0   0   0   4   0  11   0  366 3179 220 11  2 87
 1 4 0   73860 134004   0   0   0   0   0   0   0  358 3943 257 15  3 82
 2 4 0   73860 134004   0   0   0   0   0   0   0  340 4201 240 12 42 45
 2 4 0   73860 134004   0   0   0   0   0   0   0  240 1842  90  0 100  0
 2 4 0   73116 134004   0   0   0   0   0  19   0  265 1802  98  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  241 1753  93  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  239 1729  96  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  241 1612  94  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  243 1576  97  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  243 1541  98  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  239 1487 102  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  241 1401  93  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  251 1405 100  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  246 1338 101  0 100  0
 2 4 0   73116 134004   0   0   0   0   0   0   0  238 1297  94  0 100  0
 2 4 0   73860 134004   0   0   0   0   0   0   2  243 1282 100  0 100  0
 2 4 0   73860 134004   0   0   0   0   0   0   0  239 1223  89  0 100  0
 2 4 0   73860 134004   0   0   0   2   0   9  16  300 1180  92  0 100  0
 procs  memory pagedisks faults  cpu
 r b w avm   fre  flt  re  pi  po  fr  sr da0 da1   in   sy  cs us sy id
 3 4 0   73860 134004   0   0   0   0   0   0   0  251 1156  90  0 100  0
 3 4 0   50296 134004   0   0   0   0   0   6   0  258 1116  93  0 100  0
 2 4 0   50296 134004   0   0   0   0   0   0   0  240 1108  83  0 100  0
 3 4 0   50296 134004   0   0   0   0   0   0   0  245 1064  92  0 100  0
 3 4 0   46988 134004   0   0   0   0   0   0   0  242 1031  83  0 100  0
 3 4 0   46988 134004   0   0   0   0   0   0   0  242  989  82  0 100  0
 2 4 0   46988 134004   0   0   0   0   0   0   0  243 1010  85  0 100  0
 2 4 0   46988 134004   0   0   0   0   0   1   0  241  985  81  0 100  0
 2 4 0   46988 134004   0   0   0   0   0   0   0  241  971  89  1 99  0
 2 4 0   46988 134004   0   0   0   0   0   0   0  243  940  74  0 100  0
 3 4 0   46988 134004   0   0   0   2   0   8   0  250  926  80  0 100  0
 2 4 0   46988 134004   0   0   0   0   0   1   0  245  930  88  0 100  0
 3 4 0   46988 134004   0   0   0   0   0   0   0  240  905  80  0 100  0
 2 4 0   46988 134004   0   0   0   0   0   7   0  253  920 100  0 98  2
 3 4 0   47332 13056   90   0   0   0   0   0   0   0  239 2113 116  3 97  0
 2 4 0   46588 130484   0   0   0   0   0   1   0  243 2334 103  1 99  0
 1 4 0   46244 133924   0   0   0  86   0   8   0  276 4383 140  7 19 74
 1 4 0   47896 13184   59   0   0   0   0   0   2   0  275  621  56  7  1 92
 0 4 0   47896 13152   20   0   0   0   0   0   1   0  253  471  46  6  1 93
 1 4 0   47492 13372   18   0   0   0  64   0   0   0  251  478  43  0  1 99
 0 4 0   47492 133724   0   0   0   0   0   0   0  235  440  40  0  0 100
 0 4 0   47492 133724   0   0   0   0   0   0   0  238  442  40  0  2 98

The CPU time drop from 80 all the way to zero and make the Apache hang for like 30 
seconds and the resume back again.  It happens VERY often if I only have like 30 users 
surf the website at the same time.  It pretty much bring the web server down if I have 
around 50 users surft the site

Previous Comments:
---

[2001-04-11 18:03:59] [EMAIL PROTECTED]
I am running on FreeBSD 4.2 Stable, Apache 1.3.19 + PHP 4.0.4pl1 + Modssl on a Dual P2 
400mhz with 256mb ram.  From time to time, one of the httpd process will eat up all 
the CPU time and memory, and after around 5 to 10 seconds, it goes back to normal  
Even a Very simple script like



can make it happen. 1 out of 25 reload of the above script can make the spike happen.  
But the web server do not crash though.  If I run on a script with heavy database 
access, it happen 1 out of 10 if I press reload button continously.

BTW, is that normal for Apache to take up 30% of the CPU time to excute one single 
PHP-data

[PHP-DEV] Bug #10324 Updated: reproducable seg fault during generic script exec with pgsql and mcrypt

[derick]

ID: 10324
Updated by: derick
Reported By: [EMAIL PROTECTED]
Old-Status: Open
Status: Feedback
Bug Type: Reproduceable crash
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

Can you  try configuring php with --enable-debug, so that better backtraces can be 
made?

Previous Comments:
---

[2001-04-14 00:19:26] [EMAIL PROTECTED]
Hi,

I've managed to uncover a reproducable segmentation fault that occurs during execution 
of a script containing a loop of pgsql mcrypt calls.  As best as I can tell mcrypt 
doesn't appear to by the cuplrit as removing the mcrypt calls doesn't prent the 
segfault (although it does seem to change the time/position) when the crash happens.  
Commententing out the Db queries (implemented using PEAR DB) does prevent the crash, 
however, on several occausions I managed to get the script to crash after my code had 
completed and the send buffer had been flushed (only record of a fault was in the 
error log), so I'm  doubtful that the error is in the db code per se. 

Running gdb seems to show that memory is courupt before the script is run the first 
time (after researting apache) as can be seen in the trace below (this first memory 
error is exposed when executing any other script after an apache restart).  Once the 
script runs for a while (it contains a rather expensive loop of db calls) it fails 
with the seg fault.

I've already rebuilt postgres, libmcrypt and php, to no avail...

Any ideas would be most appricated!

Thanks
Kevin


---
build flags:

'./configure' '--prefix=/etc/php' '--with-apxs=/etc/apache/bin/apxs' '--with-mysql' 
'--with-pgsql' '--with-mcrypt'



gdb session:

This GDB was configured as "ppc-yellowdog-linux"...
(gdb) run -X
Starting program: /etc/apache/bin/httpd -X
Cannot access memory at address 0x34623731.
(gdb) bt
#0  _dl_debug_state () at dl-debug.c:56
#1  0xfea2044 in dl_open_worker (a=0x30026c70) at dl-open.c:195
#2  0xfea21f8 in _dl_open (file=0xfea1d44 "224!ÿÀ|b

-- 
PHP Development Mailing List 
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 #10325: Opening database connection breaks ldap

[dan]

From: [EMAIL PROTECTED]
Operating system: Linux 2.4.3
PHP version:  4.0.4pl1
PHP Bug Type: LDAP related
Bug description:  Opening database connection breaks ldap

Opening a database connection breaks LDAP's link index.

Example code:



This generates the error:
PHP Warning: 1 is not a LDAP link index

If you comment out the pg_connect() line, LDAP works fine.
If you pg_close($dbcon) right after the pg_connect(), you still get the PHP error.

This is a definite show stopper considering some people use a database for sessions, 
which means you can't use LDAP
after you start your session.

I'm using the latest openldap 2.0.7 & postgres 7.0.3,
php compiled into apache:
./configure --enable-memory-limit --enable-track-vars --enable-sysvsem 
--enable-sysvshm --with-gd --with-pgsql --with-freetype 
--with-ldap=/usr/local/openldap --with-xml --with-mhash --enable-trans-sid 
--with-kerberos --with-mcrypt --with-apache=../apache_1.3.19 --enable-bcmath 
--with-zlib --with-sockets --enable-inline-optimizations

Please fix soon :)


-- 
Edit Bug report at: http://bugs.php.net/?id=10325&edit=1



-- 
PHP Development Mailing List 
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 #10322 Updated: Logical error in fopen-wrappers.c

[jmoore]

ID: 10322
Updated by: jmoore
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: PHP options/info functions
PHP Version: 4.0.4pl1
Assigned To: 
Comments:

This will not make it into 4.0.5 as this was branched a while back but it might well 
make it into 4.0.6. Ill get a developer to look at this patch.

- James

Previous Comments:
---

[2001-04-13 20:57:35] [EMAIL PROTECTED]
I thought, while I'm here, I'd submit a patch to fix this.

The patch also includes support for an additional special case in php.ini's 
open_basedir.
The current "." allows scripts to access files in the same directory as the script.
"DOCUMENT_ROOT" allows a script to access any other file in the virtualhost's 
directory tree.  DOCUMENT_ROOT is calculated by PATH_TRANSLATED and removing 
SCRIPT_URI from the end - This conveniently works for both full Apache Virtalhosts and 
mod_aliased Mass virtual hosting (I don't know if this is true for the newer mod_vhost 
- just check what PATH_TRANSLATED and SCRIPT_URI is set to in phpinfo() - if removing 
the latter from the former is the sites docroot then you are away).

Anyway, the patch: code shamelessly copied from the "." segment :)

*** main/fopen-wrappers.c.orig  Fri Apr 13 17:50:02 2001
--- main/fopen-wrappers.c   Sat Apr 14 01:46:28 2001
***
*** 141,151 
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
int local_open_basedir_pos;
SLS_FETCH();

/* Special case basedir==".": Use script-directory */
!   if ((strcmp(PG(open_basedir), ".") == 0) &&
SG(request_info).path_translated &&
*SG(request_info).path_translated
) {
--- 141,167 
char resolved_name[MAXPATHLEN];
char resolved_basedir[MAXPATHLEN];
char local_open_basedir[MAXPATHLEN];
+   char *local_open_request_uri;
int local_open_basedir_pos;
SLS_FETCH();

+   /* Special case basedir="DOCUMENT_ROOT": Restrict to directory of the
+* virtualhost itself as calculated by PATH_TRANSLATED - SCRIPT_URI
+* [EMAIL PROTECTED]
+*/
+   if ((strcmp(basedir, "DOCUMENT_ROOT") == 0) &&
+   SG(request_info).path_translated &&
+   *SG(request_info).path_translated ) {
+   /* Copy path_translated to local_open_basedir, the look in
+  this string for where request_uri starts and zero that byte
+  thus leaving local_open_basedir set to the virtualhost's
+  DOCUMENT_ROOT */
+   strlcpy(local_open_basedir, SG(request_info).path_translated, si
zeof(local_open_basedir));
+   local_open_request_uri=strstr(local_open_basedir,SG(request_info
).request_uri);
+   if (local_open_request_uri) *local_open_request_uri = '

-- 
PHP Development Mailing List 
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 / TODO-4.1.txt

[James Moore]

> Stig Bakken wrote:
> >   Log:
> >   here's a preliminary list of stuff for 4.1
>
>   Is there any timeframe for when PHP 4.1.0 will be released?
>
>   PS: When will PHP 4.0.5 be released? :)

Well im not happy with the current state of some bugs in HTTP_AUTH section
and waiting for a reply from Rasmus on this issue then we can have yet
another final RC and release it hopefully.

- James


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] PHP 4.0 Bug #9641 Updated: get_required_files()/get_included_files() does not work as docuemented

[yohgaki]

ID: 9641
User Update by: [EMAIL PROTECTED]
Old-Status: Closed
Status: Open
Bug Type: Documentation problem
Description: get_required_files()/get_included_files() does not work as docuemented

Document is updated to reflect current PHP behavior. (Some what) Problems are still 
there, so I reopen this.

Since include()/require()/include_once()/required_once() behavior has been changed 
recently, descriptions are still incorrect for at least 4.0.4pl1.

I think those functions(lang. constructs) behave almost the same in recent PHP.
(Except require()/require_once() dies when it fails)

include()/require()/include_once()/require_once() now shares the same hash, so result 
of get_included_files()/get_required_files() are the same. These function also lists 
files included by include()/require() due to recent changes in these.

This makes function descriptions still incorrect.

Function descriptions for 
include()/require()/include_once()/require_once()/get_included_files()/get_required_files()
 are needed to be changed to reflect recent changes.

It would be helpful for users, if there are descriptions about changes in 
include()/require()/include_once()/required_once(). (At least which versions supposed 
to work as described)

Hope this helps.


Previous Comments:
---

[2001-03-17 02:18:33] [EMAIL PROTECTED]
documentation updated to reflect new behavior

---

[2001-03-15 09:22:56] [EMAIL PROTECTED]
Now, get_required_files and get_included_files are the same.
Documentation should be changed. 

---

[2001-03-08 18:26:48] [EMAIL PROTECTED]
get_required_files()/get_included_files() does not work as docuemented
http://www.php.net/manual/en/function.get-required-files.php

Tested under Apache 1.3.17 w/ mod-ssl, mod-gzip, and other modules comes with apache. 
RedHat 7.0.1/j. PHP 4.0.4pl1 running as apache module.

I found strange require_once() behaviour (to be reported as bug) and I also found this 
problem.

If this is not a script engine problem, then it should be documentation problem. Hope 
this info helps developer/documentation team.

Following code is identical to the example in manual.
';
echo "Required_once filesn";
print_r (get_required_files());

echo "Included_once filesn";
print_r (get_included_files());

echo date('H:i:s',time());
echo '';

?>

I get

===
Required_once files
Array
(
[0] => /home/httpd/httpd/html/untitled/local.php
[1] => /home/httpd/httpd/html/inc/global.php
[2] => /home/httpd/httpd/html/untitled/util1php
[3] => /home/httpd/httpd/html/untitled/util2php
[4] => /home/httpd/httpd/html/untitled/util3php
[5] => /home/httpd/httpd/html/untitled/util4php
)
Included_once files
Array
(
[0] => /home/httpd/httpd/html/untitled/local.php
[1] => /home/httpd/httpd/html/inc/global.php
[2] => /home/httpd/httpd/html/untitled/util1php
[3] => /home/httpd/httpd/html/untitled/util2php
[4] => /home/httpd/httpd/html/untitled/util3php
[5] => /home/httpd/httpd/html/untitled/util4php
)
08:17:35
===

---


Full Bug description available at: http://bugs.php.net/?id=9641


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]