#21242 [Opn->Bgs]: cannot locate Kerberos libraries (--with-imap, --wipe-kerberos)
ID: 21242 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Red Hat 7.1 PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php As [EMAIL PROTECTED] wrote you need a symlink which should be done by a normal make install or rpm call. Previous Comments: [2002-12-28 08:13:38] [EMAIL PROTECTED] try creating a softlink to the files not found. eg: libdyn.so to libdyn.so.1.0. This worked several times for me. [2002-12-28 07:27:21] [EMAIL PROTECTED] . [2002-12-28 07:17:23] [EMAIL PROTECTED] ./configure --with-apache=../apache_1.3.27 --with-mysql=/usr --with-gettext --enable-track-vars --with-imap=/usr --with-kerberos --with-imap-ssl --enable-trans-id Results in configure error : configure: error: Kerberos libraries not found. Check the path given to --with-kerberos (if no path is given, searches in /usr/kerberos, /usr/local and /usr ) - Kerberos libraries are properly installed as usual in /usr/kerberos/lib : [root@pajonk lib]# ls -la /usr/kerberos/lib total 1096 drwxr-xr-x2 root root 4096 Dec 28 13:59 . drwxr-xr-x7 root root 4096 Mar 30 2001 .. lrwxrwxrwx1 root root 17 Feb 10 2002 libcom_err.so.3 -> libcom_err.so.3.0 -rwxr-xr-x1 root root 5881 Mar 30 2001 libcom_err.so.3.0 lrwxrwxrwx1 root root 16 Feb 10 2002 libdes425.so.3 -> libdes425.so.3.0 -rwxr-xr-x1 root root14459 Mar 30 2001 libdes425.so.3.0 lrwxrwxrwx1 root root 13 Feb 10 2002 libdyn.so.1 -> libdyn.so.1.0 -rwxr-xr-x1 root root 9598 Mar 30 2001 libdyn.so.1.0 lrwxrwxrwx1 root root 21 Feb 10 2002 libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2 -rwxr-xr-x1 root root86532 Mar 30 2001 libgssapi_krb5.so.2.2 lrwxrwxrwx1 root root 16 Feb 10 2002 libgssrpc.so.3 -> libgssrpc.so.3.0 -rwxr-xr-x1 root root89826 Mar 30 2001 libgssrpc.so.3.0 lrwxrwxrwx1 root root 18 Feb 10 2002 libk5crypto.so.3 -> libk5crypto.so.3.0 -rwxr-xr-x1 root root73926 Mar 30 2001 libk5crypto.so.3.0 lrwxrwxrwx1 root root 19 Feb 10 2002 libkadm5clnt.so.4 -> libkadm5clnt.so.4.0 -rwxr-xr-x1 root root75536 Mar 30 2001 libkadm5clnt.so.4.0 lrwxrwxrwx1 root root 18 Feb 10 2002 libkadm5srv.so.4 -> libkadm5srv.so.4.0 -rwxr-xr-x1 root root 105053 Mar 30 2001 libkadm5srv.so.4.0 lrwxrwxrwx1 root root 14 Feb 10 2002 libkdb5.so.3 -> libkdb5.so.3.0 -rwxr-xr-x1 root root88685 Mar 30 2001 libkdb5.so.3.0 lrwxrwxrwx1 root root 14 Feb 10 2002 libkrb4.so.2 -> libkrb4.so.2.0 -rwxr-xr-x1 root root75685 Mar 30 2001 libkrb4.so.2.0 lrwxrwxrwx1 root root 14 Feb 10 2002 libkrb5.so.3 -> libkrb5.so.3.0 -rwxr-xr-x1 root root 414190 Mar 30 2001 libkrb5.so.3.0 lrwxrwxrwx1 root root 13 Feb 10 2002 libpty.so.1 -> libpty.so.1.1 -rwxr-xr-x1 root root12995 Mar 30 2001 libpty.so.1.1 -- Edit this bug report at http://bugs.php.net/?id=21242&edit=1
#21579 [Opn]: freetype wont compile into php 4.3
ID: 21579 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: linux PHP Version: 4.3.0 New Comment: Please show the line 41 from your file: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h Previous Comments: [2003-01-11 05:33:42] [EMAIL PROTECTED] In file included from /usr/src/sources/php/php-4.3.0/ext/gd/libgd/gdft.c:49: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22: ft2build.h: N o such file or directory here is the initial error thens spits out heaps of other gd errors which is too much to paste in, i cannot compile freetype in, but when i take it out php 4.3 compiled fine -- Edit this bug report at http://bugs.php.net/?id=21579&edit=1
#21298 [Opn]: jpeg dups
ID: 21298 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Failure Operating System: FreeBSD 4.7 PHP Version: 4.3.0 New Comment: Please try to reinstall your jpeg library and test again. From the output you presented it seems you have a bad libjpeg. And please use a packege. However: If you configure without --with-jpeg-dir you should not be able to work with jpeg files. Could you please verify this? Because if you remove the mentioned configure line and still have the jpeg functions in your php build then the jpeg functionality comes from another library and that is the error then. Previous Comments: [2002-12-30 16:43:28] [EMAIL PROTECTED] Configure: ./configure --enable-mbstring --with-mysql=/usr/local --with-xml --with-gd --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --enable-bcmath --with-imap --enable-ftp --with-jpeg-dir --with-png-dir --with-ttf --enable-sockets --with-zlib --with-openssl --with-pdflib --with-curl --with-mcrypt --with-freetype --with-freetype-dir=/usr/local/include/freetype2 --with-tsrm-pth Make works fine until it hits this: /bin/sh libtool --silent --mode=link gcc -g -O2 -prefer-pic -rpath /usr/home/install/packages/php-4.3.0/libs -avoid-version -module -L/usr/local/lib -L/usr/local/lib/mysql -L/lib -R /usr/local/lib -R /usr/local/lib/mysql -R /lib ext/zlib/zlib.lo ext/zlib/zlib_fopen_wrapper.lo ext/bcmath/bcmath.lo ext/bcmath/number.lo ext/bcmath/libbcmath/src/add.lo ext/bcmath/libbcmath/src/div.lo ext/bcmath/libbcmath/src/init.lo ext/bcmath/libbcmath/src/neg.lo ext/bcmath/libbcmath/src/outofmem.lo ext/bcmath/libbcmath/src/raisemod.lo ext/bcmath/libbcmath/src/rt.lo ext/bcmath/libbcmath/src/sub.lo ext/bcmath/libbcmath/src/compare.lo ext/bcmath/libbcmath/src/divmod.lo ext/bcmath/libbcmath/src/int2num.lo ext/bcmath/libbcmath/src/num2long.lo ext/bcmath/libbcmath/src/output.lo ext/bcmath/libbcmath/src/recmul.lo ext/bcmath/libbcmath/src/sqrt.lo ext/bcmath/libbcmath/src/zero.lo ext/bcmath/libbcmath/src/debug.lo ext/bcmath/libbcmath/src/doaddsub.lo ext/bcmath/libbcmath/src/nearzero.lo ext/bcmath/libbcmath/src/num2str.lo ext/bcmath/libbcmath/src/raise.lo ext/bcmath/libbcmath/src/rmzero.lo ext/bcmath/libbcmath/src/str2num.lo ext/ctype/ctype.lo ext/curl/curl.lo ext/curl/curlstreams.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gd/gd.lo ext/gd/gdttf.lo ext/gd/libgd/gd.lo ext/gd/libgd/gd_gd.lo ext/gd/libgd/gd_gd2.lo ext/gd/libgd/gd_io.lo ext/gd/libgd/gd_io_dp.lo ext/gd/libgd/gd_io_file.lo ext/gd/libgd/gd_ss.lo ext/gd/libgd/gd_io_ss.lo ext/gd/libgd/gd_png.lo ext/gd/libgd/gd_jpeg.lo ext/gd/libgd/gdxpm.lo ext/gd/libgd/gdfontt.lo ext/gd/libgd/gdfonts.lo ext/gd/libgd/gdfontmb.lo ext/gd/libgd/gdfontl.lo ext/gd/libgd/gdfontg.lo ext/gd/libgd/gdtables.lo ext/gd/libgd/gdft.lo ext/gd/libgd/gdcache.lo ext/gd/libgd/gdkanji.lo ext/gd/libgd/wbmp.lo ext/gd/libgd/gd_wbmp.lo ext/gd/libgd/gdhelpers.lo ext/gd/libgd/gd_topal.lo ext/gd/libgd/gd_gif_in.lo ext/imap/php_imap.lo ext/mbstring/mbfilter_ja.lo ext/mbstring/mbfilter_cn.lo ext/mbstring/mbfilter_tw.lo ext/mbstring/mbfilter_kr.lo ext/mbstring/mbfilter_ru.lo ext/mbstring/mbfilter.lo ext/mbstring/mbstring.lo ext/mbstring/mbregex.lo ext/mbstring/php_mbregex.lo ext/mbstring/html_entities.lo ext/mbstring/php_unicode.lo ext/mcrypt/mcrypt.lo ext/mysql/php_mysql.lo ext/openssl/openssl.lo ext/overload/overload.lo ext/pcre/pcrelib/maketables.lo ext/pcre/pcrelib/get.lo ext/pcre/pcrelib/study.lo ext/pcre/pcrelib/pcre.lo ext/pcre/php_pcre.lo ext/pdf/pdf.lo ext/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.lo ext/sockets/sockets.lo ext/standard/array.lo ext/standard/base64.lo ext/standard/basic_functions.lo ext/standard/browscap.lo ext/standard/crc32.lo ext/standard/crypt.lo ext/standard/cyr_convert.lo ext/standard/datetime.lo ext/standard/dir.lo ext/standard/dl.lo ext/standard/dns.lo ext/standard/exec.lo ext/standard/file.lo ext/standard/filestat.lo ext/standard/flock_compat.lo ext/standard/formatted_print.lo ext/standard/fsock.lo ext/standard/head.lo ext/standard/html.lo ext/standard/image.lo ext/standard/info.lo ext/standard/iptc.lo ext/standard/lcg.lo ext/standard/link.lo ext/standard/mail.lo ext/standard/math.lo ext/standard/md5.lo ext/standard/metaphone.lo ext/standard/microtime.lo ext/standard/pack.lo ext/standard/pageinfo.lo ext/standard/parsedate.lo ext/standard/quot_print.lo ext/standard/rand.lo ext/standard/reg.lo ext/standard/soundex.lo ext/standard/string.lo ext/standard/scanf.lo ext/standard/syslog.lo ext/standard/type.lo ext/standard/uniqid.lo ext/standard/url.lo ext/standard/url_scanner.lo ext/standard/var.lo ext/standard/versioning.lo ext/standard/assert.lo ext/standard/strnatcmp.lo ext/standard/levenshtein.lo ext/standard/incomplete_class.lo ext/standard/url_scanner_ex.lo ext/standard/ftp_fopen_wrap
#21054 [Sus]: 'ob_gzhandler' cannot be used twice???
ID: 21054 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Suspended Bug Type: Output Control Operating System: Redhat 7.2 PHP Version: 4.3.0RC3 New Comment: To both of you: please execute the following script: Previous Comments: [2002-12-18 04:45:40] [EMAIL PROTECTED] The same message appears if I place in the begining of the any php script. (W2kPro SP2, PHP4.3.0RC2, Apache 2.0.43) [2002-12-16 15:56:49] [EMAIL PROTECTED] It's a pretty useless bugreport like this. Suspended until you can profile some real useful information to reproduce this problem. [2002-12-16 15:52:45] [EMAIL PROTECTED] I don't know if it's a particular script to cause the warning, the log don't tell me anything Other informations: Apache: 2.0.43 PHP: 4.3.0RC3 Zend Optimizer: 2.0.3 Configure: './configure' '--enable-track-vars' '--prefix=/usr' '--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--datadir=/home/httpd' '--sysconfdir=/etc/httpd/conf' '--localstatedir=/var' '--libdir=/usr/lib/apache' '--includedir=/usr/include/apache' '--mandir=/usr/man' '--with-mysql=/usr' '--with-config-file-path=/usr/local/Zend/etc' '--enable-memory-limit' '--with-apxs2' '--with-zlib' '--disable-session' [2002-12-16 15:45:29] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2002-12-16 15:44:55] [EMAIL PROTECTED] Sometimes (it seems random) I find in the error_log this fatal error: PHP Warning: (null)() [ref.outcontr ol]: output handler 'ob_gzhandler' cannot be used twice in Unknown on line 0 Repeated 4 times. I haven't activated gz_handler in php.ini and it's not activated in virtaulhosts, I don't set in scripts. I'm not using it, why it tells me that I use it TWICE? Andrea Busia -- Edit this bug report at http://bugs.php.net/?id=21054&edit=1
#14383 [Asn->NoF]: using postgres with DBA causes DBA not to be able to find any keys.
ID: 14383
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Assigned
+Status: No Feedback
Bug Type: DBM/DBA related
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.2.0-dev
Assigned To: yohgaki
New Comment:
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
Previous Comments:
[2002-11-06 06:00:30] [EMAIL PROTECTED]
For me it works, i think.
Could you please try latest cvs version copy new test below to
ext/pgsql/tests/30_bug14383.phpt and run the following test script
using:
php run-tests.php ext/pgsql
===ext/pgsql/tests/30_bug14383.phpt
--TEST--
Bug 14383
--SKIPIF--
--FILE--
--EXPECTF--
database handler: %s
3NYNYY
Content String 2
Content 2 replaced
Read during write permitted
Content 2 replaced 2nd time
The 6th value
array(3) {
["key number 6"]=>
string(13) "The 6th value"
["key2"]=>
string(27) "Content 2 replaced 2nd time"
["key5"]=>
string(23) "The last content string"
}
===EOF ext/pgsql/tests/30_bug14383.phpt
[2001-12-13 04:40:28] [EMAIL PROTECTED]
Thanks a lot.
I'll take a look at source. It could be hard to figure out
what's wrong. Please be patient.
Since I don't use FreeBSD, I might ask something later.
[2001-12-13 03:29:55] [EMAIL PROTECTED]
Hi,
Yes the latest snapshop has the same error.
Again, if I comment out the pg_connect call it
works just fine.
[2001-12-13 03:17:09] [EMAIL PROTECTED]
Ok,
I just tested it with 4.1.0 and I still get the exact same
error, no change.
I'll try to get a snap if I can and try it.
[2001-12-13 02:51:58] [EMAIL PROTECTED]
No, I've not tried it with 4.1.0.
I'm trying to get it or one of the snaps right now and
the servers are slllo...:(
Will report back when I get it tested.
--
GB
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14383
--
Edit this bug report at http://bugs.php.net/?id=14383&edit=1
#21054 [Sus->Csd]: 'ob_gzhandler' cannot be used twice???
ID: 21054
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Suspended
+Status: Closed
Bug Type: Output Control
Operating System: Redhat 7.2
PHP Version: 4.3.0RC3
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
So than it is fixed in CVS -> closed
Previous Comments:
[2003-01-11 14:58:35] [EMAIL PROTECTED]
Now I have 4.4.0-dev (200301041230) and the problem seems to be
corrected, I don't see anymore this warning in logs.
BTW this is the output:
array(4) { ["output_buffering"]=> string(1) "1" ["output_handler"]=>
bool(false) ["zlib.output_compression"]=> string(0) ""
["zlib.output_handler"]=> string(0) "" }
[2003-01-11 11:41:09] [EMAIL PROTECTED]
To both of you: please execute the following script:
[2002-12-18 04:45:40] [EMAIL PROTECTED]
The same message appears if I place
in the begining of the any php script.
(W2kPro SP2, PHP4.3.0RC2, Apache 2.0.43)
[2002-12-16 15:56:49] [EMAIL PROTECTED]
It's a pretty useless bugreport like this. Suspended until you can
profile some real useful information to reproduce this problem.
[2002-12-16 15:52:45] [EMAIL PROTECTED]
I don't know if it's a particular script to cause the warning, the log
don't tell me anything
Other informations:
Apache: 2.0.43
PHP: 4.3.0RC3
Zend Optimizer: 2.0.3
Configure:
'./configure' '--enable-track-vars' '--prefix=/usr'
'--exec-prefix=/usr' '--libexecdir=/usr/lib/apache' '--bindir=/usr/bin'
'--sbindir=/usr/sbin' '--datadir=/home/httpd'
'--sysconfdir=/etc/httpd/conf' '--localstatedir=/var'
'--libdir=/usr/lib/apache' '--includedir=/usr/include/apache'
'--mandir=/usr/man' '--with-mysql=/usr'
'--with-config-file-path=/usr/local/Zend/etc' '--enable-memory-limit'
'--with-apxs2' '--with-zlib' '--disable-session'
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21054
--
Edit this bug report at http://bugs.php.net/?id=21054&edit=1
#21579 [Fbk->Bgs]: freetype wont compile into php 4.3
ID: 21579 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: GD related Operating System: linux PHP Version: 4.3.0 New Comment: When you installed the library correctly and experience the problem again feel free to open the bug. For now we suppose the erroneous library causing the problem. Previous Comments: [2003-01-11 12:32:56] [EMAIL PROTECTED] You really should compile/install that ft2 lib correctly first.. [2003-01-11 12:25:36] [EMAIL PROTECTED] #include #include FT_CONFIG_CONFIG_H #include FT_ERRORS_H #include FT_TYPES_H i had found ft2build.h in /usr/local/etc/freetype/include so i made a symlink to it but even that didnt work ? can i not reply via email what is [EMAIL PROTECTED] ? [2003-01-11 12:14:31] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. [2003-01-11 11:33:03] [EMAIL PROTECTED] Please show the line 41 from your file: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h [2003-01-11 05:33:42] [EMAIL PROTECTED] In file included from /usr/src/sources/php/php-4.3.0/ext/gd/libgd/gdft.c:49: /usr/local/etc/freetype/include/freetype2/freetype/freetype.h:41:22: ft2build.h: N o such file or directory here is the initial error thens spits out heaps of other gd errors which is too much to paste in, i cannot compile freetype in, but when i take it out php 4.3 compiled fine -- Edit this bug report at http://bugs.php.net/?id=21579&edit=1
#21479 [Opn]: function crashes when used with a URL
ID: 21479 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GetImageSize related Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: I cannot reproduce this with 4.4: [c:\dokumente und einstellungen\marcus]c:\Programme\PHP4\php.exe http://economads.com/libaware/_font/title/image.gif')); ?> ^Z Content-type: text/html X-Powered-By: PHP/4.4.0-dev Warning: getimagesize(http://economads.com/libaware/_font/title/image.gif) [function.getimagesize]: failed to create stream: HTTP request failed! HTTP/1.1 404 Object Not Found in C:\Dokumente und Einstellungen\marcus\- on line 2 [c:\dokumente und einstellungen\marcus]php -v PHP 4.4.0-dev (cgi-fcgi), Copyright (c) 1997-2003 The PHP Group Zend Engine v1.4.0, Copyright (c) 1998-2003 Zend Technologies Previous Comments: [2003-01-22 23:30:23] [EMAIL PROTECTED] I can not reproduce this within Linux, I guess this is yet another windows only bug.. [2003-01-22 22:58:12] [EMAIL PROTECTED] HOLD IT - I just found out exactly how to reproduce it. please read carefully. the code is: http://domain/dir1/dir2/dir3/image.gif'); ?> make sure the path: http://domain/dir1/dir2/dir3/ containts THREE directories after the domain (i.e. 6 forward-slashes total), and that the PATH physically EXISTS. AND make sure that the file (in code 'image.gif') DOES NOT exist. You can test against: http://economads.com/libaware/_font/title/image.gif This crashes on my server - running PHP 4.3.0 as CGI with IIS Win2000. Hope this helps. [2003-01-20 17:13:18] [EMAIL PROTECTED] Ahha..so you had propably the old php4ts.dll there, from previous version... [2003-01-20 17:08:48] [EMAIL PROTECTED] crashes means gpf .. a windows application error, and then error cgi returned wrong headers, etc. anyway, i have installed 4.3.0 once again (removed it after discovering crash), and not like last time - rebooted the machine - and it seems to fix the problem. [2003-01-20 14:41:41] [EMAIL PROTECTED] What do you mean with 'crashes' ? And does getimagesize() work for local files? or something like that..? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21479 -- Edit this bug report at http://bugs.php.net/?id=21479&edit=1
#21751 [Opn]: make test miserably fails
ID: 21751 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Output Control Operating System: SunOS PHP Version: 4.3.0 -Assigned To: +Assigned To: helly New Comment: Symptoms are defeated the real problem remains: "failed to delete buffer default output handler" In other words with cvs versions you can do now: php -d output_buffering=4096 run-tests.php Interesting thing is that it worked in 4.2 Previous Comments: [2003-01-19 10:45:00] [EMAIL PROTECTED] I didn't have "." in my include_path and I had output_buffering = 4096. Reasonable? So the while(ob_get_level()) ob_end_clean(); algorithm in run-tsts.php runs forever: level won't go below 1. An implicit ob_start implied by buffering? then the feature is fine and the test script broken. I commented that out but forgot to fix the .ini. Result: many test failures and the result posted to your site w/o letting me say a word. (Quite nasty, isn't it?) In facts: 1) "-n" or "-c ." options to command line don't do it, 2) flush() doesn't work as expected when bufferning, 3) reading stdin doesn't work at all! You need to fix (1) and ship the product with a working php.ini for the tests. Please fix the tests by setting something like "do you want to run the tests interactively?" and if you get no answer assume NO_INTERACTION=1! TIA Ale -- Edit this bug report at http://bugs.php.net/?id=21751&edit=1
#21743 [Opn]: Driver initialization failed for handler: db3 (and db2)
ID: 21743
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DBM/DBA related
Operating System: RedHat Linux 7.2
PHP Version: 4.3.0
-Assigned To:
+Assigned To: helly
New Comment:
First please try this (note the "-" after "c":
Then please try if you can create and open an new file:
after that: From your configure script:
--enable-dba=shared \
--with-gdbm \
--with-db3 \
--with-cdb=/usr \
--with-flatfile \
This means you cannot have db2.
However you found a problem here: --with-cdb always loads
the internal cdb support (so thanks here i've fixed
this part already in cvs).
Could you try (with only db3, cdb and flatfile)
--enable-dba=shared \
--with-db3 \
--with-cdb \
--with-flatfile \
Maybe you could also try db4 or db4.1 versions buy
--with-db3=/path/to/db4 for PHP 4.3 or --with-db4 for cvs versions.
If this solves the problem then it is gdbm
The zero length test file is created by the locking
mechanism and after that calls to library should do
the rest but that failed...
Previous Comments:
[2003-01-19 02:32:50] [EMAIL PROTECTED]
dba_open with dba handler db2 or db3 always failed,
however it worked with flatfile, gdbm or cdb_make. I'm
using dba not statically linked but loaded using dl(). I'm
sure it worked before with php 4.2.1 and db2.
phpinfo for dba:
DBA support enabled
Supported handlers gdbm cdb cdb_make db3 flatfile
Code example:
The output is:
$ php db.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
Warning: dba_open(test,c) [function.dba-open]:
Driver initialization failed for handler: db3 in
/home/u1094/db.php on line 3
After it is executed, a zero sized file 'test' appears.
ldd information:
$ ldd /usr/local/lib/php/modules/dba.so
libz.so.1 => /usr/lib/libz.so.1 (0x4001a000)
libdb-3.2.so => /lib/libdb-3.2.so (0x40028000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x400cf000)
libc.so.6 => /lib/libc.so.6 (0x400d6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x8000)
$ ldd /usr/local/bin/php
libz.so.1 => /usr/lib/libz.so.1 (0x40027000)
libgdbm.so.2 => /usr/lib/libgdbm.so.2 (0x40035000)
libm.so.6 => /lib/libm.so.6 (0x4003c000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x4005e000)
libpam.so.0 => /lib/libpam.so.0 (0x4008b000)
libssl.so.2 => /lib/libssl.so.2 (0x40094000)
libcrypto.so.2 => /lib/libcrypto.so.2 (0x400c1000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40184000)
libdl.so.2 => /lib/libdl.so.2 (0x40196000)
libnsl.so.1 => /lib/libnsl.so.1 (0x4019a000)
libc.so.6 => /lib/libc.so.6 (0x401b1000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2
(0x4000)
Strace output:
(this is for db3, I can give you the output for db2 if
needed after I finished recompiling. you can't have both
db2 and db3 compiled in right?)
9504 execve("/usr/bin/php", ["php", "db.php"], [/* 31
vars */]) = 0
9504 uname({sys="Linux",
node="geodude.labs.indoglobal.com", ...}) = 0
9504 brk(0)= 0x819d96c
9504 old_mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40016000
9504 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No
such file or directory)
9504 open("/etc/ld.so.cache", O_RDONLY) = 3
9504 fstat64(3, {st_mode=S_IFREG|0644, st_size=64982,
...}) = 0
9504 old_mmap(NULL, 64982, PROT_READ, MAP_PRIVATE, 3, 0)
= 0x40017000
9504 close(3) = 0
9504 open("/usr/lib/libz.so.1", O_RDONLY) = 3
9504 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20\31\0"...,
1024) = 1024
9504 fstat64(3, {st_mode=S_IFREG|0755, st_size=59618,
...}) = 0
9504 old_mmap(NULL, 54824, PROT_READ|PROT_EXEC,
MAP_PRIVATE, 3, 0) = 0x40027000
9504 mprotect(0x40033000, 5672, PROT_NONE) = 0
9504 old_mmap(0x40033000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED, 3, 0xb000) = 0x40033000
9504 close(3) = 0
9504 open("/usr/lib/libgdbm.so.2", O_RDONLY) = 3
9504 read(3,
"\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\24\0\000"...,
1024) = 1024
9504 fstat64(3, {st_mode=S_IFREG|0755, st_size=30114,
...}) = 0
9504 old_mmap(NULL, 24908, PROT_READ|PROT_EXEC,
MAP_PRIVATE, 3, 0) = 0x40035000
9504 mprotect(0x4003a000, 4428, PROT_NONE) = 0
9
#21743 [Opn]: Driver initialization failed for handler: db3 (and db2)
ID: 21743
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: DBM/DBA related
Operating System: RedHat Linux 7.2
PHP Version: 4.3.0
Assigned To: helly
New Comment:
I've reconfigured my system with shared dba and db3-3.3
and cannot reproduce you results. Hopefully i can get a
copy of the db-3.2 source distrubution which is no longer
online :-(
Previous Comments:
[2003-01-26 00:21:47] [EMAIL PROTECTED]
> First please try this (note the "-" after "c":
> dl("dba.so");
> $a = dba_open("test", "c-", "db3");
> ?>
It is working!
# php 2.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
# ls -al test
-rw-r--r--1 root root 8192 Jan 26 12:34
test
# file test
test: Berkeley DB (Btree, version 8, native byte-order)
> Then please try if you can create and open an new file:
> dl("dba.so");
> $a = dba_open("test2", "n-", "db3");
> var_dump($a);
> dba_close($a);
> $b = dba_open("test2", "r-", "db3");
> var_dump($b);
> dba_close($b);
> ?>
It is working...
# php 3.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
resource(1) of type (dba)
resource(2) of type (dba)
> after that: From your configure script:
> --enable-dba=shared \
>--with-gdbm \
>--with-db3 \
>--with-cdb=/usr \
>--with-flatfile \
>
> This means you cannot have db2.
> However you found a problem here: --with-cdb always
loads
> the internal cdb support (so thanks here i've fixed
> this part already in cvs).
OK, while we are at this, it seems there is another
related problem. --without-db3 (or db2, flatfile, and
others too) doesn't seem to be working. configure will
show that db3 will not be included (checking for Berkeley
DB3 support... no), but it will still be included if it
finds one on my system, and the resulting binary will not
be linked to DB3 library as shown by ldd. And
--without-flatfile (and maybe --without-cdb too) will
cause undefined symbol error but I think you already know
that :)
> Could you try (with only db3, cdb and flatfile)
> --enable-dba=shared \
> --with-db3 \
> --with-cdb \
> --with-flatfile \
Doesn't work. :(
> Maybe you could also try db4 or db4.1 versions buy
> --with-db3=/path/to/db4 for PHP 4.3 or --with-db4 for
cvs versions.
I'll get back to you later on this after I finally
finished downloading and compiling (the sql worm thing is
still wreaking havoc here)
On a side note, ext/dba from PHP 4.2.1 works (phpize'ed),
maybe because it doesn't have locking?
Oh, is it possible that BerkeleyDB has its own locking
mechanism that is conflicting with PHP's? Consider this
scenario:
- on dba_open, php locks the berkeley db file
- php then handles opening the db file to berkeley db
library
- berkeley db tries to lock the file, but since it is
already locked by php it will eventually time out
>From berkeley db documentation, it seems that it does its
own locking.
http://www.sleepycat.com/docs/ref/lock/intro.html
[2003-01-25 14:18:06] [EMAIL PROTECTED]
First please try this (note the "-" after "c":
Then please try if you can create and open an new file:
after that: From your configure script:
--enable-dba=shared \
--with-gdbm \
--with-db3 \
--with-cdb=/usr \
--with-flatfile \
This means you cannot have db2.
However you found a problem here: --with-cdb always loads
the internal cdb support (so thanks here i've fixed
this part already in cvs).
Could you try (with only db3, cdb and flatfile)
--enable-dba=shared \
--with-db3 \
--with-cdb \
--with-flatfile \
Maybe you could also try db4 or db4.1 versions buy
--with-db3=/path/to/db4 for PHP 4.3 or --with-db4 for c
#21743 [Asn]: Driver initialization failed for handler: db3 (and db2)
ID: 21743
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: DBM/DBA related
Operating System: RedHat Linux 7.2
PHP Version: 4.3.0
Assigned To: helly
New Comment:
Called my contact at Berkeley and got the link to the 3.2
version. Now i am able to reproduce a segfault...I'll look
into deeper ASAP
Previous Comments:
[2003-01-26 23:49:22] [EMAIL PROTECTED]
I've tested it with db3-3.3 (RedHat 7.3) and also
experienced the same result :(.
Older berkeley db sources can be obtained from
http://rpmfind.net as SRPMSs.
I've also uploaded my binary dba.so to
http://priyadi.net/php/dba.so if that will help. It is
compiled with --with-flatfile --with-cdb --with-db3.
Compiled on a RedHat 7.2 system, and db3-3.2.9.
[2003-01-26 08:01:02] [EMAIL PROTECTED]
I've reconfigured my system with shared dba and db3-3.3
and cannot reproduce you results. Hopefully i can get a
copy of the db-3.2 source distrubution which is no longer
online :-(
[2003-01-26 00:21:47] [EMAIL PROTECTED]
> First please try this (note the "-" after "c":
> dl("dba.so");
> $a = dba_open("test", "c-", "db3");
> ?>
It is working!
# php 2.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
# ls -al test
-rw-r--r--1 root root 8192 Jan 26 12:34
test
# file test
test: Berkeley DB (Btree, version 8, native byte-order)
> Then please try if you can create and open an new file:
> dl("dba.so");
> $a = dba_open("test2", "n-", "db3");
> var_dump($a);
> dba_close($a);
> $b = dba_open("test2", "r-", "db3");
> var_dump($b);
> dba_close($b);
> ?>
It is working...
# php 3.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
resource(1) of type (dba)
resource(2) of type (dba)
> after that: From your configure script:
> --enable-dba=shared \
>--with-gdbm \
>--with-db3 \
>--with-cdb=/usr \
>--with-flatfile \
>
> This means you cannot have db2.
> However you found a problem here: --with-cdb always
loads
> the internal cdb support (so thanks here i've fixed
> this part already in cvs).
OK, while we are at this, it seems there is another
related problem. --without-db3 (or db2, flatfile, and
others too) doesn't seem to be working. configure will
show that db3 will not be included (checking for Berkeley
DB3 support... no), but it will still be included if it
finds one on my system, and the resulting binary will not
be linked to DB3 library as shown by ldd. And
--without-flatfile (and maybe --without-cdb too) will
cause undefined symbol error but I think you already know
that :)
> Could you try (with only db3, cdb and flatfile)
> --enable-dba=shared \
> --with-db3 \
> --with-cdb \
> --with-flatfile \
Doesn't work. :(
> Maybe you could also try db4 or db4.1 versions buy
> --with-db3=/path/to/db4 for PHP 4.3 or --with-db4 for
cvs versions.
I'll get back to you later on this after I finally
finished downloading and compiling (the sql worm thing is
still wreaking havoc here)
On a side note, ext/dba from PHP 4.2.1 works (phpize'ed),
maybe because it doesn't have locking?
Oh, is it possible that BerkeleyDB has its own locking
mechanism that is conflicting with PHP's? Consider this
scenario:
- on dba_open, php locks the berkeley db file
- php then handles opening the db file to berkeley db
library
- berkeley db tries to lock the file, but since it is
already locked by php it will eventually time out
>From berkeley db documentation, it seems that it does its
own locking.
http://www.sleepycat.com/docs/ref/lock/intro.html
[2003-01-25 14:18:06] [EMAIL PR
#21743 [Asn]: Driver initialization failed for handler: db3 (and db2)
ID: 21743
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: DBM/DBA related
Operating System: RedHat Linux 7.2
PHP Version: 4.3.0
Assigned To: helly
New Comment:
Please update: ext/dba/config.m4
This fixes some problems when linking against a specific
library version. If you do not use your systems default
db library you must not include ndbm support since that
is based on db1 which in turn is db-1.85 or based on db-x
where x is 1.85 or x >= 2.
I tried the following:
- db-3.2 (not shared) and it works.
- db-4.1.25 (shared/not shared) and it works.
- db-3.3 from system rpm (not shared) and it works.
- db-3.3 from source (shared) and it works
So i will ask sleepycat for known problems and maybe
disable shared dba in case of db-3.2.
I missed to answer your question: db libraries *can*
do file locking but we tell the library not to do so and
use our own locking.
To unalize your db4 problems: What extact version are you
using (ldd) and which config (but ldd should be enough).
Previous Comments:
[2003-01-30 11:38:18] [EMAIL PROTECTED]
I also encountered segfaults with db4 compiled with
--with-db3=dir but not with db3 supplied by redhat.
[2003-01-29 18:59:10] [EMAIL PROTECTED]
Called my contact at Berkeley and got the link to the 3.2
version. Now i am able to reproduce a segfault...I'll look
into deeper ASAP
[2003-01-26 23:49:22] [EMAIL PROTECTED]
I've tested it with db3-3.3 (RedHat 7.3) and also
experienced the same result :(.
Older berkeley db sources can be obtained from
http://rpmfind.net as SRPMSs.
I've also uploaded my binary dba.so to
http://priyadi.net/php/dba.so if that will help. It is
compiled with --with-flatfile --with-cdb --with-db3.
Compiled on a RedHat 7.2 system, and db3-3.2.9.
[2003-01-26 08:01:02] [EMAIL PROTECTED]
I've reconfigured my system with shared dba and db3-3.3
and cannot reproduce you results. Hopefully i can get a
copy of the db-3.2 source distrubution which is no longer
online :-(
[2003-01-26 00:21:47] [EMAIL PROTECTED]
> First please try this (note the "-" after "c":
> dl("dba.so");
> $a = dba_open("test", "c-", "db3");
> ?>
It is working!
# php 2.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
# ls -al test
-rw-r--r--1 root root 8192 Jan 26 12:34
test
# file test
test: Berkeley DB (Btree, version 8, native byte-order)
> Then please try if you can create and open an new file:
> dl("dba.so");
> $a = dba_open("test2", "n-", "db3");
> var_dump($a);
> dba_close($a);
> $b = dba_open("test2", "r-", "db3");
> var_dump($b);
> dba_close($b);
> ?>
It is working...
# php 3.php
Content-type: text/html
X-Powered-By: PHP/4.3.0
resource(1) of type (dba)
resource(2) of type (dba)
> after that: From your configure script:
> --enable-dba=shared \
>--with-gdbm \
>--with-db3 \
>--with-cdb=/usr \
>--with-flatfile \
>
> This means you cannot have db2.
> However you found a problem here: --with-cdb always
loads
> the internal cdb support (so thanks here i've fixed
> this part already in cvs).
OK, while we are at this, it seems there is another
related problem. --without-db3 (or db2, flatfile, and
others too) doesn't seem to be working. configure will
show that db3 will not be included (checking for Berkeley
DB3 support... no), but it will still be included if it
finds one on my system, and the resulting binary will not
be linked to DB3 library as shown by ldd. And
--without-flatfile (and maybe --without-cdb too) will
cause undefined symbol error but I think you already know
that :)
> Could you try (with only db3, cdb and flatfile)
> --enable-dba=shared \
#21973 [Opn->Bgs]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. Previous Comments: [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. [2003-01-30 20:20:04] [EMAIL PROTECTED] (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefixprint libpng prefix --libdirprint path to directory containing library --libs print library linking information --ccoptsprint compiler options --cppflags print pre-processor flags --cflagsprint preprocessor flags, I_opts, and compiler options --I_optsprint "-I" include options --L_optsprint linker "-L" flags for dynamic linking --R_optsprint dynamic linker "-R" or "-rpath" flags --ldoptsprint linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --staticrevise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Intel machines and they do not appear to have this with older libpng. (2) LDAP: Here there are issues with having so many different LDAP distributions to be compatible with. But PHP seems to ignore an existing, working path configuration and try to discover another configuration by using hard-coded filenames rather than compilation tests (leaving no diagnostic messages about why it did or didn't succeed). (3) Banter: > You make it sound like a 'why does php do this' type of problem, Yes: in the case of PNG, why does PHP do a linking check for libpng using the user's environment and system linker settings but then throw that away and use some hard-coded filename values for a file presence test as part of different half-related module instead of using the known-good values it already has? (I think that technically qualifies as a sentence ;) Perhaps it is to deal with some fringe case, so perhaps PHP could assess whether the fringe case is present before trying to compensate for it. > Think about it: if > 90% of unices put libraries in $prefix/lib In a mixed processor mode environment where there can be multiple architecture variants of libraries (e.g. one that uses the processor's preferred arch and one that uses a compatibility arch), something has to give. In Sun's case, it decided on the convention of putting different architectures into different directories, preventing files from one arch obliterating files from another. And in the end, I got PHP 4.3.0 to compile but it still thinks sizeof(int) == sizeof(long) and crashes during installation. [2003-01-30 19:35:26] [EMAIL PROTECTED] You make it sound like a 'why does php do this' type of problem, but think about it: if > 90% of unices put libraries in $prefix/lib, then you can just see the Sun people sitting in their offices saying: "let's make portable software sweat a little so everybody uses Solaris again". Working towards the solution: is there a config script, like png-config, which reports how the library was installed - similar to mysql_config/curl-config/mm-config and such? If not - does this apply to all Solaris 8 installed libraries and also to headers or is this different for different packages? [2003-01-30 18:42:42] [EMAIL PROTECTED] ./configure from the 4.3.0 release contains constructs like: for i in /usr /usr/local $PHP_PNG_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f \ $i/lib/libpng.a && GD_PNG_DIR=$i done The 'lib/libpng.' bit is hard-coded. But my libpng is at /usr/local/lib/sparcv9/libpng.so The end of configure's output is: checking for the
#21647 [NoF->Csd]: make test gives loop error
ID: 21647 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: *General Issues Operating System: solaris 8 PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Also see http://bugs.php.net/21751 for more info. However this part is fixed. Previous Comments: [2003-01-31 01:00:04] [EMAIL PROTECTED] No feedback was provided for this bug for over 2 weeks, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2003-01-15 03:27:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip [2003-01-14 23:50:11] [EMAIL PROTECTED] SED is gnu also [2003-01-14 23:49:10] [EMAIL PROTECTED] gcc 3.2.1 with gnu ld and solaris 8 with latest patches apache 2.0.43 and php 4.3.0 compile with --with-apxs2=/PATH_TO_APXS or anything and I get this loop are after make make test and this is what I get ( I am not running php in safe mode) PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php on line 48 PHP Notice: ob_end_clean() [http://www.php.net/ref.outcontrol]: failed to delete buffer default output handler. in /export/home/imiller/php-4.3.0/run-tests.php ?? added question marks -- Edit this bug report at http://bugs.php.net/?id=21647&edit=1
#21751 [Asn]: make test miserably fails
ID: 21751 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Output Control Operating System: SunOS PHP Version: 4.3.0 Assigned To: helly New Comment: The part already closed (the eb_end_clean() loop) was also reported in http://bugs.php.net/21647 Previous Comments: [2003-01-25 13:55:49] [EMAIL PROTECTED] Symptoms are defeated the real problem remains: "failed to delete buffer default output handler" In other words with cvs versions you can do now: php -d output_buffering=4096 run-tests.php Interesting thing is that it worked in 4.2 [2003-01-19 10:45:00] [EMAIL PROTECTED] I didn't have "." in my include_path and I had output_buffering = 4096. Reasonable? So the while(ob_get_level()) ob_end_clean(); algorithm in run-tsts.php runs forever: level won't go below 1. An implicit ob_start implied by buffering? then the feature is fine and the test script broken. I commented that out but forgot to fix the .ini. Result: many test failures and the result posted to your site w/o letting me say a word. (Quite nasty, isn't it?) In facts: 1) "-n" or "-c ." options to command line don't do it, 2) flush() doesn't work as expected when bufferning, 3) reading stdin doesn't work at all! You need to fix (1) and ship the product with a working php.ini for the tests. Please fix the tests by setting something like "do you want to run the tests interactively?" and if you get no answer assume NO_INTERACTION=1! TIA Ale -- Edit this bug report at http://bugs.php.net/?id=21751&edit=1
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Compile Failure +Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: 1) Please check if the following patch for ext/gd/config.m4 shows the correct message: Index: ext/gd/config.m4 === RCS file: /repository/php4/ext/gd/config.m4,v retrieving revision 1.120.2.8 diff -u -r1.120.2.8 config.m4 --- ext/gd/config.m423 Jan 2003 06:22:42 - 1.120.2.8 +++ ext/gd/config.m431 Jan 2003 09:11:28 - @@ -72,7 +72,9 @@ AC_DEFUN(PHP_GD_PNG,[ if test "$PHP_PNG_DIR" != "no"; then -for i in /usr /usr/local $PHP_PNG_DIR; do + PNG_USER_DIR=$PHP_PNG_DIR + unset PHP_PNG_DIR +for i in /usr /usr/local $PNG_USER_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i done 2) Since you obviated a system immanent feature (libs in x/lib and includes in x/include) you may required a link to point to your library and includes. Previous Comments: [2003-01-31 02:39:47] [EMAIL PROTECTED] > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. [2003-01-30 20:20:04] [EMAIL PROTECTED] (1) png-config: > is there a config script, like png-config Aha! A file search shows libpng-config with the following usage: Usage: libpng-config [OPTION] ... Known values for OPTION are: --prefixprint libpng prefix --libdirprint path to directory containing library --libs print library linking information --ccoptsprint compiler options --cppflags print pre-processor flags --cflagsprint preprocessor flags, I_opts, and compiler options --I_optsprint "-I" include options --L_optsprint linker "-L" flags for dynamic linking --R_optsprint dynamic linker "-R" or "-rpath" flags --ldoptsprint linker options --ldflags print linker flags (ldopts, L_opts, R_opts, and libs) --staticrevise subsequent outputs for static linking --help print this help and exit --version print version information This is for version 1.2.5. But I just had a look at various stable-distribution GNU Linux/Intel machines and they do not appear to have this with older libpng. (2) LDAP: Here there are issues with having so many different LDAP distributions to be compatible with. But PHP seems to ignore an existing, working path configuration and try to discover another configuration by using hard-coded filenames rather than compilation tests (leaving no diagnostic messages about why it did or didn't succeed). (3) Banter: > You make it sound like a 'why does php do this' type of problem, Yes: in the case of PNG, why does PHP do a linking check for libpng using the user's environment and system linker settings but then throw that away and use some hard-coded filename values for a file presence test as part of different half-related module instead of using the known-good values it already has? (I think that technically qualifies as a sentence ;) Perhaps it is to deal with some fringe case, so perhaps PHP could assess whether the fringe case is present before trying to compensate for it. > Think about it: if > 90% of unices put libraries in $prefix/lib I
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: 1) The patch allows to present the correct error message without changing anything else yet. I am working on a php wide patch that solves such problems generically. 2) I knew before what you are trying to. However you got a problem simply because you wnated to save some bytes... Try this layout .../normal/png/lib .../normal/png/include .../sparcv9/png/lib .../sparcv9/png/include What is left could be the fact that you used "libpng12" and i am not quite sure if we want to search for all versions since there should be links named libpng.whatever that point to the specific version (thats different from db-n where we search for a specific version). If you use the layout above you even have no need to configure any compiler linker configuration before calling ./configure. Previous Comments: [2003-01-31 03:34:09] [EMAIL PROTECTED] In response to (1): This makes no difference. I'm not sure if we're on the same planet. I'm not quite sure what the patch was meant to achieve (and thus I don't understand what I was supposed to do to take advantage of it once configure was regenerated). I think the loop that fails to find libpng is indeed the one you've provided the patch for, so you and I are possibly within the same universe. In response to (2): > Since you obviated a system immanent feature... Hey, I'm really confused now. I'm not at all sure what nuance you're implying with those words. I really don't understand why you said it at all. Can I try saying this to you: /usr/local/include/libpng/png.h (for both arch) /usr/local/include/libpng/pngconf.h (for both arch) /usr/local/lib/libpng12.so (32-bit) /usr/local/lib/sparcv9/libpng12.so (64-bit) PHP needs to use the files in /usr/local/include/libpng and /usr/local/lib/sparcv9. The library path is already known by the compiler, linker, and loader. [2003-01-31 03:14:27] [EMAIL PROTECTED] 1) Please check if the following patch for ext/gd/config.m4 shows the correct message: Index: ext/gd/config.m4 === RCS file: /repository/php4/ext/gd/config.m4,v retrieving revision 1.120.2.8 diff -u -r1.120.2.8 config.m4 --- ext/gd/config.m423 Jan 2003 06:22:42 - 1.120.2.8 +++ ext/gd/config.m431 Jan 2003 09:11:28 - @@ -72,7 +72,9 @@ AC_DEFUN(PHP_GD_PNG,[ if test "$PHP_PNG_DIR" != "no"; then -for i in /usr /usr/local $PHP_PNG_DIR; do + PNG_USER_DIR=$PHP_PNG_DIR + unset PHP_PNG_DIR +for i in /usr /usr/local $PNG_USER_DIR; do test -f $i/lib/libpng.$SHLIB_SUFFIX_NAME -o -f $i/lib/libpng.a && GD_PNG_DIR=$i done 2) Since you obviated a system immanent feature (libs in x/lib and includes in x/include) you may required a link to point to your library and includes. [2003-01-31 02:39:47] [EMAIL PROTECTED] > --with-png-dir[=DIR] GD: Set the path to libpng install prefix. > that means you can set your library patch as follows: > --with-png-dir=/usr/local/lib/sparcv9 That makes no observable difference. Configure still reports "checking for the location of libpng... yes" (not that I have a directory called 'yes'...) and still says "If configure fails try --with-jpeg-dir= configure: error: libpng.(a|so) not found." (and then stops). Note that the sparcv9 path is not libpng's "install prefix", it is just the lib dir. [2003-01-31 02:11:45] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Look into ./configure --help: --with-png-dir[=DIR] GD: Set the path to libpng install prefix. that means you can set your library patch as follows: --with-png-dir=/usr/local/lib/sparcv9 But yes we could do it in another order to have more helpful error messages. [2003-01-31 01:39:32] [EMAIL PROTECTED] FYI: I dont have that libpng-config thingy, and most older (7.x) RedHat versions still use libpng 1.0.x so don't assume it's available. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21973 -- Edit this bu
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: If you want support your environment we would have to change all configure files. We would have to change all lines of the form .../lib/... with ../$LIB_DIR/... and add some configure magic to determine what $LIB_DIR should be (in your case it would be sparcv9). Previous Comments: [2003-01-31 05:11:00] [EMAIL PROTECTED] Re: [EMAIL PROTECTED] [Sorry, didn't get around to reading your new message until after sending the followup that I started prior to you message.] Woah! Is this part of a concerted effort to eliminate support for modern platforms? Is that why LP64 64-bit compatibility is so broken and the Zend engine and PHP modules are drifting away from C-code portability? Is this part due to a move by Zend to only support commercially-associated hardware or something? Some missing details here. I'm not sure what status to believe this bug is at. I think "Open". It's been changed to "Bogus" twice but from what you've said, it sounds like "Won't Fix" (I don't have that option in the bug tracking interface, perhaps you do?). Of 147 packages that I compile on the same architecture, and who-knows-how-many-more that come in packages, why is PHP avoiding support? Won't it be detrimental if operating system vendors have to heavily patch/port PHP in order to keep it working on their platforms (in order to maintain viability of those platforms)? Is there an arbitration board or core developer group that I can speak to about this? Sounds like an off-list matter to begin with. [2003-01-31 05:02:49] [EMAIL PROTECTED] > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform Sun, HP, and SGI that they've got it wrong and should travel back in time to change the course of history. Nor am I in a position to contact all users and ask them to change their system settings or symlink all installed packages to accommodate PHP. Nor am I in a position to write to all package maintainers and commercial software developers and inform them to change their releases to accommodate a different file structure. Nor am I in a position to write to all developers in the globe and ask them to change their software because PHP has shown us how it should be done. > What is left could be the fact that you used "libpng12" and > i am not quite sure if we want to search for all versions since there > should be links named libpng. whatever that point to the specific > version (thats different from db-n where we search for a specific > version). libpng chooses libpng12 (as described in its docs). But I do seem to have symlinks using the name libpng rather than libpng12, as you say. Sorry for the confusion! My fault for not being particularly familiar with libpng. Anyway, in my eyes my original bug report stands, including my comment that other configuration steps, such as for LDAP, are broken. Hmm, looking at some live pages right now, LDAP compiled in fine with PHP 4.3.0 pre-release CVS. Although I had to patch PHP extensively to make it install, load, and work correctly, I don't remember having to patch anything in the configure script. Then again, my memory does have many faults. ...pause to wait for fresh copies of PHP to run 'configure'... Yes, 4.3.0 release seems to report an error when trying to find ldap whereas 4.3.0 CVS (unknown date, I could find out though) seems fine. I may have to leave this matter overnight since it is 7pm in my timezone. (Which is extremely different to whatever timezone -- apparently not UTC -- that the bugs.php.net interface seems to use :) [2003-01-31 04:18:23] [EMAIL PROTECTED] The way this works, works for 99.99% of users
#21991 [Opn->Fbk]: CLI only gets compiled with --with-apxs
ID: 21991 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Debian GNU/Linux Sid/Unstable PHP Version: 4.3.0 New Comment: Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. Seems you must have done something more. I tried it myself and it is working. However i did it with current CVS version. Could you please try that yourself? If the CVS version behaves the same way i suggest you post your configure line here and it may be necessary to inquire the generated makefile. However there is another solution for that effect: Did you use --disable-all or --disable-cli for any reason? You can verify that by locking into config.nice. Previous Comments: [2003-01-31 16:47:39] [EMAIL PROTECTED] There seems to be a configure bug with php 4.3.0. When you compile, you dont get the CLI unless you include --with-apxs in the ./configure line. I confirmed this by having my mates try out different configure lines, they too only got it when configuring with the --with-apxs option enabled. If this is a global bug I do not know, but it would seem so - One of them is running Mandrake 9.0, the other Red Hat 8.0, and myself Debian Sid/Unstable. -- Edit this bug report at http://bugs.php.net/?id=21991&edit=1
#21973 [Opn]: 'configure' script can't find libpng.(a|so), openldap...
ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment: Back to dba: I tried several combinations and having problems with shared dba earlier than 3.3. I did some fixes and disallowed buildng shared dba with those versions for now. However i got a short reply from sleepycat that they do not have any idea how to explain what is happening. Back to general linking: I made a configure function which allows me to handle all libraries required by gd and dba extension. Since those are the most complicated cases i suppose we could easily expand that function to handle all external libraries. If that is done we may even add automatic detection support for your directory structure. I will post that function here and as a diff on php-dev during the week Previous Comments: [2003-02-01 01:08:15] [EMAIL PROTECTED] > Anyway, in what version of PHP did LDAP configure > work without any patches? The CVS tag is php_4_3_0pre2. I've done a fresh checkout with that tag and can verify that the 'configure' script generated by my copies of autoconf, etc, works. I tried the following successful combinations: - autoconf 2.52, automake 1.5, libtool 1.4 - autoconf 2.57, automake 1.7.2, libtool 1.4.3 - flex 2.5.4 and bison 1.75 were used in all cases. Compiler was gcc 3.2.1 for Sun UltraSPARC v9 using Sun's CCS assembler Sun's CCS linker (typical scenario). Notes: - first, I applied my int/long correctness patches (fortunately, these do not influence the configure step). - ldap configures and compiles with no warnings or errors. BUT I have to induce -lldap myself (other modules, such as database modules, seem to pick up their libraries okay, though). So really, ldap configuration wasn't entirely working in pre2 but the fault had a different manifestation than in the release, and had obvious output/cause/workaround. - the gd module configures with errors but I commented out the 'exit' commands and configure completes. - the ldap and gd modules then appear work fine with Apache. - I had to comment out _LT_AC_TRY_DLOPEN_SELF when using the second lot of auto tools. But when I do a buildconf, configure, make with php_4_3_0, I get the problem "Cannot find ldap libraries in $LDAP_LIBDIR." Notes: - first, I applied my int/long correctness patches (fortunately, these do not influence the configure step). - I can work around the gd & ldap problems by manually deleting the 'exit' commands in the configure script or inserting the sparcv9 path element into the configure script, in which case the ldap module then picks up -lldap by itself. - the _LT_AC_TRY_DLOPEN_SELF problem has disappeared in 4.3.0 release. - the ldap and gd modules then appear work fine with Apache. > Is the only problem really that we check that the actual > library _file_ exists? Better way of course would be to > use PHP_CHECK_LIBRARY macro always and not do the > filesystem checks at all, like Marcus suggested..? Yes, in my understanding. [2003-01-31 07:55:59] [EMAIL PROTECTED] I misunderstood the problem apparently, sorry for that. Anyway, in what version of PHP did LDAP configure work without any patches? Is the only problem really that we check that the actual library _file_ exists? Better way of course would be to use PHP_CHECK_LIBRARY macro always and not do the filesystem checks at all, like Marcus suggested..? [2003-01-31 06:19:33] [EMAIL PROTECTED] > we would have to change all configure files. Maybe huge rafts of PHP use the lib name convention, but for some reason it doesn't matter -- those parts of PHP work in my context anyway. And yes, some modules compile and some don't. Some used to and now they don't. >From my point of view: A) Why it would be okay that a module like ldap worked two/three months ago but does not configure correctly today. Surely this would considered to be regression. B) Why other software doesn't stumble during configuration but PHP does. Surely this is a problem with PHP. Maybe it's a case of "gosh, this is extensively wrong", but that doesn't make the problem bogus. C) I suspect that PHP would compile and run correctly if I comment out the 'exit' commands in configure. Then, if the ONLY reason that PHP doesn't compile is that configure stumbles -- not that any libraries are missing or can't already be found by the compiler -- surely that is because the implementation of 'configure' is wrong. It's as though...configure doesn'
#22011 [Opn->Csd]: php -n does not work as expected
ID: 22011 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Unknown/Other Function Operating System: linux RH 8.0 PHP Version: 4.3.0 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Please ask such questions on [EMAIL PROTECTED] Previous Comments: [2003-02-02 08:13:58] [EMAIL PROTECTED] Hi, if php CLI was configured: --with-config-file-path=/etc --with-config-file-scan-dir=/some/directory -n switch passed to the CLI scans this additional ini file(s). php -h says -n No php.ini file will be used Does this "No" exclude additional ini-files? PHP 4.3.0 (cli) PHP API => 20020918 PHP Extension => 20020429 Zend Extension => 20021010 Debug Build => no Thread Safety => disabled Registered PHP Streams => php, http, ftp, https, ftps, compress.zlib Regards Friedhelm Betz -- Edit this bug report at http://bugs.php.net/?id=22011&edit=1
#22097 [Opn->Bgs]: Eval fails to process this gem.
ID: 22097
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux x86 2.4.18
PHP Version: 4.3.0
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You need to double evaluate.
$$errortype resolves to $invalid
evaluating resolves to the string containing $number.
That has to be evaluated as well.
Also why not use foreach and you can use eval()'s
return value. See below:
$errortype) {
$errormessage .= eval("echo eval(\"echo
\\\"$$errortype\\\";\");");
}
echo $errormessage;
?
Send further questions please [EMAIL PROTECTED]
Previous Comments:
[2003-02-06 16:43:28] [EMAIL PROTECTED]
$error["1231"] = "invalid";
$error["1255"] = "invalid_max";
$invalid = 'You did not choose a valid quantity for item number
$item.\n';
$invalid_min = 'You did not order the minimum amount for item
$item.\n';
$invalid_max = 'You ordered more than you were permitted for item
$item.\n';
while (list($item, $errortype) = each($error)) {
eval("\$errormessage .= \"$$errortype\";");
}
print $errormessage;
Eval prints the following:
You did not choose a valid quantity for item number $item.
You ordered more than you were permitted for item $item.
It should print this:
You did not choose a valid quantity for item number 1231.
You ordered more than you were permitted for item 1255.
--
Edit this bug report at http://bugs.php.net/?id=22097&edit=1
#22097 [Bgs]: Eval fails to process this gem.
ID: 22097
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Linux x86 2.4.18
PHP Version: 4.3.0
New Comment:
CAUTION: The input field scrambled my input!
You have to use
- 3 slashes where it shows 7
- 1 slash where it shows 3
- 0 slash where it shows 1
Previous Comments:
[2003-02-06 17:28:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You need to double evaluate.
$$errortype resolves to $invalid
evaluating resolves to the string containing $number.
That has to be evaluated as well.
Also why not use foreach and you can use eval()\'s
return value. See below:
$errortype) {
$errormessage .= eval(\"echo eval(\\\"echo
\\\"$$errortype\\\";\\\");\");
}
echo $errormessage;
?
Send further questions please [EMAIL PROTECTED]
[2003-02-06 16:43:28] [EMAIL PROTECTED]
$error["1231"] = "invalid";
$error["1255"] = "invalid_max";
$invalid = 'You did not choose a valid quantity for item number
$item.\n';
$invalid_min = 'You did not order the minimum amount for item
$item.\n';
$invalid_max = 'You ordered more than you were permitted for item
$item.\n';
while (list($item, $errortype) = each($error)) {
eval("\$errormessage .= \"$$errortype\";");
}
print $errormessage;
Eval prints the following:
You did not choose a valid quantity for item number $item.
You ordered more than you were permitted for item $item.
It should print this:
You did not choose a valid quantity for item number 1231.
You ordered more than you were permitted for item 1255.
--
Edit this bug report at http://bugs.php.net/?id=22097&edit=1
#22108 [Fbk->Bgs]: php doesn't ignore the utf-8 BOM
ID: 22108 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: Output Control Operating System: windows 2000 PHP Version: 4.2.3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php BOM = Byte Order Mark for UCS-2 encoding This value sould not be used in UTF-8 since the only reason besides detecting the byte order of UCS-2 was a special non breaking space. And newer Unicode versions have another representation for the same thing. Anyhow BOM = FE FF That makes depending on the byte order: UCS-2BE <-> "\xFE\xFF" UCS-2LE <-> "\xFF\xFE" Therefore a sequence of "EF BB" is another character and must not be ignored. Previous Comments: [2003-02-07 10:42:16] [EMAIL PROTECTED] sniper, imagine someone would want to echo some text in eg. French. In that case, if you'd save it as ascii, you would get corrupted output. So instead you'd have to save as utf-8. Which seems to cause problems (or so [EMAIL PROTECTED] tells us) [2003-02-07 08:58:21] [EMAIL PROTECTED] And why an earth would you save PHP files in any other format than ascii? [2003-02-07 08:53:10] [EMAIL PROTECTED] What is a BOM ? Derick [2003-02-07 08:46:36] [EMAIL PROTECTED] Problem: When a php file is saved in utf-8 format with the UTF-8 BOM as the first three bytes of the file (EF BB BF), PHP doesn't ignore these bytes when loading and compiling the file, but instead considers them output coming prior to the http://bugs.php.net/?id=22108&edit=1
#22109 [Opn]: With-flatfile compile option causes core dumps during make test
ID: 22109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: DBM/DBA related Operating System: Solaris 2.7 PHP Version: 4CVS-2003-02-07 (stable) New Comment: Could you please send the outputs of "ldd php" and if you used shared builds then the ldd output of any loaded php module, too. And then i'd like to see the ouput of "php -r 'print_r(dba_handlers(1));'" if you did not use a cvs version then you must omit the parameter "1". Previous Comments: [2003-02-07 09:01:33] [EMAIL PROTECTED] Compiled with GCC 3.2.1 on Solaris 2.7 to work with Apache 2.0.40. Apache compiled with same GCC. Testing with CLI version in sapi/cli via make test. The SISSEGV segmentation core dump occurs with the "tests/func/005a.phpt" only when I include the --with-flatfile option in the configure script, by itself or in combination with any other option. Absent this flatfile setting, no core dump occurs. I've confirmed this with numerous clean, right from scratch reconfigures and compiles. Within the failing test, the register_shutdown_function() call works ok. It appears that the dump is being triggered when the time limit set by set_time_limit() expires within the infinite for loop. I varied the time value to set_time_limit(), but still got the core dumps. Using GDB 4.1.18, I got this backtrace: Program received signal SIGSEGV, Segmentation fault. 0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 (gdb) bt #0 0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 #1 0xfeffbdfc in __sighndlr () from /usr/lib/libthread.so.1 #2 #3 execute (op_array=0x2890b0, tsrm_ls=0x1dbbd0) at /opt/src/php/php4-STABLE-200302021630/Zend/zend_execute.c:1350 #4 0x1395fc in zend_execute_scripts (type=8, tsrm_ls=0x1dbbd0, retval=0x0, file_count=3) at /opt/src/php/php4-STABLE-200302021630/Zend/zend.c:864 #5 0x1078ac in php_execute_script (primary_file=0xffbef110, tsrm_ls=0x1dbbd0) at /opt/src/php/php4-STABLE-200302021630/main/main.c:1582 #6 0x14da14 in main (argc=2, argv=0xffbef19c) at /opt/src/php/php4-STABLE-200302021630/sapi/cli/php_cli.c:753 Due to the infinite for loop in the failing test, subseqent core dumps will backtrace differently depending on just where in the loop cycle the dump occurs at. Inother words, don't expect execute in frame 3 to look the same from trace to trace. Though its a bit of a chameleon to chase down, I'm still on the prowl to locate exact where this is happening at. ---dave -- Edit this bug report at http://bugs.php.net/?id=22109&edit=1
#22114 [NEW]: @echo not working
From: [EMAIL PROTECTED] Operating system: PHP version: 5CVS-2003-02-07 (dev) PHP Bug Type: Scripting Engine problem Bug description: @echo not working One cannot use '@' to hide warnings inside 'echo'. Example: [marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";' Command line code(1) : Parse error - parse error, unexpected T_ECHO -- Edit bug report at http://bugs.php.net/?id=22114&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22114&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22114&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22114&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22114&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22114&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22114&r=support Expected behavior: http://bugs.php.net/fix.php?id=22114&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22114&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22114&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22114&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22114&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22114&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22114&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22114&r=gnused
#22114 [Bgs]: @echo not working
ID: 22114 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type:Scripting Engine problem PHP Version: 5CVS-2003-02-07 (dev) New Comment: I know of corse but shouldn't it be allowed for echo, too? Previous Comments: [2003-02-07 15:04:43] [EMAIL PROTECTED] echo is not a function, but a language construct. Not a bug -> bogus. [2003-02-07 14:57:35] [EMAIL PROTECTED] One cannot use '@' to hide warnings inside 'echo'. Example: [marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";' Command line code(1) : Parse error - parse error, unexpected T_ECHO -- Edit this bug report at http://bugs.php.net/?id=22114&edit=1
#22114 [Bgs]: @echo not working
ID: 22114
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type:Scripting Engine problem
PHP Version: 5CVS-2003-02-07 (dev)
New Comment:
The following patch *is* not the beautiful way to solve it but is shows
its working. Anyway it works when using print instead of echo which is
handled as an expression.
Index: Zend/zend_language_parser.y
===
RCS file: /repository/ZendEngine2/zend_language_parser.y,v
retrieving revision 1.86
diff -u -r1.86 zend_language_parser.y
--- Zend/zend_language_parser.y 1 Feb 2003 01:49:14 - 1.86
+++ Zend/zend_language_parser.y 7 Feb 2003 21:25:05 -
@@ -202,6 +202,7 @@
| T_GLOBAL global_var_list ';'
| T_STATIC static_var_list ';'
| T_ECHO echo_expr_list ';'
+ | '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } T_ECHO
echo_expr_list ';' { zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }
| T_INLINE_HTML { zend_do_echo(&$1
TSRMLS_CC); }
| expr ';'{
zend_do_free(&$1 TSRMLS_CC); }
| T_USE use_filename ';' {
zend_error(E_COMPILE_ERROR,"use: Not yet supported. Please use
include_once() or require_once()"); zval_dtor(&$2.u.constant); }
Previous Comments:
[2003-02-07 15:08:43] [EMAIL PROTECTED]
I know of corse but shouldn't it be allowed for echo, too?
[2003-02-07 15:04:43] [EMAIL PROTECTED]
echo is not a function, but a language construct. Not a bug -> bogus.
[2003-02-07 14:57:35] [EMAIL PROTECTED]
One cannot use '@' to hide warnings inside 'echo'.
Example:
[marcus@zaphod php-HEAD]$ php -r '@echo "<$x>";'
Command line code(1) : Parse error - parse error, unexpected T_ECHO
--
Edit this bug report at http://bugs.php.net/?id=22114&edit=1
#21912 [Ver]: getimagesize() on remote images fails sometimes..
ID: 21912
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: GetImageSize related
Operating System: Linux
PHP Version: 4.3.1-dev
New Comment:
I suppose ther is another problem :-)
When i download the image and put it on one of my local servers it
works:
[marcus@zaphod php4-HEAD]$ php -r 'print_r(getimagesize($argv[1]));' --
http://zaphod.boerger.de/php/ext/exif/test/bug21912.jpg
Array
(
[0] => 389
[1] => 500
[2] => 2
[3] => width="389" height="500"
[bits] => 8
[channels] => 3
[mime] => image/jpeg
)
[marcus@zaphod php4-HEAD]$ php -r 'var_dump(getimagesize($argv[1]));'
-- http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg
bool(false)
Previous Comments:
[2003-01-28 13:52:36] [EMAIL PROTECTED]
Yes, it has indeed something to do with the image. If I take another
image it works fine! But there must be some difference in the PHP
versions since the 2nd pictures only works with PHP 4.1.2, and not with
the latest PHP version.
[2003-01-28 13:26:00] [EMAIL PROTECTED]
php -r '$size =
getimagesize("http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg";);
print_r($size); echo "\n";'
works without problems here (PHP 4.3.0), while
php -r '$size =
getimagesize("http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg";);
print_r($size); echo "\n";'
prints nothing. ImageMagick's "identify" sees some strange ipct data in
the second image; probably these make getimagesize() misbehave.
[2003-01-27 17:25:35] [EMAIL PROTECTED]
I can reproduce this with latest stable CVS (4.3.1-dev)
It does work if the image is local..but not if it's remote.
[2003-01-27 16:12:37] [EMAIL PROTECTED]
Hallo,
I have a weird problem, which I think is a bug. The following script
works with PHP 4.1.2 (I know, very outdated), but DOES NOT work with
PHP 4.3.0:
http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg";;
$image_size=getimagesize($foto);
$width=$image_size[0];
$height=$image_size[1];
$type=$image_size[2];
print ("\n");
print ("\n");
print ("width: $width; height: $height; type: $type\n");
print ("\n");
$foto="http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg";;
$image_size=getimagesize($foto);
$width=$image_size[0];
$height=$image_size[1];
$type=$image_size[2];
print ("\n");
print ("\n");
print ("width: $width; height: $height; type: $type\n");
?>
The problem is :
The first image works fine, it shows the height, width and type.
However, the information about the second image is only beeing
displayed if using PHP 4.1.2. With PHP 4.3.0 no information is beeing
displayed.
--
Edit this bug report at http://bugs.php.net/?id=21912&edit=1
#22108 [Opn]: php doesn't ignore the utf-8 BOM
ID: 22108 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: All (as of the current implementation) New Comment: Ok, the UTF-8 BOM was new to me. If i find the time i'll have a look at it over the weekend. I think the solution would be somewhere in zend's multibyte support since i fear adding that bom to mbstring alone does not do the trick. Previous Comments: [2003-02-08 05:43:14] [EMAIL PROTECTED] derick, assuming that you wanted to create a version of the the example at http://www.php.net/manual/en/introduction.php#intro-whatis which displayed the text "Hi, I'm a PHP script" in multiple languages, how would you propose doing it? The only way is to use a form of unicode encoding. The least intrusive of these ways is utf-8 because it encodes the text in such a way that ascii characters (7 bit characters) are still plain ascii characters, and all encoded characters are always >128 and will never be mistaken for ascii. I haven't seen any documentation which states that php can only handle ascii text, please direct me to it if it exists. If there is some known problem with PHP parsing UTF-8 scripts, I haven't found it yet in a multitude of different files with different languages which PHP is parsing happily. The only problem that I have had is that any files which have an UTF-8 BOM, PHP is mistakenly outputting the BOM as input. This is a bug of PHP. The solution is easy, on loading a file, strip the BOM if it exists. Make it optional processing via a php.ini config argument if necessary. Don't be US-centric in your thinking, there is far more world existing outside those borders. Regards, Brodie. [2003-02-08 04:24:12] [EMAIL PROTECTED] PHP doesn't want UNICODE scripts, but just ASCII ones. Not a bug -> bogus. [2003-02-08 02:01:11] [EMAIL PROTECTED] And assigning this task to me. [2003-02-08 01:48:15] [EMAIL PROTECTED] Yes, I suppose this might be a bug, but most of developers involved in PHP are not just so aware of this issue as you expected (and I had expected). So I thought that changing the category is a better choice than bogusing. [2003-02-07 23:13:07] [EMAIL PROTECTED] The BOM (byte order mark) is a few bytes at the very front of a file that act as a signature denoting what type of encoding has been used, and in UTF16/32 it also makes the byte order (LE or BE). Although utf-8 is byte order independent, it has become popular on windows (perhaps not so on unix) to make use of the BOM encoded in UTF-8 to flag the file as being in UTF-8 format. This allows editors to determine the type of the file from the first few characters instead of trying to guess what type the file is. Ref: Textpad 4.6 (http://textpad.com) See the Unicode FAQ for details of the utf-8 BOM... http://www.unicode.org/unicode/faq/utf_bom.html#25 The use of this should be obvious, you have to leave the my-language-only mindset that afflicts too many programmers (myself included before this job) and think about the growing multiplicity of languages on the web. I am writing web applications in Japan, with European language and CJK (Chinese/Japanese/Korean) language processing and interfaces. Thus I have php files where variable values are strings of all sorts of languages - hence utf-8 encoding. I feel that this is definitely a bug in php. Considering that: * php is slowly growing into a language-neutral (i18n/l10n possible) language * php is designed such that php commands can be liberally sprinkled through html, and html is increasing encoded in utf-8 these days * the utf-8 bom is becoming increasingly popular for reasons of indentifying the file character format * if the utf-8 bom exists php actually outputs it incorrectly and in doing so prevents header output I request that you don't see this as a feature request, but as a bug in the handling of utf-8 files. Whether the output generator is the correct characterization of this bug or not I leave up to you. Regards, Brodie. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/22108 -- Edit this bug report at http://bugs.php.net/?id=22108&edit=1
#22109 [Csd]: With-flatfile compile option causes core dumps during make test
ID: 22109 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DBM/DBA related Operating System: Solaris 2.7 PHP Version: 4CVS-2003-02-07 (stable) New Comment: Just another question what is your system: 32 or 64bit? To dba switches: You can see that information by either the function "dba_handlers()" or "php -i" or the output of the function "phpinfo()" (the last one creates layoted html output if called from your internet browser). And --with-dbXXX or other related dba switch turns DBA extension on. If you add --enable-dba then all default submodules which do not require external libraries are used, too (flatfile, cdb, cdb_make). Hope this helps. Maybe i reorganize the configure messages so that they do not confuse in the way you described it. regards marcus Previous Comments: [2003-02-10 13:04:58] [EMAIL PROTECTED] Closed per user-request. (and seems like fixed too..?) [2003-02-10 12:54:15] [EMAIL PROTECTED] I downloaded a late Sunday evening snapshot and did not receive any of the mentioned core dumps as in previous posts. I've also reviewed the information provided at http://www.php.net/manual/en/ref.dba.php and learned that the flatfile interface is deprecated. Based on this, there seems no need to persist with this as a bug report. Go ahead and close it. [2003-02-07 20:03:35] [EMAIL PROTECTED] Here is the ldd output you asked for: libcrypt_i.so.1 => /usr/lib/libcrypt_i.so.1 libresolv.so.2 =>/usr/lib/libresolv.so.2 libm.so.1 => /usr/lib/libm.so.1 libdl.so.1 =>/usr/lib/libdl.so.1 libnsl.so.1 => /usr/lib/libnsl.so.1 libsocket.so.1 =>/usr/lib/libsocket.so.1 libpthread.so.1 => /usr/lib/libpthread.so.1 libc.so.1 => /usr/lib/libc.so.1 libgen.so.1 => /usr/lib/libgen.so.1 libmp.so.2 =>/usr/lib/libmp.so.2 libthread.so.1 =>/usr/lib/libthread.so.1 /usr/platform/SUNW,Ultra-1/lib/libc_psr.so.1 I tried to run your print_r( dba_handlers() ) but I got an undefined function error. That only shows up in the code with the --enable-dba option, an option not used in my configure script. I included it, then re-configured and did a full re-compile. Still had the core dump afterwards. The output from the print_r command is: Array ( [flatfile] => 1.0, $Revision: 1.5.2.3 $ ) ) Side question: is there a configure reference or rule that states if one option is present, these other options should be as well. As in the above, is the enable-dba option required in the presence of the --with-dbXX or --with-flatfile options. Without the --enable-dba present, I saw the message "checking whether DBA interface is enabled=yes" in the config output. This led me to believe that DBA was enabled. That was not the case based on your email and the subsequent config output "checking whether DBA is enabled=yes" showed up right before the earlier mentioned one. I'm new to PHP so this seems ambiguous to me! [2003-02-07 14:03:25] [EMAIL PROTECTED] Could you please send the outputs of "ldd php" and if you used shared builds then the ldd output of any loaded php module, too. And then i'd like to see the ouput of "php -r 'print_r(dba_handlers(1));'" if you did not use a cvs version then you must omit the parameter "1". [2003-02-07 09:01:33] [EMAIL PROTECTED] Compiled with GCC 3.2.1 on Solaris 2.7 to work with Apache 2.0.40. Apache compiled with same GCC. Testing with CLI version in sapi/cli via make test. The SISSEGV segmentation core dump occurs with the "tests/func/005a.phpt" only when I include the --with-flatfile option in the configure script, by itself or in combination with any other option. Absent this flatfile setting, no core dump occurs. I've confirmed this with numerous clean, right from scratch reconfigures and compiles. Within the failing test, the register_shutdown_function() call works ok. It appears that the dump is being triggered when the time limit set by set_time_limit() expires within the infinite for loop. I varied the time value to set_time_limit(), but still got the core dumps. Using GDB 4.1.18, I got this backtrace: Program received signal SIGSEGV, Segmentation fault. 0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 (gdb) bt #0 0xff165758 in aiosigcancelhndlr () from /usr/lib/libaio.so.1 #1 0xfeffbdfc in __sighndlr () from /usr/lib/libthread.so.1 #2 #3 execute (op_array=0x2890b0, tsrm_ls=0x1dbbd0) at /opt
#22179 [Opn->Fbk]: convert float to int crashes
ID: 22179 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: Debian GNU/Linux PHP Version: 4.2.3 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2003-02-11 18:59:49] [EMAIL PROTECTED] i386 says sum is 0 alpha just does a floating point exception sparc64 says sum is 2147483647 powerpc says sum is -2147483648 It should be 0, I guess. If you prefer a one-liner: Same result. -- Edit this bug report at http://bugs.php.net/?id=22179&edit=1
#22173 [Opn]: Strange behaviour with the string 'inf'
ID: 22173
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Scripting Engine problem
Operating System: Linux
PHP Version: 4.2.1
New Comment:
We're already discussing this - so reopening was valid.
Previous Comments:
[2003-02-12 05:16:36] [EMAIL PROTECTED]
Re-open: at least with single three characters 'inf', this is a bug and
not a 'functionality'.
[2003-02-12 04:38:17] [EMAIL PROTECTED]
Ok, double-checked the documentation: this behavior of 'inf...' strings
seems absolutely undocumented.
Auto-convertion of any string that begins by 'inf' in infinite seems to
me inadequate. Considering that this 'functionality' has not been
documented, would be desirable to create a new predefined constant INF
or a new data type INF or a new reserved word INF to treat infinite
numbers, in the same form in which NULL, TRUE or FALSE correspond to
predefined values. Consider that when we locked up 'NULL', 'TRUE' or
'FALSE' in a string, they are not evaluated like the corresponding
constants. The same behavior would be desirable with a (new) predefined
constant INF.
And at least an error exists now in the form in which the strings that
begin by 'inf' are treated. The strings of more than 3 characters
('information', 'infant' ...) are evaluated as INF in the comparisons
with numbers, but the string 'inf', with single three characters, does
not. Try this:
';
echo (double)'inf', '';
echo 'information' > 1 ? 1 : 0, '';
echo 'inf' > 1 ? 1 : 0, '';
?>
Result:
INF
INF
1
0
Saludos
Àngel
[2003-02-11 17:11:20] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When performing a mathematical calculation between a number and a
string in PHP, PHP will attempt to convert the string to an integer.
Since PHP supports things such as INF certain strings, such as 'inf
more data' will be converted to INF.
[2003-02-11 13:55:05] [EMAIL PROTECTED]
Very strange bug: (double) of any string begining with 'inf' evaluates
as 'INF', but only in strings of more than 3 characters a comparison
with a integer results in same bug.
Try this script:
1 ? 1 : 0, '';
echo 'inf' > 1 ? 1 : 0, '';
echo 'info' > 1 ? 1 : 0, '';
echo 'inf at begin' > 1 ? 1 : 0, '';
echo (double)'somestring', '';
echo (double)'inf', '';
echo (double)'inf at begin', '';
?>
Expected results are:
0
0
0
0
0
0
0
But real results are:
0
0
1
1
0
INF
INF
Saludos
Àngel
--
Edit this bug report at http://bugs.php.net/?id=22173&edit=1
#20242 [Ver->WFx]: Method call infront of class definition
ID: 20242
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Wont fix
Bug Type:Zend Engine 2 problem
PHP Version: 4CVS-2002-11-04
New Comment:
I'll make it a no fix since the last discussions with
Zeev and Andi suggest so.
Previous Comments:
[2003-02-15 09:43:25] [EMAIL PROTECTED]
yes this works with ZE1 completely, but still fails with ZE2...
any news on this? sorry if this isnt the rite place... its just been
awhile since the last comment.
[2002-11-04 10:59:34] [EMAIL PROTECTED]
This is indeed a ZE2 bug. It appears that unlike ZE1, ZE2 does not
allow the class defenition to be made AFTER the calls to the class are
made.
This of course is not a good way to do things, class defenitions should
occur before the class is being used. However, since this worked in
ZE1, it probably should work in ZE2 as well.
[2002-11-04 06:45:44] [EMAIL PROTECTED]
Ups i rechecked it and now it works for ZE 1.3 maybe i
missconfigured the test for ZE1. But it still fails for ZE2. I guess i
should commit the test then.
[2002-11-04 06:25:39] [EMAIL PROTECTED]
Huh? It just works for me.
Hmm I'm rather interested in what causes it to fail in your
environment.
[2002-11-04 05:17:21] [EMAIL PROTECTED]
While you can call functions in front or after current code you cannot
do so with classes. As this is documented nowhere this is an error with
both ZE1 and ZE2.
Following .phpt file:
--TEST--
Method call infront of class definition
--FILE--
show_method();
class test {
function show_static() {
echo "static\n";
}
function show_method() {
echo "method\n";
}
}
?>
--EXPECT--
static
method
=EOF
Produces following .out
Fatal error: Class 'test' not found in
/usr/src/php4-HEAD/tests/classes/classes001.php on line 3
/usr/src/php4-HEAD/tests/classes/classes001.php(3) : Fatal error
- Class 'test' not found
=EOF
--
Edit this bug report at http://bugs.php.net/?id=20242&edit=1
#21912 [Ver]: getimagesize() on remote images fails sometimes..
ID: 21912
Updated by: [EMAIL PROTECTED]
Reported By: tozz at kijkt dot tv
Status: Verified
Bug Type: GetImageSize related
Operating System: Linux
PHP Version: 4.3.1-dev
New Comment:
To :
The difference is that we have a new streams abstraction
layer which allows GetImageSize() to work which whatever
can be treated as a file.
To :
That was what i expected. And it means there is a problem
with the streams stuff.
Previous Comments:
[2003-02-17 17:37:35] michael dot mauch at gmx dot de
Yes, it's the same here - on the local servers it works with both
images, but it doesn't work with the 00645.jpg when I put it on another
remote server.
When I change line 387 of ext/standard/image.c:
if ((marker = php_stream_getc(stream)) == EOF)
into
marker = php_stream_getc(stream);
fprintf(stderr,"%0x ",marker);
if (marker == EOF)
I see
e0 ff ed ff ee ff db ff c0
when the image is served from localhost and only
e0 ff ed 68
or
e0 ff ed 64
when fetching from the remote servers. That looks strange, but I'm
afraid I don't understand what's going on here.
[2003-02-08 05:41:17] [EMAIL PROTECTED]
I suppose ther is another problem :-)
When i download the image and put it on one of my local servers it
works:
[marcus@zaphod php4-HEAD]$ php -r 'print_r(getimagesize($argv[1]));' --
http://zaphod.boerger.de/php/ext/exif/test/bug21912.jpg
Array
(
[0] => 389
[1] => 500
[2] => 2
[3] => width="389" height="500"
[bits] => 8
[channels] => 3
[mime] => image/jpeg
)
[marcus@zaphod php4-HEAD]$ php -r 'var_dump(getimagesize($argv[1]));'
-- http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg
bool(false)
[2003-01-28 13:52:36] tozz at kijkt dot tv
Yes, it has indeed something to do with the image. If I take another
image it works fine! But there must be some difference in the PHP
versions since the 2nd pictures only works with PHP 4.1.2, and not with
the latest PHP version.
[2003-01-28 13:26:00] michael dot mauch at gmx dot de
php -r '$size =
getimagesize("http://s005.pictura-dp.nl/foto/500px/GAM_908/08841.jpg";);
print_r($size); echo "\n";'
works without problems here (PHP 4.3.0), while
php -r '$size =
getimagesize("http://s005.pictura-dp.nl/foto/500px/GAM_017/00645.jpg";);
print_r($size); echo "\n";'
prints nothing. ImageMagick's "identify" sees some strange ipct data in
the second image; probably these make getimagesize() misbehave.
[2003-01-27 17:25:35] [EMAIL PROTECTED]
I can reproduce this with latest stable CVS (4.3.1-dev)
It does work if the image is local..but not if it's remote.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21912
--
Edit this bug report at http://bugs.php.net/?id=21912&edit=1
#21743 [Asn->Fbk]: Driver initialization failed for handler: db3 (and db2)
ID: 21743 Updated by: [EMAIL PROTECTED] Reported By: priyadi at priyadi dot net -Status: Assigned +Status: Feedback Bug Type: DBM/DBA related Operating System: RedHat Linux 7.2 PHP Version: 4.3.0 Assigned To: helly New Comment: To priyadi: - (1) strange, maybe you can send me a strace outut but not on the list to [EMAIL PROTECTED] is enough. - (4) if the file uses another db layout (e.g. different major release) you will have to updragde the file. But you should have received an errormessage which informs about that. To rmallet: This is intereseting. I suspect more a problem with the way php locks the file since we do not use the locking facilities of the library. So the output of strace would help, again to [EMAIL PROTECTED] is enough. Previous Comments: [2003-02-21 13:01:37] rmallett at ccs dot carleton dot ca I encountered the same problem on a Sun Solaris 8 system running apache-1.3.27 and with php 4.3.0 installed as an apache module with dba enabled and db-4.1.25 available as db3, and adding the "-" to the mode flag (c or n) as per your suggestion ([EMAIL PROTECTED]) fixed the problem so it looks like the theory that its a locking problem is right. Anything I should try to help you to fix the problem? I was using the simple example from the PHP manual for testing BTW; that is, which gives the "Driver initialization failed ..." but which works with "n-". [2003-02-06 09:29:39] priyadi at priyadi dot net Hello, sorry for not responding for so long. I have another observation to this elusive problem. - It fails when using mode 'c' but the file doesn't exist already - It succeeds when using mode 'n' and the file doesn't already exist - It succeeds when using mode 'c' and the file exists and it is a valid db3 btree - It fails when using mode 'c' and the file exists but it is not a valid db3 btree Regarding db4 version, I lost access to the system but I think it is version 4.0.14. [2003-01-31 01:28:04] [EMAIL PROTECTED] Please update: ext/dba/config.m4 This fixes some problems when linking against a specific library version. If you do not use your systems default db library you must not include ndbm support since that is based on db1 which in turn is db-1.85 or based on db-x where x is 1.85 or x >= 2. I tried the following: - db-3.2 (not shared) and it works. - db-4.1.25 (shared/not shared) and it works. - db-3.3 from system rpm (not shared) and it works. - db-3.3 from source (shared) and it works So i will ask sleepycat for known problems and maybe disable shared dba in case of db-3.2. I missed to answer your question: db libraries *can* do file locking but we tell the library not to do so and use our own locking. To unalize your db4 problems: What extact version are you using (ldd) and which config (but ldd should be enough). [2003-01-30 11:38:18] priyadi at priyadi dot net I also encountered segfaults with db4 compiled with --with-db3=dir but not with db3 supplied by redhat. [2003-01-29 18:59:10] [EMAIL PROTECTED] Called my contact at Berkeley and got the link to the 3.2 version. Now i am able to reproduce a segfault...I'll look into deeper ASAP The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21743 -- Edit this bug report at http://bugs.php.net/?id=21743&edit=1
#21676 [NoF->Csd]: GetImageSize nolonger works
ID: 21676 Updated by: [EMAIL PROTECTED] Reported By: moderator at blackpeeps dot com -Status: No Feedback +Status: Closed Bug Type: GetImageSize related Operating System: RAQ4-Latest Patches/Apache 1.3.2 PHP Version: 4.3.0 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. This one has been fixed by fixing a streams issue. Previous Comments: [2003-01-31 13:52:04] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-01-16 13:47:43] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip I cannot replicate the described bug using latest snapshot. If you still experience the problem try using the bundled GD library. [2003-01-16 13:34:50] moderator at blackpeeps dot com This image returns null information on GetImageSize: http://www.blackpeeps.com/IV/ecnirp/img3d6ea40af403a.jpg This image does return correct Width and Height info: http://www.blackpeeps.com/IV/ecnirp/img3e124d90c8123.jpg I have even tried downloading the first and uploading back to server to make sure there is not a Binary file transfer issue. No luck. Here is a file that my Thumbnail script is not creating a thumbnail for. Well, actually, it creates a Blacked out thumbnail. The script uses ( GetImgageSize , imagecreatetruecolor, and ImageCreateFromJPEG ) http://www.blackpeeps.com/IV/ecnirp/img3cae54c4a3771.jpg [2003-01-16 13:32:53] moderator at blackpeeps dot com This image returns null information on GetImageSize: http://www.blackpeeps.com/IV/ecnirp/img3d6ea40af403a.jpg This image does return correct Width and Height info: http://www.blackpeeps.com/IV/ecnirp/img3e124d90c8123.jpg";; I have even tried downloading the first and uploading back to server to make sure there is not a Binary file transfer issue. No luck. Here is a file that my Thumbnail script is not creating a thumbnail for. Well, actually, it creates a Blacked out thumbnail. The script uses ( GetImgageSize , imagecreatetruecolor, and ImageCreateFromJPEG ) http://www.blackpeeps.com/IV/ecnirp/img3cae54c4a3771.jpg [2003-01-16 12:51:12] [EMAIL PROTECTED] GetImageSize is not related to GD in anyway. Please provide a sample image, which could be used to duplicate the problem you describe. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21676 -- Edit this bug report at http://bugs.php.net/?id=21676&edit=1
#16190 [Ver]: DBM Support on Windows truncates values
ID: 16190
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Verified
Bug Type: DBM/DBA related
Operating System: Windows 2000
PHP Version: 4.3.0-dev
New Comment:
[marcus@zaphod php4-HEAD]$ php -r
'ini_set("magic_quotes_runtime",1);$db=dbmopen("db","n");dbmreplace($db,"7","alpha");var_dump(dbmfetch($db,"7"));dbmclose($db);'
string(5) "alpha"
My windowsXP reports:
string(6) "lpha\0"
that means the original length of the windows result is 5
"lpha" plus one zero byte.
that implies the fetch function starts reading after 'a' or
skips 'a' on windows.
the only thing i can think of is fgets() returns the wrong
filepointer on windows or read() starts reading at current
offset +1. Maybe this is because we are mixing fgets with read perhaps
we should use fgets twice.
Previous Comments:
[2002-08-17 00:51:54] [EMAIL PROTECTED]
okay, we *thought* we'd fixed it ... sorry ...
[2002-08-14 18:00:45] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab
the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-08-12 23:47:55] [EMAIL PROTECTED]
Dup of 18746... yes I know this came first, but the other one has a
shorter example, and a few more comments.
[2002-08-05 18:25:38] [EMAIL PROTECTED]
See my bugreport 18746 for a shorter example.
[2002-07-06 12:52:21] [EMAIL PROTECTED]
Also a problem on Windows 98 and PHP 4.2.0
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16190
--
Edit this bug report at http://bugs.php.net/?id=16190&edit=1
#18746 [Csd]: DBM query cuts string
ID: 18746 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: DBM/DBA related -Operating System: Windows 2000 +Operating System: Windows PHP Version: 4.2.2 -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. See bug #16190 for details Previous Comments: [2002-08-17 00:54:35] [EMAIL PROTECTED] Sorry, this appeared fixed on first testing but actually isn't. Keeping this one closed against the duplicate (re-opened) bug #16190. [2002-08-13 00:10:42] [EMAIL PROTECTED] This bug has been fixed in CVS. You can grab a snapshot of the CVS version at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites. Thank you for the report, and for helping us make PHP better. [2002-08-12 23:46:23] [EMAIL PROTECTED] Can be reproduced in CVS on Win2k [2002-08-05 18:31:51] [EMAIL PROTECTED] (1) Seems to be very similar to bugreport 16190 (2) Truncation looks dependent on key string length [2002-08-05 15:51:28] [EMAIL PROTECTED] I forgot to tell that I'm using Windows 2000 Professional The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18746 -- Edit this bug report at http://bugs.php.net/?id=18746&edit=1
#16190 [Ver->Csd]: DBM Support on Windows truncates values
ID: 16190
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Closed
Bug Type: DBM/DBA related
-Operating System: Windows 2000
+Operating System: Windows
PHP Version: 4.3.0-dev
-Assigned To:
+Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
My suggestion turned out to be the solution to this.
Previous Comments:
[2002-11-12 22:11:58] [EMAIL PROTECTED]
[marcus@zaphod php4-HEAD]$ php -r
'ini_set("magic_quotes_runtime",1);$db=dbmopen("db","n");dbmreplace($db,"7","alpha");var_dump(dbmfetch($db,"7"));dbmclose($db);'
string(5) "alpha"
My windowsXP reports:
string(6) "lpha\0"
that means the original length of the windows result is 5
"lpha" plus one zero byte.
that implies the fetch function starts reading after 'a' or
skips 'a' on windows.
the only thing i can think of is fgets() returns the wrong
filepointer on windows or read() starts reading at current
offset +1. Maybe this is because we are mixing fgets with read perhaps
we should use fgets twice.
[2002-08-17 00:51:54] [EMAIL PROTECTED]
okay, we *thought* we'd fixed it ... sorry ...
[2002-08-14 18:00:45] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab
the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2002-08-12 23:47:55] [EMAIL PROTECTED]
Dup of 18746... yes I know this came first, but the other one has a
shorter example, and a few more comments.
[2002-08-05 18:25:38] [EMAIL PROTECTED]
See my bugreport 18746 for a shorter example.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/16190
--
Edit this bug report at http://bugs.php.net/?id=16190&edit=1
#20564 [Opn->Csd]: ext/dba/dba_db3.c requires patch to build against DB 4.1.24
ID: 20564
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Compile Failure
Operating System: Any
PHP Version: 4.2.3
-Assigned To:
+Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
I will make a db4 module and try to check the versions in all BerkleyDB
modules.
Previous Comments:
[2002-11-22 03:34:57] [EMAIL PROTECTED]
ext/dba/dba_db3.c builds fine against DB 4.0.x, but
requires a little patch to build against DB 4.1.X:
--- php-4.2.3/ext/dba/dba_db3.c.origThu Apr 18 14:31:19 2002
+++ php-4.2.3/ext/dba/dba_db3.c Fri Nov 22 10:30:24 2002
@@ -74,7 +74,11 @@
}
if (db_create(&dbp, NULL, 0) == 0 &&
+#if (DB_VERSION_MAJOR == 4 && DB_VERSION_MINOR >= 1)
+ dbp->open(dbp, 0, info->path, NULL, type, gmode, filemode)
== 0) {
+#else
dbp->open(dbp, info->path, NULL, type, gmode, filemode) ==
0) {
+#endif
dba_db3_data *data;
data = malloc(sizeof(*data));
--
Edit this bug report at http://bugs.php.net/?id=20564&edit=1
#20479 [Opn->Csd]: handler 'ob_gzhandler' cannot be used twice in Unknown on line 0
ID: 20479
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Output Control
Operating System: Linux 2.4.18
PHP Version: 4.3.0RC1
New Comment:
This check was added in 4.3.0dev some time ago to prevent
missconfiguration. There simply was no check in earlier versions.
Previous Comments:
[2002-11-18 11:09:08] [EMAIL PROTECTED]
Humm, indeed, output_buffering was set to 4096, now it works.
How this case was handled in php 4.2.3 ?
[2002-11-18 11:01:14] [EMAIL PROTECTED]
You propably have set it in php.ini too?
[2002-11-18 07:31:42] [EMAIL PROTECTED]
Sorry, the complete error message is :
Warning: (null)() [ref.outcontrol]: output handler 'ob_gzhandler'
cannot be used twice in Unknown on line 0
[2002-11-18 07:30:51] [EMAIL PROTECTED]
Hi,
When using :
ob_start("ob_gzhandler") in my code, I obtain the following error :
handler 'ob_gzhandler' cannot be used twice in Unknown on line 0
No problem so far with PHP 4.2.3
Regards,
Jocelyn
--
Edit this bug report at http://bugs.php.net/?id=20479&edit=1
#20433 [Opn]: Unaligned access error messages at runtime
ID: 20433 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Compile Warning Operating System: Tru64, NetBSD(Alpha platform) PHP Version: 4.3.0-RC1 -Assigned To: +Assigned To: helly New Comment: The problem is OnUpdateInt which will result in an error on 64bit systems. Compiling and testing now. Previous Comments: [2002-11-16 10:47:30] [EMAIL PROTECTED] Verified on NetBSD/Alpha. [2002-11-15 05:34:33] [EMAIL PROTECTED] Verified with 4.3.0RC1 [2002-11-14 15:34:13] [EMAIL PROTECTED] When testing cli/cgi, unaligned access messages are displayed. Following modifications fixes problem. in main/php_globals.h int log_errors_max_len changed to long log_errors_max_len in ext/standard/file.h int default_socket_timeout int auto_detect_line_endings changed to long default_socket_timeout long auto_detect_line_endings -- Edit this bug report at http://bugs.php.net/?id=20433&edit=1
#20433 [Opn->Csd]: Unaligned access error messages at runtime
ID: 20433 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Compile Warning Operating System: Tru64, NetBSD(Alpha platform) PHP Version: 4.3.0-RC1 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-11-30 10:35:24] [EMAIL PROTECTED] The problem is OnUpdateInt which will result in an error on 64bit systems. Compiling and testing now. [2002-11-16 10:47:30] [EMAIL PROTECTED] Verified on NetBSD/Alpha. [2002-11-15 05:34:33] [EMAIL PROTECTED] Verified with 4.3.0RC1 [2002-11-14 15:34:13] [EMAIL PROTECTED] When testing cli/cgi, unaligned access messages are displayed. Following modifications fixes problem. in main/php_globals.h int log_errors_max_len changed to long log_errors_max_len in ext/standard/file.h int default_socket_timeout int auto_detect_line_endings changed to long default_socket_timeout long auto_detect_line_endings -- Edit this bug report at http://bugs.php.net/?id=20433&edit=1
#20156 [Opn->Csd]: main/internal_functions.c
ID: 20156 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 4CVS-2002-10-29 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-10-30 01:35:58] [EMAIL PROTECTED] at least it let you compile it (after disabling xmlrpc-support bug #20155). [2002-10-30 00:39:51] [EMAIL PROTECTED] Hmm, wouldn't be that easy to fix unless somebody comes up with some good autoconf magic. For now you can compile with --disable-overload AFAIK. Derick [2002-10-29 17:11:42] [EMAIL PROTECTED] gcc -Imain/ -I/home/weigon/projects/in-cvs/php4/main/ -DPHP_ATOM_INC -I/home/weigon/projects/in-cvs/php4/include -I/home/weigon/projects/in-cvs/php4/main -I/home/weigon/projects/in-cvs/php4 -I/home/weigon/projects/in-cvs/php4/Zend -I/usr/include/freetype2 -I/usr//include -I/home/weigon/projects/in-cvs/php4/TSRM -g -O2 -c main/internal_functions.c -o main/internal_functions.o && echo > main/internal_functions.lo main/internal_functions.c:61: `phpext_overload_ptr' undeclared here (not in a function) main/internal_functions.c:61: initializer element is not constant main/internal_functions.c:61: (near initialization for `php_builtin_extensions[7]') phpext_overload_ptr isn't defined with ZendEngine2 enabled. -- Edit this bug report at http://bugs.php.net/?id=20156&edit=1
#20858 [Opn]: dba_open create always a lock file
ID: 20858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: This was intended and the documentation is bad on this. 'l' and 'd' are only to force one of the two. Maybe i'll add a new modifier to skip locking... Previous Comments: [2002-12-06 08:57:30] [EMAIL PROTECTED] Already reported in comment on #20828. I make a separate bug report since it's another bug. Opening a db with create a lock file (note that the "l" attribute is not used) This script will fail on a ro directory! -- Edit this bug report at http://bugs.php.net/?id=20858&edit=1
#20858 [Asn->Dup]: dba_open create always a lock file
ID: 20858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Duplicate Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: I added '-' modifier for that now. And marked this one duplicate. See bug 20828 for more. Previous Comments: [2002-12-07 09:11:03] [EMAIL PROTECTED] This was intended and the documentation is bad on this. 'l' and 'd' are only to force one of the two. Maybe i'll add a new modifier to skip locking... [2002-12-06 08:57:30] [EMAIL PROTECTED] Already reported in comment on #20828. I make a separate bug report since it's another bug. Opening a db with create a lock file (note that the "l" attribute is not used) This script will fail on a ro directory! -- Edit this bug report at http://bugs.php.net/?id=20858&edit=1
#20828 [Opn]: dba_open hang on nfs files
ID: 20828 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: It is important to keep the .lck file - so that is no problem. Also database access needs to be locked - so generally locking is wanted and not having it was an error in older dba versions. I added modifier '-' to disable/skip/ignore locking (or whatever to call it). Previous Comments: [2002-12-05 09:09:50] [EMAIL PROTECTED] dba_open hang when trying to open a file located on a nfs server : test script : with file "E.db" on a nfs server : Block with file "E.db" on a local filesystem : Ok In both case, E.db.lck is created (Hey! i've used "r" not "rl" ???) and by the way, not removed. Seems the new locking scheme start by itself, doesn't cleanup on exit and finally hang on nfs. -- Edit this bug report at http://bugs.php.net/?id=20828&edit=1
#20828 [Opn->Csd]: dba_open hang on nfs files
ID: 20828 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: DBM/DBA related Operating System: Linux 2.2.16 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. The default is now locking on the database file. This is done by GDBM handler automatically and maybe other future handlers will do also. So now all handlers behave the same way when no further modifier is used. Previous Comments: [2002-12-09 12:09:57] [EMAIL PROTECTED] It is important to keep the .lck file - so that is no problem. Also database access needs to be locked - so generally locking is wanted and not having it was an error in older dba versions. I added modifier '-' to disable/skip/ignore locking (or whatever to call it). [2002-12-05 09:09:50] [EMAIL PROTECTED] dba_open hang when trying to open a file located on a nfs server : test script : with file "E.db" on a nfs server : Block with file "E.db" on a local filesystem : Ok In both case, E.db.lck is created (Hey! i've used "r" not "rl" ???) and by the way, not removed. Seems the new locking scheme start by itself, doesn't cleanup on exit and finally hang on nfs. -- Edit this bug report at http://bugs.php.net/?id=20828&edit=1
#21010 [Opn]: typo in tag name and some identifiers
ID: 21010
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Graphics related
Operating System: FreeBSD 4.6-RELEASE
PHP Version: 4CVS-2002-12-14 (stable)
-Assigned To:
+Assigned To: helly
New Comment:
You're correct this is about the manufacturer.
Thanks for noticing :-)
Previous Comments:
[2002-12-14 08:14:48] [EMAIL PROTECTED]
typo in tag name and some identifiers
in ext/exif/exif.c:
marker note -> maker note
Reference:
Digital Still Camera Image File Format Standard
(Exchangeable image file format for Digital Still Cameras: Exif)
Version 2.1
June 12, 1998
Japan Electronic Industry Development Association(JEIDA)
p40
MakerNote
A tag for manufacturers of Exif writers to record any desired
information. The contents are up to the manufacturer.
Tag = 37500 (927C.H)
Type = UNDEFINED
Count = Any
Default = none
--- exif.c.orig Sat Dec 14 22:32:49 2002
+++ exif.c Sat Dec 14 22:54:22 2002
@@ -427,7 +427,7 @@
/* 0x920B - 0x920D */
/* 0x9211 - 0x9216 */
#define TAG_SUBJECT_AREA0x9214
-#define TAG_MARKER_NOTE 0x927C
+#define TAG_MAKER_NOTE 0x927C
#define TAG_USERCOMMENT 0x9286
#define TAG_SUB_SEC_TIME0x9290
#define TAG_SUB_SEC_TIME_ORIGINAL 0x9291
@@ -917,9 +917,9 @@
int offset;
mn_byte_order_t byte_order;
mn_offset_mode_t offset_mode;
-} marker_note_type;
+} maker_note_type;
-static const marker_note_type marker_note_array[] = {
+static const maker_note_type maker_note_array[] = {
{ tag_table_VND_CANON, "Canon", NULL, NULL,
0, 0, MN_ORDER_INTEL,MN_OFFSET_GUESS},
/* { tag_table_VND_CANON, "Canon", NULL, NULL,
0, 0, MN_ORDER_NORMAL, MN_OFFSET_NORMAL},*/
{ tag_table_VND_CASIO, "CASIO", NULL, NULL,
0, 0, MN_ORDER_MOTOROLA, MN_OFFSET_NORMAL},
@@ -1253,7 +1253,7 @@
#define SECTION_INTEROP 10
#define SECTION_APP12 11
#define SECTION_WINXP 12
-#define SECTION_MARKERNOTE 13
+#define SECTION_MAKERNOTE 13
#define SECTION_COUNT 14
#define FOUND_FILE (1<make?marker_note->make:"",
marker_note->model?marker_note->model:"");*/
- if (marker_note->make && (!ImageInfo->make ||
strcmp(marker_note->make, ImageInfo->make)))
+ /*exif_error_docref(NULL TSRMLS_CC, ImageInfo, E_NOTICE, "check
(%s,%s)", maker_note->make?maker_note->make:"",
maker_note->model?maker_note->model:"");*/
+ if (maker_note->make && (!ImageInfo->make ||
strcmp(maker_note->make, ImageInfo->make)))
continue;
- if (marker_note->model && (!ImageInfo->model ||
strcmp(marker_note->model, ImageInfo->model)))
+ if (maker_note->model && (!ImageInfo->model ||
strcmp(maker_note->model, ImageInfo->model)))
continue;
- if (marker_note->id_string && strncmp(marker_note->id_string,
value_ptr, marker_note->id_string_len))
+ if (maker_note->id_string && strncmp(maker_note->id_string,
value_ptr, maker_note->id_string_len))
continue;
break;
}
- dir_start = value_ptr + marker_note->offset;
+ dir_start = value_ptr + maker_note->offset;
#ifdef EXIF_DEBUG
- exif_error_docref(NULL TSRMLS_CC, ImageInfo, E_NOTICE, "process %s
@x%04X + 0x%04X=%d: %s", exif_get_sectionname(section_index),
(int)dir_start-(int)offset_base+marker_note->offset+displacement,
value_len, value_len, exif_char_dump(value_ptr, value_len,
(int)dir_start-(int)offset_base+marker_note->offset+displacement));
+ exif_error_docref(NULL TSRMLS_CC, ImageInfo, E_NOTICE, "process %s
@x%04X + 0x%04X=%d: %s", exif_get_sectionname(section_index),
(int)dir_start-(int)offset_base+maker_note->offset+displacement,
value_len, value_len, exif_char_dump(value_ptr, value_len,
(int)dir_start-(int)offset_base+maker_note->offset+displacement));
#endif
- ImageInfo->sections_found |= FOUND_MARKERNOTE;
+ ImageInfo->sections_found |= FOUND_MAKERNOTE;
old_motorola_intel = ImageInfo->motorola_intel;
- switch (marker_note->byte_order) {
+ switch (maker_note->byte_order) {
case MN_ORDER_INTEL:
ImageInfo->motorola_intel = 0;
break;
@@ -
#21010 [Opn->Csd]: typo in tag name and some identifiers
ID: 21010
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: *Graphics related
Operating System: FreeBSD 4.6-RELEASE
PHP Version: 4CVS-2002-12-14 (stable)
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2002-12-14 11:52:40] [EMAIL PROTECTED]
You're correct this is about the manufacturer.
Thanks for noticing :-)
[2002-12-14 08:14:48] [EMAIL PROTECTED]
typo in tag name and some identifiers
in ext/exif/exif.c:
marker note -> maker note
Reference:
Digital Still Camera Image File Format Standard
(Exchangeable image file format for Digital Still Cameras: Exif)
Version 2.1
June 12, 1998
Japan Electronic Industry Development Association(JEIDA)
p40
MakerNote
A tag for manufacturers of Exif writers to record any desired
information. The contents are up to the manufacturer.
Tag = 37500 (927C.H)
Type = UNDEFINED
Count = Any
Default = none
--- exif.c.orig Sat Dec 14 22:32:49 2002
+++ exif.c Sat Dec 14 22:54:22 2002
@@ -427,7 +427,7 @@
/* 0x920B - 0x920D */
/* 0x9211 - 0x9216 */
#define TAG_SUBJECT_AREA0x9214
-#define TAG_MARKER_NOTE 0x927C
+#define TAG_MAKER_NOTE 0x927C
#define TAG_USERCOMMENT 0x9286
#define TAG_SUB_SEC_TIME0x9290
#define TAG_SUB_SEC_TIME_ORIGINAL 0x9291
@@ -917,9 +917,9 @@
int offset;
mn_byte_order_t byte_order;
mn_offset_mode_t offset_mode;
-} marker_note_type;
+} maker_note_type;
-static const marker_note_type marker_note_array[] = {
+static const maker_note_type maker_note_array[] = {
{ tag_table_VND_CANON, "Canon", NULL, NULL,
0, 0, MN_ORDER_INTEL,MN_OFFSET_GUESS},
/* { tag_table_VND_CANON, "Canon", NULL, NULL,
0, 0, MN_ORDER_NORMAL, MN_OFFSET_NORMAL},*/
{ tag_table_VND_CASIO, "CASIO", NULL, NULL,
0, 0, MN_ORDER_MOTOROLA, MN_OFFSET_NORMAL},
@@ -1253,7 +1253,7 @@
#define SECTION_INTEROP 10
#define SECTION_APP12 11
#define SECTION_WINXP 12
-#define SECTION_MARKERNOTE 13
+#define SECTION_MAKERNOTE 13
#define SECTION_COUNT 14
#define FOUND_FILE (1<make?marker_note->make:"",
marker_note->model?marker_note->model:"");*/
- if (marker_note->make && (!ImageInfo->make ||
strcmp(marker_note->make, ImageInfo->make)))
+ /*exif_error_docref(NULL TSRMLS_CC, ImageInfo, E_NOTICE, "check
(%s,%s)", maker_note->make?maker_note->make:"",
maker_note->model?maker_note->model:"");*/
+ if (maker_note->make && (!ImageInfo->make ||
strcmp(maker_note->make, ImageInfo->make)))
continue;
- if (marker_note->model && (!ImageInfo->model ||
strcmp(marker_note->model, ImageInfo->model)))
+ if (maker_note->model && (!ImageInfo->model ||
strcmp(maker_note->model, ImageInfo->model)))
continue;
- if (marker_note->id_string && strncmp(marker_note->id_string,
value_ptr, marker_note->id_string_len))
+ if (maker_note->id_string && strncmp(maker_note->id_string,
value_ptr, maker_note->id_string_len))
continue;
break;
}
- dir_start = value_ptr + marker_note->offset;
+ dir_start = value_ptr + maker_note->offset;
#ifdef EXIF_DEBUG
- exif_error_docref(NULL TSRMLS_CC, ImageInfo, E_NOTICE, "process %s
@x%04X + 0x%04X=%d: %s", exif_get_sectionname(section_index),
(int)dir_start-(int)offset_base+marker_note->offset+displacement,
value_len, value_len, exif_char_dump(value_ptr, value_len,
(int)dir_start-(int)offset_base+marker_note->offset+displacement));
+ exif_error_docref(NULL TSRMLS_CC, ImageInfo, E_NOTICE, "process %s
@x%04X + 0x%04X=%d: %s", exif_get_sectionname(section_index),
#20755 [Fbk->Csd]: exif relocation error
ID: 20755 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: mbstring related Operating System: Mandrake 9.0 PHP Version: 4.3.0RC2 Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-12-14 23:51:57] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-03 07:12:45] [EMAIL PROTECTED] readline still wasn't found so I had to disable it. I was not able to build zlib as a shared module. Here's my new configure line: './configure' '--prefix=/usr/local/php4' '--sysconfdir=/etc' '--with-apxs2=/usr/sbin/apxs' '--with-layout=GNU' '--with-config-file-path=/etc/httpd/conf' '--with-openssl=shared,/usr' '--enable-magic-quotes' '--disable-rpath' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--enable-inline-optimization' '--with-zlib' '--without-aspell' '--with-bz2=shared,/usr' '--enable-calendar=shared' '--with-jpeg-dir=shared,/usr' '--with-tiff-dir=shared,/usr' '--with-curl=shared,/usr' '--enable-dba=shared,/usr' '--with-gdbm=shared,/usr' '--with-db3=shared,/usr' '--with-db4=shared,/usr' '--with-cdb=shared,/usr' '--with-flatfile=shared' '--enable-dbx=shared,/usr' '--enable-dio=shared,/usr' '--with-dom=shared,/usr' '--with-dom-xslt=shared,/usr' '--with-dom-exslt=shared,/usr' '--enable-ftp=shared' '--with-gd=shared' '--with-jpeg-dir=shared,/usr' '--with-png-dir=shared,/usr' '--with-ttf=shared,/usr' '--with-freetype-dir=shared,/usr' '--with-t1lib=shared,/usr' '--enable-gd-native-ttf' '--with-gettext=shared,/usr' '--with-gmp=shared,/usr' '--with-imap=shared,/usr' '--with-imap-ssl=shared,/usr' '--with-ldap=shared,/usr' '--with-mcrypt=shared,/usr' '--with-mhash=shared,/usr' '--enable-mime_magic=shared,/usr' '--with-ming=shared,/usr' '--with-mysql=shared,/usr' '--with-unixODBC=shared,/usr' '--with-jpeg-dir=shared,/usr' '--with-png-dir=shared,/usr' '--with-tiff-dir=shared,/usr' '--with-pgsql=shared,/usr' '--with-pspell=shared,/usr' '--with-recode=shared,/usr' '--with-snmp=shared,/usr' '--enable-ucd-snmp-hack' '--enable-sockets=shared' '--with-regex=system' '--enable-sysvmsg=shared' '--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-wddx=shared' '--with-xmlrpc=shared,/usr' '--enable-xslt=shared,/usr' '--with-xslt-sablot=shared,/usr' '--enable-yp=shared' '--with-zip=shared,/usr' '--with-xpm-dir=/usr/X11R6/lib/' '--enable-mbregex=shared' '--enable-overload=shared' '--enable-tokenizer=shared' '--enable-ctype=shared' '--enable-mime-magic=shared' '--enable-shared' I ran make test and let it send the test by e-mail. [2002-12-01 22:10:24] [EMAIL PROTECTED] What a fast reply! I have fixed my configure line now, but when I tried to enable readline support I got: checking for readline in -lreadline... no configure: error: readline library not found Gotta continue with this tomorrow. [2002-12-01 21:33:32] [EMAIL PROTECTED] And btw. you shouldn't try outsmarting the configure with all those LIBS/CFLAGS you're defining before running configure.. And read the 'configure --help' sometimes. Some configuration options DO NOT SUPPORT 'shared' at all. (like --with-xpm-dir) Building anything as shared is pretty much asking for trouble, just build what you need and don't use the shared modules. [2002-12-01 21:31:07] [EMAIL PROTECTED] If you compile mbstring as static module, you can workaround this error. It's not very good idea to enable it anyway.. For the mbstring authors: You should decide whether or not to allow external usage of these functions (ie. in other extensions) or disable the building of this extension as shared altogether.. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20755 -- Edit this bug report at http://bugs.php.net/?id=20755&edit=1
#21139 [NEW]: zlib.output_compression + windows failure
From: [EMAIL PROTECTED] Operating system: Windows PHP version: 4.3.0RC4 PHP Bug Type: Output Control Bug description: zlib.output_compression + windows failure I have just installed latest php 4.3 on linux and windows. I use the same directory and therefore .htaccess files for apache/mod_php on both platforms. When i enable enable output compression with ini setting php_value zlib.output_compression On in .htaccess the linux version works as expected but the windows version fails. Sometimes i receive errors with access violations. Sometimes i can downlowd the result but when rename the resulting file to .gz i can open it and as you might expect it contains the correct result. And sometime i see the encoding result presented in the browser and then i cannot save and view it although the gzip header seems correct. marcus -- Edit bug report at http://bugs.php.net/?id=21139&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21139&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21139&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21139&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21139&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21139&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21139&r=support Expected behavior: http://bugs.php.net/fix.php?id=21139&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21139&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21139&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21139&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21139&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21139&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21139&r=isapi
#21139 [Opn->Ctl]: zlib.output_compression + windows failure
ID: 21139 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Critical Bug Type: Output Control Operating System: Windows PHP Version: 4.3.0RC4 Previous Comments: [2002-12-21 17:48:30] [EMAIL PROTECTED] I have just installed latest php 4.3 on linux and windows. I use the same directory and therefore .htaccess files for apache/mod_php on both platforms. When i enable enable output compression with ini setting php_value zlib.output_compression On in .htaccess the linux version works as expected but the windows version fails. Sometimes i receive errors with access violations. Sometimes i can downlowd the result but when rename the resulting file to .gz i can open it and as you might expect it contains the correct result. And sometime i see the encoding result presented in the browser and then i cannot save and view it although the gzip header seems correct. marcus -- Edit this bug report at http://bugs.php.net/?id=21139&edit=1
Bug #14994 Updated: Adding TIFF support to GetImageSize
ID: 14994 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type:Feature/Change Request PHP Version: 4.1.1 -Assigned To: +Assigned To: helly New Comment: Included in 4.2 Previous Comments: [2002-03-02 12:30:39] [EMAIL PROTECTED] Next version of read_exif_data will provide the information needed. So i think we can add a constant for TIFF and add support... [2002-01-11 06:07:43] [EMAIL PROTECTED] I know, that Rasmus made the implementation for this function and that he used the header readouts from an imageinfo.c, but I'm missing the ability to identify TIFF images. As i'm not firm with imageheaders, I'd like to ask someone to implement this feature. -- Edit this bug report at http://bugs.php.net/?id=14994&edit=1
Bug #13508 Updated: read exif data not working on large thumbnails
ID: 13508 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Assigned Bug Type: *Graphics related Operating System: Linux PHP Version: 4.0.6 -Assigned To: +Assigned To: helly New Comment: Try with CVS or PHP 4.2 please... Previous Comments: [2002-02-02 06:43:23] [EMAIL PROTECTED] No feedback was provided for this bug, so it is being suspended. If you are able to provide the information that was requested, please do so and change the status of the bug back to "Open". [2002-01-11 17:27:19] [EMAIL PROTECTED] Can you try this with 4.1.1? [2001-10-02 06:54:38] [EMAIL PROTECTED] This (Bug #11784) can't really be classified as Closed, because it still won't enable 'large' thumbnails to be extracted from the EXIF data. My application requires that I extract the actual thumbnail image from the Exif data of the digital image. Will READ-EXIF-DATA be fixed to handle large thumbnails - or just ignore them?? (at least the fix extracts the other data) -- Edit this bug report at http://bugs.php.net/?id=13508&edit=1
#4248 [Opn->Csd]: Unable to run ./configure --with-cdb using cdb v0.75
ID: 4248 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Installation problem Operating System: Solaris 2.6 PHP Version: 4.3.0dev -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. I had no problems with installing CDB 0.75 but had to fix the handler. It should work now. Previous Comments: [2002-09-18 16:00:25] [EMAIL PROTECTED] This still doesn't seem to be corrected in PHP 4.3.0-dev, which makes the --with-cdb option pretty much useless. Could one of the developers maybe look rewriting the PHP code to interface with the CDB 0.75 library? - Colin [2000-04-26 12:14:13] [EMAIL PROTECTED] ./configure checks for cdb_bread when passed --with-cdb. However, the CDB API has changed somewhere between 0.55 (the version that works) and version 0.75 (the version that gave me a couple of hours of headaches ;) ). Enough so that the the check performed by ./configure to see if libcdb.a works now fails. Yay. (note that cdb-0.55 *does* work, with relevant files in the same locations) My full ./configure line: ./configure \ --enable-versioning \ --with-apache=../apache_1.3.12 \ --with-aspell=/usr/local/include/aspell \ --with-ftp \ --with-gd \ --with-jpeg-dir \ --with-mysql \ --with-xml \ --with-zlib \ --with-pdflib \ --with-config-file-path=/usr/local/etc \ --enable-safe-mode \ --enable-track-vars \ --enable-force-cgi-redirect \ --enable-memory-limit \ --enable-sysvsem \ --enable-sysvshm \ --with-gdbm \ --with-db2 \ --with-cdb -- Edit this bug report at http://bugs.php.net/?id=4248&edit=1
#14383 [Asn]: using postgres with DBA causes DBA not to be able to find any keys.
ID: 14383
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Assigned
Bug Type: DBM/DBA related
Operating System: FreeBSD 4.4-STABLE
PHP Version: 4.2.0-dev
Assigned To: yohgaki
New Comment:
For me it works, i think.
Could you please try latest cvs version copy new test below to
ext/pgsql/tests/30_bug14383.phpt and run the following test script
using:
php run-tests.php ext/pgsql
===ext/pgsql/tests/30_bug14383.phpt
--TEST--
Bug 14383
--SKIPIF--
--FILE--
--EXPECTF--
database handler: %s
3NYNYY
Content String 2
Content 2 replaced
Read during write permitted
Content 2 replaced 2nd time
The 6th value
array(3) {
["key number 6"]=>
string(13) "The 6th value"
["key2"]=>
string(27) "Content 2 replaced 2nd time"
["key5"]=>
string(23) "The last content string"
}
===EOF ext/pgsql/tests/30_bug14383.phpt
Previous Comments:
[2001-12-13 04:40:28] [EMAIL PROTECTED]
Thanks a lot.
I'll take a look at source. It could be hard to figure out
what's wrong. Please be patient.
Since I don't use FreeBSD, I might ask something later.
[2001-12-13 03:29:55] [EMAIL PROTECTED]
Hi,
Yes the latest snapshop has the same error.
Again, if I comment out the pg_connect call it
works just fine.
[2001-12-13 03:17:09] [EMAIL PROTECTED]
Ok,
I just tested it with 4.1.0 and I still get the exact same
error, no change.
I'll try to get a snap if I can and try it.
[2001-12-13 02:51:58] [EMAIL PROTECTED]
No, I've not tried it with 4.1.0.
I'm trying to get it or one of the snaps right now and
the servers are slllo...:(
Will report back when I get it tested.
--
GB
[2001-12-13 02:39:11] [EMAIL PROTECTED]
Did you try it with 4.1.0? Do you still have the problem?
If you still have problem, could you try snapshot also?
http://snaps.php.net/
If you still have problem with snapshot, I'll look into what's wrong.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/14383
--
Edit this bug report at http://bugs.php.net/?id=14383&edit=1
Bug #14731 Updated: read_exif_data crash reading specific images
ID: 14731 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Graphics related Operating System: FreeBSD 4.4 PHP Version: 4.1.0 -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. Original version was not really standard complient... Hope i fixed all. But i implemented a test mechanism and it works with all files from exif.org now. Previous Comments: [2002-02-21 04:41:23] [EMAIL PROTECTED] ... camera is Pentax Optio 330 [2002-02-21 04:40:33] [EMAIL PROTECTED] I get the same problem reported here. It doesn't break on all my images. Just certain ones (all taken with the same camera.) Apache logs: FATAL: emalloc(): Unable to allocate -2147483648 bytes System Info: Apache/1.3.22 (Unix) (Red-Hat/Linux) mod_ssl/2.8.5 OpenSSL/0.9.6b DAV/1.0.2 PHP/4.1.1 mod_perl/1.24_01 [2002-02-11 23:01:37] [EMAIL PROTECTED] I had it working ok when reading one file from a DC4800. Tried to open 10 in a row and I got the following error in the apache log file for each file: FATAL: emalloc(): Unable to allocate -2147483648 bytes FreeBSD 4.5, PHP 4.1.1 [2002-01-11 17:43:35] [EMAIL PROTECTED] I've been strugling with this issue for some time, also on FreeBSD 4.4-stable. The bug still exists in CVS as of today. I can also conform that removing TAG_JPEGQUAL and TAG_MACRO fixes the problem. [2001-12-28 07:26:12] [EMAIL PROTECTED] When calling read_exif_data with a picture taken with a Kodak DC240 it causes PHP to crash. (This error is probably related to bug #14026) It seems to be caused to the (mis-)reading of the thumbnail-info from the exif-tag. After changing the ext/exif.c and removing the cases TAG_JPEGQUAL and TAG_MACRO at line 760-779, the read_exif_data runs without any problems - But then (of course) it only read the data about the picture and not the thumbnail. To reproduce call read_exif_data with any photo taken with a Kodak DC240 Examplephoto http://thoestesen.dk/DCP_4030.JPG -- Edit this bug report at http://bugs.php.net/?id=14731&edit=1
Bug #14026 Updated: Apache Crash
ID: 14026 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Graphics related Operating System: Linux 2.4.5 PHP Version: 4.1.1 -Assigned To: +Assigned To: helly New Comment: This bug has been fixed in CVS. This bug has been fixed in CVS. Original version was not really standard complient... Hope i fixed all. But i implemented a test mechanism and it works with all files from exif.org now. Previous Comments: [2002-02-22 13:02:13] [EMAIL PROTECTED] Could you send me an image that has this problem? Or point me at a URL where I can grab one? It should be a simple fix if I can reproduce it locally here. [2002-02-20 21:03:29] [EMAIL PROTECTED] I have a Minolta DiMage7 DC I am getting intermittent problems with FATAL: emalloc(): Unable to allocate -2147483648 bytes read_exif_data will work with most pictures, but sometimes will produce the error. [2001-11-12 05:42:16] [EMAIL PROTECTED] Thx much prompt reply. Tried PHP Version 4.2.0-dev at http://www.aimaker.com/info.php Still got the same error with ricoh.jpg but ok with canon jpg. [2001-11-12 04:59:29] [EMAIL PROTECTED] You might want to try a snapshot from snaps.php.net. AFAIK, this should be fixed. Derick [2001-11-12 04:55:20] [EMAIL PROTECTED] :) php-read_exif-data can read exif from Canon DC jpg file :( php-read_exif-data cannot read exif from Ricoh DC jpg file A server error got is - FATAL: emalloc(): Unable to allocate -2147483648 bytes A example of Ricoh DC jpg at http://www.aimaker.com/ricoh.jpg -- Edit this bug report at http://bugs.php.net/?id=14026&edit=1
Bug #14994 Updated: Adding TIFF support to GetImageSize
ID: 14994 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Analyzed Bug Type:Feature/Change Request PHP Version: 4.1.1 New Comment: Next version of read_exif_data will provide the information needed. So i think we can add a constant for TIFF and add support... Previous Comments: [2002-01-11 06:07:43] [EMAIL PROTECTED] I know, that Rasmus made the implementation for this function and that he used the header readouts from an imageinfo.c, but I'm missing the ability to identify TIFF images. As i'm not firm with imageheaders, I'd like to ask someone to implement this feature. -- Edit this bug report at http://bugs.php.net/?id=14994&edit=1
Bug #15680 Updated: WIll not read this image at all
ID: 15680 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GetImageSize related Operating System: solaris 2.7 PHP Version: 4.1.1 New Comment: Works on winxp/cygwin Previous Comments: [2002-02-22 13:38:49] [EMAIL PROTECTED] getimagesize will not read this image at all where it will be read by a browser just fine: http://www.adultdeal.com/logos/blurr_banner2.gif Thanks -- Edit this bug report at http://bugs.php.net/?id=15680&edit=1
Bug #13213 Updated: Unknown image format
ID: 13213
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Analyzed
Bug Type: GetImageSize related
Operating System: Linux RedHat 7.1
PHP Version: 4.1.1
-Assigned To:
+Assigned To: helly
New Comment:
The current CVS implementation has been improoved on that.
As you can see from exif's debug warnings. photo1 and photo3 are
illegal. An internal section says it is longer than the file :-(
I could implement handling that but it would blow up code.
I will consider the applied patch...
photo1.jpg
GetImageSize [ , , , ]
exif_read_data exif_read_data returned false
Invalid JPEG/TIFF file: 'photo1.jpg'
21
PHP Warning: error reading from file: got=x3648(=13896) !=
itemlen-2=x4EE1(=20193)
photo2.jpg
GetImageSize [ 640, 480, 2, width="640" height="480" ]
exif_read_data exif_read_data returned false
O.K.
22
photo3.jpg
GetImageSize [ , , , ]
exif_read_data exif_read_data returned false
Invalid JPEG/TIFF file: 'photo3.jpg'
23
PHP Warning: error reading from file: got=x1E3D(=7741) !=
itemlen-2=xF698(=63128)
photo4.jpg
GetImageSize [ 640, 480, 2, width="640" height="480" ]
exif_read_data exif_read_data returned false
O.K.
Previous Comments:
[2002-01-22 16:34:48] [EMAIL PROTECTED]
Solution: Read additional bytes to resync on the marker sequence. If
marker length is too short, nothing is lost. If too long, one marker
will be missing. Besides that APPn in $info array will contain
consistent entries and no bogus markers. Uhm, ... and if the JPEG
format follows the spec and contains correct marker lengths, it will
work also ;-)
This patch against 4.1.1 might do the trick:
--- ext/standard/image.c.orig Sat Aug 11 19:03:37 2001
+++ ext/standard/image.cTue Jan 22 22:10:42 2002
@@ -253,12 +253,20 @@
/* {{{ php_next_marker
*/
-static unsigned int php_next_marker(int socketd, FILE *fp, int
issock)
+static unsigned int php_next_marker(int socketd, FILE *fp, int issock,
int isfirst)
/* get next marker byte from file */
{
int c;
- /* get marker byte, swallowing possible padding */
+ if (!isfirst) {
+ /* swallow bytes resulting from short marker length */
+ do {
+ if ((c = FP_FGETC(socketd, fp, issock)) ==
EOF)
+ return M_EOI; /* we hit EOF */
+ } while (c != 0xff);
+ }
+
+ /* get marker byte, swallowing possible 0xff padding */
do {
if ((c = FP_FGETC(socketd, fp, issock)) == EOF)
return M_EOI; /* we hit EOF */
@@ -320,12 +328,14 @@
static struct gfxinfo *php_handle_jpeg (int socketd, FILE *fp, int
issock, pval *info)
{
struct gfxinfo *result = NULL;
+ int isfirst = 1;/* First marker after JPEG sig 'FF D8
FF' */
unsigned int marker;
char tmp[2];
unsigned char a[4];
for (;;) {
- marker = php_next_marker(socketd, fp, issock);
+ marker = php_next_marker(socketd, fp, issock,
isfirst);
+ isfirst = 0;
switch (marker) {
case M_SOF0:
case M_SOF1:
[2002-01-22 13:15:04] [EMAIL PROTECTED]
Offending images contain COM marker with length parameter two bytes
short. This breaks further decoding of JPEG header - GetImageSize()
cannot return useful information.
[2002-01-11 17:09:08] [EMAIL PROTECTED]
I experience the same on 4.1.1
[2002-01-07 10:17:09] [EMAIL PROTECTED]
ID: 13213
Updated by: lobbin
I get a 404 not found on this url.
http://www.dr-micro.net/files/gis.php
Sorry. I sent this script to the server months ago and somebody removed
it from there... Please try again.
[2002-01-07 08:49:28] [EMAIL PROTECTED]
I get a 404 not found on this url.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/13213
--
Edit this bug report at http://bugs.php.net/?id=13213&edit=1
Bug #15680 Updated: WIll not read this image at all
ID: 15680 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: GetImageSize related Operating System: solaris 2.7 PHP Version: 4.1.1 -Assigned To: +Assigned To: helly New Comment: This bug has already been fixed in the latest released version of PHP, which you can download at http://www.php.net/downloads.php Previous Comments: [2002-03-06 17:12:09] [EMAIL PROTECTED] Works on winxp/cygwin [2002-02-22 13:38:49] [EMAIL PROTECTED] getimagesize will not read this image at all where it will be read by a browser just fine: http://www.adultdeal.com/logos/blurr_banner2.gif Thanks -- Edit this bug report at http://bugs.php.net/?id=15680&edit=1
Bug #15174 Updated: JPEG SOFn marker incompletely read
ID: 15174
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: GetImageSize related
Operating System: Linux
PHP Version: 4.1.1
-Assigned To:
+Assigned To: helly
New Comment:
SOFn sections have format:
LL B HH WW C C*3
L=length of section
B=bits per sample
H=height
w=width
c=channels
+3*c bytes for channel information
code will be added in next cvs version / php 4.3
Previous Comments:
[2002-01-22 15:54:25] [EMAIL PROTECTED]
In ext/standard/image.c:static struct gfxinfo *php_handle_jpeg():
After $result->channels has been read from the file, there are still
$result->channels * 3 bytes left in the SOF marker. These bytes have to
be read to synchronize reading of the following markers in the JPEG
stream. If not, bogus markers will be decoded and SOS marker will be
missed in most cases.
The following patch against 4.1.1 might take care of the problem:
--- ext/standard/image.c.orig Sat Aug 11 19:03:37 2001
+++ ext/standard/image.cTue Jan 22 21:14:31 2002
@@ -323,6 +323,8 @@
unsigned int marker;
char tmp[2];
unsigned char a[4];
+ unsigned short skip;
+ unsigned char *buffer;
for (;;) {
marker = php_next_marker(socketd, fp, issock);
@@ -349,6 +351,11 @@
result->height = (((unsigned short) a[ 0 ]) << 8) +
((unsigned short) a[ 1 ]);
result->width = (((unsigned short) a[ 2 ]) << 8) +
((unsigned short) a[ 3 ]);
result->channels = FP_FGETC(socketd, fp, issock);
+ /* skip component specification parameters */
+ skip = result->channels * 3;
+ buffer = emalloc(skip);
+ FP_FREAD(buffer, (long) skip, socketd, fp, issock);
+ efree(buffer);
if (! info) /* if we don't want an extanded info ->
return */
return result;
--
Edit this bug report at http://bugs.php.net/?id=15174&edit=1
Bug #13213 Updated: Unknown image format
ID: 13213
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Analyzed
+Status: Closed
Bug Type: GetImageSize related
Operating System: Linux RedHat 7.1
PHP Version: 4.1.1
Assigned To: helly
New Comment:
Took a closer look on the file.
The promlem is that both photo1 and photo3 have an illegal comment
section. The section is appended by some 0x00 where 0xFF were expected.
As other software ignores the NULLs i will add this to CVS / php4.3
version.
Previous Comments:
[2002-03-08 11:44:25] [EMAIL PROTECTED]
The current CVS implementation has been improoved on that.
As you can see from exif's debug warnings. photo1 and photo3 are
illegal. An internal section says it is longer than the file :-(
I could implement handling that but it would blow up code.
I will consider the applied patch...
photo1.jpg
GetImageSize [ , , , ]
exif_read_data exif_read_data returned false
Invalid JPEG/TIFF file: 'photo1.jpg'
21
PHP Warning: error reading from file: got=x3648(=13896) !=
itemlen-2=x4EE1(=20193)
photo2.jpg
GetImageSize [ 640, 480, 2, width="640" height="480" ]
exif_read_data exif_read_data returned false
O.K.
22
photo3.jpg
GetImageSize [ , , , ]
exif_read_data exif_read_data returned false
Invalid JPEG/TIFF file: 'photo3.jpg'
23
PHP Warning: error reading from file: got=x1E3D(=7741) !=
itemlen-2=xF698(=63128)
photo4.jpg
GetImageSize [ 640, 480, 2, width="640" height="480" ]
exif_read_data exif_read_data returned false
O.K.
[2002-01-22 16:34:48] [EMAIL PROTECTED]
Solution: Read additional bytes to resync on the marker sequence. If
marker length is too short, nothing is lost. If too long, one marker
will be missing. Besides that APPn in $info array will contain
consistent entries and no bogus markers. Uhm, ... and if the JPEG
format follows the spec and contains correct marker lengths, it will
work also ;-)
This patch against 4.1.1 might do the trick:
--- ext/standard/image.c.orig Sat Aug 11 19:03:37 2001
+++ ext/standard/image.cTue Jan 22 22:10:42 2002
@@ -253,12 +253,20 @@
/* {{{ php_next_marker
*/
-static unsigned int php_next_marker(int socketd, FILE *fp, int
issock)
+static unsigned int php_next_marker(int socketd, FILE *fp, int issock,
int isfirst)
/* get next marker byte from file */
{
int c;
- /* get marker byte, swallowing possible padding */
+ if (!isfirst) {
+ /* swallow bytes resulting from short marker length */
+ do {
+ if ((c = FP_FGETC(socketd, fp, issock)) ==
EOF)
+ return M_EOI; /* we hit EOF */
+ } while (c != 0xff);
+ }
+
+ /* get marker byte, swallowing possible 0xff padding */
do {
if ((c = FP_FGETC(socketd, fp, issock)) == EOF)
return M_EOI; /* we hit EOF */
@@ -320,12 +328,14 @@
static struct gfxinfo *php_handle_jpeg (int socketd, FILE *fp, int
issock, pval *info)
{
struct gfxinfo *result = NULL;
+ int isfirst = 1;/* First marker after JPEG sig 'FF D8
FF' */
unsigned int marker;
char tmp[2];
unsigned char a[4];
for (;;) {
- marker = php_next_marker(socketd, fp, issock);
+ marker = php_next_marker(socketd, fp, issock,
isfirst);
+ isfirst = 0;
switch (marker) {
case M_SOF0:
case M_SOF1:
[2002-01-22 13:15:04] [EMAIL PROTECTED]
Offending images contain COM marker with length parameter two bytes
short. This breaks further decoding of JPEG header - GetImageSize()
cannot return useful information.
[2002-01-11 17:09:08] [EMAIL PROTECTED]
I experience the same on 4.1.1
[2002-01-07 10:17:09] [EMAIL PROTECTED]
ID: 13213
Updated by: lobbin
I get a 404 not found on this url.
http://www.dr-micro.net/files/gis.php
Sorry. I sent this script to the server months ago and somebody removed
it from there... Please try again.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/13213
--
Edit this bug report at http://bugs.php.net/?id=13213&edit=1
#25377 [Bgs]: Class variables can be added out of class definition
ID: 25377 Updated by: [EMAIL PROTECTED] Reported By: forseti at oak dot rpg dot pl Status: Bogus Bug Type: Class/Object related Operating System: Windows 98 SE PHP Version: 5CVS-2003-09-03 (dev) New Comment: Class variables can NOT be added onnly object variables can. That makes PHP a language between class oriented and real object oriented languages. Previous Comments: [2003-11-18 15:36:23] [EMAIL PROTECTED] This is actually a feature, not bug. [2003-09-03 04:16:27] forseti at oak dot rpg dot pl Description: Class variables can be added freely out of class declaration context. This can be done by simply assigning a value to existing object's non-existing variable. Resulting modified object remains of his old type. Reproduce code: --- b = 'bar'; $test3 = new Test; echo 'test1: ';print_r($test1);echo ''; echo 'test2: ';print_r($test2);echo ''; echo 'test3: ';print_r($test3);echo ''; $hint = new HintTest($test2); ?> Expected result: Adding new class variables this way shouldn't be possible because modified object is no longer of the same type. And as last line shows it is treated by engine as such. Actual result: -- Modified object is nevertheless treated as if it was of Test type. -- Edit this bug report at http://bugs.php.net/?id=25377&edit=1
#26396 [Opn->Bgs]: foreach scope modality
ID: 26396
Updated by: [EMAIL PROTECTED]
Reported By: php dot net dot 1 at odi dot ch
-Status: Open
+Status: Bogus
Bug Type: Arrays related
Operating System: Win32
PHP Version: 4.3.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You can not nest foreach calls.
Previous Comments:
[2003-11-25 04:58:19] php dot net dot 1 at odi dot ch
Description:
The behaviour of foreach seems to be scope dependent. The following
code (slightly more than 20 lines) should yield the same results in
both cases, but doesn't.
I know that foreach uses the internal array pointer. The result beeing
"de" or "de fr it" is NOT the topic here. The point is that the two
results differ, although the code is the same except for the scope.
This could be the reason for bug #19285
Reproduce code:
---
";
g();
echo "--";
echo "Test2:";
foreach ($usr_langs as $lang) {
f();
echo "$lang ";
}
?>
Expected result:
Test1:
de
--
Test2:
de
OR even better
Test1:
de fr it
--
Test2:
de fr it
Actual result:
--
Test1:
de
--
Test2:
de fr it
--
Edit this bug report at http://bugs.php.net/?id=26396&edit=1
#26396 [Bgs->Opn]: foreach scope modality
ID: 26396
Updated by: [EMAIL PROTECTED]
Reported By: php dot net dot 1 at odi dot ch
-Status: Bogus
+Status: Open
Bug Type: Arrays related
-Operating System: Win32
+Operating System: *
PHP Version: 4.3.3
New Comment:
Interesting, anybody?
Previous Comments:
[2003-11-25 13:22:18] jpatrin at pnicorp dot com
Here's the proof that the global keyword is broken. If you change the
code to use $GLOBALS as such:
';
g();
echo '--';
echo 'Test2:';
foreach($usr_langs as $lang) {
f();
echo $lang.' ';
}
?>
The output is:
Test1:
de fr it
--
Test2:
de fr it
As was originally expected. Please either open this bug again or
explain why global is treated differently than $GLOBALS.
[2003-11-25 13:12:37] jpatrin at pnicorp dot com
You *CAN* nest foreach loops, as I have been doing it for a LONG time.
You can even nest foreach loops with the same array and the output will
be as expected (see code at bottom). Because foreach works on a copy of
the array, it does not change the internal pointer and therefore there
are two bugs here. The first being that the outputs aren't the same and
second being that all values int he array are not output by g().
What seems to be happening if that f() is somehow altering the internal
pointer of the *copy* that g() is operating on. Is it almost certain
that this is a problem with how global is implemented.
This code:
";
foreach($usr_langs as $lang2) {
echo "2 $lang2";
}
}
?>
Produces this output:
1 de
2 de
2 fr
2 it
1 fr
2 de
2 fr
2 it
1 it
2 de
2 fr
2 it
[2003-11-25 12:36:00] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You can not nest foreach calls.
[2003-11-25 04:58:19] php dot net dot 1 at odi dot ch
Description:
The behaviour of foreach seems to be scope dependent. The following
code (slightly more than 20 lines) should yield the same results in
both cases, but doesn't.
I know that foreach uses the internal array pointer. The result beeing
"de" or "de fr it" is NOT the topic here. The point is that the two
results differ, although the code is the same except for the scope.
This could be the reason for bug #19285
Reproduce code:
---
";
g();
echo "--";
echo "Test2:";
foreach ($usr_langs as $lang) {
f();
echo "$lang ";
}
?>
Expected result:
Test1:
de
--
Test2:
de
OR even better
Test1:
de fr it
--
Test2:
de fr it
Actual result:
--
Test1:
de
--
Test2:
de fr it
--
Edit this bug report at http://bugs.php.net/?id=26396&edit=1
#26396 [Opn->WFx]: foreach scope modality
ID: 26396
Updated by: [EMAIL PROTECTED]
Reported By: php dot net dot 1 at odi dot ch
-Status: Open
+Status: Wont fix
Bug Type: Arrays related
Operating System: *
PHP Version: 4.3.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
I was right then. Global creates a reference and referenced arrays
cannot be nested. When an array is passed to foreach and it is not a
reference then a copy of the array is created. That's where the
difference comes from.
Previous Comments:
[2003-11-25 16:27:47] jpatrin at pnicorp dot com
Here's a bit more. If you use
$usr_langs =& $GLOBALS['usr_langs'];
instead of
global $usr_langs;
the same bug presents it self.
Also, if you put
global $usr_langs;
above the echo "Test2..." You get only "de" in the output. It seems
like global is munging the scope of foreach copies.
[2003-11-25 16:08:19] [EMAIL PROTECTED]
Interesting, anybody?
[2003-11-25 13:22:18] jpatrin at pnicorp dot com
Here's the proof that the global keyword is broken. If you change the
code to use $GLOBALS as such:
';
g();
echo '--';
echo 'Test2:';
foreach($usr_langs as $lang) {
f();
echo $lang.' ';
}
?>
The output is:
Test1:
de fr it
--
Test2:
de fr it
As was originally expected. Please either open this bug again or
explain why global is treated differently than $GLOBALS.
[2003-11-25 13:12:37] jpatrin at pnicorp dot com
You *CAN* nest foreach loops, as I have been doing it for a LONG time.
You can even nest foreach loops with the same array and the output will
be as expected (see code at bottom). Because foreach works on a copy of
the array, it does not change the internal pointer and therefore there
are two bugs here. The first being that the outputs aren't the same and
second being that all values int he array are not output by g().
What seems to be happening if that f() is somehow altering the internal
pointer of the *copy* that g() is operating on. Is it almost certain
that this is a problem with how global is implemented.
This code:
";
foreach($usr_langs as $lang2) {
echo "2 $lang2";
}
}
?>
Produces this output:
1 de
2 de
2 fr
2 it
1 fr
2 de
2 fr
2 it
1 it
2 de
2 fr
2 it
[2003-11-25 12:36:00] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You can not nest foreach calls.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26396
--
Edit this bug report at http://bugs.php.net/?id=26396&edit=1
#26380 [Opn->Csd]: empty($SimpleXMLObject) doesn't return true when empty
ID: 26380
Updated by: [EMAIL PROTECTED]
Reported By: bart at mediawave dot nl
-Status: Open
+Status: Closed
-Bug Type: Zend Engine 2 problem
+Bug Type: Feature/Change Request
-Operating System: Windows 2000
+Operating System: *
-PHP Version: 5.0.0b2 (beta2)
+PHP Version: 5
-Assigned To:
+Assigned To: helly
New Comment:
Please leave this bug closed!
empty() has a different meaning than the one you seem to expect.
Objects can never be empty!
Previous Comments:
[2003-11-26 09:29:19] bart at mediawave dot nl
simplexml_element Object
(
[foo] => simplexml_element Object
(
)
[bar] => Array
(
[0] => s2
[1] => s3
)
)
[foo] looks empty to me?
Or maybe there are private properties that I can't see? If so, should
empty() return true if an object only has private properties?
How else can we tell if an SimpleXML object represents an empty tag?
[2003-11-25 14:50:47] [EMAIL PROTECTED]
The object is not empty. No bug here.
[2003-11-24 07:56:25] bart at mediawave dot nl
Changed this to "Zend Engine 2 problem" because it seems empty() should
return true if an object has no properties:
http://www.php.net/manual/en/function.empty.php
[2003-11-24 07:36:26] bart at mediawave dot nl
Description:
This bug/feature request has some relation with bug: #25640.
I've loaded XML into a simpleXML object. SimpleXML currently loads
empty tags (e.g. ) as empty SimpleXML objects.
With the SimpleXML object I wanted to use the following code to find
out whether a tag has child tags or not:
if (is_object($SimpleXMLObjectNode)) {
// $node has child tags
Unfortunately this doesn't work very well since this code will think
that empty tags have child tags too. (Since empty tags are loaded as
objects)
Therefore I thought it would be a nice feature to be able to find out
whether an object is empty or not. Something like:
if (empty($object)) {
// Object is empty
}
Reproduce code:
---
s2s3';
$t = simplexml_load_string($xml);
print_r($t);
if (empty($t->foo)) {
echo 'Tag is empty';
} else {
echo 'Tag has contents';
}
?>
Expected result:
Tag is empty
Actual result:
--
Tag has contents
--
Edit this bug report at http://bugs.php.net/?id=26380&edit=1
#26396 [WFx]: foreach scope modality
ID: 26396 Updated by: [EMAIL PROTECTED] Reported By: php dot net dot 1 at odi dot ch Status: Wont fix Bug Type: Arrays related Operating System: * PHP Version: 4.3.3 New Comment: PHP variables are implemented as refcounted unions in c. A reference in PHP means a flag in php which is the difference of making copies or working on the original memory. PHP Objects are handles in PHP 5 so copying it doesn't make a difference - only the handle is copied. Previous Comments: [2003-11-25 18:48:12] php dot net dot 1 at odi dot ch Sad to see that PHP's language constructs are so fundamentally flawed. [2003-11-25 18:11:31] jpatrin at pnicorp dot com Ok, I'll accept that response, but why does foreach not make a copy of the referenced array? I see no place in the foreach docs that say that it doesn't make a copy when the variable is a reference. Sidenote: I thought that all PHP vars were refernces and that usinf =& made it a refernce to the same object instead of a refernce to a copy of the object. If this is true, the copy should still be made just fine. foreach is ALWAYS supposed to make a copy of the array and foreach over that. [2003-11-25 17:21:46] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php I was right then. Global creates a reference and referenced arrays cannot be nested. When an array is passed to foreach and it is not a reference then a copy of the array is created. That's where the difference comes from. [2003-11-25 16:27:47] jpatrin at pnicorp dot com Here's a bit more. If you use $usr_langs =& $GLOBALS['usr_langs']; instead of global $usr_langs; the same bug presents it self. Also, if you put global $usr_langs; above the echo "Test2..." You get only "de" in the output. It seems like global is munging the scope of foreach copies. [2003-11-25 16:08:19] [EMAIL PROTECTED] Interesting, anybody? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26396 -- Edit this bug report at http://bugs.php.net/?id=26396&edit=1
#26411 [Fbk]: while {} else {}
ID: 26411
Updated by: [EMAIL PROTECTED]
Reported By: php at bellytime dot com
Status: Feedback
Bug Type: Feature/Change Request
-Operating System: FreeBSD
+Operating System: *
-PHP Version: Irrelevant
+PHP Version: *
New Comment:
Read again. Your code would always print 'No results found' while the
intended change wouldn't.
Previous Comments:
[2003-11-25 19:16:51] [EMAIL PROTECTED]
Can you give a better example to support your request? Your example can
easily be written as:
while ($row = mysql_fetch_assoc($result)) {
print 'Here is a result';
...
}
if (!row) {
print 'No results found';
}
I don't think that this one test is so expensive that it makes it worth
the trouble (and cost) to clutter up the language.
[2003-11-25 12:28:30] php at bellytime dot com
Description:
How about a while...else structure. Often we do
if (!mysql_num_rows($result)) {
print 'No results found';
}
while ($row = mysql_fetch_assoc($result)) {
print 'Here is a result';
...
}
Wouldn't it be nicer to do a
while ($row = mysql_fetch_assoc($result)) {
print 'Here is a result';
...
} else {
print 'No results found';
}
--
Edit this bug report at http://bugs.php.net/?id=26411&edit=1
#26182 [Ver->Csd]: Object properties created redundantly
ID: 26182
Updated by: [EMAIL PROTECTED]
Reported By: hongnk at hotmail dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
-Operating System: Win2k
+Operating System: *
PHP Version: 5CVS
New Comment:
PHP5 knows the concepts of implicit public properties and dynamic
properties.
Implicit public properties are properties that are declared by simply
using them.
Dynamic properties are properties that can be 'attached' to an object
while using it.
Previous Comments:
[2003-11-25 04:20:11] [EMAIL PROTECTED]
Works as expected with PHP 4, fails with PHP 5.
[2003-11-08 19:47:47] hongnk at hotmail dot com
Description:
Whenever a variable is refered anywhere inside a class under the form
$this->varname, it is automatically created in class instances.
Reproduce code:
---
class A {
function NotAConstructor(){
if(isset($this->x)){
//just for demo
}
}
}
$t=new A();
var_dump($t);
Expected result:
object(a)#1 (0) { }
Actual result:
--
object(a)#1 (1) { ["x"]=> NULL }
--
Edit this bug report at http://bugs.php.net/?id=26182&edit=1
#26182 [Csd->Opn]: Object properties created redundantly
ID: 26182
Updated by: [EMAIL PROTECTED]
Reported By: hongnk at hotmail dot com
-Status: Closed
+Status: Open
-Bug Type: Zend Engine 2 problem
+Bug Type: Feature/Change Request
Operating System: *
PHP Version: 5CVS
New Comment:
Reopen as feature request:
Shouldn't creation of implicit public properties be an E_STRICE error?
Previous Comments:
[2003-11-27 12:05:22] [EMAIL PROTECTED]
PHP5 knows the concepts of implicit public properties and dynamic
properties.
Implicit public properties are properties that are declared by simply
using them.
Dynamic properties are properties that can be 'attached' to an object
while using it.
[2003-11-25 04:20:11] [EMAIL PROTECTED]
Works as expected with PHP 4, fails with PHP 5.
[2003-11-08 19:47:47] hongnk at hotmail dot com
Description:
Whenever a variable is refered anywhere inside a class under the form
$this->varname, it is automatically created in class instances.
Reproduce code:
---
class A {
function NotAConstructor(){
if(isset($this->x)){
//just for demo
}
}
}
$t=new A();
var_dump($t);
Expected result:
object(a)#1 (0) { }
Actual result:
--
object(a)#1 (1) { ["x"]=> NULL }
--
Edit this bug report at http://bugs.php.net/?id=26182&edit=1
#24915 [Opn->WFx]: empty()/isset() misleading with __get/__set
ID: 24915
Updated by: [EMAIL PROTECTED]
Reported By: tater at potatoe dot com
-Status: Open
+Status: Wont fix
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-11-29
New Comment:
There are no plans on adding the missing third handler.
BUT you can go with the newly introduced ArrayAccess interface which
supports all necessary access methods.
Previous Comments:
[2003-11-29 00:18:34] tater at potatoe dot com
Oh, I see, you just saw the word "private" and threw a mental
exception. OK, here:
class foo
{
public $_x;
public function __get($p) { return $this->_x; }
public function __set($p,$v) { $this->_x = $v; }
}
$y = new foo;
$y->x = 12;
if (empty($y->x))
print "y->x is empty: {$y->x} \n";
else
print "y->x is not empty: {$y->x} \n";
if (isset($y->x))
print "y->x is set: {$y->x} \n";
else
print "y->x is not set: {$y->x} \n";
[2003-08-02 07:12:58] tater at potatoe dot com
Description:
Given a "property" that is really being handled by __get() and __set()
functions, you are allowed to use it with empty() and isset() without
errors or warnings, but they always report that the property is
empty/not-set.
I understand that this may not be a bug, but a "feature"
of PHP 5 - i.e., just the way it works - but if that is true,
please be kind enough to say so explicitly. It is not helpful
to mark bugs as Bogus with comments like "I suggest you read
ZEND_CHANGES :)"
If it is to be expected, it might be good to throw the
same kind of error that one would see if trying to use
empty() on a function call, if that's possible.
This is possibly related to bug #24436.
Reproduce code:
---
class foo
{
private $_x;
private function __get($p) { return $this->_x; }
private function __set($p,$v) { $this->_x = $v; }
}
$y = new foo;
$y->x = 12;
if (empty($y->x))
print "y->x is empty: {$y->x} \n";
else
print "y->x is not empty: {$y->x} \n";
if (isset($y->x))
print "y->x is set: {$y->x} \n";
else
print "y->x is not set: {$y->x} \n";
Expected result:
y->x is not empty: 12
y->x is set: 12
Actual result:
--
y->x is empty: 12
y->x is not set: 12
--
Edit this bug report at http://bugs.php.net/?id=24915&edit=1
#26591 [Opn->Csd]: "__autoload threw an exception" during an uncaught Exception
ID: 26591
Updated by: [EMAIL PROTECTED]
Reported By: bugzilla at malkusch dot de
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: Debian Woody
PHP Version: 5.0.0b2 (beta2)
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-11 07:30:30] bugzilla at malkusch dot de
Description:
If I use __autoload() PHP says "__autoload threw an exception" while I
throw an exception which would be caught somewhere between several
catch statements.
That means __autoload() first loads the Class for the thrown Exception
then PHP searches a catch statement for the threwn exception. The
first statement is for another Exception (the exception still is
uncaught) so __autoload should load this class. But here it fails and
says "__autoload threw an exception".
A Workaround would be to require all Exceptions for all catch
Statements before any exception is thrown.
Reproduce code:
---
// Be sure that Test1.php and Test2.php exists
function __autoload($className) {
echo '' . $className;
require_once ucfirst($className) . '.php';
echo 'loaded';
}
// If I would do "require_once Test1.php;" here
// everything would work
try {
throw new Test2();
} catch(Test1 $e) {
} catch(Test2 $e) {
}
Expected result:
test2loaded
test1loaded
Actual result:
--
test2loaded
test1
Fatal error: __autoload threw an exception in
/home/malkusch/http/index.php on line 13
--
Edit this bug report at http://bugs.php.net/?id=26591&edit=1
#26598 [Opn->Fbk]: Segmentation fault
ID: 26598
Updated by: [EMAIL PROTECTED]
Reported By: robert at interjinn dot com
-Status: Open
+Status: Feedback
Bug Type: Reproducible crash
Operating System: Mandrake 9.0
PHP Version: 5CVS-2003-12-12 (dev)
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
Previous Comments:
[2003-12-12 05:17:46] robert at interjinn dot com
Description:
No idea why script crashes. I'm including my compile information and
the backtrace.
export PHP_VERSION_DIR=php5-200312120830
make clean
rm config.cache
./configure \
--disable-all \
--with-mysql \
--enable-carnagemath \
--enable-carnagexml \
--enable-carnageutilities \
--enable-interjinn \
--enable-ctype \
--with-zlib \
--enable-ftp \
--enable-sockets \
--with-ncurses \
--enable-pcntl \
--with-pcre-regex \
--enable-exif \
--with-jpeg-dir=/usr/lib \
--with-png-dir=/usr/lib \
--with-tiff-dir=/usr/lib \
--with-gif-dir=/usr/lib \
--with-gd \
--prefix=/usr/local/php/${PHP_VERSION_DIR}/installation \
--exec-prefix=/usr/local/php/${PHP_VERSION_DIR}/installation
make
make install
Program received signal SIGSEGV, Segmentation fault.
zend_do_declare_property (var_name=0xbffed0e0, value=0xbffed110,
access_type=256)
at /usr/local/php/php5-200312120830/Zend/zend_compile.c:2442
2442if (CG(active_class_entry)->ce_flags &
ZEND_ACC_INTERFACE) {
(gdb) bt
#0 zend_do_declare_property (var_name=0xbffed0e0, value=0xbffed110,
access_type=256)
at /usr/local/php/php5-200312120830/Zend/zend_compile.c:2442
#1 0x08121b3a in zendparse () at Zend/zend_language_parser.c:2545
#2 0x0812371e in compile_file (file_handle=0xbffee4e0, type=2) at
Zend/zend_language_scanner.c:3139
#3 0x08155ad1 in zend_include_or_eval_handler
(execute_data=0xbfff0ad0, op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3355
#4 0x08151442 in execute (op_array=0x4032039c) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#5 0x0815407a in zend_do_fcall_common_helper (execute_data=0xbfff5180,
op_array=0x40315e44)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2580
#6 0x081542c9 in zend_do_fcall_by_name_handler (execute_data=0x0,
op_array=0x40315e44)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2666
#7 0x08151442 in execute (op_array=0x40315e44) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#8 0x0815407a in zend_do_fcall_common_helper (execute_data=0xbfff9e30,
op_array=0x40282c04)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2580
#9 0x081542c9 in zend_do_fcall_by_name_handler (execute_data=0x0,
op_array=0x40282c04)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:2666
#10 0x08151442 in execute (op_array=0x40282c04) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#11 0x08155b55 in zend_include_or_eval_handler
(execute_data=0xbfffbbc0, op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3403
#12 0x08151442 in execute (op_array=0x402796b4) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#13 0x08155b55 in zend_include_or_eval_handler
(execute_data=0xbfffc000, op_array=0x0)
at /usr/local/php/php5-200312120830/Zend/zend_execute.c:3403
#14 0x08151442 in execute (op_array=0x40278a5c) at
/usr/local/php/php5-200312120830/Zend/zend_execute.c:1277
#15 0x08139c32 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/php/php5-200312120830/Zend/zend.c:1016
#16 0x0810d368 in php_execute_script (primary_file=0xbfffe370)
at /usr/local/php/php5-200312120830/main/main.c:1638
#17 0x0815ac57 in main (argc=3, argv=0xbfffe404) at
/usr/local/php/php5-200312120830/sapi/cgi/cgi_main.c:1564
#18 0x40154082 in __libc_start_main () from /lib/i686/libc.so.6
--
Edit this bug report at http://bugs.php.net/?id=26598&edit=1
#26304 [Asn->Csd]: Unexpected data loss when opening dba file
ID: 26304
Updated by: [EMAIL PROTECTED]
Reported By: vesely at tana dot it
-Status: Assigned
+Status: Closed
Bug Type: DBM/DBA related
-Operating System: Solaris
+Operating System: *
PHP Version: 4.3.4
Assigned To: helly
Previous Comments:
[2003-11-19 22:14:01] vorlon at debian dot org
Correction, the "bad file descriptor" error came from excessive
fiddling with my test case. The lock handling when opening with mode
'c' in CVS HEAD appears to be correct for db4.
[2003-11-19 00:32:45] vorlon at debian dot org
This bug has also been reported at <http://bugs.debian.org/221559>.
The source of this behavior is quite clear --
ext/dba/dba.c:
case 'c':
modenr = DBA_CREAT;
lock_mode = (lock_flag & DBA_LOCK_CREAT) ? LOCK_EX : 0;
file_mode = "a+b";
if (!lock_mode || !lock_dbf) {
break;
}
/* When we lock the db file it will be created before the handler
* even tries to open it, hence we must change to truncate mode.
*/
case 'n':
modenr = DBA_TRUNC;
lock_mode = (lock_flag & DBA_LOCK_TRUNC) ? LOCK_EX : 0;
file_mode = "w+b";
break;
So unless locking is explicitly disabled (or explicitly configured to
use an external lockfile), 'CREAT' mode results in automatic truncation
of the database? What kind of sense does that make?
The behavior on the HEAD branch looks correct, but doesn't seem to
interact well with the 4.3 version of the code ("Driver initialization
failed for handler: db4: Bad file descriptor"). The current behavior
certainly is NOT correct, for db4.
[2003-11-18 12:59:58] vesely at tana dot it
Also, that correction around line 67 in dba_db4.c
(DBA_OPEN_FUNC) is bogus: if stat returns 0 you want
to say DB_UNKNOWN, since you cannot say it is DB_BTREE
when it was created by some other program.
To reproduce the bug you should create a DB with a different
type, e.g. in C if you just include db.h and then call
the dbm_open compatibility layer. The Sleepycat message
will then say "call implies an access method which is
inconsistent with previous calls."
[2003-11-18 12:09:46] vesely at tana dot it
Description:
Opening a file in 'c' mode (see example below)
truncates the file!! The docs say '"c" for read/write
access and database creation if it doesn't currently exist.'
I cannot understand that comment at line 658 in
ext/dba/dba.c, as it seems to imply that truncating
the database is necessary for locking it (??).
Reproduce code:
---
dba_open("important_data.db", "c", "db4");
Expected result:
open db (create if doesn't exist)
Actual result:
--
truncated db
--
Edit this bug report at http://bugs.php.net/?id=26304&edit=1
#26035 [Asn->Csd]: Opening existing CDB does not work
ID: 26035
Updated by: [EMAIL PROTECTED]
Reported By: a dot stagl at gmx dot at
-Status: Assigned
+Status: Closed
Bug Type: DBM/DBA related
Operating System: *
PHP Version: 4CVS, 5CVS
Assigned To: helly
New Comment:
- The cascon database is not a CDB database.
- The failure is in malloc (safe_emalloc)
which tries to allocate more memory then available.
This cannot be fixed within dba.
- The workaround to check the file length would slowdown
CDB by adding 2 additional seeks. This contradicts its
design.
- Hence there is nothing to fixed -> closed
Previous Comments:
[2003-10-31 08:28:12] [EMAIL PROTECTED]
OTOH, I don't think that Nokia/Cascon are using the CDB but something
of their own invention.
[2003-10-31 08:26:33] [EMAIL PROTECTED]
It actually returns empty string. When you change the
check to while ($key !== false) it'll crash:
(gdb) bt
#0 0x4072cf51 in kill () from /lib/i686/libc.so.6
#1 0x082762ac in _emalloc (size=1735290733, __zend_filename=0x8327600
"/usr/src/web/php/php4/ext/dba/dba_cdb.c",
__zend_lineno=303, __zend_orig_filename=0x84a6220
"/usr/src/web/php/php4/Zend/zend_alloc.c", __zend_orig_lineno=218)
at /usr/src/web/php/php4/Zend/zend_alloc.c:166
#2 0x082765c1 in _safe_emalloc (nmemb=1735290732, size=1, offset=1,
__zend_filename=0x8327600
"/usr/src/web/php/php4/ext/dba/dba_cdb.c", __zend_lineno=303,
__zend_orig_filename=0x0,
__zend_orig_lineno=0) at
/usr/src/web/php/php4/Zend/zend_alloc.c:218
#3 0x080bce64 in dba_nextkey_cdb (info=0x864eb74, newlen=0xbfffd4ec)
at /usr/src/web/php/php4/ext/dba/dba_cdb.c:303
#4 0x080bbfa4 in zif_dba_nextkey (ht=1, return_value=0x86401ec,
this_ptr=0x0, return_value_used=1)
at /usr/src/web/php/php4/ext/dba/dba.c:914
Assigned to Marcus who added this thing.
[2003-10-31 03:55:39] a dot stagl at gmx dot at
Unfortunatly, I cannot provide you the DB which I'm refering to,
because - as already mentioned - it is the contacts-database from a
nokia 9210i which contains sensitive data. I tried to get a sample
contacts.cdb directly from nokia, but they haven't been supportive :-(
But I found the following two cdb-databases on the internet:
http://web.mit.edu/cascon/updates/cascon.cdb (does not work with the
provided code)
http://cvs.sourceforge.net/viewcvs.py/*checkout*/cdbfile/cdbFile/cdbFile/Attic/test.cdb?rev=1.1.1.1
(works fine with my code)
HTH
[2003-10-30 05:30:43] a dot stagl at gmx dot at
Description:
I'm trying to open the contacts-databse from a nokia 9210i mobile, but
it doesn't work.
Reproduce code:
---
$db_conn = dba_open("contacts.cdb","r","cdb");
if (!$db_conn) die ("opening failed");
$key = dba_firstkey ($db_conn);
while ($key != false)
{
echo $key."";
echo dba_fetch ($key, $db_conn)."";
$key = dba_nextkey ($db_conn);
}
dba_close($db_conn);
Expected result:
...to get a list of key-value pairs.
Actual result:
--
The code didn't produce the expected output nor any error message. It
seems that the commands dba_firstkey and dba_nextkey always return
false instead of a key.
--
Edit this bug report at http://bugs.php.net/?id=26035&edit=1
#25905 [Asn->Csd]: getimagesize fail with some jpegs
ID: 25905
Updated by: [EMAIL PROTECTED]
Reported By: sitnikov at infonet dot ee
-Status: Assigned
+Status: Closed
Bug Type: Feature/Change Request
-Operating System: Linux
+Operating System: *
PHP Version: 4CVS-2003-10-18 (stable)
Assigned To: helly
New Comment:
The code you mentioned is to support the 'standard' error in writing
wrong jpeg files. I do not plan to add any additional workarounds for
any other software whose manufacturer cannot read a standard. If you
feel a need for this go ahead and show me a working patch. If that does
not hurt robustness too much, i will consider applying it.
Previous Comments:
[2003-10-20 10:41:48] sitnikov at infonet dot ee
reopen
[2003-10-19 06:03:48] [EMAIL PROTECTED]
Well it's a valid point you can take. Probably i'll even adapt the code
for getImageSize() but not now.
[2003-10-19 05:21:36] sitnikov at infonet dot ee
ok, why you implement this ?
/* get marker byte, swallowing possible padding */
if ( last_marker==M_COM && comment_correction) {
/* some software does not count the length bytes of COM section */
/* one company doing so is very much envolved in JPEG... so we accept
too */
/* by the way: some of those companies changed their code now... */
comment_correction = 2;
} else {
last_marker = 0;
comment_correction = 0;
}
[2003-10-19 04:56:21] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Your image file is corrupt and i don\'t think i will implement a
special handling for all wrong software out there. That would lead to
unrobust php code.
[2003-10-19 03:10:52] sitnikov at infonet dot ee
/usr/local/ImageMagick/bin/identify -format "%[EXIF:*]" wrong_jpeg.jpg
Make=Konica
Model=Revio C2
Orientation=1
XResolution=288/3
YResolution=288/3
ResolutionUnit=2
DateTime=2003:10:15 13:48:10
YCbCrPositioning=2
ExifOffset=174
ExposureTime=5924356/268435456
FNumber=28/10
ExposureProgram=3
ISOSpeedRatings=64
ExifVersion=0220
DateTimeOriginal=2003:10:15 13:48:10
DateTimeDigitized=2003:10:15 13:48:10
ComponentsConfiguration=...
CompressedBitsPerPixel=1989456/1228800
ShutterSpeedValue=44/8
ApertureValue=28/10
ExposureBiasValue=0/10
MaxApertureValue=28/10
SubjectDistance=11/10
MeteringMode=5
LightSource=0
Flash=0
FocalLength=45/10
MakerNote=0060162454
FlashPixVersion=0100
ColorSpace=1
ExifImageWidth=1280
ExifImageLength=960
unknown=
InteroperabilityOffset=724
unknown=R98
unknown=0100
ExposureIndex=1/1
SensingMethod=2
FileSource=.
SceneType=.
unknown=1280/1280
unknown=37
jpeg lib also working properly with this image.
Please see this code (from jpeg-6b):
next_marker (j_decompress_ptr cinfo)
{
int c;
INPUT_VARS(cinfo);
for (;;) {
INPUT_BYTE(cinfo, c, return FALSE);
/* Skip any non-FF bytes.
* This may look a bit inefficient, but it will not occur in a
valid file.
* We sync after each discarded byte so that a suspending data
source
* can discard the byte from its buffer.
*/
while (c != 0xFF) {
cinfo->marker->discarded_bytes++;
INPUT_SYNC(cinfo);
INPUT_BYTE(cinfo, c, return FALSE);
}
/* This loop swallows any duplicate FF bytes. Extra FFs are legal
as
* pad bytes, so don't count them in discarded_bytes. We assume
there
* will not be so many consecutive FF bytes as to overflow a
suspending
* data source's input buffer.
*/
do {
INPUT_BYTE(cinfo, c, return FALSE);
} while (c == 0xFF);
if (c != 0)
break;/* found a valid marker, exit loop */
/* Reach here if we found a stuffed-zero data sequence (FF/00).
* Discard it and loop back to try again.
*/
cinfo->marker->discarded_bytes += 2;
INPUT_SYNC(cinfo);
}
if (cinfo->marker->discarded_bytes != 0) {
WARNMS2(cinfo, JWRN_EXTRANEOUS_DATA,
cinfo->marker->discarded_bytes, c);
cinfo->marker->discarded_bytes = 0;
}
cinfo->unread_marker = c;
INPUT_SYNC(cinfo);
return TRUE;
}
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25905
--
Edit this bug report at http://bugs.php.net/?id=25905&edit=1
#25905 [Csd]: getimagesize fail with some jpegs
ID: 25905
Updated by: [EMAIL PROTECTED]
Reported By: sitnikov at infonet dot ee
Status: Closed
Bug Type: Feature/Change Request
Operating System: *
PHP Version: 4CVS-2003-10-18 (stable)
Assigned To: helly
New Comment:
Also see: Bug #13213 Unknown image format
Previous Comments:
[2003-12-15 17:03:04] [EMAIL PROTECTED]
The code you mentioned is to support the 'standard' error in writing
wrong jpeg files. I do not plan to add any additional workarounds for
any other software whose manufacturer cannot read a standard. If you
feel a need for this go ahead and show me a working patch. If that does
not hurt robustness too much, i will consider applying it.
[2003-10-20 10:41:48] sitnikov at infonet dot ee
reopen
[2003-10-19 06:03:48] [EMAIL PROTECTED]
Well it's a valid point you can take. Probably i'll even adapt the code
for getImageSize() but not now.
[2003-10-19 05:21:36] sitnikov at infonet dot ee
ok, why you implement this ?
/* get marker byte, swallowing possible padding */
if ( last_marker==M_COM && comment_correction) {
/* some software does not count the length bytes of COM section */
/* one company doing so is very much envolved in JPEG... so we accept
too */
/* by the way: some of those companies changed their code now... */
comment_correction = 2;
} else {
last_marker = 0;
comment_correction = 0;
}
[2003-10-19 04:56:21] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Your image file is corrupt and i don\'t think i will implement a
special handling for all wrong software out there. That would lead to
unrobust php code.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/25905
--
Edit this bug report at http://bugs.php.net/?id=25905&edit=1
#13213 [Csd]: Unknown image format
ID: 13213
Updated by: [EMAIL PROTECTED]
Reported By: pulstar at mail dot com
Status: Closed
Bug Type: GetImageSize related
Operating System: Linux RedHat 7.1
PHP Version: 4.1.1
Assigned To: helly
New Comment:
Also see: Bug #25905 getimagesize fail with some jpegs
Previous Comments:
[2002-03-10 07:15:50] janderk at digitaldutch dot com
I'm the main developer of Arles Image Web Page Creator, the application
that generated those JPEG's with the illegal comment section. I got an
email about this PHP BUG report from a user asking me to repair this
Arles bug.
FYI: It was a bug in an older versions of Arles and has been repaired
in the latest releases. It was actually caused by a bug in the Intel
JPEG library we used at that time.
I'm glad that we could help making PHP more robust in reading corrupted
images ;)
[2002-03-09 11:04:37] [EMAIL PROTECTED]
Took a closer look on the file.
The promlem is that both photo1 and photo3 have an illegal comment
section. The section is appended by some 0x00 where 0xFF were expected.
As other software ignores the NULLs i will add this to CVS / php4.3
version.
[2002-03-08 11:44:25] [EMAIL PROTECTED]
The current CVS implementation has been improoved on that.
As you can see from exif's debug warnings. photo1 and photo3 are
illegal. An internal section says it is longer than the file :-(
I could implement handling that but it would blow up code.
I will consider the applied patch...
photo1.jpg
GetImageSize [ , , , ]
exif_read_data exif_read_data returned false
Invalid JPEG/TIFF file: 'photo1.jpg'
21
PHP Warning: error reading from file: got=x3648(=13896) !=
itemlen-2=x4EE1(=20193)
photo2.jpg
GetImageSize [ 640, 480, 2, width="640" height="480" ]
exif_read_data exif_read_data returned false
O.K.
22
photo3.jpg
GetImageSize [ , , , ]
exif_read_data exif_read_data returned false
Invalid JPEG/TIFF file: 'photo3.jpg'
23
PHP Warning: error reading from file: got=x1E3D(=7741) !=
itemlen-2=xF698(=63128)
photo4.jpg
GetImageSize [ 640, 480, 2, width="640" height="480" ]
exif_read_data exif_read_data returned false
O.K.
[2002-01-22 16:34:48] mul at rentapacs dot com
Solution: Read additional bytes to resync on the marker sequence. If
marker length is too short, nothing is lost. If too long, one marker
will be missing. Besides that APPn in $info array will contain
consistent entries and no bogus markers. Uhm, ... and if the JPEG
format follows the spec and contains correct marker lengths, it will
work also ;-)
This patch against 4.1.1 might do the trick:
--- ext/standard/image.c.orig Sat Aug 11 19:03:37 2001
+++ ext/standard/image.cTue Jan 22 22:10:42 2002
@@ -253,12 +253,20 @@
/* {{{ php_next_marker
*/
-static unsigned int php_next_marker(int socketd, FILE *fp, int
issock)
+static unsigned int php_next_marker(int socketd, FILE *fp, int issock,
int isfirst)
/* get next marker byte from file */
{
int c;
- /* get marker byte, swallowing possible padding */
+ if (!isfirst) {
+ /* swallow bytes resulting from short marker length */
+ do {
+ if ((c = FP_FGETC(socketd, fp, issock)) ==
EOF)
+ return M_EOI; /* we hit EOF */
+ } while (c != 0xff);
+ }
+
+ /* get marker byte, swallowing possible 0xff padding */
do {
if ((c = FP_FGETC(socketd, fp, issock)) == EOF)
return M_EOI; /* we hit EOF */
@@ -320,12 +328,14 @@
static struct gfxinfo *php_handle_jpeg (int socketd, FILE *fp, int
issock, pval *info)
{
struct gfxinfo *result = NULL;
+ int isfirst = 1;/* First marker after JPEG sig 'FF D8
FF' */
unsigned int marker;
char tmp[2];
unsigned char a[4];
for (;;) {
- marker = php_next_marker(socketd, fp, issock);
+ marker = php_next_marker(socketd, fp, issock,
isfirst);
+ isfirst = 0;
switch (marker) {
case M_SOF0:
case M_SOF1:
[2002-01-22 13:15:04] mul at rentapacs dot com
Offending images contain COM marker with length parameter two bytes
short. This breaks further decoding of JPEG header - GetImageSize()
cannot return useful information.
The remainder of the comments for this report are too long. To view
th
#26643 [Opn->Bgs]: numeric converted to float
ID: 26643 Updated by: [EMAIL PROTECTED] Reported By: michael dot frank at bmg dot com -Status: Open +Status: Bogus Bug Type: Sybase-ct (ctlib) related Operating System: RedHat Linux PHP Version: 4.3.4 New Comment: Floating point values have a limited precision. Hence a value might not have the same string representation after any processing. That also includes writing a floating point value in your script and directly printing it without any mathematical operations. Thank you for your interest in PHP. The two numbers 11502401 and 1.15024E+15 are the exact same number on your machine. Previous Comments: [2003-12-17 03:27:19] michael dot frank at bmg dot com Description: When I try to fetch a numeric (18,0) value in php 4.2.3 I get correct values. After upgrade to php 4.3.4 I get converted numbers. On the older Version i Recieved e.g.: 11502401 on the new version i get this: 1.15024E+15 It seems like a old php bug - but i have the newest PHP Version running Sybase is ASE 12.5 on RedhatLinux. Apache is 1.3.29 -- Edit this bug report at http://bugs.php.net/?id=26643&edit=1
#24837 [Ver->Csd]: Incorrect behaviour of PPP using foreach
ID: 24837
Updated by: [EMAIL PROTECTED]
Reported By: redeye at erisx dot de
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-11-29
Assigned To: helly
Previous Comments:
[2003-07-28 02:39:49] redeye at erisx dot de
Description:
Using a foreach ( or while ) loop to print the
content of an object should to my understanding
skip private and protected values ( or methods ).
Actually these values are returned but missing
their respective keys, so at least their source
is hidden.
Reproduce code:
---
$val ){
echo $key." => ".$val."\r\n";
}
?>
Expected result:
empty page :)
Actual result:
--
=> test foo
=> test bar
=> test foobar
--
Edit this bug report at http://bugs.php.net/?id=24837&edit=1
#24837 [Csd]: Incorrect behaviour of PPP using foreach
ID: 24837
Updated by: [EMAIL PROTECTED]
Reported By: redeye at erisx dot de
Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-11-29
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-07-28 02:39:49] redeye at erisx dot de
Description:
Using a foreach ( or while ) loop to print the
content of an object should to my understanding
skip private and protected values ( or methods ).
Actually these values are returned but missing
their respective keys, so at least their source
is hidden.
Reproduce code:
---
$val ){
echo $key." => ".$val."\r\n";
}
?>
Expected result:
empty page :)
Actual result:
--
=> test foo
=> test bar
=> test foobar
--
Edit this bug report at http://bugs.php.net/?id=24837&edit=1
#26663 [Opn->Csd]: Iterator problem
ID: 26663
Updated by: [EMAIL PROTECTED]
Reported By: jonas at datatal dot se
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: win2k
PHP Version: 5.0.0b2 (beta2)
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-19 03:42:46] jonas at datatal dot se
Description:
The iterators doesnt work like they should.
More detailed info can be found at:
http://phplens.com/lens/lensforum/msgs.php?id=8065&PHPSESSID=954db40fa67b0cd2d81b22f5fa74e21f
Reproduce code:
---
foreach($rs as $val) {
echo $val;
}
Expected result:
while ($iterator->hasMore()) {
$val = $iterator->current();
echo $val;
$iterator->next();
}
Actual result:
--
while ($iterator->hasMore()) {
$val = $iterator->current();
$iterator->next();
echo $val;
}
--
Edit this bug report at http://bugs.php.net/?id=26663&edit=1
#24837 [Opn->Csd]: Incorrect behaviour of PPP using foreach
ID: 24837
Updated by: [EMAIL PROTECTED]
Reported By: redeye at erisx dot de
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5CVS-2003-11-29
Assigned To: helly
New Comment:
get_class_methods([obj]); has nothing to do with the above error.
Please open a new bug report and explain in detail.
Previous Comments:
[2003-12-22 03:59:04] redeye at erisx dot de
Also variables are hidden now, methods are still visible
using the function get_class_methods([obj]);
[2003-12-18 17:01:31] [EMAIL PROTECTED]
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
[2003-07-28 02:39:49] redeye at erisx dot de
Description:
Using a foreach ( or while ) loop to print the
content of an object should to my understanding
skip private and protected values ( or methods ).
Actually these values are returned but missing
their respective keys, so at least their source
is hidden.
Reproduce code:
---
$val ){
echo $key." => ".$val."\r\n";
}
?>
Expected result:
empty page :)
Actual result:
--
=> test foo
=> test bar
=> test foobar
--
Edit this bug report at http://bugs.php.net/?id=24837&edit=1
#26675 [Ver->Csd]: Segfault on ArrayAccess use
ID: 26675
Updated by: [EMAIL PROTECTED]
Reported By: xi at ngs dot ru
-Status: Verified
+Status: Closed
Bug Type: Reproducible crash
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-20 05:31:51] [EMAIL PROTECTED]
I could verify this.
[2003-12-20 03:32:46] xi at ngs dot ru
Backtrace:
#0 zend_call_function (fci=0xbfffd4c0, fci_cache=0xbfffd4a0)
at /home/simeon/php/php5-200312191230/Zend/zend_execute_API.c:668
#1 0x08141822 in zend_call_method (object_pp=0xbfffd550,
obj_ce=0x4032b6dc,
fn_proxy=0x0, function_name=0x81941be "offsetset",
function_name_len=9,
retval_ptr_ptr=0x0, param_count=136060708, arg1=0x0,
arg2=0x4032a568)
at /home/simeon/php/php5-200312191230/Zend/zend_interfaces.c:79
#2 0x081430ae in zend_std_write_dimension (object=0x4032c1cc,
offset=0x0,
value=0x4032a568)
at
/home/simeon/php/php5-200312191230/Zend/zend_object_handlers.c:405
#3 0x08157410 in zend_assign_to_object (result=0x4032a4f0,
object_ptr=0x4032c250, op2=0x4032a520, value_op=0x4032a560,
Ts=0xbfffd610,
opcode=147) at
/home/simeon/php/php5-200312191230/Zend/zend_execute.c:416
#4 0x081517e0 in zend_assign_dim_handler (execute_data=0xbfffd6f0,
op_array=0x40324e5c)
at /home/simeon/php/php5-200312191230/Zend/zend_execute.c:2058
#5 0x0814f5fd in execute (op_array=0x40324e5c)
at /home/simeon/php/php5-200312191230/Zend/zend_execute.c:1260
#6 0x0813515a in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/simeon/php/php5-200312191230/Zend/zend.c:1030
#7 0x081017ef in php_execute_script (primary_file=0xbac0)
at /home/simeon/php/php5-200312191230/main/main.c:1638
#8 0x0815a312 in main (argc=2, argv=0xbb44)
at /home/simeon/php/php5-200312191230/sapi/cli/php_cli.c:910
[2003-12-20 02:52:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
[2003-12-19 20:20:02] xi at ngs dot ru
Description:
The following code produces segfault using snapshot php5-200312191230.
Reproduce code:
---
array[ $offset ] ); }
public function offsetGet( $offset )
{ return $this->array[ $offset ]; }
public function offsetSet( $offset, $data )
{ $this->array[ $offset ] = $data; }
public function offsetUnset( $offset )
{ unset( $this->array[ $offset ] ); }
}
$a = new A();
$a[] = 'Segfault here!';
?>
Expected result:
String added to $a
Actual result:
--
Segmentation fault
--
Edit this bug report at http://bugs.php.net/?id=26675&edit=1
#26695 [Opn->Csd]: Reflection API does not recognize mixed-case class hints
ID: 26695
Updated by: [EMAIL PROTECTED]
Reported By: hans at velum dot net
-Status: Open
+Status: Closed
Bug Type: Class/Object related
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-22 13:52:14] hans at velum dot net
Description:
This is a problem in PHP 5.0.0b3 (distro), which wasn't an option in
the bug report select list.
Basically, upon upgrading to PHP5.0.0b3 our application generated
runtime Reflection_Exceptions claiming to be unable to find the class
specified by a class hint.
E.g. when calling
$params = $method->getParameters();
$hint = $params[0]->getClass();
Changing the class hint to lowercase fixes this problem.
Reproduce code:
---
class Foo {
}
class Bar {
function demo(Foo $f) {
// nothing
}
}
$class = new Reflection_Class('Bar');
$methods = $class->getMethods();
$params = $methods[0]->getParameters();
$hint = $params[0]->getClass();
// reflection_exception was thrown
print "Class expected is: ". $hint . "\n";
Expected result:
Class expected is: Foo
Actual result:
--
Fatal error: Uncaught exception 'reflection_exception' with
message 'Class Foo does not exist' in ...
--
Edit this bug report at http://bugs.php.net/?id=26695&edit=1
#26702 [Opn->Bgs]: bin2hex compare with HEX value that equals DEC value of HEX of bin returns true
ID: 26702
Updated by: [EMAIL PROTECTED]
Reported By: bugs dot php dot net at zetafleet dot com
-Status: Open
+Status: Bogus
Bug Type: Scripting Engine problem
Operating System: Win32; Cygwin x86
PHP Version: 4.3.3
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
The problem here is that bin2hey returns a string without the '0x' to
identify a hex number. Hence the string is interpreted as a decimal
number (if possible) when compared to any number.
To demonstrate:
$ php -r 'var_dump(("0x".bin2hex("D")) == 0x44);'
bool(true)
Previous Comments:
[2003-12-22 23:24:49] bugs dot php dot net at zetafleet dot com
Description:
This is complicated, so I'll try explaining as best I can.
There is a binary file. The first byte is 0x44. Doing a comparison (==)
to 0x2C returns "TRUE" because 44 is the decimal for 0x2C. The decimal
value of 0x44 is 68. This should return "FALSE" but does not.
Reproduce code:
---
(bin2hex("D") == 0x2C) RETURNS TRUE; SHOULD RETURN FALSE;
(bin2hex("D") == 0x44) RETURNS FALSE; SHOULD RETURN TRUE;
(bin2hex("D") == 44) RETURNS TRUE; SHOULD RETURN TRUE;
Expected result:
print(bin2hex("D") == 0x2C) //prints nothing
print(bin2hex("D") == 0x44) //prints '1'
print(bin2hex("D") == 44) //prints '1'
Actual result:
--
print(bin2hex("D") == 0x2C) //prints '1'
print(bin2hex("D") == 0x44) //prints nothing
print(bin2hex("D") == 44) //prints '1'
--
Edit this bug report at http://bugs.php.net/?id=26702&edit=1
#26697 [Opn->Csd]: calling class_exists on a nonexistent class in __autoload results in segfault
ID: 26697
Updated by: [EMAIL PROTECTED]
Reported By: arjen at glas dot its dot tudelft dot nl
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-22 18:50:01] davidc at blesys dot com
What happens, I think, is that __autoload starts recursing endlessly.
Do this:
$autotracker=false;
function __autoload ($n) {
global $autotracker; $n=strtolower($n);
if ($autotracker==$n)die("Attempting to autoload $n again");
$autotracker=$n;
//rest of function __autoload
}//end __autoload
Probably a bug, but rather easy to fix by the client programmer. I
think the bug I found today w/ thrown exceptions is much more dangerous
(http://bugs.php.net/bug.php?id=26698) because you can't really fix it
for all cases.
[2003-12-22 16:03:57] arjen at glas dot its dot tudelft dot nl
Description:
When calling class_exists on a nonexistent classname in __autoload,
you'll get a segfault.
This is in beta1, beta2 and beta3 (and now I had the time to create a
testcase and do a report). Which ran under apache2 (2.0.48) on gentoo
linux.
And then I saw this report:
http://bugs.php.net/bug.php?id=26630&edit=2
So I downloaded the php5-20031030 snapshot and there it also
segfaults...
Reproduce code:
---
--
Edit this bug report at http://bugs.php.net/?id=26697&edit=1
#26325 [Opn->Csd]: At least a notice when accessing private members in a derived class?
ID: 26325
Updated by: [EMAIL PROTECTED]
Reported By: drm at melp dot nl
-Status: Open
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
-PHP Version: 5.0.0b2 (beta2)
+PHP Version: 5.0.0b2
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
A derived class does not know *anything* about private members of a
base class. Hence there cannot be a distinction. Hence the result is
correct.
Previous Comments:
[2003-12-23 10:30:23] arjen at glas dot its dot tudelft dot nl
I've tested this with php5-20031030 snapshot and I get two notices,
when using this code (which is correct):
member}, nonexistent
{$this->nonexistent}";
}
}
$o = new DeriveTest ();
echo $o, '';
highlight_file(__FILE__);
?>
It could, however, be done even better if it were a bit more
explainatory notice. Like Java's error for instance:
DeriveTest.java:5: member2 has private access in Test
return "Member contains: " + member2 + " and getMember
sais: " + nonexistent;
^
DeriveTest.java:5: cannot resolve symbol
symbol : variable nonexistent
location: class DeriveTest
return "Member contains: " + member2 + " and getMember
sais: " + nonexistent;
^
2 errors
I.e. a distinction between nonexistent members and private members.
[2003-12-17 12:06:25] drm at melp dot nl
sniper >
I tried the snapshot (labeled PHP/5.0.0b3-dev), but the problem
persists.
[2003-12-16 03:00:41] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
AFAICT, bug #26182 is fixed..so try the snapshot?
[2003-11-26 11:07:13] drm at melp dot nl
J > Sorry i reacted that way, I misinterpreted your post.
I cannot reproduce what you mean in PHP4. Can you give an example?
I tried some stuff, but all the versions i tried gave expected results.
Changing "private $member" into "var $member" or removing that line
completely results in:
-
Member contains: Test constructor, though getMember() says: Test
constructor?
Member contains: a, though getMember() says: a?
-
which is logical, since the member will be public as soon as you
introduce it, both with "var $member" and removing the line completely
(and initializing it in the Test constructor). When removing the
initialization in the Test constructor, the same notice as in the other
codesample will be produced. (Notice: Undefined property: member in
)
btw: i figure this hasn't got anything to do with the fact that I
tested on WinXP, maybe that should be changed to OS: irrelevant?
[2003-11-24 11:28:58] [EMAIL PROTECTED]
Take your original example and edit it so it works in PHP
4. It runs in both 4 and 5 without a notice. Based on your
original example code, that isn't "just plain bs."
Upon further inspection based on your second example,
there is definitely something weird going on here. This is
most likely related to #26182.
J
I'm not positive, but I think this may have something to
do with #26182.
J
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26325
--
Edit this bug report at http://bugs.php.net/?id=26325&edit=1
#24926 [Ver->Csd]: a lambda function (create_function()) cannot be stored in a class property
ID: 24926 Updated by: [EMAIL PROTECTED] Reported By: kris dot hofmans at pandora dot be -Status: Verified +Status: Closed Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2003-11-29 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Btw: Your code example is wrong because you declared the class bleh twice. Also you cannot call a non method with $this. Previous Comments: [2003-11-28 21:27:15] [EMAIL PROTECTED] Note: Works fine with PHP 4.. [2003-08-03 16:37:13] kris dot hofmans at pandora dot be Description: As soon as a lamba function created by create_function gets stored in a class property it cannot be called anymore. Errors while trying: Warning: call_user_func(bleh::): First argument is expected to be a valid callback in /home/blacky/public_html/php5-dev/callback-test.php on line 66 And Fatal error: Call to a member function test() on a non-object in /home/blacky/public_html/php5-dev/callback-test.php on line 36 with test being my defined function. The closest bug report I could find resembling this problem is: http://bugs.php.net/bug.php?id=21909 Reproduce code: --- http://bbox.homelinux.net:4000/~blacky/php5-dev/callback-test.phps Expected result: I'd like to store functions in a property, preferably an array and call them like $this->property[$index]($arg1, $arg2); Actual result: -- Warning: call_user_func(bleh::): First argument is expected to be a valid callback in /home/blacky/public_html/php5-dev/callback-test.php on line 66 Or Fatal error: Call to a member function test() on a non-object in /home/blacky/public_html/php5-dev/callback-test.php on line 36 I'd expected both cases to work, first one being more logical. -- Edit this bug report at http://bugs.php.net/?id=24926&edit=1
#25038 [Ver->Csd]: call_user_func issues warning if function throws exception
ID: 25038
Updated by: [EMAIL PROTECTED]
Reported By: tater at potatoe dot com
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
PHP Version: 5.0.0b3
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-11-29 00:06:11] tater at potatoe dot com
The Exception class seems to have changed since this bug was logged. So
here is a new test case for you.
function bar($x='no argument')
{
throw new Exception("This is an exception from bar({$x}).");
}
try { bar('first try'); }
catch (Exception $e) { print "{$e->getMessage()}\n"; }
try { call_user_func('bar','second try'); }
catch (Exception $e) { print "{$e->getMessage()}\n"; }
Same results.
[2003-11-28 20:57:45] [EMAIL PROTECTED]
With latest CVS:
PHP Fatal error: Cannot access protected property exception::$message
in /home/jani/t.php on line 8
[2003-08-11 06:35:02] tater at potatoe dot com
Description:
Throwing an exception from a function called by call_user_func() causes
a warning to be issued,
saying it was unable to call the function.
An odd side note: if I set up my own error handler,
it does not receive this warning. Kind of an
inadvertant workaround for now...
Reproduce code:
---
function bar($x='no argument')
{
throw new Exception("This is an exception from bar({$x}).");
}
try { bar('first try'); }
catch (Exception $e) { print "{$e->message}\n"; }
try { call_user_func('bar','second try'); }
catch (Exception $e) { print "{$e->message}\n"; }
Expected result:
This is an exception from bar(first try).
This is an exception from bar(second try).
Actual result:
--
This is an exception from bar(first try).
Warning: call_user_func(bar): Unable to call bar(second try) in
/my/pathname/test.php on line 8
This is an exception from bar(second try).
--
Edit this bug report at http://bugs.php.net/?id=25038&edit=1
#25329 [Ver]: sqlite_create_function cant call method of $this as function kills apache(2)
ID: 25329
Updated by: [EMAIL PROTECTED]
Reported By: firepages at firepages dot com dot au
Status: Verified
Bug Type: SQLite related
Operating System: *
PHP Version: 5.0.0b2-dev, 4.3.3
New Comment:
The problem is the reference to $this from the generated sqlite
(php)function. See ext/sqlite/tests/sqlite_oo_029.phpt on how to work
around.
Previous Comments:
[2003-08-31 03:30:57] [EMAIL PROTECTED]
PECL_4_3:
/usr/src/web/php/php4_3/Zend/zend_hash.c(544) : ht=0x08212634 is being
destroyed
/usr/src/web/php/php4_3/Zend/zend_hash.c(108) : Bailed out without a
bailout address!
HEAD:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
_efree (ptr=0x0) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
257 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0 _efree (ptr=0x0) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
#1 0x816cdfb in _zval_ptr_dtor (zval_ptr=0x4029bac4) at
/usr/src/web/php/php5/Zend/zend_execute.h:67
#2 0x80b80c2 in php_sqlite_callback_invalidator (funcs=0x4029babc) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:288
#3 0x80b8110 in php_sqlite_callback_dtor (pDest=0x4029babc) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:310
#4 0x817a738 in zend_hash_destroy (ht=0x4029b8ec) at
/usr/src/web/php/php5/Zend/zend_hash.c:513
#5 0x80b813c in php_sqlite_db_dtor (rsrc=0x4029b95c) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:321
#6 0x817bb4d in list_entry_destructor (ptr=0x4029b95c) at
/usr/src/web/php/php5/Zend/zend_list.c:178
#7 0x817a89e in zend_hash_apply_deleter (ht=0x8349f10, p=0x4029b924)
at /usr/src/web/php/php5/Zend/zend_hash.c:568
#8 0x817a9da in zend_hash_graceful_reverse_destroy (ht=0x8349f10) at
/usr/src/web/php/php5/Zend/zend_hash.c:634
#9 0x817bc56 in zend_destroy_rsrc_list (ht=0x8349f10) at
/usr/src/web/php/php5/Zend/zend_list.c:234
#10 0x816cc93 in shutdown_executor () at
/usr/src/web/php/php5/Zend/zend_execute_API.c:279
#11 0x817555f in zend_deactivate () at
/usr/src/web/php/php5/Zend/zend.c:795
#12 0x8149224 in php_request_shutdown (dummy=0x0) at
/usr/src/web/php/php5/main/main.c:1197
#13 0x81ab61e in main (argc=2, argv=0xb694) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:1013
#14 0x401b19cb in __libc_start_main (main=0x81aa848 , argc=2,
argv=0xb694, init=0x8070368 <_init>,
fini=0x81abbe4 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xb68c)
at ../sysdeps/generic/libc-start.c:92
[2003-08-31 00:00:32] firepages at firepages dot com dot au
Description:
when trying to use sqlite_create_function() & passing a class method of
$this apache dies orribly (appreciate it may be an apache issue)
Win XP Pro / php 4.3.3 compiled (MSVC) against apache 2.0.47
eg
sqlite_create_function($this->db, 'link_keywords', array(
$this,'linkers' ) , 1);
/*OR*/
sqlite_create_function($this->db, 'link_keywords', array(
&$this,'linkers' ) , 1);
note that calling an external class method or normal function
[array($ext_class,$method)]gives no problem , just methods of $this
not tested on apache 1.*
Reproduce code:
---
class sqlite_help{
function sqlite_help(){
$this->db = sqlite_open('e:/phpdev/cp/my_admin.sqldb.eng', 0666,
$sqliteerror);
sqlite_create_function($this->db, 'link_keywords', array( $this ,
'linkers') , 1);
return $this->db;
}
function get_single( $key ){
$res = sqlite_query( $this->db,"SELECT link_keywords(var) FROM
my_admin WHERE key = '$key'" );
$r = sqlite_fetch_array( $res , SQLITE_NUM );
return $r[0];
}
function linkers( $str ){
$keywords = array('phpmyadmin'=>'http://localhost/phpmyadmin/index.php"";>phpMyAdmin');
foreach($keywords as $k=>$v){$str = str_replace( $k , $v , $str );}
return nl2br( $str );
}
}
$yaks=new sqlite_help();
echo $yaks->get_single('general');
Expected result:
str_replaced data from DB
works if function is external or external class method
Actual result:
--
an MS 'Apache has encountered an ' etc Dialog no apache error log
available , no PHP error logged.
--
Edit this bug report at http://bugs.php.net/?id=25329&edit=1
#25329 [Ver->Csd]: sqlite_create_function with method and reference to $this
ID: 25329
Updated by: [EMAIL PROTECTED]
Reported By: firepages at firepages dot com dot au
-Status: Verified
+Status: Closed
Bug Type: SQLite related
Operating System: *
PHP Version: 5.0.0b3-dev, 4.3.4
Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-12-27 16:56:25] [EMAIL PROTECTED]
The problem is the reference to $this from the generated sqlite
(php)function. See ext/sqlite/tests/sqlite_oo_029.phpt on how to work
around.
[2003-08-31 03:30:57] [EMAIL PROTECTED]
PECL_4_3:
/usr/src/web/php/php4_3/Zend/zend_hash.c(544) : ht=0x08212634 is being
destroyed
/usr/src/web/php/php4_3/Zend/zend_hash.c(108) : Bailed out without a
bailout address!
HEAD:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (runnable)]
_efree (ptr=0x0) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
257 CALCULATE_REAL_SIZE_AND_CACHE_INDEX(p->size);
(gdb) bt
#0 _efree (ptr=0x0) at /usr/src/web/php/php5/Zend/zend_alloc.c:257
#1 0x816cdfb in _zval_ptr_dtor (zval_ptr=0x4029bac4) at
/usr/src/web/php/php5/Zend/zend_execute.h:67
#2 0x80b80c2 in php_sqlite_callback_invalidator (funcs=0x4029babc) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:288
#3 0x80b8110 in php_sqlite_callback_dtor (pDest=0x4029babc) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:310
#4 0x817a738 in zend_hash_destroy (ht=0x4029b8ec) at
/usr/src/web/php/php5/Zend/zend_hash.c:513
#5 0x80b813c in php_sqlite_db_dtor (rsrc=0x4029b95c) at
/usr/src/web/php/php5/ext/sqlite/sqlite.c:321
#6 0x817bb4d in list_entry_destructor (ptr=0x4029b95c) at
/usr/src/web/php/php5/Zend/zend_list.c:178
#7 0x817a89e in zend_hash_apply_deleter (ht=0x8349f10, p=0x4029b924)
at /usr/src/web/php/php5/Zend/zend_hash.c:568
#8 0x817a9da in zend_hash_graceful_reverse_destroy (ht=0x8349f10) at
/usr/src/web/php/php5/Zend/zend_hash.c:634
#9 0x817bc56 in zend_destroy_rsrc_list (ht=0x8349f10) at
/usr/src/web/php/php5/Zend/zend_list.c:234
#10 0x816cc93 in shutdown_executor () at
/usr/src/web/php/php5/Zend/zend_execute_API.c:279
#11 0x817555f in zend_deactivate () at
/usr/src/web/php/php5/Zend/zend.c:795
#12 0x8149224 in php_request_shutdown (dummy=0x0) at
/usr/src/web/php/php5/main/main.c:1197
#13 0x81ab61e in main (argc=2, argv=0xb694) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:1013
#14 0x401b19cb in __libc_start_main (main=0x81aa848 , argc=2,
argv=0xb694, init=0x8070368 <_init>,
fini=0x81abbe4 <_fini>, rtld_fini=0x4000aea0 <_dl_fini>,
stack_end=0xb68c)
at ../sysdeps/generic/libc-start.c:92
[2003-08-31 00:00:32] firepages at firepages dot com dot au
Description:
when trying to use sqlite_create_function() & passing a class method of
$this apache dies orribly (appreciate it may be an apache issue)
Win XP Pro / php 4.3.3 compiled (MSVC) against apache 2.0.47
eg
sqlite_create_function($this->db, 'link_keywords', array(
$this,'linkers' ) , 1);
/*OR*/
sqlite_create_function($this->db, 'link_keywords', array(
&$this,'linkers' ) , 1);
note that calling an external class method or normal function
[array($ext_class,$method)]gives no problem , just methods of $this
not tested on apache 1.*
Reproduce code:
---
class sqlite_help{
function sqlite_help(){
$this->db = sqlite_open('e:/phpdev/cp/my_admin.sqldb.eng', 0666,
$sqliteerror);
sqlite_create_function($this->db, 'link_keywords', array( $this ,
'linkers') , 1);
return $this->db;
}
function get_single( $key ){
$res = sqlite_query( $this->db,"SELECT link_keywords(var) FROM
my_admin WHERE key = '$key'" );
$r = sqlite_fetch_array( $res , SQLITE_NUM );
return $r[0];
}
function linkers( $str ){
$keywords = array('phpmyadmin'=>'http://localhost/phpmyadmin/index.php"";>phpMyAdmin');
foreach($keywords as $k=>$v){$str = str_replace( $k , $v , $str );}
return nl2br( $str );
}
}
$yaks=new sqlite_help();
echo $yaks-&
#26065 [Ver->Csd]: Crash when nesting classes
ID: 26065
Updated by: [EMAIL PROTECTED]
Reported By: kester dot everts at wanadoo dot nl
-Status: Verified
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: *
-PHP Version: 5CVS-2003-11-29
+PHP Version: 5.0.0b3
-Assigned To:
+Assigned To: helly
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2003-11-01 05:12:32] [EMAIL PROTECTED]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 15661)]
0x0830cc13 in zend_do_abstract_method (function_name=0xbfffc450,
modifiers=0xbfffc3f0, body=0xbfffc4c8)
at /usr/src/web/php/php5/Zend/zend_compile.c:445
445 if (CG(active_class_entry)->ce_flags &
ZEND_ACC_INTERFACE) {
(gdb) bt
#0 0x0830cc13 in zend_do_abstract_method (function_name=0xbfffc450,
modifiers=0xbfffc3f0, body=0xbfffc4c8)
at /usr/src/web/php/php5/Zend/zend_compile.c:445
#1 0x082ff20d in zendparse () at zend_language_parser.y:457
#2 0x08302336 in compile_file (file_handle=0xbbb0, type=2) at
zend_language_scanner.l:367
#3 0x08322f6e in zend_execute_scripts (type=8, retval=0x0,
file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1005
#4 0x082e1f46 in php_execute_script (primary_file=0xbbb0) at
/usr/src/web/php/php5/main/main.c:1622
#5 0x0835c13f in main (argc=2, argv=0xbc44) at
/usr/src/web/php/php5/sapi/cli/php_cli.c:910
(gdb)
[2003-10-31 17:30:21] kester dot everts at wanadoo dot nl
Description:
When nesting a class within another class function, PHP crashes.
I have PHP running on an Apache2 (2.0.47) server as a module.
Changes in my php.ini, different from php.ini-dist are my SMTP server
setting, my error reporting level setting to E_ALL and the floating
point number precision to 14. No exentions are enabled.
Reproduce code:
---
class foo {
function bar() {
//here comes the line of doom:
class my_class {}
}
}
Expected result:
I expected PHP to return a fatal error which says that classes cannot
be nested.
Actual result:
--
PHP crashed...
I am using Windows, so I have not got a backtrace. I have sent an error
report to Microsoft; maybe that helps.
--
Edit this bug report at http://bugs.php.net/?id=26065&edit=1
#26275 [Ver->Dup]: Server Crash when throw exception
ID: 26275 Updated by: [EMAIL PROTECTED] Reported By: php dot bug at stre dot it -Status: Verified +Status: Duplicate Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2003-11-19 (dev) New Comment: See #26698 Previous Comments: [2003-11-18 19:15:43] [EMAIL PROTECTED] #0 0x08318170 in _zval_ptr_dtor (zval_ptr=0x40e33bf8, __zend_filename=0x856f580 "/usr/src/web/php/php5/Zend/zend_execute.h", __zend_lineno=122) at /usr/src/web/php/php5/Zend/zend_execute_API.c:352 #1 0x0834e4cb in zend_ptr_stack_clear_multiple () at zend_execute.h:122 #2 0x08349a4e in zend_do_fcall_common_helper (execute_data=0xbfffd7b0, op_array=0x40e428b4) at /usr/src/web/php/php5/Zend/zend_execute.c:2644 #3 0x08349c57 in zend_do_fcall_handler (execute_data=0xbfffd7b0, op_array=0x40e428b4) at /usr/src/web/php/php5/Zend/zend_execute.c:2696 #4 0x0834571f in execute (op_array=0x40e428b4) at /usr/src/web/php/php5/Zend/zend_execute.c:1271 #5 0x08324148 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/web/php/php5/Zend/zend.c:1016 #6 0x082e303a in php_execute_script (primary_file=0xbbb0) at /usr/src/web/php/php5/main/main.c:1622 #7 0x0835d87b in main (argc=2, argv=0xbc44) at /usr/src/web/php/php5/sapi/cli/php_cli.c:910 [2003-11-16 13:20:35] php dot bug at stre dot it sorry short version work, because there is first a standalone badfunc call, this version dont work i think is a failure by building stack trace [2003-11-16 12:20:32] php dot bug at stre dot it Description: this code below bring my server to crash Reproduce code: --- getMessage(); } ?> Expected result: no response from server, must restart service -- Edit this bug report at http://bugs.php.net/?id=26275&edit=1
