[PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed.
From: [EMAIL PROTECTED]
Operating system: RH 7
PHP version: 4.0.4
PHP Bug Type: Performance problem
Bug description: Memory is not being freed.
Hi guys,
I do not have much information. I know that my Apache processes memory is growing by
the minute. If I start a separate server on another port and serve only static pages
and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with anything. I know I
need to attach to a process and it seems I can `gdb {pid}` but that gives me nothing.
How can I get some info for you guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
--
Edit Bug report at: http://bugs.php.net/?id=8889edit=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] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which contains a hacked
up solution. It looks like it should be able to turn into a usable end solution.
Previous Comments:
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory is growing by
the minute. If I start a separate server on another port and serve only static pages
and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with anything. I know I
need to attach to a process and it seems I can `gdb {pid}` but that gives me nothing.
How can I get some info for you guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
PHP Development Mailing List http://www.php.net/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9240: unserialize fails non-determenistic on large objects
From: [EMAIL PROTECTED]
Operating system: RedHat 6.2
PHP version: 4.0.4pl1
PHP Bug Type: Variables related
Bug description: unserialize fails non-determenistic on large objects
I'm unserializing a large object using the following test script:
for ($i = 0; $i 20; $i++)
{
echo "$i\n";
$ObjectToCreate = array();
if (!$fp = fopen('test.ser', 'r'))
return false;
$ObjectToCreate = unserialize(fread ($fp, filesize ('test.ser')));
fclose($fp);
}
I get the following output:
0
1
2
3
4
5
6
PHP Warning: unserialize() failed at offset 2150380 of 3601223 bytes in test.inc on
line 8
font color=ffbr
bWarning/b: unserialize() failed at offset 2150380 of 3601223 bytes in
btest.inc/b on line b8/bbr
/font7
8
9
10
11
PHP Warning: unserialize() failed at offset 2822123 of 3601223 bytes in test.inc on
line 8
font color=ffbr
bWarning/b: unserialize() failed at offset 2822123 of 3601223 bytes in
btest.inc/b on line b8/bbr
/font12
13
14
15
16
17
18
19
Repeatedly running the script produces different output each time with different
numbers of failures at different offsets. So far the lowest offset at which I have
had a problem is about 65.
I can supply the 'test.ser' file on request but for obvious reasons do not wish to
include it in this error report!
--
Edit Bug report at: http://bugs.php.net/?id=9240edit=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] PHP 4.0 Bug #9343: Causes server to core
From: [EMAIL PROTECTED] Operating system: linux/solaris (been tested with both) PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Causes server to core Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl will cause the server to core (and this only happens with PHP, jserv, mod_roaming... the rest all work). You can simulate the behavior with Apache::Storage. For some reason, when mod_perl goes to access the module's config list inside of Apache, Apache cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem seems to have returned though. -- Edit Bug report at: http://bugs.php.net/?id=9343edit=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] PHP 4.0 Bug #9344: Causes server to core
From: [EMAIL PROTECTED] Operating system: linux/solaris (been tested with both) PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: Causes server to core Here is the problem. When PHP is installed with mod_perl, certain calls in mod_perl will cause the server to core (and this only happens with PHP, jserv, mod_roaming... the rest all work). You can simulate the behavior with Apache::Storage. For some reason, when mod_perl goes to access the module's config list inside of Apache, Apache cores. This was fixed a while ago and the fix was mentioned on slashdot. The problem seems to have returned though. -- Edit Bug report at: http://bugs.php.net/?id=9344edit=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] PHP 4.0 Bug #9345: PHP as subrequests in Apache
From: [EMAIL PROTECTED] Operating system: doens\'t matter PHP version: 4.0.4pl1 PHP Bug Type: Apache related Bug description: PHP as subrequests in Apache Here is the problem, if you make a call to ap_run_sub_req() with a PHP script with a GET method and content length set to zero, PHP will still gobble up whatever is sitting in the socket. This problematic when you don't want PHP to be the script to answer the POST request. I have tried dinking with a number of things (like remaining, length) and such that make up the request_rec, but PHP seems to be ignoring all of them. -- Edit Bug report at: http://bugs.php.net/?id=9345edit=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] PHP 4.0 Bug #9240 Updated: unserialize fails non-determenistic on large objects
ID: 9240
User Update by: [EMAIL PROTECTED]
Old-Status: Feedback
Status: Open
Bug Type: Variables related
Description: unserialize fails non-determenistic on large objects
I have noticed a tendancy for this to occur when the server is particularly short on
memory. My impression is that it is failing with a "can't unserialize at" error
instead of a memory error.
Previous Comments:
---
[2001-02-22 10:54:03] [EMAIL PROTECTED]
Could you please send me smallest possible object that has
this behaviour? If it's large, please compress it.
---
[2001-02-13 10:38:17] [EMAIL PROTECTED]
I'm unserializing a large object using the following test script:
for ($i = 0; $i 20; $i++)
{
echo "$in";
$ObjectToCreate = array();
if (!$fp = fopen('test.ser', 'r'))
return false;
$ObjectToCreate = unserialize(fread ($fp, filesize ('test.ser')));
fclose($fp);
}
I get the following output:
0
1
2
3
4
5
6
PHP Warning: unserialize() failed at offset 2150380 of 3601223 bytes in test.inc on
line 8
font color=ffbr
bWarning/b: unserialize() failed at offset 2150380 of 3601223 bytes in
btest.inc/b on line b8/bbr
/font7
8
9
10
11
PHP Warning: unserialize() failed at offset 2822123 of 3601223 bytes in test.inc on
line 8
font color=ffbr
bWarning/b: unserialize() failed at offset 2822123 of 3601223 bytes in
btest.inc/b on line b8/bbr
/font12
13
14
15
16
17
18
19
Repeatedly running the script produces different output each time with different
numbers of failures at different offsets. So far the lowest offset at which I have
had a problem is about 65.
I can supply the 'test.ser' file on request but for obvious reasons do not wish to
include it in this error report!
---
Full Bug description available at: http://bugs.php.net/?id=9240
--
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 #11731: PHP_URL_FOPEN only doesn't work
From: [EMAIL PROTECTED] Operating system: Linux PHP version: 4.0.6 PHP Bug Type: Network related Bug description: PHP_URL_FOPEN only doesn't work ? $url = www.yahoo.com; $link = fopen(http://$url;, r); echo Link ($url): $linkBR; $url2 = www.yahoo.com; $link2 = fopen(http://$url2;, r); echo Link2 ($url2): $link2BR; ? Yields: Link (www.yahoo.com): ($link is empty) Link2 (www.voyage.com): ($link2 is empty) version: PHP Version 4.0.6RC3 Configure: '../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=system' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--with-layout=GNU' '--enable-memory-limit' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--disable-debug' '--disable-static' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-curl=shared,/usr' '--with-db2' '--with-ndbm' '--with-dom=shared,/usr' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--with-gd=shared,/usr' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-imap=shared,/usr' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mm' '--with-mhash=shared,/usr' '--with-mysql=shared,/usr' '--with-pcre-regex=/usr' '--without-pgsql' '--with-sablot=shared,/usr' '--enable-shmop' '--with-snmp=shared' '--enable-sockets' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr' '--enable-wddx' '--with-xml=/usr' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' -- Edit Bug report at: http://bugs.php.net/?id=11731edit=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 #11731 Updated: PHP_URL_FOPEN only doesn't work
ID: 11731 User Update by: [EMAIL PROTECTED] Old-Status: Feedback Status: Open Bug Type: Network related Operating system: Linux PHP Version: 4.0.6 Description: PHP_URL_FOPEN only doesn't work oh sorry I'am a error with my message, test this code : ? $url = www.yahoo.com; $link = fopen(http://$url;, r); echo Link ($url): $linkBR; $url2 = www.voyage.com; $link2 = fopen(http://$url2;, r); echo Link2 ($url2): $link2BR; ? And link2 is only empty... Previous Comments: --- [2001-06-27 13:26:52] [EMAIL PROTECTED] Your example script works just fine for me. Which linux distribution is this? RH? Suse? Do you get any error messages into logs? --- [2001-06-27 05:56:51] [EMAIL PROTECTED] ? $url = www.yahoo.com; $link = fopen(http://$url;, r); echo Link ($url): $linkBR; $url2 = www.yahoo.com; $link2 = fopen(http://$url2;, r); echo Link2 ($url2): $link2BR; ? Yields: Link (www.yahoo.com): ($link is empty) Link2 (www.voyage.com): ($link2 is empty) version: PHP Version 4.0.6RC3 Configure: '../configure' '--prefix=/usr' '--with-apxs=/usr/bin/apxs' '--with-regex=system' '--with-config-file-path=/etc/php4/apache' '--disable-rpath' '--with-layout=GNU' '--enable-memory-limit' '--enable-calendar' '--enable-sysvsem' '--enable-sysvshm' '--enable-track-vars' '--enable-trans-sid' '--disable-debug' '--disable-static' '--enable-bcmath' '--with-bz2' '--enable-ctype' '--with-curl=shared,/usr' '--with-db2' '--with-ndbm' '--with-dom=shared,/usr' '--enable-exif' '--enable-filepro' '--enable-ftp' '--with-gettext' '--with-gd=shared,/usr' '--with-jpeg-dir=shared,/usr' '--with-xpm-dir=shared,/usr/X11R6' '--with-png-dir=shared,/usr' '--with-imap=shared,/usr' '--with-ldap=shared,/usr' '--with-mcal=shared,/usr' '--with-mm' '--with-mhash=shared,/usr' '--with-mysql=shared,/usr' '--with-pcre-regex=/usr' '--without-pgsql' '--with-sablot=shared,/usr' '--enable-shmop' '--with-snmp=shared' '--enable-sockets' '--with-sybase-ct=shared,/usr' '--with-ttf=shared,/usr' '--with-t1lib=shared,/usr' '--enable-wddx' '--with-xml=/usr' '--with-expat-dir=/usr' '--enable-yp' '--with-zlib' --- Full Bug description available at: http://bugs.php.net/?id=11731 -- 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 #13775: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
From: [EMAIL PROTECTED]
Operating system: Linux - SuSE 7.2
PHP version: 4.0.6
PHP Bug Type: *Graphics related
Bug description: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
With this code (via Rasmus/php-general):
http://www.php.net/~rasmus/reductor.php
html
body bgcolor=#00
font color=#ffOriginal Image:/fontimg src=php.png
align=middlebr clear=left
?php
if(!$ch) $ch='$';
$im = ImageCreateFromPNG('./php.png');
$output = ;
for($y=0;$yimagesy($im);$y++) {
for($x=0;$ximagesx($im);$x++) {
$color = ImageColorsForIndex($im,ImageColorAt($im, $x, $y));
echo font size=\1\ color=\#;
echo
printf(%02x%02x%02x,$color['red'],$color['green'],$color['blue']);
echo \$ch/font;
}
echo br\n;
}
?
/body/html
Apache stops responding; Nothing is displayed, not even an error. Apache
must be restarted to bring it back to life.
In the error_log, one sees:
[Sun Oct 21 06:10:03 2001] [notice] child pid 28635 exit signal
Segmentation fault (11)
[Sun Oct 21 06:10:03 2001] [notice] child pid 28634 exit signal
Segmentation fault (11)
Etc...
My php 4.0.6 configure line:
./configure \
--with-config-file-path=/var/www/conf \
--with-gd=/usr/local \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local/ \
--with-tiff-dir=/usr/local \
--with-zlib-dir=/usr \
--with-zlib=/usr \
--with-ttf=/usr/local \
--with-t1lib=/usr/local \
--with-mysql=/usr \
--with-mcrypt=/usr/local \
--with-pdflib=/usr/local \
--with-bz2=/usr/local \
--with-zip=/usr/local \
--with-pspell=/usr/local \
--with-curl=/usr/local \
--with-dom=/usr \
--with-xml \
--enable-magic-quotes \
--enable-ftp \
--with-apache=../apache_1.3.22 ~root/php_configure.log
My Apache 1.3.22 configure line:
./configure \
--prefix=/var/www \
--mandir=/usr/local/man \
--server-uid=www \
--server-gid=www \
--libexecdir=/var/www/modules \
--enable-module=rewrite \
--enable-module=so \
--enable-shared=speling \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--activate-module=src/modules/perl/libperl.a
I listed this as graphics related, but I really don't know if it really
is.
-Brian
--
Edit bug report at: http://bugs.php.net/?id=13775edit=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 #13775 Updated: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
ID: 13775
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Graphics related
Operating System: Linux - SuSE 7.2
PHP Version: 4.0.6
New Comment:
By the way, as far as verified gd/png support in my build:
% egrep -i '(png|gd)' ~root/php_configure.log
checking for GDBM support... no
checking whether to include GD support... yes
checking whether to enable truetype string function in gd... no
checking for the location of libpng... yes
checking for png_info_init in -lpng... yes
checking for gdImageString16 in -lgd... yes
checking for gdImagePaletteCopy in -lgd... yes
checking for gdImageCreateFromPng in -lgd... yes
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageWBMP in -lgd... yes
checking for gdImageCreateFromJpeg in -lgd... yes
checking for gdImageCreateFromXpm in -lgd... yes
checking for gdImageCreateTrueColor in -lgd... no
checking for gdImageSetTile in -lgd... yes
checking for gdImageSetBrush in -lgd... yes
checking for gdImageStringFTEx in -lgd... no
checking for gdImageColorClosestHWB in -lgd... yes
checking for gdImageColorResolve in -lgd... yes
checking for gdImageGifCtx in -lgd... no
checking for the location of libpng... yes
checking for png_create_info_struct in -lpng... yes
creating ext/gd/Makefile
Previous Comments:
[2001-10-21 06:38:11] [EMAIL PROTECTED]
With this code (via Rasmus/php-general):
http://www.php.net/~rasmus/reductor.php
html
body bgcolor=#00
font color=#ffOriginal Image:/fontimg src=php.png align=middlebr
clear=left
?php
if(!$ch) $ch='$';
$im = ImageCreateFromPNG('./php.png');
$output = ;
for($y=0;$yimagesy($im);$y++) {
for($x=0;$ximagesx($im);$x++) {
$color = ImageColorsForIndex($im,ImageColorAt($im, $x, $y));
echo font size=\1\ color=\#;
echo printf(%02x%02x%02x,$color['red'],$color['green'],$color['blue']);
echo \$ch/font;
}
echo br\n;
}
?
/body/html
Apache stops responding; Nothing is displayed, not even an error. Apache must be
restarted to bring it back to life.
In the error_log, one sees:
[Sun Oct 21 06:10:03 2001] [notice] child pid 28635 exit signal Segmentation fault
(11)
[Sun Oct 21 06:10:03 2001] [notice] child pid 28634 exit signal Segmentation fault
(11)
Etc...
My php 4.0.6 configure line:
./configure \
--with-config-file-path=/var/www/conf \
--with-gd=/usr/local \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local/ \
--with-tiff-dir=/usr/local \
--with-zlib-dir=/usr \
--with-zlib=/usr \
--with-ttf=/usr/local \
--with-t1lib=/usr/local \
--with-mysql=/usr \
--with-mcrypt=/usr/local \
--with-pdflib=/usr/local \
--with-bz2=/usr/local \
--with-zip=/usr/local \
--with-pspell=/usr/local \
--with-curl=/usr/local \
--with-dom=/usr \
--with-xml \
--enable-magic-quotes \
--enable-ftp \
--with-apache=../apache_1.3.22 ~root/php_configure.log
My Apache 1.3.22 configure line:
./configure \
--prefix=/var/www \
--mandir=/usr/local/man \
--server-uid=www \
--server-gid=www \
--libexecdir=/var/www/modules \
--enable-module=rewrite \
--enable-module=so \
--enable-shared=speling \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--activate-module=src/modules/perl/libperl.a
I listed this as graphics related, but I really don't know if it really is.
-Brian
Edit this bug report at http://bugs.php.net/?id=13775edit=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 #13775 Updated: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
ID: 13775
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Old Status: Feedback
Status: Open
Bug Type: GD related
Operating System: Linux - SuSE 7.2
PHP Version: 4.0.6
New Comment:
Same version.
% ls /usr/local/src/graphics
T1Lib-1.2 freetype-2.0.4 gd-1.8.4 jpeg-6b libpng-1.2.0
I'm still testing; I was tired as $#!t last night and I had to give it up. So I guess
this may be directly related to graphics after all?
For the record, I also tested without mod_ssl and without mod_perl as well. Still
segfaulted.
I'm about to try 4.0.8-dev from snaps and see if that makes any difference.
Previous Comments:
[2001-10-21 18:28:34] [EMAIL PROTECTED]
I can't reproduce this with PHP 4.1.0Rc1 and GD 1.8.4.
Which GD version do you have?
[2001-10-21 06:58:46] [EMAIL PROTECTED]
By the way, as far as verified gd/png support in my build:
% egrep -i '(png|gd)' ~root/php_configure.log
checking for GDBM support... no
checking whether to include GD support... yes
checking whether to enable truetype string function in gd... no
checking for the location of libpng... yes
checking for png_info_init in -lpng... yes
checking for gdImageString16 in -lgd... yes
checking for gdImagePaletteCopy in -lgd... yes
checking for gdImageCreateFromPng in -lgd... yes
checking for gdImageCreateFromGif in -lgd... no
checking for gdImageWBMP in -lgd... yes
checking for gdImageCreateFromJpeg in -lgd... yes
checking for gdImageCreateFromXpm in -lgd... yes
checking for gdImageCreateTrueColor in -lgd... no
checking for gdImageSetTile in -lgd... yes
checking for gdImageSetBrush in -lgd... yes
checking for gdImageStringFTEx in -lgd... no
checking for gdImageColorClosestHWB in -lgd... yes
checking for gdImageColorResolve in -lgd... yes
checking for gdImageGifCtx in -lgd... no
checking for the location of libpng... yes
checking for png_create_info_struct in -lpng... yes
creating ext/gd/Makefile
[2001-10-21 06:38:11] [EMAIL PROTECTED]
With this code (via Rasmus/php-general):
http://www.php.net/~rasmus/reductor.php
html
body bgcolor=#00
font color=#ffOriginal Image:/fontimg src=php.png align=middlebr
clear=left
?php
if(!$ch) $ch='$';
$im = ImageCreateFromPNG('./php.png');
$output = ;
for($y=0;$yimagesy($im);$y++) {
for($x=0;$ximagesx($im);$x++) {
$color = ImageColorsForIndex($im,ImageColorAt($im, $x, $y));
echo font size=\1\ color=\#;
echo printf(%02x%02x%02x,$color['red'],$color['green'],$color['blue']);
echo \$ch/font;
}
echo br\n;
}
?
/body/html
Apache stops responding; Nothing is displayed, not even an error. Apache must be
restarted to bring it back to life.
In the error_log, one sees:
[Sun Oct 21 06:10:03 2001] [notice] child pid 28635 exit signal Segmentation fault
(11)
[Sun Oct 21 06:10:03 2001] [notice] child pid 28634 exit signal Segmentation fault
(11)
Etc...
My php 4.0.6 configure line:
./configure \
--with-config-file-path=/var/www/conf \
--with-gd=/usr/local \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local/ \
--with-tiff-dir=/usr/local \
--with-zlib-dir=/usr \
--with-zlib=/usr \
--with-ttf=/usr/local \
--with-t1lib=/usr/local \
--with-mysql=/usr \
--with-mcrypt=/usr/local \
--with-pdflib=/usr/local \
--with-bz2=/usr/local \
--with-zip=/usr/local \
--with-pspell=/usr/local \
--with-curl=/usr/local \
--with-dom=/usr \
--with-xml \
--enable-magic-quotes \
--enable-ftp \
--with-apache=../apache_1.3.22 ~root/php_configure.log
My Apache 1.3.22 configure line:
./configure \
--prefix=/var/www \
--mandir=/usr/local/man \
--server-uid=www \
--server-gid=www \
--libexecdir=/var/www/modules \
--enable-module=rewrite \
--enable-module=so \
--enable-shared=speling \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--activate-module=src/modules/perl/libperl.a
I listed this as graphics related, but I really don't know if it really is.
-Brian
Edit this bug report at http://bugs.php.net/?id=13775edit=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 #13775 Updated: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
\ --with-mcrypt=/usr/local \ --with-pdflib=/usr/local \ --with-bz2=/usr/local \ --with-zip=/usr/local \ --with-pspell=/usr/local \ --with-curl=/usr/local \ --with-dom=/usr \ --with-xml \ --enable-magic-quotes \ --enable-ftp \ --with-apache=../apache_1.3.22 ~root/php_configure.log My Apache 1.3.22 configure line: ./configure \ --prefix=/var/www \ --mandir=/usr/local/man \ --server-uid=www \ --server-gid=www \ --libexecdir=/var/www/modules \ --enable-module=rewrite \ --enable-module=so \ --enable-shared=speling \ --enable-module=ssl \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a I listed this as graphics related, but I really don't know if it really is. -Brian Edit this bug report at http://bugs.php.net/?id=13775edit=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 #13775 Updated: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
in -lgd... yes
checking for gdImageStringFTEx in -lgd... no
checking for gdImageColorClosestHWB in -lgd... yes
checking for gdImageColorResolve in -lgd... yes
checking for gdImageGifCtx in -lgd... no
checking for the location of libpng... yes
checking for png_create_info_struct in -lpng... yes
creating ext/gd/Makefile
[2001-10-21 06:38:11] [EMAIL PROTECTED]
With this code (via Rasmus/php-general):
http://www.php.net/~rasmus/reductor.php
html
body bgcolor=#00
font color=#ffOriginal Image:/fontimg src=php.png align=middlebr
clear=left
?php
if(!$ch) $ch='$';
$im = ImageCreateFromPNG('./php.png');
$output = ;
for($y=0;$yimagesy($im);$y++) {
for($x=0;$ximagesx($im);$x++) {
$color = ImageColorsForIndex($im,ImageColorAt($im, $x, $y));
echo font size=\1\ color=\#;
echo printf(%02x%02x%02x,$color['red'],$color['green'],$color['blue']);
echo \$ch/font;
}
echo br\n;
}
?
/body/html
Apache stops responding; Nothing is displayed, not even an error. Apache must be
restarted to bring it back to life.
In the error_log, one sees:
[Sun Oct 21 06:10:03 2001] [notice] child pid 28635 exit signal Segmentation fault
(11)
[Sun Oct 21 06:10:03 2001] [notice] child pid 28634 exit signal Segmentation fault
(11)
Etc...
My php 4.0.6 configure line:
./configure \
--with-config-file-path=/var/www/conf \
--with-gd=/usr/local \
--with-jpeg-dir=/usr/local \
--with-png-dir=/usr/local/ \
--with-tiff-dir=/usr/local \
--with-zlib-dir=/usr \
--with-zlib=/usr \
--with-ttf=/usr/local \
--with-t1lib=/usr/local \
--with-mysql=/usr \
--with-mcrypt=/usr/local \
--with-pdflib=/usr/local \
--with-bz2=/usr/local \
--with-zip=/usr/local \
--with-pspell=/usr/local \
--with-curl=/usr/local \
--with-dom=/usr \
--with-xml \
--enable-magic-quotes \
--enable-ftp \
--with-apache=../apache_1.3.22 ~root/php_configure.log
My Apache 1.3.22 configure line:
./configure \
--prefix=/var/www \
--mandir=/usr/local/man \
--server-uid=www \
--server-gid=www \
--libexecdir=/var/www/modules \
--enable-module=rewrite \
--enable-module=so \
--enable-shared=speling \
--enable-module=ssl \
--activate-module=src/modules/php4/libphp4.a \
--activate-module=src/modules/perl/libperl.a
I listed this as graphics related, but I really don't know if it really is.
-Brian
Edit this bug report at http://bugs.php.net/?id=13775edit=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 #13775 Updated: Segfault (11) with PHP 4.0.6 / Apache 1.3.22
ID: 13775 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Old Status: Feedback Status: Open Bug Type: GD related Operating System: Linux - SuSE 7.2 PHP Version: 4.0.6 and 4.2.0-dev New Comment: Rebulding gd-1.8.4 with libpng-1.0.12 then rebuilding PHP 4.2.0-dev corrected the problem. Apache no longer segfaults. However, it *says* TTF is disabled in gd: % egrep -i truetype ~root/php_configure.log checking whether to enable truetype string function in gd... no But a call to ?php imagettftext(); ? (with no arguments) *does* give me: Warning: Wrong parameter count for imagettftext() in /var/www/htdocs/ttf.test.php on line 3 And phpinfo() says: FreeType Support: enabled FreeType Linkage: with freetype T1Lib Support: enabled So is that be anything to worry about? But I suppose that doesn't matter as far as the bug report. If it's anything to worry about, just let me know privately if you want. For the record, the working configure(s): PHP 4.2.0-dev % ./configure \ --with-config-file-path=/var/www/conf \ --enable-debug \ --with-gd=/usr/local \ --with-tiff-dir=../tiff-v3.5.6-beta \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-zlib-dir=/usr \ --with-zlib=/usr \ --with-t1lib=/usr/local \ --with-mysql=/usr \ --with-mcrypt=/usr/local \ --with-pdflib=/usr/local \ --with-bz2=/usr/local \ --with-zip=/usr/local \ --with-pspell=/usr/local \ --with-curl=/usr/local \ --with-xml \ --enable-magic-quotes \ --enable-ftp \ --enable-gd-native-tt \ --enable-gd-imgstrttf \ --with-freetype-dir=/usr/local/include/freetype2 \ --with-apache=../apache_1.3.22 ~root/php_configure.log Apache 1.3.22: % SSL_BASE=/usr/include/openssl % ./configure \ --prefix=/var/www \ --mandir=/usr/local/man \ --server-uid=www \ --server-gid=www \ --libexecdir=/var/www/modules \ --enable-module=rewrite \ --enable-module=so \ --enable-module=speling \ --enable-shared=speling \ --enable-module=ssl \ --activate-module=src/modules/php4/libphp4.a \ --activate-module=src/modules/perl/libperl.a \ --add-module=../mod_gzip.c Thank you! :) You guys are great! Previous Comments: [2001-10-22 01:34:01] [EMAIL PROTECTED] The segfault seems to be happening in the png code. I guess the 1.2.0 version might not be very stable. Try with the previous release, 1.0.12. I will check this out myself too. --Jani [2001-10-21 20:26:31] [EMAIL PROTECTED] And finally, a backtrace having enabled debugging: % gdb --quiet /var/www/bin/httpd (gdb) run -X Starting program: /var/www/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x999 in ?? () (gdb) bt #0 0x999 in ?? () #1 0x4016e058 in png_create_info_struct () from /usr/local/lib/libpng.so.3 #2 0x823ffbc in gdImageCreateFromPngCtx () #3 0x823feff in gdImageCreateFromPng () #4 0x80fb910 in _php_image_create_from (ht=1, return_value=0x84bab8c, this_ptr=0x0, return_value_used=1, image_type=2, tn=0x82fb30b PNG, func_p=0x823fee0 gdImageCreateFromPng, ioctx_func_p=0x823ff20 gdImageCreateFromPngCtx) at gd.c:1182 #5 0x80fba3c in zif_imagecreatefrompng (ht=1, return_value=0x84bab8c, this_ptr=0x0, return_value_used=1) at gd.c:1229 #6 0x81e421a in execute (op_array=0x84b6544) at ./zend_execute.c:1598 #7 0x81be8a9 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at zend.c:814 #8 0x80e4f11 in php_execute_script (primary_file=0xb588) at main.c:1310 #9 0x81cab8c in apache_php_module_main (r=0x83b981c, display_source_mode=0) at sapi_apache.c:90 #10 0x80e1346 in send_php () #11 0x80e13a6 in send_parsed_php () #12 0x81eed39 in ap_invoke_handler () #13 0x8204dcf in process_request_internal () #14 0x8204e42 in ap_process_request () #15 0x81fb926 in child_main () #16 0x81fbb05 in make_child () #17 0x81fbc86 in startup_children () #18 0x81fc32d in standalone_main () #19 0x81fcbac in main () #20 0x4034bc6f in __libc_start_main () from /lib/libc.so.6 (gdb) [2001-10-21 19:56:44] [EMAIL PROTECTED] No such luck. % uname -a Linux callisto 2.4.12-4GB #1 Fri Oct 19 08:34:54 GMT 2001 i686 unknown Still SuSE 7.2.. PHP 4.2.0-dev: % ./configure \ --with-config-file-path=/var/www/conf \ --with-gd=/usr/local \ --with-tiff-dir=../tiff-v3.5.6-beta \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local/ \ --with-zlib-dir=/usr \ --with-zlib=/usr \ --with-t1lib=/usr/local \ --with-mysql=/usr \ --with-mcrypt=/usr/local \ --with-pdflib=/usr/local \ --with-bz2=/usr/local \ --with-zip=/usr/local \ --with-pspell=/usr/local \ --with-curl=/usr/local \ --with-xml \ --enable-magic-quotes \ --enable-ftp \ --enable-gd-native-tt \ --enable-gd-imgstrttf \
[PHP-DEV] PHP 4.0 Bug #8843: aclocal: configure.in: 54: macro `AM_INIT_AUTOMAKE' not found in library
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.0 Latest CVS (22/01/2001) PHP Bug Type: *Install and Config Bug description: aclocal: configure.in: 54: macro `AM_INIT_AUTOMAKE' not found in library ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.3.5 (ok) aclocal: configure.in: 54: macro `AM_INIT_AUTOMAKE' not found in library aclocal: configure.in: 68: macro `AM_CONFIG_HEADER' not found in library aclocal: configure.in: 69: macro `AM_MAINTAINER_MODE' not found in library aclocal: configure.in: 113: macro `AM_PROG_CC_STDC' not found in library aclocal: configure.in: 119: macro `AM_PROG_LEX' not found in library aclocal: configure.in: 793: macro `AM_PROG_LIBTOOL' not found in library make[1]: *** [aclocal.m4] Error 1 make: *** [all] Error 2 Ooh. Stuck. I check the mailing list archives, the bug db and searched the site, but could find nothing on this. Presumably its a transient, but I thought someone should know about it. -- Edit Bug report at: http://bugs.php.net/?id=8843edit=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] PHP 4.0 Bug #8843 Updated: aclocal: configure.in: 54: macro `AM_INIT_AUTOMAKE' not found in library
ID: 8843 User Update by: [EMAIL PROTECTED] Old-Status: Open Status: Closed Bug Type: *Install and Config Description: aclocal: configure.in: 54: macro `AM_INIT_AUTOMAKE' not found in library Reinstalled autoconf/automake/libtool and now the problem has gone away. Sorry to waste everyone's time. I should have thought of that first. Best Regards, Brian Previous Comments: --- [2001-01-22 17:45:40] [EMAIL PROTECTED] ./buildconf buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: automake version 1.4 (ok) buildconf: libtool version 1.3.5 (ok) aclocal: configure.in: 54: macro `AM_INIT_AUTOMAKE' not found in library aclocal: configure.in: 68: macro `AM_CONFIG_HEADER' not found in library aclocal: configure.in: 69: macro `AM_MAINTAINER_MODE' not found in library aclocal: configure.in: 113: macro `AM_PROG_CC_STDC' not found in library aclocal: configure.in: 119: macro `AM_PROG_LEX' not found in library aclocal: configure.in: 793: macro `AM_PROG_LIBTOOL' not found in library make[1]: *** [aclocal.m4] Error 1 make: *** [all] Error 2 Ooh. Stuck. I check the mailing list archives, the bug db and searched the site, but could find nothing on this. Presumably its a transient, but I thought someone should know about it. --- Full Bug description available at: http://bugs.php.net/?id=8843 -- 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] PHP 4.0 Bug #8889: Memory is not being freed.
That is what we are doing now. We have it at 5. Any higher and we are running out. There is only 128MB of RAM in our machine. I am considering switching to CGI PHP just to eliviate this problem. Of course, that sucks. Brian Moon -- Phorum Dev Team - http://phorum.org Making better forums with PHP -- - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Filip Sielimowicz" [EMAIL PROTECTED] Cc: "Brian Moon" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 29, 2001 6:56 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. Yes, yes, I agree ! But this is the problem ! Unfortunatelly "memory hungry script" happens from time to time and there's no chance to prevent httpd processes from keeping memory (which is not used again in most cases). Maybe it is not a problem for you, but it is for us. A quick fix would be to set your MaxRequestsPerChild to a lower value. -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] PHP 4.0 Bug #8889: Memory is not being freed.
Yes, but it would be really nice if it was returned. Systems with 128MB or RAM run out quickly if there is a script ( like a long Phorum thread ) that takes a good chunk. Of course the argument can be made that the box needs more RAM but if the memory can be returned (maybe even with a php.ini setting that states the max amount PHP should keep) to the system why not do it? Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Brian Moon" [EMAIL PROTECTED] Cc: "Filip Sielimowicz" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, January 28, 2001 12:23 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. It is not a leak exactly but more of a greed. It seems to be a semi-intentional but not necessary thing. It seems that the way Zend/PHP is allocating memory is not allowing it to be returned to the system. Once PHP has some memory it will not let it go, but it will reuse it. So, if a script takes up a good chunk of memory, it is never returned to the system unless that httpd process is killed or dies. Right, this is standard. But this does not explain incremental memory usage. Memory is marked as free and re-used. It does not need to be returned to the system for it to be re-used. So the memory usage for any one process should never exceed the memory usage of your most memory hungry script. -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] PHP 4.0 Bug #8889: Memory is not being freed.
Ok, so what are the benefits of not returning memory to the system? It seems that no one who can do it wants to so there must be a good reason. Brian Moon -- Phorum Dev Team - http://phorum.org Making better forums with PHP -- - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Brian Moon" [EMAIL PROTECTED] Cc: "Filip Sielimowicz" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 29, 2001 5:03 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. Seems to me like it would be a lot easier just to add more RAM. $89 for 256M these days. RAM is cheap. -Rasmus On Mon, 29 Jan 2001, Brian Moon wrote: That is what we are doing now. We have it at 5. Any higher and we are running out. There is only 128MB of RAM in our machine. I am considering switching to CGI PHP just to eliviate this problem. Of course, that sucks. Brian Moon -- Phorum Dev Team - http://phorum.org Making better forums with PHP -- - Original Message - From: "Rasmus Lerdorf" [EMAIL PROTECTED] To: "Filip Sielimowicz" [EMAIL PROTECTED] Cc: "Brian Moon" [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, January 29, 2001 6:56 AM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889: Memory is not being freed. Yes, yes, I agree ! But this is the problem ! Unfortunatelly "memory hungry script" happens from time to time and there's no chance to prevent httpd processes from keeping memory (which is not used again in most cases). Maybe it is not a problem for you, but it is for us. A quick fix would be to set your MaxRequestsPerChild to a lower value. -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] PHP 4.0 Bug #8889: Memory is not being freed.
4. And, BTW, you can control it - see MAX_ constants at zend_alloc.h As I CLEARLY (as I think ...) described in http://marc.theaimsgroup.com/?l=php-devm=98080647502573w=2 the mechanism of memory "deadlocks" is not based on the cache size (it is small in fact), but in order of memory operations (problem appears even when the size is set to 1 !). We've tested some very simple fixes (turn off ZEND_FAST_CACHE and for example force the shutdown_memory_manager always to clean the cache, not only when "clean" flag is set. It needs some small modification in for loop in order to reinitialize cache globals) and the problem has dissapeared (almost, but I'll say about it later in 5). The CPU performance lowers down only a little bit. I did what it says at that URL and still had the problems. I suspect it is related to libraries and such that we use at phorum.org but I am not sure how to pinpoint it. Can you tell me what you did to force the shutdown_memory_manager. I would like to see what that can do for me. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP 4.0 Bug #9058: dir() and readdir() don't work
From: [EMAIL PROTECTED] Operating system: Solaris 8 PHP version: 4.0.4pl1 PHP Bug Type: Directory function related Bug description: dir() and readdir() don't work Using the examples cut-n-pasted from the dir() and readdir() documentation, dir() they both return nothing. They work ok in php3. I see other entries in the bug database saying this issue was fixed in the cvs, but these are dated before the release of the version I'm using, so I guess they became broken again or Solaris 8 is a problem. I'll be delighted to help debug this if someone can tell me how. Best Regards, Brian -- Edit Bug report at: http://bugs.php.net/?id=9058edit=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] Getting Started with new module
Some months back I inquired about writing a BEA Tuxedo module for PHP. I got side-tracked for a while, but now I'd like to resume exploring this possibility. Primarily, because I'd like to use this module myself, but also feel it would be a natural match to an environment like PHP on a web server. First obvious question is is anyone working on a Tuxedo hook? If not, I'd like to volunteer. For those not familiar with Tuxedo, its a high-end transaction middleware Client/Server environment used in many larger corporate environments. Reference http://www.beasys.com/products/tuxedo/index.shtml for a good starting point. My thoughts are that PHP should have the ability to be a Tuxedo client, so it can call Tux services elsewhere in a Tux environment. These services can be located on the same machine, one other machine, numerous other machines, even mainframes. Ideally, all seemlessly called. It would call services in much the same way PHP calls a service from a database. I would only propose a web/PHP server be a client to Tuxedo. I can't imagine how a Tux server would even technically be incorporated into PHP. So, where to start??? I've looked through some of the code for other external modules. Sybase_ct for instance which is another environment I'm familiar with. Tuxedo has numerous API calls, but most of them aren't used for clients, so I don't think there would be many new functions. A basic Tux client can be written with as few as 6 API functions. It does require some similar connection concepts as databases, and also has its own memory allocation / free functions (tpalloc, tpfree). My personal resume includes 8+ years of UNIX, C, and database development mostly on Solaris, Linux, Sybase, and Informix. I feel I should be technically able to complete this type of project. I've read the apidoc.txt and apidoc-zend.txt files, but seems there are still some holes. Can anyone suggest the best way to get started? Much appreciated, Brian Foddy [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Sybase_ct on linux core and LANG variable
I just thought I would pass this along, it might be the cause of some bug reports. Using Linux Mandrake 7.2 and Sybase Open client 11.1.1, php4.0.4p1. I was getting a core (illegal instruction) on apache startup when I had the sybase modules installed in PHP. However, I knew it worked fine on Solaris 2.6 at work, so I was puzzled. looking at the backtrace, I discovered it was dumping in cs_ctx_alloc which tries to read the locales.dat files. Then it hit me, Sybase is very picky about the LANG variable being set correctly for a matching record in locales.dat. Mine was set to "en" The fix... Either 1. set LANG=C in apachectl or 2. add "locale = en, us_english, iso_1" to the locales.dat in the linux section. This can be very frustrating, I've been working with Sybase for years and it still took me a long time to find this. I don't know if this is documented anywhere, but if not it would be nice to have it so. Brian -- 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]
Fwd: [PHP-DEV] Sybase_ct on linux core and LANG variable
That's is the sybase_ct libraries, just for clarification. ==BEGIN FORWARDED MESSAGE== I just thought I would pass this along, it might be the cause of some bug reports. Using Linux Mandrake 7.2 and Sybase Open client 11.1.1, php4.0.4p1. I was getting a core (illegal instruction) on apache startup when I had the sybase modules installed in PHP. However, I knew it worked fine on Solaris 2.6 at work, so I was puzzled. looking at the backtrace, I discovered it was dumping in cs_ctx_alloc which tries to read the locales.dat files. Then it hit me, Sybase is very picky about the LANG variable being set correctly for a matching record in locales.dat. Mine was set to "en" The fix... Either 1. set LANG=C in apachectl or 2. add "locale = en, us_english, iso_1" to the locales.dat in the linux section. This can be very frustrating, I've been working with Sybase for years and it still took me a long time to find this. I don't know if this is documented anywhere, but if not it would be nice to have it so. Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] ===END FORWARDED MESSAGE=== -- 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] PHP 4.0 Bug #8834 Updated: crypt() starts from not random salt
I too have seen this, but I assumed it you had to put a random salt key in. I picked the system mseconds and put that in a random seed to get a random salt key. I was also on Solaris 2.6. Simple work around if its not supposed to work that way. On 5 Apr 2001 18:57:45 -, [EMAIL PROTECTED] wrote: ID: 8834 Updated by: sniper Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Strings related Assigned To: Comments: This is most likely a Solaris specific issue as I can't reproduce this on Linux. Can you please include the output of this command in both Solaris 2.4 and 2.6 (in php4): # grep RAND main/php_config.h It might be that in both of those system the seed generator found is srand() which isn't so good as srandom() is. But I also found (with google :) that srandom() might not be that good either (in Solaris) so that leaves us with a problem. One solution might be that we run php_srand() in RINIT instead of MINIT when Solaris is used. --Jani Previous Comments: --- [2001-01-22 06:05:34] [EMAIL PROTECTED] PHP compiled as Apache module. Look like crypt() starts from not random salt. In case of my Solaris 2.4, first crypt() call always generates string starting from "IH". In case of Solaris 2.6 it always starts from "C.". Looks like in every instantiation of new Apache process PHP starts crypt from the same salt value. In the same process next crypt() calls look like they generate random strings, though. But next process restarts with the same value. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=8834edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] PHP-Tuxedo Open Source Project
Open Source Project Announcement... I have started an open source project to build a module for PHP4 that will allow direct calls to Tuxedo services from the PHP script, the project name is php-tuxedo. Think about it for a second... The ability from inside a PHP web page to directly call already existing Tuxedo services anywhere in your environment. Just like PHP can open a database connection to Oracle or Sybase, it would open a Tuxedo connection as a Tux client to a Tuxedo middleware environment. For those who have used PHP, you know how easy it is to build dynamic web pages. But those pages are mostly limited to database queries or flat file access for data. With this project you could call all your existing enterprise Tuxedo services directly. I believe this would be a very powerful enhancement to PHP's capabilities. To those familiar with Tuxedo, you know about how powerful an implementation of Tux middleware services can be for departmental and enterprise solutions. I want to bring these two pieces together. Project status. The project is in its early infancy, but some parts are functional. I have successfully built a client page that uses a STRING buffer to call a service with tpcall and returns a STRING buffer back. Primitive? Sure, but this is only the start. I have ideas of how to implement many other functions and buffer types including FMLs. There is much work to do, but if you are interested please check out http://php-tuxedo.sourceforge.net. There you can download my first cut and more importantly follow the project as it progresses. For the really ambitious I would welcome any testing or development help on the project. Please note I'm posting this note to several lists I don't normally monitor, so I may not see a reply on the list. Hope to hear from you. Brian Foddy [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Hash Functions API
I've been looking everywhere for a good reference of how to read and update arrays. The Zend documentation (www.zend.com/apidoc) has descriptions of how to create an array, and how to add elements to it, but I can't find anything on how to simply read the values of an array. Mostly I want to write two functions: 1. Accept a provided 2 dimensional array and loop through every element, by primary index then an inner loop by the second index, sequentially. I need to extract from the array the two keys and the value. The keys will not be sequential, at least the primary. 2. Build a 2-d array, basically the reverse of 1 above. Build an array with specific primary and secondary indexes. Again keys will not be sequential. To make matters worse, I'd like the keys to be either integer or strings. I've looked through the zend_hash.h header, and a few functions look likely (zend_hash_move_forward, zend_hash_get_current_key). But its hard knowing if these are the best to use and exactly how to use them. One more question, very simple. What is the difference between zend_hash_find and quick_find? I assume index_find lets me specify an integer (ie: array[3] in C notation). Have I missed the docs on these functions somewhere? Thanks for help. Brian -- 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] GD 2.0.1 and FreeType 2
Hi guys, A) has anyone tried PHP and gd 2.0.1? B) If I compile gd with FreeType 2 support, do I have to compile FreeType into PHP? Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. "Caching Dynamic Web Content to Increase Dependability and Performance" http://www.apachecon.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] GD 2.0.1 and FreeType 2
When compiling Apache I get: modules/php4/libphp4.a(gd.o): In function `php_imagettftext_common': /usr/src/apache/php4-200104131045/ext/gd/gd.c:2667: undefined reference to `gdttf' Brian Moon Phorum Dev Team - Making better forums with PHP http://phorum.org/ - - Original Message - From: "Wez Furlong" [EMAIL PROTECTED] To: "Brian Moon" [EMAIL PROTECTED] Sent: Friday, April 13, 2001 5:42 AM Subject: Re: [PHP-DEV] GD 2.0.1 and FreeType 2 Hi Brian, A) has anyone tried PHP and gd 2.0.1? Yes - me. B) If I compile gd with FreeType 2 support, do I have to compile FreeType into PHP? PHP needs to be linked to any and all libraries that are used by those libraries that you use, if you get my meaning! If gd has a dependency on freetype, then anything that uses that gd library will need to be linked to freetype as well. I've attached a patch that takes care of this and enables the true color and alpha channel code, plus a handful of line style and image brush/tile options that have so far been missing from PHP. ./configure --with-ttf=no --with-freetype-dir --with-png-dir --with-jpeg-dir --with-gd The --with-ttf=no is there to prevent linking against the libttf if it is installed. Please let me know how you get on with this! --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]
Re: [PHP-DEV] GD 2.0.1 and FreeType 2
_F26Dot6' undeclared (first use in this function) gdttf.c:764: parse error before `ur_x' gdttf.c:766: `TT_BBox' undeclared (first use in this function) gdttf.c:766: `bbox' undeclared (first use in this function) gdttf.c:766: warning: statement with no effect gdttf.c:767: parse error before `double' gdttf.c:769: `font' undeclared (first use in this function) gdttf.c:769: warning: statement with no effect gdttf.c:770: `fontkey_t' undeclared (first use in this function) gdttf.c:770: parse error before `fontkey' gdttf.c:777: `fontCache' undeclared (first use in this function) gdttf.c:778: warning: implicit declaration of function `TT_Init_FreeType' gdttf.c:778: `engine' undeclared (first use in this function) gdttf.c:787: `fontkey' undeclared (first use in this function) gdttf.c:791: parse error before `)' gdttf.c:795: `sin_a' undeclared (first use in this function) gdttf.c:796: `cos_a' undeclared (first use in this function) gdttf.c:797: `advance_x' undeclared (first use in this function) gdttf.c:797: `advance_y' undeclared (first use in this function) gdttf.c:799: `next' undeclared (first use in this function) gdttf.c:801: `ch' undeclared (first use in this function) gdttf.c:817: `x1' undeclared (first use in this function) gdttf.c:820: `error' undeclared (first use in this function) gdttf.c:820: `advance' undeclared (first use in this function) gdttf.c:823: `i' undeclared (first use in this function) gdttf.c:824: `ll_x' undeclared (first use in this function) gdttf.c:825: `ll_y' undeclared (first use in this function) gdttf.c:826: `ur_x' undeclared (first use in this function) gdttf.c:827: `ur_y' undeclared (first use in this function) make[3]: *** [gdttf.lo] Error 1 make[3]: Leaving directory `/usr/src/apache/php4-200104131045/ext/gd' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/apache/php4-200104131045/ext/gd' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/apache/php4-200104131045/ext' make: *** [all-recursive] Error 1 Brian Moon Phorum Dev Team - Making better forums with PHP http://phorum.org/ - - Original Message - From: "Wez Furlong" [EMAIL PROTECTED] To: "Brian Moon" [EMAIL PROTECTED] Sent: Friday, April 13, 2001 5:42 AM Subject: Re: [PHP-DEV] GD 2.0.1 and FreeType 2 Hi Brian, A) has anyone tried PHP and gd 2.0.1? Yes - me. B) If I compile gd with FreeType 2 support, do I have to compile FreeType into PHP? PHP needs to be linked to any and all libraries that are used by those libraries that you use, if you get my meaning! If gd has a dependency on freetype, then anything that uses that gd library will need to be linked to freetype as well. I've attached a patch that takes care of this and enables the true color and alpha channel code, plus a handful of line style and image brush/tile options that have so far been missing from PHP. ./configure --with-ttf=no --with-freetype-dir --with-png-dir --with-jpeg-dir --with-gd The --with-ttf=no is there to prevent linking against the libttf if it is installed. Please let me know how you get on with this! --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] Timeout Function:
Personally, I think having an alarm (timeout) function is a really good idea. Setting a timer, and then being able to jump from whatever you are doing if it is taking too long is something that has helped me do some really neat stuff in C and Perl... and I was a little dissapointed when I learned PHP didn't have. Of course, I have no idea how hard it would be to do... so my opinion isn't worth a hole lot more than .02 Brian Tanner http://www.zaam.com -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] sybase-ct and datetime results
On Wed, 25 Apr 2001 22:59:15 +0200, Bj,rn Dolkemeier wrote: (I posted this also to php.db, but the more I think php.dev would be a better place) Hello, If I do a sybase_query(select getdate(),$Conn) this will return the current date in the format Nov 3 1998 8:06PM (so I don't have seconds). I think this leads to the usage of CS_SHORT_DATE in ext/sybase_ct/php_sybase_ct.c (Line 275). Does somebody know, if there is a solution for getting another datetime-format beyond doing something like sybase_query(select convert(varchar,getdate(),108). Wouldn't it be better to return the datetime-results of queries as a timestamp? Or have a php.ini-setting / global parameter how to return datetime-results? Thanks for anwers, Bjoern WHen you send the select getdate () PHP doesn't parse that, it just sends it on to Sybase exactly as is. If you issue that query in ISQL, you should get the same result. PHP can't start parsing SQL requests. There are some ways in Sybase to change some of the defaults for date/times. Check the Sybase manuals, they may help. The only other thing that could even possibly be done (and I'm not advocating it) is the creation of a new function that would return the Sybase timestamp with greater precision. Don't get me wrong, I think Sybase should have better time formatting also. For example to format 12/31/2001 23:59:59 it takes two datetimes formatted string catted together, that's pretty sad. But still that is a Sybase issue. Not much PHP can do. Brian -- 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] Troubles with DL'ed module
I'm having strange problems with a new DL module I'm trying to write. The most common problem is PHP will coredump after my module has executed in the module cleanup routines (the Zend routines, not my module routines). For instance it will coredump on cleaning up the 10th constant defined by my module. It cores at line 643 of zend_hash.c (the pefree line). Looking in the debugger, the address looks valid, but free doesn't like it. NOTE: The constants are defined with CONST_CS | CONST_PERSISTENT, but taking the Persistent out has no effect (the persistent flag is still set in the struct). If I remove all my constants, or make other alterations it may core in other but related places inside the cleanup. I'm doing most of this on Solaris 2.6 (sparc) with the Workshop compiler (Forte 6.1), but it seems to work ok on Linux and gcc. I'm not to the point of calling this a Zend bug and opening a bug report, but I'm hoping to get a few more pointers of how to proceed. I haven't tried compiling the module yet directly into PHP. I'm rechecking my compile flags, for example I added -KPIC to the compile but that didn't help. BTW, the base PHP I'm building against is 4.0.4p2. Any help would be greatly appreciated... Brian -- 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] Troubles with DL'ed module
Both were compiled with debug ON. I'll try them off. I'm away for the weekend but will try it Sunday night or Monday. Thanks, Brian Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). Andi At 01:41 PM 4/27/2001 -0500, Brian Foddy wrote: I'm having strange problems with a new DL module I'm trying to write. The most common problem is PHP will coredump after my module has executed in the module cleanup routines (the Zend routines, not my module routines). For instance it will coredump on cleaning up the 10th constant defined by my module. It cores at line 643 of zend_hash.c (the pefree line). Looking in the debugger, the address looks valid, but free doesn't like it. NOTE: The constants are defined with CONST_CS | CONST_PERSISTENT, but taking the Persistent out has no effect (the persistent flag is still set in the struct). If I remove all my constants, or make other alterations it may core in other but related places inside the cleanup. I'm doing most of this on Solaris 2.6 (sparc) with the Workshop compiler (Forte 6.1), but it seems to work ok on Linux and gcc. I'm not to the point of calling this a Zend bug and opening a bug report, but I'm hoping to get a few more pointers of how to proceed. I haven't tried compiling the module yet directly into PHP. I'm rechecking my compile flags, for example I added -KPIC to the compile but that didn't help. BTW, the base PHP I'm building against is 4.0.4p2. Any help would be greatly appreciated... Brian -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] Troubles with DL'ed module
Andi Gutmans wrote: Did you compile with debug on or off? Please try without debug in both PHP and your module and let us know if something changes. Also can you try and load it via php.ini (extension=module.so) and not with dl(). I rebuilt php 4.0.4p1 with debug off, rebuilt my module with debug off, and switched from using DL to the extension load in the php.ini. Unfortunately I still get the same coredump at the same line, just a different constant. As before I can step though it with the debugger and the address it cores in is viewable and has data. My gut is telling me its a build problem. Some address not aligned right or something. For example shouldn't the -KPIC have been used in the build argument list to libtool? But yet, in a seperate install without my new module the same version of php on the same machine is running in production very stable. Any ideas? Brian -- 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] Troubles with DL'ed module
One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- 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] Troubles with DL'ed module
I'm going to try and build it statically first. I don't have any problem posting the code (its already avail on sourceforge but you will need some proprietary libraries to build it). The MINIT and/or RINIT is the constants are initialized. You've given me some to go on, I'll work with it for a day or so first. Thanks, Brian Andi Gutmans wrote: Sounds like some kind of memory corruption. With these kind of problems even the order of statements can make a difference. Do you want to post those two functions and we can take a look at them? Also are your RINIT() MINIT() functions doing anything? Maybe they are causing problems? Andi At 11:17 AM 4/30/2001 -0500, Brian Foddy wrote: One more strange behavior I just saw. Take this little script: ? phpinfo (); $tux = tux_tpalloc (TUX_FML32, , 5000); print $tux; tux_tpfree ($tux); print $tux; ? The tux_tpalloc and tux_free are new functions in my module. If I comment out everything but the phpinfo () and hit a fresh start of the web server, it will not core. My module is loaded because I see it in the phpinfo output. After that I can uncomment the rest of the script and it will NOT core. However if I just run this script right away from a fresh restart, it will coredump. Very strange... Brian -- 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] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 1:45 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
14MB of memory in use isn't necessarily that much. Some of that memory
might be in shared libraries (shared across the Apache processes). Are you
doing any big SQL queries in those scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory manager
holds a memory cache, but we're talking at around 1MB per process max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes memory
is
growing by the minute. If I start a separate server on another port and
serve only static pages and files through it, those process do not grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can `gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
This is the answer I had previously received. IMHO, this sucks. We don't
do SQL queries on our production site. It is all cached. So, SQL is not
the problem. It is most likely because of the storage of large arrays or
something of that nature.
I guess we will continue to use MaxRequestsPerChild until one day the people
that wrote that memory allocation system get a clue.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 2:54 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
Memory is never returned to the system with libc memory allocation.
When you need memory it enlarges the address space it is using. Freeing
memory won't make it shrink its address space.
All I can suggest is to write your scripts in a way that if it deals with
many SQL queries free a query before you do the next. This way the maximum
size of your scripts memory space will hopefully be smaller.
Andi
At 02:37 PM 4/30/2001 -0500, Brian Moon wrote:
The big problem is that the memory is never returned to the system. The
Apache process holds on to it until it dies.
Brian Moon
-
Phorum Dev Team - http://phorum.org
Making better forums with PHP
-
Look for my presentation at ApacheCon 2001.
Caching Dynamic Web Content to Increase Dependability and Performance
http://www.apachecon.com/
- Original Message -
From: Andi Gutmans [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Monday, April 30, 2001 1:45 PM
Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being
freed.
14MB of memory in use isn't necessarily that much. Some of that memory
might be in shared libraries (shared across the Apache processes). Are
you
doing any big SQL queries in those scripts?
Do you have time to do some tests and let us know if things improve?
Andi
At 06:31 PM 4/30/2001 +, [EMAIL PROTECTED] wrote:
ID: 8889
User Update by: [EMAIL PROTECTED]
Status: Open
Bug Type: Performance problem
Description: Memory is not being freed.
I am talking about nearly endless amounts. I saw Apache processes
with
as
much as 14MB of memory in use.
Brian.
Previous Comments:
---
[2001-04-29 19:59:56] [EMAIL PROTECTED]
What kind of sizes are we talking about here? the Zend memory
manager
holds a memory cache, but we're talking at around 1MB per process
max.
---
[2001-01-26 18:45:45] [EMAIL PROTECTED]
Ok, this is just like what is described in
http://marc.theaimsgroup.com/?l=php-devm=97923602322593w=2 which
contains a hacked up solution. It looks like it should be able to
turn
into a usable end solution.
---
[2001-01-24 13:21:13] [EMAIL PROTECTED]
Hi guys,
I do not have much information. I know that my Apache processes
memory
is
growing by the minute. If I start a separate server on another port
and
serve only static pages and files through it, those process do not
grow.
I have tried what I remembered of gdb but have not come up with
anything. I know I need to attach to a process and it seems I can
`gdb
{pid}` but that gives me nothing. How can I get some info for you
guys? I do have --enable-debug.
thanks,
Brian.
Phorum.org
---
Full Bug description available at: http://bugs.php.net/?id=8889
--
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] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- 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] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: I too have experienced this problem and can reproduce, I just changed to the cgi version instead to eliminate the problem, which I would agree, it is. I have one page on a site of hundreds of pages that produces the large process, 30MB+ and this is on a heavily used server with more than 300 processes. So if I don't run the cgi-version the server will crash in a matter of time as the memory is not freed and eventually will swap itself to death. So while the cgi-version is slightly slower, I have reliability. John Hamlik -Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 3:20 PM To: [EMAIL PROTECTED]; Andi Gutmans Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] PHP 4.0 Bug #8889 Updated: Memory is not being freed.
That sounds like it would work also. People would have to build PHP for both modules and CGI, but if they are willing to do that... Works for me. Brian On Mon, 30 Apr 2001 23:53:16 -0400, Rod K wrote: Couldn't one just run a cgi and module version simultaneously? Set an add type directive to pass an extension, say .cphp, to the cgi instead of the module. Then those scripts that use extensive memory could be extended with .cphp??? -Original Message- From: Brian Foddy [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 11:56 PM To: Andi Gutmans; Brian Moon; John Hamlik; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. Perhaps another possible solution is this... For those 1 in 300 web hits that the developer knows is going to use gobs of memory and assuming they can't be re-engineered to use less (through temp files, etc), create a simple function that is callable in PHP that will cause the parent apache process to exit (if it doesn't exist already) It will be immediately replaced by another much smaller version ready to handle the remaining 299 web hits. This gives the performance benefit for most hits of the apache module, but the memory benefits of the cgi behavior. But before I'd do that, I'd make sure the big page can't be re-engineered first. Brian On Mon, 30 Apr 2001 18:42:59 -0700, John Hamlik wrote: I too have experienced this problem and can reproduce, I just changed to the cgi version instead to eliminate the problem, which I would agree, it is. I have one page on a site of hundreds of pages that produces the large process, 30MB+ and this is on a heavily used server with more than 300 processes. So if I don't run the cgi-version the server will crash in a matter of time as the memory is not freed and eventually will swap itself to death. So while the cgi-version is slightly slower, I have reliability. John Hamlik -Original Message- From: Brian Moon [mailto:[EMAIL PROTECTED]] Sent: Monday, April 30, 2001 3:20 PM To: [EMAIL PROTECTED]; Andi Gutmans Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. But the reverse side of this is that I might have one script out of 1000 that needs that much memory. But since 20 of my httpd processes have run that script, they all have that much memory and are not going to let it go no matter what. I basically sounds like a flaw that memory can not be freed. Reuse in the same process is not free memory, it is reused memory. And it sounds like there is nothing that the PHP team can do about it. Brian Moon - Phorum Dev Team - http://phorum.org Making better forums with PHP - Look for my presentation at ApacheCon 2001. Caching Dynamic Web Content to Increase Dependability and Performance http://www.apachecon.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, April 30, 2001 5:02 PM Subject: Re: [PHP-DEV] PHP 4.0 Bug #8889 Updated: Memory is not being freed. At 04:59 PM 4/30/2001 -0500, Brian Moon wrote: This is the answer I had previously received. IMHO, this sucks. We don't do SQL queries on our production site. It is all cached. So, SQL is not the problem. It is most likely because of the storage of large arrays or something of that nature. Well maybe you should try and see what in your script is taking up lots of memory. I guess we will continue to use MaxRequestsPerChild until one day the people that wrote that memory allocation system get a clue. They are very clue full. A program which uses X MB of memory is very likely to use X MB of memory again at a later time. For example, how does it help you if your 14 MB were shrunk back to 10 MB on each request. The next request would probably make it grow back to 14 MB. There might be some memory management libraries that shrink the memory back but I doubt you can gain much from it especially as memory fragmentation can severally limit the amount of memory you can reclaim and because of the point I made before, it's probably just not worth it. If you can find a case where you really think PHP is using much too much memory let me know and we can try and check together if there's a way to improve the situation. Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional
Re: [PHP-DEV] Bug #10598 Updated: Windows Protocol ini file placement
Looking at the API I think I can do this. The only question I have is how do I tell from inside the code whether or not PHP is a DLL or an EXE? The function call has to be made differently depending on that information. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 02, 2001 2:56 AM Subject: [PHP-DEV] Bug #10598 Updated: Windows Protocol ini file placement ID: 10598 Updated by: brianlmoon Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Install and Config PHP Version: 4.0.5 Assigned To: Comments: While I do agree with you that this is a pain, there is a possible solution assuming that you can set environment variables on your machine. Set PHPRC to the path where the php.ini file is. Then PHP will look there instead. Previous Comments: -- - [2001-05-02 03:17:12] [EMAIL PROTECTED] I've been running PHP with this: http://www.php.net/do_download.php?download_file=php405-installer.exesource _site=www.php.net Basically, I have a problem with the placement of your php.ini. I would have thought, hoped it would run from the php directory as well as the windows directory. This is standard Windows protocol. A windows *.exe normally prioritises looking in the app directory and then in the windows directory for the location of *.ini files. Your Msvcrt.dll was installed in my network drive: t:php and works like a charm; so should the php.ini!. My at-work installation of windows is NT Server based and I don't have permissions to access D:ntdir where NT was installed. I'm running a http microweb out of a separate directory and hoped to make use of PHP at work. I can't because I can't put the php in the windows directory. It won't work in my network drive: t:phpphp.ini While my case may or may not be non-standard, your port to windows lack in basic *.ini protocol. It should look in the app directory to see if the ini exists there too! -- - ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=10598edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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 #9555 Updated: Dynamic libraries are not being found in the php.ini's extension_dir
Hey James, No, this happens with all extensions. php_gtk.dll was just an example I used, it was the first, in a series of extensions, I tried loading. Brian -Original Message- From: Bug Database [mailto:[EMAIL PROTECTED]] Sent: April 29, 2001 2:37 AM To: [EMAIL PROTECTED] Subject: Bug #9555 Updated: Dynamic libraries are not being found in the php.ini's extension_dir ID: 9555 Updated by: jmoore Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Feedback Bug Type: Dynamic loading PHP Version: 4.0.4pl1 Assigned To: Comments: Does this only happen with php_gtk.dll if so you need to get a newer version of PHP, the php_gtk.dll only works with latest cvs not with 4.0.4. It will work the 4.0.5 when its released. - James Previous Comments: --- [2001-03-05 02:41:15] [EMAIL PROTECTED] Everytime I try to load any dynamic library from the php.ini's extension_dir, I get the following error (the dll specified changes depending on what library I am trying to load): Unable to load dynamic library 'C:Inetpubphpextensions/php_gtk.dll' - The specified procedure could not be found. My php.ini file contains the following line: extension_dir = C:Inetpubphpextensions It occured to me that I was missing a trailing backslash; therefore I changed my ini file to: extension_dir = C:Inetpubphpextensions This didn't seem to help as I got a similar error message: Unable to load dynamic library 'C:Inetpubphpextensionsphp_gtk.dll' - The specified procedure could not be found. I then thought that maybe any dll I load from the extension dir must also be in the %systemroot%system32 dir, so I copied the php_gtk.dll to C:WINNTsystem32. Sadly, I kept getting the same error. I also tried putting single qoutes and double qoutes around the extension_dir path... as you can guess, I got the same error. This seems to me, to be a very serious problem! I can't understand how the inability to load dynamic libraries has gone unnoticed for so many versions. Any help on this matter would be greatly appreciated! I am running php 4.0.4pl1 as a CGI on Windows 2000 / IIS. As a side not, I have compiled and configured php many times, on various Linux installations, and dynamic loading works perfectly. --- ATTENTION! Do NOT reply to this email! To reply, use the web interface found at http://bugs.php.net/?id=9555edit=2 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Zend API changes
A small point I'd like to raise here. I noticed 4.0.5 made a change to the arguments of zend_hash_get_current_key by adding a dupe argument to the define and underlying function. This of course broke any external custom modules that are not changed appropriately. In this case the change was very simple, but it raises a good question... Are there some guidelines independent external modules can follow to remain more compatible between releases? I'm not questioning the right or need for underlying Zend API changes, obviously when such changes are made all functions inside the PHP collection are change accordingly. But are there suggestions to minimize these in the future and get better notified when they do occur? Thanks, Brian -- 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 #9878 Updated: gmmktime is 1 hour off during standard time
On 5 May 2001 19:40:27 -, Bug Database wrote: ID: 9878 Updated by: rasmus Reported By: [EMAIL PROTECTED] Old-Status: Open Status: Analyzed Bug Type: Date/time related PHP Version: 4.0.4pl1 Assigned To: Comments: Are you sure that bit of code applies in your case? ie. is HAVE_TM_GMTOFF undefined in your main/php_config.h file? I am unable to recreate this problem here, but on my Linux box my gmadjust value comes straight from the libc system call ie. I have HAVE_TM_GMTOFF defined. Previous Comments: Yes, Solaris 2.6 does not have the tm_gmtoff value in the tm structure in time.h, and correspondingly the php_config.h does not define the HAVE_TM_GMTOFF value. I don't know if newer versions of Solaris have this value. My linux has the value. I suppose you can rebuild your Linux and override this define to try and duplicate the problem. Also remember it only happens during the standard timezone which ended in early April in the US. If its any help, I'm using the exact patch I suggested on our production Solaris environment and it worked fine before and after the time shift. Until your note, I didn't know how common this value even is in the structure, I'll have to make note of it for later use. Thanks, Brian -- 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] stat/fstat
Zeev Suraski wrote: At 18:21 11/5/2001, Brian Foddy wrote: [EMAIL PROTECTED] wrote: On 11 May 2001, Stig Sæther Bakken wrote: Why not have both numerical and descriptive indices? Backwards compatible, slightly bloatish, but not really a problem. it's already implemented this way now (it was added last night) AFAIK Derick Rethans You are creating the same array indexed both by a integer and a string? I'm curious how this is done. I might have a good use for this trick. No special tricks needed; PHP's arrays support both numeric and string indices ever since PHP 3.0 (at least). You can simply add both types of indices to the same array without having to do anything special. Thanks everyone, I knew arrays could be one or the other, but never considered the same value with multiple indexes. I have a perfect use for this, where an array I build, the values have a int index value, and a string an equiv string name. I'm already doing the zend_hash_update and index_update functions anyway, so this should be pretty easy. Question, what will zend_hash_get_current_key return if it gets input like this? Brian -- 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] Integer casts broken or...?
This is correct. The type casting converts the string into its integer value. If there is a non-numeric character in the string, it stops at that point. So 09 is 9 and 09t is 9 but 0t9 is 0. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Lars Torben Wilson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 1:29 PM Subject: [PHP-DEV] Integer casts broken or...? Type casting to int from string works only for decimal values--is this by design? Example: echo (int) '09' . ', ' . (int) '0x24'; ...produces: 9, 0 which seems intuitively wrong (I'd have expected 0, 36). Is this wrong, or should I just document it? Thanks, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com +1.604.709.0506 -- 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] weird passthru() behavior
I know that passthru only outputs what was sent to stdout and nothing else. So, if XalanTransform is sending output to something other than stdout then that might be it. That is just my experience with passthru. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Michael Dickson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, May 14, 2001 7:39 PM Subject: [PHP-DEV] weird passthru() behavior I have a php script that looks like this: ?php passthru(sabcmd foo.xml foo.xsl); ? It works fine. But when I instead try: ?php passthru(XalanTransform foo.xml foo.xsl); ? I get no output (no errors either, just nothing---if I add some html code around the php script then this html code comes out, but still nothing from the passthru().) Some relevant facts: 1. When run from the command line, sabcmd foo.xml foo.xsl and XalanTransform foo.xml foo.xsl return exactly the same thing to the terminal. 2. sabcmd and XalanTransform are both C programs, and they both reside in /usr/bin. Any hints about what is going on here would be greatly appreciated! P.S. In case you're wondering, sabcmd and Xalantransform are XSLT engines. They translate foo.xml according to the rules in foo.xsl and send the result to the terminal. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Re: [PEAR-DEV] Comparison style
There is another reason as well. type casting is done right to left. This will always ensure that the variables type is compared to , which will convert to 0 if $content is a number. Not sure if this was intentional or not, but it is true. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Jon Parise [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, May 14, 2001 9:31 PM Subject: [PEAR-DEV] Comparison style I was just perusing some of the PEAR code, and a certain condition caught my eye: if ( == $content) My habit has always been to write that sort of condition using the style: if ($content == ) (leaving the unknown value on the left side of the comparison operator) Is one of these styles preferable to the other, either always or in certain instances? -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- PEAR Development Mailing List (http://pear.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] removing ereg functions
That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 2:19 AM Subject: Re: [PHP-DEV] removing ereg functions Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Uh, are you out of your mind? -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] removing ereg functions
No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I understand your reaction now Rasmus. Sorry for the confusion. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Zeev Suraski [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 3:17 AM Subject: Re: [PHP-DEV] removing ereg functions At 08:50 16/5/2001, Brian Moon wrote: Is it possible to remove the ereg functions? We have a strict policy to only use preg as they are more reliable and faster. So, I am not to happy that PHP is bloated with these ereg functions. Any thoughts? Wow, it's like a plague out there. :) No way. ereg() has got to be used by millions of code lines around the world. I don't see it being removed in this millennium. These functions can fit nicely into the lean-and-mean approach. Zeev -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] removing ereg functions
The problem is not the PHP C code. It is the regex library. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: John Lim [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 10:51 AM Subject: Re: [PHP-DEV] removing ereg functions In my mind the problem that Brian raised is that ereg is slow. The solution is not to ban eregi but to fix it by performance tuning the C code. Just my 2c worth. John Lim Rasmus Lerdorf [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... That is why I am asking. Is there a core reason that the ereg functions have to be there? I could extend this to other functions as well of course. But this set in particular I have wondered about. 1) There was no PCRE library when I first added regex support to PHP. Henry Spencer's regex library, although not my initial choice, was chosen because that is what came bundled with Apache. 2) The ereg_* functions implement the Posix 1003.2 extended regular expression standard. The same regular expressions found in the Unix command line utils like grep, egrep and fgrep. The preg_* functions support the perverted Perl-style regular expressions. 3) Removing the ereg_* functions would cause a backward compatibility nightmare. Thousands, if not hundreds of thousands of scripts out there would have to be converted. 4) If you are using Apache you already have the library linked in anyway. Removing PHP support wouldn't save you any bloat. Not that this bloat is at all significant on any modern OS with shared pages. -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 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] removing ereg functions
I guess it just seems a little odd too me that PCRE is optional and POSIX is not. I know the history and all. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, May 16, 2001 11:33 AM Subject: Re: [PHP-DEV] removing ereg functions No, sorry, I think you misunderstood my question. I would just like to see a --disable-ereg option for configure. I would never dream of removing ereg from PHP as a supported function set. It would break Phorum and lots of stuff I have written. I just don't see the point in this. There are other functions like split() that rely on the ereg code, and since removing the code isn't actually going to save you anything as the library is non-optional in Apache, removing the hooks from PHP makes no sense. I don't think disabling functions in PHP is a good way to enforce coding conventions. -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 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] Zdnet Article
That may be the worst done article I have ever read. I could rewrite every paragraph and turn it on ASP or Perl or any language. He obviously did not put much effort into it. My Take: The Unix version of ASP, unfortunately, cannot be taken seriously as it does not exist except in a very expensive form from ChiliSoft. We scanned the web for comments on IIS and commonly found that there are built in back doors that allow everyone in the world to see your code. ASP uses some sort of home rolled database abstraction layer that limits the use of key features of most databases and turns them all into simplified useless tools. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Emmanuel FAIVRE [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, May 17, 2001 5:22 PM Subject: [PHP-DEV] Zdnet Article http://www.zdnet.com/products/stories/reviews/0,4161,2711724,00.html no word to comment that ! just see a adbanner for ColdFusion on the same page ! Manu -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Manual Error
Maybe its just me, but the section to do with objects, more specifically the :: page is labelled: http://www.php.net/manual/en/keyword.paamayim_nekudotayim.php Is that how it should be? -Tanner -- 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] Need Help!!
I want to try to fix the character truncation problem when using an mssql database, but I can't seem to figure out how to compile PHP under VC 6. I have searched all over the site for some insight into what to do, but I am still having problems creating/finding TSRM.mak. Any and all help would be apreciated. Brian P.S. The problem I refer to is that in the php_mssql.dll extension char and varchar are treated as chars, this limits the length of the string to 256 characters. But, the problem is that and nvarchar in MS SQL can be up to 4000 characters! So, I want to try to fix the problem in the dll, but it requires the php dll and so on. -- 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] Need Help!!
Yes. There is nothing specific in there about compiling the code under windows. Brian James Moore [EMAIL PROTECTED] wrote in message 01c0e2f6$4aacba80$010a@zeus">news:01c0e2f6$4aacba80$010a@zeus... I want to try to fix the character truncation problem when using an mssql database, but I can't seem to figure out how to compile PHP under VC 6. I have searched all over the site for some insight into what to do, but I am still having problems creating/finding TSRM.mak. Any and all help would be apreciated. Have you tried reading the manual?? - James -- 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] Bug #11075: bad operation of nl2br function
Ok, I've seen this bug reported too many times to sit idly by. :) The br / has the / so that the html is XHTML compliant. (if memory serves) My question -- is this breaking anything for anyone? Is br / in any way detrimental to browsers anywhere? Brian Tanner Project Manager Zaam Internet Solutions -- 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] Register_Shutdown_Function happens before shutdown
In theory (at least IMHO), this function should be used to register functions to finish up after the client has detached from the server. This way, time consuming tasks like logging, closing connections, sending e-mail, or whatever can be done *after* the client is happily surfing to their next page. However, I have tested Register_Shutdown_Function as much as I can locally, and no matter what I try... I have to wait until my shutdown functions are done before I see the page, get redirected, or whatever. This is bug or a feature? Or am I a dummy? -Brian Tanner -- 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] Bug #11512: Parsing of vars inside a string
I think the problem here is that $varone_foo is the valid form of a variable so: $vartwo=$varone_foo; is getting parsed as a single variable called $varone_foo PHP is *smart* enough to know that foo_$varone is not a valid name for a variable or constant, and it goes out of its way to implicitly treat it like: $vartwo=foo_.$varone instead of $vartwo=foo_$varone; You mentioned that in your example, $vartwo is not blah_foo as expected... if you cranked your error reporting, you'll probably get an error like $varone_foo is not a valid variable -Brian Tanner $varone=blah; $vartwo=$varone_foo; = The resulting contents of $vartwo is not blah_foo as expected. You can only get the desired result by having $vartwo= $varone . _foo; However something like $vartwo=foo_$varone works as expected = foo_blah; Is this a language construct issue perhaps? -- Edit Bug report at: http://bugs.php.net/?id=11512edit=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 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] Register_Shutdown_Function happens before shutdown
PHP lives inside the connection and content delivery area of Apache. Therefore, all code is parsed while the connection is open. You must have some bad HTML design however if you can not see your page until after all that is done. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Brian Tanner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 8:15 PM Subject: [PHP-DEV] Register_Shutdown_Function happens before shutdown In theory (at least IMHO), this function should be used to register functions to finish up after the client has detached from the server. This way, time consuming tasks like logging, closing connections, sending e-mail, or whatever can be done *after* the client is happily surfing to their next page. However, I have tested Register_Shutdown_Function as much as I can locally, and no matter what I try... I have to wait until my shutdown functions are done before I see the page, get redirected, or whatever. This is bug or a feature? Or am I a dummy? -Brian Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] File Handle Resource
Now that the list is back up, I have a question... In my module I'm writing, I need to have some functions that will take as an argument a FILE resource id. So the question begs asking is there any function I can call to obtain the FILE resource structure (that contains the FILE*) from the standard file module? In my module, I don't want to have to modify the File code, or make some variable global or anything. I just want the user to give me the File resource, let me call a function that will give me the structure to the open FILE *. Does that exist? Any other suggestions? Brian -- 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] Register_Shutdown_Function happens before shutdown
//You must have some bad HTML design however if you can not see your page until after all that is done. Thanks for your insight. You are very wise. //PHP lives inside the connection and content delivery area of Apache. //Therefore, all code is parsed while the connection is open. I'm not talking about the code being parsed, I'm talking about it being executed. However, form your other comment, I am going to assume that you meant executed, and you are trying to tell me that code cannot execute after the connection is severed. This function must be a part of my imagination then: int ignore_user_abort ([int setting]) Also, it seems pretty useless that ShutDown functions can't output to the browser... if it is guaranteed to be hanging around anyway. Why is that? -Brian Tanner Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Brian Tanner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 18, 2001 8:15 PM Subject: [PHP-DEV] Register_Shutdown_Function happens before shutdown In theory (at least IMHO), this function should be used to register functions to finish up after the client has detached from the server. This way, time consuming tasks like logging, closing connections, sending e-mail, or whatever can be done *after* the client is happily surfing to their next page. However, I have tested Register_Shutdown_Function as much as I can locally, and no matter what I try... I have to wait until my shutdown functions are done before I see the page, get redirected, or whatever. This is bug or a feature? Or am I a dummy? -Brian Tanner -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Cookie Detection
//When browser turnoff cookie support, the PHP will add session id at end of all local URL links Can someone put me up to date on exactly *HOW* PHP knows if cookies are enabled? Is there a practical way to check for that? I have my own session handling implemented... and I do both sid passing as well as cookies... but I'd love to know how to detect -Brian Tanner -- 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] Totally Blue Sky
Sounds like a great idea. You could probably improve it by not using an actual browser, but by using the browser properties in a standalone application. Here me out... I am confident there are some Windows widgets that let you easily build you own browser.. which is actually Internet Explorer without all of the options. If you were to make a more limited browser interface (so that you cut out the browser functionality that an application shouldn't have home,forward,back,view source, disable javascript,disable cookies,etc, etc, etc), and then install the browser application... you could probably make it a standardized .EXE so that any user written PHP program would run on it. Other than that, you just need to get the web server figured out. How hard would it be to customize this browser application to start and quit apache in tandem with the application. Again, agree on a standardized apache config so that there is only one site running... which is on local host, you're pretty much set. I think its a great idea. Brian Tanner Project Manager Zaam Internet Solutions Toll Free: 1-866-225-2675 [EMAIL PROTECTED] http://www.zaam.com Situation: PHP is the greatest damned language I've ever used. With PHP and a database on the back-end, and a decent browser capable of running Javascript/JScript on the front end, you can create beautiful, seamless web applications with so little work that it almost seems like cheating. Problem: If you don't want your application to be just a web application, then you're stuck using some other relatively stinky language. Shudders while thinking back to the days when you had to write thousands of lines of code just to put some graphics on the screen or open a socket to a web server Variation on a theme: I'd love to be able to create a PHP Windows .exe that installed just like a regular application. This ideal program would run just like an application too. You'd launch it and it would open an application window, but the window contents would be the current web browser installed on the system, pointed to the index.php page in your newly installed application's directory. In other words, it would be like installing a PHP-enabled webserver whose output could only go to the application's main and child windows (if any). I do NOT want to require the user to install a webserver and I do NOT want the server to keep running after the application has quit, but I would LOVE to be able to do basic application type actions like saving files without having to resort to lame, bloated, miscarriages like signed Java applets. Also, I would LOVE to be able to simply create user interfaces without writing tons of code like in Visual C++. Admittedly, Visual BASIC is similar in purpose here, but as we all know, VB ain't got nothin' on PHP. Questions: [1] Does such a beast exist? [2] Can anyone think of a fundamental reason why we couldn't do such a thing? [3] Is the general consensus that this would be a handy thing to have, or is it just me? Please be kind with the flames, I'm new here... Gre7g. = Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/ Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm I want to die peacefully in my sleep, like my grandfather ...not screaming in terror like his passengers. -- 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] Bug #8989 Updated: Bug#5493 resurfaced
I want to chime in here. The reason (IMHO) that they are asking you to test the latest release is because you are reporting a symptom of a bigger problem. They *think* that they fixed the bigger problem. However, the best way to be *sure* (like you want) -- is to have people see if the symptoms are gone. Instead of recreating every problem that people describe... they try to fix the root cause, and see if all of the related problems go away. Make sense? -Brian Amazing. No report has been made that the bug has been resolved, yet you have a burr up your butt to close out the problem anyway. Great debugging technique. Truly professional. Good to know PHP is in such good hands. Yes, to answer your comment, I DO remember that I wrote that. In fact, it's basically a repeat of the same thing I wrote earlier, since you did not seem to pay attention the first time. Each time a point release is out, I check it, as I--like many PHP users--would like to have the latest features and bug fixes. PHP totally kicks ass, but unfortunately there are some glitches from time to time. HOWEVER, a nightly CVS build is not considered by most to be a stable release. Ergo we have such things as RELEASE CANDIDATES. PHP is now at 4.0.6 RC3 if memory recalls correctly. However, this too is not a full release. RCs are basically like beta releases for those so inclined (and with sufficient time) to be guinea pigs. CVS nightly builds are for those normally heavily involved, RCs are for those who want to help point out flaws in the next release, and then actual point releases are what most users obtain. I apologize if I don't satisfy your sudden demand for people to jump at testing your nightly builds or RCs. But like many I actually have a job and life that requires most of my time. I gladly test full point releases, but unfortunately do not have time to be your daily minion. This is the first time I've witnessed anyone involved with PHP development act in such a manner. I hope it's not a sign of things to come. Previous Comments: --- [2001-06-19 16:45:30] [EMAIL PROTECTED] Do you remember this: I have not tried the latest snapshots. I tend to wait for point releases to re test. Unfortunately I do not have that much time to keep retesting with the nightly b uilds, etc. When 4.0.6 is released, I will test with that. Then reopen this report when it is not fixed in 4.0.6. period --- [2001-06-19 10:56:24] [EMAIL PROTECTED] What is this, the Microsoft approach to dealing with bugs? You have no evidence if the problem is resolved, yet you close out the problem anyway. Burying your head in the sand doesn't make the issue go away. I'm sorry, but you don't close a problem until a resolution is found and the fix confirmed. There is a session bug, which existed in early 4.0 releases, was then fixed, and is now broken again. The last working version of PHP for Windows that did sessions properly was 4.0.3pl1, and nothing thus far indicates that this issue has been resolved since then. I have updated the PHP Version for you to reflect the problem still exists in 4.0.5, the latest release most users would touch. Most PHP users are not about to touch nightly CVS builds. That's why you HAVE point releases like 4.0.3pl1, 4.0.4, 4.0.5, etc. This problem should remain open until it can be confirmed that the bug is fixed. --- [2001-06-19 09:27:34] [EMAIL PROTECTED] Reopen this if it doesn't work with 4.0.6. --Jani --- [2001-06-15 11:08:43] [EMAIL PROTECTED] I have not tried the latest snapshots. I tend to wait for point releases to retest. Unfortunately I do not have that much time to keep retesting with the nightly builds, etc. When 4.0.6 is released, I will test with that. --- [2001-06-14 23:18:19] [EMAIL PROTECTED] Does this happen with latest snapshot from http://www.zend.com/snapshots/ ?? There have been some fixes regarding this. --Jani --- The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online. Full Bug description available at: http://bugs.php.net/?id=8989 -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Command line option for shell scripting
Hi guys, I would like to create a command line option that would do the following: assume -q ignore error_prepend_string and error_append_string set html_errors off turn off output buffering if it is set in ini file. anything else? I use those ini settings in the apache module but don't need them in the binary running cron jobs. Having two ini files is a pain. If I could get just one command line option that would do all of that it would rock. I would be willing to do the work, although, last time I tried to submit a change (a bug fix) I was told I do not have karma. Did something change with the premissions or was that just part of the temporary server setup? I have tried playing with zend_alter_ini_entry() but it seems to have a queer reaction to passing as the value. It does not set the value of the setting to . Instead it continues to use what is in the INI file. There does not appear to be a simple function to unregister a ini setting. I need to have an ini_entry struct and a module number to do that. Any pointers on that? Thanks, Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DEV] List messages are being delayed?
The hard part is finding someone who is willing to do it and does not want a lot of advertising in return. Good Luck. BTW, what kind of machine does it take to turn the list out? I know you were on a dual CPU box with Gig of ram at VA. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Rasmus Lerdorf [EMAIL PROTECTED] To: Daniel Beckham [EMAIL PROTECTED] Cc: Bug Database [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 8:55 AM Subject: Re: [PHP-DEV] List messages are being delayed? From what I can tell, you are hosting this on your own connection at home/work? Is there no one in the community that is willing to host the server for you guys? It is on my home DSL connection. And yes, there are people willing, but we are somewhat picky about the terms of such hosting. We basically want a server to ourselves with full root access, but we also want someone we can call who will get the server back up and running quickly if something happens. And we want to host it somewhere that will still be around in 6 months. -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 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] Totally Blue Sky
GTK is actually a GUI and is not based on HTML at all... I think what Greg is looking for is an HTML based application that runs standalone... -Brian Have you looked at http://gtk.php.net/? Maybe that's what you need. Edin - Original Message - From: Gre7g Luterman [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, June 19, 2001 9:43 PM Subject: [PHP-DEV] Totally Blue Sky Situation: PHP is the greatest damned language I've ever used. With PHP and a database on the back-end, and a decent browser capable of running Javascript/JScript on the front end, you can create beautiful, seamless web applications with so little work that it almost seems like cheating. Problem: If you don't want your application to be just a web application, then you're stuck using some other relatively stinky language. Shudders while thinking back to the days when you had to write thousands of lines of code just to put some graphics on the screen or open a socket to a web server Variation on a theme: I'd love to be able to create a PHP Windows .exe that installed just like a regular application. This ideal program would run just like an application too. You'd launch it and it would open an application window, but the window contents would be the current web browser installed on the system, pointed to the index.php page in your newly installed application's directory. In other words, it would be like installing a PHP-enabled webserver whose output could only go to the application's main and child windows (if any). I do NOT want to require the user to install a webserver and I do NOT want the server to keep running after the application has quit, but I would LOVE to be able to do basic application type actions like saving files without having to resort to lame, bloated, miscarriages like signed Java applets. Also, I would LOVE to be able to simply create user interfaces without writing tons of code like in Visual C++. Admittedly, Visual BASIC is similar in purpose here, but as we all know, VB ain't got nothin' on PHP. Questions: [1] Does such a beast exist? [2] Can anyone think of a fundamental reason why we couldn't do such a thing? [3] Is the general consensus that this would be a handy thing to have, or is it just me? Please be kind with the flames, I'm new here... Gre7g. = Gre7g Luterman [EMAIL PROTECTED] http://www.templeofluna.com/ Stay informed: http://www.templeofluna.com/keeper/mailinglist.htm I want to die peacefully in my sleep, like my grandfather ...not screaming in terror like his passengers. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] Command line option for shell scripting [ And some interactive mode issues]
Looks like we just need to call: zend_unset_timeout(); zend_set_timeout(0); in sapi/cgi/cgi_main.c. I will put this in the patch I send in. This is a good idea. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: James Moore [EMAIL PROTECTED] To: 'Brian Moon' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 5:00 PM Subject: RE: [PHP-DEV] Command line option for shell scripting [ And some interactive mode issues] Something along this line which I wanted to do was to turn the time out off for interactive mode as at the moment it times out after 30secs, anyone got any objections if I make that change?? - James -- 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] Command line option for shell scripting [ And some interactive mode issues]
output_buffering also needs to be turned off in interactive mode. I will add that as well. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: James Moore [EMAIL PROTECTED] To: 'Brian Moon' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, June 20, 2001 5:00 PM Subject: RE: [PHP-DEV] Command line option for shell scripting [ And some interactive mode issues] Something along this line which I wanted to do was to turn the time out off for interactive mode as at the moment it times out after 30secs, anyone got any objections if I make that change?? - James -- 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] [emile@iris-advies.com: Re: [PHP-DEV] Adding URI Translation Handlers]
Isn't this what mod_rewrite is for? Also, what we do is have urls like: http://dealnews.com/articles/23930.html We use a force type on the feil articles to make it get parsed as PHP. We then read $PATH_INFO in which is /23930.html to set up our vars. You could have: http://florists.ftd.com/florists/rosebowlfloral/ Although it makes for a longer URL, it does not require all the files you talked about and does not require any C. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Stephen van Egmond [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Friday, June 22, 2001 12:09 AM Subject: [PHP-DEV] [[EMAIL PROTECTED]: Re: [PHP-DEV] Adding URI Translation Handlers] Back when the mailing lists were down, I started a discussion about adding a feature to PHP to do URI translating. The brief definition of URI translation is that you get to rewrite URIs dynamically. This is how you you would host, for instance, 10,000 florist home pages: http://florists.ftd.com/rosebowlfloral/ and http://florists.ftd.com/fiveflower/ without having 10,000 directoriies under the server root. In Apache, these would be rewritten to a directory containing the style of page the florist chose, with some extra apache notes to tell you which florist page had been visited. The question I wanted to raise was how to do this. And although it looks like initially a simple task, it generalizes to a few other concepts which Apache + mod_perl has done wonders with. This was the most recent post on the topic, and I wondered if there were other thoughts out there? Failing that, I will probably pursue the approach of building this into the Apache SAPI and letting other web servers follow suit. - Forwarded message from Emiliano [EMAIL PROTECTED] - Date: Thu, 31 May 2001 09:34:00 +0200 (CEST) From: Emiliano [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Adding URI Translation Handlers Stephen van Egmond wrote: One thing which I am bumping into is the need to do URI rewriting, kind of like what mod_perl does. I would like to implement this myself in mod_php, and I'm looking for some advice on the implementation. I considered the following: a) Allowing the automatically prepended file (see php's auto_prepend_file config option) to change $ENV['REQUEST_URI'] before the script is actually executed. This, intuitively, seems clean, but would probably happen too late in the request process (it will have already decided to call the error file). Yep. This would be executed in the response phase, but apache itself would have decided in the translation phase way before that not to handle the request. b) adding a new config directive that... what? defines a file to be read which is supposed to define a function? Is eval'ed? The way I see it you have a couple of options: - Use mod_perl, mod_python, mod_tcl(I think) to script a translation handler. - Write a translation handler in C (we do this with Midgard) - Extend mod_php4 to do what mod_perl et al do so you can write handlers in PHP. Conceptually, this is not too hard, but will definately be more work than the other two. You set up the zend engine just like the response phase handler does, set a few relevant variables before you start it (like $ENV['REQUEST_URI'] for example, kick off the script (either be just executing the code, or calling a function therein), then read the relevant variables after the script exits and act on them. You'll be doing this in C. Emile - End forwarded message - -- ,,, (. .) +--ooO-(_)-Ooo- - -- - - - - | The Annotated BeBook: http://bang.dhs.org/be/bebook/ -- 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] Adding URI Translation Handlers
Now as for precompiled code, I am all for that. We have lots of bit of code that are run on every page and I know that it is possible to rework all this somehow to not have to do that. I am still not clear on your problem with the rewriting. I don't see what the number of files in the templates has to do with anything. Can you elaborate more on that. Maybe some examples of what the request would be and how you would rewrite it and why. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Stephen van Egmond [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Friday, June 22, 2001 12:50 PM Subject: Re: [PHP-DEV] Adding URI Translation Handlers Brian Moon ([EMAIL PROTECTED]) wrote: Isn't this what mod_rewrite is for? mod_rewrite works only in a static sense. You set up your rules, and fire up your Apache. If your rules change (as they certainly will in the case of 10,000 florists), you have to rewrite the rules file and restart apache. http://florists.ftd.com/florists/rosebowlfloral/ It also doesn't address the issue of the various files which will be there. Path_info will work with one file, in the case of articles. But if each (in this case) florist has a series of files in their templates (product detail pages, personal accounts, ordering pages, etc) you're out of luck. The example is real; I was the lead developer for florists.ftd.com for most of last year. The point I'm making is that I would like to improve the Apache SAPI code for PHP to support more of the Apache server's features, like the request rewriting step, tear-up/tear-down, and even precompiling code when the server forks so that it doesn't need to be recomputed on every hit. Are there other people interested in this that would like to get a hacking crew together? -- 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] Internal Working -- performance question
I'm am writing a large web application, and on every request, my pages must
load the environment, which takes up a significant amount of time (.1
seconds on a Athlon 1 Ghz).
Much of that time seems to be spent on loading the environment from disk,
and processing it into usable form.
So I thought of running a PHP script all the time, that accepts socket
connections, transfers all the data in serialized form through a port to the
requesting script. The PHP script that is always on would only have to load
the data files once.
Sounds great right... but it actually is slower to transfer data through a
TCP/IP connection from 2 ports on the same machine, if you are doing it with
small chunks (100 Kbytes at a time) -- but I noticed if I cranked the chunk
size, it was up to 100 times faster:
while ($out=socket_read ($sock,10)) {
$EncodedString.=$out;
}
Now, what I am wondering is:
a) Is there a faster way to send data between 2 processes, that will work
with PHP, and is supported by Windows and *nix.
b) Is there any drawback to use data chunks that are: 10 bytes?
I'd ask this on the other list, but nobody is going to really have a good of
a handle as you guys.
-Thanks in advance, sorry for the intrustion.
-Brian Tanner
--
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] Internal Working -- performance question
Thats what I'm looking at doing actually... I would really love to have shared mem in Windows... cause thats what I develop with :( But yah... looking at the 3 pronged approach, falling back to slower and slower implementations. Should make things fast in a good environment at least :) Thanks. -Brian -Original Message- From: James Moore [mailto:[EMAIL PROTECTED]] Sent: June 23, 2001 3:04 AM To: 'Brian Tanner'; [EMAIL PROTECTED] Subject: RE: [PHP-DEV] Internal Working -- performance question a) Is there a faster way to send data between 2 processes, that will work with PHP, and is supported by Windows and *nix. How about abstacting it, under Linux use shared mem (should be fastest) if its avalible, other wise use sockets then If that's not avalible use database/file version. - James -- 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] Read a file into a string (RE: [PHP-DEV] Sablotron leaks)
Doesn't this do that? $FilePointer=fopen($FileLocation,r); $_MyString.=fread($FilePointer,filesize ($FileLocation)); fclose($FilePointer); Althought I guess this could suck memory pretty hard on large files, and you guys want to get away from that... -Brian Blah... I see this a lot. We should probably just relent and make a function that reads an entire file into a string. Yes, please do :) -- 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] About ext/sockets/
Just thought I'd pipe up on this topic, cause its very applicable. I'm a 4th year Honours CompSci student. I've written some client server stuff in C (hence a little sockets experience), and I have been using PHP for a year now. My *only* complaint of PHP is that all the really fun stuff (memory sharing, sockets, couple of others) doesn't work for Windows. I've coded sockets for *nix in C before, but I am rusty. It took me 30 minutes to get familiar and start coding with the new API. The changes are are very straightforward, and make the socket extension work more like the rest of PHP. Returning 0 for success and negative numbers just isn't how PHP does things. http://introverted.com/php-sockets.html Considering a very low % of PHP programmers have extensive C socket experience, I wouldn't worry too much about making it inconvenient. You guys are just a little biased (IMHO), because you are all talented, experienced, C programmers. Anyway.. basically just wanted to say that I have used the new API, it works well, and I was very happy to see sockets making it to windows. -Brian Tanner -Original Message- From: Sascha Schumann [mailto:[EMAIL PROTECTED]] Sent: June 24, 2001 2:19 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] About ext/sockets/ Jeroen, For lower-scale and home-use you can argue it is easier than *nix. So when possible, you should try to support windows. [..] [looked like C, was easier for ppl with C-background] I don't think you should target php at C-ppl. PHP has been since its inception strongly influenced by C. And as a tool originally conceived on Unix, it should maintain its roots and continue to provide people familiar with Unix APIs a convenient way for scripting. Thus, improved Windows support should not come at the expense of Unix support without a perfect reason. I'm missing that reason here. I haven't looked deeply at what API changes have been introduced lately, but I'd suggest to use the standard BSD sockets return value semantics (-1 for failure, = 0 for success). Those semantics also prevail in the Winsock implementation, so they should be quite natural. - Sascha Experience IRCG http://schumann.cx/http://schumann.cx/ircg -- 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] Totally Blue Sky
I'm not sure you would be able to distribute a commercial application that is built around PHP commercially, could you? Isn't that what the GPL protects against? -Brian -Original Message- From: Marc Boeren [mailto:[EMAIL PROTECTED]] Sent: June 25, 2001 12:56 AM To: 'Gre7g Luterman'; '[EMAIL PROTECTED]' Subject: RE: [PHP-DEV] Totally Blue Sky I am pleased to announce that I dove into this new idea last night and made my first proof-of-concept program (PoC-1) for this new programming environment (which I am calling LocalPHP for the lack of a better name, any suggestions?). I have a version of exactly what you wish to do right here in the final stages of development. It includes an executable that contains the htmlview, a dll that catches all requests from the htmlview and processes them (either by passing them on to php and passing the results back to the browser, or by returning the requested file as-is). It doesn't need Apache or anything, just the cgi-version of php (including any modules you wish to use), and an IE4. It could easily be extended to fetch all files from one big library (thus protecting your php-source) or to start other apps as well (map any extension to any executable... Perl, custom executables, whatever) We're still looking into the method of distribution, whether it will be a commercial app or an open source project and such things, but your efforts might kick a few people over here into motion :-) As you can understand, I can not really say more about this project at this time, but I'll hope to come back to this soon! Cheerio, MArc. -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] Scratch That about Arg_Separator
Found it.. sorry to bug you all. -Brian -- 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 -- (manual send -- the Bug mail send failed)
From: [EMAIL PROTECTED] Operating system: Win32 (Win 2k) PHP version: 4.0.6 PHP Bug Type: Scripting Engine problem Bug description: Unserialize dies with Apache Module but is FINE with CGI I've been running fine on CGI for a while now, jumping between 4.04, 4.07-dev, 4.05 When I tried to switch from 4.05 CGI to 4.05 4.05-Apache ... one of my files does not unserialize properly. The error message is: Warning: unserialize() failed at offset 487 of 2797 bytes in c:\program files\apache group\apache\htdocs\gt2\libraries\classes\module.class on line 189 If you guys know something about this, please let me know, as soon as possible. In the mean time, I am going to make a script that saves a serialized object to disk. I will save it to a file using CGI and then Apache modules. Then, I will try to load em both using Apache and CGI modules... see what turns up. -- 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] Memory limit is used for all scripts instead of one?
What version of PHP are you using? There were some changes in 4.0.6 that
may change your results.
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: Swift [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 27, 2001 9:52 AM
Subject: [PHP-DEV] Memory limit is used for all scripts instead of one?
Warning: Could not execute mail delivery program in
/local/Web/sites/phpweb/bugs.php on line 419
Mail not sent!
Please send this page in a mail to [EMAIL PROTECTED] manually.
--
Hi there!
As far as I understand, the option memory_limit sets the mem-limit for
ONE script.
I installed PHP as a Apache module and I set the memory_limit to 16M
(via php.ini).
When I allocate 8M of memory, all works fine. But when two different
scripts each allocate 8M, I will get sometimes the following message:
Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to
allocate 4194304 bytes) in /usr/local/httpd/htdocs/testxx.php on line 6
Both scripts (testx.php and testxx.php) contain the following code:
?php
$str = x;
for($i=0; $i23; $i++)
{
$str .= $str;
echo strlen($str) . br;
}
?
First, 1 byte will be allocated, then 2, then 4 and so on. The last
allocated string has a size of 8M.
It's a little difficult to reproduce the problem because I have to call
both scripts exactly at the same time from my browser. But, as I said,
sometimes I get the described error-message.
My question is: Is this normal and memory_limit sets the limit for ALL
scripts that are currently running or is this a bug?
Thanks in advance!
... tobias wiersch from germany
--
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] PHP Bug Type: Strings related ???
You have magic_quotes_gpc turned on. You will need to stripslashes anything passed in as a GET var. You can turn this off in php.ini or Apache conf files (including .htaccess). See the configuration portion of the manual for instructions. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Guido Laubner [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, June 27, 2001 12:39 PM Subject: [PHP-DEV] PHP Bug Type: Strings related ??? From: [EMAIL PROTECTED] Operating system: Solaris 8 / Intel PHP version: 4.0.4pl1 PHP Bug Type: Strings related Bug description: Backslash parameter passing in Forms Here's instructions on how to reproduce : 1. Create a php-file with this content : HTML BODY ?php print( $p ); ? /BODY /HTML and call it whatever you want (eg. blah.php) 2. Next call the URL eg. http://server/blah.php?p=/ 2a. Same with http://server/blah.php?p=%5c The apache access_log shows the very same url one typed into netscape or explorer, so this looks fine to me. 3. Look at the output page. It'll show 2 (in words : two) backslashes Why is this ? How do i pass just one backslash ? Thanks a lot Cheers Guido Sorry, the web page reported a bug in /local/Web/sites/phpweb/bugs.php on line 419 and said : Sorry, mail not sent! and asked me to send this mail manually. +=+ | Guido Laubner Phone : +49 6102 7786 618 | | Morse Computers Fax : +49 6102 7786 666 | | Martin-Behaim-Strasse 19-21 Email : [EMAIL PROTECTED] | | 63263 Neu-Isenburg WEB : http://www.morse.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 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] Bug #11789: Apache can't start
I see this a lot when the LD_LIBRARY_PATH is not set correctly to load the Sybase libraries. Double check that type of stuff. [EMAIL PROTECTED] wrote: From: [EMAIL PROTECTED] Operating system: Linux 2.4.5 PHP version: 4.0.6 PHP Bug Type: Sybase-ct (ctlib) related Bug description: Apache can't start When I launch apache with sybase_ct, I've got following messages : DRK01:/soft/apache/bin# ./apachectl start ./apachectl: line 184: 15557 Segmentation fault $HTTPD ./apachectl start: httpd could not be started Sybase Version : 11.9.2 $SYBASE environment variable is correctly set There's nothing in apache's logs There's nothing in dmesg's output Do you have any idea ? Thanks for your answer @++ JC -- Edit Bug report at: http://bugs.php.net/?id=11789edit=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 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] switch, equality and preg_match
Here is your culprit:
RETVAL_LONG(matched);
The declaration in the docs says the function returns an int. However, the
text of the doc says that the function returns True or False.
Changing your call to:
$match = (bool)preg_false(); /* prints alpha always */
gives you the results you want.
Andrei, you are listed as the author on this file. What needs to change?
The return type? That would make the most sense to me.
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: chrism [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 30, 2001 7:02 PM
Subject: [PHP-DEV] switch, equality and preg_match
I encountered a problem where the result of a preg_match was FALSE.
This was fed into a switch statement - and I believe PHP executed the
the wrong case section.
I've tracked this down to preg_match not really returning FALSE
combined with SWITCH executing the first case statement always on either
a numeric 0 or BOOLEAN TRUE.
As a consequence of auto type conversion, you can't mix
STRING/NUMERIC/BOOLEAN within a switch. And with the preg_match issue,
you can't assume all input into your switch will be of one TYPE (BOOLEAN).
Aside from changing functions to return real booleans
1. Should type conversion be turned off inside switch() ?
2. If 0 == FALSE then why 0 == ANYTHING ?
Chris
?
/* auto type conversion is the root of my switch problem */
if (0 == ONE) echo one\n; /* TRUE */
if (1 == TWO) echo two\n; /* FALSE */
if (TRUE == THREE) echo three\n; /* TRUE */
if (FALSE == FOUR) echo four\n; /* FALSE */
if (TRUE == 0) echo hopefully not\n;
function preg_false() {
return(preg_match(/no/, dXiuehXX));
}
/* note the difference between FALSE and preg_false() */
// $match = TRUE; /* prints alpha always */
// $match = 0; /* prints alpha always */
// $match = FALSE; /* prints gamma section */
$match = preg_false(); /* prints alpha always */
if(is_bool($match) == TRUE) echo match is boolean\n;
switch($match) {
case ALPHA:
echo hmm.. alpha\n;
break;
case BETA:
echo hmm.. beta\n;
break;
case 0:
echo hmm.. gamma\n;
break;
case TRUE:
echo hmm.. TRUE\n;
break;
case FALSE:
echo hmm.. FALSE\n;
break;
}
?
--
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] switch, equality and preg_match
It is not the switch's fault. That is just the way variable's work in PHP.
If you need to know for sure about the type for this, you will need to do
this:
if($match===ALPHA) {
echo hmm.. alpha\n;
} elseif($match===BETA) {
echo hmm.. beta\n;
} elseif($match===0) {
echo hmm.. gamma\n;
} elseif($match===TRUE) {
echo hmm.. TRUE\n;
} elseif($match===FALSE) {
echo hmm.. FALSE\n;
}
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: chrism [EMAIL PROTECTED]
To: Brian Moon [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Sent: Sunday, July 01, 2001 11:02 AM
Subject: Re: [PHP-DEV] switch, equality and preg_match
I wasn't intending to throw blame at preg_match - My main concern is what
switch is doing - executing the first CASE when the input is either 0 or
TRUE.
I don't think switch should execute the first CASE whenever a numeric 0 is
fed into it.
Even TRUE gives me problems. And with 0 == FALSE, it all seems so messed
up.
Chris
Here is your culprit:
RETVAL_LONG(matched);
The declaration in the docs says the function returns an int. However,
the
text of the doc says that the function returns True or False.
Changing your call to:
$match = (bool)preg_false(); /* prints alpha always */
gives you the results you want.
Andrei, you are listed as the author on this file. What needs to
change?
The return type? That would make the most sense to me.
Brian Moon
--
dealnews.com, Inc.
Makers of dealnews, dealmac
http://dealnews.com/ | http://dealmac.com/
- Original Message -
From: chrism [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, June 30, 2001 7:02 PM
Subject: [PHP-DEV] switch, equality and preg_match
I encountered a problem where the result of a preg_match was FALSE.
This was fed into a switch statement - and I believe PHP executed the
the wrong case section.
I've tracked this down to preg_match not really returning FALSE
combined with SWITCH executing the first case statement always on
either
a numeric 0 or BOOLEAN TRUE.
As a consequence of auto type conversion, you can't mix
STRING/NUMERIC/BOOLEAN within a switch. And with the preg_match
issue,
you can't assume all input into your switch will be of one TYPE
(BOOLEAN).
Aside from changing functions to return real booleans
1. Should type conversion be turned off inside switch() ?
2. If 0 == FALSE then why 0 == ANYTHING ?
Chris
?
/* auto type conversion is the root of my switch problem */
if (0 == ONE) echo one\n; /* TRUE */
if (1 == TWO) echo two\n; /* FALSE */
if (TRUE == THREE) echo three\n; /* TRUE */
if (FALSE == FOUR) echo four\n; /* FALSE */
if (TRUE == 0) echo hopefully not\n;
function preg_false() {
return(preg_match(/no/, dXiuehXX));
}
/* note the difference between FALSE and preg_false() */
// $match = TRUE; /* prints alpha always */
// $match = 0; /* prints alpha always */
// $match = FALSE; /* prints gamma section */
$match = preg_false(); /* prints alpha always */
if(is_bool($match) == TRUE) echo match is boolean\n;
switch($match) {
case ALPHA:
echo hmm.. alpha\n;
break;
case BETA:
echo hmm.. beta\n;
break;
case 0:
echo hmm.. gamma\n;
break;
case TRUE:
echo hmm.. TRUE\n;
break;
case FALSE:
echo hmm.. FALSE\n;
break;
}
?
--
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] switch, equality and preg_match
If you look back to the original problem, switch was matching the 0 returned from preg_match to a string. However, if the return value is a boolean it would not match 0 to a string. However, I guess it would then match the true to a string. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Jon Parise [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 02, 2001 7:21 PM Subject: Re: [PHP-DEV] switch, equality and preg_match On Mon, Jul 02, 2001 at 05:01:43PM -0500, Brian Moon wrote: IMO, I like preg_match to return a bool and preg_match_all return a count. But that is me. It may be thought of as inconsistent to some. I just see the functions has having a different purpose. That would make sense. preg_match_all() would return 1 if only one match is found, so there's no need for preg_match() to return the number of matches. However, even if preg_match() were to return a one or zero, it would still function the same in boolean evaluations. That makes the whole thing simply a matter of correctness. Returning an 'int' would be more consistent but returning a boolean would be specific. -- Jon Parise ([EMAIL PROTECTED]) . Rochester Inst. of Technology http://www.csh.rit.edu/~jon/ : Computer Science House Member -- 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] php 4.1 or php 5.0
FWIW, I am +1 on PHP5. There are a lot of things in the language that need to be cleaned up. People here more familiar with other closed languages have gotten confused about things like case, underscores, haystack and needle, the way some array functions return an array and some modify the passed array. There is just a lot of stuff like that. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Phil Driscoll [EMAIL PROTECTED] To: php developers [EMAIL PROTECTED] Sent: Wednesday, July 04, 2001 6:21 AM Subject: [PHP-DEV] php 4.1 or php 5.0 When I posted the other day about tidying up the language, I was hoping to get some kind of feel as to whether the new Zend engine would cause us to move to PHP 4.1 or to 5.0, since a move to 4.1 would allow us less opportunity to have a clean up than 5.0. (But moving to 4.1 would give us more time to think things through and get things done) Does anyone have a view? -- Phil Driscoll -- 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] Possible feature for current version of PHP or PHP 4.1/5.0.
-1 ;) I think it could make thing much more difficult and confusing actually. I like to keep all my include files in a central place, and define a constant __IncPath, where __IncPath is something like: $Document_Root.libraries/ That way I always just: include(__IncPath.foo.php); include(__IncPath.bar.php); I guess this might not be the best in all situations, but I find it makes my code more portable. Define one constant, and all is well. Although for newer users, you guys are probably very right. Makes things much easier when learning. So I guess as long as it doesn't add to ambiguity (would there be include_relative() or include($FilePath[,boolean relative])... could be useful. -Brian Tanner -Original Message- From: Andi Gutmans [mailto:[EMAIL PROTECTED]] Sent: July 8, 2001 9:15 AM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- 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] Bug #11961: \r\n or \n
For the record, this is probably the EXACT same problem that was dismissed when I couldn't unserialize objects WRITTEN in CGI mode (non binary) with both Apache Module and CGI version. If I wrote the file with line breaks, with CGI -- the Apache module version of PHP would die on the unserialize, but a CGI version unserialize worked fine... I got told to always write in binary mode, and that the inconsistency when reading was not important. :( Win32, btw -Brian Tanner -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: July 8, 2001 3:46 PM To: [EMAIL PROTECTED] Subject: [PHP-DEV] Bug #11961: \r\n or \n From: [EMAIL PROTECTED] Operating system: Win98 SE PHP version: 4.0.6 PHP Bug Type: Unknown/Other Function Bug description: \r\n or \n I've submitted this bug some days before but I didn't get very kind reply. I decided to resubmit it. test.php: ?php $fp = fopen(test.txt, r); $str = ; while (!feof($fp)) $str .= fgets($fp, 64); fclose($fp); echo count(split(\n, $str)).br /.count(split(\r\n, $str)); ? And I've put 3 random lines in test.txt OK, my PHP is running as Apache module, so when I type localhost/test.php, I got the output 3br /1. Then, I run this script in CGI mode. This can be done simply by the command c:\php_path\php.exe test.php, and I will get the output 3br /3. OK, so PHP is not portable, even in the same platform but different PHP running mode. CGI PHP and module PHP interpret \r\n differently. -- Edit bug report at: http://bugs.php.net/?id=11961edit=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 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] php 4.1 or php 5.0
Well, I think to start with someone or multiple people need to take a look at the PHP code and figure out just exactly what we want to do to it. I can help out. I am pretty sure that Daniel Beckham will as well. As far as I know, we want to: 1. convert all function names to a standard naming convention. 2. convert all function params to a standard order. 3. get rid of old aliased functions. 4. Make sure all return codes are consistent. Some are 1 or 0 some are true or false. What else is there? I am sure there is more. Brian Moon -- dealnews.com, Inc. Makers of dealnews, dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Brian Moon [EMAIL PROTECTED]; php developers [EMAIL PROTECTED] Sent: Thursday, July 05, 2001 4:53 PM Subject: Re: [PHP-DEV] php 4.1 or php 5.0 I think both for Zend 2 and for the cleanup version of PHP (if they happen at the same time or not) it is important to come up with how to do the development. We can either work in a branch or create a new CVS tree. They both have their pros cons, but especially for the PHP CVS which is a moving target it's going to be hard to make a cleanup and keep the patches in sync with the being cleaned version. It'll be easier for Zend because it is very stable and doesn't change very much. Any ideas? Andi At 05:27 PM 7/4/2001 +0100, Phil Driscoll wrote: On Wednesday 04 July 2001 17:12, Brian Moon wrote: FWIW, I am +1 on PHP5. There are a lot of things in the language that need to be cleaned up. People here more familiar with other closed languages have gotten confused about things like case, underscores, haystack and needle, the way some array functions return an array and some modify the passed array. There is just a lot of stuff like that. I'm all for making the radical changes at 5.0, its just that it seems like Zeev is keen on a shortish timeframe for the new engine, whereas I suspect that tidying up the language will take quite a bit longer. FWIW my vote is for us to make a concerted start on tidying the language with a realistic time frame of guess 1 year. If the new Zend engine is going to be ready much sooner than that, and it will only affect OO stuff and the business of accessing individual characters in strings, then that change should be to 4.1. If the engine is going to take a year, then we'll have a big pile of stuff to launch as 5.0 Cheers -- Phil Driscoll -- 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] Possible feature for current version of PHP or PHP 4.1/5.0.
Just want to pipe up and say I'm worried about a potential performance hit here. I'm building an enterprise web app that includes over 30 files on every request. Will changing the directory for the include file, and changing it back after create a significant performance hit? (I would think so). Just to point out -- things might get a little more confusing here... because if people get to pretend that the file they are including is being executed in the directory where it is stored, they may have problems adjusting to the idea of making links and images (in HTML) relative to the script that called their file, and they might have to end up re-implementing existing workarounds anyway. Just a thought. -Brian Tanner -Original Message- From: Zeev Suraski [mailto:[EMAIL PROTECTED]] Sent: July 9, 2001 5:48 AM To: Andi Gutmans Cc: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Yeah, this has been requested several times. I think that changing the cwd to the directory of an included file makes good sense. It is, indeed, downwards incompatible and may break existing applications. We have 4 options: 1. Do nothing 2. Make include() and friends change directory to the directory of the file they include. This makes the most sense, but may break existing apps. 3. #2, only make it optional 4. Add the directory of the included file to the include_path when the included file is being executed. It can get a bit nasty with nested includes, even though I think it should work. It's also a bit tricky to implement, as the engine doesn't know about include_path (at least right now). I'm leaning towards #3, even though I don't like the yet-another-runtime-option. It may be justified if we say we're phasing out the old functionality in PHP 5.0. Zeev At 18:14 8/7/2001, Andi Gutmans wrote: Hey, I think one thing that bothers PHP developers is when they do: include ../foo.inc; and in foo.inc they do: include bar.inc; That bar.inc is not searched for in foo.inc's current directory automatically. As we pretty much always have the expanded filename of the current executing script I thought it would be nice to add that if bar.inc is not found in the include_path to take the full path of foo.inc (i.e. /path/to/foo_inc/foo.inc) and try opening /path/to/foo_inc/bar.inc. What do you guys think? Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/ -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP 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] Possible feature for current version of PHP or PHP 4.1/5.0.
That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. I still like the idea. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 2:46 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 12:03 PM 7/9/2001 -0700, Vlad Krupin wrote: Is it better to break things once or twice? Ok, not completely break, but now I have some code working with PHP4, later I will have some code that will work with PHP4.1, and finally I will re-write it to work with the latest-and-best PHP5. It is more like saying Here is my script, you can run it with this version of PHP *only*, if you want to run it with another one, I have another version of the script for you. On a sidenote, could we just create a different include (e.g. include_relative, like there is include_once) that will incorporate the desired functionality, and not touch include() at all? Or am I suggestiong yet another bloat? Or am I missing the point here? Or did we all agree that the current include() operation is so buggy that it warrants a change breaking compatibility and soon? I do not think that going to 5.0 warrants letting the hell break loose and break everything, I would still like to be able to run at least some of my php4 scripts once php5 comes out, and I have lots of very elaborate solutions to work around the current problems with include(). Such a change will not break my code, but I can easily see what code that *will* break, and I think there will be a lot of it. What do you think about the solution I suggested? If the file can't be found to then look in the current scripts directory. It solves the problems and doesn't break BC. Andi -- 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] Possible feature for current version of PHP or PHP 4.1/5.0.
It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 3:44 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- 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] Possible feature for current version of PHP or PHP 4.1/5.0.
I am -1 on yet another new function. Because, if you create a new include_local or whatever, people are gonna want include_local_once and so on and so forth. I am alos -1 on making it an option. Do you know what a headache it is to try and write and app like Phorum and mess with a million different server setups. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Vlad Krupin [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED] Cc: Zeev Suraski [EMAIL PROTECTED]; Andi Gutmans [EMAIL PROTECTED]; Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 4:49 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. Andi, I definitely do like your approachl. I do not like that different versions of PHP will behave differently. That's what I was talking about. And it is a situation similar to what Brian described that prompted me to write to the list and see if we can come up with one solution which will stay, whether in version 4.1, or 5, or 5.5. I know that I have myriads of includes with a pretty extensive directory structure, and some scripts are having the same names. I have run into problems including the wrong file by mistake. I do not want to make that mistake easier to make. That's why I asked if it makes sense to leave include() as it is, and create another function/construct that will behave as described, and asked if that would be too much of a bloat. I can not judge that myself, for I do not know enough. If it is, discard that idea, but could we please implement something that will not change between verision 4.1 and 5 and hopefully later? Sorry, couldn't reply earlier - I was following up on the heated discussions here... Vlad Brian Moon wrote: It is not so much BC. It is more like unexpected new behavior. As of now, a bad programmer might have this: /www/site.com/include/file.php /www/site.com/include/config.php /www/site.com/index.php /www/site.com/config.php if index.php includes include/file.php which includes config.php, the config in the main dir gets included. Now, in the future, if the main config.php is not there, the one in the include file gets included. Now, granted, this may not be the best case, but it would cause some confusion if someone was not well aware of this change. I am still +1, but think it should be at least a 4.1 thing. Brian Moon -- dealnews.com, Inc. Makers of dealnews dealmac http://dealnews.com/ | http://dealmac.com/ - Original Message - From: Andi Gutmans [EMAIL PROTECTED] To: Brian Moon [EMAIL PROTECTED]; Vlad Krupin [EMAIL PROTECTED]; Zeev Suraski [EMAIL PROTECTED] Cc: Andrei Zmievski [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, July 09, 2001 3:44 PM Subject: Re: [PHP-DEV] Possible feature for current version of PHP or PHP 4.1/5.0. At 03:43 PM 7/9/2001 -0500, Brian Moon wrote: That is not completely true. If there is a file in the included scripts dir that has the same name as one in the including scripts dir, that would cause some unexpected problems. Well as I would only resort to looking according to the current file if all other things fail (cwd and include_path) I can't see how it would break BC. I still like the idea. Thanks :) Andi -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DEV] RE: Bug #11990 Updated: defined constants getting corrupted
Title: RE: Bug #11990 Updated: defined constants getting corrupted
The bug update page isn't accepting my changes; keeps telling me:
The password you supplied was incorrect.
Something went wrong updating the database.
I've got the right password.
Since I can't submit my updates via the form, here goes:
Well, I haven't succeeded yet in reproducing the corrupted define, but I have managed to repeatably kill PHP with a 22 line script generated by the following shell script:
echo ?php
define=this is a very long define, indeed! asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf asdf
count=0
while [ $count -lt 10 ]; do
echo define(\DEF_${count}\, \$define\);
echo if(DEF_${count} != \$define\) { print(\bad\); }
count=$(($count + 1))
done
echo ?
I redirected that to a file and ran php through gdb. here's the resulting stack trace:
(gdb) run
Starting program: /home/blalor/redhat/BUILD/php-4.0.6/php_standalone ../test.php
Program received signal SIGSEGV, Segmentation fault.
0x812770b in execute (op_array=0x81dc6c4) at ./zend_execute.c:1639
(gdb) bt
#0 0x812770b in execute (op_array=0x81dc6c4) at ./zend_execute.c:1639
#1 0x80ee58b in zend_execute_scripts (type=8, file_count=3) at zend.c:752
#2 0x80635a1 in php_execute_script (primary_file=0xb554) at main.c:1206
#3 0x80615c9 in main (argc=2, argv=0xb5b4) at cgi_main.c:718
[snip]
(gdb) print valptr-value
$1 = {lval = 136194132, dval = 1.067726779661273e-313, str = {
val = 0x81e2854 DEF_0, len = 5}, ht = 0x81e2854, obj = {ce = 0x81e2854,
properties = 0x5}}
Note that it appears that PHP is trying to access the data for DEF_0 at zend_execute.c:1639.
Note that I did this with php 4.0.6, not 4.0.5. *Some* kind of problem still exists there...
--
Brian Lalor
[EMAIL PROTECTED]
(v) 480-333-3196
(f) 480-760-9298
-Original Message-
From: Bug Database [mailto:[EMAIL PROTECTED]]
Sent: Monday, July 09, 2001 4:52 PM
To: [EMAIL PROTECTED]
Subject: Bug #11990 Updated: defined constants getting corrupted
ID: 11990
Updated by: sniper
Reported By: [EMAIL PROTECTED]
Old Status: Open
Status: Feedback
Old Bug Type: *Programming Data Structures
Bug Type: Scripting Engine problem
Operating System: RedHat Linux 6.2
PHP Version: 4.0.5
New Comment:
Would it be possible to test this same script with PHP 4.0.6?
I don't remember anyone reporting anything like this before
and I have never experienced anything like this myself.
Also, if you could create a short bug complete script
which could be used to reproduce this, it would
be a lot easier to debug this issue.
And what was your configure line used to configure PHP ?
--Jani
Previous Comments:
--
--
[2001-07-09 18:13:11] [EMAIL PROTECTED]
We're seeing severe data corruption problems with defines.
For example, the following snippet is from a PHP script that
uses defined constants to build up a filename. The resulting
variable contains junk data.
no exist :ieldp/cðÃÄclasssupport/getproductlist.php
Warning: Failed opening 'ield' for inclusion
(include_path='.:/u/php:/u/htdocs') in
/u/php/corelib/sp/procedure.php on line 57
no exist :ieldp/cðÃÄclasssupport/getfullproduct.php
Warning: Failed opening 'ield' for inclusion
(include_path='.:/u/php:/u/htdocs') in
/u/php/corelib/sp/procedure.php on line 57
PHP doesn't seem to crash.
--
--
ATTENTION! Do NOT reply to this email!
To reply, use the web interface found at
http://bugs.php.net/?id=11990=1
RE: [PHP-DEV] Bug #11990 Updated: defined constants getting corrupted
Title: RE: [PHP-DEV] Bug #11990 Updated: defined constants getting corrupted I'm still working trying to come up with a way to make this bug reproducible on command. So far, it fails sometimes 10 times out of 10, and then maybe 1 out of 1000. This is *very* frustrating. Is there any way I can get some statistics on the state of the interpreter at some point? We're require_once()'ing and include_once()'ing a buttload of files and I'd love to get some idea of the memory used during a particular request, including number of lines processed, defines defined, objects defined, etc. Programmatic access to the context would be cool... :-) Has anyone given any thought to this problem of corruption of defines? Are there any other instances of data corruption that we could maybe draw lines between? Thanks, B -- Brian Lalor [EMAIL PROTECTED] (v) 480-333-3196 (f) 480-760-9298
[PHP-DEV] Help with corrupted defines [bug 11990]
Hey all. I haven't seen any further traffic on this issue (aside from myself, that is :-) ). At one point yesterday, we were seeing an approximate 5% failure rate; 5% of pages served had errors due to garbage for a define. I spent some time poking about the PHP and Zend source yesterday and was able to call a php_printf() whenever a constant was defined as a string. Yeah, big deal, I know, but I'm thinking of using that method to verify that what's going into the hash table is what I've put in the script. Is there a way to dump an arbitrary Zend hash table from a PHP script? I've tried stepping through the entire execution of a PHP script with GDB. Not a pretty thing, as I'm sure most of you know. I'm not able to determine even where the line define(FOO, bar); is read from the file. Somewhere, the data for the defined constant is getting corrupted. I don't know enough about the Zend internals to checkpoint the data at various points to see if it matches what I expect. The other problem is that I can't reliably reproduce the error with a compact script or series of scripts, which is a major bummer for all involved. Would someone with the knowledge of the internals of PHP and Zend be willing to spend some time one-on-one with me any my team trying to get a solution to this? Thanks, B -- Brian Lalor [EMAIL PROTECTED] (v) 480-333-3196 (f) 480-760-9298 -- 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]
