#21608 [NEW]: GD 2 + Freetype 2 = make Error
From: [EMAIL PROTECTED] Operating system: Free BSD 4.5 PHP version: 4.3.0 PHP Bug Type: GD related Bug description: GD 2 + Freetype 2 = make Error *** Error code 1: .../php-4.3.0/ext/gd/gd.c:2940: undefined reference to `gdImageStringFTEx' I have installed Freetype 2.3.1 -- Edit bug report at http://bugs.php.net/?id=21608edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21608r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21608r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21608r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21608r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21608r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21608r=support Expected behavior: http://bugs.php.net/fix.php?id=21608r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21608r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21608r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21608r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21608r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21608r=dst IIS Stability: http://bugs.php.net/fix.php?id=21608r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21608r=gnused
#21608 [Opn-Bgs]: GD 2 + Freetype 2 = make Error
ID: 21608 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: GD related Operating System: Free BSD 4.5 PHP Version: 4.3.0 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Previous Comments: [2003-01-13 02:25:23] [EMAIL PROTECTED] *** Error code 1: .../php-4.3.0/ext/gd/gd.c:2940: undefined reference to `gdImageStringFTEx' I have installed Freetype 2.3.1 -- Edit this bug report at http://bugs.php.net/?id=21608edit=1
#21608 [Bgs-Fbk]: GD 2 + Freetype 2 = make Error
ID: 21608 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Feedback Bug Type: GD related Operating System: Free BSD 4.5 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. oops, sorry Previous Comments: [2003-01-13 02:45:56] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. [2003-01-13 02:25:23] [EMAIL PROTECTED] *** Error code 1: .../php-4.3.0/ext/gd/gd.c:2940: undefined reference to `gdImageStringFTEx' I have installed Freetype 2.3.1 -- Edit this bug report at http://bugs.php.net/?id=21608edit=1
#21592 [Fbk-Opn]: form submit and iso-8859-2
ID: 21592 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: RH 8.0 PHP Version: 4.3.0 New Comment: Then some more info: Here is an example: http://www.parbanszep.hu/aa.php And the file: html head meta http-equiv=Content-Type content=text/html; charset=iso-8859-2 /head body h1?=htmlspecialchars($xx);?/h1 form method=post input type=text name=xx value=?=$xx? textarea name=yy?=htmlspecialchars($yy);?/textarea input type=submit /form /body /html Now try to enter õûÕÛ into the two fields, they will become #245; etc. instead of their one-char-form. Further info: http://www.parbanszep.hu/phpinfo.php Previous Comments: [2003-01-12 12:46:00] [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. Please provide an example which reproduces this error, also include any relevant httpd.conf/php.ini settings. [2003-01-12 02:52:51] [EMAIL PROTECTED] When I submit a form (GET or POST), characters only in the iso-8859-2 charset (like õûÕÛ) are not converted from quoted-printable to their 1-character-long representations, instead they left unchanged like #245; etc. I set the charset in the httpd.conf file, in the php.ini file, in the header of the html file and in the accept-charset attrib. of the form tag, but with no avail. I tried it in NN, Opera and IE. One more thing: sometimes it works correctly, but most of the time it doesn't. So strange enough! -- Edit this bug report at http://bugs.php.net/?id=21592edit=1
#21542 [Com]: variables bad values - register_global - session
ID: 21542 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: Session related Operating System: Linux PHP Version: 4.3.0 New Comment: Hello, after reading with more attention the 'bugs database', this bug is the same than http://bugs.php.net/bug.php?id=21312 (31/Dec/2002). Best regards, Nicolas Previous Comments: [2003-01-09 19:46:39] [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 Set session.bug_compat_warn to Off and the warning messages you are seeing should go away. [2003-01-09 06:23:45] [EMAIL PROTECTED] Hi, a strange problem, with session and register_global. The problem does not exist with PHP-4.2.3. When you have a variable set to a undefined value of $_SERVER array, and register_global set to ON, PHP set all variables to the same value (the last value). If you reload the page, there is no problem, it is only the FIRST time you read the page where there is the session variable is built. If you try with an unset variable, there is no problem. By the way, I don't understand the last message about Your script possibly relies on a session side-effect... when register_global is set to OFF. Best Regards, Nicolas --- info PHP PHP Version 4.3.0 register_argc_argv On session.auto_start Off session.bug_compat_42 On session.bug_compat_warn On session.cookie_domain no value session.name PHPSESSID session.use_cookies On session.use_only_cookies Off session.use_trans_sid Off -- test.php - +++SCRIPT+++ session_start(); $referer=$_SERVER['HTTP_REFERER']; # ERR (first time) #$referer=; # OK (always) session_register(referer); echo PRE; echo session_encode(); echo /PRE; $var1=V1; $var2=V2; $var3=V3; echo BR$var1 -- $var2 -- $var3 -- $var_not_affected\n; +++ --- WITH register_global : On At the first execution of ths script: +++OUTPUT+++ referer|N; V3 -- V3 -- V3 -- V3 +++ AND after reload: +++OUTPUT+++ referer|N; V1 -- V2 -- V3 -- +++ --- WITH register_global : Off +++OUTPUT+++ referer|N; V1 -- V2 -- V3 -- Warning: Unknown(): Your script possibly relies on a session side-effect which existed until PHP 4.2.3. Please be advised that the session extension does not consider global variables as a source of data, unless register_globals is enabled. You can disable this functionality and this warning by setting session.bug_compat_42 or session.bug_compat_warn to off, respectively. in Unknown on line 0 +++ -- Edit this bug report at http://bugs.php.net/?id=21542edit=1
#21271 [Com]: imap_sort returns irregular sort
ID: 21271 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: IMAP related Operating System: Windows 2000 Advanced Server PHP Version: 4CVS-2002-12-29 (stable) New Comment: hi I'm experiencing the same problem on a Mandrake box Mandrake 9.0 - 2.4.20 self-made kernel php 4.3.0 pear 4.1.0 './configure' '--with-apache=../apache_1.3.27' '--with-mysql' '--with-gettext' '--with-imap=../imap-2002a' '--with-gd' '--with-jpeg-dir=/usr/local' '--with-png-dir=/usr/local' '--with-zlib-dir=/usr/local' '--with-xml' '--enable-ftp' imap sorting functions don't work at all. horde/imp work well but sorting (date, subject, sender...) is unavailable. the imap server is a NT4 with mailsite email server http://www.rockliffe.com/products/emailserver.asp thx for your time change _nosp@mz_ by @ to answer me directly Previous Comments: [2002-12-29 13:21:32] [EMAIL PROTECTED] Hi, I built an webmail interface for Courier-IMAP mail server and I use PHP version 4.4.0. When i try to sort the messages from the mail server with imap_sort I always get a random sorting for Subject, To, From and Size; the Date sorting seems to work good. I also had this problem with the previous versions of PHP: 4.2.1 ... 4.2.3 Is there a ptoblem with the imap client on Windows ? Should I upgrade some dll on server ? Thank you for your time. -- Edit this bug report at http://bugs.php.net/?id=21271edit=1
#21565 [Fbk-Opn]: safe_mode works well with include but not with require
ID: 21565 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Tru64Unix 5.1A PHP Version: 4.3.0 New Comment: Well, you are right with the difference fatal error vs. warning. After I turned the warning messages on I can see the difference. So, the problem should be re-classified as a problem of both include and require. Still, with safe_mode on, it does not work, with safe_mode off, it works fine. Previous Comments: [2003-01-10 16:56:46] [EMAIL PROTECTED] It is likely that your error reporting level is such that warning messages do not get shown. Unlike require which fails with an error include will only output a warning on failure. Beyond that there is very little difference between the require/include code none of which is the code reponsible for actually openning files. [2003-01-10 03:35:37] [EMAIL PROTECTED] After upgrade from PHP 4.2.2 to 4.3.0 I encountered the problem with safe_mode in conjunction with require(). Example: [php.ini] safe_mode = On; include_path = .:./:/path/to/my/app/dir; safe_mode_include_dir = .:./:/path/to/my/app/dir; [/path/to/my/app/dir/index_working.php] - works fine for me ?php include header.php; ? [/path/to/my/app/dir/index_buggy.php] - throws error ?php require header.php; ? The error: [error] PHP Fatal error: main() [a href='http://www.php.net/function.main'function.main/a]: Failed opening required 'header.php' (include_path='.:./:/path/to/my/app/dir') in /path/to/my/app/dir/index_buggy.php on line 2 Operating system: Tru64Unix 5.1a Webserver: Apache 1.3.26 -- Edit this bug report at http://bugs.php.net/?id=21565edit=1
#21610 [NEW]: ODBC_DO() problem
From: [EMAIL PROTECTED] Operating system: Win XP PHP version: 4.2.0 PHP Bug Type: ODBC related Bug description: ODBC_DO() problem odbc_num_rows() return -1 (Access Database)when the request is an select, with update, insert and delete, it runs. I need help it's for my training period and i can't waste my time on it I use easyPHP 1.6( PHP 4.2.0) Thank -- Edit bug report at http://bugs.php.net/?id=21610edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21610r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21610r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21610r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21610r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21610r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21610r=support Expected behavior: http://bugs.php.net/fix.php?id=21610r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21610r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21610r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21610r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21610r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21610r=dst IIS Stability: http://bugs.php.net/fix.php?id=21610r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21610r=gnused
#21612 [NEW]: Enhancing include()
From: [EMAIL PROTECTED] Operating system: all PHP version: 4.3.0 PHP Bug Type: Feature/Change Request Bug description: Enhancing include() At the moment include() is only supporting files as arguments. Why not using array elements too? My excample: I have have a php-page that reads in text files and shows their content: http://christophorusschule-hamburg.de depending on the two parameters menu(m) and submenue(u). For http://christophorusschule-hamburg.de?m=6u=3 I want to show what setting of color and resolution is selected at the moment. So I need to have php-code included. The source is in a txt-file and after exploding in an array element. I want to use an if statement: if array element begins with ?php than the content shall be included, otherwise the content shall be echoed. With kind regards, Rüdiger -- Edit bug report at http://bugs.php.net/?id=21612edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21612r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21612r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21612r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21612r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21612r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21612r=support Expected behavior: http://bugs.php.net/fix.php?id=21612r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21612r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21612r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21612r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21612r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21612r=dst IIS Stability: http://bugs.php.net/fix.php?id=21612r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21612r=gnused
#21612 [Opn]: Enhancing include()
ID: 21612 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.3.0 New Comment: At the moment include() is only supporting files as arguments. Why not using array elements too? My excample: I have have a php-page that reads in text files and shows their content: http://christophorusschule-hamburg.de depending on the two parameters menu(m) and submenue(u). For http://christophorusschule-hamburg.de/basis.php?m=6u=3 I want to show what setting of color and resolution is selected at the moment. So I need to have php-code included. The source for this and all the other pages resides in a txt-file and after exploding in an array element. I want to use an if statement: if array element begins with ?php than the content shall be included, otherwise the content shall be echoed. With kind regards, Rüdiger Previous Comments: [2003-01-13 04:58:39] [EMAIL PROTECTED] At the moment include() is only supporting files as arguments. Why not using array elements too? My excample: I have have a php-page that reads in text files and shows their content: http://christophorusschule-hamburg.de depending on the two parameters menu(m) and submenue(u). For http://christophorusschule-hamburg.de?m=6u=3 I want to show what setting of color and resolution is selected at the moment. So I need to have php-code included. The source is in a txt-file and after exploding in an array element. I want to use an if statement: if array element begins with ?php than the content shall be included, otherwise the content shall be echoed. With kind regards, Rüdiger -- Edit this bug report at http://bugs.php.net/?id=21612edit=1
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn Previous Comments: [2003-01-11 12:15:55] [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. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. [2003-01-11 06:37:21] [EMAIL PROTECTED] I'm using Windows 2000 with IIS 5, and I've tried both CGI and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as you may notice in another bug-report I submitted ( http:// bugs.php.net/bug.php?id=20426 ). I did not run Windows Update this week, and I disabled auto-update service since I don't trust Microsoft. :-) Anyway, it should not be called as 'bug', and I have not trouble to modify my codes (just find/replace PATH_INFO with PHP_SELF.) I'm just curious about what is going on. Does PHP.INI would affect environment variables ? I'm using all default settings but enabling register_globals. [2003-01-10 21:54:37] [EMAIL PROTECTED] Environment variables are supplied by the environment under which PHP is running. In most cases this means the webserver. Did you change/upgrade your webserver at the same time? Moreover, what webserver are you running and on what OS? [2003-01-10 21:01:46] [EMAIL PROTECTED] Environment variable PATH_INFO disappeared in PHP4.30, which is presented in 4.1x and 4.2x. I know that I can use PHP_SELF instead, but my old codes now having problems. -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21607 [Bgs-Csd]: output line to long
ID: 21607 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Closed Bug Type: Compile Failure Operating System: Solaris8 PHP Version: 4.3.0 New Comment: TX It works now. Previous Comments: [2003-01-13 01:14:44] [EMAIL PROTECTED] Due to a bug in the installed sed on your system the build fails. Install GNU sed and it should be okay. Thank you for your interest in PHP. [2003-01-13 00:58:50] [EMAIL PROTECTED] /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -L/usr/ucblib -L/opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 -R /usr/ucblib -R /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.2 ext/ctype/ctype.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo ext/mysql/libmysql/thr_mutex.lo ext/mysql/libmysql/mulalloc.lo ext/mysql/libmysql/string.lo ext/mysql/libmysql/default.lo ext/mysql/libmysql/my_compress.lo ext/mysql/libmysql/array.lo ext/mysql/libmysql/my_once.lo ext/mysql/libmysql/list.lo ext/mysql/libmysql/my_net.lo ext/mysql/libmysql/dbug.lo ext/mysql/libmysql/strmov.lo ext/mysql/libmysql/strxmov.lo ext/mysql/libmysql/strnmov.lo ext/mysql/libmysql/strmake.lo ext/mysql/libmysql/strend.lo ext/mysql/libmysql/strfill.lo ext/mysql/libmysql/is_prefix.lo ext/mysql/libmysql/int2str.lo ext/mysql/libmysql/str2int.lo ext/mysql/libmysql/strinstr.lo ext/mysql/libmysql/strcont.lo ext/mysql/libmysql/strcend.lo ext/mysql/libmysql/bchange.lo ext/mysql/libmysql/bmove.lo ext/mysql/libmysql/bmove_upp.lo ext/mysql/libmysql/longlong2str.lo ext/mysql/libmysql/strtoull.lo ext/mysql/libmysql/strtoll.lo ext/mysql/libmysql/charset.lo ext/mysql/libmysql/ctype.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/posix/posix.lo ext/session/session.lo ext/session/mod_files.lo ext/session/mod_mm.lo ext/session/mod_user.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_wrapper.lo ext/standard/http_fopen_wrapper.lo ext/standard/php_fopen_wrapper.lo ext/standard/credits.lo ext/standard/css.lo ext/standard/var_unserializer.lo ext/standard/ftok.lo ext/standard/aggregation.lo ext/standard/sha1.lo ext/tokenizer/tokenizer.lo ext/xml/xml.lo ext/xml/expat/xmlparse.lo ext/xml/expat/xmlrole.lo ext/xml/expat/xmltok.lo regex/regcomp.lo regex/regexec.lo regex/regerror.lo regex/regfree.lo TSRM/TSRM.lo TSRM/tsrm_strtok_r.lo TSRM/tsrm_virtual_cwd.lo main/main.lo main/snprintf.lo main/spprintf.lo main/php_sprintf.lo main/safe_mode.lo main/fopen_wrappers.lo main/alloca.lo
#21613 [NEW]: fsockopen() causes apache restart
From: [EMAIL PROTECTED]
Operating system: RedHat 7.2
PHP version: 4.2.3
PHP Bug Type: Sockets related
Bug description: fsockopen() causes apache restart
?php
$fp = fsockopen (localhost, 80, $errno, $errstr, 30);
if (!$fp) {
echo $errstr ($errno)br\n;
} else {
fputs ($fp, GET / HTTP/1.0\r\nHost: www.example.com\r\n\r\n);
while (!feof($fp)) {
echo fgets ($fp,128);
}
fclose ($fp);
}
?
'./configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr' '--with-config-file-path=/etc'
'--enable-force-cgi-redirect' '--disable-debug' '--enable-pic'
'--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db3'
'--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin'
'--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd'
'--enable-gd-native-ttf' '--with-ttf' '--with-gdbm'
'--with-gettext=shared' '--with-ncurses' '--with-gmp' '--with-iconv'
'--with-jpeg-dir=/usr' '--with-mm' '--with-openssl' '--with-png'
'--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr'
'--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-debugger'
'--enable-exif' '--with-pear=/usr/share/pear' '--enable-magic-quotes'
'--enable-safe-mode' '--enable-sockets' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx'
'--without-oci8' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos=/usr/kerberos' '--with-ldap=shared'
'--enable-sysvsem=shared' '--enable-sysvshm=shared' '--enable-ftp=shared'
'--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr'
'--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared'
'--enable-memory-limit' '--enable-bcmath' '--enable-shmop'
'--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio'
'--enable-mbstring' '--with-apxs=/usr/sbin/apxs'
We tried to upgrade to php4.3 and after that we couldn't use fsockopen().
The downgrade to 4.2.3 didn't solve the problem. In the apache eror log
comes:
[Mon Jan 13 06:57:56 2003] [notice] child pid 31227 exit signal
Segmentation fault (11)
(gdb) run -X
Starting program: /usr/sbin/httpd -X
[New Thread 1024 (LWP 29955)]
Processing config directory: /etc/appliance/apacheconf
.. Folowed from apache restart
Program exited with code 01.
--
Edit bug report at http://bugs.php.net/?id=21613edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21613r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21613r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21613r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21613r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21613r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21613r=support
Expected behavior: http://bugs.php.net/fix.php?id=21613r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21613r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21613r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21613r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21613r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21613r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21613r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21613r=gnused
#21575 [Bgs]: 4.2x to 4.3 Compatibility issue
ID: 21575 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. Previous Comments: [2003-01-13 05:30:53] [EMAIL PROTECTED] How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn [2003-01-11 12:15:55] [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. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. [2003-01-11 06:37:21] [EMAIL PROTECTED] I'm using Windows 2000 with IIS 5, and I've tried both CGI and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as you may notice in another bug-report I submitted ( http:// bugs.php.net/bug.php?id=20426 ). I did not run Windows Update this week, and I disabled auto-update service since I don't trust Microsoft. :-) Anyway, it should not be called as 'bug', and I have not trouble to modify my codes (just find/replace PATH_INFO with PHP_SELF.) I'm just curious about what is going on. Does PHP.INI would affect environment variables ? I'm using all default settings but enabling register_globals. [2003-01-10 21:54:37] [EMAIL PROTECTED] Environment variables are supplied by the environment under which PHP is running. In most cases this means the webserver. Did you change/upgrade your webserver at the same time? Moreover, what webserver are you running and on what OS? [2003-01-10 21:01:46] [EMAIL PROTECTED] Environment variable PATH_INFO disappeared in PHP4.30, which is presented in 4.1x and 4.2x. I know that I can use PHP_SELF instead, but my old codes now having problems. -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#21613 [Opn-Fbk]: fsockopen() causes apache restart
ID: 21613
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: Sockets related
Operating System: RedHat 7.2
PHP Version: 4.2.3
New Comment:
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.
Please follow the instructions for generating a backtrace and post the
details here.
There will be no more 4.2.x releases and we are only interested in
fixing problems in the 4.3.x series, so please try 4.3.0 again.
Previous Comments:
[2003-01-13 05:58:54] [EMAIL PROTECTED]
?php
$fp = fsockopen (localhost, 80, $errno, $errstr, 30);
if (!$fp) {
echo $errstr ($errno)br\n;
} else {
fputs ($fp, GET / HTTP/1.0\r\nHost: www.example.com\r\n\r\n);
while (!feof($fp)) {
echo fgets ($fp,128);
}
fclose ($fp);
}
?
'./configure' 'i386-redhat-linux' '--prefix=/usr' '--exec-prefix=/usr'
'--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc'
'--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib'
'--libexecdir=/usr/libexec' '--localstatedir=/var'
'--sharedstatedir=/usr/com' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--prefix=/usr'
'--with-config-file-path=/etc' '--enable-force-cgi-redirect'
'--disable-debug' '--enable-pic' '--disable-rpath'
'--enable-inline-optimization' '--with-bz2' '--with-db3' '--with-curl'
'--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr'
'--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf'
'--with-gdbm' '--with-gettext=shared' '--with-ncurses' '--with-gmp'
'--with-iconv' '--with-jpeg-dir=/usr' '--with-mm' '--with-openssl'
'--with-png' '--with-pspell' '--with-regex=system' '--with-xml'
'--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU'
'--enable-bcmath' '--enable-debugger' '--enable-exif'
'--with-pear=/usr/share/pear' '--enable-magic-quotes'
'--enable-safe-mode' '--enable-sockets' '--enable-discard-path'
'--enable-track-vars' '--enable-trans-sid' '--enable-yp'
'--enable-wddx' '--without-oci8' '--with-imap=shared' '--with-imap-ssl'
'--with-kerberos=/usr/kerberos' '--with-ldap=shared'
'--enable-sysvsem=shared' '--enable-sysvshm=shared'
'--enable-ftp=shared' '--with-mysql=shared,/usr' '--with-pgsql=shared'
'--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack'
'--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath'
'--enable-shmop' '--enable-versioning' '--enable-calendar'
'--enable-dbx' '--enable-dio' '--enable-mbstring'
'--with-apxs=/usr/sbin/apxs'
We tried to upgrade to php4.3 and after that we couldn't use
fsockopen(). The downgrade to 4.2.3 didn't solve the problem. In the
apache eror log comes:
[Mon Jan 13 06:57:56 2003] [notice] child pid 31227 exit signal
Segmentation fault (11)
(gdb) run -X
Starting program: /usr/sbin/httpd -X
[New Thread 1024 (LWP 29955)]
Processing config directory: /etc/appliance/apacheconf
.. Folowed from apache restart
Program exited with code 01.
--
Edit this bug report at http://bugs.php.net/?id=21613edit=1
#21614 [NEW]: Non-ASCII characters get entity escaped on input from MSIE only
From: [EMAIL PROTECTED] Operating system: Various PHP version: 4.2.3 PHP Bug Type: Unknown/Other Function Bug description: Non-ASCII characters get entity escaped on input from MSIE only Entering non-ASCII data (eg in ISO-8859-1) using MSIE 6 and 5.5 (possibly others) via an HTTP POST (multipart/form-data, perhaps others) request to PHP 4.2.3 as a dynamically-loaded Apache (1.3 series) module causes the non-ASCII characters to be HTML entity escaped. eg: étan - eacute;tan This does not happen with Mozilla 1.2b (20021016), and did not happen with PHP 4.1.2 (with mbstring enabled). It happens with both mbstring enabled and disabled on PHP 4.2.3. It has been observed on Debian GNU/Linux, FreeBSD and WinXP. -- Edit bug report at http://bugs.php.net/?id=21614edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21614r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21614r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21614r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21614r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21614r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21614r=support Expected behavior: http://bugs.php.net/fix.php?id=21614r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21614r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21614r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21614r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21614r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21614r=dst IIS Stability: http://bugs.php.net/fix.php?id=21614r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21614r=gnused
#21615 [NEW]: PCRE segfault with (very) large string.
From: [EMAIL PROTECTED] Operating system: GNU/linux PHP version: 4.3.0 PHP Bug Type: Reproducible crash Bug description: PCRE segfault with (very) large string. PCRE segfault on a big regular expression on a really big string (17490 chars) special parameters in php.ini file: memory_limit = 64M test script: http://planet-service.fr/test2.php.gz this script test a substring of the crashing string. a loop do the test with this substring, and increase the size of the string at each step and print out the size. I put 17490 as starting size as that crash at 17491. The parameters at at the end of the script (after the string itself). compilation options: ./configure --prefix=/opt/php-4.3.0 --with-apache=../apache_1.3.27 --with-config-file-path=/opt/php-4.3.0/lib --enable-calendar --enable-track-vars --enable-ftp --with-readline --with-imap=/opt/c-client --with-openssl=/opt/openssl --with -gdbm=/usr --with-mysql=/opt/mysql --with-pgsql=/opt/postgresql --enable-trans-sid -with-regex=php --enable-sysvsem --enable-sysvshm --enable-memory-limit --enable-debug=no --with-ttf=/opt/freetype --with-t1lib=/opt/t1lib --with-xml --enable-sockets --with-jpeg-dir=/opt/jpeg --with-tiff-dir=/opt/tiff --with-png-dir=/opt/libpng --with-zlib-dir=/opt/zlib --with-gd --enable-gd-native-ttf --enable-exif --with-pdflib=/opt/pdflib --enable-bcmath --with-ming=/opt/ming --with-bz2=/opt/bzip2 --with-zlib --with-dom=/opt/libxml2 --with-dom-xslt=/opt/libxslt --with-dom-exslt=/opt/libxslt --enable-xslt --with-xslt-sablot=/opt/sablotron --with-expat-dir=/opt/expat --with-ldap=/opt/openldap --with-mcal=/opt/libmcal --with-curl=/opt/curl-7.10.2 --with-iconv=/opt/libiconv --enable-mbstring --with-zip=/opt/zziplib Olivier -- Edit bug report at http://bugs.php.net/?id=21615edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21615r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21615r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21615r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21615r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21615r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21615r=support Expected behavior: http://bugs.php.net/fix.php?id=21615r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21615r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21615r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21615r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21615r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21615r=dst IIS Stability: http://bugs.php.net/fix.php?id=21615r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21615r=gnused
#21616 [NEW]: encoding error in attributes with result_dump_*
From: [EMAIL PROTECTED] Operating system: linux PHP version: 4.3.0 PHP Bug Type: DOM XML related Bug description: encoding error in attributes with result_dump_* encoding error in attributes with result_dump_* when xsl:output method=html encoding=windows-1251/ characters in win-1251 encoding presented in href, src, .. html attributes encode into %HEX sequence incorrectly -- Edit bug report at http://bugs.php.net/?id=21616edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21616r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21616r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21616r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21616r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21616r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21616r=support Expected behavior: http://bugs.php.net/fix.php?id=21616r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21616r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21616r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21616r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21616r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21616r=dst IIS Stability: http://bugs.php.net/fix.php?id=21616r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21616r=gnused
#20426 [Com]: php.exe refused to end process: can not close connection to MSSQL
ID: 20426 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: MSSQL related Operating System: Windows 2000 Server PHP Version: 4.30 New Comment: I got the same problem on a w2k machine as well i'm using a mysql database. I got as well a smallinteger in my table. If i don't get many hits it survives. But when the hits increase (don't know at which point) PHP crashes i'm still working on it Previous Comments: [2003-01-03 00:03:25] [EMAIL PROTECTED] OK... here goes more detail... Just tried PHP 4.30 ISAPI mode. It still crashed, but now it would response messages like this: PHP has encountered an Access Violation at 77FCB032 And more crashing condition: In both CGI and ISAPI mode, PHP will crash when executing select * from any table that contains ONE, TWO OR MORE datetime/smalldatetime format columns THAT THERE IS ANY OTHER COLUMN BEHIND these datetime columns. for example: example_table ( sn int, title varchar(40), modifytime datetime ); Executing SELECT sn, title, modifytime FROM example_table will be okay, but executing SELECT sn, modifytime, title FROM example_table will crash. [2003-01-02 23:11:12] [EMAIL PROTECTED] For more detailed information: 1. On Trad. Chinese version Windows 2000 with Trad. Chinese MSSQL 2000, I will get date format like '2003-01-06 10:23:00' when I execute select * in Quary Analyzer. But I will get response like '2003 ¤@¤ë 06 10:23 ¤W¤È' when executing the same query with PHP. 2. I've tried to change date/number format settings in Windowd Location control panel, not working. 3. I've tried to change database default encoding, not working. 4. I've tried to add mssql.datetimeconvert=0 AND mssql.datetimeconvert=Off in php.ini, not working. 5. The ONLY way to alter the date-format converting style of php_mssql is to change the default language script of Windows 2000. For detailed description of the crashing problem: 1. When executing select * from any table that contains ONE datetime/smalldatetime format column, PHP will execute and output text to browser. But that php.exe process will not end, neither calling mssql_close() nor not. You can see it in the Task Manager, and it can not be stopper by clicking End Process. 2. When executing select * from any table that contains TWO OR MORE datetime/smalldatetime format column, PHP will crashed upon calling mssql_query. Again, that php.exe process will not quit and can not be forced quit using Task Manager. 3. By switching Windows 2000 default script to Japaness, all this problem disappears. 4. I've tried ALL other data format. None would cause crashing like this. Now I'm 100% sure this IS a date-format converting bug. And now I'm just asking for one thing: to disable this feature. Please! I beg you! [2003-01-02 22:23:39] [EMAIL PROTECTED] OK... I've Just installed latest PHP 4.30, and the crashing problem is getting WORSE! Now PHP will crash whenever I just execute select * from any table that contains two or more datetime/smalldatetime columns. Again, this crashing situation disappears when I switch default script of Windows2000 to Japaness. But I can not tell my customers to do this. Could you nice guys just DISABLE the auto date format converting feature ? To us, this is not a feature; it's a CURSE! [2002-11-26 20:03:47] [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. [2002-11-15 01:36:34] [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 you don't need to open new reports, you can reclassify them..(and this belongs in mssql) 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/20426 -- Edit this bug report at http://bugs.php.net/?id=20426edit=1
#21543 [Fbk-Opn]: unsupported field type errors with lvarchars
ID: 21543 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Informix related Operating System: All PHP Version: 4.3.0 New Comment: sorry, it seems that i had a problem submitting the answer a few days ago. here is the version info from out RH8 linux box: # $INFORMIXDIR/bin/esql -V IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.UC2 Software Serial Number RDS#. Previous Comments: [2003-01-09 19:55:28] [EMAIL PROTECTED] What is the output of 'esql -V' for you to require this? The version detection works fine here.. (and what OS? Is it GNU sed you have there?) [2003-01-09 06:26:59] [EMAIL PROTECTED] lvarchars are not supported, because 'ext/informix/config.m4' gets a wrong version number from 'esql -V'. So HAVE_IFX_IUS is not set. with this patch the problem should be solved: --- php-4.3.0/ext/informix/config.m4.org2003-01-09 11:15:07.0 +0100 +++ php-4.3.0/ext/informix/config.m42003-01-09 11:15:11.0 +0100 @@ -44,7 +44,7 @@ esac AC_MSG_CHECKING([Informix version]) - IFX_VERSION=[`$INFORMIXDIR/bin/esql -V | sed -ne '1 s/^[^0-9]*\([0-9]\)\.\([0-9]*\).*/\1\2/p'`] + IFX_VERSION=[`$INFORMIXDIR/bin/esql -V | sed -ne '1 s/^.*Version \([0-9]\)\.\([0-9]*\).*$/\1\2/p'`] AC_MSG_RESULT($IFX_VERSION) AC_DEFINE_UNQUOTED(IFX_VERSION, $IFX_VERSION, [ ]) Oliver -- Edit this bug report at http://bugs.php.net/?id=21543edit=1
#21615 [Opn-Fbk]: PCRE segfault with (very) large string.
ID: 21615 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: GNU/linux PHP Version: 4.3.0 New Comment: Cannot download the test script due to what appears to be a parse error. Could you please make the file avaliable as text (.txt). Previous Comments: [2003-01-13 07:51:41] [EMAIL PROTECTED] PCRE segfault on a big regular expression on a really big string (17490 chars) special parameters in php.ini file: memory_limit = 64M test script: http://planet-service.fr/test2.php.gz this script test a substring of the crashing string. a loop do the test with this substring, and increase the size of the string at each step and print out the size. I put 17490 as starting size as that crash at 17491. The parameters at at the end of the script (after the string itself). compilation options: ./configure --prefix=/opt/php-4.3.0 --with-apache=../apache_1.3.27 --with-config-file-path=/opt/php-4.3.0/lib --enable-calendar --enable-track-vars --enable-ftp --with-readline --with-imap=/opt/c-client --with-openssl=/opt/openssl --with -gdbm=/usr --with-mysql=/opt/mysql --with-pgsql=/opt/postgresql --enable-trans-sid -with-regex=php --enable-sysvsem --enable-sysvshm --enable-memory-limit --enable-debug=no --with-ttf=/opt/freetype --with-t1lib=/opt/t1lib --with-xml --enable-sockets --with-jpeg-dir=/opt/jpeg --with-tiff-dir=/opt/tiff --with-png-dir=/opt/libpng --with-zlib-dir=/opt/zlib --with-gd --enable-gd-native-ttf --enable-exif --with-pdflib=/opt/pdflib --enable-bcmath --with-ming=/opt/ming --with-bz2=/opt/bzip2 --with-zlib --with-dom=/opt/libxml2 --with-dom-xslt=/opt/libxslt --with-dom-exslt=/opt/libxslt --enable-xslt --with-xslt-sablot=/opt/sablotron --with-expat-dir=/opt/expat --with-ldap=/opt/openldap --with-mcal=/opt/libmcal --with-curl=/opt/curl-7.10.2 --with-iconv=/opt/libiconv --enable-mbstring --with-zip=/opt/zziplib Olivier -- Edit this bug report at http://bugs.php.net/?id=21615edit=1
#21569 [Com]: PHP can't set cookies after a test with an unset variable
ID: 21569
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
This is a shortest example:
?
# $test=;
setcookie(debug,1,0,,);
if ($test==) { echo ; }
setcookie(debug,3,0,,);
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
Previous Comments:
[2003-01-10 13:14:02] [EMAIL PROTECTED]
I've submitted a specific bug. It depends either from PHP or Windows
2000 itself in some way, because I've tested it deeply in many
configurations of operating systems, Apache and PHP versions.
The sample code provided is a proof of concept, not a code I'm asking
advice about.
[2003-01-10 12:56:40] [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-10 12:55:06] [EMAIL PROTECTED]
PHP can't set cookies on Windows 2000 systems after testing a
non-existing variable.
This problem was reported in the following conditions:
- Windows 2000 server SP-3 (IIS not installed)
- Apache v2.0.43 (confirmed on Apache v1.3.27 as well)
- PHP 4.3.0 (confirmed on 4.2.2 and 4.2.3 as well)
The problem happens with Windows 2000 only. On Windows 98 with the very
same configuration, or on Linux, everything works fine.
Try the following code:
?
# $test=X;
setcookie(debug,1,time()+60*60*24*30,,);
if ($test==) {setcookie(debug,2,time()+60*60*24*30,,);}
setcookie(debug,3,time()+60*60*24*30,,);
?
HTML
HEAD
TITLEw2k/PHP setcookie bug test/TITLE
/HEAD
BODY
BEGINBR
?
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
ENDBR
/BODY
/HTML
When $test is not set, the cookie debug remains set to 1, while when
$test is set to any value (including , an empty string), cookie will
be eventually properly set to 3.
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#21569 [Com]: PHP can't set cookies after a test with an unset variable
ID: 21569
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
I've found out that the problem is not limited to tests. It happens
every time you invoke an unset variable before than setting a cookie.
In the previous example, try
$a = $test;
instead of
if ($test==) { echo ; }
and the setcookie won't work as well.
Previous Comments:
[2003-01-13 10:03:29] [EMAIL PROTECTED]
This is a shortest example:
?
# $test=;
setcookie(debug,1,0,,);
if ($test==) { echo ; }
setcookie(debug,3,0,,);
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
[2003-01-10 13:14:02] [EMAIL PROTECTED]
I've submitted a specific bug. It depends either from PHP or Windows
2000 itself in some way, because I've tested it deeply in many
configurations of operating systems, Apache and PHP versions.
The sample code provided is a proof of concept, not a code I'm asking
advice about.
[2003-01-10 12:56:40] [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-10 12:55:06] [EMAIL PROTECTED]
PHP can't set cookies on Windows 2000 systems after testing a
non-existing variable.
This problem was reported in the following conditions:
- Windows 2000 server SP-3 (IIS not installed)
- Apache v2.0.43 (confirmed on Apache v1.3.27 as well)
- PHP 4.3.0 (confirmed on 4.2.2 and 4.2.3 as well)
The problem happens with Windows 2000 only. On Windows 98 with the very
same configuration, or on Linux, everything works fine.
Try the following code:
?
# $test=X;
setcookie(debug,1,time()+60*60*24*30,,);
if ($test==) {setcookie(debug,2,time()+60*60*24*30,,);}
setcookie(debug,3,time()+60*60*24*30,,);
?
HTML
HEAD
TITLEw2k/PHP setcookie bug test/TITLE
/HEAD
BODY
BEGINBR
?
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
ENDBR
/BODY
/HTML
When $test is not set, the cookie debug remains set to 1, while when
$test is set to any value (including , an empty string), cookie will
be eventually properly set to 3.
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#21569 [Com]: PHP can't set cookies after a test with an unset variable
ID: 21569
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
Workaround (which doesn't mean this bug shouldn't be fixed):
To perform tests:
if (!isset($test) || $test==) { echo ; }
To set a variable:
$a=; if (isset($test)) { $a=$test; }
Previous Comments:
[2003-01-13 10:05:53] [EMAIL PROTECTED]
I've found out that the problem is not limited to tests. It happens
every time you invoke an unset variable before than setting a cookie.
In the previous example, try
$a = $test;
instead of
if ($test==) { echo ; }
and the setcookie won't work as well.
[2003-01-13 10:03:29] [EMAIL PROTECTED]
This is a shortest example:
?
# $test=;
setcookie(debug,1,0,,);
if ($test==) { echo ; }
setcookie(debug,3,0,,);
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
[2003-01-10 13:14:02] [EMAIL PROTECTED]
I've submitted a specific bug. It depends either from PHP or Windows
2000 itself in some way, because I've tested it deeply in many
configurations of operating systems, Apache and PHP versions.
The sample code provided is a proof of concept, not a code I'm asking
advice about.
[2003-01-10 12:56:40] [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-10 12:55:06] [EMAIL PROTECTED]
PHP can't set cookies on Windows 2000 systems after testing a
non-existing variable.
This problem was reported in the following conditions:
- Windows 2000 server SP-3 (IIS not installed)
- Apache v2.0.43 (confirmed on Apache v1.3.27 as well)
- PHP 4.3.0 (confirmed on 4.2.2 and 4.2.3 as well)
The problem happens with Windows 2000 only. On Windows 98 with the very
same configuration, or on Linux, everything works fine.
Try the following code:
?
# $test=X;
setcookie(debug,1,time()+60*60*24*30,,);
if ($test==) {setcookie(debug,2,time()+60*60*24*30,,);}
setcookie(debug,3,time()+60*60*24*30,,);
?
HTML
HEAD
TITLEw2k/PHP setcookie bug test/TITLE
/HEAD
BODY
BEGINBR
?
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
ENDBR
/BODY
/HTML
When $test is not set, the cookie debug remains set to 1, while when
$test is set to any value (including , an empty string), cookie will
be eventually properly set to 3.
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#21546 [Asn-Csd]: parse_ini_file() sends warning if the file is malformed
ID: 21546 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Unknown/Other Function Operating System: Linux PHP Version: 4.3.0 Assigned To: derick 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-01-09 15:38:24] [EMAIL PROTECTED] needs some thing how to do it cleanly, will sleep over it :-) [2003-01-09 15:26:15] [EMAIL PROTECTED] bullshit nicos, this is a bug. It does not terminate at all, you modified the docs in a wrong way. It's still a bug, the warning should be silenced. reopening [2003-01-09 09:24: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. [2003-01-09 08:59:24] [EMAIL PROTECTED] This is an excepted behaviour. Changing this to a documentation problem (even if it says already that PHP will quit if the file is malformed). [2003-01-09 06:47:59] [EMAIL PROTECTED] parse_ini_file() outputs Warning: Error parsing /file2parse.ini ... if there is more than one = in a config line. PHP ignores error_reporting(0) and @parse_ini_file(). -- Edit this bug report at http://bugs.php.net/?id=21546edit=1
#18644 [Com]: bc_math.log linker error
ID: 18644 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Compile Failure Operating System: AIX 4.3.3 PHP Version: 4-STABLE-CVS-20020820 New Comment: ld: 0711-161 ERROR: File ext/ctype/ctype.lo cannot be processed. The file was found to be truncated and is being ignored. collect2: ld returned 8ld exit status: 0711-161 ERROR: File ext/ctype/ctype.lo cannot be processed. The file was found to be truncated and is being ignored. collect2: ld returned 8 exit status I get this error when compiling php 4.3.0 or the cvs snapshot for today (jan 13th 2003) on AIX 5.2, sounds like the same error but the latest snapshot does not fix it. gcc-2.9.aix51.020209-1 libtool-1.4.2-1 make-3.79.1-3 automake-1.5-1 autoconf-2.53-1 If anyone knows how to get past this please email me [EMAIL PROTECTED] Previous Comments: [2002-11-01 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. [2002-10-16 14:29:07] [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-08-20 18:49:05] [EMAIL PROTECTED] Hmm, now the STABLE branch also gives an error, since today. Seems that permissions are set without a read flag, resulting in a permission defined when linking. autoconf 2.13, automake 1.5 and libtool 1.4. mdev@femke ~/_src/php-STABLE $ ls -al ext/bcmath/libbcmath/.libs/libbcmath.lax/libbcmath.a total 208 drwxr-xr-x 2 mdev staff512 Aug 21 00:33 . drwxr-xr-x 3 mdev staff512 Aug 21 00:33 .. --w-w- 1 mdev staff 1487 Aug 21 00:33 add.o --w-w- 1 mdev staff 1504 Aug 21 00:33 compare.o --w-w- 1 mdev staff 1908 Aug 21 00:33 debug.o --w-w- 1 mdev staff 3483 Aug 21 00:33 div.o --w-w- 1 mdev staff 1813 Aug 21 00:33 divmod.o --w-w- 1 mdev staff 2574 Aug 21 00:33 doaddsub.o --w-w- 1 mdev staff 2728 Aug 21 00:33 init.o --w-w- 1 mdev staff 1259 Aug 21 00:33 int2num.o --w-w- 1 mdev staff945 Aug 21 00:33 nearzero.o --w-w- 1 mdev staff823 Aug 21 00:33 neg.o --w-w- 1 mdev staff957 Aug 21 00:33 num2long.o --w-w- 1 mdev staff 1218 Aug 21 00:33 num2str.o --w-w- 1 mdev staff 1191 Aug 21 00:33 outofmem.o --w-w- 1 mdev staff 4058 Aug 21 00:33 output.o --w-w- 1 mdev staff 2216 Aug 21 00:33 raise.o --w-w- 1 mdev staff 2600 Aug 21 00:33 raisemod.o --w-w- 1 mdev staff 5610 Aug 21 00:33 recmul.o --w-w- 1 mdev staff920 Aug 21 00:33 rmzero.o --w-w- 1 mdev staff 1643 Aug 21 00:33 rt.o --w-w- 1 mdev staff 2666 Aug 21 00:33 sqrt.o --w-w- 1 mdev staff 1758 Aug 21 00:33 str2num.o --w-w- 1 mdev staff 1503 Aug 21 00:33 sub.o --w-w- 1 mdev staff982 Aug 21 00:33 zero.o [2002-08-11 12:02:29] [EMAIL PROTECTED] do you still have this problem with current cvs-version? [2002-07-31 06:09:58] [EMAIL PROTECTED] I've written some testcases for myself. They all seem to work fine. 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/18644 -- Edit this bug report at http://bugs.php.net/?id=18644edit=1
#21569 [Com]: PHP can't set cookies after a test with an unset variable
ID: 21569
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
Workaround #2:
At the beginning og your script, declare any possibly unset variable
that will be invoked:
if (!isset($test)) {$test=;}
Previous Comments:
[2003-01-13 10:07:12] [EMAIL PROTECTED]
Workaround (which doesn't mean this bug shouldn't be fixed):
To perform tests:
if (!isset($test) || $test==) { echo ; }
To set a variable:
$a=; if (isset($test)) { $a=$test; }
[2003-01-13 10:05:53] [EMAIL PROTECTED]
I've found out that the problem is not limited to tests. It happens
every time you invoke an unset variable before than setting a cookie.
In the previous example, try
$a = $test;
instead of
if ($test==) { echo ; }
and the setcookie won't work as well.
[2003-01-13 10:03:29] [EMAIL PROTECTED]
This is a shortest example:
?
# $test=;
setcookie(debug,1,0,,);
if ($test==) { echo ; }
setcookie(debug,3,0,,);
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
[2003-01-10 13:14:02] [EMAIL PROTECTED]
I've submitted a specific bug. It depends either from PHP or Windows
2000 itself in some way, because I've tested it deeply in many
configurations of operating systems, Apache and PHP versions.
The sample code provided is a proof of concept, not a code I'm asking
advice about.
[2003-01-10 12:56:40] [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.
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/21569
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#21615 [Com]: PCRE segfault with (very) large string.
ID: 21615 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: GNU/linux PHP Version: 4.3.0 New Comment: I'm really sorry: http://planet-service.fr/test2.php.gz Previous Comments: [2003-01-13 09:53:25] [EMAIL PROTECTED] Cannot download the test script due to what appears to be a parse error. Could you please make the file avaliable as text (.txt). [2003-01-13 07:51:41] [EMAIL PROTECTED] PCRE segfault on a big regular expression on a really big string (17490 chars) special parameters in php.ini file: memory_limit = 64M test script: http://planet-service.fr/test2.php.gz this script test a substring of the crashing string. a loop do the test with this substring, and increase the size of the string at each step and print out the size. I put 17490 as starting size as that crash at 17491. The parameters at at the end of the script (after the string itself). compilation options: ./configure --prefix=/opt/php-4.3.0 --with-apache=../apache_1.3.27 --with-config-file-path=/opt/php-4.3.0/lib --enable-calendar --enable-track-vars --enable-ftp --with-readline --with-imap=/opt/c-client --with-openssl=/opt/openssl --with -gdbm=/usr --with-mysql=/opt/mysql --with-pgsql=/opt/postgresql --enable-trans-sid -with-regex=php --enable-sysvsem --enable-sysvshm --enable-memory-limit --enable-debug=no --with-ttf=/opt/freetype --with-t1lib=/opt/t1lib --with-xml --enable-sockets --with-jpeg-dir=/opt/jpeg --with-tiff-dir=/opt/tiff --with-png-dir=/opt/libpng --with-zlib-dir=/opt/zlib --with-gd --enable-gd-native-ttf --enable-exif --with-pdflib=/opt/pdflib --enable-bcmath --with-ming=/opt/ming --with-bz2=/opt/bzip2 --with-zlib --with-dom=/opt/libxml2 --with-dom-xslt=/opt/libxslt --with-dom-exslt=/opt/libxslt --enable-xslt --with-xslt-sablot=/opt/sablotron --with-expat-dir=/opt/expat --with-ldap=/opt/openldap --with-mcal=/opt/libmcal --with-curl=/opt/curl-7.10.2 --with-iconv=/opt/libiconv --enable-mbstring --with-zip=/opt/zziplib Olivier -- Edit this bug report at http://bugs.php.net/?id=21615edit=1
#21615 [Com]: PCRE segfault with (very) large string.
ID: 21615 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: Reproducible crash Operating System: GNU/linux PHP Version: 4.3.0 New Comment: oops: http://planet-service.fr/test2.txt.gz Previous Comments: [2003-01-13 10:55:35] [EMAIL PROTECTED] I'm really sorry: http://planet-service.fr/test2.php.gz [2003-01-13 09:53:25] [EMAIL PROTECTED] Cannot download the test script due to what appears to be a parse error. Could you please make the file avaliable as text (.txt). [2003-01-13 07:51:41] [EMAIL PROTECTED] PCRE segfault on a big regular expression on a really big string (17490 chars) special parameters in php.ini file: memory_limit = 64M test script: http://planet-service.fr/test2.php.gz this script test a substring of the crashing string. a loop do the test with this substring, and increase the size of the string at each step and print out the size. I put 17490 as starting size as that crash at 17491. The parameters at at the end of the script (after the string itself). compilation options: ./configure --prefix=/opt/php-4.3.0 --with-apache=../apache_1.3.27 --with-config-file-path=/opt/php-4.3.0/lib --enable-calendar --enable-track-vars --enable-ftp --with-readline --with-imap=/opt/c-client --with-openssl=/opt/openssl --with -gdbm=/usr --with-mysql=/opt/mysql --with-pgsql=/opt/postgresql --enable-trans-sid -with-regex=php --enable-sysvsem --enable-sysvshm --enable-memory-limit --enable-debug=no --with-ttf=/opt/freetype --with-t1lib=/opt/t1lib --with-xml --enable-sockets --with-jpeg-dir=/opt/jpeg --with-tiff-dir=/opt/tiff --with-png-dir=/opt/libpng --with-zlib-dir=/opt/zlib --with-gd --enable-gd-native-ttf --enable-exif --with-pdflib=/opt/pdflib --enable-bcmath --with-ming=/opt/ming --with-bz2=/opt/bzip2 --with-zlib --with-dom=/opt/libxml2 --with-dom-xslt=/opt/libxslt --with-dom-exslt=/opt/libxslt --enable-xslt --with-xslt-sablot=/opt/sablotron --with-expat-dir=/opt/expat --with-ldap=/opt/openldap --with-mcal=/opt/libmcal --with-curl=/opt/curl-7.10.2 --with-iconv=/opt/libiconv --enable-mbstring --with-zip=/opt/zziplib Olivier -- Edit this bug report at http://bugs.php.net/?id=21615edit=1
#21618 [NEW]: fopen on no existing files generates unexpected output.
From: [EMAIL PROTECTED]
Operating system: Apache on RedHat Linux
PHP version: 4.2.3
PHP Bug Type: *General Issues
Bug description: fopen on no existing files generates unexpected output.
I planned to use the following function testing for a flag file
'offline_message.txt' to disable my application and contain an offline
message.
function isOffLine() {
global $OffLineMessage;
$OffLineMessage = ;
$OffLineFilename = offline_message.txt ;
if (!($fp = fopen($OffLineFilename, r))) {
return false;
} else {
$OffLineMessage = file( $OffLineFilename ) ;
return true;
}
}
However bothe the fopen file functions generates an unexpected and
unwanted warning messages to the output stream.
Warning: fopen(offline_message.txt, r) - No such file or directory in
/var/www/html/webmail/common.php on line 104
Warning: file(offline_message.txt) - No such file or directory in
/var/www/html/webmail/common.php on line 105
--
Edit bug report at http://bugs.php.net/?id=21618edit=1
--
Try a CVS snapshot: http://bugs.php.net/fix.php?id=21618r=trysnapshot
Fixed in CVS: http://bugs.php.net/fix.php?id=21618r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=21618r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=21618r=needtrace
Try newer version: http://bugs.php.net/fix.php?id=21618r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=21618r=support
Expected behavior: http://bugs.php.net/fix.php?id=21618r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=21618r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=21618r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=21618r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21618r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=21618r=dst
IIS Stability: http://bugs.php.net/fix.php?id=21618r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=21618r=gnused
#21575 [Com]: 4.2x to 4.3 Compatibility issue
ID: 21575 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: IIS related Operating System: Any PHP Version: 4.3.0 New Comment: register globals has nothing to do with this. For 4.3, cgi variables were changed to correctly conform to cgi specs. This means that PATH_INFO is now in fact PATH_INFO as per: http://hostname/script_name.php/path/info?query_string Use SCRIPT_NAME or PHP_SELF if you need to refer to /script_name.php, and use SCRIPT_FILENAME if you need to get the full path to script_name.php Previous Comments: [2003-01-13 06:15:51] [EMAIL PROTECTED] In PHP 4.2.0, the 'register_globals' setting default changed to 'off'. See http://www.php.net/release_4_2_0.php for more info. We are sorry about the inconvenience, but this change was a necessary part of our efforts to make PHP scripting more secure and portable. [2003-01-13 05:30:53] [EMAIL PROTECTED] How can a PHP variable which existed when running 4.2.3 then disappears, without a mention that it was going to, when running 4.3.0 not be considered a bug? I have the same problem here. Yes, PHP has to rely on the server environment for the values to the PHP Variables, but if one version of PHP can see it and a newer one cannot, then surely the code has been modified incorrectly in the newer version. Nothing else has changed on my server - I can easily test this by having PHP in two different directories, PHP.4.2.3 and PHP.4.3.0. Naming each to PHP in turn and running the phpinfo() command produces a version with PHP_INFO, i.e. for 4.2.3 and one without, for 4.3.0 Regards, Taomyn [2003-01-11 12:15:55] [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. php.ini settings do not have any impact on the enviroment variables. PHP will automatically gather all avaliable enviroment variables and make then avaliable to you, if an enviroment variable does not exist it simply means it is not set. In which case PHP cannot make it avaliable to you. [2003-01-11 06:37:21] [EMAIL PROTECTED] I'm using Windows 2000 with IIS 5, and I've tried both CGI and ISAPI mode. I updated my server to PHP4.30 on 2 Jan, as you may notice in another bug-report I submitted ( http:// bugs.php.net/bug.php?id=20426 ). I did not run Windows Update this week, and I disabled auto-update service since I don't trust Microsoft. :-) Anyway, it should not be called as 'bug', and I have not trouble to modify my codes (just find/replace PATH_INFO with PHP_SELF.) I'm just curious about what is going on. Does PHP.INI would affect environment variables ? I'm using all default settings but enabling register_globals. [2003-01-10 21:54:37] [EMAIL PROTECTED] Environment variables are supplied by the environment under which PHP is running. In most cases this means the webserver. Did you change/upgrade your webserver at the same time? Moreover, what webserver are you running and on what OS? 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/21575 -- Edit this bug report at http://bugs.php.net/?id=21575edit=1
#20497 [Com]: Will not compile Output line too long
ID: 20497 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: No Feedback Bug Type: Compile Failure Operating System: solaris 8 PHP Version: 4.3.0RC1 New Comment: I currently have the same problem on Solaris 8 (MU7), apache-httpd 2.0.43 und php 4.3.0 (as dynamic module). Shouldn't it work with the sed shipped with Solaris? Maybe we should send SUN a bug report if something is wrong with their implementation of sed. Previous Comments: [2003-01-07 13:35:25] [EMAIL PROTECTED] After reading your comments, I installed GNU sed from sunfreeware.com. PHP is now compiled properly. Thank you for this information. [2002-12-01 16:39:00] [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. [2002-11-19 12:20:34] [EMAIL PROTECTED] Can you first check why the sed check didn't break the configure, from config.log, look for something like this: configure:1579: checking for working sed (to 'fix' this problem, install GNU sed) [2002-11-19 11:46:09] [EMAIL PROTECTED] Gcc 3.1, apache 2.0.43 solaris 8 The configure line ./configure --enable-ftp --enable-bcmath --enable-calendar --with-mysql --with-mhash --with-mcrypt --with-ldap=/usr/local --with-apxs2=/www/bin/apxs --with-imap=/export/home/test/imap-2002.RC10 --with-zlib --with-gdbm --with-ndbm --with-gettext --enable-force-cgi-redirect then I ran make and this is were it ended. cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -avoid-version -module -L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/local/lib -L/export/home/test/imap-2002.RC10/c-client -R /usr/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -R /usr/local/lib -R /export/home/test/imap-2002.RC10/c-client 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/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db3.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gettext/gettext.lo ext/imap/php_imap.lo ext/ldap/ldap.lo ext/mcrypt/mcrypt.lo ext/mhash/mhash.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo ext/mysql/libmysql/typelib.lo ext/mysql/libmysql/safemalloc.lo ext/mysql/libmysql/my_alloc.lo ext/mysql/libmysql/mf_format.lo ext/mysql/libmysql/mf_path.lo ext/mysql/libmysql/mf_unixpath.lo ext/mysql/libmysql/my_fopen.lo ext/mysql/libmysql/mf_loadpath.lo ext/mysql/libmysql/my_pthread.lo ext/mysql/libmysql/my_thr_init.lo
#20441 [Com]: PHP_AUTH_USER isn't set
ID: 20441 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache related Operating System: all PHP Version: 4.3.0 New Comment: The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a form action=XXX method=post. With method=get it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method=get option is a workaround, but this does not work in upload scripts, which has to use post. Is this a new bug? Previous Comments: [2002-12-21 15:16:22] [EMAIL PROTECTED] It has been agreed in php-dev to keep the PHP_AUTH_* variables but to disable them when in safe mode. This change was made after 4.3.0-RC4 but will exist in PHP 4.3.0. This is from the PHP 4.3.0 NEWS: Make PHP_AUTH_* variables not available in safe mode under Apache when an external basic auth mechanism is used. (Philip) REMOTE_USER will exist regardless. In the future, a new ini directive such as expose_php_auth_vars may be available. The docs will be updated. [2002-12-18 15:21:10] [EMAIL PROTECTED] This needs to be fixed before 4.3 goes out. While it is of course important to improve the code and iron out long standing errors, we must not forget that our users rely on the old behaviour. The default behaviour of 4.3 should be the same as in old versions. [2002-12-18 13:29:19] [EMAIL PROTECTED] This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out. I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this. I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour is widely relied upon, and perhaps we should consider an php.ini switch. The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour. [2002-12-11 10:58:19] [EMAIL PROTECTED] We fixed a bug, period. Derick [2002-12-11 10:53:53] [EMAIL PROTECTED] Can someone explain this? Apparently some external auth systems did not populate PHP_AUTH_USER while others did... Was this BC break discussed? It has been documented forever but this behavior changed so please explain it. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/20441 -- Edit this bug report at http://bugs.php.net/?id=20441edit=1
#20497 [NoF-Opn]: Will not compile Output line too long
ID: 20497 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Open Bug Type: Compile Failure Operating System: solaris 8 PHP Version: 4.3.0RC1 New Comment: When I upgraded the sed it worked, I think that SUN should .know about this this should not be the case!! sed functionality should be the same across the board. -Ian [EMAIL PROTECTED] Previous Comments: [2003-01-13 11:29:26] [EMAIL PROTECTED] I currently have the same problem on Solaris 8 (MU7), apache-httpd 2.0.43 und php 4.3.0 (as dynamic module). Shouldn't it work with the sed shipped with Solaris? Maybe we should send SUN a bug report if something is wrong with their implementation of sed. [2003-01-07 13:35:25] [EMAIL PROTECTED] After reading your comments, I installed GNU sed from sunfreeware.com. PHP is now compiled properly. Thank you for this information. [2002-12-01 16:39:00] [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. [2002-11-19 12:20:34] [EMAIL PROTECTED] Can you first check why the sed check didn't break the configure, from config.log, look for something like this: configure:1579: checking for working sed (to 'fix' this problem, install GNU sed) [2002-11-19 11:46:09] [EMAIL PROTECTED] Gcc 3.1, apache 2.0.43 solaris 8 The configure line ./configure --enable-ftp --enable-bcmath --enable-calendar --with-mysql --with-mhash --with-mcrypt --with-ldap=/usr/local --with-apxs2=/www/bin/apxs --with-imap=/export/home/test/imap-2002.RC10 --with-zlib --with-gdbm --with-ndbm --with-gettext --enable-force-cgi-redirect then I ran make and this is were it ended. cc1: warning: changing search order for system directory /usr/local/include cc1: warning: as it has already been specified as a non-system directory /bin/sh libtool --silent --mode=link gcc -export-dynamic -g -O2 -avoid-version -module -L/usr/ucblib -L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -L/usr/local/lib -L/export/home/test/imap-2002.RC10/c-client -R /usr/ucblib -R /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.1 -R /usr/local/lib -R /export/home/test/imap-2002.RC10/c-client 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/calendar/calendar.lo ext/calendar/dow.lo ext/calendar/french.lo ext/calendar/gregor.lo ext/calendar/jewish.lo ext/calendar/julian.lo ext/calendar/easter.lo ext/calendar/cal_unix.lo ext/ctype/ctype.lo ext/dba/dba.lo ext/dba/dba_cdb.lo ext/dba/dba_db2.lo ext/dba/dba_dbm.lo ext/dba/dba_gdbm.lo ext/dba/dba_ndbm.lo ext/dba/dba_db3.lo ext/ftp/php_ftp.lo ext/ftp/ftp.lo ext/gettext/gettext.lo ext/imap/php_imap.lo ext/ldap/ldap.lo ext/mcrypt/mcrypt.lo ext/mhash/mhash.lo ext/mysql/php_mysql.lo ext/mysql/libmysql/libmysql.lo ext/mysql/libmysql/errmsg.lo ext/mysql/libmysql/net.lo ext/mysql/libmysql/violite.lo ext/mysql/libmysql/password.lo ext/mysql/libmysql/my_init.lo ext/mysql/libmysql/my_lib.lo ext/mysql/libmysql/my_static.lo ext/mysql/libmysql/my_malloc.lo ext/mysql/libmysql/my_realloc.lo ext/mysql/libmysql/my_create.lo ext/mysql/libmysql/my_delete.lo ext/mysql/libmysql/my_tempnam.lo ext/mysql/libmysql/my_open.lo ext/mysql/libmysql/mf_casecnv.lo ext/mysql/libmysql/my_read.lo ext/mysql/libmysql/my_write.lo ext/mysql/libmysql/errors.lo ext/mysql/libmysql/my_error.lo ext/mysql/libmysql/my_getwd.lo ext/mysql/libmysql/my_div.lo ext/mysql/libmysql/mf_pack.lo ext/mysql/libmysql/my_messnc.lo ext/mysql/libmysql/mf_dirname.lo ext/mysql/libmysql/mf_fn_ext.lo ext/mysql/libmysql/mf_wcomp.lo
#21620 [NEW]: $REMOTE_USER does not exist after a POST-request
From: [EMAIL PROTECTED] Operating system: Redhat 6.2 PHP version: 4.3.0 PHP Bug Type: Scripting Engine problem Bug description: $REMOTE_USER does not exist after a POST-request In PHP 4.3.0 in safe mode the $PHP_AUTH_* variables do not exist anymore. It is recommended to use $REMOTE_USER instead. The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a form action=XXX method=post. With method=get it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method=get option is a workaround, but this does not work in upload scripts, which has to use post. Is this a new bug? -- Edit bug report at http://bugs.php.net/?id=21620edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21620r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21620r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21620r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21620r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21620r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21620r=support Expected behavior: http://bugs.php.net/fix.php?id=21620r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21620r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21620r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21620r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21620r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21620r=dst IIS Stability: http://bugs.php.net/fix.php?id=21620r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21620r=gnused
#21261 [Com]: $_SERVER['PHP_SELF'] gives wrong info
ID: 21261 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: linux 2.4.18 - slack 8.1 PHP Version: 4.3.0 Assigned To: shane New Comment: That (or similar) urgent problem occurs here too. PHP versions before mid december were not affected IMO. At first today I've checked out the php4 and php5 modules from CVS, configured, and build them. After installation of the CGI binaries I detected a problem with $_SERVER['PHP_SELF']: a) the PHP4 version shows no value b) the PHP5 version shows illegal characters, cut off strings with low ASCII values etc. Depending on the namebased vhost name the value of PHP_SELF looks like ind## instead of index.php (# should represent low ASCII chars, which are shown as boxes here) of just 5 which is definitely the last char of index.php5. Short: looks like a pointer on a string array is bent somewhere. The problem insist with and without '--enable-force-cgi-redirect' in both versions. As an example you may want to take a look at http://daniel-gorski.de/index.php4 (PHP4 CGI) http://daniel-gorski.de/index.php5 (PHP5 CGI) and compare the values of $_SERVER['PHP_SELF']. Additionally the PHP5 version has a strange Zend Extension date: 90021012. OTOH this value seems to be correct in the PHP4 version. The operating system is Linux (RedHat 6.2). I would appreciate to see this bug solved as soon as possible, because this is a dramatic show stopper for a few ZE2 applications I am developing running. What required information can I provide to help to solve this problem? regards dtg Previous Comments: [2003-01-09 14:57:05] [EMAIL PROTECTED] Quick Dirty PHP-Based workaround: Put this code in a file and add it to auto_prepend_file-directive in php.ini: -snip // Small Workaround for a bug in PHP 4.3.0/cgi // See http://bugs.php.net/bug.php?id=21261 for details $_SERVER['SCRIPT_NAME'] = substr($_SERVER['PATH_TRANSLATED'], strlen($_SERVER['DOCUMENT_ROOT'])); $PHP_SELF = $SCRIPT_NAME = $_SERVER['PHP_SELF'] = $_SERVER['SCRIPT_NAME']; -snip Works fine for me... If PHP is used as CLI it may be neccessary to check current mode before running this code. [2003-01-07 13:30:23] [EMAIL PROTECTED] There is no space in SCRIPT_NAME on my localhost, this was an copypaste-error. But the I at the end exists. [2003-01-07 13:27:55] [EMAIL PROTECTED] Same for me, your patch seems to have no affect. I checked the debugging output from cgiwrap which says: [...] Fixing Environment Variables. Environment Variables: QUERY_STRING: '' SCRIPT_NAME: '/phpinfo.php' SCRIPT_FILENAME: 'DOCUMENT_ROOT/phpinfo.php' REDIRECT_URL: 'NULL' PATH_INFO: '/phpinfo.php' PATH_TRANSLATED: 'DOCUMENT_ROOT/phpinfo.php' REMOTE_USER: 'NULL' REMOTE_HOST: 'NULL' REMOTE_ADDR: '217.4.137.70' [...] Seems to be ok?! But PHP_SELF has no value. On my localhost PHP 4.3/CGI works with cgiwrap. The same paragraph with this machine: [...] Fixing Environment Variables. Environment Variables: QUERY_STRING: '' SCRIPT_NAME: '/php/ phpinfo.phpI' SCRIPT_FILENAME: 'DOCUMENT_ROOT/php/phpinfo.php' REDIRECT_URL: '' PATH_INFO: '/php/phpinfo.php' PATH_TRANSLATED: 'DOCUMENT_ROOT/php/phpinfo.php' REMOTE_USER: '' REMOTE_HOST: '' REMOTE_ADDR: '192.168.23.2' [...] In this case, script_name is broken for some reason (don't ask me why, i didn't find out). But PHP_SELF has the correct value! On both server SCRIPT_NAME isn't listed in the phpinfo()-Output. Hope this will help. [2003-01-07 00:42:23] [EMAIL PROTECTED] [EMAIL PROTECTED]: email me your httpd.conf, php.ini and the test script you use. You can remove anything from the files that are private. Also, as per spec PATH_TRANSLATED will be empty unless you have PATH_INFO, which is path data *after* the script in a url: http://host/script.php/path/info?query-string The only thing I'm concerned about is the garbled PHP_SELF. PHP_SELF is the same as SCRIPT_NAME, is SCRIPT_NAME also garbled? [2003-01-06 11:06:47] [EMAIL PROTECTED] Negative. Patch not only did not work (I applied it to current 4.3.0) but I now no longer have a $_SERVER['PATH_TRANSLATED'] variable . So $_SERVER['PHP_SELF'] remains corrupted and $_SERVER['PATH_TRANSLATED'] gives some kind of udefined error. Joshua
#21151 [Com]: zlib and pcre as external modules don't work
ID: 21151 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Dynamic loading Operating System: Mandrake 9.0 PHP Version: 4.3.0RC4 New Comment: Jean-Michel Yes I am ;) But if these extensions can't be built as a loadable dso, you shouldn't be able to use =shared. This is really extreme stuff and I doubt people would use this configure line. Previous Comments: [2003-01-07 10:27:49] [EMAIL PROTECTED] Confirmed same issue on Solaris 8 for version 4.3.0. I do agree that zlib is not that large and can be compiled into php (hit after reading that suggestion!) but still the option is there and does not work... [2003-01-03 02:26:36] [EMAIL PROTECTED] Oden, you're a modularization maniac ;-) Some extensions, like ftp, session, zlib and pcre should really remain in the PHP core, since: 1) they don't need extra libraries (try to install an RPM without libz.so ;-) 2) they are really small and don't add extra weigth to PHP 3) users need them and will complain if they're not installed by default (trust me on this one!) Jean-Michel [2002-12-23 02:53:24] [EMAIL PROTECTED] Too many modules rely on zlib and pcre, the best thing would be to disallow them to be compiled as shared module. For now: just don't do it :) Derick [2002-12-22 19:18:39] [EMAIL PROTECTED] Hi. zlib and pcre won't build as external modules. Here's my configure line: ./configure \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --datadir=/usr/share \ --sysconfdir=/etc \ --libdir=/usr/lib \ --includedir=/usr/include \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --with-apxs2=/usr/sbin/apxs \ --enable-force-cgi-redirect \ --enable-discard-path \ --enable-debug \ --with-layout=GNU \ --with-config-file-path=/etc \ --with-config-file-scan-dir=/etc/httpd/conf.d \ --with-pear=/usr/lib/php \ --enable-safe-mode \ --with-exec-dir=/usr/bin \ --enable-magic-quotes \ --disable-rpath \ --with-openssl=shared,/usr --with-zlib=shared,/usr --with-zlib-dir=/usr \ --enable-bcmath=shared \ --with-bz2=shared,/usr \ --enable-calendar=shared \ --without-cpdflib \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --without-crack \ --with-ctype=shared \ --with-curl=shared,/usr \ --without-cyrus \ --without-db \ --enable-dba=shared,/usr \ --with-gdbm=shared,/usr \ --without-ndbm \ --without-db2 \ --without-db3 \ --with-db4=shared,/usr \ --without-dbm \ --with-cdb=shared,/usr \ --with-flatfile=shared \ --enable-dbase=shared \ --enable-dbx=shared,/usr \ --enable-dio=shared,/usr \ --with-dom=shared,/usr --with-zlib-dir=/usr --with-dom-xslt=shared,/usr --with-dom-exslt=shared,/usr \ --enable-exif=shared \ --without-fbsql \ --without-fdftk \ --enable-filepro=shared \ --without-fribidi \ --enable-ftp=shared \ --with-gd=shared --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr/X11R6/lib/ \ --with-ttf=/usr \ --with-freetype-dir=/usr \ --with-t1lib=/usr \ --enable-gd-native-ttf \ --with-gettext=shared,/usr \ --with-gmp=shared,/usr \ --without-hwapi \ --without-hyperwave \ --without-iconv \ --with-imap=shared,/usr \ --without-kerberos \ --with-imap-ssl=shared,/usr \ --without-informix \ --without-ingres \ --without-interbase \ --without-ircg \ --with-ircg-config=/dev/null \ --without-java \ --with-ldap=shared,/usr \ --enable-mbstring=shared \ --enable-mbregex=shared \ --without-mcal \ --with-mcrypt=shared,/usr \ --without-mcve \ --with-mhash=shared,/usr \ --enable-mime-magic=shared \ --with-ming=shared,/usr \ --with-mnogosearch=shared,/usr \ --without-msession \ --without-msql \ --without-mssql \ --with-mysql=shared,/usr --with-mysql-sock=/var/lib/mysql/mysql.sock --with-zlib-dir=/usr \ --with-ncurses=shared,/usr \ --without-oci8 \ --without-adabas \ --without-sapdb \ --without-solid \ --without-ibm-db2 \ --without-empress \ --without-empress-bcs \ --without-birdstep \ --without-custom-odbc \ --without-iodbc \ --without-esoob \ --with-unixODBC=shared,/usr \ --without-openlink \ --without-dbmaker \ --without-oracle \ --enable-overload=shared \ --without-ovrimos \ --disable-pcntl \
#21620 [Opn-Fbk]: $REMOTE_USER does not exist after a POST-request
ID: 21620 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Redhat 6.2 PHP Version: 4.3.0 New Comment: Which web version of Apache? I don't see anything on the PHP side of things that would make this behave differently based on the request type. Previous Comments: [2003-01-13 11:36:29] [EMAIL PROTECTED] In PHP 4.3.0 in safe mode the $PHP_AUTH_* variables do not exist anymore. It is recommended to use $REMOTE_USER instead. The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a form action=XXX method=post. With method=get it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method=get option is a workaround, but this does not work in upload scripts, which has to use post. Is this a new bug? -- Edit this bug report at http://bugs.php.net/?id=21620edit=1
#21153 [Com]: readline won't be built as an external module
ID: 21153 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Readline related Operating System: Mandrake 9.0 PHP Version: 4.3.0RC4 New Comment: No, it's because ncurses stuff isn't present in readline for Mandrake. I found the error and sent a patch a while back to the cooker list, it went ignored (that's not unusual). Well, here's the fix anyway: http://www.mandrake.com/en/archives/cooker/2002-12/msg01367.php Chears. Previous Comments: [2003-01-12 16:00:37] [EMAIL PROTECTED] This looks to be related to readline includes in /usr/include and the actualy libraries being installed in /lib so they are available for applications such as bash during boot up when /usr may not be available. [2003-01-07 12:57:20] [EMAIL PROTECTED] It does not work with: cd ext/readline;phpize;aclocal ./configure --with-readline [--SNIP--] checking for libedit readline replacement... yes, shared checking for readline support... yes, shared checking for tgetent in -lncurses... yes checking for readline in -lreadline... no configure: error: readline library not found The problem is it checks for tgetent in -lncurses, but it doesn't add the lib in the $LIBS variable. I have the GNU readline library, version 4.3 I managed to get it work, but then, it also insists on checking *both* readline and libedit. So I installed libedit, and the same problem with the -lncurses appeared. Seems to me someone should check the config.m4 [2002-12-22 19:29:40] [EMAIL PROTECTED] Hi. (sorry, this one was accidently also filed as #21152, I forgot to change the summary...) readline won't build as a external module. Here's my configure line that don't work: ./configure \ --prefix=/usr \ --exec-prefix=/usr \ --bindir=/usr/bin \ --sbindir=/usr/sbin \ --datadir=/usr/share \ --sysconfdir=/etc \ --libdir=/usr/lib \ --includedir=/usr/include \ --infodir=/usr/share/info \ --mandir=/usr/share/man \ --with-apxs2=/usr/sbin/apxs \ --enable-force-cgi-redirect \ --enable-discard-path \ --enable-debug \ --with-layout=GNU \ --with-config-file-path=/etc \ --with-config-file-scan-dir=/etc/httpd/conf.d \ --with-pear=/usr/lib/php \ --enable-safe-mode \ --with-exec-dir=/usr/bin \ --enable-magic-quotes \ --disable-rpath \ --with-openssl=shared,/usr --with-zlib=shared,/usr --with-zlib-dir=/usr \ --enable-bcmath=shared \ --with-bz2=shared,/usr \ --enable-calendar=shared \ --without-cpdflib \ --with-jpeg-dir=/usr \ --with-tiff-dir=/usr \ --without-crack \ --with-ctype=shared \ --with-curl=shared,/usr \ --without-cyrus \ --without-db \ --enable-dba=shared,/usr \ --with-gdbm=shared,/usr \ --without-ndbm \ --without-db2 \ --without-db3 \ --with-db4=shared,/usr \ --without-dbm \ --with-cdb=shared,/usr \ --with-flatfile=shared \ --enable-dbase=shared \ --enable-dbx=shared,/usr \ --enable-dio=shared,/usr \ --with-dom=shared,/usr --with-zlib-dir=/usr --with-dom-xslt=shared,/usr --with-dom-exslt=shared,/usr \ --enable-exif=shared \ --without-fbsql \ --without-fdftk \ --enable-filepro=shared \ --without-fribidi \ --enable-ftp=shared \ --with-gd=shared --with-jpeg-dir=/usr --with-png-dir=/usr --with-zlib-dir=/usr --with-xpm-dir=/usr/X11R6/lib/ \ --with-ttf=/usr \ --with-freetype-dir=/usr \ --with-t1lib=/usr \ --enable-gd-native-ttf \ --with-gettext=shared,/usr \ --with-gmp=shared,/usr \ --without-hwapi \ --without-hyperwave \ --without-iconv \ --with-imap=shared,/usr \ --without-kerberos \ --with-imap-ssl=shared,/usr \ --without-informix \ --without-ingres \ --without-interbase \ --without-ircg \ --with-ircg-config=/dev/null \ --without-java \ --with-ldap=shared,/usr \ --enable-mbstring=shared \ --enable-mbregex=shared \ --without-mcal \ --with-mcrypt=shared,/usr \ --without-mcve \ --with-mhash=shared,/usr \ --enable-mime-magic=shared \ --with-ming=shared,/usr \ --with-mnogosearch=shared,/usr \ --without-msession \ --without-msql \ --without-mssql \ --with-mysql=shared,/usr --with-mysql-sock=/var/lib/mysql/mysql.sock --with-zlib-dir=/usr \ --with-ncurses=shared,/usr \ --without-oci8 \ --without-adabas \ --without-sapdb \ --without-solid \ --without-ibm-db2 \ --without-empress \ --without-empress-bcs \ --without-birdstep \ --without-custom-odbc \
#21620 [Fbk-Csd]: $REMOTE_USER does not exist after a POST-request
ID: 21620 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Closed Bug Type: Scripting Engine problem Operating System: Redhat 6.2 PHP Version: 4.3.0 New Comment: Forget about it. I just noticed that the .htaccess file contained LIMIT GET require valid-user /LIMIT After deleteing the LIMIT GET and /LIMIT tags the post version also worked. The $PHP_AUTH_USER worked even though the LIMIT tags were there, but the $REMOTE_USER obviously does not. Forgive me for not thinking of this earlier. Previous Comments: [2003-01-13 12:18:40] [EMAIL PROTECTED] Which web version of Apache? I don't see anything on the PHP side of things that would make this behave differently based on the request type. [2003-01-13 11:36:29] [EMAIL PROTECTED] In PHP 4.3.0 in safe mode the $PHP_AUTH_* variables do not exist anymore. It is recommended to use $REMOTE_USER instead. The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a form action=XXX method=post. With method=get it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method=get option is a workaround, but this does not work in upload scripts, which has to use post. Is this a new bug? -- Edit this bug report at http://bugs.php.net/?id=21620edit=1
#21621 [NEW]: configure hangs
From: [EMAIL PROTECTED] Operating system: solaris8 PHP version: 4.3.0 PHP Bug Type: *Configuration Issues Bug description: configure hangs I am trying to build PHP-4.3.0 with apache-2.0.43 using prescribed build steps but when I try to configure PHP it hangs on the tr command. cd apache-2.0.43 configure --prefix=/usr/local/apache checking for chosen layout... Apache checking for working mkdir -p... yes checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 Configuring Apache Portable Runtime library ... checking for APR... reconfig configuring package in srclib/apr now configure: loading cache /dev/null checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 ... cd ../php-4.3.0 configure --with-apache=../2.0.43 creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Updated php_version.h It hangs here trying to run the translate command (tr). If I retype the configure command then I get. configure --with-apache=../2.0.43 loading cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Again, it hangs on tr. This seems like a configure bug. Can you please help me here? Thanks... John Edson Atmel Corporation 1150 E. Cheyenne Mtn. Blvd., MS 10250 Colorado Springs, CO 80906 Phone: 719-540-3220 -- Edit bug report at http://bugs.php.net/?id=21621edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21621r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21621r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21621r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21621r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21621r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21621r=support Expected behavior: http://bugs.php.net/fix.php?id=21621r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21621r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21621r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21621r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21621r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21621r=dst IIS Stability: http://bugs.php.net/fix.php?id=21621r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21621r=gnused
#20441 [Csd]: PHP_AUTH_USER isn't set
ID: 20441 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Apache related Operating System: all PHP Version: 4.3.0 New Comment: For the record, the last comment was found to be bogus in bug #21620. And on a unrelated note, it's recommended to not rely on the register_globals directive so use $_SERVER['REMOTE_USER'] not $REMOTE_USER. Previous Comments: [2003-01-13 11:33:03] [EMAIL PROTECTED] The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a form action=XXX method=post. With method=get it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method=get option is a workaround, but this does not work in upload scripts, which has to use post. Is this a new bug? [2002-12-21 15:16:22] [EMAIL PROTECTED] It has been agreed in php-dev to keep the PHP_AUTH_* variables but to disable them when in safe mode. This change was made after 4.3.0-RC4 but will exist in PHP 4.3.0. This is from the PHP 4.3.0 NEWS: Make PHP_AUTH_* variables not available in safe mode under Apache when an external basic auth mechanism is used. (Philip) REMOTE_USER will exist regardless. In the future, a new ini directive such as expose_php_auth_vars may be available. The docs will be updated. [2002-12-18 15:21:10] [EMAIL PROTECTED] This needs to be fixed before 4.3 goes out. While it is of course important to improve the code and iron out long standing errors, we must not forget that our users rely on the old behaviour. The default behaviour of 4.3 should be the same as in old versions. [2002-12-18 13:29:19] [EMAIL PROTECTED] This problem has just caused me a big headache - a customer has been relying on the fact that both .htaccess and PHP_AUTH_USER have been available in parallel since at least PHP 4. They've asked me to fix their scripts, but it would be a massive rewrite to sort out. I only have two customers who do their own scripting, and 50% of them are bitten by this. I think that 4.3.0 may well annoy lots of people with this. I can see from the documentation of bug #19251 why the change has been made, and I understand that that the manual documents the new behaviour, but I suspect this misbehaviour is widely relied upon, and perhaps we should consider an php.ini switch. The only economic solution I can suggest for my customer in the meanwhile is for me to patch php back to its old behaviour. [2002-12-11 10:58:19] [EMAIL PROTECTED] We fixed a bug, period. Derick 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/20441 -- Edit this bug report at http://bugs.php.net/?id=20441edit=1
#21622 [NEW]: MSSQL: 100% CPU usage on database queries and eventually timeout
From: [EMAIL PROTECTED] Operating system: Win2K PHP version: 4.3.0 PHP Bug Type: Performance problem Bug description: MSSQL: 100% CPU usage on database queries and eventually timeout I installed php to utilize phpbb forums on a dual CPU high end server. Win2K MSSQL 7.0. Performance was ok but now having only 10,000 posts (and having moved to another server single P3 CPU) I cannot get anything to return from the database. CPU pins at 100% until my forums eventually timeout. All utilization is coming from MSSQL Server (cpu usage and memory). I did have huge memory leak problems coming from MSSQL server on the first server (was using latest PHP installed around Oct/2002). This seems to have gone away (PHP 4.3) but I can't tell for sure since I can't use the forums yet. I have another set of forums on the same server (PHP/MSSQL) with only a few posts and they at least work. I can query the database no problem outside of PHP with excellent performance. I did search around in these bug reports and wasn't able to solve my problem. Thank you. -- Edit bug report at http://bugs.php.net/?id=21622edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21622r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21622r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21622r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21622r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21622r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21622r=support Expected behavior: http://bugs.php.net/fix.php?id=21622r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21622r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21622r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21622r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21622r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21622r=dst IIS Stability: http://bugs.php.net/fix.php?id=21622r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21622r=gnused
#21623 [NEW]: Turning on Magic quotes Segfaults PHP
From: [EMAIL PROTECTED] Operating system: RedHat PHP version: 5CVS-2003-01-13 (dev) PHP Bug Type: Reproducible crash Bug description: Turning on Magic quotes Segfaults PHP I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the PostNuke package. Unfortunately I have no idea how/where it crashes... here's the backtrace... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 2993malloc.c: No such file or directory. in malloc.c Obviously something has gone wrong trying to malloc memory, however I don't have any real way to see what PHP code actually breaks everything... Perhaps I'll try to install one of the realtime debuggers and attempt to determine where exactly it's crashing. Configured with: --with-mysql --with-apxs -- Edit bug report at http://bugs.php.net/?id=21623edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21623r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21623r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21623r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21623r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21623r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21623r=support Expected behavior: http://bugs.php.net/fix.php?id=21623r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21623r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21623r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21623r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21623r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21623r=dst IIS Stability: http://bugs.php.net/fix.php?id=21623r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21623r=gnused
#21623 [Opn-Fbk]: Turning on Magic quotes Segfaults PHP
ID: 21623 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Reproducible crash Operating System: RedHat PHP Version: 5CVS-2003-01-13 (dev) New Comment: 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. Previous Comments: [2003-01-13 13:31:51] [EMAIL PROTECTED] I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the PostNuke package. Unfortunately I have no idea how/where it crashes... here's the backtrace... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 2993malloc.c: No such file or directory. in malloc.c Obviously something has gone wrong trying to malloc memory, however I don't have any real way to see what PHP code actually breaks everything... Perhaps I'll try to install one of the realtime debuggers and attempt to determine where exactly it's crashing. Configured with: --with-mysql --with-apxs -- Edit this bug report at http://bugs.php.net/?id=21623edit=1
#21623 [Fbk-Opn]: Turning on Magic quotes Segfaults PHP
ID: 21623 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Reproducible crash Operating System: RedHat PHP Version: 5CVS-2003-01-13 (dev) New Comment: Here's the bt: One more thing -- magic_quotes_gpc is on and working fine... things also work if the magic quotes runtime are disabled. #0 chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 #1 0x4011b02c in __libc_malloc (bytes=100) at malloc.c:2811 #2 0x402ae54b in _emalloc (size=83) at /home/php/php4/Zend/zend_alloc.c:158 #3 0x402c0b03 in zend_hash_add_or_update (ht=0x8202e64, arKey=0x8216bc4 s:30:\\\Bad arguments for API function\\\;PNSVuid, nKeyLength=48, pData=0xbfff8b50, nDataSize=4, pDest=0x0, flag=1) at /home/php/php4/Zend/zend_hash.c:262 #4 0x402bff53 in zend_set_hash_symbol (symbol=0x823d7e4, name=0x8216bc4 s:30:\\\Bad arguments for API function\\\;PNSVuid, name_length=47, is_ref=0, num_symbol_tables=1) at /home/php/php4/Zend/zend_API.c:1261 #5 0x4021e4ea in php_set_session_var ( name=0x8216bc4 s:30:\\\Bad arguments for API function\\\;PNSVuid, namelen=47, state_val=0x823d7e4, var_hash=0xbfff8bc8) at /home/php/php4/ext/session/session.c:324 #6 0x4021ec90 in ps_srlzr_decode_php ( val=0x821693c PNSVrand|i:625621835;PNSVlang|s:3:\\\eng\\\;PNSVerrormsg|s:30:\\\Bad arguments for API function\\\;PNSVuid|i:2;PNSVrememberme|i:1;, vallen=126) at /home/php/php4/ext/session/session.c:487 #7 0x4021ef46 in php_session_decode ( val=0x821693c PNSVrand|i:625621835;PNSVlang|s:3:\\\eng\\\;PNSVerrormsg|s:30:\\\Bad arguments for API function\\\;PNSVuid|i:2;PNSVrememberme|i:1;, vallen=126) at /home/php/php4/ext/session/session.c:533 #8 0x4021f3c9 in php_session_initialize () at /home/php/php4/ext/session/session.c:692 #9 0x4022044f in php_session_start () at /home/php/php4/ext/session/session.c:1095 #10 0x402217b9 in zif_session_start (ht=0, return_value=0x823c43c, this_ptr=0x0, return_value_used=0) at /home/php/php4/ext/session/session.c:1540 #11 0x402cfe24 in execute (op_array=0x8204860) at /home/php/php4/Zend/zend_execute.c:1596 #12 0x402cffe2 in execute (op_array=0x812cea0) at /home/php/php4/Zend/zend_execute.c:1640 #13 0x402cffe2 in execute (op_array=0x8111434) at /home/php/php4/Zend/zend_execute.c:1640 #14 0x402bd630 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/php/php4/Zend/zend.c:925 #15 0x4029703d in php_execute_script (primary_file=0xb620) at /home/php/php4/main/main.c:1691 #16 0x402d73c6 in apache_php_module_main (r=0x8100e24, display_source_mode=0) at /home/php/php4/sapi/apache/sapi_apache.c:55 #17 0x402d7f32 in send_php (r=0x8100e24, display_source_mode=0, filename=0x0) at /home/php/php4/sapi/apache/mod_php4.c:589 #18 0x402d7f86 in send_parsed_php (r=0x8100e24) at /home/php/php4/sapi/apache/mod_php4.c:604 #19 0x0806a5f7 in ap_invoke_handler () #20 0x0807ee77 in process_request_internal () #21 0x0807f29b in ap_internal_redirect () #22 0x0805f530 in handle_dir () #23 0x0806a5f7 in ap_invoke_handler () #24 0x0807ee77 in process_request_internal () #25 0x0807eed8 in ap_process_request () #26 0x0807612d in child_main () #27 0x080762d8 in make_child () #28 0x0807644c in startup_children () #29 0x08076ac4 in standalone_main () #30 0x08077317 in main () #31 0x400bb306 in __libc_start_main (main=0x8076f80 main, argc=2, ubp_av=0xbb34, init=0x804e5d8 _init, fini=0x8094460 _fini, rtld_fini=0x4000d2dc _dl_fini, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 Previous Comments: [2003-01-13 13:33:06] [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-01-13 13:31:51] [EMAIL PROTECTED] I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the PostNuke package. Unfortunately I have no idea how/where it crashes... here's the backtrace... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal SIGSEGV, Segmentation fault. chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 2993malloc.c: No such
#16339 [Com]: Warning: Undefined index .....
ID: 16339
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Other web server
Operating System: XP Edition
PHP Version: 4.1.2
New Comment:
I am having the same proglem! I cannot figure it out!
I am using Abyss Web Server 1.1.2 and I have installed php 4.3.0 and it
gives me the same thing!
using this code:
?php
if (empty($e)) { $e =home; }
$page = array( home = pages/home.php, gates = pages/gates.php,
plate = pages/plate.php, inuit = pages/inuit.php, tut =
pages/tut.php, koala = pages/koala.php, rome = pages/rome.php,
sci = pages/sci.php, sunshine = pages/sunshine.php, rainer =
pages/rainer.php, blonde = pages/blonde.php, mamma =
pages/mamma.php, pass = pages/pass.php, mail = pages/mail.php,
shop = pages/shop.php, im = pages/im.php, contact =
pages/contact.php, thanks = pages/thanks.php, buddy =
pages/buddy.php, buddyinfo = pages/buddyinfo.php,);
include($page[$e]);
?
I get this error:
Notice: Use of undefined constant main - assumed 'main' in C:\Documents
and Settings\Gregory.GATEWAY\My Documents\Sites\EKINGME 2003\index.php
on line 81
Previous Comments:
[2002-03-29 01:22:57] [EMAIL PROTECTED]
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
[2002-03-29 00:54:45] [EMAIL PROTECTED]
i try to add ENV in my Webpage but display error messege
Warning: Undefined index: HTTP_X_FORWARDED_FOR in
d:\NETWORK\SAMBAR\docs\00\index.php on line 26
?
$ip = $_SERVER[HTTP_X_FORWARDED_FOR];
echo $ip;
exit();
?
but variables_order = EGPCS always in my php.ini
my web server is sambar 5.1
--
Edit this bug report at http://bugs.php.net/?id=16339edit=1
#20864 [NoF-Csd]: Cc/Bcc fields don't seem to work
ID: 20864 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: No Feedback +Status: Closed Bug Type: Mail related Operating System: Windows 2000 PHP Version: 4.2.3 New Comment: PHP 4.3.0 so far seems to have solved this issue, that's why I posted no further feedback. Sorry for not closing the bug sooner Previous Comments: [2002-12-24 01:00:06] [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. [2002-12-08 02:39:07] [EMAIL PROTECTED] Are you sure your php.ini is even read? Is it in correct place? Is it with correct NAME..(common problem, people tend to name it php.ini.ini on Windows) [2002-12-07 10:10:43] [EMAIL PROTECTED] I seem to have been misunderstood. I tried using the referred devel snapshot and I always get the PHP CGI cannot be accessed directly [...] message, even with the parameters shown above. Can anybody tell me what else might be wrong (note: I haven't had these problems with any other PHP release before..) [2002-12-07 02:55:26] [EMAIL PROTECTED] In my case, Cc: and Bcc: work now (dev and stable snapshots on winXP). Christoph [2002-12-06 18:31:06] [EMAIL PROTECTED] So does the mail work now? 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/20864 -- Edit this bug report at http://bugs.php.net/?id=20864edit=1
#21472 [Opn]: Problems with short tags and script tags
ID: 21472 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: script tags must have the language variable in s now whereas before they did not have to be, this makes them work. Previous Comments: [2003-01-09 07:50:13] [EMAIL PROTECTED] I do not have any special ASP items installed on the servers, and we do not use ASP pages either. [2003-01-08 18:03:54] [EMAIL PROTECTED] do you have ASP installed as well? [2003-01-07 07:54:33] [EMAIL PROTECTED] A. It says C:\WINNT\php.ini B. I edited that file to change the value for short tags to 1, or on. C. Restarted IIS. D. PHPINFO says that the directive is on. [2003-01-06 15:44:45] [EMAIL PROTECTED] Please be specific with the questions below: 1) EXACTLY what does (a) say from below? 2) Did you restart the web server after editing? 3) What does phpinfo() say for this directive? 4) What value are you assigning to this directive in php.ini? [2003-01-06 15:26:05] [EMAIL PROTECTED] It is in c:\WINNT, the one I have been modifying all the time. Same situation. 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/21472 -- Edit this bug report at http://bugs.php.net/?id=21472edit=1
#21624 [NEW]: no transparent Colors in PNG's with Opera 6/7
From: [EMAIL PROTECTED] Operating system: RedHat PHP version: 4.3.0 PHP Bug Type: GD related Bug description: no transparent Colors in PNG's with Opera 6/7 If I generate a PNG with PHP 4.3.0, GD and libpng 1.2.5 and try to use a transparent color with imagecolortransparent(), that doesn't work in Opera (I've tested with Versions 6 7). Sometimes simply nothing happens and sometimes another color is set as transparent. In Mozilla, everything works fine. With the previous Version of PHP and GD 1.8.4 and libpng 1.2.4 it worked in Opera. My configure line: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-freetype-dir=/usr/local/include --with-jpeg-dir=/var/install/php/jpeg-6b --with-png-dir --enable-track-vars --enable-ftp --with-zlib --with-gd --with-sockets --enable-sockets --with-sysvshm --with-sysvsem --disable-debug --with-mysql=/usr -- Edit bug report at http://bugs.php.net/?id=21624edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21624r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21624r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21624r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21624r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21624r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21624r=support Expected behavior: http://bugs.php.net/fix.php?id=21624r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21624r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21624r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21624r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21624r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21624r=dst IIS Stability: http://bugs.php.net/fix.php?id=21624r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21624r=gnused
#21618 [Opn-Bgs]: fopen on no existing files generates unexpected output.
ID: 21618
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: *General Issues
Operating System: Apache on RedHat Linux
PHP Version: 4.2.3
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.
Previous Comments:
[2003-01-13 11:02:11] [EMAIL PROTECTED]
I planned to use the following function testing for a flag file
'offline_message.txt' to disable my application and contain an offline
message.
function isOffLine() {
global $OffLineMessage;
$OffLineMessage = ;
$OffLineFilename = offline_message.txt ;
if (!($fp = fopen($OffLineFilename, r))) {
return false;
} else {
$OffLineMessage = file( $OffLineFilename ) ;
return true;
}
}
However bothe the fopen file functions generates an unexpected and
unwanted warning messages to the output stream.
Warning: fopen(offline_message.txt, r) - No such file or directory
in /var/www/html/webmail/common.php on line 104
Warning: file(offline_message.txt) - No such file or directory in
/var/www/html/webmail/common.php on line 105
--
Edit this bug report at http://bugs.php.net/?id=21618edit=1
#20752 [Ana-Csd]: Seems like it has something to do with ZEND_API(?).
ID: 20752 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Compile Failure Operating System: Tru64 5.1a PHP Version: 4CVS-2002-12-01 (dev) New Comment: According to novell, this has been fixed. Previous Comments: [2002-12-02 01:42:11] [EMAIL PROTECTED] This one works, but spits out a warning every time ZEND_API is used: #define ZEND_API true(); #define ZEND_API false(); This _wont_ work: #define ZEND_API #define ZEND_API(type) type #define ZEND_API 1 Just some that I've tested. [2002-12-01 18:39:39] [EMAIL PROTECTED] The cc on tru64 does not like having 'empty' / non-existing defines. ZEND_API has to be defined to something.. Other projects, like Apache, have solved this by using this kind of macros: #if !defined(WIN32) #define APR_DECLARE(type)type #define APR_DECLARE_NONSTD(type) type #define APR_DECLARE_DATA#define APR_DECLARE_DATA #elif defined(APR_DECLARE_STATIC) #define APR_DECLARE(type)type __stdcall #define APR_DECLARE_NONSTD(type) type #elif defined(APR_DECLARE_EXPORT) #define APR_DECLARE(type)__declspec(dllexport) type __stdcall #define APR_DECLARE_NONSTD(type) __declspec(dllexport) type #define APR_DECLARE_DATA __declspec(dllexport) #else #define APR_DECLARE(type)__declspec(dllimport) type __stdcall #define APR_DECLARE_NONSTD(type) __declspec(dllimport) type #define APR_DECLARE_DATA __declspec(dllimport) #endif So I guess we should be doing something similar. --Jani [2002-12-01 18:36:28] [EMAIL PROTECTED] Just some notes what I need to test: #define ZEND_API extern Second one: Remove the extern's and just use ZEND_API. [2002-12-01 17:38:03] [EMAIL PROTECTED] I'm using the shipped c compiler, GNU versions of bison, autoconf, automake, flex, gmake. Here's the output from the compile: cc: Error: /opt/DEV/php/php4/Zend/zend_globals_macros.h, line 37: Missing ;. (nosemi) extern ZEND_API struct _zend_compiler_globals compiler_globals; ^ cc: Error: /opt/DEV/php/php4/Zend/zend_globals_macros.h, line 47: Missing ;. (nosemi) extern ZEND_API zend_executor_globals executor_globals; ^ cc: Error: /opt/DEV/php/php4/Zend/zend_globals_macros.h, line 56: Missing ;. (nosemi) extern ZEND_API zend_alloc_globals alloc_globals; ^ cc: Error: /opt/DEV/php/php4/Zend/zend_globals_macros.h, line 66: Missing ;. (nosemi) extern ZEND_API zend_scanner_globals language_scanner_globals; ^ cc: Error: /opt/DEV/php/php4/Zend/zend_globals_macros.h, line 76: Missing ;. (nosemi) extern ZEND_API zend_scanner_globals ini_scanner_globals; ^ cc: Error: /opt/DEV/php/php4/Zend/zend_alloc.h, line 73: Missing ;. (nosemi) ZEND_API char *zend_strndup(const char *s, unsigned int length); -^ cc: Error: /opt/DEV/php/php4/Zend/zend_hash.h, line 79: Missing ;. (nosemi) ZEND_API int zend_hash_init(HashTable *ht, uint nSize, hash_func_t pHashFunction, dtor_func_t pDestructor, int persistent); -^ cc: Error: /opt/DEV/php/php4/Zend/zend_hash.h, line 121: Missing ;. (nosemi) ZEND_API void zend_hash_graceful_destroy(HashTable *ht); -^ cc: Error: /opt/DEV/php/php4/Zend/zend_hash.h, line 203: Missing ;. (nosemi) ZEND_API ulong zend_hash_func(char *arKey, uint nKeyLength); -^ cc: Error: /opt/DEV/php/php4/Zend/zend_llist.h, line 51: Missing ;. (nosemi) ZEND_API void zend_llist_init(zend_llist *l, size_t size, llist_dtor_func_t dtor, unsigned char persistent); -^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 360: Missing ;. (nosemi) ZEND_API void _zend_bailout(char *filename, uint lineno); -^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 418: Missing ;. (nosemi) extern ZEND_API int (*zend_printf)(const char *format, ...); ^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 419: Missing ;. (nosemi) extern ZEND_API zend_write_func_t zend_write; ^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 420: Missing ;. (nosemi) extern ZEND_API FILE *(*zend_fopen)(const char *filename, char **opened_path); ^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 421: Missing ;. (nosemi) extern ZEND_API void (*zend_block_interruptions)(void); ^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 422: Missing ;. (nosemi) extern ZEND_API void (*zend_unblock_interruptions)(void); ^ cc: Error: /opt/DEV/php/php4/Zend/zend.h, line 423: Missing
#21624 [Opn-Bgs]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: GD related Operating System: RedHat 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. Given that the behaviour is incositent across browsers and I cannot replicate the described problem in Mozilla or IE 6.0 I'd say this is a broser and not a PHP issue. Perpahps, Opera cannot handle alpha transparency, which is what is causing the problem, this particular type of transparency would not have been avaliable in older GD library. Previous Comments: [2003-01-13 15:33:23] [EMAIL PROTECTED] If I generate a PNG with PHP 4.3.0, GD and libpng 1.2.5 and try to use a transparent color with imagecolortransparent(), that doesn't work in Opera (I've tested with Versions 6 7). Sometimes simply nothing happens and sometimes another color is set as transparent. In Mozilla, everything works fine. With the previous Version of PHP and GD 1.8.4 and libpng 1.2.4 it worked in Opera. My configure line: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-freetype-dir=/usr/local/include --with-jpeg-dir=/var/install/php/jpeg-6b --with-png-dir --enable-track-vars --enable-ftp --with-zlib --with-gd --with-sockets --enable-sockets --with-sysvshm --with-sysvsem --disable-debug --with-mysql=/usr -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21621 [Opn-Fbk]: configure hangs
ID: 21621 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: solaris8 PHP Version: 4.3.0 New Comment: Which 'tr' command are you using, version # and is it native to solaris or is it GNU? Previous Comments: [2003-01-13 12:46:07] [EMAIL PROTECTED] I am trying to build PHP-4.3.0 with apache-2.0.43 using prescribed build steps but when I try to configure PHP it hangs on the tr command. cd apache-2.0.43 configure --prefix=/usr/local/apache checking for chosen layout... Apache checking for working mkdir -p... yes checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 Configuring Apache Portable Runtime library ... checking for APR... reconfig configuring package in srclib/apr now configure: loading cache /dev/null checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 ... cd ../php-4.3.0 configure --with-apache=../2.0.43 creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Updated php_version.h It hangs here trying to run the translate command (tr). If I retype the configure command then I get. configure --with-apache=../2.0.43 loading cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Again, it hangs on tr. This seems like a configure bug. Can you please help me here? Thanks... John Edson Atmel Corporation 1150 E. Cheyenne Mtn. Blvd., MS 10250 Colorado Springs, CO 80906 Phone: 719-540-3220 -- Edit this bug report at http://bugs.php.net/?id=21621edit=1
#21620 [Csd-Bgs]: $REMOTE_USER does not exist after a POST-request
ID: 21620 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Closed +Status: Bogus Bug Type: Scripting Engine problem Operating System: Redhat 6.2 PHP Version: 4.3.0 Previous Comments: [2003-01-13 12:40:09] [EMAIL PROTECTED] Forget about it. I just noticed that the .htaccess file contained LIMIT GET require valid-user /LIMIT After deleteing the LIMIT GET and /LIMIT tags the post version also worked. The $PHP_AUTH_USER worked even though the LIMIT tags were there, but the $REMOTE_USER obviously does not. Forgive me for not thinking of this earlier. [2003-01-13 12:18:40] [EMAIL PROTECTED] Which web version of Apache? I don't see anything on the PHP side of things that would make this behave differently based on the request type. [2003-01-13 11:36:29] [EMAIL PROTECTED] In PHP 4.3.0 in safe mode the $PHP_AUTH_* variables do not exist anymore. It is recommended to use $REMOTE_USER instead. The suggestion that $REMOTE_USER still works and can be used in Safe mode is only party true. I noticed that this variable is filled with the username supplied by the external basic auth mechanism (.htaccess) unless you are in a script which has been called by a form action=XXX method=post. With method=get it works OK. I need the $REMOTE_USER to lookup users from the database and find their ID in the DB. The method=get option is a workaround, but this does not work in upload scripts, which has to use post. Is this a new bug? -- Edit this bug report at http://bugs.php.net/?id=21620edit=1
#21624 [Bgs]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: Since Version 6.0 Beta 1 Opera fully supports alpha transparency: http://www.opera.com/windows/changelogs/600b1/index.dml So because it worked in previous PHP/GD-versions, I think it is a PHP issue Previous Comments: [2003-01-13 16:20:04] [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. Given that the behaviour is incositent across browsers and I cannot replicate the described problem in Mozilla or IE 6.0 I'd say this is a broser and not a PHP issue. Perpahps, Opera cannot handle alpha transparency, which is what is causing the problem, this particular type of transparency would not have been avaliable in older GD library. [2003-01-13 15:33:23] [EMAIL PROTECTED] If I generate a PNG with PHP 4.3.0, GD and libpng 1.2.5 and try to use a transparent color with imagecolortransparent(), that doesn't work in Opera (I've tested with Versions 6 7). Sometimes simply nothing happens and sometimes another color is set as transparent. In Mozilla, everything works fine. With the previous Version of PHP and GD 1.8.4 and libpng 1.2.4 it worked in Opera. My configure line: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-freetype-dir=/usr/local/include --with-jpeg-dir=/var/install/php/jpeg-6b --with-png-dir --enable-track-vars --enable-ftp --with-zlib --with-gd --with-sockets --enable-sockets --with-sysvshm --with-sysvsem --disable-debug --with-mysql=/usr -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21569 [Bgs]: PHP can't set cookies after a test with an unset variable
ID: 21569
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
There's really no bug here. You're getting a notice about unitialized
variable which causes the rest of the headers not to get send. Try
adding 'error_reporting(0);' in the beginning of your script..
Previous Comments:
[2003-01-13 10:48:18] [EMAIL PROTECTED]
Workaround #2:
At the beginning og your script, declare any possibly unset variable
that will be invoked:
if (!isset($test)) {$test=;}
[2003-01-13 10:07:12] [EMAIL PROTECTED]
Workaround (which doesn't mean this bug shouldn't be fixed):
To perform tests:
if (!isset($test) || $test==) { echo ; }
To set a variable:
$a=; if (isset($test)) { $a=$test; }
[2003-01-13 10:05:53] [EMAIL PROTECTED]
I've found out that the problem is not limited to tests. It happens
every time you invoke an unset variable before than setting a cookie.
In the previous example, try
$a = $test;
instead of
if ($test==) { echo ; }
and the setcookie won't work as well.
[2003-01-13 10:03:29] [EMAIL PROTECTED]
This is a shortest example:
?
# $test=;
setcookie(debug,1,0,,);
if ($test==) { echo ; }
setcookie(debug,3,0,,);
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
[2003-01-10 13:14:02] [EMAIL PROTECTED]
I've submitted a specific bug. It depends either from PHP or Windows
2000 itself in some way, because I've tested it deeply in many
configurations of operating systems, Apache and PHP versions.
The sample code provided is a proof of concept, not a code I'm asking
advice about.
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/21569
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#20497 [Opn-Bgs]: Will not compile Output line too long
ID: 20497 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Compile Failure Operating System: solaris 8 PHP Version: 4.3.0RC1 New Comment: sed is not the first or last tool in Solaris to be buggy as hell. And it's not our problem if it is. Previous Comments: [2003-01-13 11:33:27] [EMAIL PROTECTED] When I upgraded the sed it worked, I think that SUN should .know about this this should not be the case!! sed functionality should be the same across the board. -Ian [EMAIL PROTECTED] [2003-01-13 11:29:26] [EMAIL PROTECTED] I currently have the same problem on Solaris 8 (MU7), apache-httpd 2.0.43 und php 4.3.0 (as dynamic module). Shouldn't it work with the sed shipped with Solaris? Maybe we should send SUN a bug report if something is wrong with their implementation of sed. [2003-01-07 13:35:25] [EMAIL PROTECTED] After reading your comments, I installed GNU sed from sunfreeware.com. PHP is now compiled properly. Thank you for this information. [2002-12-01 16:39:00] [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. [2002-11-19 12:20:34] [EMAIL PROTECTED] Can you first check why the sed check didn't break the configure, from config.log, look for something like this: configure:1579: checking for working sed (to 'fix' this problem, install GNU sed) 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/20497 -- Edit this bug report at http://bugs.php.net/?id=20497edit=1
#21624 [Bgs-Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: It is a PHP issue. A patch was posted to php-dev a while ago, but nobody has had a chance to look at it yet. Previous Comments: [2003-01-13 16:36:56] [EMAIL PROTECTED] Since Version 6.0 Beta 1 Opera fully supports alpha transparency: http://www.opera.com/windows/changelogs/600b1/index.dml So because it worked in previous PHP/GD-versions, I think it is a PHP issue [2003-01-13 16:20:04] [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. Given that the behaviour is incositent across browsers and I cannot replicate the described problem in Mozilla or IE 6.0 I'd say this is a broser and not a PHP issue. Perpahps, Opera cannot handle alpha transparency, which is what is causing the problem, this particular type of transparency would not have been avaliable in older GD library. [2003-01-13 15:33:23] [EMAIL PROTECTED] If I generate a PNG with PHP 4.3.0, GD and libpng 1.2.5 and try to use a transparent color with imagecolortransparent(), that doesn't work in Opera (I've tested with Versions 6 7). Sometimes simply nothing happens and sometimes another color is set as transparent. In Mozilla, everything works fine. With the previous Version of PHP and GD 1.8.4 and libpng 1.2.4 it worked in Opera. My configure line: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-freetype-dir=/usr/local/include --with-jpeg-dir=/var/install/php/jpeg-6b --with-png-dir --enable-track-vars --enable-ftp --with-zlib --with-gd --with-sockets --enable-sockets --with-sysvshm --with-sysvsem --disable-debug --with-mysql=/usr -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21624 [Opn-Bgs]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: PHP generates the very same image for every browser. If it works in 2 browsers and does not work in one, is it not reasonable to assume that the browser where the image does not work is the one at fault? Previous Comments: [2003-01-13 16:38:53] [EMAIL PROTECTED] It is a PHP issue. A patch was posted to php-dev a while ago, but nobody has had a chance to look at it yet. [2003-01-13 16:36:56] [EMAIL PROTECTED] Since Version 6.0 Beta 1 Opera fully supports alpha transparency: http://www.opera.com/windows/changelogs/600b1/index.dml So because it worked in previous PHP/GD-versions, I think it is a PHP issue [2003-01-13 16:20:04] [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. Given that the behaviour is incositent across browsers and I cannot replicate the described problem in Mozilla or IE 6.0 I'd say this is a broser and not a PHP issue. Perpahps, Opera cannot handle alpha transparency, which is what is causing the problem, this particular type of transparency would not have been avaliable in older GD library. [2003-01-13 15:33:23] [EMAIL PROTECTED] If I generate a PNG with PHP 4.3.0, GD and libpng 1.2.5 and try to use a transparent color with imagecolortransparent(), that doesn't work in Opera (I've tested with Versions 6 7). Sometimes simply nothing happens and sometimes another color is set as transparent. In Mozilla, everything works fine. With the previous Version of PHP and GD 1.8.4 and libpng 1.2.4 it worked in Opera. My configure line: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-freetype-dir=/usr/local/include --with-jpeg-dir=/var/install/php/jpeg-6b --with-png-dir --enable-track-vars --enable-ftp --with-zlib --with-gd --with-sockets --enable-sockets --with-sysvshm --with-sysvsem --disable-debug --with-mysql=/usr -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21603 [Opn-Fbk]: snmp shared module crash the apache server when starts
ID: 21603 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: SNMP related Operating System: Linux RedHat 8.0.92 PHP Version: 4CVS-2003-01-12 (stable) New Comment: 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. Previous Comments: [2003-01-12 17:38:50] [EMAIL PROTECTED] Hi, all at php, I'm building rpms oh php-4.3.1 stable from 12 Jan 2003, httpd-2.0.40-15, on a RedHat 8.0.92, I built it succesfully a lot of packages, but the snmp module crash apache web server, but there is something very strange, it works on a server but in another don't,(is working on the server where I built it) here my ldd command on the server that is working..., there's not error log in apache [root@ecodevel root]# ldd /usr/lib/php4/snmp.so libsnmp.so.5 = /usr/lib/libsnmp.so.5 (0x4001c000) libc.so.6 = /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) [root@ecodevel root]# here the ldd in the server that crash apache, both servers have the same redhat8.0.92.. [root@linux root]# ldd /usr/lib/php4/snmp.so libsnmp.so.5 = /usr/lib/libsnmp.so.5 (0x40009000) libc.so.6 = /lib/i686/libc.so.6 (0x4200) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x8000) [root@linux root]# As you see the number after libsnmp is different... Here my configure line... './configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--prefix=/usr' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4' '--with-curl' '--with-dom=/usr' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-ttf' '--with-gdbm' '--with-gettext' '--with-pdflib=shared' '--with-tiff-dir=/usr' '--with-ncurses' '--with-gmp' '--with-iconv' '--enable-xslt=shared' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos=/usr/kerberos' '--with-ldap=shared' '--with-mcal=shared,/usr' '--with-mcrypt=shared,/usr' '--with-mhash=shared,/usr' '--with-mssql=shared,/usr' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--with-xslt-sablot=shared,/usr' '--with-sablot-js=shared,/usr' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-versioning' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--with-apxs2=/usr/sbin/apxs' I hope it helps -- Edit this bug report at http://bugs.php.net/?id=21603edit=1
#21624 [Bgs-Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: No, because the very same script works fine with previous versions of PHP. Just because a browser is able to decypher the broken images we generate doesn't mean we are doing it right. Previous Comments: [2003-01-13 16:39:10] [EMAIL PROTECTED] PHP generates the very same image for every browser. If it works in 2 browsers and does not work in one, is it not reasonable to assume that the browser where the image does not work is the one at fault? [2003-01-13 16:38:53] [EMAIL PROTECTED] It is a PHP issue. A patch was posted to php-dev a while ago, but nobody has had a chance to look at it yet. [2003-01-13 16:36:56] [EMAIL PROTECTED] Since Version 6.0 Beta 1 Opera fully supports alpha transparency: http://www.opera.com/windows/changelogs/600b1/index.dml So because it worked in previous PHP/GD-versions, I think it is a PHP issue [2003-01-13 16:20:04] [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. Given that the behaviour is incositent across browsers and I cannot replicate the described problem in Mozilla or IE 6.0 I'd say this is a broser and not a PHP issue. Perpahps, Opera cannot handle alpha transparency, which is what is causing the problem, this particular type of transparency would not have been avaliable in older GD library. [2003-01-13 15:33:23] [EMAIL PROTECTED] If I generate a PNG with PHP 4.3.0, GD and libpng 1.2.5 and try to use a transparent color with imagecolortransparent(), that doesn't work in Opera (I've tested with Versions 6 7). Sometimes simply nothing happens and sometimes another color is set as transparent. In Mozilla, everything works fine. With the previous Version of PHP and GD 1.8.4 and libpng 1.2.4 it worked in Opera. My configure line: ./configure --with-apxs=/usr/local/apache/bin/apxs --with-freetype-dir=/usr/local/include --with-jpeg-dir=/var/install/php/jpeg-6b --with-png-dir --enable-track-vars --enable-ftp --with-zlib --with-gd --with-sockets --enable-sockets --with-sysvshm --with-sysvsem --disable-debug --with-mysql=/usr -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21621 [Fbk-Opn]: configure hangs
ID: 21621 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: *Configuration Issues Operating System: solaris8 PHP Version: 4.3.0 New Comment: I am using /usr/ucb/tr which is native solaris8 and should be using /usr/bin/tr it looks like. That fixed the problem. Thanks for your help. Previous Comments: [2003-01-13 16:21:21] [EMAIL PROTECTED] Which 'tr' command are you using, version # and is it native to solaris or is it GNU? [2003-01-13 12:46:07] [EMAIL PROTECTED] I am trying to build PHP-4.3.0 with apache-2.0.43 using prescribed build steps but when I try to configure PHP it hangs on the tr command. cd apache-2.0.43 configure --prefix=/usr/local/apache checking for chosen layout... Apache checking for working mkdir -p... yes checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 Configuring Apache Portable Runtime library ... checking for APR... reconfig configuring package in srclib/apr now configure: loading cache /dev/null checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 ... cd ../php-4.3.0 configure --with-apache=../2.0.43 creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Updated php_version.h It hangs here trying to run the translate command (tr). If I retype the configure command then I get. configure --with-apache=../2.0.43 loading cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Again, it hangs on tr. This seems like a configure bug. Can you please help me here? Thanks... John Edson Atmel Corporation 1150 E. Cheyenne Mtn. Blvd., MS 10250 Colorado Springs, CO 80906 Phone: 719-540-3220 -- Edit this bug report at http://bugs.php.net/?id=21621edit=1
#21621 [Opn-Csd]: configure hangs
ID: 21621 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: *Configuration Issues Operating System: solaris8 PHP Version: 4.3.0 Previous Comments: [2003-01-13 16:44:26] [EMAIL PROTECTED] I am using /usr/ucb/tr which is native solaris8 and should be using /usr/bin/tr it looks like. That fixed the problem. Thanks for your help. [2003-01-13 16:21:21] [EMAIL PROTECTED] Which 'tr' command are you using, version # and is it native to solaris or is it GNU? [2003-01-13 12:46:07] [EMAIL PROTECTED] I am trying to build PHP-4.3.0 with apache-2.0.43 using prescribed build steps but when I try to configure PHP it hangs on the tr command. cd apache-2.0.43 configure --prefix=/usr/local/apache checking for chosen layout... Apache checking for working mkdir -p... yes checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 Configuring Apache Portable Runtime library ... checking for APR... reconfig configuring package in srclib/apr now configure: loading cache /dev/null checking build system type... sparc-sun-solaris2.8 checking host system type... sparc-sun-solaris2.8 checking target system type... sparc-sun-solaris2.8 ... cd ../php-4.3.0 configure --with-apache=../2.0.43 creating cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Updated php_version.h It hangs here trying to run the translate command (tr). If I retype the configure command then I get. configure --with-apache=../2.0.43 loading cache ./config.cache checking for Cygwin environment... no checking for mingw32 environment... no checking for working sed... sed checking host system type... sparc-sun-solaris2.8 Again, it hangs on tr. This seems like a configure bug. Can you please help me here? Thanks... John Edson Atmel Corporation 1150 E. Cheyenne Mtn. Blvd., MS 10250 Colorado Springs, CO 80906 Phone: 719-540-3220 -- Edit this bug report at http://bugs.php.net/?id=21621edit=1
#21569 [Com]: PHP can't set cookies after a test with an unset variable
ID: 21569
Comment by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
Why does it affect only Windows 2000, while the very same PHP version
with the same php.ini file works fine on Windows 98 ? And it works
fine on Linux too?
To make it clearer, the workarounds are needed only if the scripts
run under Windows 2000, so that the example script returns 1 on
Windows 2000 and 3 on Windows 98 or Linux.
Previous Comments:
[2003-01-13 16:37:48] [EMAIL PROTECTED]
There's really no bug here. You're getting a notice about unitialized
variable which causes the rest of the headers not to get send. Try
adding 'error_reporting(0);' in the beginning of your script..
[2003-01-13 10:48:18] [EMAIL PROTECTED]
Workaround #2:
At the beginning og your script, declare any possibly unset variable
that will be invoked:
if (!isset($test)) {$test=;}
[2003-01-13 10:07:12] [EMAIL PROTECTED]
Workaround (which doesn't mean this bug shouldn't be fixed):
To perform tests:
if (!isset($test) || $test==) { echo ; }
To set a variable:
$a=; if (isset($test)) { $a=$test; }
[2003-01-13 10:05:53] [EMAIL PROTECTED]
I've found out that the problem is not limited to tests. It happens
every time you invoke an unset variable before than setting a cookie.
In the previous example, try
$a = $test;
instead of
if ($test==) { echo ; }
and the setcookie won't work as well.
[2003-01-13 10:03:29] [EMAIL PROTECTED]
This is a shortest example:
?
# $test=;
setcookie(debug,1,0,,);
if ($test==) { echo ; }
setcookie(debug,3,0,,);
echo Cookie: [.$_COOKIE[debug].] (HIT RELOAD)BR;
?
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/21569
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#21340 [Opn-Fbk]: numerics can overflow php numeric datatypes
ID: 21340 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Sybase-ct (ctlib) related Operating System: redhat linux 7.3 PHP Version: 4.3.0 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-01-03 10:28:07] [EMAIL PROTECTED] Update: this patch doesn't quite work, a value of '0' is returned as NULL. In the meantime, I've downgraded to 4.2.3 and will look into this issue more as I get time. [2003-01-02 17:27:56] [EMAIL PROTECTED] Looks like I forgot to seperate CS_DECIMAL_TYPE from the CS_NUMERIC_TYPE string conversion. As far as I can tell, DECIMAL types should still be returned as float/real datatypes, though I am not very familiar with them. I can upload another patch if wanted, but the changes are so minor and straightforward that I don't see a need right now. :) [2003-01-02 10:57:49] [EMAIL PROTECTED] Large NUMERIC (20,0) fields can easily overflow the built-in php datatypes (float, real), causing truncation to 2147483647 (2^31 - 1). Some solutions: 1) Return numerics as string 2) Return numerics as gmp val 3) redesign my database Until (2) becomes a builtin datatype in PHP, I don't see this as a good solution. (3) is out of the question, so I elected to use (1); patch follows. I also have the CS_NUMERIC_TYPE ident as numeric. --- php_sybase_ct.c.old Thu Jan 2 11:42:57 2003 +++ php_sybase_ct.c Thu Jan 2 11:46:18 2003 @@ -1166,9 +1166,9 @@ break; case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: - result-datafmt[i].maxlength = result-datafmt[i].precision + 3; - /* numeric(10) vs numeric(10, 1) */ - result-numerics[i] = (result-datafmt[i].scale == 0) ? 1 : 2; + /* numerics can overflow real and long types, return as a string */ + result-datafmt[i].maxlength++; + result-numerics[i] = 0; break; default: result-datafmt[i].maxlength++; @@ -1769,10 +1769,12 @@ break; case CS_REAL_TYPE: case CS_FLOAT_TYPE: - case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: return real; break; + case CS_NUMERIC_TYPE: + return numeric; + break; case CS_MONEY_TYPE: case CS_MONEY4_TYPE: return money; -- Edit this bug report at http://bugs.php.net/?id=21340edit=1
#21624 [Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: Is there the prospect of a soon bugfix for this problem? Because downgrading to an older version would be a very bad solution... Previous Comments: [2003-01-13 16:40:41] [EMAIL PROTECTED] No, because the very same script works fine with previous versions of PHP. Just because a browser is able to decypher the broken images we generate doesn't mean we are doing it right. [2003-01-13 16:39:10] [EMAIL PROTECTED] PHP generates the very same image for every browser. If it works in 2 browsers and does not work in one, is it not reasonable to assume that the browser where the image does not work is the one at fault? [2003-01-13 16:38:53] [EMAIL PROTECTED] It is a PHP issue. A patch was posted to php-dev a while ago, but nobody has had a chance to look at it yet. [2003-01-13 16:36:56] [EMAIL PROTECTED] Since Version 6.0 Beta 1 Opera fully supports alpha transparency: http://www.opera.com/windows/changelogs/600b1/index.dml So because it worked in previous PHP/GD-versions, I think it is a PHP issue [2003-01-13 16:20:04] [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. Given that the behaviour is incositent across browsers and I cannot replicate the described problem in Mozilla or IE 6.0 I'd say this is a broser and not a PHP issue. Perpahps, Opera cannot handle alpha transparency, which is what is causing the problem, this particular type of transparency would not have been avaliable in older GD library. 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/21624 -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21625 [NEW]: --with-config-file-scan-dir
From: [EMAIL PROTECTED] Operating system: Mandrake Linux 9.0/Cooker PHP version: 4.3.0 PHP Bug Type: PHP options/info functions Bug description: --with-config-file-scan-dir Hi. This --with-config-file-scan-dir=/etc/php is wierd. When compiled as in Mandrake Linux 9.0/Cooker the included files from /etc/php/ is randomly listed when viewed in phpinfo(). Here's an example: This phpinfo.html file was generated from a build from source: http://d-srv.com/Cooker/PRE/phpinfo.html This phpinfo.html file was generated from a RPM build as in/for Mandrake Linux 9.0/Cooker: http://d-srv.com/Cooker/phpinfo.html Also I noticed that php scans recursivly in this /etc/php/ directory which is not very nice (or maybe it's per design?). Chears. -- Edit bug report at http://bugs.php.net/?id=21625edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21625r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21625r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21625r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21625r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21625r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21625r=support Expected behavior: http://bugs.php.net/fix.php?id=21625r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21625r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21625r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21625r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21625r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21625r=dst IIS Stability: http://bugs.php.net/fix.php?id=21625r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21625r=gnused
#21615 [Ver]: PCRE segfault with (very) large string.
ID: 21615 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Reproducible crash Operating System: GNU/linux PHP Version: 4.3.0 New Comment: for information ther's the same bug on php-4.2.3 compiled more infos. With same parameters (only gd external lib was used instead of 4.3 bundled). But this works fine on Mandrake linux 8.2 system with its own rpmized php (php-4.1.2 I think). Don't know if Mandrake team applied a special patch on sources??? Previous Comments: [2003-01-13 16:26:42] [EMAIL PROTECTED] The actual crash occurs inside the pcrelib, so it could pcre related, but since I am unable to replicate the crash using pcre command line tools it maybe PHP related after all. [2003-01-13 10:56:27] [EMAIL PROTECTED] oops: http://planet-service.fr/test2.txt.gz [2003-01-13 10:55:35] [EMAIL PROTECTED] I'm really sorry: http://planet-service.fr/test2.php.gz [2003-01-13 09:53:25] [EMAIL PROTECTED] Cannot download the test script due to what appears to be a parse error. Could you please make the file avaliable as text (.txt). [2003-01-13 07:51:41] [EMAIL PROTECTED] PCRE segfault on a big regular expression on a really big string (17490 chars) special parameters in php.ini file: memory_limit = 64M test script: http://planet-service.fr/test2.php.gz this script test a substring of the crashing string. a loop do the test with this substring, and increase the size of the string at each step and print out the size. I put 17490 as starting size as that crash at 17491. The parameters at at the end of the script (after the string itself). compilation options: ./configure --prefix=/opt/php-4.3.0 --with-apache=../apache_1.3.27 --with-config-file-path=/opt/php-4.3.0/lib --enable-calendar --enable-track-vars --enable-ftp --with-readline --with-imap=/opt/c-client --with-openssl=/opt/openssl --with -gdbm=/usr --with-mysql=/opt/mysql --with-pgsql=/opt/postgresql --enable-trans-sid -with-regex=php --enable-sysvsem --enable-sysvshm --enable-memory-limit --enable-debug=no --with-ttf=/opt/freetype --with-t1lib=/opt/t1lib --with-xml --enable-sockets --with-jpeg-dir=/opt/jpeg --with-tiff-dir=/opt/tiff --with-png-dir=/opt/libpng --with-zlib-dir=/opt/zlib --with-gd --enable-gd-native-ttf --enable-exif --with-pdflib=/opt/pdflib --enable-bcmath --with-ming=/opt/ming --with-bz2=/opt/bzip2 --with-zlib --with-dom=/opt/libxml2 --with-dom-xslt=/opt/libxslt --with-dom-exslt=/opt/libxslt --enable-xslt --with-xslt-sablot=/opt/sablotron --with-expat-dir=/opt/expat --with-ldap=/opt/openldap --with-mcal=/opt/libmcal --with-curl=/opt/curl-7.10.2 --with-iconv=/opt/libiconv --enable-mbstring --with-zip=/opt/zziplib Olivier -- Edit this bug report at http://bugs.php.net/?id=21615edit=1
#21623 [Opn]: Turning on Magic quotes Segfaults PHP
ID: 21623 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Reproducible crash Operating System: RedHat PHP Version: 5CVS-2003-01-13 (dev) New Comment: Does it work with 4.3.0? :) Previous Comments: [2003-01-13 13:44:20] [EMAIL PROTECTED] Here's the bt: One more thing -- magic_quotes_gpc is on and working fine... things also work if the magic quotes runtime are disabled. #0 chunk_alloc (ar_ptr=0x401cd520, nb=105) at malloc.c:2993 #1 0x4011b02c in __libc_malloc (bytes=100) at malloc.c:2811 #2 0x402ae54b in _emalloc (size=83) at /home/php/php4/Zend/zend_alloc.c:158 #3 0x402c0b03 in zend_hash_add_or_update (ht=0x8202e64, arKey=0x8216bc4 s:30:\\\Bad arguments for API function\\\;PNSVuid, nKeyLength=48, pData=0xbfff8b50, nDataSize=4, pDest=0x0, flag=1) at /home/php/php4/Zend/zend_hash.c:262 #4 0x402bff53 in zend_set_hash_symbol (symbol=0x823d7e4, name=0x8216bc4 s:30:\\\Bad arguments for API function\\\;PNSVuid, name_length=47, is_ref=0, num_symbol_tables=1) at /home/php/php4/Zend/zend_API.c:1261 #5 0x4021e4ea in php_set_session_var ( name=0x8216bc4 s:30:\\\Bad arguments for API function\\\;PNSVuid, namelen=47, state_val=0x823d7e4, var_hash=0xbfff8bc8) at /home/php/php4/ext/session/session.c:324 #6 0x4021ec90 in ps_srlzr_decode_php ( val=0x821693c PNSVrand|i:625621835;PNSVlang|s:3:\\\eng\\\;PNSVerrormsg|s:30:\\\Bad arguments for API function\\\;PNSVuid|i:2;PNSVrememberme|i:1;, vallen=126) at /home/php/php4/ext/session/session.c:487 #7 0x4021ef46 in php_session_decode ( val=0x821693c PNSVrand|i:625621835;PNSVlang|s:3:\\\eng\\\;PNSVerrormsg|s:30:\\\Bad arguments for API function\\\;PNSVuid|i:2;PNSVrememberme|i:1;, vallen=126) at /home/php/php4/ext/session/session.c:533 #8 0x4021f3c9 in php_session_initialize () at /home/php/php4/ext/session/session.c:692 #9 0x4022044f in php_session_start () at /home/php/php4/ext/session/session.c:1095 #10 0x402217b9 in zif_session_start (ht=0, return_value=0x823c43c, this_ptr=0x0, return_value_used=0) at /home/php/php4/ext/session/session.c:1540 #11 0x402cfe24 in execute (op_array=0x8204860) at /home/php/php4/Zend/zend_execute.c:1596 #12 0x402cffe2 in execute (op_array=0x812cea0) at /home/php/php4/Zend/zend_execute.c:1640 #13 0x402cffe2 in execute (op_array=0x8111434) at /home/php/php4/Zend/zend_execute.c:1640 #14 0x402bd630 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /home/php/php4/Zend/zend.c:925 #15 0x4029703d in php_execute_script (primary_file=0xb620) at /home/php/php4/main/main.c:1691 #16 0x402d73c6 in apache_php_module_main (r=0x8100e24, display_source_mode=0) at /home/php/php4/sapi/apache/sapi_apache.c:55 #17 0x402d7f32 in send_php (r=0x8100e24, display_source_mode=0, filename=0x0) at /home/php/php4/sapi/apache/mod_php4.c:589 #18 0x402d7f86 in send_parsed_php (r=0x8100e24) at /home/php/php4/sapi/apache/mod_php4.c:604 #19 0x0806a5f7 in ap_invoke_handler () #20 0x0807ee77 in process_request_internal () #21 0x0807f29b in ap_internal_redirect () #22 0x0805f530 in handle_dir () #23 0x0806a5f7 in ap_invoke_handler () #24 0x0807ee77 in process_request_internal () #25 0x0807eed8 in ap_process_request () #26 0x0807612d in child_main () #27 0x080762d8 in make_child () #28 0x0807644c in startup_children () #29 0x08076ac4 in standalone_main () #30 0x08077317 in main () #31 0x400bb306 in __libc_start_main (main=0x8076f80 main, argc=2, ubp_av=0xbb34, init=0x804e5d8 _init, fini=0x8094460 _fini, rtld_fini=0x4000d2dc _dl_fini, stack_end=0xbb2c) at ../sysdeps/generic/libc-start.c:129 [2003-01-13 13:33:06] [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-01-13 13:31:51] [EMAIL PROTECTED] I thought this might be because I was running an older version 4.4-dev version of PHP from CVS that I had hacked up a bit, but it turns out it's in the current CVS as well.. I am honestly not sure why PHP is crashing, but it has something to do with turning magic_quotes_runtime on. It doesn't break all the time, only when using the PostNuke package. Unfortunately I have no idea how/where it crashes... here's the backtrace... (gdb) run -X Starting program: /usr/local/apache/bin/httpd -X Program received signal
#21624 [Opn-Fbk]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: Could you please provide a short example of thew script that can be used to duplicate the problem. Previous Comments: [2003-01-13 17:05:20] [EMAIL PROTECTED] Is there the prospect of a soon bugfix for this problem? Because downgrading to an older version would be a very bad solution... [2003-01-13 16:40:41] [EMAIL PROTECTED] No, because the very same script works fine with previous versions of PHP. Just because a browser is able to decypher the broken images we generate doesn't mean we are doing it right. [2003-01-13 16:39:10] [EMAIL PROTECTED] PHP generates the very same image for every browser. If it works in 2 browsers and does not work in one, is it not reasonable to assume that the browser where the image does not work is the one at fault? [2003-01-13 16:38:53] [EMAIL PROTECTED] It is a PHP issue. A patch was posted to php-dev a while ago, but nobody has had a chance to look at it yet. [2003-01-13 16:36:56] [EMAIL PROTECTED] Since Version 6.0 Beta 1 Opera fully supports alpha transparency: http://www.opera.com/windows/changelogs/600b1/index.dml So because it worked in previous PHP/GD-versions, I think it is a PHP issue 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/21624 -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21624 [Fbk-Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: No, not really. It's a rather low-priority problem. Previous Comments: [2003-01-13 17:18:00] [EMAIL PROTECTED] Could you please provide a short example of thew script that can be used to duplicate the problem. [2003-01-13 17:05:20] [EMAIL PROTECTED] Is there the prospect of a soon bugfix for this problem? Because downgrading to an older version would be a very bad solution... [2003-01-13 16:40:41] [EMAIL PROTECTED] No, because the very same script works fine with previous versions of PHP. Just because a browser is able to decypher the broken images we generate doesn't mean we are doing it right. [2003-01-13 16:39:10] [EMAIL PROTECTED] PHP generates the very same image for every browser. If it works in 2 browsers and does not work in one, is it not reasonable to assume that the browser where the image does not work is the one at fault? [2003-01-13 16:38:53] [EMAIL PROTECTED] It is a PHP issue. A patch was posted to php-dev a while ago, but nobody has had a chance to look at it yet. 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/21624 -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21340 [Fbk-Opn]: numerics can overflow php numeric datatypes
ID: 21340 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Open Bug Type: Sybase-ct (ctlib) related Operating System: redhat linux 7.3 PHP Version: 4.3.0 New Comment: That seems to fix the problem. Will respond if I find any other problems related to this bug. Previous Comments: [2003-01-13 16:49:49] [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-03 10:28:07] [EMAIL PROTECTED] Update: this patch doesn't quite work, a value of '0' is returned as NULL. In the meantime, I've downgraded to 4.2.3 and will look into this issue more as I get time. [2003-01-02 17:27:56] [EMAIL PROTECTED] Looks like I forgot to seperate CS_DECIMAL_TYPE from the CS_NUMERIC_TYPE string conversion. As far as I can tell, DECIMAL types should still be returned as float/real datatypes, though I am not very familiar with them. I can upload another patch if wanted, but the changes are so minor and straightforward that I don't see a need right now. :) [2003-01-02 10:57:49] [EMAIL PROTECTED] Large NUMERIC (20,0) fields can easily overflow the built-in php datatypes (float, real), causing truncation to 2147483647 (2^31 - 1). Some solutions: 1) Return numerics as string 2) Return numerics as gmp val 3) redesign my database Until (2) becomes a builtin datatype in PHP, I don't see this as a good solution. (3) is out of the question, so I elected to use (1); patch follows. I also have the CS_NUMERIC_TYPE ident as numeric. --- php_sybase_ct.c.old Thu Jan 2 11:42:57 2003 +++ php_sybase_ct.c Thu Jan 2 11:46:18 2003 @@ -1166,9 +1166,9 @@ break; case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: - result-datafmt[i].maxlength = result-datafmt[i].precision + 3; - /* numeric(10) vs numeric(10, 1) */ - result-numerics[i] = (result-datafmt[i].scale == 0) ? 1 : 2; + /* numerics can overflow real and long types, return as a string */ + result-datafmt[i].maxlength++; + result-numerics[i] = 0; break; default: result-datafmt[i].maxlength++; @@ -1769,10 +1769,12 @@ break; case CS_REAL_TYPE: case CS_FLOAT_TYPE: - case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: return real; break; + case CS_NUMERIC_TYPE: + return numeric; + break; case CS_MONEY_TYPE: case CS_MONEY4_TYPE: return money; -- Edit this bug report at http://bugs.php.net/?id=21340edit=1
#21615 [Ver]: PCRE segfault with (very) large string.
ID: 21615 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Reproducible crash Operating System: GNU/linux PHP Version: 4.3.0 New Comment: Could you please confirm the PHP PCRE version that are used in the 'working' version, that would be of great help. Previous Comments: [2003-01-13 17:14:36] [EMAIL PROTECTED] for information ther's the same bug on php-4.2.3 compiled more infos. With same parameters (only gd external lib was used instead of 4.3 bundled). But this works fine on Mandrake linux 8.2 system with its own rpmized php (php-4.1.2 I think). Don't know if Mandrake team applied a special patch on sources??? [2003-01-13 16:26:42] [EMAIL PROTECTED] The actual crash occurs inside the pcrelib, so it could pcre related, but since I am unable to replicate the crash using pcre command line tools it maybe PHP related after all. [2003-01-13 10:56:27] [EMAIL PROTECTED] oops: http://planet-service.fr/test2.txt.gz [2003-01-13 10:55:35] [EMAIL PROTECTED] I'm really sorry: http://planet-service.fr/test2.php.gz [2003-01-13 09:53:25] [EMAIL PROTECTED] Cannot download the test script due to what appears to be a parse error. Could you please make the file avaliable as text (.txt). 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/21615 -- Edit this bug report at http://bugs.php.net/?id=21615edit=1
#21340 [Opn-Csd]: numerics can overflow php numeric datatypes
ID: 21340 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Sybase-ct (ctlib) related Operating System: redhat linux 7.3 PHP Version: 4.3.0 New Comment: closing then. Submit new report about any other bug you might encounter. Previous Comments: [2003-01-13 17:19:16] [EMAIL PROTECTED] That seems to fix the problem. Will respond if I find any other problems related to this bug. [2003-01-13 16:49:49] [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-03 10:28:07] [EMAIL PROTECTED] Update: this patch doesn't quite work, a value of '0' is returned as NULL. In the meantime, I've downgraded to 4.2.3 and will look into this issue more as I get time. [2003-01-02 17:27:56] [EMAIL PROTECTED] Looks like I forgot to seperate CS_DECIMAL_TYPE from the CS_NUMERIC_TYPE string conversion. As far as I can tell, DECIMAL types should still be returned as float/real datatypes, though I am not very familiar with them. I can upload another patch if wanted, but the changes are so minor and straightforward that I don't see a need right now. :) [2003-01-02 10:57:49] [EMAIL PROTECTED] Large NUMERIC (20,0) fields can easily overflow the built-in php datatypes (float, real), causing truncation to 2147483647 (2^31 - 1). Some solutions: 1) Return numerics as string 2) Return numerics as gmp val 3) redesign my database Until (2) becomes a builtin datatype in PHP, I don't see this as a good solution. (3) is out of the question, so I elected to use (1); patch follows. I also have the CS_NUMERIC_TYPE ident as numeric. --- php_sybase_ct.c.old Thu Jan 2 11:42:57 2003 +++ php_sybase_ct.c Thu Jan 2 11:46:18 2003 @@ -1166,9 +1166,9 @@ break; case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: - result-datafmt[i].maxlength = result-datafmt[i].precision + 3; - /* numeric(10) vs numeric(10, 1) */ - result-numerics[i] = (result-datafmt[i].scale == 0) ? 1 : 2; + /* numerics can overflow real and long types, return as a string */ + result-datafmt[i].maxlength++; + result-numerics[i] = 0; break; default: result-datafmt[i].maxlength++; @@ -1769,10 +1769,12 @@ break; case CS_REAL_TYPE: case CS_FLOAT_TYPE: - case CS_NUMERIC_TYPE: case CS_DECIMAL_TYPE: return real; break; + case CS_NUMERIC_TYPE: + return numeric; + break; case CS_MONEY_TYPE: case CS_MONEY4_TYPE: return money; -- Edit this bug report at http://bugs.php.net/?id=21340edit=1
#21624 [Opn-Fbk]: no transparent Colors in PNG's with Opera 6/7
ID: 21624 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: RedHat PHP Version: 4.3.0 New Comment: Still waiting for feedback. Previous Comments: [2003-01-13 17:18:02] [EMAIL PROTECTED] No, not really. It's a rather low-priority problem. [2003-01-13 17:18:00] [EMAIL PROTECTED] Could you please provide a short example of thew script that can be used to duplicate the problem. [2003-01-13 17:05:20] [EMAIL PROTECTED] Is there the prospect of a soon bugfix for this problem? Because downgrading to an older version would be a very bad solution... [2003-01-13 16:40:41] [EMAIL PROTECTED] No, because the very same script works fine with previous versions of PHP. Just because a browser is able to decypher the broken images we generate doesn't mean we are doing it right. [2003-01-13 16:39:10] [EMAIL PROTECTED] PHP generates the very same image for every browser. If it works in 2 browsers and does not work in one, is it not reasonable to assume that the browser where the image does not work is the one at fault? 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/21624 -- Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21569 [Bgs]: PHP can't set cookies after a test with an unset variable
ID: 21569
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Windows 2000 only
PHP Version: 4.3.0
New Comment:
Does it work on those other machines, because you already have accepted
cookies, or because they run another OS?
Please make sure you understand how cookies work, specifically, that
they are only 'visible at the next page'.
Also make sure you don't have some automated blocking in effect for the
Windows 2000 machine, by verifying with plain telnet, if the
'SetCookie: ' header is sent rather than trusting the browser.
Previous Comments:
[2003-01-13 16:47:53] [EMAIL PROTECTED]
Why does it affect only Windows 2000, while the very same PHP version
with the same php.ini file works fine on Windows 98 ? And it works
fine on Linux too?
To make it clearer, the workarounds are needed only if the scripts
run under Windows 2000, so that the example script returns 1 on
Windows 2000 and 3 on Windows 98 or Linux.
[2003-01-13 16:37:48] [EMAIL PROTECTED]
There's really no bug here. You're getting a notice about unitialized
variable which causes the rest of the headers not to get send. Try
adding 'error_reporting(0);' in the beginning of your script..
[2003-01-13 10:48:18] [EMAIL PROTECTED]
Workaround #2:
At the beginning og your script, declare any possibly unset variable
that will be invoked:
if (!isset($test)) {$test=;}
[2003-01-13 10:07:12] [EMAIL PROTECTED]
Workaround (which doesn't mean this bug shouldn't be fixed):
To perform tests:
if (!isset($test) || $test==) { echo ; }
To set a variable:
$a=; if (isset($test)) { $a=$test; }
[2003-01-13 10:05:53] [EMAIL PROTECTED]
I've found out that the problem is not limited to tests. It happens
every time you invoke an unset variable before than setting a cookie.
In the previous example, try
$a = $test;
instead of
if ($test==) { echo ; }
and the setcookie won't work as well.
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/21569
--
Edit this bug report at http://bugs.php.net/?id=21569edit=1
#21624 [Fbk-Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Open
Bug Type: GD related
Operating System: RedHat
PHP Version: 4.3.0
New Comment:
iliaa:
?
header('Content-type: image/png');
$Image = imagecreate(300,150);
$Body = imagecolorallocate($Image,222,222,222);
$Char = imagecolorallocate($Image,10,36,106);
imagecolortransparent($Image,$Char);
imagechar($Image,5,100,50,P,$Char);
imagepng($Image);
?
rasmus: yeah but I think this problem perhaps only DOESN'T appear with
IE Mozilla but with most other browsers...
Previous Comments:
[2003-01-13 17:21:36] [EMAIL PROTECTED]
Still waiting for feedback.
[2003-01-13 17:18:02] [EMAIL PROTECTED]
No, not really. It's a rather low-priority problem.
[2003-01-13 17:18:00] [EMAIL PROTECTED]
Could you please provide a short example of thew script that can be
used to duplicate the problem.
[2003-01-13 17:05:20] [EMAIL PROTECTED]
Is there the prospect of a soon bugfix for this problem?
Because downgrading to an older version would be a very bad solution...
[2003-01-13 16:40:41] [EMAIL PROTECTED]
No, because the very same script works fine with previous versions of
PHP. Just because a browser is able to decypher the broken images we
generate doesn't mean we are doing it right.
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/21624
--
Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21472 [Opn-Csd]: Problems with short tags and script tags
ID: 21472 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Scripting Engine problem Operating System: Windows 2000 PHP Version: 4.3.0 New Comment: Closed then, feel free to open it again if you have an another problem. Thank you for your report. Previous Comments: [2003-01-13 14:48:31] [EMAIL PROTECTED] script tags must have the language variable in s now whereas before they did not have to be, this makes them work. [2003-01-09 07:50:13] [EMAIL PROTECTED] I do not have any special ASP items installed on the servers, and we do not use ASP pages either. [2003-01-08 18:03:54] [EMAIL PROTECTED] do you have ASP installed as well? [2003-01-07 07:54:33] [EMAIL PROTECTED] A. It says C:\WINNT\php.ini B. I edited that file to change the value for short tags to 1, or on. C. Restarted IIS. D. PHPINFO says that the directive is on. [2003-01-06 15:44:45] [EMAIL PROTECTED] Please be specific with the questions below: 1) EXACTLY what does (a) say from below? 2) Did you restart the web server after editing? 3) What does phpinfo() say for this directive? 4) What value are you assigning to this directive in php.ini? 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/21472 -- Edit this bug report at http://bugs.php.net/?id=21472edit=1
#21624 [Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: RedHat
PHP Version: 4.3.0
New Comment:
Sure, but most other browsers make up a very very small percentage of
what people use.
Anyway, a potential patch for this was posted a couple of weeks ago.
Try the code referenced in the article below and let us know if it
fixes it:
http://news.php.net/article.php?group=php.devarticle=93058
Previous Comments:
[2003-01-13 17:23:41] [EMAIL PROTECTED]
iliaa:
?
header('Content-type: image/png');
$Image = imagecreate(300,150);
$Body = imagecolorallocate($Image,222,222,222);
$Char = imagecolorallocate($Image,10,36,106);
imagecolortransparent($Image,$Char);
imagechar($Image,5,100,50,P,$Char);
imagepng($Image);
?
rasmus: yeah but I think this problem perhaps only DOESN'T appear with
IE Mozilla but with most other browsers...
[2003-01-13 17:21:36] [EMAIL PROTECTED]
Still waiting for feedback.
[2003-01-13 17:18:02] [EMAIL PROTECTED]
No, not really. It's a rather low-priority problem.
[2003-01-13 17:18:00] [EMAIL PROTECTED]
Could you please provide a short example of thew script that can be
used to duplicate the problem.
[2003-01-13 17:05:20] [EMAIL PROTECTED]
Is there the prospect of a soon bugfix for this problem?
Because downgrading to an older version would be a very bad solution...
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/21624
--
Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21543 [Opn-Csd]: unsupported field type errors with lvarchars
ID: 21543 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: Informix related Operating System: All PHP Version: 4.3.0 New Comment: Ah, they've changed the version line in later releases. Your patch is now committed to CVS, thank you. Previous Comments: [2003-01-13 09:41:42] [EMAIL PROTECTED] sorry, it seems that i had a problem submitting the answer a few days ago. here is the version info from out RH8 linux box: # $INFORMIXDIR/bin/esql -V IBM Informix CSDK Version 2.80, IBM Informix-ESQL Version 9.52.UC2 Software Serial Number RDS#. [2003-01-09 19:55:28] [EMAIL PROTECTED] What is the output of 'esql -V' for you to require this? The version detection works fine here.. (and what OS? Is it GNU sed you have there?) [2003-01-09 06:26:59] [EMAIL PROTECTED] lvarchars are not supported, because 'ext/informix/config.m4' gets a wrong version number from 'esql -V'. So HAVE_IFX_IUS is not set. with this patch the problem should be solved: --- php-4.3.0/ext/informix/config.m4.org2003-01-09 11:15:07.0 +0100 +++ php-4.3.0/ext/informix/config.m42003-01-09 11:15:11.0 +0100 @@ -44,7 +44,7 @@ esac AC_MSG_CHECKING([Informix version]) - IFX_VERSION=[`$INFORMIXDIR/bin/esql -V | sed -ne '1 s/^[^0-9]*\([0-9]\)\.\([0-9]*\).*/\1\2/p'`] + IFX_VERSION=[`$INFORMIXDIR/bin/esql -V | sed -ne '1 s/^.*Version \([0-9]\)\.\([0-9]*\).*$/\1\2/p'`] AC_MSG_RESULT($IFX_VERSION) AC_DEFINE_UNQUOTED(IFX_VERSION, $IFX_VERSION, [ ]) Oliver -- Edit this bug report at http://bugs.php.net/?id=21543edit=1
#21565 [Opn]: include/require fail under safe-mode.
ID: 21565 Updated by: [EMAIL PROTECTED] -Summary: safe_mode works well with include but not with require Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Scripting Engine problem Operating System: Tru64Unix 5.1A PHP Version: 4.3.0 New Comment: updated the summary line. Previous Comments: [2003-01-13 04:09:18] [EMAIL PROTECTED] Well, you are right with the difference fatal error vs. warning. After I turned the warning messages on I can see the difference. So, the problem should be re-classified as a problem of both include and require. Still, with safe_mode on, it does not work, with safe_mode off, it works fine. [2003-01-10 16:56:46] [EMAIL PROTECTED] It is likely that your error reporting level is such that warning messages do not get shown. Unlike require which fails with an error include will only output a warning on failure. Beyond that there is very little difference between the require/include code none of which is the code reponsible for actually openning files. [2003-01-10 03:35:37] [EMAIL PROTECTED] After upgrade from PHP 4.2.2 to 4.3.0 I encountered the problem with safe_mode in conjunction with require(). Example: [php.ini] safe_mode = On; include_path = .:./:/path/to/my/app/dir; safe_mode_include_dir = .:./:/path/to/my/app/dir; [/path/to/my/app/dir/index_working.php] - works fine for me ?php include header.php; ? [/path/to/my/app/dir/index_buggy.php] - throws error ?php require header.php; ? The error: [error] PHP Fatal error: main() [a href='http://www.php.net/function.main'function.main/a]: Failed opening required 'header.php' (include_path='.:./:/path/to/my/app/dir') in /path/to/my/app/dir/index_buggy.php on line 2 Operating system: Tru64Unix 5.1a Webserver: Apache 1.3.26 -- Edit this bug report at http://bugs.php.net/?id=21565edit=1
#21367 [Opn-Fbk]: FastCGI -b option error
ID: 21367 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 New Comment: -b is not available for fastcgi binary..iirc, the binary provided in the release package is compiled with the fastcgi support turned on. You can check that with 'php -v' Previous Comments: [2003-01-02 19:54:26] [EMAIL PROTECTED] I've downloaded the full Win32 PHP binary and the -b argument that should Bind Path for external FASTCGI server mode doesn't work. What happens is: c:\phpphp -b 5000 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b I read on php.dev newsgroup that this is the right way to start FastCGI support since SAPI/FastCGI was discontinued. But it doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21367edit=1
#21565 [Opn-Fbk]: include/require fail under safe-mode.
ID: 21565 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Tru64Unix 5.1A PHP Version: 4.3.0 New Comment: Do you get any other warning/error messages, something about UID of the script not matching that of the file? Previous Comments: [2003-01-13 17:37:23] [EMAIL PROTECTED] updated the summary line. [2003-01-13 04:09:18] [EMAIL PROTECTED] Well, you are right with the difference fatal error vs. warning. After I turned the warning messages on I can see the difference. So, the problem should be re-classified as a problem of both include and require. Still, with safe_mode on, it does not work, with safe_mode off, it works fine. [2003-01-10 16:56:46] [EMAIL PROTECTED] It is likely that your error reporting level is such that warning messages do not get shown. Unlike require which fails with an error include will only output a warning on failure. Beyond that there is very little difference between the require/include code none of which is the code reponsible for actually openning files. [2003-01-10 03:35:37] [EMAIL PROTECTED] After upgrade from PHP 4.2.2 to 4.3.0 I encountered the problem with safe_mode in conjunction with require(). Example: [php.ini] safe_mode = On; include_path = .:./:/path/to/my/app/dir; safe_mode_include_dir = .:./:/path/to/my/app/dir; [/path/to/my/app/dir/index_working.php] - works fine for me ?php include header.php; ? [/path/to/my/app/dir/index_buggy.php] - throws error ?php require header.php; ? The error: [error] PHP Fatal error: main() [a href='http://www.php.net/function.main'function.main/a]: Failed opening required 'header.php' (include_path='.:./:/path/to/my/app/dir') in /path/to/my/app/dir/index_buggy.php on line 2 Operating system: Tru64Unix 5.1a Webserver: Apache 1.3.26 -- Edit this bug report at http://bugs.php.net/?id=21565edit=1
#21367 [Fbk-Ver]: FastCGI -b option error
ID: 21367 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Verified Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 New Comment: Verified: C:\php4php -v PHP 4.3.0 (cgi-fcgi), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies C:\php4php -h [snip] -b address:port|port Bind Path for external FASTCGI Server mode [snip] C:\php4php -b 127.0.0.1:12345 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Previous Comments: [2003-01-13 17:41:33] [EMAIL PROTECTED] -b is not available for fastcgi binary..iirc, the binary provided in the release package is compiled with the fastcgi support turned on. You can check that with 'php -v' [2003-01-02 19:54:26] [EMAIL PROTECTED] I've downloaded the full Win32 PHP binary and the -b argument that should Bind Path for external FASTCGI server mode doesn't work. What happens is: c:\phpphp -b 5000 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b I read on php.dev newsgroup that this is the right way to start FastCGI support since SAPI/FastCGI was discontinued. But it doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21367edit=1
#21367 [Ver]: FastCGI -b option error
ID: 21367 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Verified Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 New Comment: -b is ONLY available was what I wanted to say. :) Anyway, if you have any of these set in your environment: SERVER_SOFTWARE SERVER_NAME GATEWAY_INTERFACE REQUEST_METHOD then it won't be available. Previous Comments: [2003-01-13 17:47:08] [EMAIL PROTECTED] Verified: C:\php4php -v PHP 4.3.0 (cgi-fcgi), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies C:\php4php -h [snip] -b address:port|port Bind Path for external FASTCGI Server mode [snip] C:\php4php -b 127.0.0.1:12345 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b [2003-01-13 17:41:33] [EMAIL PROTECTED] -b is not available for fastcgi binary..iirc, the binary provided in the release package is compiled with the fastcgi support turned on. You can check that with 'php -v' [2003-01-02 19:54:26] [EMAIL PROTECTED] I've downloaded the full Win32 PHP binary and the -b argument that should Bind Path for external FASTCGI server mode doesn't work. What happens is: c:\phpphp -b 5000 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b I read on php.dev newsgroup that this is the right way to start FastCGI support since SAPI/FastCGI was discontinued. But it doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21367edit=1
#21624 [Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: RedHat
PHP Version: 4.3.0
New Comment:
The example script works perfectly with: Konqueror 3.0, IE 6.0, Mozilla
1.3a, IE6 and Opera 6.02 (Linux). I am using bundled GD with libpng
1.2.0.
Once I compiled libpng 1.2.5 and tried running the same script the
image no longer worked in any browser.
Previous Comments:
[2003-01-13 17:26:14] [EMAIL PROTECTED]
Sure, but most other browsers make up a very very small percentage of
what people use.
Anyway, a potential patch for this was posted a couple of weeks ago.
Try the code referenced in the article below and let us know if it
fixes it:
http://news.php.net/article.php?group=php.devarticle=93058
[2003-01-13 17:23:41] [EMAIL PROTECTED]
iliaa:
?
header('Content-type: image/png');
$Image = imagecreate(300,150);
$Body = imagecolorallocate($Image,222,222,222);
$Char = imagecolorallocate($Image,10,36,106);
imagecolortransparent($Image,$Char);
imagechar($Image,5,100,50,P,$Char);
imagepng($Image);
?
rasmus: yeah but I think this problem perhaps only DOESN'T appear with
IE Mozilla but with most other browsers...
[2003-01-13 17:21:36] [EMAIL PROTECTED]
Still waiting for feedback.
[2003-01-13 17:18:02] [EMAIL PROTECTED]
No, not really. It's a rather low-priority problem.
[2003-01-13 17:18:00] [EMAIL PROTECTED]
Could you please provide a short example of thew script that can be
used to duplicate the problem.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21624
--
Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21367 [Ver-Asn]: FastCGI -b option error
ID: 21367 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Assigned Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 -Assigned To: +Assigned To: shane Previous Comments: [2003-01-13 17:51:18] [EMAIL PROTECTED] -b is ONLY available was what I wanted to say. :) Anyway, if you have any of these set in your environment: SERVER_SOFTWARE SERVER_NAME GATEWAY_INTERFACE REQUEST_METHOD then it won't be available. [2003-01-13 17:47:08] [EMAIL PROTECTED] Verified: C:\php4php -v PHP 4.3.0 (cgi-fcgi), Copyright (c) 1997-2002 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2002 Zend Technologies C:\php4php -h [snip] -b address:port|port Bind Path for external FASTCGI Server mode [snip] C:\php4php -b 127.0.0.1:12345 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b [2003-01-13 17:41:33] [EMAIL PROTECTED] -b is not available for fastcgi binary..iirc, the binary provided in the release package is compiled with the fastcgi support turned on. You can check that with 'php -v' [2003-01-02 19:54:26] [EMAIL PROTECTED] I've downloaded the full Win32 PHP binary and the -b argument that should Bind Path for external FASTCGI server mode doesn't work. What happens is: c:\phpphp -b 5000 Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b Error in argument 1, char 2: option not found b I read on php.dev newsgroup that this is the right way to start FastCGI support since SAPI/FastCGI was discontinued. But it doesn't work. -- Edit this bug report at http://bugs.php.net/?id=21367edit=1
#21624 [Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624
User updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: RedHat
PHP Version: 4.3.0
New Comment:
The patch doesn't fix this problem :(
I changed the code and reconfigured/-compiled, but the example still
only works correct in Mozilla.
I think the best way would be to use an older version of libpng, e.g.
version 1.0.15 from http://www.libpng.org/pub/png/libpng.html, right?
Previous Comments:
[2003-01-13 17:54:17] [EMAIL PROTECTED]
The example script works perfectly with: Konqueror 3.0, IE 6.0, Mozilla
1.3a, IE6 and Opera 6.02 (Linux). I am using bundled GD with libpng
1.2.0.
Once I compiled libpng 1.2.5 and tried running the same script the
image no longer worked in any browser.
[2003-01-13 17:26:14] [EMAIL PROTECTED]
Sure, but most other browsers make up a very very small percentage of
what people use.
Anyway, a potential patch for this was posted a couple of weeks ago.
Try the code referenced in the article below and let us know if it
fixes it:
http://news.php.net/article.php?group=php.devarticle=93058
[2003-01-13 17:23:41] [EMAIL PROTECTED]
iliaa:
?
header('Content-type: image/png');
$Image = imagecreate(300,150);
$Body = imagecolorallocate($Image,222,222,222);
$Char = imagecolorallocate($Image,10,36,106);
imagecolortransparent($Image,$Char);
imagechar($Image,5,100,50,P,$Char);
imagepng($Image);
?
rasmus: yeah but I think this problem perhaps only DOESN'T appear with
IE Mozilla but with most other browsers...
[2003-01-13 17:21:36] [EMAIL PROTECTED]
Still waiting for feedback.
[2003-01-13 17:18:02] [EMAIL PROTECTED]
No, not really. It's a rather low-priority problem.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21624
--
Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21525 [Ana-Asn]: bind_textdomain_codeset() missing
ID: 21525 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Assigned Bug Type: Gettext related Operating System: Win2k PHP Version: 4.3.0 Assigned To: edink Previous Comments: [2003-01-11 09:49:13] [EMAIL PROTECTED] I just compiled the dll with HAVE_BIND_TEXTDOMAIN_CODESET defined. Everything went well and I'm retrieving UTF-8 strings now. I'm using libintl.dll from http://gettext.sourceforge.net Would you like a patch for gettext.dsp with defined HAVE_BIND_TEXTDOMAIN_CODESET? Will this be fixed in the next PHP release? [2003-01-08 14:58:15] [EMAIL PROTECTED] What is the codeset used by gettext() on Win32? I'm looking for UTF-8. Is this supported? Is gettext() using the codeset specified in the .mo file? [2003-01-08 14:48:35] [EMAIL PROTECTED] The function appears to be dependant on HAVE_BIND_TEXTDOMAIN_CODESET, which is not defined in Win32 builds. [2003-01-08 14:04:56] [EMAIL PROTECTED] Trying to use bind_textdomain_codeset() with the PHP 4.3.0 binaries results in the following error: Fatal error: Call to undefined function: bind_textdomain_codeset() Is the php_gettext.dll in the 4.3.0 release outdated? -- Edit this bug report at http://bugs.php.net/?id=21525edit=1
#21624 [Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: RedHat
PHP Version: 4.3.0
New Comment:
It was my fault libpng 1.2.5 didn't work (header confusion). Once I
clean the headers up the code once again worked properly. The only
browser with which I can duplicate the problem is Netscape 4.7 on
Linux.
Previous Comments:
[2003-01-13 18:02:26] [EMAIL PROTECTED]
The patch doesn't fix this problem :(
I changed the code and reconfigured/-compiled, but the example still
only works correct in Mozilla.
I think the best way would be to use an older version of libpng, e.g.
version 1.0.15 from http://www.libpng.org/pub/png/libpng.html, right?
[2003-01-13 17:54:17] [EMAIL PROTECTED]
The example script works perfectly with: Konqueror 3.0, IE 6.0, Mozilla
1.3a, IE6 and Opera 6.02 (Linux). I am using bundled GD with libpng
1.2.0.
Once I compiled libpng 1.2.5 and tried running the same script the
image no longer worked in any browser.
[2003-01-13 17:26:14] [EMAIL PROTECTED]
Sure, but most other browsers make up a very very small percentage of
what people use.
Anyway, a potential patch for this was posted a couple of weeks ago.
Try the code referenced in the article below and let us know if it
fixes it:
http://news.php.net/article.php?group=php.devarticle=93058
[2003-01-13 17:23:41] [EMAIL PROTECTED]
iliaa:
?
header('Content-type: image/png');
$Image = imagecreate(300,150);
$Body = imagecolorallocate($Image,222,222,222);
$Char = imagecolorallocate($Image,10,36,106);
imagecolortransparent($Image,$Char);
imagechar($Image,5,100,50,P,$Char);
imagepng($Image);
?
rasmus: yeah but I think this problem perhaps only DOESN'T appear with
IE Mozilla but with most other browsers...
[2003-01-13 17:21:36] [EMAIL PROTECTED]
Still waiting for feedback.
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/21624
--
Edit this bug report at http://bugs.php.net/?id=21624edit=1
#21624 [Opn]: no transparent Colors in PNG's with Opera 6/7
ID: 21624
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: GD related
Operating System: RedHat
PHP Version: 4.3.0
New Comment:
I guess this is a different problem then than the one described by
Steven Brown.
Previous Comments:
[2003-01-13 18:13:18] [EMAIL PROTECTED]
It was my fault libpng 1.2.5 didn't work (header confusion). Once I
clean the headers up the code once again worked properly. The only
browser with which I can duplicate the problem is Netscape 4.7 on
Linux.
[2003-01-13 18:02:26] [EMAIL PROTECTED]
The patch doesn't fix this problem :(
I changed the code and reconfigured/-compiled, but the example still
only works correct in Mozilla.
I think the best way would be to use an older version of libpng, e.g.
version 1.0.15 from http://www.libpng.org/pub/png/libpng.html, right?
[2003-01-13 17:54:17] [EMAIL PROTECTED]
The example script works perfectly with: Konqueror 3.0, IE 6.0, Mozilla
1.3a, IE6 and Opera 6.02 (Linux). I am using bundled GD with libpng
1.2.0.
Once I compiled libpng 1.2.5 and tried running the same script the
image no longer worked in any browser.
[2003-01-13 17:26:14] [EMAIL PROTECTED]
Sure, but most other browsers make up a very very small percentage of
what people use.
Anyway, a potential patch for this was posted a couple of weeks ago.
Try the code referenced in the article below and let us know if it
fixes it:
http://news.php.net/article.php?group=php.devarticle=93058
[2003-01-13 17:23:41] [EMAIL PROTECTED]
iliaa:
?
header('Content-type: image/png');
$Image = imagecreate(300,150);
$Body = imagecolorallocate($Image,222,222,222);
$Char = imagecolorallocate($Image,10,36,106);
imagecolortransparent($Image,$Char);
imagechar($Image,5,100,50,P,$Char);
imagepng($Image);
?
rasmus: yeah but I think this problem perhaps only DOESN'T appear with
IE Mozilla but with most other browsers...
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/21624
--
Edit this bug report at http://bugs.php.net/?id=21624edit=1
#18288 [Fbk-NoF]: browscap.ini and get_browser()
ID: 18288 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: * PHP Version: 4.3.0 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-12-29 23:01:38] [EMAIL PROTECTED] Can you try this again please? It should work better now and please get an up-to-date browscap.ini at: http://www.garykeith.com/browsers/downloads.asp The one at cyscape is outdated by about two years. [2002-09-11 11:35:37] [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. [2002-07-26 06:22:52] [EMAIL PROTECTED] Are you sure it's not the browscap.ini file? Anyway, this thing has not worked very well for a long time.. [2002-07-26 02:49:08] [EMAIL PROTECTED] The problem is that when I use the browsecap function, i am supposed to get a bunch of information back. I get stuff that tells me I am using netscape 4.0 and I am running IE 6. If this is working correctly, what good is the browse cap function? [2002-07-25 23:43:04] [EMAIL PROTECTED] Thats the environment variables that your browser sends. Saying that its Mozilla not a PHP bug. Bogusing. 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/18288 -- Edit this bug report at http://bugs.php.net/?id=18288edit=1
#21260 [Fbk-NoF]: phpBB fails to work with GD turned on
ID: 21260 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: GD related Operating System: Linux PHP Version: 4.3.0 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-12-28 22:35:24] [EMAIL PROTECTED] Please run the following test on your system: 1) Create a file named testgd.php in the document root of your webserver with the following content: ?php $img = imagecreate(100,100); $black = imagecolorallocate($img,0,0,0); $white = imagecolorallocate($img,255,255,255); imagefilledrectangle($img,0,0,99,99,$white); imagerectangle($img,0,0,99,99,$black); header(Content-type: image/png); imagePNG($img); ? 2) Browse the URL for that page (i.e.: http://myserver.com/testgd.php ) 3) Tell us if a white square with a black frame appears. If the image shows properly then the problem is likely with PHPBB and there's nothing anyone here can do. If not, then there may be a problem with your GD build. [2002-12-28 21:56:17] [EMAIL PROTECTED] I use PHPbb on my web site(I have also already reported this problem to them) when I install PHP without the new GD support in 4.3.0 turned on everything works fine, however if I turn the GD support on the PHPbb fails to load and all I get is a blank page...no errors no anything The following are my configure lines PHPbb works ./configure --with-mysql=/mysql --with-apxs PHPbb doesn't work... ./configure --with-mysql=/mysql --with-apxs --with-gd --with-zlib-dir=/usr/include I should mention that I also use phpMyAdmin...and that works fine either way -- Edit this bug report at http://bugs.php.net/?id=21260edit=1
#21273 [Fbk-NoF]: memory_limit seems to be ignored
ID: 21273 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: PHP options/info functions Operating System: Windows 2000 service pack 3 PHP Version: 4.3.0 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-12-29 14:51:16] [EMAIL PROTECTED] seems to be the same with php 4.2.3 am I doing something wrong ? [2002-12-29 14:39:25] [EMAIL PROTECTED] Configuration File (php.ini) Path C:\WINNT\php.ini You need a screenshot ? [2002-12-29 14:37:07] [EMAIL PROTECTED] What does phpinfo() tell you about the location of php.ini? Derick [2002-12-29 14:32:06] [EMAIL PROTECTED] I have memory_limit = 8M in php.ini (c:\winnt\php.ini) phpinfo(); doesn't show me the limit. Also the limit is not obeyed. I can make big fsockopen(), fgets no error. The same with memory_limit=4M or 16M (php is standard from downloaded win32 binary, php-ini-dist) Is there something new in php 4.3 ?? -- Edit this bug report at http://bugs.php.net/?id=21273edit=1
#21281 [Fbk]: False Line output
ID: 21281 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: *General Issues Operating System: Win2k PHP Version: 4.3.0 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: [2002-12-30 17:32:23] [EMAIL PROTECTED] i'm sure that it is PHP 4.3.0 that is not my fault because i know why the notice message appears but i only wanted to tell you that. [2002-12-30 00:35:47] [EMAIL PROTECTED] hmm, this is indeed weird... are you sure this is the 4.3.0 release? as I remember reporting and fixing this issue. Derick [2002-12-30 00:35:09] [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. [2002-12-29 20:03:12] [EMAIL PROTECTED] hello dear debugger :) i got this funny notice in a script: - Notice: Undefined variable: tdw in D:\Eigene Dateien\Gernot\Homepage\under construction\Cheat-script\admin.php on line 951037880 - it's not that it really disturbs me but i wanted to tell you that. thank you for your attention :-) have a nice day -- Edit this bug report at http://bugs.php.net/?id=21281edit=1
#21339 [Opn-Fbk]: cannot compile gettext support
ID: 21339
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
-Bug Type: Compile Failure
+Bug Type: Gettext related
Operating System: Solaris 8
-PHP Version: 4.2.3
+PHP Version: 4.3.0
New Comment:
Could you try with an older gettext version?
Like 0.10.40, which I know works for sure.
Previous Comments:
[2003-01-02 10:28:29] [EMAIL PROTECTED]
Compiler: SUNWspro 5.0 (same with gcc 2.95.2)
# ./configure --prefix=/lfs/web1/php-4.2.3
--with-apxs=/lfs/web1/apache-1.3.27/bin/apxs --enable-safe-mode
--with-exec-dir=/lfs/web1/php-bin
--with-openssl=/lfs/web1/openssl-0.9.6g
--with-zlib-dir=/lfs/web1/zlib-1.1.4 --enable-calendar
--with-gdbm=/lfs/web1/gdbm-1.8.0 --enable-dbx --enable-ftp
--with-gd=/lfs/web1/gd-2.0.8 --with-jpeg-dir=/lfs/web1/libjpeg-6b
--with-png-dir=/lfs/web1/libpng-1.2.5 --enable-gd-native-ttf
--with-mysql=/lfs/web1/mysql-3.23.39 --with-oci8=/lfs/web1/oracle-8.1.7
--with-pdflib=/lfs/web1/pdflib-4.0.3 --with-mm=/lfs/web1/mm-1.1.3
--enable-sockets --enable-sysvsem --enable-sysvshm
--with-zip=/lfs/web1/zziplib-0.10.27
--with-gettext=/lfs/web1/gettext-0.11.5
--with-iconv=/lfs/web1/libiconv-1.8
# make (only significant part)
/bin/sh libtool --silent --mode=compile cc -Iext/gettext/
-I/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/
-DPHP_ATOM_INC -I/lfs/scratch/apache-1.3.27-build/php-4.3.0/include
-I/lfs/scratch/apache-1.3.27-build/php-4.3.0/main
-I/lfs/scratch/apache-1.3.27-build/php-4.3.0
-I/lfs/scratch/apache-1.3.27-build/php-4.3.0/Zend
-I/lfs/web1/openssl-0.9.6g/include -I/lfs/web1/zlib-1.1.4/include
-I/lfs/web1/gdbm-1.8.0/include -I/lfs/web1/libjpeg-6b/include
-I/lfs/web1/libpng-1.2.5/include -I/lfs/web1/gd-2.0.8/include
-I/lfs/web1/gettext-0.11.5/include -I/lfs/web1/libiconv-1.8/include
-I/lfs/web1/mysql-3.23.39/include/mysql
-I/lfs/web1/oracle-8.1.7/rdbms/public
-I/lfs/web1/oracle-8.1.7/rdbms/demo -I/lfs/web1/pdflib-4.0.3/include
-I/lfs/web1/mm-1.1.3/include
-I/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/xml/expat
-I/lfs/web1/zziplib-0.10.27/include -D_POSIX_PTHREAD_SEMANTICS
-DSOLARIS2=280 -DMOD_SSL=208112 -DMOD_PERL -DUSE_PERL_SSI -DEAPI
-DEAPI_MM -I/lfs/scratch/apache-1.3.27-build/php-4.3.0/TSRM -fast
-xtarget=ultra -xarch=v8a -prefer-pic -c
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c -o
ext/gettext/gettext.lo
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c,
line 37: undefined symbol: zif_libintl_textdomain
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c,
line 37: warning: improper pointer/integer combination: op =
...(stripped of a lot of look a likes)...
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c,
line 37: non-constant initializer: op NAME
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c,
line 282: identifier redeclared: zif_libintl_bind_textdomain_codeset
current : function(int, pointer to struct _zval_struct {union
_zvalue_value {..} value, uchar type, uchar is_ref, ushort refcount},
po...
previous: int :
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c,
line 53
cc: acomp failed for
/lfs/scratch/apache-1.3.27-build/php-4.3.0/ext/gettext/gettext.c
*** Error code 1
make: Fatal error: Command failed for target `ext/gettext/gettext.lo'
I can get the compile working if I move function_entry
php_gettext_functions[] and zend_module_entry
php_gettext_module_entry to the end of the gettext.c file but than I
get an UNREF for zm_info_gettext...
--
Edit this bug report at http://bugs.php.net/?id=21339edit=1
#21614 [Opn-Bgs]: Non-ASCII characters get entity escaped on input from MSIE only
ID: 21614 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: Various PHP Version: 4.2.3 New Comment: Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to Open. Again, thank you for your continued support of PHP. Previous Comments: [2003-01-13 07:29:01] [EMAIL PROTECTED] Entering non-ASCII data (eg in ISO-8859-1) using MSIE 6 and 5.5 (possibly others) via an HTTP POST (multipart/form-data, perhaps others) request to PHP 4.2.3 as a dynamically-loaded Apache (1.3 series) module causes the non-ASCII characters to be HTML entity escaped. eg: étan - eacute;tan This does not happen with Mozilla 1.2b (20021016), and did not happen with PHP 4.1.2 (with mbstring enabled). It happens with both mbstring enabled and disabled on PHP 4.2.3. It has been observed on Debian GNU/Linux, FreeBSD and WinXP. -- Edit this bug report at http://bugs.php.net/?id=21614edit=1
#21606 [Opn-Fbk]: binary value not returned correctly
ID: 21606 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: LDAP related Operating System: Linux Debian 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. Previous Comments: [2003-01-12 23:55:19] [EMAIL PROTECTED] binary value which is kept in LDAP (like userCertificate or jpegPhoto attributes) not returned correctly when ldap_search call is made. In fact it returns only a few bytes of full attribute value. The problem is probably in some symbols in binary file which are cannot be exported by PHP so PHP simply breaks an export. Below is hex-dump of what is actually exported instead of full file: for jpegPhoto attribute: FF D8 FF 00 for userCertificate attribute: 30 82 03 68 30 82 03 0B A0 03 02 01 -- Edit this bug report at http://bugs.php.net/?id=21606edit=1
#21625 [Opn-Fbk]: --with-config-file-scan-dir
ID: 21625 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: PHP options/info functions Operating System: Mandrake Linux 9.0/Cooker PHP Version: 4.3.0 New Comment: What do you mean with 'randomly listed' ? Listed in random order or only some files are listed..? Previous Comments: [2003-01-13 17:10:49] [EMAIL PROTECTED] Hi. This --with-config-file-scan-dir=/etc/php is wierd. When compiled as in Mandrake Linux 9.0/Cooker the included files from /etc/php/ is randomly listed when viewed in phpinfo(). Here's an example: This phpinfo.html file was generated from a build from source: http://d-srv.com/Cooker/PRE/phpinfo.html This phpinfo.html file was generated from a RPM build as in/for Mandrake Linux 9.0/Cooker: http://d-srv.com/Cooker/phpinfo.html Also I noticed that php scans recursivly in this /etc/php/ directory which is not very nice (or maybe it's per design?). Chears. -- Edit this bug report at http://bugs.php.net/?id=21625edit=1
