#28240 [Opn->Bgs]: class member assigment without declaration defines new member
ID: 28240 Updated by: [EMAIL PROTECTED] Reported By: php at jort dot net -Status: Open +Status: Bogus Bug Type: Class/Object related Operating System: Win2000 Pro PHP Version: 5.0.0RC2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php . Previous Comments: [2004-05-04 05:51:30] phpbug at gb404 dot com It is totally normal. As far as I can remember, PHP never needed to declare a variable before using it. [2004-04-30 22:30:09] php at jort dot net Description: When you assign a value to a class member that was not declared the system defines a new class member. I'm not sure this is a feature or a bug. I would expect an error or at least a notice or a warning. Reproduce code: --- foo = "test"; } } $bar = new foo(); print $bar->foo; ?> Expected result: Notice/Warning/Error Actual result: -- test -- Edit this bug report at http://bugs.php.net/?id=28240&edit=1
#28270 [Opn->Bgs]: any call to error_log(...) crashes - revisited
ID: 28270 Updated by: [EMAIL PROTECTED] Reported By: leha2 at mail dot ru -Status: Open +Status: Bogus Bug Type: Reproducible crash Operating System: Win32 (in my case WinXPPro+SP1) PHP Version: 4.3.6 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. Reopen the old report, NEVER refile an existing bug please. Previous Comments: [2004-05-04 07:30:22] leha2 at mail dot ru Description: This report is just a reminder about "Bug #16787any call to error_log(...) crashes", that was posted to bugtrace two years ago. I've added a comment there with description of troubles I've encounter after migrating from PHP v.4.1.0 to 4.3.5, and then to 4.3.6. Quick URL for viewing that post is: http://bugs.php.net/bug.php?id=16787 Thanks for help in advance, LeXa2 Reproduce code: --- Here is a fragment of modified FastTemplate class, where the trouble was first encountered: function show_unknowns ($Line) { $unknown = array(); if (ereg("({[A-Z0-9_]+})",$Line,$unknown)) { $UnkVar = $unknown[0]; if(!(empty($UnkVar))) { this is the trouble line => @error_log("[FastTemplate] Warning: no value found for variable: $UnkVar ",0); } } }// end show_unknowns() Expected result: just to log error as usual Actual result: -- PHP stalls and I have to kill it's process via Task Manager. After that I got 500 Internal Server Error (not surprising, really ;) -- Edit this bug report at http://bugs.php.net/?id=28270&edit=1
#28175 [Com]: compile failure
ID: 28175 Comment by: paul dot gardiner at barleychalu dot co dot uk Reported By: martin dot kenney at i2net dot com Status: Feedback Bug Type: Compile Failure Operating System: slackware 9.1, 2.4.25 kernel PHP Version: 4.3.6 New Comment: Iliaa, I looked at your patch to gdft.c and modified it as there was a ')' missing from the end of the main line and it needed repeating further down in the file. Once this was applied it compiled OK :) I've included a basic diff below. Thanks, - Paul - 476c476 < #if (defined(FREETYPE_MAJOR) && (FREETYPE_MAJOR >=2 ) && (FREETYPE_MINOR >= 1)) --- > #if (defined(FREETYPE_MAJOR) && ((FREETYPE_MAJOR == 2 && ((FREETYPE_MINOR == 1 && FREETYPE_PATCH >= 3) || FREETYPE_MINOR > 1) || FREETYPE_MAJOR > 2))) 485c485 < #endif /* Freetype 2.1 or better */ --- > #endif /* Freetype 2.1.3 or better */ 973c973 < #if (defined(FREETYPE_MAJOR) && (FREETYPE_MAJOR >=2 ) && (FREETYPE_MINOR >= 1)) --- > #if (defined(FREETYPE_MAJOR) && ((FREETYPE_MAJOR == 2 && ((FREETYPE_MINOR == 1 && FREETYPE_PATCH >= 3) || FREETYPE_MINOR > 1) || FREETYPE_MAJOR > 2))) 983c983 < #endif /* Freetype 2.1 or better */ --- > #endif /* Freetype 2.1.3 or better */ Previous Comments: [2004-04-29 15:25:13] [EMAIL PROTECTED] Try the following patch: http://ilia.ws/stuff/gd.txt [2004-04-28 14:37:01] paul dot gardiner at barleychalu dot co dot uk I get the same on redhat 8. Removing the --with-freetype-dir=/usr from configure results in a successful compile. It used to work on 4.3.5. I'd guess it would probably be the upgrade of the bundled gd. Not had time to take a proper look though. [2004-04-27 03:53:07] martin dot kenney at i2net dot com Description: ./configure --prefix=/usr/php --with-apxs=/usr/sbin/apxs --with-openssl=/usr --enable-sigchild --enable-libgcc --enable-bcmath --with-bz2=/usr --enable-calendar --enable-ctype --enable-dba=shared --enable-gdbm=/usr --enable-ndbm=/usr --enable-db2=/usr --enable-db3=/usr --enable-dbase --with-zlib --enable-ftp --with-mhash=/usr/local --with-gd --with-jpeg-dir=/usr --with-png-dir=/usr --with-mysql=/usr/local --with-pgsql=/usr/local --enable-shmop --enable-sockets --enable-inline-optimization --enable-sysvsem --enable-sysvshm --enable-wddx --with-gnu-ld --with-gettext --with-freetype-dir=/usr --enable-gd-native-ttf when making this is where error starts /bin/sh /usr/local/src/servers/php-4.3.6/libtool --silent --preserve-dup-deps --mode=compile gcc -I/usr/local/src/servers/php-4.3.6/ext/gd/libgd -DHAVE_LIBPNG -DHAVE_LIBJPEG -DHAVE_LIBFREETYPE -Iext/gd/ -I/usr/local/src/servers/php-4.3.6/ext/gd/ -DPHP_ATOM_INC -I/usr/local/src/servers/php-4.3.6/include -I/usr/local/src/servers/php-4.3.6/main -I/usr/local/src/servers/php-4.3.6 -I/usr/local/src/servers/php-4.3.6/Zend -I/usr/include/freetype2 -I/usr/local/include -I/usr/local/include/mysql -I/usr/local/src/servers/php-4.3.6/ext/xml/expat -I/usr/local/src/servers/php-4.3.6/TSRM -g -O2 -prefer-pic -c /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c -o ext/gd/libgd/gdft.lo /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c: In function `fontFetch': /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:478: `FT_ENCODING_MS_SYMBOL' undeclared (first use in this function) /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:478: (Each undeclared identifier is reported only once /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:478: for each function it appears in.) /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:479: `FT_ENCODING_ADOBE_CUSTOM' undeclared (first use in this function) /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:479: `FT_ENCODING_ADOBE_STANDARD' undeclared (first use in this function) /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c: In function `gdImageStringFTEx': /usr/local/src/servers/php-4.3.6/ext/gd/libgd/gdft.c:974: `FT_ENCODING_MS_SYMBOL' undeclared (first use in this function) make: *** [ext/gd/libgd/gdft.lo] Error 1 version of gd: gd-2.0.3 ./configure --prefix /usr tried going back to php-4.3.4 and compiles fine with same ./configure listed above -- Edit this bug report at http://bugs.php.net/?id=28175&edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286 Comment by: gaida at gmxpro dot net 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: Apache: Apache 2.0.49 (Win32) PHP : PHP 4.3.6 MySQL : MySQL 4.0.14-NT OS: Windows XP Pro SP1 Server crashes only (Parent: child process exited with status 3221225477 -- Restarting.) when Turck MMCache (version 2.4.6 for php 4.3.6) is enabled and JPGraph generated images were accessed. If mmcache is disabled in php.ini (mmcache.enable="0") everythings runs a lot slower but at least without crashes. Previous Comments: [2004-05-01 06:38:56] peter at helpnet dot com dot au I get both Parent: child process exited with status 3221225477 and Parent: child process exited with status 1073807364 alternating in a seemingly random order. Win2000. Apache 2 2.0.47. I am about to try 2.0.49. PHP 4.3.4 then 4.3.6. I upgraded to 4.3.6 but it did not solve the problem. I get the error in code using XML but not MySQL. The error first occurred when I opened lots of classes and created lots of objects. Each element in a small XML file became an object which in turn may include other objects. Some objects are from classes extending classes. I figured it might be a memory problem so extended memory from 8MB to 18 MB. That did not change anything. My next guess was a file open resource problem. Some of the objects read directories to count input files. I removed some of the files to decrease files within a directory. That did not work. I can understand that as I have had 10 or more files in one directory and the script has worked. My tests are currently using less than 100 files per directory. I removed some of the directories but that did not stop the problem. I removed some of the lower level directories and that stopped the problem for a while. There appears to be a resource issue when working down through a directory tree several levels. I added print statements to trace the execution. Adding lots of print statements made the problem happen faster but on some occasions I have used many more print statements without this problem. The print statements did not always print up to where the code stopped so I added file logging. Opening output files made the problem worse. That reinforces the idea that there is a resource problem. I set the log code to open, write to, and close a log file. At first that worked. As soon as I run xml_parser_free, the file logging stops. The file log code can write the next message but no more. After that it can open and write to the file but not close the file. This error occurs with modpython and some other Apache stuff. I think we are hitting a resource limit within Apache. Neither PHP nor Apache has code to detect the problem. [2004-04-19 08:39:10] cpuidle at gmx dot de 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 [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? 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/26286 -- Edit this bug report at http://bugs.php.net/?id=26286&edit=1
#28220 [Opn]: mb_strwidth() returns wrong width values for some Hangul characters.
ID: 28220 User updated by: martin dot t dot kutschker at blackbox dot net Reported By: martin dot t dot kutschker at blackbox dot net Status: Open Bug Type:mbstring related PHP Version: Irrelevant New Comment: I rechecked EastAsianWidth and have found two more wide chars and noticed that the range 2E80..4DB5 is in fact split by a single half-width filler space char 1100..115F Hangul Choseong 2329LEFT-POINTING ANGLE BRACKET 232ARIGHT-POINTING ANGLE BRACKET 2E80-303E CJK and Kangxi radicals, ideographic chars 3041-4DB5 Hiragana, Katakana, Bopomofo and Hangul letters 4E00..D7A3 CJK ideographs, Yi and Hangul syllables F900..FA6A CJK compatibiliy ideographs FE30..FE6B presentation forms, punctuations, etc. FF01..FF60 full-width Latin letters FFE0FULLWIDTH CENT SIGN FFE1FULLWIDTH POUND SIGN FFE2FULLWIDTH NOT SIGN FFE3FULLWIDTH MACRON FFE4FULLWIDTH BROKEN BAR FFE5FULLWIDTH YEN SIGN FFE6FULLWIDTH WON SIGN Please also note that Unicode knows about "ambigous" (A) chars. See quotes from http://www.unicode.org/reports/tr11/ "In a broad sense, wide characters include W, F, and A (when in EA context), while narrow characters include N, Na, H, and A (when not in EA context)." "Ambiguous characters behave like wide or narrow characters depending on context (language tag, script identification, associated font, source of data, or explicit markup; all can provide the context). If the context cannot be established reliably they should be treated as narrow characters by default." So mb_strwidth could try to auto-detect the context (eg. by locale) or have an optional east-asian context argument. Previous Comments: [2004-05-01 15:30:09] [EMAIL PROTECTED] This is a valid bug. # thanks Nuno. [2004-04-29 18:48:17] martin dot t dot kutschker at blackbox dot net Description: The table describing the width of the characters is wrong if you compare it with the table for Unicode 4.0: http://www.unicode.org/Public/UNIDATA/EastAsianWidth.txt For the BMP the wide/full-width chars are: 1100..115F Hangul Choseong 2E80..4DB5 CJK radicals and CJK Ideograph Extension A 4E00..D7A3 CJK Ideographs, Yi syll. and Hangul syll. F900..FA6A CJK compatibiliy ideographs FE30..FE6B presentation forms, punctuations, etc. FF01..FF60 full-width Latin letters FFE0FULLWIDTH CENT SIGN FFE1FULLWIDTH POUND SIGN FFE2FULLWIDTH NOT SIGN FFE3FULLWIDTH MACRON FFE4FULLWIDTH BROKEN BAR FFE5FULLWIDTH YEN SIGN FFE6FULLWIDTH WON SIGN I didn't check what the actual implementation does, but the docs are certainly wrong (if they mean Unicoe codepoints). -- Edit this bug report at http://bugs.php.net/?id=28220&edit=1
#28265 [Bgs->Opn]: Realpath, getcwd not returning true pathname
ID: 28265 User updated by: csaba at alum dot mit dot edu Reported By: csaba at alum dot mit dot edu -Status: Bogus +Status: Open Bug Type: Directory function related Operating System: Windows - all -PHP Version: 5CVS-2004-05-03 (dev) +PHP Version: 5CVS-2004-05-04 (dev) New Comment: This problem is still happening on the latest snapshot of PHP I just downloaded today (2004-May-04). If I run the code I included below on my Win 2000 Pro system, I get three sections, each with distinct capitalization (mixed, lower case, upper case) of the drive letter and trailing directory (the inner parts all match up with mixed case). All 5 lines should appear identical (in mixed case). This is expecially noticable on a browser page where you have proportional fonts. Csaba Gabor Also, that old bug report (17822) functionally does not exist - it's been lost (at least large parts of it). If google can't see it, and I can't find it by searching, and PHP can't find it by searching (when I submit almost the same report), I'd call that lost. So in my book, it's not a duplicate report. And what should I do then? Previous Comments: [2004-05-04 08:55:57] [EMAIL PROTECTED] Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Thank you for your interest in PHP. It\'s also fixed. [2004-05-04 00:07:53] csaba at alum dot mit dot edu Description: I am resubmitting this bug report (#17822) since the previous report seems to have been corrupted and all the developer comments gone missing! The bug is still there, too: [18 Jun 2002 6:20pm CEST] csaba at alum dot mit dot edu realpath and getcwd on Windows systems do not actually report the applicable directory, but rather a string that will !strcasecmp() with the true directory: I have a directory name, $dir, on my Win2K system (PHP 4.2.0), but it's in all lower case, and I'd like to get the actual pathname including the capitalizations: Both realpath() and dirname() only muck around with the $dir string and don't hit the file system. Not only that, but getcwd() returns $dir (sans capitalizations) after I've hopped over to it with chdir($dir)! My only solution to this point is to pop up a level and use readdir(...) but this is wasteful, only giving me one level at a time. Isn't there a REAL realpath() for windows? Thanks, Csaba Gabor [27 Jul 2002 11:45am CEST] [EMAIL PROTECTED] Looked into this, it looks possible to implement. Wish me luck :) [10 Oct 2002 10:47pm CEST] [EMAIL PROTECTED] Any news? [27 Oct 2002 7:27pm CET] [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. [15 Feb 2003 5:38pm CET] csaba at alum dot mit dot edu I have marked this bug as open because of the demonstration below on my PHP 4.3 build date Dec. 20, 2002; Apache 2.0.43 Filter; Win2K Pro system. Here is the test: getcwd Problem " . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> On my system the first 2 directories show in lower case, the last two are in caps. Csaba [15 Feb 2003 7:32pm CET] [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 Cannot replicate using latest CVS. [22 Feb 2003 8:03pm CET] [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. [23 Apr 12:26am CEST] csaba at alum dot mit dot edu I have tested this with the latest snapshot 5.0 RC 2 of April 22 on my Win 2K Pro system and it is still a problem. Here are the outputs that I get (I did an inititial print right after the first cwd() so you can see what windows thinks the directory is): C:\Morph\phpDev\40gNiKU5LQ0C c:\Morph\phpDev\40gniku5lq0c c:\Morph\phpDev\40gniku5lq0c C:\Morph\phpDev\40GNIKU5LQ0C C:\Morph\phpDev\40GNIKU5LQ0C So it appears that the middle part is OK but the drive letter and the final directory
#28271 [NEW]: proc_open.c:753: error: `TIOCNOTTY' undeclared
From: admin at iut-info dot ens dot univ-reims dot fr Operating system: HP-UX 11i PHP version: 5.0.0RC2 PHP Bug Type: Compile Failure Bug description: proc_open.c:753: error: `TIOCNOTTY' undeclared Description: On HP-UX 11i compilation of PHP-5.0.0RC failed (Ok until /php5-200403131230) ./configure \ --prefix=/opt/APACHE/php\ --without-sqlite\ --with-oci8 \ --with-apache=../apache_1.3.29 \ --with-gd \ --with-pdflib=/opt/pdflib \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-tiff-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-zlib \ --with-bz2 \ --enable-sigchild \ --with-mysql=/opt/mysql \ --with-pgsql=/opt/pgsql \ --with-tsrm-pthreads\ --with-dom \ --with-libxml \ --with-xsl \ --enable-ftp\ --with-snmp=/usr/local \ --with-imap=/usr/local/imap \ --with-imap-ssl=/usr/local \ --with-openssl=/usr/local \ --enable-sockets Make failed with : gcc -Iext/standard/ -I/home/sys/install/php-5.0.0RC2/ext/standard/ -DPHP_ATOM_INC -I/home/sys/install/php-5.0.0RC2/include -I/home/sys/install/php-5.0.0RC2/main -I/home/sys/install/php-5.0.0RC2 -I/home/sys/install/php-5.0.0RC2/Zend -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/imap/include -I/opt/mysql/include/mysql -I/oracle/app/oracle/product/8.1.7/rdbms/public -I/oracle/app/oracle/product/8.1.7/rdbms/demo -I/opt/pdflib/include -I/opt/pgsql/include -I/home/sys/install/php-5.0.0RC2/TSRM -g -O2 -c /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c -o ext/standard/proc_open.o && echo > ext/standard/proc_open.lo /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c: In function `zif_proc_open': /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: `TIOCNOTTY' undeclared (first use in this function) /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: (Each undeclared identifier is reported only once /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: for each function it appears in.) *** Error exit code 1 - Declaration of `TIOCNOTTY' is present in - Workaround Adding this declaration in proc_open.c is a temporary solution (build successed). --- Cordialy -- Edit bug report at http://bugs.php.net/?id=28271&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28271&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28271&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28271&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28271&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28271&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28271&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28271&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28271&r=support Expected behavior: http://bugs.php.net/fix.php?id=28271&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28271&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28271&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28271&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28271&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28271&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28271&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28271&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28271&r=float
#11058 [Com]: php_network_getaddresses: getaddrinfo failed
ID: 11058 Comment by: jeppe at bundsgaard dot net Reported By: pat at mail dot rit dot edu Status: Bogus Bug Type: Network related Operating System: OpenBSD 2.6 PHP Version: 4.0.6 New Comment: I guess it is connected to the server - the problem occurs on some, but not all the servers running php4.3 that I am using. Anyway it would be nice with a solution that solves the problem independent of the servers - or that tells exactly what is to be done with the server (I know, this is not the place for such a request - but I don't know where to turn to). Previous Comments: [2004-02-12 21:15:45] cosas at minovela dot com hello, my php is PHP Version 4.3.4 i've exatctly the same problem. my server isn't conected by dialup, and i got ever the message "php_network_getaddresses: getaddrinfo failed" when i use this line: fsockopen ("dummy_ip", 25, &$errno, &$errstr, 10) it didn't occurs with older versions of php. this IS NOT a server problem, is a problem of PHP, you only need tho make a search at google http://www.google.es/search?hl=es&ie=UTF-8&oe=UTF-8&q=php+php_network_getaddresses%3A+getaddrinfo+failed&meta= target "php_network_getaddresses: getaddrinfo failed" and see results, a lot of people get the same errors. i hope you found a solution for this :) [2003-06-04 10:08:18] fcartegnie dot at dot free dot dot dot fr at null dot null Okay. I identified the problem. When apache starts, php or apache gets dns servers entry from /etc/resolv.conf You're using a dialup connection and when logging in, your dns servers have been added at this later moment. So there's a problem with apache or php to get informed that the content of resolv.conf has been updated. Confirmed for PHP 4.3.1/apache_1.3.27 so. Temporary solution is just to reload apache doing a apachectl stop/start [2002-04-03 16:27:07] g dot almasi at gigcity dot com Well you can tell I had nothing to do today but beat my head against a wall. But I found a solution! I added my target site to /etc/hosts and restarted apache, and now I can include a page in that target site from a different site. It's Miller Time! [2002-04-03 16:20:32] [EMAIL PROTECTED] And that is the cause of the problem (and the reason that this report is set to bogus). You need to tell your SuSE box how to resolve the addresses; the SuSE yast tool should let you set the nameserver in it's network configuration. I can't help you any further here, and this is not the place to discuss this further. I'd suggest looking at the SuSE support database for this: it's bound to be a FAQ. [2002-04-03 15:58:04] g dot almasi at gigcity dot com another note: I have root to another box (it serves about 20 sites to the web) that is also running PHP 4.0.6 and php_network_getaddresses works fine. Does this function require a nameserver? My SuSE 7.3 box is a development machine on my LAN, so I just use proxies to get to it with a browser. Getting DNS, BIND, and DHCP to work was beyond me when I set it up (still is, actually). So I just use a proxy setting for browsers while I build sites. 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/11058 -- Edit this bug report at http://bugs.php.net/?id=11058&edit=1
#19263 [Com]: huge POST data corrupt
ID: 19263 Comment by: richardks666 at hotmail dot com Reported By: erwin at isiz dot com Status: Bogus Bug Type: Apache2 related Operating System: Solaris 8 PHP Version: 4CVS-2002-09-06 New Comment: Solved! I removed /etc/httpd/conf.d/php.conf and updated /etc/httpd/conf/httpd.conf with: AddType application/x-httpd-php .php .phtml .phtm .inc .oc and restarted the webserver, things were back to normal. Was quite frustrating! Previous Comments: [2004-05-03 12:46:40] richardks666 at hotmail dot com Hey I am on Apache 2.0.40 using PHP5 RC2, experiencing the same problems as you guys did. Going to try these solutions later on today, but I wanted to tell you that as seen, this problem exist in PHP5 RC2 as well. If these are not the solutions to my problem, which I hope they are, wrongly linked LIBJPEGs and other libraries might interfere. Last night I sniffed the data between the webserver and my dev. computer, which showed that the instant I choose to upload my image (depends on filetype of course), that the appropriate library is linked and executed even there, and at the time, my PHP code hasn't been ran. In my case the Header dump contained the libjpeg version 1 addon. One might also wish to comment that, in conjunction with the original post, I too receive very odd FORM data. The size is somewhat correct ( I didn't doublecheck ) but extra objects are posted, for instance if I got an array of id[], then it might contain awkward data. Solution for that was to simply attach a INPUT TYPE HIDDEN nameing it "dummy" or something with a dummy value, now the objects are passed correctly. Staying in touch [2003-11-21 11:11:38] contact at creation-online dot net Hi !!! You really help me because I had the same problem with Apache 2 and Php 4.3.4 Now it works very good because of you solution ;-) Best regards, Aurélien [2003-11-19 08:38:43] grall at mit dot edu You are right erwin about this bug. The bug is in Apache 2.0.40 Possibly upgrading to a newer version will solve this. In any case, using the 'AddType application/x-httpd-php .php' didn't work for me, but instead I had to just insert into my httpd.conf: SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 1024 Some people report that you have to choose between one or the other, but in my case the second choice is the only one that works. Incidentally, if you are using MulitViews (as I am), using the approach, Multiviews no longer works. This is more of an Apache problem, but whatever, this thread is about that problem. Any suggestions? [2003-10-02 21:07:44] josantri at hotmail dot com Same experience with RedHat 7.3, Apache 2.0.45 & PHP 4.3.1. The solution was disabling MIME type for PHP (I don't see new problems by now with this issue): #AddType application/x-httpd-php .php And now, leaving enabled filtering method, but be care with above example or you get a 'Syntax error [...]: AddInputFilter requires at least two arguments, input filter name (or ; delimited names) followed by one or more file extensions' when Apache2 is restarted. The code we use is: AddInputFilter PHP .php AddOutputFilter PHP .php (Note the field naming the extension.) I'm not sure how enable filtering for *php.*, because AddInputFilter and AddOutputFilter seems not to accept wildcards on extensions (in files section definition is fine). Probably, independent definitions for each extension will work as well. Thanks to all of the above for help provided. [2003-07-01 02:35:35] php at gijs dot triple-it dot nl Hi, On my configuration (RedHat 9.0, Apache 2.0.40, php-4.2.2), I had to remove one of the following from the conf/httpd.conf or the /conf.d/php.conf AddType application/x-httpd-php .php4 .php3 .phtml .php Or SetOutputFilter PHP SetInputFilter PHP LimitRequestBody 1024 Either of these functions will work, but together they screw up and create the problem as reported above. Good Luck! Gijs Zonneveld 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/19263 -- Edit this bug report at http://bugs.php.net/?id=19263&edit=1
#28271 [Opn->Csd]: proc_open.c:753: error: `TIOCNOTTY' undeclared
ID: 28271 User updated by: admin at iut-info dot ens dot univ-reims dot fr Reported By: admin at iut-info dot ens dot univ-reims dot fr -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: HP-UX 11i PHP Version: 5.0.0RC2 New Comment: File is Ok in PHP5-200405041230 Previous Comments: [2004-05-04 14:33:09] admin at iut-info dot ens dot univ-reims dot fr Description: On HP-UX 11i compilation of PHP-5.0.0RC failed (Ok until /php5-200403131230) ./configure \ --prefix=/opt/APACHE/php\ --without-sqlite\ --with-oci8 \ --with-apache=../apache_1.3.29 \ --with-gd \ --with-pdflib=/opt/pdflib \ --with-jpeg-dir=/usr/local \ --with-png-dir=/usr/local \ --with-tiff-dir=/usr/local \ --with-freetype-dir=/usr/local \ --with-zlib \ --with-bz2 \ --enable-sigchild \ --with-mysql=/opt/mysql \ --with-pgsql=/opt/pgsql \ --with-tsrm-pthreads\ --with-dom \ --with-libxml \ --with-xsl \ --enable-ftp\ --with-snmp=/usr/local \ --with-imap=/usr/local/imap \ --with-imap-ssl=/usr/local \ --with-openssl=/usr/local \ --enable-sockets Make failed with : gcc -Iext/standard/ -I/home/sys/install/php-5.0.0RC2/ext/standard/ -DPHP_ATOM_INC -I/home/sys/install/php-5.0.0RC2/include -I/home/sys/install/php-5.0.0RC2/main -I/home/sys/install/php-5.0.0RC2 -I/home/sys/install/php-5.0.0RC2/Zend -I/usr/local/include/libxml2 -I/usr/local/include -I/usr/local/include/freetype2 -I/usr/local/imap/include -I/opt/mysql/include/mysql -I/oracle/app/oracle/product/8.1.7/rdbms/public -I/oracle/app/oracle/product/8.1.7/rdbms/demo -I/opt/pdflib/include -I/opt/pgsql/include -I/home/sys/install/php-5.0.0RC2/TSRM -g -O2 -c /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c -o ext/standard/proc_open.o && echo > ext/standard/proc_open.lo /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c: In function `zif_proc_open': /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: `TIOCNOTTY' undeclared (first use in this function) /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: (Each undeclared identifier is reported only once /home/sys/install/php-5.0.0RC2/ext/standard/proc_open.c:753: error: for each function it appears in.) *** Error exit code 1 - Declaration of `TIOCNOTTY' is present in - Workaround Adding this declaration in proc_open.c is a temporary solution (build successed). --- Cordialy -- Edit this bug report at http://bugs.php.net/?id=28271&edit=1
#28273 [NEW]: feof() doesn't return TRUE when invalid file handle is passed to it
From: mikeboulet at newfangled dot com Operating system: Redhat 7.2 or Redhat AS 2.1 PHP version: 4.3.4 PHP Bug Type: Filesystem function related Bug description: feof() doesn't return TRUE when invalid file handle is passed to it Description: When a fopen() is done on a file that has permissions that are set to not allow the current process user to read it or the file doesn't exist it returns false. This is expected. The problem is when feof() is fed the invalid handle it doesn't return TRUE() thus creating an infinite loop in the following code example. Reproduce code: --- Expected result: feof() would return TRUE to cancel the loop and the script would end. There would of course be warnings because of the invalid file handle, but that is expected. There should be better error handling on the developers part and catch the invalid file handle, but I would expect the file functions to handle this situation accordingly. Actual result: -- Inifinite loop -- Edit bug report at http://bugs.php.net/?id=28273&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28273&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28273&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28273&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28273&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28273&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28273&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28273&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28273&r=support Expected behavior: http://bugs.php.net/fix.php?id=28273&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28273&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28273&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28273&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28273&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28273&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28273&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28273&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28273&r=float
#28273 [Opn->Bgs]: feof() doesn't return TRUE when invalid file handle is passed to it
ID: 28273 Updated by: [EMAIL PROTECTED] Reported By: mikeboulet at newfangled dot com -Status: Open +Status: Bogus Bug Type: Filesystem function related Operating System: Redhat 7.2 or Redhat AS 2.1 PHP Version: 4.3.4 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. feof() does exactly what it's supposed to. Previous Comments: [2004-05-04 15:58:52] mikeboulet at newfangled dot com Description: When a fopen() is done on a file that has permissions that are set to not allow the current process user to read it or the file doesn't exist it returns false. This is expected. The problem is when feof() is fed the invalid handle it doesn't return TRUE() thus creating an infinite loop in the following code example. Reproduce code: --- Expected result: feof() would return TRUE to cancel the loop and the script would end. There would of course be warnings because of the invalid file handle, but that is expected. There should be better error handling on the developers part and catch the invalid file handle, but I would expect the file functions to handle this situation accordingly. Actual result: -- Inifinite loop -- Edit this bug report at http://bugs.php.net/?id=28273&edit=1
#28273 [Bgs]: feof() doesn't return TRUE when invalid file handle is passed to it
ID: 28273 User updated by: mikeboulet at newfangled dot com Reported By: mikeboulet at newfangled dot com Status: Bogus Bug Type: Filesystem function related Operating System: Redhat 7.2 or Redhat AS 2.1 PHP Version: 4.3.4 New Comment: I argue that it is a bug and that it was already addressed in a similar problem see http://bugs.php.net/bug.php?id=25939. Basically while in the while( feof() ) loop the socket goes away due to network failure and the stream is no longer there. This causes an infinite loop in 4.3.4 because feof() would not return TRUE. In 4.3.5 they changed this behavior to return TRUE on socket failure. This would be similar to saying the file handle is not valid and there is nothing there feof() thus we are at the end of nothing. I guess you could say we are at begining of nothing. I understand this is more of a symantics issue than a bug. If you google 'feof infinite php' you will see that there are a lot of people that get stung by this issue. Maybe it should be changed to get around a common problem. What do you think? Previous Comments: [2004-05-04 16:46:45] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. feof() does exactly what it\'s supposed to. [2004-05-04 15:58:52] mikeboulet at newfangled dot com Description: When a fopen() is done on a file that has permissions that are set to not allow the current process user to read it or the file doesn't exist it returns false. This is expected. The problem is when feof() is fed the invalid handle it doesn't return TRUE() thus creating an infinite loop in the following code example. Reproduce code: --- Expected result: feof() would return TRUE to cancel the loop and the script would end. There would of course be warnings because of the invalid file handle, but that is expected. There should be better error handling on the developers part and catch the invalid file handle, but I would expect the file functions to handle this situation accordingly. Actual result: -- Inifinite loop -- Edit this bug report at http://bugs.php.net/?id=28273&edit=1
#28274 [NEW]: register_globals removal petiton
From: raniz at gmx dot net Operating system: All PHP version: 4.3.6 PHP Bug Type: Feature/Change Request Bug description: register_globals removal petiton Description: As register_globals does create som security issues, and therefore is recommended to be turned off. I think it would be for the best if it was removed completely in the future. It also seems like register_globals is causing a lot of trouble for coders new to PHP (at least on the forums I hang). And I think many of them would disappear if register_globals were to be removed. I'm not saying I wan't an immediate removal, marking it as deprecated in the manual and removing it in a few versions would probably be the best. /Raniz -- Edit bug report at http://bugs.php.net/?id=28274&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28274&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28274&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28274&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28274&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28274&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28274&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28274&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28274&r=support Expected behavior: http://bugs.php.net/fix.php?id=28274&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28274&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28274&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28274&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28274&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28274&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28274&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28274&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28274&r=float
#28274 [Opn->WFx]: register_globals removal petiton
ID: 28274 Updated by: [EMAIL PROTECTED] Reported By: raniz at gmx dot net -Status: Open +Status: Wont fix Bug Type: Feature/Change Request Operating System: All PHP Version: 4.3.6 New Comment: That's not going to happen. Previous Comments: [2004-05-04 17:27:48] raniz at gmx dot net Description: As register_globals does create som security issues, and therefore is recommended to be turned off. I think it would be for the best if it was removed completely in the future. It also seems like register_globals is causing a lot of trouble for coders new to PHP (at least on the forums I hang). And I think many of them would disappear if register_globals were to be removed. I'm not saying I wan't an immediate removal, marking it as deprecated in the manual and removing it in a few versions would probably be the best. /Raniz -- Edit this bug report at http://bugs.php.net/?id=28274&edit=1
#28261 [Opn->Csd]: Lifting reserved keyword restriction for method names
ID: 28261 Updated by: [EMAIL PROTECTED] Reported By: Philippe dot Jausions at 11abacus dot com -Status: Open +Status: Closed Bug Type: Class/Object related -Operating System: Irrelevant +Operating System: * -PHP Version: Irrelevant +PHP Version: * New Comment: That's simply impossible. Previous Comments: [2004-05-03 17:36:00] Philippe dot Jausions at 11abacus dot com Description: Suggestion: Wouldn't it be possible to lift the reserved keyword restriction for method names? It seems to me that there shouldn't be any namespace conflict with the core PHP language. Reproduce code: --- Actual result: -- Parse error: parse error, unexpected T_EVAL, expecting T_STRING -- Edit this bug report at http://bugs.php.net/?id=28261&edit=1
#28222 [Opn->Csd]: DBX module should be bundled
ID: 28222 Updated by: [EMAIL PROTECTED] Reported By: rycamor at brainscraps dot com -Status: Open +Status: Closed Bug Type: Feature/Change Request -Operating System: all +Operating System: * -PHP Version: 5CVS-2004-04-29 (dev) +PHP Version: * New Comment: Version 4.3 is a stable version where we do not do further featzre changes. PHP 5.0 is in feature freeze mode too. But there is a new database abstraction extension in development. It may be ready for PHP 5.1. So please be patient. Previous Comments: [2004-05-03 09:09:05] [EMAIL PROTECTED] I've changed this from bogus=>open as amt misunderstood the feature request. Feel free to close this with a valid reason (or actually bundle it, but then, I'm biased :) BTW, the dbx version in cvs already contains support for SQLite. [2004-04-29 23:21:46] rycamor at brainscraps dot com Thanks, but I think I am being misunderstood here: SQLite is a stand-alone DBMS, which definitely has its place, but is not at all in the same problem domain as a database abstraction layer to allow unified methods for interacting with various server-based database systems. (http://php.net/dbx). My point is, at present PHP has no existing *built-in* standardization of database access. DBX is already available, it is a well-tested solution, and it is a very small addition to the standard PHP build, because it is really a thin layer over the existing database modules. DBX has only a few functions, but these functions are all that is really needed for true relational DBMS interaction, because all serious logic should be handled on the database side. Also, by default DBX returns all results in object form, making it a natural for the strong OO capabilities of PHP5. As a long-time user of PHP (since 1999), I strongly urge the PHP development team to consider this. [2004-04-29 22:34:30] [EMAIL PROTECTED] Thanks for the suggestion. We've actually decide to go with SQLite instead. See http://www.php.net/sqlite. [2004-04-29 22:07:43] rycamor at brainscraps dot com Description: Please make the dbx database abstraction module part of the default PHP build. There are many library developers who would like to start using dbx, but they cannot, because they don't know if the user has built PHP with dbx. I'm well aware that there are other abstraction libraries, but dbx is very simple, fast, and covers all standard interaction needs for a relational DBMS. Personally, I and many developers prefer it to the (overly) complex ones like PEAR:DB or ADODB. I think it would be a great benefit to the PHP project if a simple, straightforward, universal database module can be used anywhere, and dbx gets my vote. Thank you, Rick Morris -- Edit this bug report at http://bugs.php.net/?id=28222&edit=1
#28275 [NEW]: mktime() b0rked for 4-4-YYYY
From: escot001 at student dot ucr dot edu Operating system: FreeBSD 4.9-STABLE PHP version: 4.3.5 PHP Bug Type: Calendar related Bug description: mktime() b0rked for 4-4- Description: When feeding mktime() the parameters 4 for month, 4 for date, and any year, the begining of the UNIX epoch is returned. Reproduce code: --- "); } $d = 00; } ?> Expected result: 03-22-2010 03-23-2010 03-24-2010 03-25-2010 03-26-2010 03-27-2010 03-28-2010 03-29-2010 03-30-2010 03-31-2010 04-01-2010 04-01-2010 04-02-2010 04-03-2010 04-04-2010 04-05-2010 04-06-2010 04-07-2010 04-08-2010 04-09-2010 04-10-2010 04-11-2010 04-12-2010 04-13-2010 04-14-2010 04-15-2010 04-16-2010 04-17-2010 04-18-2010 04-19-2010 04-20-2010 04-21-2010 04-22-2010 04-23-2010 Actual result: -- 03-22-2010 03-23-2010 03-24-2010 03-25-2010 03-26-2010 03-27-2010 03-28-2010 03-29-2010 03-30-2010 03-31-2010 04-01-2010 04-01-2010 04-02-2010 04-03-2010 12-31-1969 04-05-2010 04-06-2010 04-07-2010 04-08-2010 04-09-2010 04-10-2010 04-11-2010 04-12-2010 04-13-2010 04-14-2010 04-15-2010 04-16-2010 04-17-2010 04-18-2010 04-19-2010 04-20-2010 -- Edit bug report at http://bugs.php.net/?id=28275&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28275&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28275&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28275&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28275&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28275&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28275&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28275&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28275&r=support Expected behavior: http://bugs.php.net/fix.php?id=28275&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28275&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28275&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28275&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28275&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28275&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28275&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28275&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28275&r=float
#28276 [NEW]: function rename stopped working after the last Windows update
From: motion4u at hotmail dot com Operating system: Windows 2000 Advanced PHP version: 4.3.6 PHP Bug Type: Directory function related Bug description: function rename stopped working after the last Windows update Description: The function: rename($oldname, $newname); stopped working after the last windows update. I'm using the rename Function to rename a directory rename($oldname, $newname); It doesn't work anymore... Before making a fool out of myself, I have double checked it. If you think to answer that it might be that the directory is in use or a file within it is open ... the answer is no! I have restarted the server and the client and disconnected the internet plug for it. Reproduce code: --- just fill in the path to any subdirectory and call -- Edit bug report at http://bugs.php.net/?id=28276&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28276&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28276&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28276&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28276&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28276&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28276&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28276&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28276&r=support Expected behavior: http://bugs.php.net/fix.php?id=28276&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28276&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28276&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28276&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28276&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28276&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28276&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28276&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28276&r=float
#28275 [Opn->Bgs]: mktime() b0rked for 4-4-YYYY
ID: 28275 User updated by: escot001 at student dot ucr dot edu Reported By: escot001 at student dot ucr dot edu -Status: Open +Status: Bogus Bug Type: Calendar related Operating System: FreeBSD 4.9-STABLE PHP Version: 4.3.5 New Comment: fixed in 4.3.6, sorry guys. Previous Comments: [2004-05-04 19:07:37] escot001 at student dot ucr dot edu Description: When feeding mktime() the parameters 4 for month, 4 for date, and any year, the begining of the UNIX epoch is returned. Reproduce code: --- "); } $d = 00; } ?> Expected result: 03-22-2010 03-23-2010 03-24-2010 03-25-2010 03-26-2010 03-27-2010 03-28-2010 03-29-2010 03-30-2010 03-31-2010 04-01-2010 04-01-2010 04-02-2010 04-03-2010 04-04-2010 04-05-2010 04-06-2010 04-07-2010 04-08-2010 04-09-2010 04-10-2010 04-11-2010 04-12-2010 04-13-2010 04-14-2010 04-15-2010 04-16-2010 04-17-2010 04-18-2010 04-19-2010 04-20-2010 04-21-2010 04-22-2010 04-23-2010 Actual result: -- 03-22-2010 03-23-2010 03-24-2010 03-25-2010 03-26-2010 03-27-2010 03-28-2010 03-29-2010 03-30-2010 03-31-2010 04-01-2010 04-01-2010 04-02-2010 04-03-2010 12-31-1969 04-05-2010 04-06-2010 04-07-2010 04-08-2010 04-09-2010 04-10-2010 04-11-2010 04-12-2010 04-13-2010 04-14-2010 04-15-2010 04-16-2010 04-17-2010 04-18-2010 04-19-2010 04-20-2010 -- Edit this bug report at http://bugs.php.net/?id=28275&edit=1
#8817 [Com]: $foo->getbar()->getfoobar()->method()
ID: 8817 Comment by: travis at codegoat dot com Reported By: tenshi at cinter dot de Status: Suspended Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.0.4 Assigned To: andi New Comment: I am just wondering if this will ever be brought out of `suspended` is there any intention on putting this in? If so, is there a timeline attached? I will assume there isn't , but it would be awesome to have this functionality! Previous Comments: [2001-01-20 06:58:57] [EMAIL PROTECTED] we know :) it is not available yet [2001-01-19 22:24:46] tenshi at cinter dot de Hi there. It would imho be useful to be abeled to code $foo->getbar()->getfoobar()->method(); instead of having to save each return value into a variable like: $bar = $foo->getbar(); $foobar = $bar->getfoobar(); $foobar->method(); Thanx. -- Edit this bug report at http://bugs.php.net/?id=8817&edit=1
#8817 [Sus->Csd]: $foo->getbar()->getfoobar()->method()
ID: 8817 Updated by: [EMAIL PROTECTED] Reported By: tenshi at cinter dot de -Status: Suspended +Status: Closed Bug Type: Feature/Change Request Operating System: linux PHP Version: 4.0.4 Assigned To: andi New Comment: Fixed in PHP 5. Previous Comments: [2004-05-04 20:47:48] travis at codegoat dot com I am just wondering if this will ever be brought out of `suspended` is there any intention on putting this in? If so, is there a timeline attached? I will assume there isn't , but it would be awesome to have this functionality! [2001-01-20 06:58:57] [EMAIL PROTECTED] we know :) it is not available yet [2001-01-19 22:24:46] tenshi at cinter dot de Hi there. It would imho be useful to be abeled to code $foo->getbar()->getfoobar()->method(); instead of having to save each return value into a variable like: $bar = $foo->getbar(); $foobar = $bar->getfoobar(); $foobar->method(); Thanx. -- Edit this bug report at http://bugs.php.net/?id=8817&edit=1
#28277 [NEW]: Cannot laod /usr/lib/apache/libphp4.so into server : /usr/lib/apache/libphp4.so
From: belday at hotmail dot com Operating system: Linux Red Hat 7.2 PHP version: 4.3.6 PHP Bug Type: Apache related Bug description: Cannot laod /usr/lib/apache/libphp4.so into server : /usr/lib/apache/libphp4.so Description: Cannot laod /usr/lib/apache/libphp4.so into server : /usr/lib/apache/libphp4.so: undefined symbol: ap_block_alarms I get this error when i'm trying to start apache. Any suggestions? -- Edit bug report at http://bugs.php.net/?id=28277&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28277&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28277&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28277&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28277&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28277&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28277&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28277&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28277&r=support Expected behavior: http://bugs.php.net/fix.php?id=28277&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28277&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28277&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28277&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28277&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28277&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28277&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28277&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28277&r=float
#28084 [Com]: Crashes when fonts are accessed
ID: 28084 Comment by: dietrich dot ayala at foundstone dot com Reported By: doormat at sequence-omega dot net Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2000 SP3 PHP Version: 4.3.6 New Comment: here is a simple reproduction script. the crash only occurs when writing the image to file, and is reproducible 100% of the time. Previous Comments: [2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com another comment: this is a regression. our code works fine in 4.3.2, but is broken b/c of this so we cannot upgrade. here's a quote from the jpgraph people: "There seems to be a bug with some versions of PHP on Windows. It has a (known) problem with simultaneous accessing the TTF libraries, (perhaps some thread-safety issues ?). No known workaround exists (apart from moving away from Win2000) as far as I'm aware." is anyone familiar w/ this issue? thanks, d. [2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com sorry, i left a piece of information out: php.exe is crashing for me, not the webserver. that's the only behavioral difference between what i'm experiencing from the original bug report. every time i load my graph scripts, php.exe goes boom. [2004-05-04 07:28:32] dietrich dot ayala at foundstone dot com i'm getting this also. it's reproducible 100% of the time. also using jpGraph. i'm working on getting this isolated, but as jpGraph is many thousands of lines long, it's difficult. i'm using IIS/WinXP&2k/PHP-4.3.6 & 4.3.7-dev. [2004-04-25 18:21:18] [EMAIL PROTECTED] Please make a script (as short as possible) that can be used to consistently replicate the crash. [2004-04-21 18:24:12] doormat at sequence-omega dot net I'm using Apache 1.3.29. I'm not quite sure how to show that it crashes in 10 lines or less, especially since the problem only seems to happen when multiple images are being generated at the same moment (a page is requested with multiple images, many images are generated with php/GD, if the page has a bunch of graphs, apache typically crashes). I'll work on it and get back to you though. 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/28084 -- Edit this bug report at http://bugs.php.net/?id=28084&edit=1
#26016 [Com]: Warning: fsockopen(): Bug
ID: 26016 Comment by: scott at marinar dot com Reported By: hill at bluecarrots dot com Status: No Feedback Bug Type: *General Issues Operating System: Linux PHP Version: 4.3.3 New Comment: The same is seen here with php 4.3.6 freshly compiled on Debian / Linux. Configure command is "./configure --enable-bcmath --with-openssl=/usr/local/openssl --with-mysql --with-apxs=/usr/bin/apxs --prefix=/usr/local" This bug persists through reloads of apache; apache version is 1.3.26. With so many people obviously affected by this PHP bug across multiple platforms, I'm concerned that the answer from PHP seems to be "it's not a PHP problem" promptly followed by marking threads as bogus. --Scott! Previous Comments: [2004-03-19 03:39:53] andrew at shh dot fi The error is real except this guy has the wrong script. I have the same problem - this is the script: $method = "ssl://"; $host = "myserver.com"; $port = 443; $fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30); I get the error: Warning: fsockopen(): no SSL support in this build AND SSL is loaded in php. Its a bug I patch on windows, but need one for linux [2003-11-03 14:06:38] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-10-28 04:44: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. please provide a sample script to illustrate the problem [2003-10-28 04:40:30] hill at bluecarrots dot com Description: I get the warning at the top of the page. Several refreshes of the browser rectifies. Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Reproduce code: --- Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Expected result: I expect the page to connect securely to a secure server and send some secure details. I get the warning at the top of the page. Several refreshes of the browser rectifies. I have to use this PHP code, which has been provided by the Payment provider, to get to a server that takes online payments, some information is first sent securely in order to reach the payment page on the Payment providers server. Actual result: -- The simle page takes time to load and when it does the fsockopen warning is present. -- Edit this bug report at http://bugs.php.net/?id=26016&edit=1
#28084 [Com]: Crashes when fonts are accessed
ID: 28084 Comment by: jpgraph at aditus dot nu Reported By: doormat at sequence-omega dot net Status: Feedback Bug Type: Reproducible crash Operating System: Windows 2000 SP3 PHP Version: 4.3.6 New Comment: The following code is said to repeat the crash on Win32 , works fine on Linux. Unfortunately I don't have access to a Win32 system to be able to repeat. The reproduce script was submitted by dietrich at ganx4 com Previous Comments: [2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com here is a simple reproduction script. the crash only occurs when writing the image to file, and is reproducible 100% of the time. [2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com another comment: this is a regression. our code works fine in 4.3.2, but is broken b/c of this so we cannot upgrade. here's a quote from the jpgraph people: "There seems to be a bug with some versions of PHP on Windows. It has a (known) problem with simultaneous accessing the TTF libraries, (perhaps some thread-safety issues ?). No known workaround exists (apart from moving away from Win2000) as far as I'm aware." is anyone familiar w/ this issue? thanks, d. [2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com sorry, i left a piece of information out: php.exe is crashing for me, not the webserver. that's the only behavioral difference between what i'm experiencing from the original bug report. every time i load my graph scripts, php.exe goes boom. [2004-05-04 07:28:32] dietrich dot ayala at foundstone dot com i'm getting this also. it's reproducible 100% of the time. also using jpGraph. i'm working on getting this isolated, but as jpGraph is many thousands of lines long, it's difficult. i'm using IIS/WinXP&2k/PHP-4.3.6 & 4.3.7-dev. [2004-04-25 18:21:18] [EMAIL PROTECTED] Please make a script (as short as possible) that can be used to consistently replicate the crash. 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/28084 -- Edit this bug report at http://bugs.php.net/?id=28084&edit=1
#26016 [NoF->WFx]: Warning: fsockopen(): Bug
ID: 26016 Updated by: [EMAIL PROTECTED] Reported By: hill at bluecarrots dot com -Status: No Feedback +Status: Wont fix Bug Type: *General Issues Operating System: Linux PHP Version: 4.3.3 New Comment: You must build the openssl statically to use this feature. There is a static version for windows, provided by Emini, who are also responsible for our win32 snapshots: http://ftp.emini.dk/pub/php/win32/openssl/ We won't fix this in PHP 4, but it has already been fixed in PHP 5 (you can load openssl dynamically in PHP 5). Previous Comments: [2004-05-04 21:57:10] scott at marinar dot com The same is seen here with php 4.3.6 freshly compiled on Debian / Linux. Configure command is "./configure --enable-bcmath --with-openssl=/usr/local/openssl --with-mysql --with-apxs=/usr/bin/apxs --prefix=/usr/local" This bug persists through reloads of apache; apache version is 1.3.26. With so many people obviously affected by this PHP bug across multiple platforms, I'm concerned that the answer from PHP seems to be "it's not a PHP problem" promptly followed by marking threads as bogus. --Scott! [2004-03-19 03:39:53] andrew at shh dot fi The error is real except this guy has the wrong script. I have the same problem - this is the script: $method = "ssl://"; $host = "myserver.com"; $port = 443; $fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30); I get the error: Warning: fsockopen(): no SSL support in this build AND SSL is loaded in php. Its a bug I patch on windows, but need one for linux [2003-11-03 14:06:38] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-10-28 04:44: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. please provide a sample script to illustrate the problem [2003-10-28 04:40:30] hill at bluecarrots dot com Description: I get the warning at the top of the page. Several refreshes of the browser rectifies. Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Reproduce code: --- Warning: fsockopen(): php_network_getaddresses: getaddrinfo failed: Name or service not known in /home/.sites/.blahphp on line 14 Warning: fsockopen(): unable to connect to blah.com:80 in /home/.sites/blah.php on line 14 Resource temporarily unavailable (11) Expected result: I expect the page to connect securely to a secure server and send some secure details. I get the warning at the top of the page. Several refreshes of the browser rectifies. I have to use this PHP code, which has been provided by the Payment provider, to get to a server that takes online payments, some information is first sent securely in order to reach the payment page on the Payment providers server. Actual result: -- The simle page takes time to load and when it does the fsockopen warning is present. -- Edit this bug report at http://bugs.php.net/?id=26016&edit=1
#26016 [WFx->NoF]: Warning: fsockopen(): Bug
ID: 26016 Updated by: [EMAIL PROTECTED] Reported By: hill at bluecarrots dot com -Status: Wont fix +Status: No Feedback Bug Type: *General Issues Operating System: Linux PHP Version: 4.3.3 New Comment: Err, I obviously was reading the odd-one-out comment. Restoring status. Previous Comments: [2004-05-04 23:01:10] [EMAIL PROTECTED] You must build the openssl statically to use this feature. There is a static version for windows, provided by Emini, who are also responsible for our win32 snapshots: http://ftp.emini.dk/pub/php/win32/openssl/ We won't fix this in PHP 4, but it has already been fixed in PHP 5 (you can load openssl dynamically in PHP 5). [2004-05-04 21:57:10] scott at marinar dot com The same is seen here with php 4.3.6 freshly compiled on Debian / Linux. Configure command is "./configure --enable-bcmath --with-openssl=/usr/local/openssl --with-mysql --with-apxs=/usr/bin/apxs --prefix=/usr/local" This bug persists through reloads of apache; apache version is 1.3.26. With so many people obviously affected by this PHP bug across multiple platforms, I'm concerned that the answer from PHP seems to be "it's not a PHP problem" promptly followed by marking threads as bogus. --Scott! [2004-03-19 03:39:53] andrew at shh dot fi The error is real except this guy has the wrong script. I have the same problem - this is the script: $method = "ssl://"; $host = "myserver.com"; $port = 443; $fp = fsockopen($method.$host, $port, $errno, $errstr, $timeout = 30); I get the error: Warning: fsockopen(): no SSL support in this build AND SSL is loaded in php. Its a bug I patch on windows, but need one for linux [2003-11-03 14:06:38] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-10-28 04:44: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. please provide a sample script to illustrate the problem The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26016 -- Edit this bug report at http://bugs.php.net/?id=26016&edit=1
#28278 [NEW]: flakey return by reference under certain circumstances
From: jeff at opendbms dot com Operating system: Linux 2.6.1-rc1 PHP version: 5.0.0RC2 PHP Bug Type: Zend Engine 2 problem Bug description: flakey return by reference under certain circumstances Description: While passing references every which way, I come to a point where I cannot get my processForm function to return a reference to an object member variable. Pretty serious bug I think... Reproduce code: --- http://www.opendbms.com/test.phps 80 lines with comments, Ready to run. Expected result: I expect the output to look like this: Request Object ( [attributes:private] => Array ( [sequencelist] => Array ( [0] => Orders.ProductInfo [1] => NewSequence1.New1 ) ) [parameters:private] => Array ( [sequence] => Orders.ProductInfo ) ) Request:Request Object ( [attributes:private] => Array ( [sequencelist] => Array ( [0] => Orders.ProductInfo [1] => NewSequence1.New1 [2] => NewSequence2.New2 [3] => NewSequence3.New3 ) ) [parameters:private] => Array ( [sequence] => Orders.ProductInfo ) ) Reference:Array ( [0] => Orders.ProductInfo [1] => NewSequence1.New1 [2] => NewSequence2.New2 [3] => NewSequence3.New3 ) Actual result: -- Request Object ( [attributes:private] => Array ( [sequencelist] => Array ( [0] => Orders.ProductInfo [1] => NewSequence1.New1 ) ) [parameters:private] => Array ( [sequence] => Orders.ProductInfo ) ) Request:Request Object ( [attributes:private] => Array ( [sequencelist] => Array ( [0] => Orders.ProductInfo [1] => NewSequence1.New1 [2] => NewSequence2.New2 ) ) [parameters:private] => Array ( [sequence] => Orders.ProductInfo ) ) Reference:Array ( [0] => Orders.ProductInfo [1] => NewSequence1.New1 [2] => NewSequence2.New2 [3] => NewSequence3.New3 ) The Request object is missing the last element of the array, because it is no longer a reference at that point. -- Edit bug report at http://bugs.php.net/?id=28278&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28278&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28278&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28278&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28278&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28278&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28278&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28278&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28278&r=support Expected behavior: http://bugs.php.net/fix.php?id=28278&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28278&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28278&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28278&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28278&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28278&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28278&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28278&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28278&r=float
#28190 [Fbk->NoF]: Page not completely outputted
ID: 28190 Updated by: [EMAIL PROTECTED] Reported By: prof_moriarty at veryfst dot biz -Status: Feedback +Status: No Feedback Bug Type: Apache2 related Operating System: win xp home PHP Version: 5.0.0RC2 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-04-27 21:19:09] [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-27 20:52:16] prof_moriarty at veryfst dot biz Description: Running PHP5.RC2 as a sapi module (or whatever it is) in apache 2.0.49. MySQL 4.0.18 When trying to load phpmyadmin (2.5.6) pages, about 4 out of five times, the server decides to stop serving them mid page. So i end up with a semi-complete table in front of me. Using Opera as the browser. If i try looking at the pages in IE (oh horrors), it just returns a "The page cannot be displayed" (but hey, it's IE :) ). I'm guessing IE doesn't like recieving only part of the page, so doesn't display it because it wants the rest. Opera is more willing to go part-way. I'm afraid i can't be more specific as to precisely what the problem is, because i don't know. All the other scripts i've tried are fine (though that's not many), however phpmyadmin seems to not be liked much. There's no report of this bug on the phpmyadmin web-site, so i'm guessing it's probably the PHP interface with apache 2 (again :) ). There are no errors/ notices or anything reported when reporting level is set to ALL. Note: This also happens with php4.3.6 whilst using it's php4apache2.dll file. Need any more details just ask. I'm sure it's not going to go away over night. :) Moriarty -- Edit this bug report at http://bugs.php.net/?id=28190&edit=1
#28084 [Fbk->NoF]: Crashes when fonts are accessed
ID: 28084 Updated by: [EMAIL PROTECTED] Reported By: doormat at sequence-omega dot net -Status: Feedback +Status: No Feedback Bug Type: Reproducible crash Operating System: Windows 2000 SP3 PHP Version: 4.3.6 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-05-04 22:38:17] jpgraph at aditus dot nu The following code is said to repeat the crash on Win32 , works fine on Linux. Unfortunately I don't have access to a Win32 system to be able to repeat. The reproduce script was submitted by dietrich at ganx4 com [2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com here is a simple reproduction script. the crash only occurs when writing the image to file, and is reproducible 100% of the time. [2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com another comment: this is a regression. our code works fine in 4.3.2, but is broken b/c of this so we cannot upgrade. here's a quote from the jpgraph people: "There seems to be a bug with some versions of PHP on Windows. It has a (known) problem with simultaneous accessing the TTF libraries, (perhaps some thread-safety issues ?). No known workaround exists (apart from moving away from Win2000) as far as I'm aware." is anyone familiar w/ this issue? thanks, d. [2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com sorry, i left a piece of information out: php.exe is crashing for me, not the webserver. that's the only behavioral difference between what i'm experiencing from the original bug report. every time i load my graph scripts, php.exe goes boom. [2004-05-04 07:28:32] dietrich dot ayala at foundstone dot com i'm getting this also. it's reproducible 100% of the time. also using jpGraph. i'm working on getting this isolated, but as jpGraph is many thousands of lines long, it's difficult. i'm using IIS/WinXP&2k/PHP-4.3.6 & 4.3.7-dev. 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/28084 -- Edit this bug report at http://bugs.php.net/?id=28084&edit=1
#28172 [Fbk->NoF]: Crazy error when commenting out a simplexml var
ID: 28172 Updated by: [EMAIL PROTECTED] Reported By: scholzrobert at web dot de -Status: Feedback +Status: No Feedback Bug Type: SimpleXML related Operating System: Fedora C1 (Linux 2.6.5) PHP Version: 5.0.0RC2 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-04-27 08:25:50] [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 , 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-27 01:02:54] scholzrobert at web dot de Description: I have the Object $xml. It has the simplexml Obj $xml::xml. The "reproduce code" lines stop my apache2 for this one script. Firefox does not load the page, konqueror says that "Connction to localhost ist broken" and IE displas a site which says "technical problems". Reproduce code: --- // $xml->xml->news->text /* $xml->xml->news->text */ # $xml->xml->news->text Expected result: Nothing, it's only a comment to remember how ot worked before Actual result: -- Firefox does not load the page, konqueror says connection broken and IE displays a "technical error" page. -- Edit this bug report at http://bugs.php.net/?id=28172&edit=1
#28183 [Fbk->NoF]: Variables mix up
ID: 28183 Updated by: [EMAIL PROTECTED] Reported By: patrick dot hagemeister at krankikom dot de -Status: Feedback +Status: No Feedback Bug Type: Scripting Engine problem Operating System: Linux SuSE 8.0 PHP Version: 4.3.6 New Comment: No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". Previous Comments: [2004-04-27 21:13:33] [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 , 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-27 16:26:38] patrick dot hagemeister at krankikom dot de Changed category to "Scripting engine problem" [2004-04-27 16:21:04] patrick dot hagemeister at krankikom dot de Description: I have a medium-sized php applications (~2 lines), which starts to produce a few problems. Sometimes, variables mix up: i.e. i create a new instance $root of class "CBXTreeNode", but only 3 lines later, suddenly the class type (checked using get_class()) of $root is "CBXWorkflow", and the value is the one of another variable in the same function. But between these lines, i didn't even touch the variable... In some places, a similar problem shows up: I instanciate a class CBXTreeNode, but if i do get_class($variable), it returns "cbxtreenodd" instead of ctxtreenode. Unfortunately i could not reproduce it on every server, on my development server it works, on the production server, it doesn't :( Also, the exact same source works outside my application, on the same server. I updated PHP from 4.2.3 to 4.3.6, but no change. Reproduce code: --- $root = $treemgr->getRootNode(); echo "root is class ".get_class($root).""; $workflow =& $this->getWorkflow(); echo "workflow is class ".get_class($workflow).""; echo "root is class ".get_class($root).""; // **Output in my application** // root is class CBXTreeNode // workflow is class SPWorkflow // root is class SPWorkflow Expected result: Output should be: root is class CBXTreeNode workflow is class SPWorkflow root is class CBXTreeNode -- Edit this bug report at http://bugs.php.net/?id=28183&edit=1
#28172 [NoF->Csd]: Crazy error when commenting out a simplexml var
ID: 28172 User updated by: scholzrobert at web dot de Reported By: scholzrobert at web dot de -Status: No Feedback +Status: Closed Bug Type: SimpleXML related Operating System: Fedora C1 (Linux 2.6.5) PHP Version: 5.0.0RC2 New Comment: Can't reproduce this bug (apache 2.0.48/49). Previous Comments: [2004-05-05 01:00:06] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-04-27 08:25:50] [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 , 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-27 01:02:54] scholzrobert at web dot de Description: I have the Object $xml. It has the simplexml Obj $xml::xml. The "reproduce code" lines stop my apache2 for this one script. Firefox does not load the page, konqueror says that "Connction to localhost ist broken" and IE displas a site which says "technical problems". Reproduce code: --- // $xml->xml->news->text /* $xml->xml->news->text */ # $xml->xml->news->text Expected result: Nothing, it's only a comment to remember how ot worked before Actual result: -- Firefox does not load the page, konqueror says connection broken and IE displays a "technical error" page. -- Edit this bug report at http://bugs.php.net/?id=28172&edit=1
#28084 [NoF->Ctl]: Crashes when fonts are accessed
ID: 28084 Updated by: [EMAIL PROTECTED] Reported By: doormat at sequence-omega dot net -Status: No Feedback +Status: Critical Bug Type: Reproducible crash Operating System: Windows 2000 SP3 PHP Version: 4.3.6 Previous Comments: [2004-05-05 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-05-04 22:38:17] jpgraph at aditus dot nu The following code is said to repeat the crash on Win32 , works fine on Linux. Unfortunately I don't have access to a Win32 system to be able to repeat. The reproduce script was submitted by dietrich at ganx4 com [2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com here is a simple reproduction script. the crash only occurs when writing the image to file, and is reproducible 100% of the time. [2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com another comment: this is a regression. our code works fine in 4.3.2, but is broken b/c of this so we cannot upgrade. here's a quote from the jpgraph people: "There seems to be a bug with some versions of PHP on Windows. It has a (known) problem with simultaneous accessing the TTF libraries, (perhaps some thread-safety issues ?). No known workaround exists (apart from moving away from Win2000) as far as I'm aware." is anyone familiar w/ this issue? thanks, d. [2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com sorry, i left a piece of information out: php.exe is crashing for me, not the webserver. that's the only behavioral difference between what i'm experiencing from the original bug report. every time i load my graph scripts, php.exe goes boom. 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/28084 -- Edit this bug report at http://bugs.php.net/?id=28084&edit=1
#28084 [Ctl->Opn]: Crashes when fonts are accessed
ID: 28084 Updated by: [EMAIL PROTECTED] Reported By: doormat at sequence-omega dot net -Status: Critical +Status: Open Bug Type: Reproducible crash Operating System: Windows 2000 SP3 PHP Version: 4.3.6 New Comment: err, I meant open. Previous Comments: [2004-05-05 01:00:05] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2004-05-04 22:38:17] jpgraph at aditus dot nu The following code is said to repeat the crash on Win32 , works fine on Linux. Unfortunately I don't have access to a Win32 system to be able to repeat. The reproduce script was submitted by dietrich at ganx4 com [2004-05-04 21:40:38] dietrich dot ayala at foundstone dot com here is a simple reproduction script. the crash only occurs when writing the image to file, and is reproducible 100% of the time. [2004-05-04 07:49:16] dietrich dot ayala at foundstone dot com another comment: this is a regression. our code works fine in 4.3.2, but is broken b/c of this so we cannot upgrade. here's a quote from the jpgraph people: "There seems to be a bug with some versions of PHP on Windows. It has a (known) problem with simultaneous accessing the TTF libraries, (perhaps some thread-safety issues ?). No known workaround exists (apart from moving away from Win2000) as far as I'm aware." is anyone familiar w/ this issue? thanks, d. [2004-05-04 07:32:10] dietrich dot ayala at foundstone dot com sorry, i left a piece of information out: php.exe is crashing for me, not the webserver. that's the only behavioral difference between what i'm experiencing from the original bug report. every time i load my graph scripts, php.exe goes boom. 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/28084 -- Edit this bug report at http://bugs.php.net/?id=28084&edit=1
#22335 [Com]: htmlspecialchars() encodes foriegn chars too!
ID: 22335 Comment by: mano at cvr dot hu Reported By: caleb_ownz at yahoo dot com Status: Bogus Bug Type: Strings related Operating System: Windows PHP Version: 4.3.0 New Comment: Hi Yes, I also recognized this problem with the hungarian chars! I hope that I'll find the solutions around here... .mano Previous Comments: [2003-02-22 14:27:09] [EMAIL PROTECTED] set proper status. [2003-02-22 14:26:55] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Works fine here, the error you are seeing sounds like a result of COPY/PASTE operation from another Win32 application. Win32 has a nasty tendency to automatically encode special characters into their HTML enteties. The example below should demonstrate that htmlspecialchars() works correctly. [2003-02-21 06:02:01] caleb_ownz at yahoo dot com hmm after checking some more research i noticed that this happens only when the browser encoding != language you are writing. So if you write in hebrew when the browser is set to encode Western European you will get something similar to this: "עברית" although i did solve all these problems by calling html_entities_decode() but still.. why should htmlspecialchars() encode anything but the SPECIAL chars, and not language chars.. ùìåí becomes שלום [2003-02-20 17:25:17] [EMAIL PROTECTED] Could you please supply a simple string with which the problem occures. [2003-02-20 13:00:33] caleb_ownz at yahoo dot com Hello, The htmlspecialchars() function should only convert SPECIAL chars such as '&' '"' ''' '<' '>'. (at least this is what the documentation says) But this function also seems to convert foriegn language (non-english) chars too which is what htmlentities() basically does. I have tested this on Russian and Hebrew! -- Edit this bug report at http://bugs.php.net/?id=22335&edit=1
#28276 [Opn]: function rename stopped working after the last Windows update
ID: 28276 User updated by: motion4u at hotmail dot com Reported By: motion4u at hotmail dot com Status: Open Bug Type: Directory function related Operating System: Windows 2000 Advanced PHP Version: 4.3.6 New Comment: Sorry, it is not a bug! simply with this version the folders have to have more access permissions under windows as before. I'm sure that it is mentioned somewhere in the documentations, which I have missed. You may drop this report if you like. Previous Comments: [2004-05-04 19:28:58] motion4u at hotmail dot com Description: The function: rename($oldname, $newname); stopped working after the last windows update. I'm using the rename Function to rename a directory rename($oldname, $newname); It doesn't work anymore... Before making a fool out of myself, I have double checked it. If you think to answer that it might be that the directory is in use or a file within it is open ... the answer is no! I have restarted the server and the client and disconnected the internet plug for it. Reproduce code: --- just fill in the path to any subdirectory and call -- Edit this bug report at http://bugs.php.net/?id=28276&edit=1
#28279 [NEW]: function symlink() crash under windows
From: motion4u at hotmail dot com Operating system: Windows 2000 Advanced PHP version: 4.3.6 PHP Bug Type: IIS related Bug description: function symlink() crash under windows Description: Create and Manipulate NTFS Junction Points doesn't work in PHP but it was solved by www.sysinternals.com. They also offer the c-code free for download. I have tested it and it works very well. You can download the free source code there: http://www.sysinternals.com/files/jnctnsrc.zip Reproduce code: --- $letters = 'abcdefghijklmnopqrstuvwxyz'; srand((double) microtime() * 100); $string = ''; for ($i = 1; $i <= rand(4,12); $i++) { $q = rand(1,24); $string = $string . $letters[$q]; } //- this part can't work under windows $handle = opendir($downloaddir); while ($dir = readdir($handle)) { if (is_dir($downloaddir . $dir)){ if ($dir != "." && $dir != ".."){ @unlink($downloaddir . $dir . "/" . $filename); @rmdir($downloaddir . $dir); } } } closedir($handle); //-- mkdir($downloaddir . $string, 0777); // here symlink produce browser crash under windows symlink($safedir . $filename, $downloaddir . $string . "/" . $filename); Header("Location: ".$downloadURL.$string. "/" . $filename); Expected result: start downloading but produce browser crash -- Edit bug report at http://bugs.php.net/?id=28279&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28279&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28279&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28279&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28279&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28279&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28279&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28279&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28279&r=support Expected behavior: http://bugs.php.net/fix.php?id=28279&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28279&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28279&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28279&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28279&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28279&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28279&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28279&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28279&r=float
#25876 [Com]: session_start(): Failed to initialize storage module
ID: 25876 Comment by: tkaeser at gmx dot net Reported By: golden at riscom dot com Status: Closed Bug Type: Session related Operating System: freebsd 4.8 PHP Version: 4.3.3 New Comment: Hi, had the same error, added the following line before starting the session: ini_set('session.save_handler', 'files'); this fixed it in my case... I don't have any idea why this works, got it from http://lists.mushaake.org/pipermail/php/Week-of-Mon-20031117/004091.html Previous Comments: [2004-04-05 08:17:56] venkat at ehostpros dot com # Problem : Fatal error: session_start(): Failed to initialize storage module # The solution (fingers crossed) was to clear the session.save_path directory - it got thousands of session files there. Hope it helps someone out there. # The above solution works fine :) Thanks, Venkatesh.G [2004-04-01 16:37:42] php dot net at harrysufehmi dot com I just experienced this problem with php 4.3.3 The solution (fingers crossed) was to clear the session.save_path directory - it got thousands of session files there. Hope it helps someone out there. [2004-03-08 05:38:31] hck7 at mailcity dot com We installed PHP 4.3.1 and this problem disappears!!! Thanks for all !!! [2004-03-02 04:49:14] ozone at sange dot fi As suggested by mivox on Feb 12 in comments to bug 26038, which seems to be a duplicate of this one, I added a line in my apache.conf: php_value session.save_handler files (source: http://bugs.php.net/bug.php?id=260389 ) After this I haven't seen any problems (running for a bit less than a day), but it's hard to say whether it really helped. Maybe there are still problems with the initialization of session parameters when PHP is running as a module and the same code is used to serve lots of requests. For me the problems started when using FreeBSD 4-STABLE (4.8 I think, or even earlier) with PHP 4.2.x and continued with PHP 4.3.x, but they were very infrequent when using Apache 1.3. Upgrading to Apache 2 made problems turn up much more often and users started complaining loudly. I applied the patch from CVS that was supposed to fix the problem to PHP 4.3.4 (from FreeBSD ports) but it didn't help. Of course that's not quite the same as trying a recent snapshot, but other people have tried that and it didn't help either. [2004-02-27 10:30:37] bernoico at netcabo dot pt I also have made the change you sugested and the problem continues... You have to reopen this bug report. Thanks. 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/25876 -- Edit this bug report at http://bugs.php.net/?id=25876&edit=1
#21772 [Com]: mssql speed when using remote server
ID: 21772 Comment by: reubs at idsdatanet dot com Reported By: pvy at novosoft dot ru Status: Bogus Bug Type: MSSQL related Operating System: windows 2000/sp3 PHP Version: 4.2.3 New Comment: We have the same problem - but there is an interesting twist. Was running through the test in a progressive manner. 1. Vanilla install on local machine MSSQL2k/PHP433 - works as expected without any service packs --- Machine A 2. Vanilla install on remote machine MSSQL2k - unacceptably slow - response and processing time went from 1 second to 15-20seconds. -- +Machine B - colleague ran a packet sniffer and found fragmented requests 3. Installed latest service packs on Machine B, fragmented packets are reduced. Speed is still slow - improvements were minor. -- here is where you have to read carefully. 4. Installed latest service pack on Machine A (remember machine A had a version of MSSQL2k but not used as the target DB) - Speed went up to equivelant of MySQL/PHP, impressive, problem solved(?) - assumption must install connector service pack upgrade on Web server as well 5. Client complained - no improvement, 6. Uninstalled the MSSQL server on my webserver - installed just the connectors, ran the MDAC update patches - Result, same as note 2 - 15-20second response time. Obviously there seems to be a difference in MSSQL Connector DLLs. Have to look into this (unless someone here know what is going on) but I must admit my suggestion to them would be a LAMP config. --sob story - basic rant start The excessive finger pointing on bug ownership in the end puts us at risks of losing a key client as we come up to no solution but a lot of doubts by the client on the platform of choice - and the IS department having spent a lot of money on MSSQL will blame it on PHP first before putting the blame on their choice of corporate db. Previous Comments: [2003-01-21 12:27:09] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. There are some networking issues when Linux & Win32 machines communicate. For example a stock 100mbit lan only operates at 1/3 - 1/2 speed while if both machines run the same OS all 100mbit are avaliable. Since this appears to be a networking issue, I am marking this a bogus (not a php bug). [2003-01-21 11:24:59] [EMAIL PROTECTED] Hi, I'm unable to reproduce these diferences on my systems. I have tested the speed on a SQL Server 7.0 and I get almost the same response times on local and remote connections. In my case the local connects are slower due to the fact that both PHP and MSSQL server is competing on the CPU. If there is a diference from Linux to Windows this must be caused by old versions of DBLIB used on Windows. I'm working on using FreeTDS on Windows. Other factors can be how you configure your MSSQL Server and Clients. If you don't do anything MSSQL defaults to named pipes (approx 8 times slover on a network but faster on a local connection compared to TCP/IP). You should use the Client Network Configuration tool to specify default libraries and configure aliases for your local and remote servers. Then use this alias when connecting to the server. When you compare PHP and MS Queary Tool you compare apples and oranges. PHP is build on an old database protocol and MS Query Tool uses the most modern technology available. - Frank [2003-01-21 03:51:35] pvy at novosoft dot ru Thank you Joey! Good work! [2003-01-21 03:49:56] [EMAIL PROTECTED] We've been using PHP hosted on a win32 machine to connect to SQL Server 2000. When the PHP host and the MSSQL host are the same machine, everything is fine. But when we try to use seperate hosts for PHP and MSSQL, query times become unbearably slow. The odd thing is that I can run the same scripts on the same network connecting to the same MSSQL server from a Linux box, and see acceptable response times. As an example, I did a script that does 1000 iterations of 'sp_sproc_columns @procudure_name = "some_proc"' in three different setups. Setup 1: MSSQL and PHP on the Win2k host, call it machine 'A' Average Response time over 5 iterations of script: 18s Setup 2: MSSQL on host 'A', PHP on Linux host ('B') Average Response time over 5 iterations of script: 41s (Given the size of the result set, this is an acceptable response time.) Setup 3: MSSQL on host 'A', PHP on seperate Win2k host ('C') Average Response time over 5 iterations: 3