#22692 [Opn-Csd]: Oracle 9i
ID: 22692 Updated by: [EMAIL PROTECTED] Reported By: frusti at frusti dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request Operating System: Windows 2000 Server SP3 PHP Version: 4.3.2RC1 Previous Comments: [2004-04-19 06:20:46] cjbj at hotmail dot com Php_oci8 is the newest PHP Oracle extension. It uses Oracle's most current C API - called OCI8 because it was introduced with Oracle version 8. [2003-03-14 03:18:59] frusti at frusti dot com Hello, I am using portable SQL with ADODB and now I have performance-problemes with Oracle 9i. I have also tested it with PEAR-DB, the same problem. With Oracle 8i it goes well. Have anyone an idea when a newer Oracle-extensions come out? At moment I use php_oci8. Please give me a feedback as soon as possible. Thanks and best regards, Frast Andreas -- Edit this bug report at http://bugs.php.net/?id=22692edit=1
#19714 [Asn-WFx]: OCI8: Using default user in OCI8 functions
ID: 19714 Updated by: [EMAIL PROTECTED] Reported By: jomar at hafro dot is -Status: Assigned +Status: Wont fix Bug Type: Feature/Change Request Operating System: SunOS PHP Version: 4.2.2 Assigned To: maxim New Comment: That seems to be a useful feature, which makes PHP more secure, so I'm changing this to Won't fix. Previous Comments: [2004-04-19 06:05:10] cjbj at hotmail dot com From http://otn.oracle.com/tech/opensource/php/php_troubleshooting_faq.html#extauth Allowing externally authenticated database connections over the web would be a potential security risk for most configurations. Luckily PHP's OCI8 extension will not allow external authentication where the username is / and the password an empty string. The call in PHP's oci8.c to Oracle's OCISessionBegin() always sets the credential flag to OCI_CRED_RDBMS. To support operating system authentication the PHP source code would have to be changed to pass Oracle the OCI_CRED_EXT flag when appropriate. [2002-11-11 13:08:10] [EMAIL PROTECTED] Oracle does not seem to read user/pass if it is passed to it as the username via OCILogon. When second parameter is an empty strng OCISessionBegin() complains about the NULL password Given while if username contains '/' it is 1) unparsed by API, 2) will still leave OCISessionBegin() without a password. I will take a look at it. [2002-10-02 08:04:17] jomar at hafro dot is I´m using Apache enviroment : SetEnv ORACLE_HOME /usr/oracle SetEnv ORA_NLS33 /usr/oracle/ocommon/nls/admin/data SetEnv NLS_LANG icelandic_america I also set the tns_names and more env within root enviroment before I execute apachectl start running php as a module. I also compiled Php with Oci8. I´m having trouble with ocilogon function when I use the ocilogon(/,) (default user/nopass,server) If I logon using a valid username and password then it is ok, but when I use this method it returns an ora error : ORA-01005: null password given; logon denied I also have the ora libs and if I use ora_logon(/,) that seems to work. -- Edit this bug report at http://bugs.php.net/?id=19714edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286 Comment by: cpuidle at gmx dot de Reported By: igg10 at alu dot ua dot es Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Windows error reporting mentions: szModName: php5ts.dll szModVer: 5.0.0.0 offset:00052dc6 Can provide full memory dump from winXP error reporting on request (12m unzipped). Cheers, Andi Previous Comments: [2004-04-19 07:34:56] cpuidle at gmx dot de Same issue for me, using Apache 2.0.49, PHP5RC1 Seems to be happening in conjunction with MySQL? [2004-04-09 09:51:28] hagen at xiag dot ch The same on WindowsXP SP1, PHP 5RC1 as a module on Apache 2.0.48. [2004-04-08 20:44:45] colstrom at dxlab dot com I am running into the same problem, with the following configuration: Windows XP SP1 Apache 2.0.47 PHP 4.3.4 In an attempt to correct this, I upgraded to the following: Apache 2.0.49 PHP 4.3.5 And yet the problem persists. As for scripts, I am running a very heavily hacked phpBB-v2.0.6, and dotProject-v1.0.2. I have tried the aforementioned fix of turning register_globals ON, and still the error persists. What am I doing wrong? [2004-03-23 17:01:19] MSunbeam at gmx dot net I had that same bug. Using apache 2.0.49 php5.0.0rc1 on Win2k Using SSL Listen 443 LoadFile /server/php/ssleay32.dll LoadModule ssl_module modules/mod_ssl.so The error eccord when user was request http://localhost:443 (he called normal server on SSL-port) error.log [Tue Mar 23 23:03:46 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Tue Mar 23 23:03:49 2004] [notice] Parent: Created child process 592 [Tue Mar 23 23:03:54 2004] [notice] Child 592: Child process is running [Tue Mar 23 23:03:54 2004] [notice] Child 592: Acquired the start mutex. [Tue Mar 23 23:03:54 2004] [notice] Child 592: Starting 250 worker threads. drwtsn32 error report Anwendungsausnahme aufgetreten: Anwendung: (pid=1080) Wann: 23.03.2004 @ 23:03:45.902 Ausnahmenummer: c005 (Zugriffsverletzung) * Systeminformationen * Computername: msunbeam.net Benutzername: MSun Prozessoranzahl: 1 Prozessortyp: x86 Family 6 Model 3 Stepping 3 Windows 2000-Version: 5.0 Aktuelles Build: 2195 Service Pack: None Aktueller Typ: Uniprocessor Free Firma: Besitzer: MSun * Taskliste * 0 Idle.exe 8 System.exe 144 smss.exe 172 csrss.exe 192 winlogon.exe 220 services.exe 232 lsass.exe 388 svchost.exe 416 SPOOLSV.exe 444 blackd.exe 460 svchost.exe 488 nvsvc32.exe 508 RapApp.exe 540 regsvc.exe 572 winmgmt.exe 768 explorer.exe 876 4DMAIN.exe 896 blackice.exe 1076 Apache.exe 1004 IEXPLORE.exe 1080 Apache.exe 2100 IEXPLORE.exe 2120 drwtsn32.exe 0 _Total.exe (0040 - 00405000) .\Apache.pdb (77F8 - 77FFF000) (6EEC - 6EEE) .\libapr.pdb (77E7 - 77F33000) (77DA - 77DFA000) (77D3 - 77D9F000) (74FA - 74FB4000) (7800 - 78046000) (74F9 - 74F98000) (74F6 - 74F73000) (77E0 - 77E65000) (77F4 - 77F7C000) (7797 - 77994000) (74FC - 74FC9000) (6EE6 - 6EE89000) .\libaprutil.pdb (6EE5 - 6EE59000) .\libapriconv.pdb (6FF0 - 6FF42000) .\libhttpd.pdb (6C92 - 6C928000) (664B - 66504000) (7758 - 777C6000) (70BD - 70C35000) (7171 - 71794000) (77A4 - 77B35000) (74F4 - 74F51000) (74F8 - 74F87000) (7CA0 - 7CA22000) (77C0 - 77C5E000) (7741 - 77488000) (7740 - 7741) (6FCF - 6FCF6000) (6FCD - 6FCD6000) (6FCC - 6FCC6000) (6FCB - 6FCB6000) (6FCA - 6FCA8000) (6FC8 - 6FC86000) (6FE2 - 6FE26000) (6FEA - 6FEA6000) (6FE9 - 6FE96000) (6FC4 - 6FC48000) (6FC3 - 6FC37000) (6FC2 - 6FC27000) (6FC1 - 6FC19000) (6FC0 - 6FC06000) (6FE5 - 6FE57000) (1000 - 10027000) (0084 - 00919000) (6FD0 - 6FD1F000) (0092 - 00C74000) (779A - 77A35000) (1F7D - 1F804000) (76B0 - 76B3F000) (1F8C - 1F8D9000) (0119 - 01199000) (013A - 013A8000) (013B - 013C) (013C - 013E7000) (7754 - 77571000) (0147 - 01477000) (0148 - 0148C000) (0149 - 01564000) (0157 - 01577000) (0158 - 0158B000) (0159 - 01665000) (0167 - 01701000) (77BD - 77BDF000) (0171 - 0172F000) (0173 - 01736000) (0174 - 018C3000) (018D - 018DA000) (018E - 0191F000) (0194 - 01949000) (0195 - 01956000) (0196 - 0198A000) (0199 - 019C2000) (019D - 019DC000) (019E - 01A23000) (01A4 -
#28054 [NEW]: debug_backtrace() bug
From: misu200 at yahoo dot com Operating system: Fedora Linux kernel 2.6.4 PHP version: 5.0.0RC1 PHP Bug Type: Unknown/Other Function Bug description: debug_backtrace() bug Description: I set my own error handle function and then i try to include a non-existent file (aga.php).The problem is when i make a var_dump(debug_backtrace()) in my error handle function it shows me wrong results. Reproduce code: --- ?php function ourErrorHandler($errNo, $errStr, $errFile, $errLine) { echo PRE; var_dump(debug_backtrace()); echo /PRE; } // set the user error handler to be the above $oldErrorHandler = set_error_handler(ourErrorHandler, error_reporting()); require_once(aga.php); ? Expected result: array(2) { [0]= array(3) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [function]= string(15) ourErrorHandler } [1]= array(4) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [args]= array(1) { [0]= string(28) aga.php - this should be here } [function]= string(12) require_once } } Actual result: -- array(2) { [0]= array(3) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [function]= string(15) ourErrorHandler } [1]= array(4) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [args]= array(1) { [0]= string(28) /var/www/html/dir1/file2.php - is wrong } [function]= string(12) require_once } } -- Edit bug report at http://bugs.php.net/?id=28054edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28054r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28054r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28054r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28054r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28054r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28054r=needscript Try newer version: http://bugs.php.net/fix.php?id=28054r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28054r=support Expected behavior: http://bugs.php.net/fix.php?id=28054r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28054r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28054r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28054r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28054r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28054r=dst IIS Stability: http://bugs.php.net/fix.php?id=28054r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28054r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28054r=float
#27485 [Asn-WFx]: OCI clob column objects inconsistent in result set
ID: 27485 Updated by: [EMAIL PROTECTED] Reported By: jseverson at myersinternet dot com -Status: Assigned +Status: Wont fix Bug Type: Feature/Change Request Operating System: Redhat Linux kernel 2.4.18-3 PHP Version: 4.3.4 Assigned To: tony2001 New Comment: It would be NICE if PHP had a method of saving null into your descriptor so that you can keep your clobs consistent, since the presence of empty locators behave differently when selecting from them as compared with null clobs. there is no need in such method, NULL clobs/blobs/anything alse can be saved using SQL: INSERT INTO clobs_table (, clob_field) VALUES(,NULL); Previous Comments: [2004-03-05 18:43:16] [EMAIL PROTECTED] I would classify this as a feature request then, assinging to the the maintainer, Antony. [2004-03-05 14:36:00] jseverson at myersinternet dot com After several more hours of investigating, we have determined that our first hypothesis was not true. I am not quite sure this is still a PHP bug or not, as it seems like is more a case of a behavior of Oracle. Here is a script I've setup to demonstrate the behavior: http://test1.myersinternet.com/php_test/test_clobs.html To briefly summarize, a clob can exist in two states, both of which APPEAR to be null when viewing the clob in TOAD, TORA, or SQLPLUS. In one state, the clob is actually null, which is the case where the column is ommitted completely when doing an insert. The second case, the clob is an empty locator, which is the case when specifying the column in the insert, using the empty_clob() function, but then not performing a save on the oci descriptor. My script demonstrates both of these cases and their output. Oracle Documentation explaining this behavior: http://download-west.oracle.com/docs/cd/A87860_01/doc/appdev.817/a76940/adl02bs5.htm#117091 You can set an internal LOB -- that is, a LOB column in a table, or a LOB attribute in an object type defined by you-- to be NULL or empty: Setting an Internal LOB to NULL: A LOB set to NULL has no locator. A NULL value is stored in the row in the table, not a locator. This is the same process as for all other datatypes. Setting an Internal LOB to Empty: By contrast, an empty LOB stored in a table is a LOB of zero length that has a locator. So, if you SELECT from an empty LOB column or attribute, you get back a locator which you can use to populate the LOB with data via one of the six programmatic environments, such as OCI or PL/SQL(DBMS_LOB). It would be NICE if PHP had a method of saving null into your descriptor so that you can keep your clobs consistent, since the presence of empty locators behave differently when selecting from them as compared with null clobs. [2004-03-05 02:42:00] [EMAIL PROTECTED] The same results(i.e. allright) with 4.3.4. By the way, PHP 4.3.4 was released before all these changes you're talking about, in the early november, 2003. [2004-03-04 12:22:05] jseverson at myersinternet dot com Can you please try PHP version 4.3.4? We looked at the CVS log for the OCI changes done and it looks like a lot of work was done in December, 2003 dealing with LOBs, which wouldn't be present in 4.3.3. Thanks [2004-03-04 01:59:26] [EMAIL PROTECTED] I can't get your results with this code. In both cases I get empty arrays, if OCI_RETURN_NULLS wasn't used or array of NULLs, if it was. Tested with PHP5-cvs, PHP4-cvs, PHP4.3.3. 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/27485 -- Edit this bug report at http://bugs.php.net/?id=27485edit=1
#28053 [Opn-Bgs]: ADD 3 FUNCTIONS OF FILE
ID: 28053 Updated by: [EMAIL PROTECTED] Reported By: roberto at spadim dot com dot br -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: ALL PHP Version: Irrelevant 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: [2004-04-19 06:38:49] roberto at spadim dot com dot br Description: ? // get file size function fget_filesize( $fp){ $old_point=ftell($fp); fseek($fp,0,SEEK_END); $size=ftell($fp); fseek($fp,$old_point,SEEK_SET); return($size); } // get number of rows function fget_num_lines( $fp,$length=1024,$debug = false){ $old_point=ftell($fp);$buffer=;$pos=0; if ($debug) echo BEGIN -- NUM LINES -- ftell-$old_point, buffer_length=$length\n; // not working yet.. :_( // Linha UNIX = 10 // Linha WIN = 10,13 // Linha MAC = 13,10 fseek($fp,0,SEEK_SET); $num=0; while (true){ $num+=substr_count(fread($fp, $length),chr(10)); if (feof($fp)){ if ($debug) echo * End of File *\n; break; } } fseek($fp,$old_point,SEEK_SET); if ($debug) echo *END* Num Lines: $num\n; return($num); } // get one line function fget_line( $fp,$length=1024,$debug = 0){ $old_point=ftell($fp);$buffer=;$pos=0; if ($debug0) echo BEGIN -- GET LINE -- ftell-$old_point, buffer_length=$length\n; // Linha UNIX = 10 // Linha WIN = 10,13 // Linha MAC = 13,10 while (true){ $buffer.=fread ($fp, $length); $pos=strpos($buffer,chr(10)); if ($pos0){ if (substr($buffer,$pos-1,1)==chr(13)){ // linha WIN if ($debug1) echo * WIN Line *\n; $buffer=substr($buffer,0,$pos-1);$pos++; }elseif (substr($buffer,$pos+1,1)==chr(10)){ // linha MAC if ($debug1) echo * MAC Line *\n; $buffer=substr($buffer,0,$pos);$pos+=2; }else{ if ($debug1) echo * UNIX Line *\n; $buffer=substr($buffer,0,$pos);$pos++; } break; } if (feof($fp)){ if ($debug1) echo * End of File *\n; $pos=-1; break; } $pos=0; } if ($pos==-1) fseek($fp,0,SEEK_END); else fseek($fp,$old_point+$pos,SEEK_SET); $new_point=ftell($fp); if ($debug2) echo BUFFER length-.strlen($buffer).\n$buffer\n; if ($debug0) echo *END* ftell-.ftell($fp).\n; return($buffer); } ? -- Edit this bug report at http://bugs.php.net/?id=28053edit=1
#28052 [Opn-Bgs]: php5 undefined function aggregate()
ID: 28052 Updated by: [EMAIL PROTECTED] Reported By: daemorhedron at siliconjesters dot com -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: mdk 9.2 and win xp PHP Version: 5.0.0RC1 New Comment: PHP 5 no longer supports object aggregation, there are plenty of other mechanisms to use. Previous Comments: [2004-04-19 04:34:15] daemorhedron at siliconjesters dot com Description: Whenever trying to use aggregate() under php5b3, b4 or rc1, I just get Fatal error: Call to undefined function aggregate() in /dir/file on line 666 The above code works fine on php4 of various types. I've searched bugs.php.net, news.php.net and google to no avail and wondering how to proceed from here. Is there a required configure switch to enable aggregation in php5? Since it doesn't produce an actual error, I've not provided a gdb backtrace. ** CONFIGURE LINE ** ./configure --with-config-file-path=/usr/local/apache2/conf --with-apxs2=/usr/local/apache2/bin/apxs --enable-session --enable-pcntl --with-mm=/usr/local/lib --enable-exif --with-gd=/usr/include --with-jpeg --with-jpeg-dir=/usr/lib --with-png --with-png-dir=/usr/lib --with-freetype --with-freetype-dir=/usr/lib --with-mcrypt --with-opensl --with-pspell --with-gdbm --enable-dbx --with-mysql=/usr/local/mysql --with-sqlite --with-gmp --enable-bcmath --with-zlib --with-bz2 --enable-ftp --enable-sockets --with-xml-rpc --with-xsl --with-java --without-pear --disable-cli Tried with php5b3, b4 and rc1 on both apache 1.x and 2.x, and on both windows xp, and mandrake 9.2 (whew). I'll be happy to post any relevant information required, TIA. Reproduce code: --- class cybernetics { function augment() { echo cybernetics addedrelease the winged monkeys!\n; } } class monkeys { function monkeys() { echo monkeys loaded\n; echo loading cybernetics...\n; aggregate($this,'cybernetics'); $this-augment(); } } $monkeys=new monkeys(); Expected result: Should output : monkeys loaded loading cybernetics... cybernetics addedrelease the winged monkeys! Actual result: -- monkeys loaded loading cybernetics... Fatal error: Call to undefined function aggregate() in /dir/file on line 12 -- Edit this bug report at http://bugs.php.net/?id=28052edit=1
#28018 [Bgs]: Missing files
ID: 28018 User updated by: hendrik dot schmieder at jedox dot com Reported By: hendrik dot schmieder at jedox dot com Status: Bogus Bug Type: *General Issues Operating System: Windows PHP Version: 5CVS-2004-04-16 (dev) New Comment: Hello, is this statement about all files in group a and group b or only about the files in group b ? with best regards Hendrik Schmieder Previous Comments: [2004-04-16 15:15:25] [EMAIL PROTECTED] Those extensions don't exist anymore. [2004-04-16 03:59:57] hendrik dot schmieder at jedox dot com Description: Hello, i have downloaded the Snapshot from Apr 16, 2004 06:30 GMT. But there are some files missing in this snapshot: Group a: gds32.dll iconv.dll libmcrypt.dll php_db.dll php_hyperwave.dll php_iisfunc.dll php_interbase.dll php_printer.dll Group b: php_crack.dll php_db.dll php_domxml.dll php_pspell.dll php_w32api.dll php_yaz.dll php_zip.dll There are no php5 versions for the files in group b. with best regards Hendrik Schmieder -- Edit this bug report at http://bugs.php.net/?id=28018edit=1
#28031 [Opn]: Results of comparison differ by Windows and unix.
ID: 28031 User updated by: yiwakiri at st dot rim dot or dot jp Reported By: yiwakiri at st dot rim dot or dot jp Status: Open Bug Type: Scripting Engine problem -Operating System: Windows 98 +Operating System: Windows 2k, XP, 98 PHP Version: 4.3.6, 4.3.7-dev New Comment: Hmm, I'm confused. Windows(2k, XP 98): C:\php -r var_dump('0d1' == '0d2'); (1) bool(true) C:\php -r var_dump('00d1' == '00d2'); (2) bool(false) C:\php -r var_dump('0a1' == '0a2'); (3) bool(false) Unix like OS: % php -r var_dump('0d1' == '0d2'); (4) bool(false) % php -r var_dump('0a1' == '0a2'); (5) bool(false) Only (1) does not bring a result to expect. Previous Comments: [2004-04-19 02:24:43] yiwakiri at st dot rim dot or dot jp A snapshot is also the same behavior. C:\php -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 10:21:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies C:\php -r var_dump(('0d1' == '0d2')); bool(true) [2004-04-17 15:24:52] postings-php-bug at hans-spath dot de [Windows XP Pro SP1] D:\PHP4.3.2\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.3\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.4\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.6\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 14:18:37) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies [Linux 2.6.5] [EMAIL PROTECTED]:~/compile/php-4.3.6% sapi/cli/php -r var_dump(('0d1' == '0d2')); bool(false) [2004-04-17 10:54:04] [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 [2004-04-16 20:05:20] yiwakiri at st dot rim dot or dot jp Description: The results of comparison differ by Windows and unix. Windows: c:\ php -r var_dump(('0d1' == '0d2')); bool(true) Unix like OS: % php -r var_dump(('0d1' == '0d2')); bool(false) I expect the same behavior for both. Reproduce code: --- c:\ php -r var_dump(('0d1' == '0d2')); Expected result: bool(false) Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=28031edit=1
#19714 [WFx]: OCI8: Using default user in OCI8 functions
ID: 19714 User updated by: jomar at hafro dot is Reported By: jomar at hafro dot is Status: Wont fix Bug Type: Feature/Change Request Operating System: SunOS PHP Version: 4.2.2 Assigned To: maxim New Comment: External logon can be in many ways. It seems to me that you are defining a LAN like it is ,,external logon with the Database on a different machine than the web server but does not logon through the internet or the web. So I would like to have a feture OCI8 that says allow_external_logon or something like that. This is mainly a historical problem because many of old perl programs and the oldest php programs are using this feture and its very hard to go and change both the oracle configuration and the programs. Previous Comments: [2004-04-19 08:10:40] [EMAIL PROTECTED] That seems to be a useful feature, which makes PHP more secure, so I'm changing this to Won't fix. [2004-04-19 06:05:10] cjbj at hotmail dot com From http://otn.oracle.com/tech/opensource/php/php_troubleshooting_faq.html#extauth Allowing externally authenticated database connections over the web would be a potential security risk for most configurations. Luckily PHP's OCI8 extension will not allow external authentication where the username is / and the password an empty string. The call in PHP's oci8.c to Oracle's OCISessionBegin() always sets the credential flag to OCI_CRED_RDBMS. To support operating system authentication the PHP source code would have to be changed to pass Oracle the OCI_CRED_EXT flag when appropriate. [2002-11-11 13:08:10] [EMAIL PROTECTED] Oracle does not seem to read user/pass if it is passed to it as the username via OCILogon. When second parameter is an empty strng OCISessionBegin() complains about the NULL password Given while if username contains '/' it is 1) unparsed by API, 2) will still leave OCISessionBegin() without a password. I will take a look at it. [2002-10-02 08:04:17] jomar at hafro dot is I´m using Apache enviroment : SetEnv ORACLE_HOME /usr/oracle SetEnv ORA_NLS33 /usr/oracle/ocommon/nls/admin/data SetEnv NLS_LANG icelandic_america I also set the tns_names and more env within root enviroment before I execute apachectl start running php as a module. I also compiled Php with Oci8. I´m having trouble with ocilogon function when I use the ocilogon(/,) (default user/nopass,server) If I logon using a valid username and password then it is ok, but when I use this method it returns an ora error : ORA-01005: null password given; logon denied I also have the ora libs and if I use ora_logon(/,) that seems to work. -- Edit this bug report at http://bugs.php.net/?id=19714edit=1
#27978 [Bgs]: PHP Causing Apache to Abort?
ID: 27978 User updated by: megan dot boardman at rweinnogy dot com Reported By: megan dot boardman at rweinnogy dot com Status: Bogus Bug Type: Reproducible crash Operating System: UNIX 5.1 ALPHA PHP Version: 4.3.5 New Comment: I've managed to trace this to a problem with the Oracle functions. i.e. I get no aborts in the Apache log until I try using OCILogon() to actually try to connect to the database. Could this be related to needing pthread linked in Apache (www.php.net/manual/en/ref.oc18.php)? I recognise that supporting legacy systems is difficult, but the reality is that these systems do still exist and upgrading is not always an option. Would be helpful if you could at least list what you are prepared to test against, and what systems you claim compatibility with. For what it's worth example code is given below (need to fill in relevant database, email, and db query). Behaviour I see is: - With all database related calls commented out, I get one email, the cookie gets set and I always get the data printed to the web browser). - With database calls in, I sometimes get multiple emails, muliple database submissions and may or may not get the cookie / HTML data back at the browerser end. When this poor behaviour occurs it coincides with an Abort(6) error in the Apache log. ?php function callFunction($doc, $a) { $Database = ; // Connect to database and get unique key - simulate here by assigning key $conn = OCILogon(, , $Database); $returnArray = array(); $cursor = OCIParse($conn, select user_reports_seq.NEXTVAL from dual); $ret = OCIExecute($cursor, OCI_DEFAULT); if ($ret) { OCIFetchStatement($cursor, $returnArray); OCICommit($conn); } else { OCIRollback($conn); } OCIFreeStatement($cursor); OCILogOff($conn); $row = $returnArray[NEXTVAL]; $keys = array_keys($row); $Key = $row[array_pop($keys)]; if ($ret) { // Send notification message $message = Fault report . $Key . requires your attention.; mail([EMAIL PROTECTED], Fault Report - . $Key, $message, From: [EMAIL PROTECTED]); // Present message to user $doc[$a++] = pSubmission Successful!/p; $doc[$a++] = pThe system reference number for your report is b$Key/b./p; SetCookie(Submitted, $Key); } else { $doc[$a++] = pSubmission failed/p; } } $doc = array(); $a = 0; $doc[$a++] = htmlheadtitleTest PHP Page/title/headbody; callFunction($doc, $a); $doc[$a++]=/body/html; foreach($doc as $data) { print $data; } ? Previous Comments: [2004-04-13 12:30:07] [EMAIL PROTECTED] This report is as useful as not reporting anything. Please come up with SOLID reproducing script and how to reproduce. (and note: We don't have any access to any alpha machines..aren't those some relic anyway? Get new machine? :) [2004-04-13 10:01:35] megan dot boardman at rweinnogy dot com Description: Since upgrading to PHP 4 have been experiencing problems with Apache 1.3.26 periodically appearing to crash. This has gradually gotten worse as we have worked our way up through the 4.x generation of PHP. Timeline goes as follows (based on messages in Apache error_log): - PHP 4.0.4pl1 gave occasional child exit signal Segmentation Fault (11). - PHP 4.1.2 gave no errors. - PHP 4.3.3, 4.3.4 and 4.3.5 gave frequent child X exit signal Abort (6) errors This PHP script is being used to submit requests to a database. This aborting behaviour appears to be causing the sending web browser to lose contact with Apache, and hence send the form post multiple times. The PHP script always appears to get as far as sending the submission to the database, but then falls over before sending the response back to the web server. Result - multiple duplicate database submissions, occasional Page Not Found 505 errors in the web browser. Working with an Oracle 8 database and mod_fastcgi 2.2.12 Reproduce code: --- Cannot easily reproduce code, however general form is as follows: 1) Create object that contains contents of HTML page being constructed 2) Pass object by reference to function 3) Function builds database submission (based on variables that have been POSTed by a previous web form submision) and then sends an email, sets a cookie and builds HTML based on result from database. 4) Function ends and web page printed to screen - DB Submission always happens - Email always happens - Apache appears to fall over before the cookie gets set and before the HTML gets displayed NOTE: - Seems order invarient. - Methodology applied for earlier webforms posts, and works without multiple submissions. Expected result: - DB Submission - Email to be sent - Cookie set in browser - Resultant
#28055 [NEW]: pfsockopen hangs for 30 seconds if connection is established
From: chris at deviantart dot com Operating system: Linux 2.6.5 PHP version: 4.3.6 PHP Bug Type: Sockets related Bug description: pfsockopen hangs for 30 seconds if connection is established Description: If a connection has already been established, pfsockopen will hang for 30 seconds before returning the correct persistent socket. strace reports the following: ... connect(3, {sa_family=AF_INET, sin_port=htons(11211), sin_addr=inet_addr(10.0.0.16)}, 16) = -1 EINPROGRESS (Operation now in progress) select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0}) getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 fcntl64(3, F_SETFL, O_RDWR) = 0 select(4, [3], NULL, NULL, {60, 0} *hang* The following patch seems to fix it: http://cvs.php.net/diff.php/php-src/main/network.c?sa=1r1=1.83.2.21r2=1.83.2.20ty=u Maybe this needs backporting? http://cvs.php.net/cvs.php/php-src/main/streams/streams.c?sa=1#rev1.49 Reproduce code: --- ? $fp = pfsockopen(rembrandt, 11211); $fp = pfsockopen(rembrandt, 11211); ? -- Edit bug report at http://bugs.php.net/?id=28055edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28055r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28055r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28055r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28055r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28055r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28055r=needscript Try newer version: http://bugs.php.net/fix.php?id=28055r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28055r=support Expected behavior: http://bugs.php.net/fix.php?id=28055r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28055r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28055r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28055r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28055r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28055r=dst IIS Stability: http://bugs.php.net/fix.php?id=28055r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28055r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28055r=float
#25701 [Com]: Calling flush from within an output buffer prevents headers from being sent
ID: 25701 Comment by: webmaster at line-of-fire dot de Reported By: scottmacvicar at ntlworld dot com Status: Closed Bug Type: Apache2 related Operating System: * PHP Version: 4CVS Assigned To: iliaa New Comment: Hi, I have a problem with the Gallery... If i want to upload a picture, i became a error: Warning: is_dir() [function.is-dir]: Stat failed for modules/coppermine/albums/userpics/10002 (errno=13 - Permission denied) in /home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php on line 236 Warning: mkdir(modules/coppermine/albums/userpics/10002) [function.mkdir]: Permission denied in /home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php on line 237 Warning: is_dir() [function.is-dir]: Stat failed for modules/coppermine/albums/userpics/10002 (errno=13 - Permission denied) in /home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php on line 238 ... AND Verzeichnis modules/coppermine/albums/userpics/10002 konnte nicht angelegt werden! Datei: /home/www/htdocs/nstudios.de/php/html/modules/coppermine/db_input.php - Zeile: 238 I hope someone coud help me. LoF Previous Comments: [2004-01-05 03:15:35] brion at pobox dot com While this seems to be fixed when using --with-apxs2, the bug still occurs in 4.3.4 using --with-apxs2filter. headers_sent() returns false, no warning or error message occurs when trying to use header(), just the headers silently vanish. [2003-10-01 23:22:07] [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-10-01 10:30:57] scottmacvicar at ntlworld dot com ?php ob_start(); echo 'test'; flush(); $newtext = ob_get_clean(); if (!headers_sent()) { echo 'in herebr /'; } echo $newtext; ? Based on what you've said above then you shouldn't see 'in here' within Apache 2. [2003-09-30 19:22:16] scottmacvicar at ntlworld dot com Shouldn't headers_sent() return true then? [2003-09-30 18:47:05] [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 Unlike Apache 1, when Apache 2 recieves a directive to flush it does so right away sending any pending headers in the process. Since the headers text were already sent it cannot send the header indicating the data that follows in gziped. Due to the missing header you get a whole bunch of binary data. 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/25701 -- Edit this bug report at http://bugs.php.net/?id=25701edit=1
#27110 [Com]: php_value|flag / php_admin_* settings leak from .htaccess files
ID: 27110 Comment by: j dot svoboda at phoenix dot cz Reported By: walter at brunner dot at Status: No Feedback Bug Type: Apache2 related Operating System: Linux (Gentoo) PHP Version: 4CVS-2004-02-01 Assigned To: iliaa New Comment: I am sorry, I stripped part of configure command. The full command is: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql=/usr/local/mysql' '--with-imap=/usr/local/src/imap' Previous Comments: [2004-04-19 13:08:13] j dot svoboda at phoenix dot cz I can 100% reproduce this error. How to reproduce (my case): We use the supplied Apache configuration (with several insignificant changes, listed at the bottom) and these local settings (included from separate file httpd-test-local.conf): - StartServers 1 MaxClients 1 DocumentRoot /www AddType application/x-httpd-php .php Directory / Order allow,deny Allow from all php_value include_path .:/usr/local/lib/php:/www/lib /Directory # Development Directory /www/epv php_value include_path .:/usr/local/lib/php:/www/libv:/www/lib /Directory # Authentication LocationMatch ^/ep php_value auto_prepend_file a.php /LocationMatch - In /www, we have four directories, ep, epv, lib, libv. (ep* is for PHP scripts, lib* is for PHP libraries; versions with 'v' stand for 'deVelopment'). In ep*, we have simple script i.php containing the command ? echo ini_get(include_path); ? In lib, I have the empty file a.php. 1. I restart apache 2. I open the file /ep/i.php in my browser, and it prints .:/usr/local/lib/php:/www/lib 3. I open the file /epv/i.php in my browser, and it prints .:/usr/local/lib/php:/www/lib where it should print .:/usr/local/lib/php:/www/libv:/www/lib It seems that the problem manifests only in combination with auto_prepend_file. - Insignificant changes in apache configuration: diff httpd-std.conf httpd-test.conf 81c81 PidFile logs/httpd.pid PidFile logs/httpd-8080.pid 219c219 Listen 80 Listen 8080 231a232 LoadModule php4_modulemodules/libphp4.so 1049a1051 Include /usr/local/apache2/conf/httpd-test-local.conf - System settings: System: FreeBSD www.p-i-n.cz 4.2-RELEASE FreeBSD 4.2-RELEASE #0: Wed Jan i386 Configure Command: './configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql SERVER_SOFTWARE: Apache/2.0.49 (Unix) PHP/4.3.5 - [2004-03-24 17:24:24] [EMAIL PROTECTED] It's fixed for me in 4.3.5RC3 Try the latest 4.3.5 RC, or CVS snapshot [2004-03-24 11:19:57] bfriday at lasierra dot edu Installed php-4.3.4 and this bug continues to be a problem moved to the latest RC2 when it came out last week and the bug while listed in other reports as fixed continues to be a problem. I've got a virtual host situation in which the following is occuring: 1) primary hostname is fine it is not using php so there is no error 2) this virtual host is fine but is using php and it has some additional information which is set over and above our default settings in the php.ini via .htaccess files. 3) this virtual host is using just html so is fine as well 4) this virtual host would like to use php but cannot as php demands to look for setting which is not defined in the global .htaccess but rather in the .htaccess of virtual host 2. PHP consistently errors out and is unusable on this host as no program gets past the php_value auto_prepend_file line which is located in virtual host 2's .htaccess file. Please let me know if you have need of further information I can provide the domain names to a developer to do a look see but would need to do that privately. I'd really appreciate it if this is fixed as it makes using php in a virtual host setting impossible. [2004-02-16 01:19:35] [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. [2004-02-11 12:47:16] [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 Unable to replicate with latest CVS. 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/27110 -- Edit this bug report at http://bugs.php.net/?id=27110edit=1
#28056 [NEW]: [patch] ./buildconf doesn't work under Cygwin (Fixes #27140)
From: jari dot aalto at poboxes dot com Operating system: Win32 - W2ksp4 PHP version: 4CVS-2004-04-19 (stable) PHP Bug Type: Compile Failure Bug description: [patch] ./buildconf doesn't work under Cygwin (Fixes #27140) Description: cygwin included libtool in places which cannot be derived using the current logic used in ./buildconf scripts. Attached is a patch to make the ./buildconf succeed. - Added DEBUG to make probing errors easier. - Added tests for Cygwin. - @'s were removed from Makefile to see what's really going. Using @ make it hard to report good errors. I don't think they should be overly used as is the case in current PHP make files. Jari Actual result: -- cvs diff: warning: skipping invalid entry in password file at line 233 Index: buildcheck.sh === RCS file: /repository/php-src/build/buildcheck.sh,v retrieving revision 1.21.2.6 diff -u -IId: -b -w -u -r1.21.2.6 buildcheck.sh --- buildcheck.sh 28 Sep 2003 13:37:59 - 1.21.2.6 +++ buildcheck.sh 19 Apr 2004 11:23:36 - @@ -21,6 +21,10 @@ echo buildconf: checking installation... +if test $DEBUG ; then +set -x +fi + stamp=$1 # autoconf 2.13 or newer @@ -80,6 +84,11 @@ ltpath=`echo $libtoolize | sed -e 's#/[^/]*/[^/]*$##'` ltfile=$ltpath/share/aclocal/libtool.m4 + +if [ $CYGWIN ]; then +ltfile=/usr/autotool/stable/share/aclocal/libtool.m4 +fi + if test -r $ltfile; then : else cvs diff: warning: skipping invalid entry in password file at line 233 Index: buildconf === RCS file: /repository/php-src/buildconf,v retrieving revision 1.57.4.2 diff -u -IId: -b -w -u -r1.57.4.2 buildconf --- buildconf 25 Jun 2003 13:00:46 - 1.57.4.2 +++ buildconf 19 Apr 2004 11:24:41 - @@ -1,6 +1,10 @@ #!/bin/sh # $Id: buildconf,v 1.57.4.2 2003/06/25 13:00:46 sas Exp $ +if test $DEBUG ; then +set -x +fi + eval `grep '^EXTRA_VERSION=' configure.in` case $EXTRA_VERSION in *-dev) @@ -62,3 +66,8 @@ rm -f generated_lists ${MAKE:-make} -s -f build/build.mk AMFLAGS=$automake_flags ZENDDIR=$ZENDDIR\ + +if test $DEBUG; then +# Show how make was called to pinpoint problems +${MAKE:-make} -n -s -f build/build.mk AMFLAGS=$automake_flags ZENDDIR=$\ ZENDDIR +fi Index: build2.mk === RCS file: /repository/php-src/build/build2.mk,v retrieving revision 1.27.4.1 diff -u -IId: -b -w -u -r1.27.4.1 build2.mk --- build2.mk 27 Jun 2003 00:19:26 - 1.27.4.1 +++ build2.mk 19 Apr 2004 11:25:42 - @@ -46,19 +46,25 @@ # correctly otherwise (timestamps are not updated) @echo rebuilding $@ @rm -f $@ - @autoheader 21 | $(SUPPRESS_WARNINGS) + autoheader 21 | $(SUPPRESS_WARNINGS) $(TOUCH_FILES): touch $(TOUCH_FILES) aclocal.m4: configure.in acinclude.m4 - @echo rebuilding $@ - @libtoolize=`./build/shtool path glibtoolize libtoolize`; \ + echo rebuilding $@ + libtoolize=`./build/shtool path glibtoolize libtoolize`; \ $$libtoolize --copy --automake; \ ltpath=`dirname $$libtoolize`; \ - ltfile=`cd $$ltpath/../share/aclocal; pwd`/libtool.m4; \ + if [ $(CYGWIN) ]; then \ + cdpath=/usr/share; \ + else \ + cdpath=`cd $$ltpath/../share/aclocal; pwd`; \ + fi; \ + ltfile=$$cdpath/libtool.m4; \ + echo $$cdpath; \ cat acinclude.m4 $$ltfile $@ configure: aclocal.m4 configure.in $(config_m4_files) @echo rebuilding $@ - @autoconf 21 | $(SUPPRESS_WARNINGS) + autoconf 21 | $(SUPPRESS_WARNINGS) -- Edit bug report at http://bugs.php.net/?id=28056edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28056r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28056r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28056r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28056r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28056r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28056r=needscript Try newer version: http://bugs.php.net/fix.php?id=28056r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28056r=support Expected behavior: http://bugs.php.net/fix.php?id=28056r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28056r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28056r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28056r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28056r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28056r=dst IIS Stability: http://bugs.php.net/fix.php?id=28056r=isapi Install GNU Sed:
#27140 [Bgs]: buildconf does not find system libtool 1.4.3
ID: 27140 User updated by: jari dot aalto at poboxes dot com Reported By: jari dot aalto at poboxes dot com Status: Bogus Bug Type: Compile Failure Operating System: W2k/Cygwin PHP Version: 5CVS-2004-02-04 (dev) New Comment: I've investigated this further. There is problem in checking Cygwin in general. See my bug report #28056 which includes patches. Previous Comments: [2004-02-14 08:25:56] jari dot aalto at poboxes dot com The CVS is faster than getting snapshots (bandwidth). Regarding the libtool, no I do not have it in /usr/local, but I do have /usr/local/bin/libtoolize which is checked by build/shtool path glibtoolize libtoolize buildconf should trust PATH because otherwise the checks are done behind user's environment settings by simply trusting libtool --version I removed /usr/local/libtoolize and now it says: [EMAIL PROTECTED]:/usr/src/cvs-source/php-src# ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.4.3 (ok) buildconf: /share/aclocal/libtool.m4 does not exist. Please reinstall libtool. make: *** [buildmk.stamp] Error 1 I have it installed in /usr/autotool/stable/share/aclocal Perhaps this is similar check that does not trust the libtoolize is installed? [2004-02-04 19:33:29] [EMAIL PROTECTED] Use the snapshots. You don't need to run buildconf for those. [2004-02-04 14:58:59] [EMAIL PROTECTED] Presumably you have libtool 1.4.2 in /usr/local/bin which should be prefered over /usr/bin/libtool. If that's the case then it is expected behavior since that's the sense of having /usr/local/ [2004-02-04 04:55:28] jari dot aalto at poboxes dot com Description: I checked out the CVS version and ensured that I have right libtool installed. However, the ./buildconf somehow finds the previous installation of libtool. My question is, shouldn't it rely on the system installed libtool instead? How exactly it tests the version of current libtool, maybe that would help to debug this problem. This is W2k/cygwin www.cygwin.com [EMAIL PROTECTED]:/usr/src/cvs-source/php-src# which libtool /bin/libtool [EMAIL PROTECTED]:/usr/src/cvs-source/php-src# libtool --version ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54) [EMAIL PROTECTED]:/usr/src/cvs-source/php-src# ./buildconf using default Zend directory buildconf: checking installation... buildconf: autoconf version 2.13 (ok) buildconf: libtool version 1.4.2 found. You need libtool version 1.4.3 or newer installed to build PHP from CVS. make: *** [buildmk.stamp] Error 1 [EMAIL PROTECTED]:/usr/src/cvs-source/php-src# libtool -- -- Edit this bug report at http://bugs.php.net/?id=27140edit=1
#28057 [NEW]: nl_langinfo returns wrong data for de_DE
From: bublavas at ecetra dot com Operating system: 2.4.21-9.EL GNU/Linux PHP version: 4.3.6 PHP Bug Type: Strings related Bug description: nl_langinfo returns wrong data for de_DE Description: nl_langinfo returns wrong values for THOUSEP and RADIXCHAR after setting the locale to 'de_DE'. Using localeconv() returns the same wrong values. An equivalent C program returns correct results. PHP 4.3.4 returns the same results as 4.3.6; executing the script from the command line vs. using HTTP (Apache 2.0.48) makes no difference as well. Reproduce code: --- if ( setlocale(LC_ALL, 'de_DE') ) { echo thousands separator: , nl_langinfo(THOUSEP), \n; echo decimal point: , nl_langinfo(RADIXCHAR), \n; } else { echo cannot set locale to de_DE, \n; } Expected result: thousands separator: . decimal point: , Actual result: -- thousands separator: decimal point: . -- Edit bug report at http://bugs.php.net/?id=28057edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28057r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28057r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28057r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28057r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28057r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28057r=needscript Try newer version: http://bugs.php.net/fix.php?id=28057r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28057r=support Expected behavior: http://bugs.php.net/fix.php?id=28057r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28057r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28057r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28057r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28057r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28057r=dst IIS Stability: http://bugs.php.net/fix.php?id=28057r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28057r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28057r=float
#28049 [Opn]: php_interbase.dll is missing
ID: 28049 User updated by: rene dot ladinger at ladinger dot com Reported By: rene dot ladinger at ladinger dot com Status: Open Bug Type: InterBase related Operating System: Windows 2000 PHP Version: 5CVS-2004-04-18 (dev) New Comment: From Snapshot.log: . . . Copying php_ifx.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext Copying php_interbase.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext Warning: copy(Release_TS\php_interbase.dll): failed to open stream: No such file or directory in c:\php4build\snap\win32\build\mkdist.php on line 115 Copying php_ldap.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext Copying php_mbstring.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext . . . Previous Comments: [2004-04-18 17:23:35] rene dot ladinger at ladinger dot com Description: The php_interbase.dll is missing in the W32 snaps! -- Edit this bug report at http://bugs.php.net/?id=28049edit=1
#28055 [Opn-Asn]: pfsockopen hangs for 30 seconds if connection is established
ID: 28055 Updated by: [EMAIL PROTECTED] Reported By: chris at deviantart dot com -Status: Open +Status: Assigned Bug Type: Sockets related Operating System: Linux 2.6.5 PHP Version: 4.3.6 -Assigned To: +Assigned To: wez New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Yep, it did - thanks for bringing this up. Previous Comments: [2004-04-19 13:06:20] chris at deviantart dot com Description: If a connection has already been established, pfsockopen will hang for 30 seconds before returning the correct persistent socket. strace reports the following: ... connect(3, {sa_family=AF_INET, sin_port=htons(11211), sin_addr=inet_addr(10.0.0.16)}, 16) = -1 EINPROGRESS (Operation now in progress) select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0}) getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 fcntl64(3, F_SETFL, O_RDWR) = 0 select(4, [3], NULL, NULL, {60, 0} *hang* The following patch seems to fix it: http://cvs.php.net/diff.php/php-src/main/network.c?sa=1r1=1.83.2.21r2=1.83.2.20ty=u Maybe this needs backporting? http://cvs.php.net/cvs.php/php-src/main/streams/streams.c?sa=1#rev1.49 Reproduce code: --- ? $fp = pfsockopen(rembrandt, 11211); $fp = pfsockopen(rembrandt, 11211); ? -- Edit this bug report at http://bugs.php.net/?id=28055edit=1
#28058 [NEW]: __autoload called for every class declaration
From: alex_boyer at hotmail dot com Operating system: Windows 2000 Pro PHP version: 5.0.0RC1 PHP Bug Type: Zend Engine 2 problem Bug description: __autoload called for every class declaration Description: __autoload is called for every class declaration that extends a parent class, even if the parent declaration file is included. Reproduce code: --- index.php: require_once b.php; function __autoload($theclass){ echo Auto load\n; require_once($theclass..php); } $obj = new b(); $obj-hello(); b.php: require_once a.php; class b extends a{ function hello() { echo B;} } a.php: class a{ function hello() {echo A;} } Expected result: B Actual result: -- Auto load B -- Edit bug report at http://bugs.php.net/?id=28058edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28058r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28058r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28058r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28058r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28058r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28058r=needscript Try newer version: http://bugs.php.net/fix.php?id=28058r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28058r=support Expected behavior: http://bugs.php.net/fix.php?id=28058r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28058r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28058r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28058r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28058r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28058r=dst IIS Stability: http://bugs.php.net/fix.php?id=28058r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28058r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28058r=float
#28042 [Csd]: greek letters in html to entity mapping not correct
ID: 28042 User updated by: ben at csgb dot de -Summary: greek letters in html to entitity mapping not correct Reported By: ben at csgb dot de Status: Closed Bug Type:Strings related PHP Version: all New Comment: fixing summary line for better search results (entitity - entity) Previous Comments: [2004-04-18 01:10:02] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2004-04-18 01:09:52] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. [2004-04-17 21:52:26] ben at csgb dot de retry to post code: ?php echo htmlentities(? ?,ENT_COMPAT,UTF-8); ? here is the diff of php-4.3.4/ext/standard/html.c: 139,140c139,140 Iota, Kappa, Lambda, Mu, Nu, X1, Omicron, P1, Rho, NULL, Sigma, Tau, Upsilon, Ph1, Ch1, Ps1, Omega, --- Iota, Kappa, Lambda, Mu, Nu, Xi, Omicron, Pi, Rho, NULL, Sigma, Tau, Upsilon, Phi, Chi, Psi, Omega, 144,145c144,145 iota, kappa, lambda, mu, nu, x1, omicron, p1, rho, sigmaf, sigma, tau, upsilon, ph1, ch1, ps1, omega, --- iota, kappa, lambda, mu, nu, xi, omicron, pi, rho, sigmaf, sigma, tau, upsilon, phi, chi, psi, omega, It's the same change in php-5 (with different line numbers) [2004-04-17 21:38:13] ben at csgb dot de Description: the html entity mappings used by htmlentities() have wrong entries in ent_uni_greek[]. They say P1 and p1 instead of Pi and pi. The same goes with Xi, Phi, Chi, Psi and their lowercase characters. Reproduce code: --- ?php echo htmlentities(? ?,ENT_COMPAT,UTF-8); ? Expected result: Xi;Pi;Phi;Chi;Psi; xi;pi;phi;chi;psi; Actual result: -- X1;P1;Ph1;Ch1;Ps1; x1;p1;ph1;ch1;ps1; -- Edit this bug report at http://bugs.php.net/?id=28042edit=1
#28055 [Asn-Csd]: pfsockopen hangs for 30 seconds if connection is established
ID: 28055 Updated by: [EMAIL PROTECTED] Reported By: chris at deviantart dot com -Status: Assigned +Status: Closed Bug Type: Sockets related Operating System: Linux 2.6.5 PHP Version: 4.3.6 Assigned To: wez Previous Comments: [2004-04-19 14:44:33] [EMAIL PROTECTED] This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Yep, it did - thanks for bringing this up. [2004-04-19 13:06:20] chris at deviantart dot com Description: If a connection has already been established, pfsockopen will hang for 30 seconds before returning the correct persistent socket. strace reports the following: ... connect(3, {sa_family=AF_INET, sin_port=htons(11211), sin_addr=inet_addr(10.0.0.16)}, 16) = -1 EINPROGRESS (Operation now in progress) select(4, [3], [3], [3], {60, 0}) = 1 (out [3], left {60, 0}) getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0 fcntl64(3, F_SETFL, O_RDWR) = 0 select(4, [3], NULL, NULL, {60, 0} *hang* The following patch seems to fix it: http://cvs.php.net/diff.php/php-src/main/network.c?sa=1r1=1.83.2.21r2=1.83.2.20ty=u Maybe this needs backporting? http://cvs.php.net/cvs.php/php-src/main/streams/streams.c?sa=1#rev1.49 Reproduce code: --- ? $fp = pfsockopen(rembrandt, 11211); $fp = pfsockopen(rembrandt, 11211); ? -- Edit this bug report at http://bugs.php.net/?id=28055edit=1
#28057 [Opn-Ana]: nl_langinfo returns wrong data for de_DE
ID: 28057 Updated by: [EMAIL PROTECTED] Reported By: bublavas at ecetra dot com -Status: Open +Status: Analyzed Bug Type: Strings related Operating System: 2.4.21-9.EL GNU/Linux PHP Version: 4.3.6 New Comment: No, the problem is in setlocale(). When you set LC_NUMERIC or LC_ALL and the decimal point is not '.', then LC_NUMERIC is set back to C again. This hack is required for serialize() when handling floating point numbers. Previous Comments: [2004-04-19 14:28:22] bublavas at ecetra dot com Description: nl_langinfo returns wrong values for THOUSEP and RADIXCHAR after setting the locale to 'de_DE'. Using localeconv() returns the same wrong values. An equivalent C program returns correct results. PHP 4.3.4 returns the same results as 4.3.6; executing the script from the command line vs. using HTTP (Apache 2.0.48) makes no difference as well. Reproduce code: --- if ( setlocale(LC_ALL, 'de_DE') ) { echo thousands separator: , nl_langinfo(THOUSEP), \n; echo decimal point: , nl_langinfo(RADIXCHAR), \n; } else { echo cannot set locale to de_DE, \n; } Expected result: thousands separator: . decimal point: , Actual result: -- thousands separator: decimal point: . -- Edit this bug report at http://bugs.php.net/?id=28057edit=1
#28038 [Bgs-Opn]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038 Updated by: [EMAIL PROTECTED] Reported By: jordi at jcanals dot net -Status: Bogus +Status: Open Bug Type: Mail related Operating System: Windows PHP Version: 4.3.6 New Comment: It is a bug, since PHP is sending those headers by parsing the email. Previous Comments: [2004-04-18 01:00:13] [EMAIL PROTECTED] Mailing with PHP on Windows doesn't support this. Not a bug. [2004-04-17 19:14:01] jordi at jcanals dot net Description: In windows, and using an SMTP server, when you try to send a mail using the mail function the SMTP transaction will fail if you include recipient names. When including any recipient header in the following format (wich follows the RFC 2822), the mail function does not handle it properly: To: User Name [EMAIL PROTECTED] Cc: Other User [EMAIL PROTECTED] Bcc: Third User [EMAIL PROTECTED] Loking at the SMTP transaction, the PHP mail layer sends this RCPT commands wich do not folow the SMTP standard stated on RFC 2821: RCPT TO:User Name [EMAIL PROTECTED] RCPT TO:Other User [EMAIL PROTECTED] RCPT TO:Third User [EMAIL PROTECTED] Fails always with this environments: Tested on Windows XP, Apache 2.0.49, PHP 4.3.6 (Also in 4.3.4) Tested also on Windows 2000, IIS, PHP 4.3.6 Tested Using SMTP servers on Linux with Exim and Sendmail. Tested also using the default Windows 2000 SMTP server. Reproduce code: --- // SAMPLE 1: $to_recipient = User Name [EMAIL PROTECTED]; $header = Cc: Other User [EMAIL PROTECTED]\r\n; $header .= Bcc: Third User [EMAIL PROTECTED]\r\n; mail($to_recipient, $subject, $body, $header); // FAILS with SMTP errors for all three recipients. SAMPLE 2: $to_recipient = [EMAIL PROTECTED]; $header = To: User Name [EMAIL PROTECTED]\r\n; $header .= Cc: Other User [EMAIL PROTECTED]\r\n; $header .= Bcc: Third User [EMAIL PROTECTED]\r\n; mail($to_recipient, $subject, $body, $header); FAILS on with SMTP error on the three recipients passed on the $header field. Expected result: Expected that the mail layer exctracts only the mail address from recipients to send the SMTP commands: As seen on the RFC's 2821 and 2822, when sending a mail with the recipient headers formed like above, it is expected the mail layer to extract ONLY the email address to send the RCPT commands, and pass the headers without any change in the DATA command during the SMTP transaction. Example of the correct SMTP transaction for the above headers: RCPT TO:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA To: User Name [EMAIL PROTECTED] Cc: Other User [EMAIL PROTECTED] Bcc: Third User [EMAIL PROTECTED] Actual result: -- You get that error for all recipients with the recipient name: Warning: mail(): SMTP server response: 501 SomeOne Name [EMAIL PROTECTED]: @ or . expected after SomeOne in mail.class.php on line 333 This error is produced when the mail layer is sending a wrong formed RCPT TO: command in the SMTP transaction. -- Edit this bug report at http://bugs.php.net/?id=28038edit=1
#27801 [NoF-Fbk]: networking issue..
ID: 27801 Updated by: [EMAIL PROTECTED] Reported By: ury at iptel dot by -Status: No Feedback +Status: Feedback Bug Type: Sockets related Operating System: linux PHP Version: 4.3.5 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 See Bug #28055, and please try the next snapshot. Previous Comments: [2004-04-18 12:53:58] jimmy at quadrahosting dot com dot au To those who are experiencing this problem (on 4.3.5 and up) - do you check the result of fgets using feof? If this is the case, the feof is the cause of the delay because since 4.3.5 PHP will only return true on feof when the socket connection is closed or after the socket timeout period has elapsed. See www.php.net/feof A quick fix is to call stream_set_timeout($sockethandle, 2) or a similarly low timeout. Can someone confirm that this works for you? [2004-04-12 07:31:10] [EMAIL PROTECTED] None of you have bothered to do some bug finding of your own; we don't have time to install large applications and debug them. Please give me the shortest script that reproduces the bug, as I have asked, otherwise this report will sit and rot. [2004-04-12 05:06:26] tibyke at tibyke dot hu the problem still exists, even with latest snapshot. i wonder what else we could/should do besides reporting the problem, and pointing the allegedly faulty piece of code, and. get ilohamail at www.ilohamail.org (0812), install it alongside a php 4.3.4, and you'll see what we're talking about. if you dont want to then write an email, I'll show you the case on my box (as [EMAIL PROTECTED] didnt even bother to reply to my mail) regards, tibyke [2004-04-11 12:14:20] [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. [2004-04-06 08:01:27] admin at itccanarias dot org Same problem with PHP 4.3.5. With previous versions of PHP IlohaMail works fine. This is the web server error: PHP Warning: fsockopen(): php_network_getaddresses: gethostbyname failed in /export/home/www/htdocs/IlohaMail/include/pop3.inc on line 233 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/27801 -- Edit this bug report at http://bugs.php.net/?id=27801edit=1
#28031 [Com]: Results of comparison differ by Windows and unix.
ID: 28031 Comment by: postings-php-bug at hans-spath dot de Reported By: yiwakiri at st dot rim dot or dot jp Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2k, XP, 98 PHP Version: 4.3.6, 4.3.7-dev New Comment: D:\PHPver Microsoft Windows XP [Version 5.1.2600] D:\PHPlastest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 19 2004 14:16:52) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies D:\PHP5.0.0RC1\php -v PHP 5.0.0RC1 (cli) (built: Mar 18 2004 18:20:03) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.0RC1, Copyright (c) 1998-2004 Zend Technologies D:\PHPlastest\php-cli test\string_comparison.php 0x1 0x2 ( '0x1' == '0x2' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0d2 ( '0d1' == '0d2' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php 0d1x 0d2x ( '0d1x' == '0d2x' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0dx1 ( '0d1' == '0dx1' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0xd1 ( '0d1' == '0xd1' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0xd2 ( '0d1' == '0xd2' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php d1 xd2 ( 'd1' == 'xd2' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php d1 xd1 ( 'd1' == 'xd1' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0e9 0xe4 ( '0e9' == '0xe4' ) = bool(true) D:\PHP5.0.0RC1\php test\string_comparison.php 0e9 0xe4 ( '0e9' == '0xe4' ) = bool(true) I wonder why this hasn't been discovered before. All my currently installed (win32) versions (4.3.[2346], 5.0.0RC1) suffer from this problem. Previous Comments: [2004-04-19 10:34:31] yiwakiri at st dot rim dot or dot jp Hmm, I'm confused. Windows(2k, XP 98): C:\php -r var_dump('0d1' == '0d2'); (1) bool(true) C:\php -r var_dump('00d1' == '00d2'); (2) bool(false) C:\php -r var_dump('0a1' == '0a2'); (3) bool(false) Unix like OS: % php -r var_dump('0d1' == '0d2'); (4) bool(false) % php -r var_dump('0a1' == '0a2'); (5) bool(false) Only (1) does not bring a result to expect. [2004-04-19 02:24:43] yiwakiri at st dot rim dot or dot jp A snapshot is also the same behavior. C:\php -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 10:21:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies C:\php -r var_dump(('0d1' == '0d2')); bool(true) [2004-04-17 15:24:52] postings-php-bug at hans-spath dot de [Windows XP Pro SP1] D:\PHP4.3.2\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.3\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.4\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.6\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 14:18:37) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies [Linux 2.6.5] [EMAIL PROTECTED]:~/compile/php-4.3.6% sapi/cli/php -r var_dump(('0d1' == '0d2')); bool(false) [2004-04-17 10:54:04] [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 [2004-04-16 20:05:20] yiwakiri at st dot rim dot or dot jp Description: The results of comparison differ by Windows and unix. Windows: c:\ php -r var_dump(('0d1' == '0d2')); bool(true) Unix like OS: % php -r var_dump(('0d1' == '0d2')); bool(false) I expect the same behavior for both. Reproduce code: --- c:\ php -r var_dump(('0d1' == '0d2')); Expected result: bool(false) Actual result: -- bool(true) -- Edit this bug report at http://bugs.php.net/?id=28031edit=1
#28031 [Opn-Fbk]: Results of comparison differ by Windows and unix.
ID: 28031 Updated by: [EMAIL PROTECTED] Reported By: yiwakiri at st dot rim dot or dot jp -Status: Open +Status: Feedback Bug Type: Scripting Engine problem Operating System: Windows 2k, XP, 98 PHP Version: 4.3.6, 4.3.7-dev New Comment: Most likely due to strtol() implementation in the M$ libc. Try using the === operator or strcmp() instead. (strings that look like numbers might be compared as numbers using the == operator) Previous Comments: [2004-04-19 15:11:06] postings-php-bug at hans-spath dot de D:\PHPver Microsoft Windows XP [Version 5.1.2600] D:\PHPlastest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 19 2004 14:16:52) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies D:\PHP5.0.0RC1\php -v PHP 5.0.0RC1 (cli) (built: Mar 18 2004 18:20:03) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.0RC1, Copyright (c) 1998-2004 Zend Technologies D:\PHPlastest\php-cli test\string_comparison.php 0x1 0x2 ( '0x1' == '0x2' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0d2 ( '0d1' == '0d2' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php 0d1x 0d2x ( '0d1x' == '0d2x' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0dx1 ( '0d1' == '0dx1' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0xd1 ( '0d1' == '0xd1' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0xd2 ( '0d1' == '0xd2' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php d1 xd2 ( 'd1' == 'xd2' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php d1 xd1 ( 'd1' == 'xd1' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0e9 0xe4 ( '0e9' == '0xe4' ) = bool(true) D:\PHP5.0.0RC1\php test\string_comparison.php 0e9 0xe4 ( '0e9' == '0xe4' ) = bool(true) I wonder why this hasn't been discovered before. All my currently installed (win32) versions (4.3.[2346], 5.0.0RC1) suffer from this problem. [2004-04-19 10:34:31] yiwakiri at st dot rim dot or dot jp Hmm, I'm confused. Windows(2k, XP 98): C:\php -r var_dump('0d1' == '0d2'); (1) bool(true) C:\php -r var_dump('00d1' == '00d2'); (2) bool(false) C:\php -r var_dump('0a1' == '0a2'); (3) bool(false) Unix like OS: % php -r var_dump('0d1' == '0d2'); (4) bool(false) % php -r var_dump('0a1' == '0a2'); (5) bool(false) Only (1) does not bring a result to expect. [2004-04-19 02:24:43] yiwakiri at st dot rim dot or dot jp A snapshot is also the same behavior. C:\php -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 10:21:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies C:\php -r var_dump(('0d1' == '0d2')); bool(true) [2004-04-17 15:24:52] postings-php-bug at hans-spath dot de [Windows XP Pro SP1] D:\PHP4.3.2\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.3\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.4\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.6\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 14:18:37) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies [Linux 2.6.5] [EMAIL PROTECTED]:~/compile/php-4.3.6% sapi/cli/php -r var_dump(('0d1' == '0d2')); bool(false) [2004-04-17 10:54:04] [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 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/28031 -- Edit this bug report at http://bugs.php.net/?id=28031edit=1
#24296 [Com]: Sablot XSLT gives error 3 when xml file too big
ID: 24296 Comment by: bogomil at spisanie dot com Reported By: andrew at shh dot fi Status: Closed Bug Type: XSLT related Operating System: win32 and linux PHP Version: 4.3.2 Assigned To: edink New Comment: Hi all I have the same problem with 4.3.3. My XML is small size 34 lines and 50 symbols easch. What is the problem? Bogomil Previous Comments: [2004-04-01 12:42:27] hvila at intercom dot org dot br I´m still getting this problem, using PHP version 4.3.3 (Debian package) - with already have the bundled expat in ext/xml upgraded to 1.95.6, and Expat 1.95.6. My XML files are being truncated a little bit after 8 KBytes, and this is causing a error XML parser error 3: no element found at... [2003-07-26 18:51:07] [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. PHP's bundled expat library was upgraded to 1.95.6. [2003-07-20 22:56:43] [EMAIL PROTECTED] Maybe we should upgrade the bundled expat in ext/xml too.. [2003-07-20 15:58:24] andrew at shh dot fi Close this if need be. It works for me now and the same if you run the updaté on Linux. [2003-07-20 15:56:55] andrew at shh dot fi Expat 1.95.6 http://sourceforge.net/projects/expat/ 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/24296 -- Edit this bug report at http://bugs.php.net/?id=24296edit=1
#28057 [Ana]: nl_langinfo returns wrong data for de_DE
ID: 28057 User updated by: bublavas at ecetra dot com Reported By: bublavas at ecetra dot com Status: Analyzed Bug Type: Strings related Operating System: 2.4.21-9.EL GNU/Linux PHP Version: 4.3.6 New Comment: Hmm, shouldn't this hack be in serialize() then? Do you know a workaround that I can use? Previous Comments: [2004-04-19 15:13:27] [EMAIL PROTECTED] No, the problem is in setlocale(). When you set LC_NUMERIC or LC_ALL and the decimal point is not '.', then LC_NUMERIC is set back to C again. This hack is required for serialize() when handling floating point numbers. [2004-04-19 14:28:22] bublavas at ecetra dot com Description: nl_langinfo returns wrong values for THOUSEP and RADIXCHAR after setting the locale to 'de_DE'. Using localeconv() returns the same wrong values. An equivalent C program returns correct results. PHP 4.3.4 returns the same results as 4.3.6; executing the script from the command line vs. using HTTP (Apache 2.0.48) makes no difference as well. Reproduce code: --- if ( setlocale(LC_ALL, 'de_DE') ) { echo thousands separator: , nl_langinfo(THOUSEP), \n; echo decimal point: , nl_langinfo(RADIXCHAR), \n; } else { echo cannot set locale to de_DE, \n; } Expected result: thousands separator: . decimal point: , Actual result: -- thousands separator: decimal point: . -- Edit this bug report at http://bugs.php.net/?id=28057edit=1
#28049 [Opn-Csd]: php_interbase.dll is missing
ID: 28049 Updated by: [EMAIL PROTECTED] Reported By: rene dot ladinger at ladinger dot com -Status: Open +Status: Closed Bug Type: InterBase related Operating System: Windows 2000 PHP Version: 5CVS-2004-04-18 (dev) New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-04-19 14:41:13] rene dot ladinger at ladinger dot com From Snapshot.log: . . . Copying php_ifx.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext Copying php_interbase.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext Warning: copy(Release_TS\php_interbase.dll): failed to open stream: No such file or directory in c:\php4build\snap\win32\build\mkdist.php on line 115 Copying php_ldap.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext Copying php_mbstring.dll from Release_TS to Release_TS/php-5.0.0RC2-dev/ext . . . [2004-04-18 17:23:35] rene dot ladinger at ladinger dot com Description: The php_interbase.dll is missing in the W32 snaps! -- Edit this bug report at http://bugs.php.net/?id=28049edit=1
#28059 [NEW]: Random segfaults
From: d at blrf dot net Operating system: Linux billy 2.4.22 #10 SMP Mon S PHP version: 5CVS-2004-04-19 (dev) PHP Bug Type: Reproducible crash Bug description: Random segfaults Description: This problem started from around php5-200404150830 and up. I tried the latest CVS one and I still get random segmentation fault. It seems that the point of failure is always the same: '#7 0x081d8583 in execute (op_array=0x4055dc74) at /root/setup/php5-200404191230/Zend/zend_execute.c:1391 1391if (EX(opline)-handler(execute_data, EX(opline), op_array TSRMLS_CC)) {' Reproduce code: --- I cannot post reporoduce code, as this happens in random places and I still couldn't figure out where. Sometimes at one line another time, it's working ... and then, it dies at completly different line. But as I was running the script several times, the execute frame code was always the same. That's why I'm appending two backtraces, with same script. Expected result: ... Actual result: -- Here's the backtrace I: -- warning: core file may not match specified executable file. Core was generated by `/usr/local/bin/php -q ./callcheck.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/local/lib/libhistory.so.4...done. Loaded symbols for /usr/local/lib/libhistory.so.4 Reading symbols from /usr/local/lib/libreadline.so.4...done. Loaded symbols for /usr/local/lib/libreadline.so.4 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /usr/lib/libpanel.so.5...done. Loaded symbols for /usr/lib/libpanel.so.5 Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.12...done. Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.12 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/local/lib/libsybdb.so.3...done. Loaded symbols for /usr/local/lib/libsybdb.so.3 Reading symbols from /usr/local/lib/libt1.so.5...done. Loaded symbols for /usr/local/lib/libt1.so.5 Reading symbols from /usr/local/lib/libfreetype.so.6...done. Loaded symbols for /usr/local/lib/libfreetype.so.6 Reading symbols from /usr/local/lib/libpng.so.3...done. Loaded symbols for /usr/local/lib/libpng.so.3 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/local/lib/libnetsnmp.so.5...done. Loaded symbols for /usr/local/lib/libnetsnmp.so.5 Reading symbols from /usr/local/lib/libxml2.so.2...done. Loaded symbols for /usr/local/lib/libxml2.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 #0 0x081cdd75 in zend_get_property_info (zobj=0x, member=0x40792194, silent=0) at /root/setup/php5-200404191230/Zend/zend_object_handlers.c:202 202 if (zend_hash_quick_find(zobj-ce-properties_info, Z_STRVAL_P(member), Z_STRLEN_P(member)+1, h, (void **) property_info)==SUCCESS) { (gdb) bt #0 0x081cdd75 in zend_get_property_info (zobj=0x, member=0x40792194, silent=0) at /root/setup/php5-200404191230/Zend/zend_object_handlers.c:202 #1 0x081cc939 in zend_std_read_property (object=0x407d53f4, member=0x40792194, type=0) at /root/setup/php5-200404191230/Zend/zend_object_handlers.c:287 #2 0x081d7c00 in zend_fetch_property_address_read (result=0x40792168, op1=0x4079217c, op2=0x40792190, Ts=0xbfffa100, type=0) at /root/setup/php5-200404191230/Zend/zend_execute.c:1155 #3 0x081d9d84 in zend_fetch_obj_r_handler (execute_data=0xbfffc570, opline=0x40792164, op_array=0x407774dc) at /root/setup/php5-200404191230/Zend/zend_execute.c:2120 #4 0x081d8583 in execute (op_array=0x407774dc) at /root/setup/php5-200404191230/Zend/zend_execute.c:1391 #5 0x081db61e in zend_do_fcall_common_helper (execute_data=0xbfffced0, opline=0x40761520, op_array=0x4075ec34) at /root/setup/php5-200404191230/Zend/zend_execute.c:2728 #6 0x081db8f8 in zend_do_fcall_by_name_handler (execute_data=0xc, opline=0x40761520, op_array=0x4075ec34) at /root/setup/php5-200404191230/Zend/zend_execute.c:2810 #7 0x081d8583 in execute (op_array=0x4075ec34) at /root/setup/php5-200404191230/Zend/zend_execute.c:1391 #8 0x081db61e in zend_do_fcall_common_helper
#28060 [NEW]: dlname not found in /usr/local/apache2/modules/libphp4.la.
From: jperezme at jazzfree dot com Operating system: Aix 5.2 PHP version: 4.3.6 PHP Bug Type: Compile Failure Bug description: dlname not found in /usr/local/apache2/modules/libphp4.la. Description: I have tried to compile php 4.3.6 on Aix 5.2 with gcc 2.95. All process seems to be fine except when i type make install. My libtool version is 1.5. I have build with: CC=gcc ./configure --prefix=/usr/local/apache2/php --with-config-file-path=/usr/local/apache2/php --with-mysql --with-apxs2=/usr/local/apache2/bin/apxs --enable-track-vars --disable-cgi --enable-force-cgi-redirect --with-zlib Any idea ? Actual result: -- libtool: install: warning: remember to run `libtool --finish /software/php-4.3.6/libs' Warning! dlname not found in /usr/local/apache2/modules/libphp4.la. Assuming installing a .so rather than a libtool archive. chmod 755 /usr/local/apache2/modules/libphp4.so chmod: /usr/local/apache2/modules/libphp4.so: One file or directory don't exist. apxs:Error: Command failed with rc=65536 . gmake: *** [install-sapi] Error 1 -- Edit bug report at http://bugs.php.net/?id=28060edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28060r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28060r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28060r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28060r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28060r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28060r=needscript Try newer version: http://bugs.php.net/fix.php?id=28060r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28060r=support Expected behavior: http://bugs.php.net/fix.php?id=28060r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28060r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28060r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28060r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28060r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28060r=dst IIS Stability: http://bugs.php.net/fix.php?id=28060r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28060r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28060r=float
#28054 [Com]: debug_backtrace() bug
ID: 28054 Comment by: olivier dot bichler at laposte dot net Reported By: misu200 at yahoo dot com Status: Open Bug Type: Unknown/Other Function Operating System: Fedora Linux kernel 2.6.4 PHP Version: 5.0.0RC1 New Comment: And there is an other problem : why the arguments $errNo, $errStr, $errFile, $errLine are not present in the result of debug_backtrace() ? I have the same problem... Previous Comments: [2004-04-19 09:05:28] misu200 at yahoo dot com Description: I set my own error handle function and then i try to include a non-existent file (aga.php).The problem is when i make a var_dump(debug_backtrace()) in my error handle function it shows me wrong results. Reproduce code: --- ?php function ourErrorHandler($errNo, $errStr, $errFile, $errLine) { echo PRE; var_dump(debug_backtrace()); echo /PRE; } // set the user error handler to be the above $oldErrorHandler = set_error_handler(ourErrorHandler, error_reporting()); require_once(aga.php); ? Expected result: array(2) { [0]= array(3) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [function]= string(15) ourErrorHandler } [1]= array(4) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [args]= array(1) { [0]= string(28) aga.php - this should be here } [function]= string(12) require_once } } Actual result: -- array(2) { [0]= array(3) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [function]= string(15) ourErrorHandler } [1]= array(4) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [args]= array(1) { [0]= string(28) /var/www/html/dir1/file2.php - is wrong } [function]= string(12) require_once } } -- Edit this bug report at http://bugs.php.net/?id=28054edit=1
#28061 [NEW]: Apache crashes upon SIGHUP when PHP module is loaded
From: michal at logix dot cz Operating system: Linux, glibc 2.3.2 PHP version: 4CVS-2004-04-19 (stable) PHP Bug Type: Apache2 related Bug description: Apache crashes upon SIGHUP when PHP module is loaded Description: Apache 2.0.49 and PHP 4.3.6 (as well as lates CVS snapshot). When everything is up and running I remove one of the Apache's logfiles (e.g. ~www/logs/access_log) and tell Apache to recreate it by calling killall -HUP httpd. Apache immediately crashes with the following in error_log: [Mon Apr 19 15:26:08 2004] [notice] SIGHUP received. Attempting to restart [Mon Apr 19 15:26:08 2004] [notice] seg fault or similar nasty error detected in the parent process When I disable loading of the PHP module in httpd.conf everything works just fine. When I downgrade to PHP 4.3.4 it works as well. Reproduce code: --- Compile Apache 2.0.49 with ./configure --prefix=/home/www --enable-http \ --enable-so --enable-usertrack and PHP 4.3.6 with: ./configure --prefix=/home/www/php \ --with-apxs2=/home/www/bin/apxs Install and run. Make any request, remove ~www/logs/access_log and run 'killall -HUP httpd' Expected result: access_log should be recreated Actual result: -- This appears in the error_log: [Mon Apr 19 15:26:08 2004] [notice] SIGHUP received. Attempting to restart [Mon Apr 19 15:26:08 2004] [notice] seg fault or similar nasty error detected in the parent process -- Edit bug report at http://bugs.php.net/?id=28061edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28061r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28061r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28061r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28061r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28061r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28061r=needscript Try newer version: http://bugs.php.net/fix.php?id=28061r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28061r=support Expected behavior: http://bugs.php.net/fix.php?id=28061r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28061r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28061r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28061r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28061r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28061r=dst IIS Stability: http://bugs.php.net/fix.php?id=28061r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28061r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28061r=float
#28062 [NEW]: gettext produces ? instead of german special chars
From: soletan at toxa dot de Operating system: SuSE Linux 7.2 PHP version: 4.3.6 PHP Bug Type: Gettext related Bug description: gettext produces ? instead of german special chars Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit bug report at http://bugs.php.net/?id=28062edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28062r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28062r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28062r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28062r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28062r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28062r=needscript Try newer version: http://bugs.php.net/fix.php?id=28062r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28062r=support Expected behavior: http://bugs.php.net/fix.php?id=28062r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28062r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28062r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28062r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28062r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28062r=dst IIS Stability: http://bugs.php.net/fix.php?id=28062r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28062r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28062r=float
#28062 [Opn]: gettext produces ? instead of german special chars
ID: 28062 User updated by: soletan at toxa dot de Reported By: soletan at toxa dot de Status: Open Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ Previous Comments: [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#27570 [Asn-Csd]: Tidy throw
ID: 27570 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Assigned +Status: Closed Bug Type: Unknown/Other Function Operating System: * PHP Version: 5CVS-2004-03-11 (dev) Assigned To: john New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-03-13 20:44:42] [EMAIL PROTECTED] This isn't really a bug per-se. Tidy is throwing an exception because it couldn't find the file, if you want to continue operation then you have to use a try / catch block. The only bug here is that when called from a procedural context tidy should be generating E_WARNINGs instead of throwing exceptions. [2004-03-13 16:50:18] [EMAIL PROTECTED] All functions that use TIDY_THROW exit PHP when an error is produced. Closing PHP just because the file was not found isn't a really good behaviour :) [2004-03-13 04:55:53] [EMAIL PROTECTED] And the problem is what? (AFAIK, this is the expected behaviour..) [2004-03-11 11:24:43] [EMAIL PROTECTED] Description: Using the given example, PHP exits. I think the problem is in TIDY_THROW. Reproduce code: --- ?php $tidy = tidy_parse_file('bogus.htm'); echo 'ok'; ? Expected result: ok Actual result: -- (gdb) run bug.php Starting program: /home/Nuno/php5/sapi/cli/php.exe bug.php Warning: tidy_parse_file(bogus.htm): failed to open stream: No such file or dire ctory in /home/Nuno/php5/sapi/cli/bug.php on line 2 Fatal error: Uncaught exception 'tidy_exception' with message 'Cannot Load 'bogu s.htm' into memory ' in /home/Nuno/php5/sapi/cli/bug.php:2 Stack trace: #0 {main} thrown in /home/Nuno/php5/sapi/cli/bug.php on line 2 Program exited with code 0377. -- Edit this bug report at http://bugs.php.net/?id=27570edit=1
#28063 [NEW]: Support for raw text te be send
From: alex at netflex dot nl Operating system: PHP version: Irrelevant PHP Bug Type: IMAP related Bug description: Support for raw text te be send Description: I like to see support for sending raw text to a server via imap. I'm currently working on an online calendar and i would use the Trusted Application (this allow's you to view boxes fom other users) from Novell, the imap server is a GroupWise system. (url of Novell's extension: http://developer.novell.com/ndk/doc/gwimap/gwimpenu/data/al7te9j.html) Reproduce code: --- $mbox = imap_open ({my.server.com:143}Calendar, appname, apppass); imap_send_raw($mbox, XGWCONF\n); // or somthing like this ... ... -- Edit bug report at http://bugs.php.net/?id=28063edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28063r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28063r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28063r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28063r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28063r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28063r=needscript Try newer version: http://bugs.php.net/fix.php?id=28063r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28063r=support Expected behavior: http://bugs.php.net/fix.php?id=28063r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28063r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28063r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28063r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28063r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28063r=dst IIS Stability: http://bugs.php.net/fix.php?id=28063r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28063r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28063r=float
#28064 [NEW]: php crashes with big scripts
From: gross at schlund dot de Operating system: Linux PHP version: 4.3.6 PHP Bug Type: Zend Engine 2 problem Bug description: php crashes with big scripts Description: Giving it a large script, PHP 4.3.6 crashes during parsing it. The stacktrace is as follows: (gdb) bt #0 0x081a5be6 in execute (op_array=0x8322c3c) at /usr/src/kundenserver/php-4.3.6/Zend/zend_execute.c:2007 #1 0x08191598 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/kundenserver/php-4.3.6/Zend/zend.c:886 #2 0x0816a933 in php_execute_script (primary_file=0xba38) at /usr/src/kundenserver/php-4.3.6/main/main.c:1731 #3 0x081a9fd3 in main (argc=2, argv=0xbab4) at /usr/src/kundenserver/php-4.3.6/sapi/cgi/cgi_main.c:1592 (gdb) You can find a core file under http://www.andigross.de/phpcrash/core.gz and the binary under http://www.andigross.de/phpcrash/phpbinary A phpinfo is under http://www.andigross.de/phpcrash/phpinfo.html the configure-line is: ./configure --with-zlib --enable-debug --enable-safe-mode=no --enable-discard-path=no --enable-track-vars --enable-force-cgi-redirect --enable-memory-limit --enable-trans-sid --enable-shmop --with-openssl --enable-xslt --with-xslt-sablot --with-dom --with-dom-xslt --with-dom-exslt The only modification to php.ini is: memory_limit = 90M; Compiler ist gcc 2.95.4. Reproduce code: --- You can find the code here: http://www.andigross.de/phpcrash/testdaten.php.txt Of curse, this is a very simple one to show the problem. The problem also occurs with more useful scripts. The application that caused the problem does something like $big_text=Huge PHP source; eval($big_text); Expected result: The script produces no output. With PHP 4.2.3 it works fine. Actual result: -- (gdb) bt #0 0x081a5be6 in execute (op_array=0x8322c3c) at /usr/src/kundenserver/php-4.3.6/Zend/zend_execute.c:2007 #1 0x08191598 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/kundenserver/php-4.3.6/Zend/zend.c:886 #2 0x0816a933 in php_execute_script (primary_file=0xba38) at /usr/src/kundenserver/php-4.3.6/main/main.c:1731 #3 0x081a9fd3 in main (argc=2, argv=0xbab4) at /usr/src/kundenserver/php-4.3.6/sapi/cgi/cgi_main.c:1592 (gdb) -- Edit bug report at http://bugs.php.net/?id=28064edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28064r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28064r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28064r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28064r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28064r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28064r=needscript Try newer version: http://bugs.php.net/fix.php?id=28064r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28064r=support Expected behavior: http://bugs.php.net/fix.php?id=28064r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28064r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28064r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28064r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28064r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28064r=dst IIS Stability: http://bugs.php.net/fix.php?id=28064r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28064r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28064r=float
#27899 [Com]: Apache got segfault after received SIGHUP
ID: 27899 Comment by: remco at linux-adept dot nl Reported By: charvel at bluemission dot com Status: No Feedback Bug Type: Apache2 related Operating System: Linux 2.4.25 PHP Version: 4.3.6RC2 New Comment: Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl graceful'. Which is a kill for logrotation! Everything was fine untill 4.3.5 came along. Changing back to 4.3.4 solves the problem. I have tried recompiling apache etc. Nothing helps. Gracefully restarting apache gives the following in the error-logs: [Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing restart [Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error detected in the parent process And apache has to be restarted once more to get it running. Previous Comments: [2004-04-16 08:49:45] afraser at w3internet dot com Thought I would check the previous version of Apache, since I only got this problem after upgrading Apache (2.0.48 to 2.0.49) and PHP (4.3.3 to 4.3.5) [EMAIL PROTECTED] home] www/bin/httpd -v Server version: Apache/2.0.48 Server built: Dec 14 2003 15:23:08 [EMAIL PROTECTED] home]# www/bin/apachectl configtest [Fri Apr 16 09:46:54 2004] [crit] Apache is running a threaded MPM, but your PHP Module is not compiled to be threadsafe. You need to recompile PHP. Pre-configuration failed Probably this is not a bug... but if this makes sense to one of you gurus could you explain to us what we did wrong? [2004-04-13 12:44:17] [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. [2004-04-09 11:13:18] [EMAIL PROTECTED] 1. As you're using a threaded webserver and asking for trouble this bug is pretty much bogus. (the crash happens elsewhere than in PHP itself..where is the GDB backtrace?) 2. Try adding your original configure options (those ones excluded which I told you NOT to use) one by one and see which one causes the crash, like this: # rm -f config.cache # ./configure --disable-all --with-apxs2 --with-zlib # make clean make (try them all _separately_ first!) [2004-04-09 05:24:09] charvel at bluemission dot com 1. worker 2. In this case work fine. [2004-04-08 19:01:21] [EMAIL PROTECTED] 1. What MPM is Apache2 using? 2. Get fresh sources, and use this configure line: # ./configure --disable-all --with-apxs2 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/27899 -- Edit this bug report at http://bugs.php.net/?id=27899edit=1
#27810 [Com]: Apache-2.0.49 crashes on graceful/restart
ID: 27810 Comment by: remco at linux-adept dot nl Reported By: renato at galle dot com dot br Status: Closed Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment: Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl graceful'. Which is a kill for logrotation! Everything was fine untill 4.3.5 came along. Changing back to 4.3.4 solves the problem. I have tried recompiling apache etc. Nothing helps. Gracefully restarting apache gives the following in the error-logs: [Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing restart [Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error detected in the parent process And apache has to be restarted once more to get it running. Previous Comments: [2004-04-16 11:28:38] noackjr at alumni dot rice dot edu Bless you -- the FreeBSD port works flawlessly for me now. [2004-04-16 07:46:13] ale at FreeBSD dot org Hopefully fixed in php port with this patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3apcre%3a%3aphp_pcre.c?rev=1.1content-type=text/x-cvsweb-markup [2004-04-16 03:35:45] towerofpower at operamail dot com You might want to take a look at... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20462 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17055 This seems very similar. Apache 2.0.49, mod_ssl (OpenSSL 0.9.7d), PHP 4.3.6, mod_perl 1.99_13, mod_delfate (zlib 1.1.4), perl 5.8.3 Built with VS.NET 2002 under Win2k, SP4 (except PHP 4.3.6 -- official binary) After 'net stop Apache2'... Apache.exe - Application Error The instruction at 0x77f92373 referenced memory at 0x0010. The memory could not be written. We do have a workaround for this problem: set LogLevel under httpd.conf from warn to error (this only works for a select set of versions of Apache and PHP) If Apache2 is not started with -D SSL and PHP 4.3.6 is used (over 4.3.5), the app error does not happen. [2004-04-15 17:45:01] danu at drydog dot com Here's the diffs between the old (working) version of PCRE and the new (broken) version of PCRE. Note changes in memory allocation code, which I believe is causing the problem: Note: 4.3.4 works (1.29.2.3, 1.132.2.10) Note: 4.3.5 is broken (1.29.2.5, 1.132.2.16) diff pcre.4.3.4/config.m4 pcre.4.3.5/config.m4 2c2 dnl $Id: config.m4,v 1.29.2.3 2003/06/29 00:08:29 andrei Exp $ --- dnl $Id: config.m4,v 1.29.2.5 2003/12/16 22:14:55 andrei Exp $ Only in pcre.4.3.4: pcrelib diff pcre.4.3.4/php_pcre.c pcre.4.3.5/php_pcre.c 19c19 /* $Id: php_pcre.c,v 1.132.2.10 2003/09/12 01:32:38 sniper Exp $ */ --- /* $Id: php_pcre.c,v 1.132.2.16 2004/02/01 19:56:16 moriyoshi Exp $ */ 108a109,117 pcre_malloc = php_pcre_malloc; pcre_free = php_pcre_free; #ifdef NO_RECURSE pcre_stack_malloc = php_pcre_malloc; pcre_stack_free = php_pcre_free; #endif 124,133d132 /* {{{ PHP_RINIT_FUNCTION(pcre) */ static PHP_RINIT_FUNCTION(pcre) { pcre_malloc = php_pcre_malloc; pcre_free = php_pcre_free; return SUCCESS; } /* }}} */ 177c176 while (isspace((int)*p)) p++; --- while (isspace((int)*(unsigned char *)p)) p++; 186c185 if (isalnum((int)delimiter) || delimiter == '\\') { --- if (isalnum((int)*(unsigned char *)delimiter) || delimiter == '\\') { 351c350 int flags; /* Match control flags */ --- long flags; /* Match control flags */ 365c364 int start_offset = 0; /* Where the new search starts */ --- long start_offset = 0; /* Where the new search starts */ 432c431 int name_cnt, name_size, ni = 0; --- int name_cnt = 0, name_size, ni = 0; 1394a1394,1398 case '\0': *q++ = '\\'; *q++ = '0'; break; 1526c1530 PHP_RINIT(pcre), --- NULL [2004-04-15 16:10:22] danu at drydog dot com NOT fixed with php-4.3.6 I just tried this and it isn't fixed with PHP 4.3.6 either. 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/27810 -- Edit this bug report at http://bugs.php.net/?id=27810edit=1
#27735 [Com]: restart of apache2 via kill -1 or apachectl causes crash
ID: 27735 Comment by: remco at linux-adept dot nl Reported By: as at netoholic dot de Status: Bogus Bug Type: Reproducible crash Operating System: Linux PHP Version: 4.3.5 / 4.3.6 New Comment: Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl graceful'. Which is a kill for logrotation! Everything was fine untill 4.3.5 came along. Changing back to 4.3.4 solves the problem. I have tried recompiling apache etc. Nothing helps. Gracefully restarting apache gives the following in the error-logs: [Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing restart [Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error detected in the parent process And apache has to be restarted once more to get it running. Previous Comments: [2004-04-16 08:32:27] [EMAIL PROTECTED] One of those bugs is good enough. Leave this one BOGUS. [2004-04-16 05:58:07] as at netoholic dot de Still present in 4.3.6... Hello Devs, anybody there ??? Read also http://bugs.php.net/bug.php?id=27810 [2004-03-31 15:30:49] noackjr at alumni dot rice dot edu This wasn't Bogus, as expected. It's fixed in CVS according to Bug 27810: http://bugs.php.net/bug.php?id=27810 [2004-03-31 05:53:04] js at iksz dot hu Nor FreeBSD, nor Linux libc checks whether regfree() got a null pointer. These bugs should be filtered in libc level. [2004-03-31 00:00:21] josestefan at hotmail dot com sorry, my report is wrong. I forgot that the error occurs after the first php request, when I did my testing. 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/27735 -- Edit this bug report at http://bugs.php.net/?id=27735edit=1
#27810 [Csd]: Apache-2.0.49 crashes on graceful/restart
ID: 27810 User updated by: renato at galle dot com dot br Reported By: renato at galle dot com dot br Status: Closed Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment: Here is the patch to fix it on php-4.3.6: --- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004 +++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004 @@ -106,15 +106,6 @@ REGISTER_LONG_CONSTANT(PREG_SPLIT_DELIM_CAPTURE, PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_SPLIT_OFFSET_CAPTURE, PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_GREP_INVERT, PREG_GREP_INVERT, CONST_CS | CONST_PERSISTENT); - - pcre_malloc = php_pcre_malloc; - pcre_free = php_pcre_free; - -#ifdef NO_RECURSE - pcre_stack_malloc = php_pcre_malloc; - pcre_stack_free = php_pcre_free; -#endif - return SUCCESS; } /* }}} */ @@ -130,6 +121,16 @@ } /* }}} */ +/* {{{ PHP_RINIT_FUNCTION(pcre) */ +static PHP_RINIT_FUNCTION(pcre) +{ + pcre_malloc = php_pcre_malloc; + pcre_free = php_pcre_free; + + return SUCCESS; +} +/* }}} */ + /* {{{ pcre_get_compiled_regex */ PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra, int *preg_options) { @@ -1527,7 +1528,7 @@ pcre_functions, PHP_MINIT(pcre), PHP_MSHUTDOWN(pcre), - NULL, + PHP_RINIT(pcre), NULL, PHP_MINFO(pcre), NO_VERSION_YET, Previous Comments: [2004-04-19 19:09:19] renato at galle dot com dot br Here is the patch to fix it on php-4.3.6: --- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004 +++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004 @@ -106,15 +106,6 @@ REGISTER_LONG_CONSTANT(PREG_SPLIT_DELIM_CAPTURE, PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_SPLIT_OFFSET_CAPTURE, PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_GREP_INVERT, PREG_GREP_INVERT, CONST_CS | CONST_PERSISTENT); - - pcre_malloc = php_pcre_malloc; - pcre_free = php_pcre_free; - -#ifdef NO_RECURSE - pcre_stack_malloc = php_pcre_malloc; - pcre_stack_free = php_pcre_free; -#endif - return SUCCESS; } /* }}} */ @@ -130,6 +121,16 @@ } /* }}} */ +/* {{{ PHP_RINIT_FUNCTION(pcre) */ +static PHP_RINIT_FUNCTION(pcre) +{ + pcre_malloc = php_pcre_malloc; + pcre_free = php_pcre_free; + + return SUCCESS; +} +/* }}} */ + /* {{{ pcre_get_compiled_regex */ PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra, int *preg_options) { @@ -1527,7 +1528,7 @@ pcre_functions, PHP_MINIT(pcre), PHP_MSHUTDOWN(pcre), - NULL, + PHP_RINIT(pcre), NULL, PHP_MINFO(pcre), NO_VERSION_YET, [2004-04-19 18:40:56] remco at linux-adept dot nl Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl graceful'. Which is a kill for logrotation! Everything was fine untill 4.3.5 came along. Changing back to 4.3.4 solves the problem. I have tried recompiling apache etc. Nothing helps. Gracefully restarting apache gives the following in the error-logs: [Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing restart [Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error detected in the parent process And apache has to be restarted once more to get it running. [2004-04-16 11:28:38] noackjr at alumni dot rice dot edu Bless you -- the FreeBSD port works flawlessly for me now. [2004-04-16 07:46:13] ale at FreeBSD dot org Hopefully fixed in php port with this patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3apcre%3a%3aphp_pcre.c?rev=1.1content-type=text/x-cvsweb-markup [2004-04-16 03:35:45] towerofpower at operamail dot com You might want to take a look at... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20462 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17055 This seems very similar. Apache 2.0.49, mod_ssl (OpenSSL 0.9.7d), PHP 4.3.6, mod_perl 1.99_13, mod_delfate (zlib 1.1.4), perl 5.8.3 Built with VS.NET 2002 under Win2k, SP4 (except PHP 4.3.6 -- official binary) After 'net stop Apache2'... Apache.exe - Application Error The instruction at 0x77f92373 referenced memory at 0x0010. The memory could not be written. We do have a workaround for this problem: set LogLevel under httpd.conf from warn to error (this only works for a select set of versions of Apache and PHP) If
#28038 [Opn-Asn]: Sent incorrect RCPT TO commands to SMTP server
ID: 28038 Updated by: [EMAIL PROTECTED] Reported By: jordi at jcanals dot net -Status: Open +Status: Assigned Bug Type: Mail related Operating System: Windows PHP Version: 4.3.6 -Assigned To: +Assigned To: wez New Comment: If you think it's a bug you may fix it :) Previous Comments: [2004-04-19 15:17:15] [EMAIL PROTECTED] It is a bug, since PHP is sending those headers by parsing the email. [2004-04-18 01:00:13] [EMAIL PROTECTED] Mailing with PHP on Windows doesn't support this. Not a bug. [2004-04-17 19:14:01] jordi at jcanals dot net Description: In windows, and using an SMTP server, when you try to send a mail using the mail function the SMTP transaction will fail if you include recipient names. When including any recipient header in the following format (wich follows the RFC 2822), the mail function does not handle it properly: To: User Name [EMAIL PROTECTED] Cc: Other User [EMAIL PROTECTED] Bcc: Third User [EMAIL PROTECTED] Loking at the SMTP transaction, the PHP mail layer sends this RCPT commands wich do not folow the SMTP standard stated on RFC 2821: RCPT TO:User Name [EMAIL PROTECTED] RCPT TO:Other User [EMAIL PROTECTED] RCPT TO:Third User [EMAIL PROTECTED] Fails always with this environments: Tested on Windows XP, Apache 2.0.49, PHP 4.3.6 (Also in 4.3.4) Tested also on Windows 2000, IIS, PHP 4.3.6 Tested Using SMTP servers on Linux with Exim and Sendmail. Tested also using the default Windows 2000 SMTP server. Reproduce code: --- // SAMPLE 1: $to_recipient = User Name [EMAIL PROTECTED]; $header = Cc: Other User [EMAIL PROTECTED]\r\n; $header .= Bcc: Third User [EMAIL PROTECTED]\r\n; mail($to_recipient, $subject, $body, $header); // FAILS with SMTP errors for all three recipients. SAMPLE 2: $to_recipient = [EMAIL PROTECTED]; $header = To: User Name [EMAIL PROTECTED]\r\n; $header .= Cc: Other User [EMAIL PROTECTED]\r\n; $header .= Bcc: Third User [EMAIL PROTECTED]\r\n; mail($to_recipient, $subject, $body, $header); FAILS on with SMTP error on the three recipients passed on the $header field. Expected result: Expected that the mail layer exctracts only the mail address from recipients to send the SMTP commands: As seen on the RFC's 2821 and 2822, when sending a mail with the recipient headers formed like above, it is expected the mail layer to extract ONLY the email address to send the RCPT commands, and pass the headers without any change in the DATA command during the SMTP transaction. Example of the correct SMTP transaction for the above headers: RCPT TO:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] RCPT TO:[EMAIL PROTECTED] DATA To: User Name [EMAIL PROTECTED] Cc: Other User [EMAIL PROTECTED] Bcc: Third User [EMAIL PROTECTED] Actual result: -- You get that error for all recipients with the recipient name: Warning: mail(): SMTP server response: 501 SomeOne Name [EMAIL PROTECTED]: @ or . expected after SomeOne in mail.class.php on line 333 This error is produced when the mail layer is sending a wrong formed RCPT TO: command in the SMTP transaction. -- Edit this bug report at http://bugs.php.net/?id=28038edit=1
#27810 [Csd]: Apache-2.0.49 crashes on graceful/restart
ID: 27810 User updated by: renato at galle dot com dot br Reported By: renato at galle dot com dot br Status: Closed Bug Type: Apache2 related Operating System: FreeBSD-5.2.1-RELEASE-p4 PHP Version: 4.3.5 New Comment: Here is the patch to fix it on php-4.3.6: --- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004 +++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004 @@ -106,15 +106,6 @@ REGISTER_LONG_CONSTANT(PREG_SPLIT_DELIM_CAPTURE, PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_SPLIT_OFFSET_CAPTURE, PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_GREP_INVERT, PREG_GREP_INVERT, CONST_CS | CONST_PERSISTENT); - - pcre_malloc = php_pcre_malloc; - pcre_free = php_pcre_free; - -#ifdef NO_RECURSE - pcre_stack_malloc = php_pcre_malloc; - pcre_stack_free = php_pcre_free; -#endif - return SUCCESS; } /* }}} */ @@ -130,6 +121,16 @@ } /* }}} */ +/* {{{ PHP_RINIT_FUNCTION(pcre) */ +static PHP_RINIT_FUNCTION(pcre) +{ + pcre_malloc = php_pcre_malloc; + pcre_free = php_pcre_free; + + return SUCCESS; +} +/* }}} */ + /* {{{ pcre_get_compiled_regex */ PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra, int *preg_options) { @@ -1527,7 +1528,7 @@ pcre_functions, PHP_MINIT(pcre), PHP_MSHUTDOWN(pcre), - NULL, + PHP_RINIT(pcre), NULL, PHP_MINFO(pcre), NO_VERSION_YET, Previous Comments: [2004-04-19 19:09:19] renato at galle dot com dot br Here is the patch to fix it on php-4.3.6: --- ext/pcre/php_pcre.c.origFri Apr 16 09:21:14 2004 +++ ext/pcre/php_pcre.c Fri Apr 16 09:23:36 2004 @@ -106,15 +106,6 @@ REGISTER_LONG_CONSTANT(PREG_SPLIT_DELIM_CAPTURE, PREG_SPLIT_DELIM_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_SPLIT_OFFSET_CAPTURE, PREG_SPLIT_OFFSET_CAPTURE, CONST_CS | CONST_PERSISTENT); REGISTER_LONG_CONSTANT(PREG_GREP_INVERT, PREG_GREP_INVERT, CONST_CS | CONST_PERSISTENT); - - pcre_malloc = php_pcre_malloc; - pcre_free = php_pcre_free; - -#ifdef NO_RECURSE - pcre_stack_malloc = php_pcre_malloc; - pcre_stack_free = php_pcre_free; -#endif - return SUCCESS; } /* }}} */ @@ -130,6 +121,16 @@ } /* }}} */ +/* {{{ PHP_RINIT_FUNCTION(pcre) */ +static PHP_RINIT_FUNCTION(pcre) +{ + pcre_malloc = php_pcre_malloc; + pcre_free = php_pcre_free; + + return SUCCESS; +} +/* }}} */ + /* {{{ pcre_get_compiled_regex */ PHPAPI pcre* pcre_get_compiled_regex(char *regex, pcre_extra **extra, int *preg_options) { @@ -1527,7 +1528,7 @@ pcre_functions, PHP_MINIT(pcre), PHP_MSHUTDOWN(pcre), - NULL, + PHP_RINIT(pcre), NULL, PHP_MINFO(pcre), NO_VERSION_YET, [2004-04-19 18:40:56] remco at linux-adept dot nl Using PHP 4.3.5 or 4.3.6 crashes my Apache 2.0.49 doing a 'apachectl graceful'. Which is a kill for logrotation! Everything was fine untill 4.3.5 came along. Changing back to 4.3.4 solves the problem. I have tried recompiling apache etc. Nothing helps. Gracefully restarting apache gives the following in the error-logs: [Mon Apr 19 18:28:10 2004] [notice] Graceful restart requested, doing restart [Mon Apr 19 18:28:10 2004] [notice] seg fault or similar nasty error detected in the parent process And apache has to be restarted once more to get it running. [2004-04-16 11:28:38] noackjr at alumni dot rice dot edu Bless you -- the FreeBSD port works flawlessly for me now. [2004-04-16 07:46:13] ale at FreeBSD dot org Hopefully fixed in php port with this patch: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/php4/files/patch-ext%3a%3apcre%3a%3aphp_pcre.c?rev=1.1content-type=text/x-cvsweb-markup [2004-04-16 03:35:45] towerofpower at operamail dot com You might want to take a look at... http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20462 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17055 This seems very similar. Apache 2.0.49, mod_ssl (OpenSSL 0.9.7d), PHP 4.3.6, mod_perl 1.99_13, mod_delfate (zlib 1.1.4), perl 5.8.3 Built with VS.NET 2002 under Win2k, SP4 (except PHP 4.3.6 -- official binary) After 'net stop Apache2'... Apache.exe - Application Error The instruction at 0x77f92373 referenced memory at 0x0010. The memory could not be written. We do have a workaround for this problem: set LogLevel under httpd.conf from warn to error (this only works for a select set of versions of Apache and PHP) If
#2195 [Com]: Call to undefined function: dbmopen()
ID: 2195 Comment by: info at absolutebio dot com Reported By: barce at lines dot edu Status: Closed Bug Type: DBM/DBA related Operating System: Linux Red Hat 6 PHP Version: 4.0 Beta 2 New Comment: Call to undefined function: dbmopen() What is a problem ? Nedecki_Tamás WindowsME platform Mandrake linux 9.1 platform Kliens wide Previous Comments: [1999-08-30 17:06:23] barce at lines dot edu When you try to use dbmopen yo can't because Fatal error: Call to undefined function: dbmopen() But DBM support is compiled as shown in phpinfo DataBase API V1 ($Id: dba.c,v 1.4 1999/08/02 19:16:40 zeev Exp $) gdbm ndbm -- Edit this bug report at http://bugs.php.net/?id=2195edit=1
#25252 [Com]: CGI Application Timeout
ID: 25252 Comment by: cdeogade at spectrum2020 dot com Reported By: brothererryn at atomicmonks dot com Status: Closed Bug Type: CGI related Operating System: Windows 2000 Professional PHP Version: 4.3.3 Assigned To: phildriscoll New Comment: hi, I am running PHP 4.3.4.4 on IIS 5.1 on Windows XP. I think i installed PHP in Jan 2004. I get the folowing error message: CGI Timeout The specified CGI application exceeded the allowed time for processing. The server has deleted the process. In one of your responses you stated that everything above 4.3.3 is fixed, but its doesnt seem so. Also i changed the script execution time to higher value in my IIS server. Thanks Chaitanya Previous Comments: [2004-03-30 12:11:30] bryan at bleu-tango dot com I have been having a similar problem, but it happens in every version from 4.3.2 through the 3-30 stable win32 release. See Bug #27781 [2004-03-30 01:26:55] [EMAIL PROTECTED] This bug (number 25252) is related to the fact that I accidentally put the cli rather than the cgi version of php.exe into the 4.3.3 installer. This was corrected after a few hours, and I'm certain that I didn't repeat the mistake in 4.3.4 or 4.3.5. Hence, I can state with confidence that the problems reported after I fixed the original error in August 2003, are not related to this bug. [2004-03-29 19:26:39] bryan at bleu-tango dot com I am having a similar problem with a similar setup. IIS 5, Win2k, PHP4.3.4 and 4.3.5 (tried with both). Any scripts that require database WRITES and executed with Internet Explorer (6.0) timeout. If you use Netscape, the script executes fine. If the script only does reads, you can use Netscape or IE. I have had this problem with PHPBB, in particular. This was not an issue in PHP 4.3.2 [2004-01-30 01:40:25] evan dot swendsen at shaw dot ca I have IIS 5.0 win Win 2K server with php 4.3.4 (from the installer and I'm getting the same thing) i tried pasting the 4.3.4 zip over top and im still getting it. HELP!! [2003-08-28 08:48:46] notepad at codewalkers dot com i'm not sure the problem is fixed, cause i had the same problem having downloaded the installer after this conversation took place. got it working with dan's suggestion, using the stable release. you may want to double check 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/25252 -- Edit this bug report at http://bugs.php.net/?id=25252edit=1
#27865 [Asn-Csd]: CLI PHP: STDIN/OUT/ERR are not the good fd's
ID: 27865 Updated by: [EMAIL PROTECTED] Reported By: bernard at kuantic dot com -Status: Assigned +Status: Closed Bug Type: Filesystem function related Operating System: Linux Fedora Core 1 PHP Version: 5.0.0RC1 Assigned To: wez New Comment: This bug has been fixed in CVS. 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/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2004-04-05 06:07:44] bernard at kuantic dot com Description: Hello. I'm trying to run a php script from xinetd (Fedora Linux). I need to close stdin, stdout stderr since I want to close the socket established with the caller process (I have a long processing to do locally, I need to release a remote resource closing the connection is the only way I can do it). I've tried : fclose(STDIN); fclose(STDOUT); fclose(STDERR); It does not work, the socket is still up running. When I run strace(1), I see that I'm closing fds 4, 5 6 (fd 3 is the fd of the script being read) and not fd 0, 1 2. It seems that CLI PHP calls dup(2) to get duplicates of fd 0, 1 2 and so these 3 fds are totally unreachable from the script itself. I'm not used to php source code, but I think that the problem comes from getting constants STDIN, STDOUT STDERR thru filter code generation used by php://stdin etc. and no provision is done for the first calls: a dup(2) is automatically used. So constants STDIN, STDOUT STDERR are not pointing to the correct fd's, but dup's. -- Edit this bug report at http://bugs.php.net/?id=27865edit=1
#28065 [NEW]: resource limits do not work
From: floeff at arcor dot de Operating system: Linux 2.4.26 PHP version: 4.3.6 PHP Bug Type: Reproducible crash Bug description: resource limits do not work Description: Maybe I misunderstand something, but for me it seems that the resource limits do not work. In my php.ini, I set max_execution_time = 10 max_input_time = 10 which - to my understanding - should limit executing time for scripts to 10 seconds. I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with a hughe PHP file involving some diagram creation, I can kill the machine if I re-load the script for five seconds continuously. It soaks up all my memory and runs for nearly a minute. What could be wrong in here? If you need more information, please let me know. Thanks! -- Edit bug report at http://bugs.php.net/?id=28065edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28065r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28065r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28065r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28065r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28065r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28065r=needscript Try newer version: http://bugs.php.net/fix.php?id=28065r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28065r=support Expected behavior: http://bugs.php.net/fix.php?id=28065r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28065r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28065r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28065r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28065r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28065r=dst IIS Stability: http://bugs.php.net/fix.php?id=28065r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28065r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28065r=float
#28059 [Opn-Fbk]: Random segfaults
ID: 28059 Updated by: [EMAIL PROTECTED] Reported By: d at blrf dot net -Status: Open +Status: Feedback -Bug Type: Reproducible crash +Bug Type: Zend Engine 2 problem Operating System: Linux billy 2.4.22 #10 SMP Mon S PHP Version: 5CVS-2004-04-19 (dev) New Comment: We really need a short reproducing script, otherwise there is no way to figure out what goes wrong. An additional help might be by using valgrind to check memory allocations etc. Please run apache with: valgrind /path/to/apache_1.3 -X and request your script, this should give you some information about bad memory access. Previous Comments: [2004-04-19 16:37:02] d at blrf dot net Description: This problem started from around php5-200404150830 and up. I tried the latest CVS one and I still get random segmentation fault. It seems that the point of failure is always the same: '#7 0x081d8583 in execute (op_array=0x4055dc74) at /root/setup/php5-200404191230/Zend/zend_execute.c:1391 1391if (EX(opline)-handler(execute_data, EX(opline), op_array TSRMLS_CC)) {' Reproduce code: --- I cannot post reporoduce code, as this happens in random places and I still couldn't figure out where. Sometimes at one line another time, it's working ... and then, it dies at completly different line. But as I was running the script several times, the execute frame code was always the same. That's why I'm appending two backtraces, with same script. Expected result: ... Actual result: -- Here's the backtrace I: -- warning: core file may not match specified executable file. Core was generated by `/usr/local/bin/php -q ./callcheck.php'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libcrypt.so.1...done. Loaded symbols for /lib/libcrypt.so.1 Reading symbols from /usr/local/lib/libhistory.so.4...done. Loaded symbols for /usr/local/lib/libhistory.so.4 Reading symbols from /usr/local/lib/libreadline.so.4...done. Loaded symbols for /usr/local/lib/libreadline.so.4 Reading symbols from /lib/libncurses.so.5...done. Loaded symbols for /lib/libncurses.so.5 Reading symbols from /usr/lib/libpanel.so.5...done. Loaded symbols for /usr/lib/libpanel.so.5 Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.12...done. Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.12 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/local/lib/libsybdb.so.3...done. Loaded symbols for /usr/local/lib/libsybdb.so.3 Reading symbols from /usr/local/lib/libt1.so.5...done. Loaded symbols for /usr/local/lib/libt1.so.5 Reading symbols from /usr/local/lib/libfreetype.so.6...done. Loaded symbols for /usr/local/lib/libfreetype.so.6 Reading symbols from /usr/local/lib/libpng.so.3...done. Loaded symbols for /usr/local/lib/libpng.so.3 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/local/lib/libnetsnmp.so.5...done. Loaded symbols for /usr/local/lib/libnetsnmp.so.5 Reading symbols from /usr/local/lib/libxml2.so.2...done. Loaded symbols for /usr/local/lib/libxml2.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnss_files.so.2...done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /lib/libnss_compat.so.2...done. Loaded symbols for /lib/libnss_compat.so.2 Reading symbols from /lib/libnss_dns.so.2...done. Loaded symbols for /lib/libnss_dns.so.2 #0 0x081cdd75 in zend_get_property_info (zobj=0x, member=0x40792194, silent=0) at /root/setup/php5-200404191230/Zend/zend_object_handlers.c:202 202 if (zend_hash_quick_find(zobj-ce-properties_info, Z_STRVAL_P(member), Z_STRLEN_P(member)+1, h, (void **) property_info)==SUCCESS) { (gdb) bt #0 0x081cdd75 in zend_get_property_info (zobj=0x, member=0x40792194, silent=0) at /root/setup/php5-200404191230/Zend/zend_object_handlers.c:202 #1 0x081cc939 in zend_std_read_property (object=0x407d53f4, member=0x40792194, type=0) at /root/setup/php5-200404191230/Zend/zend_object_handlers.c:287 #2 0x081d7c00 in zend_fetch_property_address_read (result=0x40792168, op1=0x4079217c, op2=0x40792190, Ts=0xbfffa100, type=0) at /root/setup/php5-200404191230/Zend/zend_execute.c:1155 #3 0x081d9d84 in zend_fetch_obj_r_handler (execute_data=0xbfffc570, opline=0x40792164, op_array=0x407774dc) at /root/setup/php5-200404191230/Zend/zend_execute.c:2120 #4 0x081d8583
#28054 [Opn-Asn]: debug_backtrace() bug
ID: 28054 Updated by: [EMAIL PROTECTED] Reported By: misu200 at yahoo dot com -Status: Open +Status: Assigned -Bug Type: Unknown/Other Function +Bug Type: Zend Engine 2 problem Operating System: Fedora Linux kernel 2.6.4 PHP Version: 5.0.0RC1 -Assigned To: +Assigned To: andi New Comment: Assigning to the engine guru, Andi. Previous Comments: [2004-04-19 16:45:48] olivier dot bichler at laposte dot net And there is an other problem : why the arguments $errNo, $errStr, $errFile, $errLine are not present in the result of debug_backtrace() ? I have the same problem... [2004-04-19 09:05:28] misu200 at yahoo dot com Description: I set my own error handle function and then i try to include a non-existent file (aga.php).The problem is when i make a var_dump(debug_backtrace()) in my error handle function it shows me wrong results. Reproduce code: --- ?php function ourErrorHandler($errNo, $errStr, $errFile, $errLine) { echo PRE; var_dump(debug_backtrace()); echo /PRE; } // set the user error handler to be the above $oldErrorHandler = set_error_handler(ourErrorHandler, error_reporting()); require_once(aga.php); ? Expected result: array(2) { [0]= array(3) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [function]= string(15) ourErrorHandler } [1]= array(4) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [args]= array(1) { [0]= string(28) aga.php - this should be here } [function]= string(12) require_once } } Actual result: -- array(2) { [0]= array(3) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [function]= string(15) ourErrorHandler } [1]= array(4) { [file]= string(28) /var/www/html/dir1/file2.php [line]= int(15) [args]= array(1) { [0]= string(28) /var/www/html/dir1/file2.php - is wrong } [function]= string(12) require_once } } -- Edit this bug report at http://bugs.php.net/?id=28054edit=1
#28061 [Opn-Bgs]: Apache crashes upon SIGHUP when PHP module is loaded
ID: 28061 Updated by: [EMAIL PROTECTED] Reported By: michal at logix dot cz -Status: Open +Status: Bogus Bug Type: Apache2 related Operating System: Linux, glibc 2.3.2 PHP Version: 4CVS-2004-04-19 (stable) New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. Please search the bug database before submitting a bug. Previous Comments: [2004-04-19 16:52:43] michal at logix dot cz Description: Apache 2.0.49 and PHP 4.3.6 (as well as lates CVS snapshot). When everything is up and running I remove one of the Apache's logfiles (e.g. ~www/logs/access_log) and tell Apache to recreate it by calling killall -HUP httpd. Apache immediately crashes with the following in error_log: [Mon Apr 19 15:26:08 2004] [notice] SIGHUP received. Attempting to restart [Mon Apr 19 15:26:08 2004] [notice] seg fault or similar nasty error detected in the parent process When I disable loading of the PHP module in httpd.conf everything works just fine. When I downgrade to PHP 4.3.4 it works as well. Reproduce code: --- Compile Apache 2.0.49 with ./configure --prefix=/home/www --enable-http \ --enable-so --enable-usertrack and PHP 4.3.6 with: ./configure --prefix=/home/www/php \ --with-apxs2=/home/www/bin/apxs Install and run. Make any request, remove ~www/logs/access_log and run 'killall -HUP httpd' Expected result: access_log should be recreated Actual result: -- This appears in the error_log: [Mon Apr 19 15:26:08 2004] [notice] SIGHUP received. Attempting to restart [Mon Apr 19 15:26:08 2004] [notice] seg fault or similar nasty error detected in the parent process -- Edit this bug report at http://bugs.php.net/?id=28061edit=1
#27801 [Com]: networking issue..
ID: 27801 Comment by: tibyke at tibyke dot net Reported By: ury at iptel dot by Status: Feedback Bug Type: Sockets related Operating System: linux PHP Version: 4.3.5 New Comment: this snapshot is ok, ilohamail works ok. thx, tibyke Previous Comments: [2004-04-19 15:19:24] [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 See Bug #28055, and please try the next snapshot. [2004-04-18 12:53:58] jimmy at quadrahosting dot com dot au To those who are experiencing this problem (on 4.3.5 and up) - do you check the result of fgets using feof? If this is the case, the feof is the cause of the delay because since 4.3.5 PHP will only return true on feof when the socket connection is closed or after the socket timeout period has elapsed. See www.php.net/feof A quick fix is to call stream_set_timeout($sockethandle, 2) or a similarly low timeout. Can someone confirm that this works for you? [2004-04-12 07:31:10] [EMAIL PROTECTED] None of you have bothered to do some bug finding of your own; we don't have time to install large applications and debug them. Please give me the shortest script that reproduces the bug, as I have asked, otherwise this report will sit and rot. [2004-04-12 05:06:26] tibyke at tibyke dot hu the problem still exists, even with latest snapshot. i wonder what else we could/should do besides reporting the problem, and pointing the allegedly faulty piece of code, and. get ilohamail at www.ilohamail.org (0812), install it alongside a php 4.3.4, and you'll see what we're talking about. if you dont want to then write an email, I'll show you the case on my box (as [EMAIL PROTECTED] didnt even bother to reply to my mail) regards, tibyke [2004-04-11 12:14:20] [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 the bug report online at http://bugs.php.net/27801 -- Edit this bug report at http://bugs.php.net/?id=27801edit=1
#28062 [Opn-Fbk]: gettext produces ? instead of german special chars
ID: 28062 Updated by: [EMAIL PROTECTED] Reported By: soletan at toxa dot de -Status: Open +Status: Feedback Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. Previous Comments: [2004-04-19 17:08:26] soletan at toxa dot de BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#28058 [Opn-Fbk]: __autoload called for every class declaration
ID: 28058 Updated by: [EMAIL PROTECTED] Reported By: alex_boyer at hotmail dot com -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Windows 2000 Pro PHP Version: 5.0.0RC1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Previous Comments: [2004-04-19 14:52:44] alex_boyer at hotmail dot com Description: __autoload is called for every class declaration that extends a parent class, even if the parent declaration file is included. Reproduce code: --- index.php: require_once b.php; function __autoload($theclass){ echo Auto load\n; require_once($theclass..php); } $obj = new b(); $obj-hello(); b.php: require_once a.php; class b extends a{ function hello() { echo B;} } a.php: class a{ function hello() {echo A;} } Expected result: B Actual result: -- Auto load B -- Edit this bug report at http://bugs.php.net/?id=28058edit=1
#2195 [Csd]: Call to undefined function: dbmopen()
ID: 2195 Updated by: [EMAIL PROTECTED] Reported By: barce at lines dot edu Status: Closed Bug Type: DBM/DBA related Operating System: Linux Red Hat 6 PHP Version: 4.0 Beta 2 New Comment: The extension isn't loaded is the problem. Previous Comments: [2004-04-19 19:14:20] info at absolutebio dot com Call to undefined function: dbmopen() What is a problem ? Nedecki_Tamás WindowsME platform Mandrake linux 9.1 platform Kliens wide [1999-08-30 17:06:23] barce at lines dot edu When you try to use dbmopen yo can't because Fatal error: Call to undefined function: dbmopen() But DBM support is compiled as shown in phpinfo DataBase API V1 ($Id: dba.c,v 1.4 1999/08/02 19:16:40 zeev Exp $) gdbm ndbm -- Edit this bug report at http://bugs.php.net/?id=2195edit=1
#28067 [NEW]: partially incorrect utf8 to htmlentities mapping
From: ben at csgb dot de Operating system: possibly all PHP version: Irrelevant PHP Bug Type: Strings related Bug description: partially incorrect utf8 to htmlentities mapping Description: During some doublecheck after Bug #28042 was closed, I discovered some more mistakes in that file. I just checked the UTF-8 tables, don't know if the other charsets are wrong, too. In Bug #28042, We forgot two letters of the greek table, 'upsih' and 'piv', which are spelled with an 'i' as in ice instead of '1'. Also there are some NULLs missing at several points. This causes htmlentities(,,UTF-8) to convert UTF-8 encoded chars into the wrong or into no HTML-Entities since the mappings are shifted. For example U+202F is mapped to permil; which should be U+2030. Here is my diff of the php5-cvs/ext/standard/html.c, the same modifications should be made in php-4.3, please double check --- html.c 2004-04-18 02:30:24.0 +0200 +++ html.c.fixed2004-04-19 18:44:47.949012992 +0200 @@ -114,13 +114,13 @@ /* 354 - 375 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 376 */ Yuml, /* 377 - 401 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 402 */ fnof }; @@ -130,7 +130,7 @@ circ, /* 711 - 731 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 732 */ tilde, }; @@ -147,9 +147,9 @@ sigmaf, sigma, tau, upsilon, phi, chi, psi, omega, /* 970 - 976 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, - thetasym, ups1h, + thetasym, upsih, NULL, NULL, NULL, - p1v + piv }; static entity_table_t ent_uni_punct[] = { @@ -158,7 +158,7 @@ thinsp, NULL, NULL, zwnj, zwj, lrm, rlm, NULL, NULL, NULL, ndash, mdash, NULL, NULL, NULL, lsquo, rsquo, sbquo, NULL, ldquo, rdquo, bdquo, - dagger, Dagger, bull, NULL, NULL, NULL, hellip, + NULL, dagger, Dagger, bull, NULL, NULL, NULL, hellip, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, permil, NULL, prime, Prime, NULL, NULL, NULL, NULL, NULL, lsaquo, rsaquo, NULL, NULL, NULL, oline, NULL, NULL, NULL, NULL, NULL, @@ -191,7 +191,7 @@ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8624 (0x21b0) */ - NULL, NULL, NULL, NULL, crarr, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, crarr, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8640 (0x21c0) */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, @@ -206,9 +206,9 @@ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8704 (0x2200) */ forall, comp, part, exist, nexist, empty, NULL, nabla, - isin, notin, epsis, NULL, ni, bepsi, NULL, prod, + isin, notin, epsis, ni, NULL, bepsi, NULL, prod, /* 8720 (0x2210) */ - coprod, sum, minus, mnplus, plusdo, NULL, setmn, NULL, + coprod, sum, minus, mnplus, plusdo, NULL, setmn, lowast, compfn, NULL, radic, NULL, NULL, prop, infin, ang90, /* 8736 (0x2220) */ ang, angmsd, angsph, mid, nmid, par, npar, and, @@ -232,17 +232,19 @@ npr, nsc, sub, sup, nsub, nsup, sube, supe, /* 8840 - 8852 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, +NULL, /* 8853 */ oplus, NULL, otimes, /* 8856 - 8868 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, +NULL, /* 8869 */ perp, /* 8870 - 8901 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, + NULL, /* 8901 */ sdot, /* 8902 - 8967 */ @@ -252,14 +254,13 @@ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, /* 8968 */ lceil, rceil, lfloor, rfloor, /* 8969 - 9000 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL,
#28063 [Opn]: Support for raw text to be send with IMAP
ID: 28063 Updated by: [EMAIL PROTECTED] -Summary: Support for raw text te be send Reported By: alex at netflex dot nl Status: Open -Bug Type:IMAP related +Bug Type:Feature/Change Request PHP Version: Irrelevant New Comment: Making this a feature request and updating summary Previous Comments: [2004-04-19 17:23:10] alex at netflex dot nl Description: I like to see support for sending raw text to a server via imap. I'm currently working on an online calendar and i would use the Trusted Application (this allow's you to view boxes fom other users) from Novell, the imap server is a GroupWise system. (url of Novell's extension: http://developer.novell.com/ndk/doc/gwimap/gwimpenu/data/al7te9j.html) Reproduce code: --- $mbox = imap_open ({my.server.com:143}Calendar, appname, apppass); imap_send_raw($mbox, XGWCONF\n); // or somthing like this ... ... -- Edit this bug report at http://bugs.php.net/?id=28063edit=1
#28067 [Opn]: partially incorrect utf8 to htmlentities mapping
ID: 28067 User updated by: ben at csgb dot de Reported By: ben at csgb dot de Status: Open Bug Type: Strings related Operating System: possibly all PHP Version: Irrelevant New Comment: sorry, please be careful when using the diff, have to learn to copy and paste correctly )-; the diff ends after the first: + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 9001 */ lang, rang, }; without the eck Previous Comments: [2004-04-19 20:46:26] ben at csgb dot de Description: During some doublecheck after Bug #28042 was closed, I discovered some more mistakes in that file. I just checked the UTF-8 tables, don't know if the other charsets are wrong, too. In Bug #28042, We forgot two letters of the greek table, 'upsih' and 'piv', which are spelled with an 'i' as in ice instead of '1'. Also there are some NULLs missing at several points. This causes htmlentities(,,UTF-8) to convert UTF-8 encoded chars into the wrong or into no HTML-Entities since the mappings are shifted. For example U+202F is mapped to permil; which should be U+2030. Here is my diff of the php5-cvs/ext/standard/html.c, the same modifications should be made in php-4.3, please double check --- html.c 2004-04-18 02:30:24.0 +0200 +++ html.c.fixed2004-04-19 18:44:47.949012992 +0200 @@ -114,13 +114,13 @@ /* 354 - 375 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 376 */ Yuml, /* 377 - 401 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 402 */ fnof }; @@ -130,7 +130,7 @@ circ, /* 711 - 731 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 732 */ tilde, }; @@ -147,9 +147,9 @@ sigmaf, sigma, tau, upsilon, phi, chi, psi, omega, /* 970 - 976 are not mapped */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, - thetasym, ups1h, + thetasym, upsih, NULL, NULL, NULL, - p1v + piv }; static entity_table_t ent_uni_punct[] = { @@ -158,7 +158,7 @@ thinsp, NULL, NULL, zwnj, zwj, lrm, rlm, NULL, NULL, NULL, ndash, mdash, NULL, NULL, NULL, lsquo, rsquo, sbquo, NULL, ldquo, rdquo, bdquo, - dagger, Dagger, bull, NULL, NULL, NULL, hellip, + NULL, dagger, Dagger, bull, NULL, NULL, NULL, hellip, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, permil, NULL, prime, Prime, NULL, NULL, NULL, NULL, NULL, lsaquo, rsaquo, NULL, NULL, NULL, oline, NULL, NULL, NULL, NULL, NULL, @@ -191,7 +191,7 @@ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8624 (0x21b0) */ - NULL, NULL, NULL, NULL, crarr, NULL, NULL, NULL, + NULL, NULL, NULL, NULL, NULL, crarr, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8640 (0x21c0) */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, @@ -206,9 +206,9 @@ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, /* 8704 (0x2200) */ forall, comp, part, exist, nexist, empty, NULL, nabla, - isin, notin, epsis, NULL, ni, bepsi, NULL, prod, + isin, notin, epsis, ni, NULL, bepsi, NULL, prod, /* 8720 (0x2210) */ - coprod, sum, minus, mnplus, plusdo, NULL, setmn, NULL, + coprod, sum, minus, mnplus, plusdo, NULL, setmn, lowast, compfn, NULL, radic, NULL, NULL, prop, infin, ang90, /* 8736 (0x2220) */ ang, angmsd, angsph, mid, nmid, par, npar, and, @@ -232,17 +232,19 @@ npr, nsc, sub, sup, nsub, nsup, sube, supe, /* 8840 - 8852 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, +NULL, /* 8853 */ oplus, NULL, otimes, /* 8856 - 8868 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, +NULL, /* 8869 */ perp, /* 8870 - 8901 */ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, - NULL, + NULL, /* 8901 */ sdot, /* 8902 - 8967 */ @@ -252,14 +254,13 @@ NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
#28064 [Opn-Fbk]: php crashes with big scripts
ID: 28064 Updated by: [EMAIL PROTECTED] Reported By: gross at schlund dot de -Status: Open +Status: Feedback Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 4.3.6 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. The link doesn't work. Please include the script here and make sure it's small. Previous Comments: [2004-04-19 17:49:18] gross at schlund dot de Description: Giving it a large script, PHP 4.3.6 crashes during parsing it. The stacktrace is as follows: (gdb) bt #0 0x081a5be6 in execute (op_array=0x8322c3c) at /usr/src/kundenserver/php-4.3.6/Zend/zend_execute.c:2007 #1 0x08191598 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/kundenserver/php-4.3.6/Zend/zend.c:886 #2 0x0816a933 in php_execute_script (primary_file=0xba38) at /usr/src/kundenserver/php-4.3.6/main/main.c:1731 #3 0x081a9fd3 in main (argc=2, argv=0xbab4) at /usr/src/kundenserver/php-4.3.6/sapi/cgi/cgi_main.c:1592 (gdb) You can find a core file under http://www.andigross.de/phpcrash/core.gz and the binary under http://www.andigross.de/phpcrash/phpbinary A phpinfo is under http://www.andigross.de/phpcrash/phpinfo.html the configure-line is: ./configure --with-zlib --enable-debug --enable-safe-mode=no --enable-discard-path=no --enable-track-vars --enable-force-cgi-redirect --enable-memory-limit --enable-trans-sid --enable-shmop --with-openssl --enable-xslt --with-xslt-sablot --with-dom --with-dom-xslt --with-dom-exslt The only modification to php.ini is: memory_limit = 90M; Compiler ist gcc 2.95.4. Reproduce code: --- You can find the code here: http://www.andigross.de/phpcrash/testdaten.php.txt Of curse, this is a very simple one to show the problem. The problem also occurs with more useful scripts. The application that caused the problem does something like $big_text=Huge PHP source; eval($big_text); Expected result: The script produces no output. With PHP 4.2.3 it works fine. Actual result: -- (gdb) bt #0 0x081a5be6 in execute (op_array=0x8322c3c) at /usr/src/kundenserver/php-4.3.6/Zend/zend_execute.c:2007 #1 0x08191598 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/kundenserver/php-4.3.6/Zend/zend.c:886 #2 0x0816a933 in php_execute_script (primary_file=0xba38) at /usr/src/kundenserver/php-4.3.6/main/main.c:1731 #3 0x081a9fd3 in main (argc=2, argv=0xbab4) at /usr/src/kundenserver/php-4.3.6/sapi/cgi/cgi_main.c:1592 (gdb) -- Edit this bug report at http://bugs.php.net/?id=28064edit=1
#28064 [Fbk-Opn]: php crashes with big scripts
ID: 28064 User updated by: gross at schlund dot de Reported By: gross at schlund dot de -Status: Feedback +Status: Open Bug Type: Zend Engine 2 problem Operating System: Linux PHP Version: 4.3.6 New Comment: It is not posible to offer a short script. Please try the link to the testscript again (I made a mistake while storing it): http://www.andigross.de/phpcrash/testdaten.php.txt Regardsw Andi Previous Comments: [2004-04-19 20:54:18] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. The link doesn't work. Please include the script here and make sure it's small. [2004-04-19 17:49:18] gross at schlund dot de Description: Giving it a large script, PHP 4.3.6 crashes during parsing it. The stacktrace is as follows: (gdb) bt #0 0x081a5be6 in execute (op_array=0x8322c3c) at /usr/src/kundenserver/php-4.3.6/Zend/zend_execute.c:2007 #1 0x08191598 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/kundenserver/php-4.3.6/Zend/zend.c:886 #2 0x0816a933 in php_execute_script (primary_file=0xba38) at /usr/src/kundenserver/php-4.3.6/main/main.c:1731 #3 0x081a9fd3 in main (argc=2, argv=0xbab4) at /usr/src/kundenserver/php-4.3.6/sapi/cgi/cgi_main.c:1592 (gdb) You can find a core file under http://www.andigross.de/phpcrash/core.gz and the binary under http://www.andigross.de/phpcrash/phpbinary A phpinfo is under http://www.andigross.de/phpcrash/phpinfo.html the configure-line is: ./configure --with-zlib --enable-debug --enable-safe-mode=no --enable-discard-path=no --enable-track-vars --enable-force-cgi-redirect --enable-memory-limit --enable-trans-sid --enable-shmop --with-openssl --enable-xslt --with-xslt-sablot --with-dom --with-dom-xslt --with-dom-exslt The only modification to php.ini is: memory_limit = 90M; Compiler ist gcc 2.95.4. Reproduce code: --- You can find the code here: http://www.andigross.de/phpcrash/testdaten.php.txt Of curse, this is a very simple one to show the problem. The problem also occurs with more useful scripts. The application that caused the problem does something like $big_text=Huge PHP source; eval($big_text); Expected result: The script produces no output. With PHP 4.2.3 it works fine. Actual result: -- (gdb) bt #0 0x081a5be6 in execute (op_array=0x8322c3c) at /usr/src/kundenserver/php-4.3.6/Zend/zend_execute.c:2007 #1 0x08191598 in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /usr/src/kundenserver/php-4.3.6/Zend/zend.c:886 #2 0x0816a933 in php_execute_script (primary_file=0xba38) at /usr/src/kundenserver/php-4.3.6/main/main.c:1731 #3 0x081a9fd3 in main (argc=2, argv=0xbab4) at /usr/src/kundenserver/php-4.3.6/sapi/cgi/cgi_main.c:1592 (gdb) -- Edit this bug report at http://bugs.php.net/?id=28064edit=1
#26757 [Com]: session.save_path should default to %TEMP%
ID: 26757 Comment by: LarryJAdams at comcast dot net Reported By: unknown at simplemachines dot org Status: Closed Bug Type: Session related Operating System: Windows PHP Version: 4CVS, 5CVS New Comment: I hear party favors going off somewhere... Previous Comments: [2004-03-29 16:37:05] [EMAIL PROTECTED] Fixed in CVS. The new default for save_path in upcoming releaess will be the empty string, which causes the temporary directory to be probed. Thanks for your patch. [2004-03-29 09:56:43] unknown at simplemachines dot org After I applied that patch, and changed session.save_path in my php.ini to nothing, it did indeed work without trouble. However, if I renamed php.ini to php_.ini, and tried it... it of course went back to the default /tmp - but if the default is changed to NULL without handling it, crashes will result... My purpose here is to make it easier for people, mainly, to test PHP on their own computers without running into funny errors. That means default values, because some people will never read the manual which is why I did it as I did in my patch. Thanks for replying, -[Unknown] [2004-03-29 07:25:14] [EMAIL PROTECTED] Please try this patch against latest stable CVS: http://www.php.net/~wez/session-files-fix-4.3.diff I also have an equivalent for PHP 5. This is slightly different from your patch, as it doesn't obliterate non file-based session save paths. [2004-03-29 04:58:24] unknown at simplemachines dot org I'm sorry, I just feel that with 47 votes (as of now) and even a provided working patch, a comment from a developer would be nice. Changing the category to Session related in the hopes that it not only will be looked at there, but also will receive some notice. Was previously a Feature/Change Request. Thanks again, -[Unknown] [2004-02-17 03:14:45] unknown at simplemachines dot org Maybe someone will read this if I say 4CVS, 5CVS instead of Irrelevant. 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/26757 -- Edit this bug report at http://bugs.php.net/?id=26757edit=1
#28064 [Opn-Asn]: php crashes with big scripts
ID: 28064 Updated by: [EMAIL PROTECTED] Reported By: gross at schlund dot de -Status: Open +Status: Assigned -Bug Type: Zend Engine 2 problem +Bug Type: Scripting Engine problem Operating System: Linux PHP Version: 4.3.6 -Assigned To: +Assigned To: andi New Comment: Although it didn't actually crash for me, valgrind showed the following errors: ==7233== Invalid write of size 4 ==7233==at 0x8213D75: execute (zend_execute.c:1266) ==7233== Address 0x4F1C80C8 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8213D80: execute (zend_execute.c:1266) ==7233== Address 0x4F1C80C4 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8213D87: execute (zend_execute.c:1266) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211CC5: zend_fetch_var_address (zend_execute.c:559) ==7233== Address 0x4F1C80C4 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211CCC: zend_fetch_var_address (zend_execute.c:559) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211CE4: zend_fetch_var_address (zend_execute.c:564) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211E31: zend_fetch_var_address (zend_execute.c:591) ==7233== Address 0x4F1C80C8 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211EF5: zend_fetch_var_address (zend_execute.c:611) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211F73: zend_fetch_var_address (zend_execute.c:620) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211F87: zend_fetch_var_address (zend_execute.c:620) ==7233== Address 0x4F1C80C4 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8211F8D: zend_fetch_var_address (zend_execute.c:620) ==7233== Address 0x4F1C80DC is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8211F90: zend_fetch_var_address (zend_execute.c:621) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E39: execute (zend_execute.c:1376) ==7233== Address 0x4F1C80C8 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E44: execute (zend_execute.c:1376) ==7233== Address 0x4F1C80C4 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E4E: execute (zend_execute.c:1376) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x82195BB: _get_zval_ptr (zend_execute.c:73) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x82195EF: _get_zval_ptr (zend_execute.c:75) ==7233== Address 0x4F1C80C8 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x82195F8: _get_zval_ptr (zend_execute.c:76) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E5C: execute (zend_execute.c:1378) ==7233== Address 0x4F1C80D4 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E87: execute (zend_execute.c:1378) ==7233== Address 0x4F1C80D0 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E8E: execute (zend_execute.c:1378) ==7233== Address 0x4F1C80CC is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214E98: execute (zend_execute.c:1378) ==7233== Address 0x4F1C80C8 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214EA2: execute (zend_execute.c:1378) ==7233== Address 0x4F1C80C4 is on thread 1's stack ==7233== ==7233== Invalid write of size 4 ==7233==at 0x8214EAC: execute (zend_execute.c:1378) ==7233== Address 0x4F1C80C0 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8219EF8: zend_assign_to_variable (zend_execute.c:315) ==7233== Address 0x4F1C80D4 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8219EFF: zend_assign_to_variable (zend_execute.c:315) ==7233== Address 0x4F1C80C4 is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8219B2A: _get_zval_ptr_ptr (zend_execute.c:165) ==7233== Address 0x4F1C80DC is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8219B47: _get_zval_ptr_ptr (zend_execute.c:166) ==7233== Address 0x4F1C80DC is on thread 1's stack ==7233== ==7233== Invalid read of size 4 ==7233==at 0x8219BAE: _get_zval_ptr_ptr (zend_execute.c:170) ==7233== Address 0x4F1C80DC is on thread 1's stack ==7233== ==7233== Invalid read of size 4
#28068 [NEW]: mssql_num_rows() is returning an invalid handle
From: oooacooo at yahoo dot com Operating system: Windows 2K Server; Apache 2.0.45 PHP version: 4.3.4 PHP Bug Type: MSSQL related Bug description: mssql_num_rows() is returning an invalid handle Description: When using mssql_execute() with PHP version 4.3.2 mssql_num_rows() will return 0, when no records are returned from a stored procedure. When using version 4.3.4 and above mssql_num_rows() will return supplied argument is not a valid MS SQL-result resource I tested this by running the code successfully with the php_mssql.dll which ships with 4.3.2 and then swapped php_mssql.dll with the one that ships with 4.3.4 and restarted Apache. Reproduce code: --- $validEpisode = mssql_query(spValidateEpisodeDate . $AccountID . ,' . $inputVisitDate . ',$db); if(mssql_num_rows($validEpisode) 0) { $row = mssql_fetch_object($validEpisode); if($row-Episode_ID == ) $errorMsg = There is no episode for this account that covers the visit date entered.br . $errorMsg; else $EpisodeID = $row-Episode_ID; } Expected result: If no records are found I would expect if(mssql_num_rows($validEpisode) 0) to return true. Actual result: -- if(mssql_num_rows($validEpisode) 0) throws an error supplied argument is not a valid MS SQL-result resource -- Edit bug report at http://bugs.php.net/?id=28068edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28068r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28068r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28068r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28068r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28068r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28068r=needscript Try newer version: http://bugs.php.net/fix.php?id=28068r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28068r=support Expected behavior: http://bugs.php.net/fix.php?id=28068r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28068r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28068r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28068r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28068r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28068r=dst IIS Stability: http://bugs.php.net/fix.php?id=28068r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28068r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28068r=float
#28062 [Fbk-Opn]: gettext produces ? instead of german special chars
ID: 28062 User updated by: soletan at toxa dot de Reported By: soletan at toxa dot de -Status: Feedback +Status: Open Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: For the moment forget about that. I tested around with it a bit and everything's working fine right now. I come back, if it re-appears. Previous Comments: [2004-04-19 20:30:13] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-04-19 17:08:26] soletan at toxa dot de BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#28062 [Opn-Bgs]: gettext produces ? instead of german special chars
ID: 28062 Updated by: [EMAIL PROTECTED] Reported By: soletan at toxa dot de -Status: Open +Status: Bogus Bug Type: Gettext related Operating System: SuSE Linux 7.2 PHP Version: 4.3.6 New Comment: Okay. Reopen this if that happens. Previous Comments: [2004-04-19 22:04:24] soletan at toxa dot de For the moment forget about that. I tested around with it a bit and everything's working fine right now. I come back, if it re-appears. [2004-04-19 20:30:13] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try avoid embedding huge scripts into the report. [2004-04-19 17:08:26] soletan at toxa dot de BTW: here's my config.nice: #! /bin/sh # # Created by configure './configure' \ '--with-apxs2=/usr/local/httpd/bin/apxs' \ '--enable-discard-path' \ '--with-debug' \ '--enable-safe-mode' \ '--with-exec-dir' \ '--with-openssl' \ '--enable-sigchild' \ '--enable-maqic-quotes' \ '--enable-libgcc' \ '--with-zlib' \ '--enable-bcmath' \ '--with-bz2' \ '--enable-calendar' \ '--with-db3=/usr/local/BerkeleyDB4.1' \ '--enable-dio' \ '--enable-ftp' \ '--with-gd' \ '--enable-gd-native-ttf' \ '--enable-dl' \ '--with-ttf' \ '--with-t1lib' \ '--with-jpeg-dir' \ '--with-png-dir' \ '--with-gettext' \ '--with-imap' \ '--with-imap-ssl' \ '--enable-mbstring' \ '--enable-mbregex' \ '--with-mcrypt' \ '--with-mysql=/usr/local/mysql' \ '--with-tiff-dir' \ '--enable-sockets' \ '--with-regex' \ '--enable-tokenizer' \ '--with-xmlrpc' \ '--with-ming=/usr' \ $@ [2004-04-19 17:05:04] soletan at toxa dot de Description: Hi, I've upgraded from 4.3.5 to 4.3.6 immediately to keep as bug-free as possible. Now I detected some trouble using gettext. I use it to translate hardcoded english strings in script to be translated into german versions. The latter ones contain special characters which are part of ISO-8859-1. These have been displayed properly under 4.3.5. Now I get questions marks instead. It must be a problem up to PHP, since I can switch back to the previously installed 4.3.5 to get working again. Both versions are compiled using identical config.nice-scripts. I grepped the Changelog and didn't found any notice on gettext. So what's up with that?? I won't use that safe (bug-fixed) version 4.3.6, since many of the sites I'm hosting rely on gettext translation. Thanks for your help in advance, best regards. Thomas Urban -- Edit this bug report at http://bugs.php.net/?id=28062edit=1
#28065 [Opn-Bgs]: resource limits do not work
ID: 28065 Updated by: [EMAIL PROTECTED] Reported By: floeff at arcor dot de -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Linux 2.4.26 PHP Version: 4.3.6 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: [2004-04-19 19:49:35] floeff at arcor dot de Description: Maybe I misunderstand something, but for me it seems that the resource limits do not work. In my php.ini, I set max_execution_time = 10 max_input_time = 10 which - to my understanding - should limit executing time for scripts to 10 seconds. I have PHP running as CGI with Apache 2.0.49 on Linux 2.4.26 here, and with a hughe PHP file involving some diagram creation, I can kill the machine if I re-load the script for five seconds continuously. It soaks up all my memory and runs for nearly a minute. What could be wrong in here? If you need more information, please let me know. Thanks! -- Edit this bug report at http://bugs.php.net/?id=28065edit=1
#26771 [Com]: register_tick_funtions crashes apache2 child process
ID: 26771 Comment by: banterbubba at yahoo dot com Reported By: info at tphnet dot com Status: Verified Bug Type: Apache2 related Operating System: * (ZTS only!) PHP Version: 4CVS, 5CVS (2004-02-25) New Comment: Any resolution? I was thinking that it might be Apache/PHP on Windows. I have another developer who runs the same config as I do, but on Linux and has no problems. Is is a Windows conflict? We may just switch the OS... Previous Comments: [2004-04-18 13:07:22] cpuidle at gmx dot de Similiar Issue, but not register_ticks-related: [Sun Apr 18 12:56:48 2004] [notice] Parent: child process exited with status 128 -- Restarting. [Sun Apr 18 12:56:49 2004] [notice] Parent: Created child process 3824 [Sun Apr 18 12:56:49 2004] [notice] Child 3824: Child process is running [Sun Apr 18 12:56:49 2004] [notice] Child 3824: Acquired the start mutex. [Sun Apr 18 12:56:49 2004] [notice] Child 3824: Starting 64 worker threads. Happening e.h. with osCommerce and custom apps. Not always reproducible... [2004-01-02 19:23:33] info at tphnet dot com Description: While searching the bug database I found some similar problems, but all were suspended. I wasn't sure if it was useful to reply to one of those (Most recent one: http://bugs.php.net/bug.php?id=26286). Well anyways, here goes: The problem is very simple. I just copy and paste the 'tick' example from the php manual into a new php file an try to execute it on my apache2 server. The apache child process crashes, restarts, crashes, restarts and eventually just stops restarting. When I comment out the line 'register_tick_function', everyting works just fine. Also, when I start the file from the CLI version of PHP it is executed without any problems. I'm using PHP 4.3.4 and Apache 2.0.48 (in conjunction with php4apache2.dll). Reproduce code: --- http://nl.php.net/manual/en/control-structures.declare.php See Example 11-1 Actual result: -- [Sat Jan 03 01:11:04 2004] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Sat Jan 03 01:11:04 2004] [notice] Parent: Created child process 3036 [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Child process is running [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Acquired the start mutex. [Sat Jan 03 01:11:04 2004] [notice] Child 3036: Starting 250 worker threads. Small snippit from my apache2 error.log. It's filled with the above lines, the status code is the same for every restart. -- Edit this bug report at http://bugs.php.net/?id=26771edit=1
#24053 [Com]: include issues spurious stream warning that clutters up the page ...
ID: 24053 Comment by: coolavin at dedanaan dot com Reported By: jphey at netdoor dot com Status: Closed Bug Type: Scripting Engine problem Operating System: Linux 2.4.20 PHP Version: 4.3.2 New Comment: I'm still getting this same error in php includes, so apparently, it still hasn't been fixed in the latest releases. Using @include seems to work, suppressing the error message, but it's not a solution, it just masks the problem. A fix needs to be applied to the next update. Previous Comments: [2004-04-10 14:00:31] gunner at muchthesame dot com I just moved my site to a host running PHP 4.3.4 and I am now getting this same message. I am including a file that is created on another site of mine and therefore have to use the full url in the include. The include works fine, but I do get this error about seeking even though I am not seeking. If I suppress the error it seems to be okay but I obviously shouldn't have to do this. [2004-02-12 14:01:05] [EMAIL PROTECTED] That bug is fixed in the Zend Optimizer 2.5 (http://www.zend.com/store/free_download.php?pid=13) [2004-02-03 19:52:37] rgraham at star-fleet dot org Running 4.3.4 with Zend installed same issue, seems this states it's listed at 4.3.2, i thought i'd bring it up. Even if it is a Zend Issue with Php doesn't it still fall into PHP's bug list? Seems it wasn't there before and now it is? The @include works because @ = supress the error messeges but it's annoying. [2004-01-25 12:15:55] webmaster at nowproduction dot com I had the same error Warning: main(): stream does not support seeking You can include remote files with adding an '@'. This code should work: ?php @include('http://remoteurl.com/somefile.html'); ? [2004-01-17 18:20:22] [EMAIL PROTECTED] Not PHP but Zend Optimizer bug - bogus. 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/24053 -- Edit this bug report at http://bugs.php.net/?id=24053edit=1
#28069 [NEW]: The extension load is broken
From: plumber at gnu-darwin dot org Operating system: darwin PHP version: 4.3.5 PHP Bug Type: Dynamic loading Bug description: The extension load is broken Description: The extension load is broken dl too and return a empty result gdb backtrace gives nothing Warning: dl(): Unable to load dynamic library /pathext/ some.so (null) from dl and php.ini the same report as made even if the .so file are not in etx dir I've test from 4.3.3 src and all is ok Reproduce code: --- from ini file php -m PHP Warning: Unknown(): Unable to load dynamic library '/pathext/ some.so' - (null) in Unknown on line 0 if i remove the so file from exte dir it's the same -- Edit bug report at http://bugs.php.net/?id=28069edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28069r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28069r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28069r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28069r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28069r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28069r=needscript Try newer version: http://bugs.php.net/fix.php?id=28069r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28069r=support Expected behavior: http://bugs.php.net/fix.php?id=28069r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28069r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28069r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28069r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28069r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28069r=dst IIS Stability: http://bugs.php.net/fix.php?id=28069r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28069r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28069r=float
#28031 [Fbk-Opn]: Results of comparison differ by Windows and unix.
ID: 28031 User updated by: yiwakiri at st dot rim dot or dot jp Reported By: yiwakiri at st dot rim dot or dot jp -Status: Feedback +Status: Open Bug Type: Scripting Engine problem Operating System: Windows 2k, XP, 98 PHP Version: 4.3.6, 4.3.7-dev New Comment: Hi, wez Why does it deceive as a problem of strtol()? Although it is comparison of STRING and STRING, Is it a problem if strtol() is called? In Unix Like OS, it is not thought that strtol() is called. Previous Comments: [2004-04-19 15:31:14] [EMAIL PROTECTED] Most likely due to strtol() implementation in the M$ libc. Try using the === operator or strcmp() instead. (strings that look like numbers might be compared as numbers using the == operator) [2004-04-19 15:11:06] postings-php-bug at hans-spath dot de D:\PHPver Microsoft Windows XP [Version 5.1.2600] D:\PHPlastest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 19 2004 14:16:52) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies D:\PHP5.0.0RC1\php -v PHP 5.0.0RC1 (cli) (built: Mar 18 2004 18:20:03) Copyright (c) 1997-2004 The PHP Group Zend Engine v2.0.0RC1, Copyright (c) 1998-2004 Zend Technologies D:\PHPlastest\php-cli test\string_comparison.php 0x1 0x2 ( '0x1' == '0x2' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0d2 ( '0d1' == '0d2' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php 0d1x 0d2x ( '0d1x' == '0d2x' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0dx1 ( '0d1' == '0dx1' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0xd1 ( '0d1' == '0xd1' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php 0d1 0xd2 ( '0d1' == '0xd2' ) = bool(true) D:\PHPlastest\php-cli test\string_comparison.php d1 xd2 ( 'd1' == 'xd2' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php d1 xd1 ( 'd1' == 'xd1' ) = bool(false) D:\PHPlastest\php-cli test\string_comparison.php 0e9 0xe4 ( '0e9' == '0xe4' ) = bool(true) D:\PHP5.0.0RC1\php test\string_comparison.php 0e9 0xe4 ( '0e9' == '0xe4' ) = bool(true) I wonder why this hasn't been discovered before. All my currently installed (win32) versions (4.3.[2346], 5.0.0RC1) suffer from this problem. [2004-04-19 10:34:31] yiwakiri at st dot rim dot or dot jp Hmm, I'm confused. Windows(2k, XP 98): C:\php -r var_dump('0d1' == '0d2'); (1) bool(true) C:\php -r var_dump('00d1' == '00d2'); (2) bool(false) C:\php -r var_dump('0a1' == '0a2'); (3) bool(false) Unix like OS: % php -r var_dump('0d1' == '0d2'); (4) bool(false) % php -r var_dump('0a1' == '0a2'); (5) bool(false) Only (1) does not bring a result to expect. [2004-04-19 02:24:43] yiwakiri at st dot rim dot or dot jp A snapshot is also the same behavior. C:\php -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 10:21:09) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2003 Zend Technologies C:\php -r var_dump(('0d1' == '0d2')); bool(true) [2004-04-17 15:24:52] postings-php-bug at hans-spath dot de [Windows XP Pro SP1] D:\PHP4.3.2\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.3\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.4\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHP4.3.6\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -r var_dump(('0d1' == '0d2')); bool(true) D:\PHPphp4-win32-STABLE-latest\php-cli -v PHP 4.3.7-dev (cli) (built: Apr 17 2004 14:18:37) Copyright (c) 1997-2004 The PHP Group Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies [Linux 2.6.5] [EMAIL PROTECTED]:~/compile/php-4.3.6% sapi/cli/php -r var_dump(('0d1' == '0d2')); bool(false) 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/28031 -- Edit this bug report at http://bugs.php.net/?id=28031edit=1
#27889 [Com]: Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0
ID: 27889 Comment by: gus at pbx dot org Reported By: mike at zrcalo dot si Status: No Feedback Bug Type: Unknown/Other Function Operating System: WIN32 PHP Version: 4CVS-2004-04-06 (stable) New Comment: I am experiencing the same issue intermitently on a Win2k3 Server running several builds of php from 4.3.4 on up.. the only way to correct is with a server reset.. occurs after about ~10 hours or 500,000 hits. Previous Comments: [2004-04-12 17:55:01] [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. [2004-04-07 05:00:03] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to Open. Thank you for your interest in PHP. [2004-04-06 11:30:37] mike at zrcalo dot si Description: Hi ! I'm running todays CVS snapshot. WIN32 (2000 and XP) with IIS And still having problems: Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0 Reproduce code: --- any ! -- Edit this bug report at http://bugs.php.net/?id=27889edit=1
#28070 [NEW]: Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0
From: gus at pbx dot org Operating system: Windows 2003 Server PHP version: 4.3.5 PHP Bug Type: Unknown/Other Function Bug description: Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0 Description: Warning: Unknown list entry type in request shutdown (2) in Unknown on line 0 diff's in my php.ini from -dist asp_tags = On output_buffering = On register_globals = On post_max_size = 32M upload_max_filesize = 32M SMTP = *censored* smtp_port = 25 sendmail_from = [EMAIL PROTECTED] odbc.allow_persistent = Off mysql.allow_persistent = Off session.save_path = C:\php\sessions Reproduce code: --- even files without a ? ? produce these results.. an empty file that is being parsed by php will exhibit this behavior. Expected result: I should see anything at all -- Edit bug report at http://bugs.php.net/?id=28070edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28070r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28070r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28070r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28070r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28070r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28070r=needscript Try newer version: http://bugs.php.net/fix.php?id=28070r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28070r=support Expected behavior: http://bugs.php.net/fix.php?id=28070r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28070r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28070r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28070r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28070r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28070r=dst IIS Stability: http://bugs.php.net/fix.php?id=28070r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28070r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28070r=float
#28071 [NEW]: Flag MYSQL_CLIENT_COMPRESS not working
From: phpb at lwnetwork dot com Operating system: Linux RedHat PHP version: 4.3.4 PHP Bug Type: MySQL related Bug description: Flag MYSQL_CLIENT_COMPRESS not working Description: Tested with: PHP 4.3.4 / MySQL 4.0.18 I have been testing MYSQL_CLIENT_COMPRESS flag in mysql_connect funcion and compressed protocol is not used, data is transfered from client/server in no compressed way. mytest.php : -- $mycmsconn=mysql_connect($dbip,$dblogin,$dbpass,false,MYSQL_CLIENT _COMPRESS); $mycmsdataquery=SELECT * FROM foo; $mycmsdataresult = mysql_query($mycmsdataquery,$mycmsconn); $mycmsdatarow = mysql_fetch_array($mycmsdataresult); --- I test versus my firewall : 29 2486 3685K ACCEPT tcp -- any any anywhere anywhere state ESTABLISHED tcp spt:mysql 29 1249 65053 ACCEPT tcp -- any any anywhere anywhere state NEW,ESTABLISHED tcp dpt:mysql then i restart my firewall and do : mytest.php : $mycmsconn=mysql_connect($dbip,$dblogin,$dbpass,false,MYSQL_CLIENT_COMPRESS); $mycmsdataquery=SELECT * FROM foo; $mycmsdataresult = mysql_query($mycmsdataquery,$mycmsconn); $mycmsdatarow = mysql_fetch_array($mycmsdataresult); /etc/init.d/firewall.sh status | grep mysql 29 2486 3684K ACCEPT tcp -- any any anywhere anywhere state ESTABLISHED tcp spt:mysql 29 1249 65053 ACCEPT tcp -- any any anywhere anywhere state NEW,ESTABLISHED tcp dpt:mysql (needless to say that the database server is on a remote host) (Info copied from Sebastian, as he got same problem as me and tested with a firewall) Regards, Alex -- Edit bug report at http://bugs.php.net/?id=28071edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28071r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28071r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28071r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28071r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28071r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28071r=needscript Try newer version: http://bugs.php.net/fix.php?id=28071r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28071r=support Expected behavior: http://bugs.php.net/fix.php?id=28071r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28071r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28071r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28071r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28071r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28071r=dst IIS Stability: http://bugs.php.net/fix.php?id=28071r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28071r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28071r=float
#9673 [Com]: Relative paths in require(), require_once(), include(), include_once()
ID: 9673 Comment by: cameron at prolifique dot com Reported By: vvo at geocities dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: RedHat Linux PHP Version: 4.3.2 New Comment: No, not necessarily a bug...just a very illogical and painful behavior for the include require functions when using relative paths. It's like having a compass that points north in relation to wherever you started your trip, not where you're standing now. Not much use. If you knew where you started, why would you need a compass? If a relative include path isn't relative to the script calling it, what's the use of a relative include path? I never expected that the hardest part of moving from ASP to PHP would be include file references, but considering this behavior (still happening in 4.3.4), it appears to be. Luckily, there appears to be a workaround: [2 Sep 2003 8:48am CEST] mathieu dot messe at urssaf dot fr A workaround found at http://fr.php.net/manual/fr/function.include.php is to use require(dirname(__FILE__) . \..\second.php); Previous Comments: [2004-04-05 08:50:44] [EMAIL PROTECTED] RTFM. There is no bug here. [2004-04-02 16:03:57] chapwest at hotmail dot com I have no idea what this means in regard to my sight. Michael [2004-04-01 18:36:07] [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 [2004-04-01 18:32:42] vvo at geocities dot com setting version to 4.3.2 [2004-04-01 18:31:04] vvo at geocities dot com Not clear to me why the issue status was changed to Bogus. As far as I can tell multiple people have same 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/9673 -- Edit this bug report at http://bugs.php.net/?id=9673edit=1
#28072 [NEW]: static array with some constant keys will be incorrectly ordered
From: pages at inrp dot fr Operating system: Fedora 2 test 2 PHP version: 4.3.6 PHP Bug Type: Scripting Engine problem Bug description: static array with some constant keys will be incorrectly ordered Description: Initialising a static associative array using constants as keys will give an incorrectly ordered array. Apparently, elements with constant keys will always appear AFTER elements without constant keys. Reproduce code: --- ?php define(FIRST_KEY, a); define(THIRD_KEY, c); function test() { static $arr = array( FIRST_KEY = 111, b = 222, THIRD_KEY = 333, d = 444 ); print_r($arr); } test(); ? Expected result: Array ( [a] = 111 [b] = 222 [c] = 333 [d] = 444 ) Actual result: -- Array ( [b] = 222 [d] = 444 [a] = 111 [c] = 333 ) -- Edit bug report at http://bugs.php.net/?id=28072edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28072r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28072r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28072r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28072r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28072r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28072r=needscript Try newer version: http://bugs.php.net/fix.php?id=28072r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28072r=support Expected behavior: http://bugs.php.net/fix.php?id=28072r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28072r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28072r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28072r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28072r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28072r=dst IIS Stability: http://bugs.php.net/fix.php?id=28072r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28072r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28072r=float
#25827 [Com]: PHP LDAP queries against Active Directory return incomplete arrays
ID: 25827 Comment by: info at dbnet dot com dot au Reported By: pennington at rhodes dot edu Status: Bogus Bug Type: LDAP related Operating System: Windows 2000 PHP Version: 4.3.3 New Comment: Hi, I'm seeing your post 6 months too late, but let me alert you to something that I found after similar grief with AD. It turns out that ONE of the AD group memberships, (in our case 'Domain Users', in your case perhaps one of the others), is handled differently in AD. It will be the one listed as the default group when you look up a user in any AD admin tool, and incredibly it just doesn't get fed back to you by AD when you ask for the memberOf attribute using any standard LDAP technique. I vaguely remember an MSDN KB article describing an astonishingly complex workaround for victims of this behaviour using ADSI.. sorry I have no link to it now. Our solution was to accept that the so-called default group for each user is just not treated properly by AD in its LDAP interface. It's a special case. Previous Comments: [2003-10-14 19:56:48] [EMAIL PROTECTED] We only wrap around the OpenLDAP libraries. So it's definately not PHP bug - bogus. You should report this to the openldap folks, they propably already know about it or are very willing to fix it if it's not already fixed. Please let us know what the response is so we can possibly update the used openldap libraries in the win32 binaries build. [2003-10-14 14:08:51] pennington at rhodes dot edu OK, you're right, after a few minutes, I found an ldapsearch command that would work: ldapsearch -x -b CN=_some_user_,CN=Users,DC=rhodes,DC=edu -D CN=_search_auth_user_,CN=Users,DC=rhodes,DC=edu -H ldap://someserver.rhodes.edu -W The memberof attribute results look like this: memberOf: CN=STAFF_DL,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Planning,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACSTAFF,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Council,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=PRESIDENT,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=FACTBOOK,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=INFO_SERVICES,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=CABINET,OU=Security Groups,OU=Groups,DC=rhodes,DC=edu memberOf: CN=Senior2006,OU=Distribution Lists,OU=Groups,DC=rhodes,DC=edu memberOf: CN=NT Users,CN=Users,DC=rhodes,DC=edu memberOf: CN=NTSETUP,CN=Users,DC=rhodes,DC=edu memberOf: CN=Domain Users,CN=Users,DC=rhodes,DC=edu Again, only 12 results were returned rather than the 13 that exist there in Active Directory. However, I've started doing a count based on attributes found by ldapsearch and Softerra's LDAPBrowser (which I think also uses openldap) and found that people missing an attibute value in ldapsearch were missing the same value in LDAPBrowser. Anyway, I think what we are down to is one of two possibilities: 1) OpenLDAP's search tool is not receiving all attribute values for a particular search; or 2) Active Directory is not supplying the missing value when queried for it using LDAP but does reply properly when Microsoft admin tools are used. I guess we could solve this if someone knows a good, freely-available, non-openldap-based LDAP search utility. Regardless, this doesn't look like a PHP bug per se, thought it could be a OpenLDAP bug that has found its way into PHP with the rest of the OpenLDAP code... [2003-10-14 12:26:58] [EMAIL PROTECTED] There is no kerberos support in PHP ldap either, and that partially works, so why would you need it with the command line binary? [2003-10-14 11:59:27] pennington at rhodes dot edu It appears that ldapsearch at that URL is not compiled with Kerberos support, which may be required to search Active Directory LDAP servers. I'm still doing research, however... D:\openldap\binldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -k ldapsearch: not compiled with Kerberos support I tried it with just SASL and that wasn't appreciated either: D:\openldap\binldapsearch -LLL -H ldap://someserver.rhodes.edu -P 3 -D pennington -I ldap_sasl_interactive_bind_s: Unknown authentication method (86) additional info: SASL(-4): no mechanism available: Unable to find a call back: 2 Can anyone verify that Kerberos support is required to search Active Directory LDAP servers? Is anyone using the OpenLDAP ldapsearch program to search Active Directory LDAP servers? If so, what kind of command should I use to get ldapsearch to search Active Directory? I am using CN=Users,DC=rhodes,DC=edu for the Base DN, CN=_search_value_ for the name to