#21600 [Ctl]: assign by reference function call changes variable contents
ID: 21600 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Critical Bug Type: Scripting Engine problem -Operating System: Redhat 8 +Operating System: Redhat 7.3, 8 -PHP Version: 4.3.0 +PHP Version: 4.3.0, 5.0.0 New Comment: update version Previous Comments: [2003-01-13 19:42:44] [EMAIL PROTECTED] I'm marking this critical because the provided script works fine on the previous released versions. [2003-01-13 01:21:08] [EMAIL PROTECTED] backtrace (with php-5.0.0-dev): #0 0x40749e49 in __sbrk (increment=1515880448) at ../sysdeps/generic/sbrk.c:33 #1 0x406e9d3c in __default_morecore (increment=1515880448) at ../sysdeps/generic/morecore.c:47 #2 0x406e676d in chunk_alloc (ar_ptr=0x40798520, nb=1515878480) at malloc.c:2583 #3 0x406e60bc in __libc_malloc (bytes=1515878476) at malloc.c:2817 #4 0x08256b63 in zend_mm_add_memory_block (heap=0x8333748, block_size=1515878476) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:143 #5 0x08256de6 in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:236 #6 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #7 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #8 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #9 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #10 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #11 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #12 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) (last frame continues atleast 15.000 times) Derick [2003-01-12 15:56:50] [EMAIL PROTECTED] Verified with HEAD(ZE2) and PHP_4_3(ZE1). The provided script causes segmentation fault. [2003-01-12 15:07:10] [EMAIL PROTECTED] under 4.3.0 with apache 2.0.40 I see this strange behavior with aliasing: $foo = "Philip Johnson's \"Glass House\" remains one of the most famous residences in the world."; $foo =& bar($foo); print $foo; function bar($text){ return $text; } outputs: Philip Johnson's "Glass House" remains one of the most famous residences in the worlh This didn't happen under 4.2.3. Although really this was a mistake on my part (I meant to do $foo = bar($foo)) it seems like strange behavior nonetheless. It's also strange to me that if I change return $text; to return "$text"; it works as I would expect. -- Edit this bug report at http://bugs.php.net/?id=21600&edit=1
#21625 [Bgs->Opn]: --with-config-file-scan-dir
ID: 21625 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: PHP options/info functions Operating System: Mandrake Linux 9.0/Cooker PHP Version: 4.3.0 New Comment: oops, sorry Previous Comments: [2003-01-14 00:43:27] [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 [2003-01-13 19:46:35] [EMAIL PROTECTED] Is there a way to cleanly add a patch to bugs.php.net? I e-mailed it to sniper and oden, but anyways, here it is. Hope it's readable... --- php-4.3.0/main/php_ini.c.orig 2003-01-13 18:17:18.0 -0400 +++ php-4.3.0/main/php_ini.c2003-01-13 19:03:23.0 -0400 @@ -30,6 +30,9 @@ #include "zend_highlight.h" #include "SAPI.h" #include "php_main.h" +#include +#include +extern int alphasort(); =20 #ifndef S_ISREG #define S_ISREG(mode) (((mode) & S_IFMT) =3D=3D S_IFREG) @@ -232,6 +235,8 @@ zend_file_handle fh; DIR *dirp =3D NULL; struct dirent *dir_entry; + struct dirent **inifiles; + int inicount,i; struct stat sb; char ini_file[MAXPATHLEN]; char *p; @@ -400,10 +405,11 @@ dirp =3D VCWD_OPENDIR(PHP_CONFIG_FILE_SCAN_DIR); if (dirp) { fh.type =3D ZEND_HANDLE_FP; - while ((dir_entry =3D readdir(dirp)) !=3D NULL) { + inicount =3D scandir(PHP_CONFIG_FILE_SCAN_DIR, &inifiles, NULL, alphaso= rt); + for(i=3D1;id_name,'.')) && strcmp(p,".ini")) contin= ue; - snprintf(ini_file, MAXPATHLEN, "%s%c%s", PHP_CONFIG_FILE_SCAN_DIR, DEF= AULT_SLASH, dir_entry->d_name); + if ((p =3D strrchr(inifiles[i-1]->d_name,'.')) && strcmp(p,".ini")) co= ntinue; + snprintf(ini_file, MAXPATHLEN, "%s%c%s", PHP_CONFIG_FILE_SCAN_DIR, DEF= AULT_SLASH, inifiles[i-1]->d_name); if (VCWD_STAT(ini_file, &sb) =3D=3D 0) { if (S_ISREG(sb.st_mode)) { if ((fh.handle.fp =3D VCWD_FOPEN(ini_file, "r"))) { [2003-01-13 19:42:35] [EMAIL PROTECTED] php_ini.c uses readdir, which gives all the files on the directory, *but in the order of the filesystem*. ie, it's acting like "ls -U", instead of just "ls". The problem is that there is no way of knowing which file will be loaded first and which one will be loaded last, with causes problems with the way Mandrake loads extensions, as we create ini files in the format 16_dba.ini ... 52_xslt.ini. Those files contain the "extention =3D" directive, so that modules can be loaded in the right order. For tricky extensions, like recode (who has to be loaded first), apc and pspell (who have to be loaded last), we need to be able to control the load order of the ini files. I enclose a small hack I made using scandir and alphasort. It should work on BSD and Linux systems, maybe on other platforms, so we should use ifdefines on platforms that do not support it. Regards, Jean-Michel Dault MandrakeSoft Apache/PHP packager [2003-01-13 19:03:07] [EMAIL PROTECTED] What do you mean with 'randomly listed' ? Listed in random order or only some files are listed..? [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=21625&edit=1
#21625 [Fbk->Bgs]: --with-config-file-scan-dir
ID: 21625 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Bogus Bug Type: PHP options/info functions Operating System: Mandrake Linux 9.0/Cooker PHP Version: 4.3.0 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2003-01-13 19:46:35] [EMAIL PROTECTED] Is there a way to cleanly add a patch to bugs.php.net? I e-mailed it to sniper and oden, but anyways, here it is. Hope it's readable... --- php-4.3.0/main/php_ini.c.orig 2003-01-13 18:17:18.0 -0400 +++ php-4.3.0/main/php_ini.c2003-01-13 19:03:23.0 -0400 @@ -30,6 +30,9 @@ #include "zend_highlight.h" #include "SAPI.h" #include "php_main.h" +#include +#include +extern int alphasort(); =20 #ifndef S_ISREG #define S_ISREG(mode) (((mode) & S_IFMT) =3D=3D S_IFREG) @@ -232,6 +235,8 @@ zend_file_handle fh; DIR *dirp =3D NULL; struct dirent *dir_entry; + struct dirent **inifiles; + int inicount,i; struct stat sb; char ini_file[MAXPATHLEN]; char *p; @@ -400,10 +405,11 @@ dirp =3D VCWD_OPENDIR(PHP_CONFIG_FILE_SCAN_DIR); if (dirp) { fh.type =3D ZEND_HANDLE_FP; - while ((dir_entry =3D readdir(dirp)) !=3D NULL) { + inicount =3D scandir(PHP_CONFIG_FILE_SCAN_DIR, &inifiles, NULL, alphaso= rt); + for(i=3D1;id_name,'.')) && strcmp(p,".ini")) contin= ue; - snprintf(ini_file, MAXPATHLEN, "%s%c%s", PHP_CONFIG_FILE_SCAN_DIR, DEF= AULT_SLASH, dir_entry->d_name); + if ((p =3D strrchr(inifiles[i-1]->d_name,'.')) && strcmp(p,".ini")) co= ntinue; + snprintf(ini_file, MAXPATHLEN, "%s%c%s", PHP_CONFIG_FILE_SCAN_DIR, DEF= AULT_SLASH, inifiles[i-1]->d_name); if (VCWD_STAT(ini_file, &sb) =3D=3D 0) { if (S_ISREG(sb.st_mode)) { if ((fh.handle.fp =3D VCWD_FOPEN(ini_file, "r"))) { [2003-01-13 19:42:35] [EMAIL PROTECTED] php_ini.c uses readdir, which gives all the files on the directory, *but in the order of the filesystem*. ie, it's acting like "ls -U", instead of just "ls". The problem is that there is no way of knowing which file will be loaded first and which one will be loaded last, with causes problems with the way Mandrake loads extensions, as we create ini files in the format 16_dba.ini ... 52_xslt.ini. Those files contain the "extention =3D" directive, so that modules can be loaded in the right order. For tricky extensions, like recode (who has to be loaded first), apc and pspell (who have to be loaded last), we need to be able to control the load order of the ini files. I enclose a small hack I made using scandir and alphasort. It should work on BSD and Linux systems, maybe on other platforms, so we should use ifdefines on platforms that do not support it. Regards, Jean-Michel Dault MandrakeSoft Apache/PHP packager [2003-01-13 19:03:07] [EMAIL PROTECTED] What do you mean with 'randomly listed' ? Listed in random order or only some files are listed..? [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=21625&edit=1
#21565 [Fbk->Opn]: include/require fail under safe-mode.
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: I turned all errors and warnings reporting to have maximum info. Here is a real example from my web, with real paths in filesystem. Both "include" and "require" are used to demonstrate the difference, previously, I used only "require". Strange is that in php 4.2.2 it worked fine for me. The only difference is the upgraded php dynamic module for Apache. It is not the problem of non-existing files or paths because with safe_mode = Off the included and required files are found and opened with no errors. The Catalogue The output of this is: Warning: main() [function.main]: Unable to access ./header.php in /usr/users/dbminer/public_html/index.php on line 2 Warning: main(header.php) [function.main]: failed to create stream: No such file or directory in /usr/users/dbminer/public_html/index.php on line 2 Warning: main() [function.main]: Failed opening 'header.php' for inclusion (include_path='.:./:/usr/users/komanek/public_html/TEST/phpclasses:/usr/local/lib/php:/usr/local/www/apache/htdocs/MINER:/usr/users/dbminer/public_html:/usr/users/popin/html2/statistics/i') in /usr/users/dbminer/public_html/index.php on line 2 The Catalogue Warning: main() [function.main]: Unable to access ./footer.php in /usr/users/dbminer/public_html/index.php on line 11 Warning: main(footer.php) [function.main]: failed to create stream: No such file or directory in /usr/users/dbminer/public_html/index.php on line 11 Fatal error: main() [function.main]: Failed opening required 'footer.php' (include_path='.:./:/usr/users/komanek/public_html/TEST/phpclasses:/usr/local/lib/php:/usr/local/www/apache/htdocs/MINER:/usr/users/dbminer/public_html:/usr/users/popin/html2/statistics/i') in /usr/users/dbminer/public_html/index.php on line 11 >From filesystem: lib[0]:/usr/users/dbminer/public_html(07:04)# ls -al index.php header.php footer.php -rw-r--r-- 1 dbminer users174 Oct 30 2000 footer.php -rw-r--r-- 1 dbminer users 1047 Nov 7 2001 header.php -rw-r--r-- 1 dbminer users161 Jan 13 12:08 index.php Configure switches: --with-apache=/scratch/sources/apache_1.3.26 --with-openssl --with-zlib=/usr/local --with-zlib-dir=/usr/local --with-bz2=/usr/local --with-db --enable-dbase --with-gd --with-dom --enable-ftp --enable-gd-native-ttf --with-freetype-dir=/usr/local/freetype2 --with-iconv --with-mysql --enable-trans-sid --with-jpeg-dir=/usr/local/lib --with-png-dir=/usr/local/lib --enable-sockets --enable-discard-path --enable-safe-mode --enable-bcmatch --enable-calendar --enable-ctype --enable-mailparse --enable-force-cgi-redirect --enable-memory-limit --with-expat-dir=/usr/local --with-xml --with-gettext --with-mcrypt --with-imap=/scratch/sources/imap/imap-2002.RC2 --with-imap-ssl=/scratch/sources/imap/imap-2002.RC2 --disable-cgi Previous Comments: [2003-01-13 17:45:48] [EMAIL PROTECTED] Do you get any other warning/error messages, something about UID of the script not matching that of the file? [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 [/path/to/my/app/dir/index_buggy.php] - throws error The error: [error] PHP Fatal error: main() [function.main]: Failed opening required 'header.php' (include_path='.:./:/path/to/my/app/dir') in /path/to/my/app/d
#21450 [Com]: File Posts from Microsoft Web Publishing Wizard don't work.
ID: 21450 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Feature/Change Request Operating System: Windows 2000 Pro PHP Version: 4CVS-2003-01-05 (dev) Assigned To: sesser New Comment: Is there any chance of mergeing this one into 4.3? Thanks - Mike :-) Previous Comments: [2003-01-07 05:26:35] [EMAIL PROTECTED] Thanks. Works fine now :-) [2003-01-07 03:48:00] [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-06 02:15:56] [EMAIL PROTECTED] Content-disposition: form-data; filename="etc\root.hint" This line of the rfc1867 fileupload lacks a name="whatever" attribute. PHP cannot handle anonymous fileuploads for now... (I will implement that) [2003-01-05 22:29:03] [EMAIL PROTECTED] Here is a capture of a complete request made by WPW: POST /temp/fb.php HTTP/1.1 Accept: */* Content-Type: Multipart/Form-Data,boundary=19359@23195#13275 User-Agent: Microsoft HTTP Post (RFC1867) Host: 10.0.0.7 Connection: Keep-Alive Cache-Control: no-cache Content-Length: 3002 --19359@23195#13275 Content-disposition: form-data; filename="etc\root.hint" Content-type: application/octet-stream ; This file holds the information on root name servers needed to ; initialize cache of Internet domain name servers ; (e.g. reference this file in the "cache . " ; configuration file of BIND domain name servers). ; ; This file is made available by InterNIC registration services ; under anonymous FTP as ; file/domain/named.root ; on server FTP.RS.INTERNIC.NET ; -OR- under Gopher atRS.INTERNIC.NET ; under menu InterNIC Registration Services (NSI) ; submenu InterNIC Registration Archives ; filenamed.root ; ; last update:Aug 22, 1997 ; related version of root zone: 1997082200 ; ; ; formerly NS.INTERNIC.NET ; .360 IN NSA.ROOT-SERVERS.NET. A.ROOT-SERVERS.NET. 360 A 198.41.0.4 ; ; formerly NS1.ISI.EDU ; .360 NSB.ROOT-SERVERS.NET. B.ROOT-SERVERS.NET. 360 A 128.9.0.107 ; ; formerly C.PSI.NET ; .360 NSC.ROOT-SERVERS.NET. C.ROOT-SERVERS.NET. 360 A 192.33.4.12 ; ; formerly TERP.UMD.EDU ; .360 NSD.ROOT-SERVERS.NET. D.ROOT-SERVERS.NET. 360 A 128.8.10.90 ; ; formerly NS.NASA.GOV ; .360 NSE.ROOT-SERVERS.NET. E.ROOT-SERVERS.NET. 360 A 192.203.230.10 ; ; formerly NS.ISC.ORG ; .360 NSF.ROOT-SERVERS.NET. F.ROOT-SERVERS.NET. 360 A 192.5.5.241 ; ; formerly NS.NIC.DDN.MIL ; .360 NSG.ROOT-SERVERS.NET. G.ROOT-SERVERS.NET. 360 A 192.112.36.4 ; ; formerly AOS.ARL.ARMY.MIL ; .360 NSH.ROOT-SERVERS.NET. H.ROOT-SERVERS.NET. 360 A 128.63.2.53 ; ; formerly NIC.NORDU.NET ; .360 NSI.ROOT-SERVERS.NET. I.ROOT-SERVERS.NET. 360 A 192.36.148.17 ; ; temporarily housed at NSI (InterNIC) ; .360 NSJ.ROOT-SERVERS.NET. J.ROOT-SERVERS.NET. 360 A 198.41.0.10 ; ; housed in LINX, operated by RIPE NCC ; .360 NSK.ROOT-SERVERS.NET. K.ROOT-SERVERS.NET. 360 A 193.0.14.129 ; ; temporarily housed at ISI (IANA) ; .360 NSL.ROOT-SERVERS.NET. L.ROOT-SERVERS.NET. 360 A 198.32.64.12 ; ; housed in Japan, operated by WIDE ; .360 NSM.ROOT-SERVERS.NET. M.ROOT-SERVERS.NET. 360 A 202.12.27.33 ; End of File --19359@23195#13275-- [2003-01-05 21:47:40] [EMAIL PROTECTED] When usin
#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: To Nice PHP staff: It seemed that PHP does not handle SMALLDATETIME format well. When I execute this SQL statement: select GetDate(), CAST(GetDate() as SMALLDATETIME) I got this: "Tue 14, Jan 2003, 12:12:42","2003 ¤@¤ë 14 12:13¤U¤È" with mssql.datetimeconvert=Off and/or with ini_set ('mssql.datetimeconvert',0); To meeder: My MSSQL problem would cause PHP to hang everytime. Just on connection would cause system to crash. What is your crashing symptom ? 'Too many connection would crash' sounds like presistant-connection-spooler-full or CGI-ERROR problem. Previous Comments: [2003-01-13 08:44:39] [EMAIL PROTECTED] 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 [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. The remainder of the comments for this report are too long. To view the rest of the comments, please view th
#21367 [Com]: FastCGI -b option error
ID: 21367 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned Bug Type: Other web server Operating System: WinXP PHP Version: 4.3.0 Assigned To: shane New Comment: My "php -v" and "php -h" are exactly equal as the above one. I don't have any of those envvars set and it still doesn't work. 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:\php4>php -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:\php4>php -h [snip] -b | Bind Path for external FASTCGI Server mode [snip] C:\php4>php -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:\php>php -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=21367&edit=1
#12358 [Com]: CGI Error-CGI application misbehaved
ID: 12358 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: PWS related Operating System: windows 98 PHP Version: 4.0.6 New Comment: I'm getting the same problem. It's not about setting cgi.force_redirect=0 in php.ini, that was for a different problem and that one is now fixed. So what is causing this error? Any help greatly appreciated! CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: Previous Comments: [2002-06-25 03:55:17] [EMAIL PROTECTED] set cgi.force_redirect=0 in your php.ini [2001-08-20 12:04:57] [EMAIL PROTECTED] no feedback. [2001-07-25 06:30:11] [EMAIL PROTECTED] provide a short example script, and it's output when run from the command line. save this as test.php: and see what you get. it should be st. like this: c:\temp>php test.php X-Powered-By: PHP/4.0.7-dev Content-type: text/html hello world! c:\temp> If that's ok (i. e. the first three lines are the same as shown above, I suggest you turn on logging errors in php.ini, request a PHP script thru PWS, and check the error log. [2001-07-25 05:58:53] [EMAIL PROTECTED] I has installed php4.0 from www.php.net.My os is windows 98 and i am using PWS.when I run any php program in browser I am getting the following error CGI Error The specified CGI application misbehaved by not returning a complete set of HTTP headers. The headers it did return are: whn I run php.exe in dos prompt I am getting the html file correctly.While running in the browser,I am getting the above error. Any body please help me My email id is [EMAIL PROTECTED] bye suresh -- Edit this bug report at http://bugs.php.net/?id=12358&edit=1
#21625 [Com]: --with-config-file-scan-dir
ID: 21625 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: PHP options/info functions Operating System: Mandrake Linux 9.0/Cooker PHP Version: 4.3.0 New Comment: Is there a way to cleanly add a patch to bugs.php.net? I e-mailed it to sniper and oden, but anyways, here it is. Hope it's readable... --- php-4.3.0/main/php_ini.c.orig 2003-01-13 18:17:18.0 -0400 +++ php-4.3.0/main/php_ini.c2003-01-13 19:03:23.0 -0400 @@ -30,6 +30,9 @@ #include "zend_highlight.h" #include "SAPI.h" #include "php_main.h" +#include +#include +extern int alphasort(); =20 #ifndef S_ISREG #define S_ISREG(mode) (((mode) & S_IFMT) =3D=3D S_IFREG) @@ -232,6 +235,8 @@ zend_file_handle fh; DIR *dirp =3D NULL; struct dirent *dir_entry; + struct dirent **inifiles; + int inicount,i; struct stat sb; char ini_file[MAXPATHLEN]; char *p; @@ -400,10 +405,11 @@ dirp =3D VCWD_OPENDIR(PHP_CONFIG_FILE_SCAN_DIR); if (dirp) { fh.type =3D ZEND_HANDLE_FP; - while ((dir_entry =3D readdir(dirp)) !=3D NULL) { + inicount =3D scandir(PHP_CONFIG_FILE_SCAN_DIR, &inifiles, NULL, alphaso= rt); + for(i=3D1;id_name,'.')) && strcmp(p,".ini")) contin= ue; - snprintf(ini_file, MAXPATHLEN, "%s%c%s", PHP_CONFIG_FILE_SCAN_DIR, DEF= AULT_SLASH, dir_entry->d_name); + if ((p =3D strrchr(inifiles[i-1]->d_name,'.')) && strcmp(p,".ini")) co= ntinue; + snprintf(ini_file, MAXPATHLEN, "%s%c%s", PHP_CONFIG_FILE_SCAN_DIR, DEF= AULT_SLASH, inifiles[i-1]->d_name); if (VCWD_STAT(ini_file, &sb) =3D=3D 0) { if (S_ISREG(sb.st_mode)) { if ((fh.handle.fp =3D VCWD_FOPEN(ini_file, "r"))) { Previous Comments: [2003-01-13 19:42:35] [EMAIL PROTECTED] php_ini.c uses readdir, which gives all the files on the directory, *but in the order of the filesystem*. ie, it's acting like "ls -U", instead of just "ls". The problem is that there is no way of knowing which file will be loaded first and which one will be loaded last, with causes problems with the way Mandrake loads extensions, as we create ini files in the format 16_dba.ini ... 52_xslt.ini. Those files contain the "extention =3D" directive, so that modules can be loaded in the right order. For tricky extensions, like recode (who has to be loaded first), apc and pspell (who have to be loaded last), we need to be able to control the load order of the ini files. I enclose a small hack I made using scandir and alphasort. It should work on BSD and Linux systems, maybe on other platforms, so we should use ifdefines on platforms that do not support it. Regards, Jean-Michel Dault MandrakeSoft Apache/PHP packager [2003-01-13 19:03:07] [EMAIL PROTECTED] What do you mean with 'randomly listed' ? Listed in random order or only some files are listed..? [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=21625&edit=1
#21600 [Ver->Ctl]: assign by reference function call changes variable contents
ID: 21600 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Verified +Status: Critical Bug Type: Scripting Engine problem Operating System: Redhat 8 PHP Version: 4.3.0 New Comment: I'm marking this critical because the provided script works fine on the previous released versions. Previous Comments: [2003-01-13 01:21:08] [EMAIL PROTECTED] backtrace (with php-5.0.0-dev): #0 0x40749e49 in __sbrk (increment=1515880448) at ../sysdeps/generic/sbrk.c:33 #1 0x406e9d3c in __default_morecore (increment=1515880448) at ../sysdeps/generic/morecore.c:47 #2 0x406e676d in chunk_alloc (ar_ptr=0x40798520, nb=1515878480) at malloc.c:2583 #3 0x406e60bc in __libc_malloc (bytes=1515878476) at malloc.c:2817 #4 0x08256b63 in zend_mm_add_memory_block (heap=0x8333748, block_size=1515878476) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:143 #5 0x08256de6 in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:236 #6 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #7 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #8 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #9 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #10 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #11 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) at /dat/dev/php/php-5.0.0dev/Zend/zend_mm.c:240 #12 0x08256e0e in zend_mm_alloc (heap=0x8333748, size=1515878448) (last frame continues atleast 15.000 times) Derick [2003-01-12 15:56:50] [EMAIL PROTECTED] Verified with HEAD(ZE2) and PHP_4_3(ZE1). The provided script causes segmentation fault. [2003-01-12 15:07:10] [EMAIL PROTECTED] under 4.3.0 with apache 2.0.40 I see this strange behavior with aliasing: $foo = "Philip Johnson's \"Glass House\" remains one of the most famous residences in the world."; $foo =& bar($foo); print $foo; function bar($text){ return $text; } outputs: Philip Johnson's "Glass House" remains one of the most famous residences in the worlh This didn't happen under 4.2.3. Although really this was a mistake on my part (I meant to do $foo = bar($foo)) it seems like strange behavior nonetheless. It's also strange to me that if I change return $text; to return "$text"; it works as I would expect. -- Edit this bug report at http://bugs.php.net/?id=21600&edit=1
#21625 [Com]: --with-config-file-scan-dir
ID: 21625 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Feedback Bug Type: PHP options/info functions Operating System: Mandrake Linux 9.0/Cooker PHP Version: 4.3.0 New Comment: php_ini.c uses readdir, which gives all the files on the directory, *but in the order of the filesystem*. ie, it's acting like "ls -U", instead of just "ls". The problem is that there is no way of knowing which file will be loaded first and which one will be loaded last, with causes problems with the way Mandrake loads extensions, as we create ini files in the format 16_dba.ini ... 52_xslt.ini. Those files contain the "extention =3D" directive, so that modules can be loaded in the right order. For tricky extensions, like recode (who has to be loaded first), apc and pspell (who have to be loaded last), we need to be able to control the load order of the ini files. I enclose a small hack I made using scandir and alphasort. It should work on BSD and Linux systems, maybe on other platforms, so we should use ifdefines on platforms that do not support it. Regards, Jean-Michel Dault MandrakeSoft Apache/PHP packager Previous Comments: [2003-01-13 19:03:07] [EMAIL PROTECTED] What do you mean with 'randomly listed' ? Listed in random order or only some files are listed..? [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=21625&edit=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: Can't reproduce it. Are you sure the php.ini that is actually read (see phpinfo()) is EXACTLY the same? Look into error_reporting and display_errors specifically. If so, what are these settings? Is there anything related in the apache/php error log? Previous Comments: [2003-01-13 17:28:03] [EMAIL PROTECTED] Just because of the OS. I know how cookies work. Actually I've noticed it while working on a web engine that couldn't keep user logged *only* when it ran on a Windows 2000/Apache/PHP/MySQL server so I decided to investigate. [2003-01-13 17:22:42] [EMAIL PROTECTED] 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. [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="";} 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=21569&edit=1
#21189 [Opn->Fbk]: TTF output function frose Apache
ID: 21189 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: GD related Operating System: windows 2000/sp3 PHP Version: 4.3.0RC4 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-27 11:36:44] [EMAIL PROTECTED] I have problems too, the same OS (Win2k sp3) with php_gd.dll and php_gd2.dll and php 4.2.3 & php 4.3.0RC4 php installed as an Apache 1.3.24 module I use the gd only to produce small png, and i get error using imagettfbbox with this script: - the results : - php 4.2.3 with php_gd.dll 99% CPU used and a lot of ram, forced to stop apache service nothing appears in the php error log. - php 4.2.3 with php_gd2.dll "Unable to find font" warning, with a relative link to the font or with an absolute link. no image is drawn. - php 4.3.0RC4 with php_gd.dll 99% CPU used and a lot of ram, forced to stop apache service nothing appears in the php error log. - php 4.3.0RC4 with php_gd2.dll "Could not set character size" warning... Don't know why... And the strange thing is that sometimes the image is drawn, and sometimes not. the script worked before on php 4.2.1, gd2, apache 1.3.?. [2002-12-26 17:20:50] [EMAIL PROTECTED] Small note, TTF library is not thread safe, meaning that in Win32 enviroment it may not operate well. [2002-12-26 04:55:12] [EMAIL PROTECTED] Hello! I made crash tests using WebRoller software. I set to 10 requests my PHP code from 50 virtual clients simultaneously, and run 40 iterations. I test php with php_gd.dll and php_gd2.dll. in second case apache generates error on windows console (GPF) I use next code: after crash test my system was frosen,apache haves 99% CPU and a lot of memory. As next, I comment string with ImageTTFText function and test it again. Apache lives! Below I will provide output from WebRollers test results: Results from WebRoller with TTF function: --- Start statistics --- --- Basic statistics --- Min:50.00 20.00 30.00 50.00 70.00 60.00 30.00 30.00 Avg:514.82 602.53 785.38 827.82 378.96 238.82 200.40 199.07 Max:3270.00 4990.00 6350.00 7550.00 3410.00 2680.00 510.00 560.00 --- Network traffic details --- Total bytes sent :124242 Total bytes received :347208 Average input speed : 1152 bytes/sec --- Summary times --- Virtual Clients statistics: Count TimeAR/SAT/R 100 1322442 0.0813224.42 110 1290436 0.0911731.24 101 1320349 0.0813072.76 101 1320809 0.0813077.32 114 1260793 0.0911059.59 110 1262395 0.0911476.32 99 1234395 0.0812468.64 101 1293280 0.0812804.75 101 1320759 0.0813076.82 111 1263257 0.0911380.69 Total work time:1337293 Total requests made:1048 Total average time per request: 1198.4126 Total average requests per second: 0.8344 --- Errors report --- Total 425 errors!!! Net :6 T/O :419 --- HTTP response codes details --- CodeCount 200 629 --- End statistics --- Results from WebRoller without TTF function: --- Start statistics --- --- Basic statistics --- Min:60.00 110.00 90.00 100.00 100.00 100.00 50.00 40.00 Avg:188.26 189.40 189.84 189.44 190.40 188.78 187.64 187.96 Max:240.00 280.00 310.00 330.00 290.00 260.00 270.00 280.00 --- Network traffic details --- Total bytes sent :475530 Average output speed : 47553 bytes/sec Total bytes received : 1844000 Average input speed : 2382 bytes/sec --- Summary times --- Virtual Clients statistics: Count TimeAR/SAT/R 400 78002 5.13195.01 400 78052 5.12195.13 400 77862 5.14194.66 400 78162 5.12195.41 400 78262 5.11195.66 400 78202 5.11195.51 400 78122 5.12195.31 400 78202 5.11195.51 400 78232 5.11195.58 400 77942 5.13194.85 Total work time:78342 Total requests made:4000 Total average time per request: 19.5948 Total average requests per second: 51.0341 --- HTTP response codes details --- CodeCount 200 4000 --- End statistics --- -- Edit this bug report at http://bugs.php.net/?id=21189&edit=1
#21626 [Opn->Bgs]: ucwords() fails to capitalize words in parenthesis
ID: 21626 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Strings related Operating System: Debian GNU/Linux 3.0 (Woody) PHP Version: 4.2.1 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Previous Comments: [2003-01-13 19:06:35] [EMAIL PROTECTED] When using ucwords() on a string which contains words in parenthesis, the first word in the parenthesis is not capitalized. Here's a quick example, pasted from an xterm. -- snip -- ieure!Phaktory:~$ cat ucwords.php #!/usr/bin/php4 -q ieure!Phaktory:~$ ./ucwords.php 'test' Test ieure!Phaktory:~$ ./ucwords.php 'test test' Test Test ieure!Phaktory:~$ ./ucwords.php 'test test (test)' Test Test (test) ieure!Phaktory:~$ ./ucwords.php 'test test (test test)' Test Test (test Test) ieure!Phaktory:~$ ./ucwords.php 'test test ( test test)' Test Test ( Test Test) ieure!Phaktory:~$ -- snip -- As you can see, ucwords() won't capitalize the first 'test' when there is no whitespace between the open-parenthesis and the first letter. Affects both CGI and Apache module versions. Here's the script I used to test the apache module: -- Edit this bug report at http://bugs.php.net/?id=21626&edit=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: 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 images on the specified site work just fine for me in my Opera (6.02 Linux). I'm marking the bug as bogus since I cannot replicate the problem, nor do I see the described problem on the specified site with 4 different browsers. Quircks of win32 Opera are surely not related to PHP. Previous Comments: [2003-01-13 18:37:56] [EMAIL PROTECTED] So there isn't a possibility to fix this? iliaa: And it don't works with Opera 6/7 for Windows. If you got to http://www.partykel.de you'll see that in IE/Mozilla, the mainmenu-buttons (generated with gd & libpng) at the top are transparent and in Opera they aren't. [2003-01-13 18:15:53] [EMAIL PROTECTED] I guess this is a different problem then than the one described by Steven Brown. [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. 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=21624&edit=1
#21626 [NEW]: ucwords() fails to capitalize words in parenthesis
From: [EMAIL PROTECTED] Operating system: Debian GNU/Linux 3.0 (Woody) PHP version: 4.2.1 PHP Bug Type: Strings related Bug description: ucwords() fails to capitalize words in parenthesis When using ucwords() on a string which contains words in parenthesis, the first word in the parenthesis is not capitalized. Here's a quick example, pasted from an xterm. -- snip -- ieure!Phaktory:~$ cat ucwords.php #!/usr/bin/php4 -q ieure!Phaktory:~$ ./ucwords.php 'test' Test ieure!Phaktory:~$ ./ucwords.php 'test test' Test Test ieure!Phaktory:~$ ./ucwords.php 'test test (test)' Test Test (test) ieure!Phaktory:~$ ./ucwords.php 'test test (test test)' Test Test (test Test) ieure!Phaktory:~$ ./ucwords.php 'test test ( test test)' Test Test ( Test Test) ieure!Phaktory:~$ -- snip -- As you can see, ucwords() won't capitalize the first 'test' when there is no whitespace between the open-parenthesis and the first letter. Affects both CGI and Apache module versions. Here's the script I used to test the apache module: -- Edit bug report at http://bugs.php.net/?id=21626&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21626&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21626&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21626&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21626&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21626&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21626&r=support Expected behavior: http://bugs.php.net/fix.php?id=21626&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21626&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21626&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21626&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21626&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21626&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21626&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21626&r=gnused
#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=21625&edit=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=21606&edit=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 -> é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=21614&edit=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=21339&edit=1
#21447 [Opn->Fbk]: gettext stopped working
ID: 21447 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: Gettext related Operating System: Linux Red Hat 8.0 PHP Version: 4.2.2 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-11 23:11:40] [EMAIL PROTECTED] restored correct summary. [2003-01-11 18:19:40] [EMAIL PROTECTED] No, I am using a stock Red Hat 8.0 and by default it should use the old process-per-request model (at least, httpd -l gives Compiled in modules: core.c prefork.c http_core.c mod_so.c Any suggestion? [2003-01-05 18:58:36] [EMAIL PROTECTED] Which worker model are you using? If you are using a thread based (worker) model you should be aware that gettext library is NOT thread safe and therefor you will encounter problems when you try using it within the threaded enviroment. [2003-01-05 18:55:58] [EMAIL PROTECTED] After installing Red Hat Linux 8.0 with Apache 2, gettext support stopped working. I am using the sequence of calls putenv("LANG=".$_ERW_locale); setlocale(LC_MESSAGES, $_ERW_locale); bindtextdomain("ERW", $_ERW_localePath); textdomain("ERW"); to bind the text domain, and this worked perfectly in several different ERW installations (http://erw.dsi.unimi.it/) up to the upgrade. It is very difficult to give any other hint. If you create a script like and the translation file is located as follows /home/vigna/cvs/ERW/php/locale/it_IT/LC_MESSAGES/ERW.mo the string does not get translated. The complete lack of feedback of any of the gettext package functions makes it also very difficult to understand what's going wrong. -- Edit this bug report at http://bugs.php.net/?id=21447&edit=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: So there isn't a possibility to fix this? iliaa: And it don't works with Opera 6/7 for Windows. If you got to http://www.partykel.de you'll see that in IE/Mozilla, the mainmenu-buttons (generated with gd & libpng) at the top are transparent and in Opera they aren't. Previous Comments: [2003-01-13 18:15:53] [EMAIL PROTECTED] I guess this is a different problem then than the one described by Steven Brown. [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.dev&article=93058 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=21624&edit=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=21281&edit=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=21273&edit=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: 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=21260&edit=1
#21256 [Fbk->NoF]: PHP crashes on executing 'php --version'
ID: 21256 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: RedHat Linux 8 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 16:51:28] [EMAIL PROTECTED] Please disable the Zend Extensions from php.ini; my guess is that they are not compatible with PHP 4.3.0. (I see zm_activate_dbg in one of the last frames in your stack dump). Derick [2002-12-28 16:49:39] [EMAIL PROTECTED] Executing 'php --version' causes "Segmentation fault" on RH 8 (i386). Also, Apache 2.0 hangs during opening .php pages. - Configure line: "--with-apxs2=/usr/sbin/apxs --host=i686-pc-linux-gnu --build=i686-pc-linux-gn u --target=i386-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr - -bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --included ir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sha redstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr - -with-config-file-path=/etc --enable-force-cgi-redirect --enable-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 --w ith-gd --enable-gd-native-ttf --with-ttf --with-gdbm --with-gettext --with-ncurs es --with-gmp --with-iconv --with-jpeg-dir=/usr --with-openssl --with-png --wi th-pspell --with-regex=system --with-xml --with-expat-dir=/usr --with-zlib --wit h-layout=GNU --enable-bcmath --enable-exif --enable-ftp --enable-magic-quotes -- enable-safe-mode --enable-sockets --enable-sysvsem --enable-sysvshm --enable-disca rd-path --enable-track-vars --enable-trans-sid --enable-yp --enable-wddx --witho ut-oci8 --with-pear=/usr/share/pear --with-imap=shared --with-imap-ssl --with-kerb eros=/usr/kerberos --with-ldap=shared --with-mysql=shared,/usr --with-pgsql=shared --with-snmp=shared,/usr --with-snmp=shared --enable-ucd-snmp-hack --with-unixODBC=s hared --enable-memory-limit --enable-bcmath --enable-shmop --enable-versioning - -enable-calendar --enable-dbx --enable-dio --enable-mcal --enable-ucd-snmp-compatibi lity" - Zend Studio 2.5 installed. - gdb backtrace: (gdb) file php Reading symbols from php...done. (gdb) set args --version (gdb) run Starting program: /usr/bin/php --version [New Thread 8192 (LWP 5565)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 8192 (LWP 5565)] 0x0815cf3e in zend_hash_find (ht=0x81eea28, arKey=0x40021b04 "_POST", nKeyLength=6, pData=0xb740) at /usr/local/_apps/php/it/php-4.3.0/Zend/zend_hash.c:882 882 if ((p->h == h) && (p->nKeyLength == nKeyLength)) { (gdb) bt #0 0x0815cf3e in zend_hash_find (ht=0x81eea28, arKey=0x40021b04 "_POST", nKeyLength=6, pData=0xb740) at /usr/local/_apps/php/it/php-4.3.0/Zend/zend_hash.c:882 #1 0x400190e3 in chk_scan_post () from /usr/lib/php4/dbg.so #2 0x400191f6 in chk_session_request_post () from /usr/lib/php4/dbg.so #3 0x4001928b in zm_activate_dbg () from /usr/lib/php4/dbg.so #4 0x0815ab21 in module_registry_request_startup (module=0x82649b0) at /usr/local/_apps/php/it/php-4.3.0/Zend/zend_API.c:1150 #5 0x0815ca11 in zend_hash_apply (ht=0x81eece0, apply_func=0x815aaf0 ) at /usr/local/_apps/php/it/php-4.3.0/Zend/zend_hash.c:688 #6 0x08158208 in zend_activate_modules () at /usr/local/_apps/php/it/php-4.3.0/Zend/zend.c:626 #7 0x0813265c in php_request_startup () at /usr/local/_apps/php/it/php-4.3.0/main/main.c:887 #8 0x08170da2 in main (argc=2, argv=0xba54) at /usr/local/_apps/php/it/php-4.3.0/sapi/cli/php_cli.c:722 #9 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 -- Edit this bug report at http://bugs.php.net/?id=21256&edit=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=18288&edit=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.dev&article=93058 [2003-01-13 17:23:41] [EMAIL PROTECTED] iliaa: 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=21624&edit=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.dev&article=93058 [2003-01-13 17:23:41] [EMAIL PROTECTED] iliaa: 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=21624&edit=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=21525&edit=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.dev&article=93058 [2003-01-13 17:23:41] [EMAIL PROTECTED] iliaa: 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=21624&edit=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:\php4>php -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:\php4>php -h [snip] -b | Bind Path for external FASTCGI Server mode [snip] C:\php4>php -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:\php>php -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=21367&edit=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.dev&article=93058 [2003-01-13 17:23:41] [EMAIL PROTECTED] iliaa: 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=21624&edit=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:\php4>php -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:\php4>php -h [snip] -b | Bind Path for external FASTCGI Server mode [snip] C:\php4>php -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:\php>php -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=21367&edit=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:\php4>php -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:\php4>php -h [snip] -b | Bind Path for external FASTCGI Server mode [snip] C:\php4>php -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:\php>php -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=21367&edit=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 [/path/to/my/app/dir/index_buggy.php] - throws error The error: [error] PHP Fatal error: main() [function.main]: 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=21565&edit=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:\php>php -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=21367&edit=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 [/path/to/my/app/dir/index_buggy.php] - throws error The error: [error] PHP Fatal error: main() [function.main]: 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=21565&edit=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=21543&edit=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: Just because of the OS. I know how cookies work. Actually I've noticed it while working on a web engine that couldn't keep user logged *only* when it ran on a Windows 2000/Apache/PHP/MySQL server so I decided to investigate. Previous Comments: [2003-01-13 17:22:42] [EMAIL PROTECTED] 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. [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; } 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=21569&edit=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.dev&article=93058 Previous Comments: [2003-01-13 17:23:41] [EMAIL PROTECTED] iliaa: 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=21624&edit=1
#21472 [Opn->Csd]: Problems with short tags and
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]
#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: 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=21624&edit=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=21569&edit=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=21624&edit=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=21340&edit=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=21615&edit=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=21340&edit=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=21624&edit=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: 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=21624&edit=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 , 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
#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=21615&edit=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=21625&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21625&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21625&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21625&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21625&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21625&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21625&r=support Expected behavior: http://bugs.php.net/fix.php?id=21625&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21625&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21625&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21625&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21625&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21625&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21625&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21625&r=gnused
#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=21624&edit=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=21340&edit=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: "; ?> 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=21569&edit=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=21621&edit=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=21621&edit=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=21624&edit=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=21603&edit=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=21624&edit=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=21624&edit=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=20497&edit=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: "; ?> [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=21569&edit=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=21624&edit=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 require valid-user After deleteing the and tags the post version also worked. The $PHP_AUTH_USER worked even though the 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 . 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=21620&edit=1
#21615 [Fbk->Ver]: PCRE segfault with (very) large string.
ID: 21615 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Feedback +Status: Verified Bug Type: Reproducible crash Operating System: GNU/linux PHP Version: 4.3.0 New Comment: 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. Previous Comments: [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=21615&edit=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=21621&edit=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: 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=21624&edit=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/ph
#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=21618&edit=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=21624&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21624&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21624&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21624&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21624&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21624&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21624&r=support Expected behavior: http://bugs.php.net/fix.php?id=21624&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21624&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21624&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21624&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21624&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21624&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21624&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21624&r=gnused
#21472 [Opn]: Problems with short tags and
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:
#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=20864&edit=1
#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: "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 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=16339&edit=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 , 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 29
#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=21623&edit=1
#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=21623&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21623&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21623&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21623&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21623&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21623&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21623&r=support Expected behavior: http://bugs.php.net/fix.php?id=21623&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21623&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21623&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21623&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21623&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21623&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21623&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21623&r=gnused
#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=21622&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21622&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21622&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21622&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21622&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21622&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21622&r=support Expected behavior: http://bugs.php.net/fix.php?id=21622&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21622&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21622&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21622&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21622&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21622&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21622&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21622&r=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 . 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=20441&edit=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=21621&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21621&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21621&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21621&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21621&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21621&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21621&r=support Expected behavior: http://bugs.php.net/fix.php?id=21621&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21621&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21621&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21621&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21621&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21621&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21621&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21621&r=gnused
#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 require valid-user After deleteing the and tags the post version also worked. The $PHP_AUTH_USER worked even though the 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 . 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=21620&edit=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 \ --without-i
#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 . 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=21620&edit=1
#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 \ --without-p
#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 copy&paste-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: '/phpinfo.php' REDIRECT_URL: '' PATH_INFO: '/phpinfo.php' PATH_TRANSLATED: '/phpinfo.php' REMOTE_USER: '' REMOTE_HOST: '' 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: '/php/phpinfo.php' REDIRECT_URL: '' PATH_INFO: '/php/phpinfo.php' PATH_TRANSLATED: '/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
#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 . 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=21620&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21620&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21620&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21620&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21620&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21620&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21620&r=support Expected behavior: http://bugs.php.net/fix.php?id=21620&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21620&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21620&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21620&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21620&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21620&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21620&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21620&r=gnused
#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_wc
#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 . 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=20441&edit=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
#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=21575&edit=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=21618&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=21618&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=21618&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=21618&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=21618&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=21618&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=21618&r=support Expected behavior: http://bugs.php.net/fix.php?id=21618&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=21618&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=21618&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=21618&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=21618&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=21618&r=dst IIS Stability: http://bugs.php.net/fix.php?id=21618&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=21618&r=gnused
#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=21615&edit=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=21615&edit=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: "; ?> [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=21569&edit=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=18644&edit=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=21546&edit=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: "; ?> [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: w2k/PHP setcookie bug test BEGIN "; ?> END 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=21569&edit=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: "; ?> [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: w2k/PHP setcookie bug test BEGIN "; ?> END 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=21569&edit=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: "; ?> 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: w2k/PHP setcookie bug test BEGIN "; ?> END 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=21569&edit=1