#28222 [Bgs->Opn]: DBX module should be bundled
ID: 28222 Updated by: [EMAIL PROTECTED] Reported By: rycamor at brainscraps dot com -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 5CVS-2004-04-29 (dev) New Comment: 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. Previous Comments: [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
#28258 [Csd->Bgs]: mktime error
ID: 28258 Updated by: [EMAIL PROTECTED] Reported By: bichinhoverde at spwinternet dot com dot br -Status: Closed +Status: Bogus Bug Type: Date/time related Operating System: winxp+apache2 module PHP Version: 4.3.6 New Comment: Wasn't a bug. Previous Comments: [2004-05-03 07:28:38] bichinhoverde at spwinternet dot com dot br Sorry, just read on the php documentation: "on systems where time_t is a 32bit signed integer, as most common today, the valid range for year is somewhere between 1901 and 2038" "Negative timestamps are not supported under any known version of Windows. Therefore the range of valid years includes only 1970 through 2038." [2004-05-03 07:14:40] bichinhoverde at spwinternet dot com dot br Description: I saw a very similar error on another bug report. It was supposed to be fixed but it doesn't seem to be. mktime fails for dates after 2038 because the long integer type cannot handle such big timestamps. Reproduce code: --- '; print mktime(23,59,60,1,18,2038); print ''; print mktime(0,0,0,1,19,2038); ?> Expected result: 2147479199 2147479200 2147479200 Actual result: -- 2147479199 2147479200 Warning: mktime(): Windows does not support negative values for this function in C:\apacheroot\index.php on line 6 -1 -- Edit this bug report at http://bugs.php.net/?id=28258&edit=1
#28227 [Opn->Asn]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Updated by: [EMAIL PROTECTED] Reported By: lukem at NetBSD dot org -Status: Open +Status: Assigned Bug Type: CGI related Operating System: NetBSD 2.0C PHP Version: 4.3.6 -Assigned To: +Assigned To: shane New Comment: Shane, can you please take a look when you have a moment? Previous Comments: [2004-05-03 04:25:48] lukem at NetBSD dot org Here's the patch: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/php4/patches/patch-aa?rev=1.10&content-type=text/plain [2004-04-30 02:11:47] lukem at NetBSD dot org Description: I upgraded PHP from 4.2.3 to 4.3.6 and I started getting the error "No input file specified." from the php-as-cgi whilst running under a (fairly minimal and small) web server called bozohttpd. Further investigation reveals that sapi/cgi/cgi_main.c::init_request_info() is using the existance of SCRIPT_FILENAME to determine if php is running as a CGI. However, the "defacto standard" for CGI/1.1: http://cgi-spec.golux.com/ makes no mention of SCRIPT_FILENAME, only SCRIPT_NAME. Thus, when a web server that is used to run php as a CGI doesn't support SCRIPT_FILENAME (which is reasonable - see the specs above), php refuses to function and fails with the error above. Some research into other web servers indicates that none of them support SCRIPT_FILENAME. These servers include: thttpd, mini_httpd, w3c-httpd, OmniHTTPd - (PHP PR 25833), Xitami (PHP PR 25305) This issue is also alluded to in the "command line" documentation on your web site: http://www.php.net/features.commandline (search for "no input file"). In summary, PHP 4.3.6 should not be relying solely upon SCRIPT_FILENAME to determine if it's running as a CGI. I have a patch to fix this issue - rev 1.10 of NetBSD's pkgsrc/www/php4/patches/patch-aa - which I can provide if necessary. Cheers, Luke Mewburn. -- Edit this bug report at http://bugs.php.net/?id=28227&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: 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 Previous Comments: [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 [2003-01-08 14:21:36] colreid at zasx dot com People are asking me what I did, so here it is: My Apache2 package has a directory which it uses for included files with httpd.conf (the path to this directory in my installation is /etc/httpd/conf.d). In there is a file called php.conf, and basically I just commented out the whole thing except for one line: LoadModule php4_module modules/libphp4.so This section here: # #SetOutputFilter PHP #SetInputFilter PHP #LimitRequestBody 524288 # liked to munge uploads. Also, in the httpd.conf file I added the line: AddType application/x-httpd-php .php .html .htm .inc And that's it. I restarted apache and uploads decided to be nice. :) The remainder of the comments for this report are too long. To view the rest of the comments, please view the bu
#28179 [Fbk->Opn]: [COM] passing classes as a parameter
ID: 28179
User updated by: arnout at argeweb dot nl
Reported By: arnout at argeweb dot nl
-Status: Feedback
+Status: Open
Bug Type: COM related
Operating System: Windows NT 5.2 / Windows 2003
PHP Version: PHP Version 5.0.0RC2
New Comment:
I've got it running now too. It only works if you import the DLL like
'event classes' instead of 'components'.
The real DLL by the way didn't work until I removed it all from the
COM+ manager and run regsvr32.exe on it.
Previous Comments:
[2004-04-30 11:45:36] [EMAIL PROTECTED]
What user account is Apache running under?
Does it make a difference if you run it as a different user?
[2004-04-29 16:45:39] arnout at argeweb dot nl
I'm using Apache 2 and run 5.0.0RC2 as a module. Maybe that makes some
difference?
$Administration = new COM("PHPTest.Administration") or die("huh?");
$Customer = new COM("PHPTest.Customer") or die("what?");
echo $Customer->Connect( $Administration ); // Huge error
[2004-04-29 16:12:20] [EMAIL PROTECTED]
The test materials you supplied worked just fine.
[2004-04-29 15:14:47] arnout at argeweb dot nl
The problem's still there.
Fatal error: Uncaught exception 'com_exception' with message 'Source:
PHPTest
Description: Can not call friend function on object which is not an
instance of defining class' in C:\Program Files\Apache
Group\Apache2\htdocs\phptest.php:32 Stack trace: #0 {main} thrown in
C:\Program Files\Apache Group\Apache2\htdocs\phptest.php on line 32
[2004-04-28 17:12:42] [EMAIL PROTECTED]
Maybe its about time I read the version field of this report.
This problem won't be fixed in PHP 4, but already works just fine in
PHP 5.
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/28179
--
Edit this bug report at http://bugs.php.net/?id=28179&edit=1
#28259 [NEW]: Getimagesize doesn't support flash7 swf
From: iljamaas at dreamsolution dot nl
Operating system: FreeBSD 4.9-STABLE
PHP version: 4.3.4
PHP Bug Type: GetImageSize related
Bug description: Getimagesize doesn't support flash7 swf
Description:
I tried to run getimagesize on a flash7 .swf file and it results in a
'Error message: getimagesize(): Read error!
'
The script works fine with any other swf (and other graphics) format.
Reproduce code:
---
$info=GetImageSize('test.swf');
Expected result:
It's expected to get the file's size and return an array filled with the
values.
Actual result:
--
It throws an error: 'getimagesize(): Read error!'
and return an array with all values '0'.
--
Edit bug report at http://bugs.php.net/?id=28259&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28259&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28259&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28259&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28259&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28259&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28259&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28259&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28259&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28259&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28259&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28259&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28259&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28259&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28259&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28259&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28259&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28259&r=float
#28255 [Com]: DLL directory missing
ID: 28255 Comment by: bart at mediawave dot nl Reported By: pburden98 at yahoo dot com Status: Open Bug Type: *Configuration Issues Operating System: windows 98 2nd Edition PHP Version: 5.0.0RC2 New Comment: I'm not an official bugs administrator but I might know the answer. I think they moved the files in the dlls directory into the main directory. (Where php.exe is) As far as I know, with PHP5, you don't need to copy/move any files to your windows and system32 directories anymore. Just extract the zipfile into a directory. Edit php.ini. Create the mappings in IIS. (.php > C:\your-installation-dir\php.exe). Restart IIS. And it should work. Also, make sure that you remove any php files from your windows and system32 directory from previous PHP installations. Previous Comments: [2004-05-02 20:20:47] pburden98 at yahoo dot com That is line 158 of INSTALL doc in the php-5.0.0RC2-Win32.zip [2004-05-02 20:18:49] pburden98 at yahoo dot com Description: Line 158 down explains : Please copy the bundled dlls from the 'dlls/' directory... Ok. Where is this directory? Reproduce code: --- Unpack php-5.0.0RC2-Win32.zip and will find no dll directory. Expected result: The dll directory in the archive. Actual result: -- No dll directory -- Edit this bug report at http://bugs.php.net/?id=28255&edit=1
#21441 [Com]: POST-ed array repeats itself
ID: 21441 Comment by: richardks666 at hotmail dot com Reported By: szabo_a at interware dot hu Status: Bogus Bug Type: Apache2 related Operating System: RH 8.0 Apache 2.0 PHP Version: 4CVS-2003-01-20 (stable) New Comment: Not to be bold or anything, but this bug still appears in PHP5 RC2, using Apache 2.0.40 on RH9. However, I'm at another thread discussing, regarding wrongly configure "AddType" and the handlers setting the LimitRequestBody in php.conf under /etc/httpd/conf.d/. Previous Comments: [2003-01-21 03:37:54] [EMAIL PROTECTED] To avoid confusions, let me mark this one as bogus. Thanks for you cooperation. [2003-01-21 03:34:04] [EMAIL PROTECTED] Excuse me, but this report is actually the dupe of bug #18648. Could you report the further info at that page? We're investigating this issue now. Moriyoshi [2003-01-21 03:01:07] szabo_a at interware dot hu The problem is that since then I upgraded to the latest CVS version (4.3.1-dev), and the problem still exists: Example: http://www.parbanszep.hu/aa.php Enter some text and submit. You will see what comes back. And the php source is: If I use GET instead of POST it seams to be OK. So this is not an array, but rather a POST related bug. Further info: http://www.parbanszep.hu/info.php [2003-01-21 02:50:22] seper at interia dot pl i use the current releas version -> 4.3.0 on redhat-8.0 with apache 2.0.43 and get the same error. - - input string>tralalala $HTTP_POST_VARS['szuk'] tralalalaszuk=tralalalala [2003-01-06 12:11:11] white at blutkonserver dot de Hi, i use the current releas version -> 4.3.0 on redhat-8.0 with apache 2.0.43 and get the same error. here is another example \$_POST "; print_r($_POST); echo "\n\$_GET "; print_r($_GET); echo ""; ?> chbox 1 chbox 2 chbox 3 chbox 4 chbox 5 output (all checkboxes selected): $_POST Array ( [chkTest] => Array ( [0] => chbox 1 [1] => chbox 2 [2] => chbox 3 [3] => chbox 4 [4] => chbox 5 [5] => chbox 2 [6] => chbox 3 [7] => chbox 4 [8] => chbox 5 ) [submit] => submit ) $_GET Array ( ) When I replace the POST wit GET it works fine. cya later /Stephan 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/21441 -- Edit this bug report at http://bugs.php.net/?id=21441&edit=1
#28179 [Opn->Csd]: [COM] passing classes as a parameter
ID: 28179
Updated by: [EMAIL PROTECTED]
Reported By: arnout at argeweb dot nl
-Status: Open
+Status: Closed
Bug Type: COM related
Operating System: Windows NT 5.2 / Windows 2003
PHP Version: PHP Version 5.0.0RC2
Previous Comments:
[2004-05-03 12:57:14] arnout at argeweb dot nl
I've got it running now too. It only works if you import the DLL like
'event classes' instead of 'components'.
The real DLL by the way didn't work until I removed it all from the
COM+ manager and run regsvr32.exe on it.
[2004-04-30 11:45:36] [EMAIL PROTECTED]
What user account is Apache running under?
Does it make a difference if you run it as a different user?
[2004-04-29 16:45:39] arnout at argeweb dot nl
I'm using Apache 2 and run 5.0.0RC2 as a module. Maybe that makes some
difference?
$Administration = new COM("PHPTest.Administration") or die("huh?");
$Customer = new COM("PHPTest.Customer") or die("what?");
echo $Customer->Connect( $Administration ); // Huge error
[2004-04-29 16:12:20] [EMAIL PROTECTED]
The test materials you supplied worked just fine.
[2004-04-29 15:14:47] arnout at argeweb dot nl
The problem's still there.
Fatal error: Uncaught exception 'com_exception' with message 'Source:
PHPTest
Description: Can not call friend function on object which is not an
instance of defining class' in C:\Program Files\Apache
Group\Apache2\htdocs\phptest.php:32 Stack trace: #0 {main} thrown in
C:\Program Files\Apache Group\Apache2\htdocs\phptest.php on line 32
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/28179
--
Edit this bug report at http://bugs.php.net/?id=28179&edit=1
#28260 [NEW]: readfile + session_start results in huge memory consumption
From: mb at diderot dot de Operating system: Linux PHP version: 4.3.6 PHP Bug Type: Session related Bug description: readfile + session_start results in huge memory consumption Description: When using readfile or fread in combination with session_start php seems to allocate memory for the whole filesize. Without session_start it doesn't. Replacing readfile by a fread loop doesn't make any difference. Reproduce code: --- memory_limit ?> memory_limit ?> Expected result: Memory consumation should stay much bellow the whole filesize as it does without sessions. Actual result: -- apache error.log: Allowed memory size of 16777216 bytes exhausted (tried to allocate 138188800 bytes) -- Edit bug report at http://bugs.php.net/?id=28260&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28260&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28260&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28260&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28260&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28260&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28260&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28260&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28260&r=support Expected behavior: http://bugs.php.net/fix.php?id=28260&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28260&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28260&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28260&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28260&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28260&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28260&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28260&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28260&r=float
#28260 [Opn]: readfile + session_start results in huge memory consumption
ID: 28260 User updated by: mb at diderot dot de Reported By: mb at diderot dot de Status: Open Bug Type: Session related Operating System: Linux PHP Version: 4.3.6 New Comment: With php5 this just works fine ;) Previous Comments: [2004-05-03 15:16:58] mb at diderot dot de Description: When using readfile or fread in combination with session_start php seems to allocate memory for the whole filesize. Without session_start it doesn't. Replacing readfile by a fread loop doesn't make any difference. Reproduce code: --- memory_limit ?> memory_limit ?> Expected result: Memory consumation should stay much bellow the whole filesize as it does without sessions. Actual result: -- apache error.log: Allowed memory size of 16777216 bytes exhausted (tried to allocate 138188800 bytes) -- Edit this bug report at http://bugs.php.net/?id=28260&edit=1
#28261 [NEW]: Lifting reserved keyword restriction for method names
From: Philippe dot Jausions at 11abacus dot com Operating system: Irrelevant PHP version: Irrelevant PHP Bug Type: Class/Object related Bug description: Lifting reserved keyword restriction for method names 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 bug report at http://bugs.php.net/?id=28261&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28261&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28261&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28261&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28261&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28261&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28261&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28261&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28261&r=support Expected behavior: http://bugs.php.net/fix.php?id=28261&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28261&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28261&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28261&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28261&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28261&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28261&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28261&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28261&r=float
#28262 [NEW]: PHP Binary version of Curl Broken
From: dac514 at sympatico dot ca Operating system: Windows 2000 PHP version: 4.3.6 PHP Bug Type: cURL related Bug description: PHP Binary version of Curl Broken Description: This is a follow up to the (incorrectly marked) bogus Bug #28168. After discussing in the php.general newsgroup. I have come to the conclusion that the Windows binary distribution of PHP 4.3.6 includes a broken php_curl.dll The binary in question was obtained via: http://www.php.net/get/php-4.3.6-Win32.zip/from/a/mirror Reproduce code: --- http://www.vegguide.org/plain/rss-code/get_and_parse_vegguide_rss_feed-php (Requires an account to be able to download RSS data) The problem is the follwing 2 lines: curl_setopt($c, CURLOPT_ENCODING, 'gzip'); $data = curl_exec($c); Expected result: $data should be a string. Actual result: -- $data is GZIP compressed binary data. NB: A user in the newsgroup reported that the code still works on Linux. Prior to 4.3.6 the above also used to work on Windows, it no longer does. -- Edit bug report at http://bugs.php.net/?id=28262&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28262&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28262&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28262&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28262&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28262&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28262&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28262&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28262&r=support Expected behavior: http://bugs.php.net/fix.php?id=28262&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28262&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28262&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28262&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28262&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28262&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28262&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28262&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28262&r=float
#28259 [Opn->Fbk]: Getimagesize doesn't support flash7 swf
ID: 28259
Updated by: [EMAIL PROTECTED]
Reported By: iljamaas at dreamsolution dot nl
-Status: Open
+Status: Feedback
Bug Type: GetImageSize related
Operating System: FreeBSD 4.9-STABLE
PHP Version: 4.3.4
New Comment:
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
Thank you for your interest in PHP.
Please provide a sample swf file.
Previous Comments:
[2004-05-03 13:02:49] iljamaas at dreamsolution dot nl
Description:
I tried to run getimagesize on a flash7 .swf file and it results in a
'Error message: getimagesize(): Read error!
'
The script works fine with any other swf (and other graphics) format.
Reproduce code:
---
$info=GetImageSize('test.swf');
Expected result:
It's expected to get the file's size and return an array filled with
the values.
Actual result:
--
It throws an error: 'getimagesize(): Read error!'
and return an array with all values '0'.
--
Edit this bug report at http://bugs.php.net/?id=28259&edit=1
#28259 [Fbk->Bgs]: Getimagesize doesn't support flash7 swf
ID: 28259
Updated by: [EMAIL PROTECTED]
Reported By: iljamaas at dreamsolution dot nl
-Status: Feedback
+Status: Bogus
Bug Type: GetImageSize related
Operating System: FreeBSD 4.9-STABLE
PHP Version: 4.3.4
New Comment:
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP --
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php
If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.
.
Previous Comments:
[2004-05-03 18:26:43] [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 swf file.
[2004-05-03 13:02:49] iljamaas at dreamsolution dot nl
Description:
I tried to run getimagesize on a flash7 .swf file and it results in a
'Error message: getimagesize(): Read error!
'
The script works fine with any other swf (and other graphics) format.
Reproduce code:
---
$info=GetImageSize('test.swf');
Expected result:
It's expected to get the file's size and return an array filled with
the values.
Actual result:
--
It throws an error: 'getimagesize(): Read error!'
and return an array with all values '0'.
--
Edit this bug report at http://bugs.php.net/?id=28259&edit=1
#28252 [Opn]: ncurses support without a cygwin install.
ID: 28252 User updated by: testic at testic dot demon dot co dot uk Reported By: testic at testic dot demon dot co dot uk Status: Open Bug Type: Feature/Change Request Operating System: Win32 PHP Version: 4.3.4 New Comment: Well, unfortunatley compiling with Cygwin is a bit beyond me. However I would still like to make this a formal request, admittedly for a feature not many other people would need. But still, there we have. Previous Comments: [2004-05-02 15:51:02] testic at testic dot demon dot co dot uk That's a very good point, I will look into it. [2004-05-02 15:46:37] [EMAIL PROTECTED] Why not simply compile PHP under cygwin too? [2004-05-02 14:53:50] testic at testic dot demon dot co dot uk Description: I am working on an application written in PHP that uses the ncurses functions, I would like this application to work on win32 machines also. However, I dont want the users required to have a fullblown cygwin install (this is fiddly at best, and win32 users). I have seen applications written in C for Unix that make use of cygwin.dll and/or cygwindevo.dll, presumably to get Unix-like functionality on Windows, however I have been unable to make any use of this with PHP. So really my request could be summarised thus: Ncurses functioning 'natively' under Win32, without the need for cygwin, preferably implemented using an extension dll as per other PHP extensions in Windows. -- Edit this bug report at http://bugs.php.net/?id=28252&edit=1
#28263 [NEW]: PNG image generation causes Segmentation Fault
From: Rich dot West at wesmo dot com Operating system: Fedora Core 1 PHP version: 4.3.6 PHP Bug Type: GD related Bug description: PNG image generation causes Segmentation Fault Description: After upgrading from PHP 4.3.3 to 4.3.5, and then again to 4.3.6, I discovered that image generation calls to create PNG files were producing zero length images. I dug through it further by testing with the CLI version of PHP, and it appears that if a PNG image is being created, the process with segfault. I was able to compile PHP 4.3.3 on this machine using the configure options below, and, after running the test script through php, it would properly output a PNG file. Using the same configure options for PHP 4.3.5 and PHP 4.3.6, the operation segfaults (and creates a core file) when creating a PNG file. It works just fine when creating a JPEG file. I can consistently get things to work for PHP 4.3.3 and I can consistently get it to NOT work for PHP 4.3.5 and PHP 4.3.6... Oh, and, yes, my GD and libpng10/libpng libraries are linked properly.. >From phpinfo(): './configure' '--host=i686-pc-linux-gnu' '--build=i686-pc-linux-gnu' '--target=i386-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib' '--libexecdir=/usr/libexec' '--localstatedir=/var' '--sharedstatedir=/usr/com' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--cache-file=../config.cache' '--with-config-file-path=/etc' '--with-config-file-scan-dir=/etc/php.d' '--enable-force-cgi-redirect' '--disable-debug' '--enable-pic' '--disable-rpath' '--enable-inline-optimization' '--with-bz2' '--with-db4=/usr' '--with-curl' '--with-exec-dir=/usr/bin' '--with-freetype-dir=/usr' '--with-png-dir=/usr' '--with-gd' '--enable-gd-native-ttf' '--with-gdbm' '--with-gettext' '--with-ncurses' '--with-gmp' '--with-iconv' '--with-jpeg-dir=/usr' '--with-openssl' '--with-png' '--with-pspell' '--with-regex=system' '--with-xml' '--with-expat-dir=/usr' '--with-dom=shared,/usr' '--with-dom-xslt=/usr' '--with-dom-exslt=/usr' '--with-xmlrpc=shared' '--with-pcre=/usr' '--with-zlib' '--with-layout=GNU' '--enable-bcmath' '--enable-exif' '--enable-ftp' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sockets' '--enable-sysvsem' '--enable-sysvshm' '--enable-discard-path' '--enable-track-vars' '--enable-trans-sid' '--enable-yp' '--enable-wddx' '--without-oci8' '--with-pear=/usr/share/pear' '--with-imap=shared' '--with-imap-ssl' '--with-kerberos' '--with-ldap=shared' '--with-pdflib' '--with-mysql=shared,/usr' '--with-pgsql=shared' '--with-snmp=shared,/usr' '--with-snmp=shared' '--enable-ucd-snmp-hack' '--with-unixODBC=shared' '--enable-memory-limit' '--enable-bcmath' '--enable-shmop' '--enable-calendar' '--enable-dbx' '--enable-dio' '--enable-mcal' '--enable-mbstring' '--enable-mbstr-enc-trans' '--enable-mbregex' '--with-apxs2=/usr/sbin/apxs' Reproduce code: --- Expected result: Result should have been a PNG image. Actual result: -- #0 0x2009 in ?? () #1 0x00f1d850 in png_create_struct_2 () from /usr/lib/libpdf.so.1 #2 0x00997dcd in png_create_info_struct () from /usr/lib/libpng12.so.0 #3 0x080c1b72 in gdImageCreateFromPngCtx () #4 0x080c1a61 in gdImageCreateFromPng () #5 0x080af917 in zif_imagecreatefromstring () #6 0x080afbea in zif_imagecreatefrompng () #7 0x0a11aa34 in ?? () -- Edit bug report at http://bugs.php.net/?id=28263&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28263&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28263&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28263&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28263&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28263&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28263&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28263&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28263&r=support Expected behavior: http://bugs.php.net/fix.php?id=28263&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28263&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28263&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28263&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28263&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28263&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28263&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28263&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28263&r=float
#28157 [Com]: error: storage size of `obj' isn't known
ID: 28157 Comment by: mose at netvision dot net dot il Reported By: ralf at kuerbis dot org Status: Open Bug Type: Compile Failure Operating System: Solaris 9 PHP Version: 5CVS-2004-04-26 (dev) New Comment: The compliation error comes from the lack of these lines: /* * shorthand type definitions for unsigned storage classes */ typedef uchar_t uchar; typedef ushort_tushort; typedef uint_t uint; typedef ulong_t ulong; in sys/types For me (OSF4.0f) it's under 'ifndef _XOPEN_SOURCE_EXTENDED' control. Previous Comments: [2004-04-29 12:30:01] ralf at kuerbis dot org If you need my help in testing on a Solaris 9 machine (Ultra 1 at home and some Enterprise 420R/220R at business), just drop me a mail. Best regards, Ralf [2004-04-29 12:16:28] [EMAIL PROTECTED] This probably isn't portable to eg: Linux, so we still need to find a better fix; however, I no longer have access to a Solaris 9 machine, so this could prove difficult. [2004-04-29 11:05:26] ralf at kuerbis dot org It works - thank you! Regards, Ralf [2004-04-28 22:52:23] pds+php at alloy dot net In ext/standard/proc_open.c, adding the following lines before #define _XOPEN_SOURCE and #define _BSD_SOURCE gets around this compile problem: #include #include [2004-04-26 15:42:14] ralf at kuerbis dot org Description: Hi! Trying to compile the PHP5 RC2 version on Solaris 9, the compile run breaks with following error: [...] /opt/sunsite/compile/production/php5-200404261230/ext/standard/proc_open.c:876: error: dereferencing pointer to incomplete type /opt/sunsite/compile/production/php5-200404261230/ext/standard/proc_open.c:898: error: dereferencing pointer to incomplete type [...many, many more...] /opt/sunsite/compile/production/php5-200404261230/ext/standard/proc_open.c:898: error: dereferencing pointer to incomplete type /opt/sunsite/compile/production/php5-200404261230/ext/standard/proc_open.c: At top level: /opt/sunsite/compile/production/php5-200404261230/Zend/zend.h:283: error: storage size of `obj' isn't known make: *** [ext/standard/proc_open.lo] Error 1 gcc --version gcc (GCC) 3.3.2 (from sunfreeware.com) uname -a SunOS groundzero 5.9 Generic_112233-11 sun4u sparc SUNW,Ultra-60 Here the configure options (copied from config.nice...): CFLAGS='-I/usr/include' \ LDFLAGS='-lstdc++' \ CC='gcc' \ './configure' \ '--prefix=/opt/www' \ '--with-apxs=/opt/www/bin/apxs' \ '--with-mysql=/opt/mysql' \ '--with-sockets' \ '--enable-memory-limit' \ '--enable-trans-sid' \ '--sysconfdir=/opt/www/conf' \ '--with-config-file-path=/opt/www/conf' \ '--with-mcrypt=/usr/local' \ '--with-tsrm-pthreads' \ '--with-gnu-ld' \ '--with-dom=/usr/local' \ '--with-dom-xslt=/usr/local' \ '--with-dom-exslt' \ '--with-libxml-dir=/usr/local' \ '--enable-xslt' \ '--with-gd' \ '--with-zlib=/usr/local' \ '--with-xsl=/usr/local' \ As you can see above, this happens with the newest CVS and the RC2 version, but not with RC1. The RC1 runs perfectly on the same machine since one week or so. If you need further info or some testing, please tell me. Best regards, Ralf -- Edit this bug report at http://bugs.php.net/?id=28157&edit=1
#28227 [Com]: PHP CGI depends upon non-standard SCRIPT_FILENAME
ID: 28227 Comment by: shane at caraveo dot com Reported By: lukem at NetBSD dot org Status: Assigned Bug Type: CGI related Operating System: NetBSD 2.0C PHP Version: 4.3.6 Assigned To: shane New Comment: The current code does not rely on script_filename, script_filename is only used as a shortcut if it is available. Otherwise, the init function tries to determine the real script path, IF the fix_pathinfo ini setting is on. The current code was only tested under apache and iis. That said, the patch looks ok, and very likely improves the situation, but needs some good testing on apache/mod_php, apache/cgi, iis/isapi and iis/cgi, with various changes of configuration in php.ini (discard path, fix pathinfo, etc.). Unfortunately I have zero time. -Shane Previous Comments: [2004-05-03 11:59:41] [EMAIL PROTECTED] Shane, can you please take a look when you have a moment? [2004-05-03 04:25:48] lukem at NetBSD dot org Here's the patch: http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/pkgsrc/www/php4/patches/patch-aa?rev=1.10&content-type=text/plain [2004-04-30 02:11:47] lukem at NetBSD dot org Description: I upgraded PHP from 4.2.3 to 4.3.6 and I started getting the error "No input file specified." from the php-as-cgi whilst running under a (fairly minimal and small) web server called bozohttpd. Further investigation reveals that sapi/cgi/cgi_main.c::init_request_info() is using the existance of SCRIPT_FILENAME to determine if php is running as a CGI. However, the "defacto standard" for CGI/1.1: http://cgi-spec.golux.com/ makes no mention of SCRIPT_FILENAME, only SCRIPT_NAME. Thus, when a web server that is used to run php as a CGI doesn't support SCRIPT_FILENAME (which is reasonable - see the specs above), php refuses to function and fails with the error above. Some research into other web servers indicates that none of them support SCRIPT_FILENAME. These servers include: thttpd, mini_httpd, w3c-httpd, OmniHTTPd - (PHP PR 25833), Xitami (PHP PR 25305) This issue is also alluded to in the "command line" documentation on your web site: http://www.php.net/features.commandline (search for "no input file"). In summary, PHP 4.3.6 should not be relying solely upon SCRIPT_FILENAME to determine if it's running as a CGI. I have a patch to fix this issue - rev 1.10 of NetBSD's pkgsrc/www/php4/patches/patch-aa - which I can provide if necessary. Cheers, Luke Mewburn. -- Edit this bug report at http://bugs.php.net/?id=28227&edit=1
#23988 [Com]: php_imap require secur32.dll that don't exist on NT4
ID: 23988 Comment by: tor at helland dot org Reported By: brunofr at ioda dot net Status: Wont fix Bug Type: IMAP related Operating System: NT4.0 SP6a PHP Version: 4.3.2 Assigned To: edink New Comment: I think the workaround for this bug is simple: http://support.microsoft.com/default.aspx?scid=kb;en-us;288358 contains a download of "Active Directory Client Extension for NT4", called DSClient.exe. The file installs secur32.dll on the system. The page also explains how to install the files without any user interface components. Can't say I have tested it, but i got no error when enabling the imap extension. (Warning: This advice comes from a php newbie ;-) Previous Comments: [2003-07-28 10:28:19] mail at harsha dot ms Is there any workaround other than using PHP4.3.2RC4. ~ harsha [2003-06-29 19:13:35] [EMAIL PROTECTED] NT4 support has been discontinued by MS, I guess we might as well follow suit. [2003-06-06 00:47:38] [EMAIL PROTECTED] Is NT even supported by Microsoft anymore? :) [2003-06-05 10:21:08] brunofr at ioda dot net Thanks for the tip, that's what i've done on this server. The trouble was publish to help people. [2003-06-05 10:01:50] [EMAIL PROTECTED] I will have a closer look, but I did upgrade c-client prior to 4.3.2 final release in order to enable ssl connections. As a workaround you can safely use php_imap.dll from RC4 distro as there were no code changes between RC4 and final. 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/23988 -- Edit this bug report at http://bugs.php.net/?id=23988&edit=1
#27758 [Com]: High memory usage/leak
ID: 27758 Comment by: jpleveille at gameloft dot com Reported By: tingle at virtuanews dot co dot uk Status: Open Bug Type: Performance problem Operating System: Windows 2000 SP4 PHP Version: 5CVS-2004-03-29 (dev) New Comment: I noticed that on the RC2. Is that fixed? I got memory usage increased of 1 to 8 megabytes sometimes. Have to reload Apache every 10 minutes sometimes, annoying! JP. Previous Comments: [2004-04-18 10:35:57] tingle at virtuanews dot co dot uk Hi, Sorry for the delay - I was not in a position to download the latest CVS due to a very slow web connection, this has now changed and I have just downloaded the latest file. The problem is now MUCH better, but is still there slightly, where as before it would increase with about 500KB each refresh, it does it by about 50KB each time. It is not as bad, but it is still there [2004-04-12 17:56:11] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2004-04-07 05:25:35] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2004-03-29 15:05:54] tingle at virtuanews dot co dot uk Description: Hi, Whilst using PHP locally I am experiencing a major problem with memory usage. When I start up apache it uses around 15mb of memory (apache.exe that is) Now as a test I sat hitting refresh on the index page of phpmyadmin installed locally for a few minutes, and the memory usage of apache.exe reached 150mb +. It seems to be using a certain amount of memory to load the page, then not releasing it as the usage never goes down, only up with each page refresh. This issue does NOT happen with PHP4, I am using the latest CVS version of PHP5 compiled by you for windows. I also have apache 2.0.49 and mysql 4.0.18 installed. I realise this is a pretty usless bug report in terms of finding a solution, but that is because I do not know what to give you. Please let me know how I can help to solve this problem - I'm sure needed to restart apahe after every thousand or so page refreses due to memory usage of nearly 200mb is not the intended use of PHP! Thanks Tingle -- Edit this bug report at http://bugs.php.net/?id=27758&edit=1
#8063 [Com]: Call to undefined function: socket()
ID: 8063
Comment by: alovan at bellsoth dot net
Reported By: maeda-i at ceres dot ocn dot ne dot jp
Status: Closed
Bug Type: Sockets related
Operating System: winnt 4.0
PHP Version: 4.0.3pl1
New Comment:
i have yet to find my password that matches my yahoo i.d. which is
dazedandconfused_2 in the birth and country i may have entered the
wrong thing but i thought it was hotrox
Previous Comments:
[2000-12-30 17:47:31] [EMAIL PROTECTED]
think this one isnt a bug and should be closed.
James
[2000-12-03 00:07:32] [EMAIL PROTECTED]
Sockets are not yet supported on Windows.
--Jani
[2000-11-30 18:58:39] maeda-i at ceres dot ocn dot ne dot jp
/* TCP/IP\Pbgðì¬ */
$socket = socket(AF_INET, SOCK_STREAM, 0);
if ($socket < 0) {
echo "socket() failed: reason: " . strerror($socket) . "\n";
} else {
"socket() successful: " . strerror($socket) . "\n";
/* php.ini file */
[PHP]
;;;
; About this file ;
;;;
; This file controls many aspects of PHP's behavior. In order for PHP
to
; read it, it must be named 'php.ini'. PHP looks for it in the
current
; working directory, in the path designated by the environment
variable
; PHPRC, and in the path that was defined in compile time (in that
order).
; Under Windows, the compile-time path is the Windows directory. The
; path in which the php.ini file is looked for can be overriden using
; the -c argument in command line mode.
;
; The syntax of the file is extremely simple. Whitespace and Lines
; beginning with a semicolon are silently ignored (as you probably
guessed).
; Section headers (e.g. [Foo]) are also silently ignored, even though
; they might mean something in the future.
;
; Directives are specified using the following syntax:
; directive = value
; Directive names are *case sensitive* - foo=bar is different from
FOO=bar.
;
; The value can be a string, a number, a PHP constant (e.g. E_ALL or
M_PI), one
; of the INI constants (On, Off, True, False, Yes, No and None) or an
expression
; (e.g. E_ALL & ~E_NOTICE), or a quoted string ("foo").
;
; Expressions in the INI file are limited to bitwise operators and
parentheses:
; | bitwise OR
; & bitwise AND
; ~ bitwise NOT
; ! boolean NOT
;
; Boolean flags can be turned on using the values 1, On, True or Yes.
; They can be turned off using the values 0, Off, False or No.
;
; An empty string can be denoted by simply not writing anything after
the equal
; sign, or by using the None keyword:
;
; foo = ; sets foo to an empty string
; foo = none ; sets foo to an empty string
; foo = "none"; sets foo to the string 'none'
;
; If you use constants in your value, and these constants belong to a
dynamically
; loaded extension (either a PHP extension or a Zend extension), you
may only
; use these constants *after* the line that loads the extension.
;
; All the values in the php.ini-dist file correspond to the builtin
; defaults (that is, if no php.ini is used, or if you delete these
lines,
; the builtin defaults will be identical).
; Language Options ;
engine = On ; Enable the PHP scripting language engine
under Apache
short_open_tag = On ; allow the tags are recognized.
asp_tags= Off ; allow ASP-style <% %> tags
precision = 14 ; number of significant digits displayed in
floating
point numbers
y2k_compliance = Off ; whether to be year 2000 compliant (will cause
problems with non y2k compliant browsers)
output_buffering= Off ; Output buffering allows you to send header
lines (including cookies)
; even after you send body
content, in the price of slowing
PHP's
; output layer a bit.
; You can enable output
buffering by in runtime by calling the
output
; buffering functions, or
enable output buffering for all files
; by setting this directive to
On.
implicit_flush = Off ; Implicit flush tells PHP to tell the output
layer to flush itself
; automatically after every
output block. This is equivalent
to
; calling the PHP function
flush() after each and every call to
print()
#28265 [NEW]: Realpath, getcwd not returning true pathname
From: csaba at alum dot mit dot edu Operating system: Windows - all PHP version: 5CVS-2004-05-03 (dev) PHP Bug Type: Directory function related Bug description: Realpath, getcwd not returning true pathname 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 need some shoring up. Csaba Gabor Reproduce code: --- getcwd Problem "; chdir (strtolower($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> -- Edit bug report at http://bugs.php.net/?id=28265&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28265&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28265&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28265&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28265&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28265&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28265&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28265&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28265&r=support Expected behavior: http://bugs.php.net/fix.php?id=28265&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28265&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28265&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28265&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28265&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28265&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28265&r=isapi Install G
#28266 [NEW]: Bug Report 17822 has been corrupted
From: csaba at alum dot mit dot edu Operating system: N/A PHP version: Irrelevant PHP Bug Type: Unknown/Other Function Bug description: Bug Report 17822 has been corrupted Description: I submitted bug report 17822 a while back (18 Jun 2002). I came back to it this April and made an update to indicate that it is still a bug. The bug report (not the bug) subsequently desintegrated. In particular, it seems to have been reclassified, but of greater concern is that the developer's comments disappeared, the search page does not locate it under my name 'Csaba' (which is how I find my prior bug reports) NOR did it find it when I resubmitted the entire text under bug report 28265. You can get to the old (corrupted) report by http://bugs.php.net/17822 and the new (reposted) one by http://bugs.php.net/28265 Google is down to a single cached version of the earlier bug report (with all the original comments), so I had to act. I am filing this separately, since this report doesn't concern the substance of the bug. Csaba Gabor from Budapest -- Edit bug report at http://bugs.php.net/?id=28266&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28266&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28266&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28266&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28266&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28266&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28266&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28266&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28266&r=support Expected behavior: http://bugs.php.net/fix.php?id=28266&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28266&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28266&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28266&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28266&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28266&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28266&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28266&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28266&r=float
#28267 [NEW]: php_image_filter_contrast calls gdImageBrightness?
From: hannes at mediagonal dot ch
Operating system: Linux 2.6.5
PHP version: 5CVS-2004-05-04 (dev)
PHP Bug Type: GD related
Bug description: php_image_filter_contrast calls gdImageBrightness?
Description:
In http://lxr.php.net/source/php-src/ext/gd/gd.c#4064, the function
php_image_filter_contrast calls gdImageBrightness where it probably should
call gdImageContrast. This seems to work and seems to make sense, since
gdImageContrast does not seem to be called from anywhere else.
Reproduce code:
---
$img = imagecreatefromgif("http://images.slashdot.org/title.gif";);
imagefilter($img, 3, 50);
imagejpeg($img);
--
Edit bug report at http://bugs.php.net/?id=28267&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28267&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28267&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28267&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28267&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28267&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28267&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28267&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28267&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28267&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28267&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28267&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28267&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28267&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28267&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28267&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28267&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28267&r=float
#10376 [Com]: abnormal program termination on imap_body($box,0)
ID: 10376
Comment by: Pether123 at yahoo dot com
Reported By: akul at otamedia dot com
Status: Closed
Bug Type: IMAP related
Operating System: Windows 98 SE
PHP Version: 4.0.4pl1
New Comment:
How DO i fix this?
Previous Comments:
[2001-05-03 15:46:46] [EMAIL PROTECTED]
Fixed in 4.0.6-cvs.
[2001-04-18 08:32:17] akul at otamedia dot com
if(!$box=imap_open('{localhost/pop3:110}INBOX','mybox','mypassword'))
die('Can\'t Open box!');
// Here is abnormal program termination
// I think returning of NULL is better solution
// imap_header is Ok (warning is generated)
$B=imap_body($box,0);
imap_close($box);
for PHP.INI see the bug #9819
--
Edit this bug report at http://bugs.php.net/?id=10376&edit=1
#28269 [NEW]: Incomplete error message when instantiating child classes of an abstract class
From: phpbug at gb404 dot com Operating system: Gentoo Linux 2.4.23 PHP version: 5.0.0RC2 PHP Bug Type: Zend Engine 2 problem Bug description: Incomplete error message when instantiating child classes of an abstract class Description: When I try to instantiate a class which extends an abstract class but without implemented all defined abstract functions, this class becomes abstract too and fatal error message returned doesn't give any reason. Then it is very difficult to find which abstract function is not implemented as defined in the abstract parent class when there is a lot of abstract functions to implement. Is it possible to display a list of the missing function after the actual error message ? Reproduce code: --- Expected result: Fatal error: Cannot instantiate class b, abstract function parent::bar not implemented in /absolute/path/to/my/file/b.php on line 15 Actual result: -- Fatal error: Cannot instantiate abstract class b in /absolute/path/to/my/file/b.php on line 15 -- Edit bug report at http://bugs.php.net/?id=28269&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28269&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28269&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28269&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28269&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28269&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28269&r=needscript Try newer version: http://bugs.php.net/fix.php?id=28269&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28269&r=support Expected behavior: http://bugs.php.net/fix.php?id=28269&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28269&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28269&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28269&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28269&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28269&r=dst IIS Stability: http://bugs.php.net/fix.php?id=28269&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28269&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28269&r=float
#28268 [NEW]: Performance problem with require_once
From: webmaster at gamedrome dot com
Operating system: Windows 2003
PHP version: 4.3.6
PHP Bug Type: Performance problem
Bug description: Performance problem with require_once
Description:
See http://www.gamedrome.com/ and view the source of the HTML. You will
notice the last line:
0.084 seconds is the time it took to generate the page. I'm using a
content cache system based similar as Story Server (known as Vignette v6)
written in PHP.
Anyway, the problem also occurs with early versions of PHP too. At some
point, depending of the number of hits we have on the site, the parsing
time of a page goes up from around 0.070 to 0.500/1.000 secs for NO
apparent reason. Almost 10 times it is normal. The only way I can fix this
is by rebooting the server (windows 2003). I've tried restarting
apache(2.0.18) etc.
The performance goes down not of the parsing of code, but the time it
takes to include files. I have written these PHP code to do some speed
tests:
\n", lib_miscMicroTime2Float(microtime()) -
lib_miscMicroTime2Float($glbl["parse_started"])) . " secs";
$glbl["parse_started"] = microtime();
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_log/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_cache/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_adminmodule/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_adminsession/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/ws_languagetext/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/ws_membersession/LibrarySite.php");
printf("%.3f\n", lib_miscMicroTime2Float(microtime()) -
lib_miscMicroTime2Float($glbl["parse_started"])) . " secs";
?>
(you can find the output of this code here:
http://www.gamedrome.com/speedtest.php)
The first part of the freads an image of around 400k, 100 times. The
second part uses require_once on the libraries I use for my website. These
files dont produce output and only contain functions used for the
website.
During normal operations the times for the first part is between
0.120-0130 secs. The second part has times of 0.007, to require_once the
files.
If the performances 'bug' occurs, the times are much higher for the
require_once code than for the fread.
First part (the fread) is between 0.135 0.152 and the require_once
code is much higher: 0.058 0.070.
My conclusion is that there must be some bug in require_once code,
because loading a file doesnt slow down as much (about 10%), while the
require_once increase 800% in time. I've exclude my code or mysql
because in the speed test I only use PHP you see and the files include do
not produce any output.
To exclude the parsing of the included files, I'll create a test with
fread to read the include and use eval to test the speed.
I'm using Windows 2003 web edition, Apache 2.0.48 and PHP as FASTCGI.
Reproduce code:
---
Sorry can't reproduce... Just happens after a while..
Expected result:
none
Actual result:
--
Told you everything in the description.
--
Edit bug report at http://bugs.php.net/?id=28268&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28268&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28268&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28268&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28268&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28268&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28268&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28268&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28268&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28268&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28268&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28268&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28268&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28268&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28268&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28268&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28268&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28268&r=float
#28056 [Fbk->NoF]: [patch] ./buildconf doesn't work under Cygwin (Fixes #27140)
ID: 28056
Updated by: [EMAIL PROTECTED]
Reported By: jari dot aalto at poboxes dot com
-Status: Feedback
+Status: No Feedback
Bug Type: Compile Failure
Operating System: Win32 - W2ksp4
PHP Version: 4CVS-2004-04-19 (stable)
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-26 00:19:25] [EMAIL PROTECTED]
Provide an url to a patch file for easier applying of the patch..
[2004-04-19 13:31:47] jari dot aalto at poboxes dot com
Description:
cygwin included libtool in places which cannot be derived using the
current logic used in ./buildconf scripts.
Attached is a patch to make the ./buildconf succeed.
- Added DEBUG to make probing errors easier.
- Added tests for Cygwin.
- @'s were removed from Makefile to see what's
really going.
Using @ make it hard to report good errors. I don't
think they should be overly used as is the case in
current PHP make files.
Jari
Actual result:
--
cvs diff: warning: skipping invalid entry in password file at line 233
Index: buildcheck.sh
===
RCS file: /repository/php-src/build/buildcheck.sh,v
retrieving revision 1.21.2.6
diff -u -IId: -b -w -u -r1.21.2.6 buildcheck.sh
--- buildcheck.sh 28 Sep 2003 13:37:59 - 1.21.2.6
+++ buildcheck.sh 19 Apr 2004 11:23:36 -
@@ -21,6 +21,10 @@
echo "buildconf: checking installation..."
+if test "$DEBUG" ; then
+set -x
+fi
+
stamp=$1
# autoconf 2.13 or newer
@@ -80,6 +84,11 @@
ltpath=`echo $libtoolize | sed -e 's#/[^/]*/[^/]*$##'`
ltfile="$ltpath/share/aclocal/libtool.m4"
+
+if [ "$CYGWIN" ]; then
+ltfile=/usr/autotool/stable/share/aclocal/libtool.m4
+fi
+
if test -r "$ltfile"; then
:
else
cvs diff: warning: skipping invalid entry in password file at line 233
Index: buildconf
===
RCS file: /repository/php-src/buildconf,v
retrieving revision 1.57.4.2
diff -u -IId: -b -w -u -r1.57.4.2 buildconf
--- buildconf 25 Jun 2003 13:00:46 - 1.57.4.2
+++ buildconf 19 Apr 2004 11:24:41 -
@@ -1,6 +1,10 @@
#!/bin/sh
# $Id: buildconf,v 1.57.4.2 2003/06/25 13:00:46 sas Exp $
+if test "$DEBUG" ; then
+set -x
+fi
+
eval `grep '^EXTRA_VERSION=' configure.in`
case "$EXTRA_VERSION" in
*-dev)
@@ -62,3 +66,8 @@
rm -f generated_lists
${MAKE:-make} -s -f build/build.mk AMFLAGS="$automake_flags"
ZENDDIR="$ZENDDIR\
"
+
+if test "$DEBUG"; then
+# Show how make was called to pinpoint problems
+${MAKE:-make} -n -s -f build/build.mk AMFLAGS="$automake_flags"
ZENDDIR="$\
ZENDDIR"
+fi
Index: build2.mk
===
RCS file: /repository/php-src/build/build2.mk,v
retrieving revision 1.27.4.1
diff -u -IId: -b -w -u -r1.27.4.1 build2.mk
--- build2.mk 27 Jun 2003 00:19:26 - 1.27.4.1
+++ build2.mk 19 Apr 2004 11:25:42 -
@@ -46,19 +46,25 @@
# correctly otherwise (timestamps are not updated)
@echo rebuilding $@
@rm -f $@
- @autoheader 2>&1 | $(SUPPRESS_WARNINGS)
+ autoheader 2>&1 | $(SUPPRESS_WARNINGS)
$(TOUCH_FILES):
touch $(TOUCH_FILES)
aclocal.m4: configure.in acinclude.m4
- @echo rebuilding $@
- @libtoolize=`./build/shtool path glibtoolize libtoolize`; \
+ echo rebuilding $@
+ libtoolize=`./build/shtool path glibtoolize libtoolize`; \
$$libtoolize --copy --automake; \
ltpath=`dirname $$libtoolize`; \
- ltfile=`cd $$ltpath/../share/aclocal; pwd`/libtool.m4; \
+ if [ "$(CYGWIN)" ]; then \
+ cdpath=/usr/share; \
+ else \
+ cdpath=`cd $$ltpath/../share/aclocal; pwd`; \
+ fi; \
+ ltfile=$$cdpath/libtool.m4; \
+ echo $$cdpath; \
cat acinclude.m4 $$ltfile > $@
configure: aclocal.m4 configure.in $(config_m4_files)
@echo rebuilding $@
- @autoconf 2>&1 | $(SUPPRESS_WARNINGS)
+ autoconf 2>&1 | $(SUPPRESS_WARNINGS)
--
Edit this bug report at http://bugs.php.net/?id=28056&edit=1
#27990 [NoF->Opn]: sqlite_open() crashing Apache on non sqlite databases
ID: 27990
User updated by: csaba at alum dot mit dot edu
Reported By: csaba at alum dot mit dot edu
-Status: No Feedback
+Status: Open
Bug Type: SQLite related
Operating System: Win 2K
-PHP Version: 5.0.0RC1
+PHP Version: 5CVS-2004-05-03 (dev)
New Comment:
The good news is that the behaviour is markedly better. This time
instead of failing disastrously every other time, it only fails
petulantly every third time.
I tested this both as you asked with the CLI version and also running
PHP as a module. With the CLI version, testing on my small three file
directory, I got behaviour as expected: I got warnings on files SQLITE
didn't like and when I supressed them with the @ in front of
sqlite_open, the result was that I got a report of the single sqlite
database file in the directory. Very nice.
Thus encouraged, I went back to the original scenario and ran the same
file through a browser. Two out of three times, I get the same
behaviour as above. The third time around, however, I get the
following variable error message:
Fatal error: Unknown function: 8å() in C:\Morph\phpDev\php.php on line
28
There are two things I'd like to mention. The first is that the "text"
between the ': ' and ' in' seems to always be garbage characters, and
always different
For the second, I have to clear my throat a bit and mutter something
about Heisenberg's uncertainty principle. The only thing on that line
28 the error message is referring to is the function
sqlite_escape_string. (Ahem. Whenever I test, I submit the PHP code
through a preprocessor that logs the submission. This has been very
stable. The submission is stuffed into a temporary file and after the
logging is done, the browser gets back a header("Location: ...") to the
temporary file. (The directory that I was doing this sqlite testing on
is in a separate tree)).
Therefore, I also created a separate file with just the code I
submitted (surrounded in appropriate tags). The results there were not
so encouraging. Apache is still crashing, and PHP complains about
trivial things like it can't find this or that variable, always in the
dirList function on different lines. Let me know if you need more
info.
The good news is that I deal with this by opening up all the files I
find and scanning their header to see if they're SQLite files, and this
is working fine for me. Why can't SQLite do that? So, although this
problem isn't affecting me cause of my workaround, I figured you'd like
to know the current status of it on my machine.
Csaba Gabor
Previous Comments:
[2004-04-29 15:16:53] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
[2004-04-22 23:30:25] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
What you're trying to do will probably end in tears;
libsqlite has a tendency to clobber files that are not valid sqlite
databases (this is not a PHP problem).
It is possible that PHP is overly sensitive to such a problem, so could
you please try to reproduce this using
the CLI version of PHP?
Use a snapshot from the link above.
[2004-04-22 23:10:32] csaba at alum dot mit dot edu
I have tested this with the latest release (April 22 RC 2 beta), and it
still crashes Apache. However, I can be a bit more specific about the
symptoms. I tested on a directory with a small sqlite database log.db
(48K) and a log.php file (6K). Both files were required to produce the
crashing effect.
If I ran the code below (with or without an @ in front of the
sqlite_open) the first time I would get a warning about: database disk
image is malformed ...
(if the @ was not present, as with the code below).
The NEXT Time I invoked the same code is when the Apache would give me
the error message about restarting (and sometimes die). This happens
regardless of whether I remove log.php from the directory tree before
running the test the second time.
Csaba Gabor
[2004-04-21 00:15:23] [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.
--
#28264 [NEW]: SQLite not doing multiple queries
From: csaba at alum dot mit dot edu
Operating system: Win 2K Pro
PHP version: 5CVS-2004-05-03 (dev)
PHP Bug Type: SQLite related
Bug description: SQLite not doing multiple queries
Description:
The sqlite_query page in a prominent box declares that SQLite will execute
multiple queries separated by semicolons, but this seems not to be the
case according to the test below. While I posted a workaround for this,
it is not very efficient because you have to send each query separately.
I have tested the command line version of SQLite (2.8.13) and it does
accept multiple queries separated by semicolons.
Also, if dealing with this problem, I'd like to suggest that if the final
query is a SELECT or other statement which produces some result normally
destined for the user, that it be returned to the caller that way. The
documentation makes it seems like maybe it will and maybe it won't, saying
it's undefined. In particular, it would be helpful if SELECT and PRAGMA
returned their results. If you indulge me on that, please extend the
functionality to sqlite_array_query.
Thanks,
Csaba Gabor
Reproduce code:
---
$db = sqlite_open(':memory:', 0666, $sqliteerror);
$tbl = "delme";
$multiQuery = "CREATE TABLE $tbl (foo INTEGER PRIMARY KEY, bar TEXT);" .
"INSERT INTO $tbl VALUES (null, 'Hi Mom');";
$dbRes = sqlite_query ($db, $multiQuery);
$creationTest = "PRAGMA table_info('$tbl');";
$insertTest = "SELECT * FROM $tbl;";
$acT = sqlite_array_query ($db, $creationTest, SQLITE_ASSOC);
var_dump ($acT);
print "Table was created,";
$aiT = sqlite_array_query ($db, $insertTest, SQLITE_ASSOC);
var_dump ($aiT);
print "but nothing was inserted";
Expected result:
I expect to that the SQL INSERT statement was carried out
Actual result:
--
However, SQL statements after the first ';' seem to be ignored. Thus, the
second var_dump only gets an empty array.
--
Edit bug report at http://bugs.php.net/?id=28264&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28264&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28264&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28264&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28264&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28264&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28264&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28264&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28264&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28264&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28264&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28264&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28264&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28264&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28264&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28264&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28264&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28264&r=float
#28269 [Opn]: Incomplete error message when instantiating child classes of an abstract class
ID: 28269 User updated by: phpbug at gb404 dot com Reported By: phpbug at gb404 dot com Status: Open Bug Type: Zend Engine 2 problem -Operating System: Gentoo Linux 2.4.23 +Operating System: * PHP Version: 5.0.0RC2 New Comment: This is not specific to linux Previous Comments: [2004-05-04 03:43:23] phpbug at gb404 dot com Description: When I try to instantiate a class which extends an abstract class but without implemented all defined abstract functions, this class becomes abstract too and fatal error message returned doesn't give any reason. Then it is very difficult to find which abstract function is not implemented as defined in the abstract parent class when there is a lot of abstract functions to implement. Is it possible to display a list of the missing function after the actual error message ? Reproduce code: --- Expected result: Fatal error: Cannot instantiate class b, abstract function parent::bar not implemented in /absolute/path/to/my/file/b.php on line 15 Actual result: -- Fatal error: Cannot instantiate abstract class b in /absolute/path/to/my/file/b.php on line 15 -- Edit this bug report at http://bugs.php.net/?id=28269&edit=1
#28240 [Com]: class member assigment without declaration defines new member
ID: 28240 Comment by: phpbug at gb404 dot com Reported By: php at jort dot net Status: Open Bug Type: Class/Object related Operating System: Win2000 Pro PHP Version: 5.0.0RC2 New Comment: It is totally normal. As far as I can remember, PHP never needed to declare a variable before using it. Previous Comments: [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
#27961 [Com]: PHP Warning: Function registration failed - duplicate name
ID: 27961 Comment by: jalmacen at edgeprojects dot com Reported By: mikado at yahoo dot com Status: Bogus Bug Type: Dynamic loading Operating System: Linux 2.4.25-grsec PHP Version: 4.3.5 New Comment: This happens when you are loading the same module twice. Typically this is common when you load the module via /etc/php.ini and then you have separate .ini files in /etc/php.d/ like mysql.ini, odbc.ini, etc. You can fix this by either commenting out the line for the module in /etc/php.ini or /etc/php.d/*ini Hope this helps. Joy Almacen Previous Comments: [2004-04-12 23:19:03] mikado at 4vn dot org Sorry man, but cant find detail supports in your support section. You said that I had loaded extensions multiple times but it seems I loaded them ***OnE*** time for each of them! PS: YoUr ***SuPpOrT*** doesnt have any troubleshooting or some thing like that, just simply ***MiNiMaL*** documents! Mailling list huh? Someone also has this problem as me for a long time but They and I didnt receive any supports from ***YoU***, my ***php.net***! Thanks! PHP newbie! [2004-04-12 10:39:15] [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. You're just loading the same extension multiple times. [2004-04-12 10:06:49] mikado at yahoo dot com Description: I compiled PHP 4.3.5 with Apache 1.3.29 by following steps: ===:Pre-config Apache:=== ./configure \ --prefix=/usr \ --sbindir=/usr/sbin \ --libexecdir=/usr/libexec/apache \ --sysconfdir=/etc/apache \ --datadir=/home/www \ --runtimedir=/var/run \ --logfiledir=/var/log/apache \ --proxycachedir=/var/cache/proxy ===:Config + Install PHP:=== ./configure \ --prefix=/usr \ --sysconfdir=/etc \ --with-gnu-ld \ --with-apache=../apache_1.3.29 \ --enable-force-cgi-redirect \ --enable-discard-path \ --enable-fastcgi \ --with-config-file-path=/etc/php \ --with-config-file-scan-dir=/etc/php \ --disable-rpath \ --with-openssl=shared \ --with-zlib=shared \ --with-zlib-dir=/usr \ --with-bz2=shared \ --with-curl=shared \ --with-mysql=shared,/usr/local/mysql \ --enable-dba=shared \ --with-inifile \ --with-flatfile \ --with-dom=shared,/usr \ --with-dom-xslt=/usr \ --with-dom-exslt=/usr \ --with-fribidi=shared \ --with-gd=shared,/usr \ --with-jpeg-dir=/usr \ --with-png-dir=/usr \ --with-tiff-dir=/usr \ --with-xpm-dir=/usr/X11R6 \ --with-ttf \ --with-freetype-dir=/usr \ --with-t1lib \ --enable-gd-native-ttf \ --enable-gd-jis-conv \ --with-gettext=shared \ --with-gmp=shared \ --with-hyperwave=shared \ --with-iconv=shared \ --with-mime-magic=shared \ --with-ncurses=shared \ --with-pdpro=shared \ --with-pspell=shared \ --with-qtdom=shared \ --with-mm= \ --enable-bcmath=shared \ --enable-calendar=shared \ --enable-dbase=shared \ --enable-dbx=shared \ --enable-dio=shared \ --enable-exif=shared \ --enable-filepro=shared \ --enable-ftp=shared \ --enable-mstring=shared \ --enable-sockets \ --enable-sysvmsg=shared \ --enable-sysvsem=shared \ --enable-sysvshm=shared \ --enable-wddx=shared \ --enable-yp \ --enable-memory-limit \ --enable-zend-multibyte then make + make install ===:Config + Install Apache:=== ./configure \ --prefix=/usr \ --sbindir=/usr/sbin \ --libexecdir=/usr/libexec/apache \ --sysconfdir=/etc/apache \ --datadir=/home/www \ --runtimedir=/var/run \ --logfiledir=/var/log/apache \ --proxycachedir=/var/cache/proxy \ --disable-rule=SSL_COMPAT \ --activate-module=src/modules/php4/libphp4.a \ --enable-module=all \ --enable-shared=max \ --disable-module=example \ --enable-suexec \ --suexec-caller=httpd \ --suexec-docroot=/home/www/htdocs \ --suexec-logfile=/var/log/apache/suexec_log \ --suexec-userdir=web \ --suexec-uidmin=1 \ --suexec-gidmin=1 then make + make install ===:httpd.conf file:=== #... LoadModule php4_modulelibexec/apache/libphp4.so #... AddModule mod_php4.c #... AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps #... ===:php.ini file:=== ;... extension_dir = "/usr/lib/php/extensions/no-debug-non-zts-20020429" ;... extension=bcmath.so extension=bz2.so extension=calendar.so extension=curl.so extension=dba.so extension=dbase.so extension=dbx.so extension=dio.so extension=domxml.so extension=exif.so extension=filepro.so extension=fribidi.so extension=ftp.so extension=gd.so extension=gettext.so extension=gmp.so extension=iconv.so extension=mime_magic.so extension=mysql.so extension=ncurses.so extension=openssl.so extension=pspell.so extension=qtdom.so extension=sysvmsg.so extension=sysvsem.so e
#16787 [Com]: any call to error_log(...) crashes
ID: 16787 Comment by: leha2 at mail dot ru Reported By: tomas dot drbohlav at mff dot cuni dot cz Status: No Feedback Bug Type: Reproducible crash Operating System: UnixWare 7.1.1 PHP Version: 4.2.0 New Comment: Got the same issue when upgrading from PHP v.4.1.0 to 4.3.6 (and after that 4.3.6) on Win32 platform (WinXPProf+SP1). I run PHP as CGI in Apache v.1.3.22 (Win32). In php.ini error_log is commented, and log_errors = Off. When I was using PHP v.4.1.0 all "error_log(,0)" messages were forwarded to apache server log, but now PHP simply stalls, until I kill the process using Task Manager. PHP freezes only when zero is used as second parameter in error_log() call, i.e. "error_log(,3)" doesn't cause any trouble. If I set error_log to some file name or to syslog, no PHP freezes are encounter. As I'm using PHP as CGI, php.ini and php4ts.dll both reside in PHP root folder, not in %systemroot%/system32. Previous Comments: [2002-09-11 10:56:04] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2002-06-16 00:18:06] [EMAIL PROTECTED] I can not reproduce this..which Apache version do you have? And what do you mean by '--enable-debug' doesn't run? Have you checked your error_log what it says when you try to start? Do you load some extensions in php.ini ? [2002-04-24 07:24:26] tomas dot drbohlav at mff dot cuni dot cz Unfortunatelly I cannot generate backtrack: cgi version doesn't crash and Apache version with --enable-debug doesn't start at all ... :-( [2002-04-24 05:49:20] [EMAIL PROTECTED] To properly diagnose this bug, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". [2002-04-24 05:47:45] tomas dot drbohlav at mff dot cuni dot cz We have tried the new relase (PHP 4.2.0) and some of our pages segfaults. Consider such a simple code as: This crashes every time, independently on any auto_prepend setting (which we normally use). When you comments out the error_log call, page runs ok. I can perform some additinal test when nedded, looking forward for any interest. T :-) P.S.: Our config: './configure' '--with-oci8=/u01/app/oracle/product/8.1.7' '--with-apxs=/usr/local/apache.dbg/bin/apxs' '--without-mysql' '--enable-sigchild' '--build=i686-sco-sysv5uw7' -- Edit this bug report at http://bugs.php.net/?id=16787&edit=1
#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: 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. Previous Comments: [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. [2004-04-21 09:12:42] [EMAIL PROTECTED] Also, which webserver do you use? And if you want us to debug this, provide a short (max 10 lines!) reproducing script (or get the JPGraph author to do this). [2004-04-21 09:12:04] [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-21 00:44:49] doormat at sequence-omega dot net Description: Using the JPGraph library, when any graphs are created at the same time, and they use TrueType fonts, apache will crash. Switching away from the use of TrueType fonts helps, but occasional crashes still happen. The developer of JPGraph said the problem was in the underlying PHP implementation (http://jpgraph.fan-atics.com/viewtopic.php?t=1752) so I'd thought I'd file a bug report to see if ya'll could figure it out. Reproduce code: --- Too long to post... download sample code from http://www.aditus.nu/jpgraph/ and put multiple graphs (especially ones that use TTFs) on one page and load it up and apache should crash. -- Edit this bug report at http://bugs.php.net/?id=28084&edit=1
#28270 [NEW]: any call to error_log(...) crashes - revisited
From: leha2 at mail dot ru
Operating system: Win32 (in my case WinXPPro+SP1)
PHP version: 4.3.6
PHP Bug Type: Reproducible crash
Bug description: any call to error_log(...) crashes - revisited
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 bug report at http://bugs.php.net/?id=28270&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28270&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28270&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28270&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28270&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28270&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28270&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28270&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28270&r=support
Expected behavior: http://bugs.php.net/fix.php?id=28270&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28270&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28270&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28270&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28270&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28270&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28270&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28270&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28270&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: 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. Previous Comments: [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. [2004-04-21 09:12:42] [EMAIL PROTECTED] Also, which webserver do you use? And if you want us to debug this, provide a short (max 10 lines!) reproducing script (or get the JPGraph author to do this). [2004-04-21 09:12:04] [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. 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 [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: 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. Previous Comments: [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. [2004-04-21 09:12:42] [EMAIL PROTECTED] Also, which webserver do you use? And if you want us to debug this, provide a short (max 10 lines!) reproducing script (or get the JPGraph author to do this). 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
#28265 [Opn->Bgs]: Realpath, getcwd not returning true pathname
ID: 28265 Updated by: [EMAIL PROTECTED] Reported By: csaba at alum dot mit dot edu -Status: Open +Status: Bogus Bug Type: Directory function related Operating System: Windows - all PHP Version: 5CVS-2004-05-03 (dev) 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. It's also fixed. Previous Comments: [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 need some shoring up. Csaba Gabor Reproduce code: --- getcwd Problem "; chdir (strtolower($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); chdir (strtoupper($cwd)); print "" . getcwd(); print "" . realpath(getcwd()); ?> -- Edit this bug report at http://bugs.php.net/?id=28265&edit=1
#28267 [Opn->Asn]: php_image_filter_contrast calls gdImageBrightness?
ID: 28267
Updated by: [EMAIL PROTECTED]
Reported By: hannes at mediagonal dot ch
-Status: Open
+Status: Assigned
Bug Type: GD related
Operating System: Linux 2.6.5
PHP Version: 5CVS-2004-05-04 (dev)
-Assigned To:
+Assigned To: paj
New Comment:
Assigning to pierre.
Previous Comments:
[2004-05-04 01:22:07] hannes at mediagonal dot ch
Description:
In http://lxr.php.net/source/php-src/ext/gd/gd.c#4064, the function
php_image_filter_contrast calls gdImageBrightness where it probably
should call gdImageContrast. This seems to work and seems to make
sense, since gdImageContrast does not seem to be called from anywhere
else.
Reproduce code:
---
$img = imagecreatefromgif("http://images.slashdot.org/title.gif";);
imagefilter($img, 3, 50);
imagejpeg($img);
--
Edit this bug report at http://bugs.php.net/?id=28267&edit=1
#28266 [Opn->Bgs]: Bug Report 17822 has been corrupted
ID: 28266 Updated by: [EMAIL PROTECTED] Reported By: csaba at alum dot mit dot edu -Status: Open +Status: Bogus Bug Type: Unknown/Other Function Operating System: N/A PHP Version: Irrelevant New Comment: There is no way we can track this down, marking "bogus". Previous Comments: [2004-05-04 00:25:44] csaba at alum dot mit dot edu Description: I submitted bug report 17822 a while back (18 Jun 2002). I came back to it this April and made an update to indicate that it is still a bug. The bug report (not the bug) subsequently desintegrated. In particular, it seems to have been reclassified, but of greater concern is that the developer's comments disappeared, the search page does not locate it under my name 'Csaba' (which is how I find my prior bug reports) NOR did it find it when I resubmitted the entire text under bug report 28265. You can get to the old (corrupted) report by http://bugs.php.net/17822 and the new (reposted) one by http://bugs.php.net/28265 Google is down to a single cached version of the earlier bug report (with all the original comments), so I had to act. I am filing this separately, since this report doesn't concern the substance of the bug. Csaba Gabor from Budapest -- Edit this bug report at http://bugs.php.net/?id=28266&edit=1
#28268 [Opn->Bgs]: Performance problem with require_once
ID: 28268
Updated by: [EMAIL PROTECTED]
Reported By: webmaster at gamedrome dot com
-Status: Open
+Status: Bogus
Bug Type: Performance problem
Operating System: Windows 2003
PHP Version: 4.3.6
New Comment:
This bugreport is quite useles, no information on how to reproduce.
Stick with apache1 + mod_apache and preferrably a unix OS. Marking
Bogus unless you can provide us with info on how to reproduce
realiably.
Previous Comments:
[2004-05-04 02:36:33] webmaster at gamedrome dot com
Description:
See http://www.gamedrome.com/ and view the source of the HTML. You will
notice the last line:
0.084 seconds is the time it took to generate the page. I'm using a
content cache system based similar as Story Server (known as Vignette
v6) written in PHP.
Anyway, the problem also occurs with early versions of PHP too. At some
point, depending of the number of hits we have on the site, the parsing
time of a page goes up from around 0.070 to 0.500/1.000 secs for NO
apparent reason. Almost 10 times it is normal. The only way I can fix
this is by rebooting the server (windows 2003). I've tried restarting
apache(2.0.18) etc.
The performance goes down not of the parsing of code, but the time it
takes to include files. I have written these PHP code to do some speed
tests:
\n", lib_miscMicroTime2Float(microtime()) -
lib_miscMicroTime2Float($glbl["parse_started"])) . " secs";
$glbl["parse_started"] = microtime();
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_log/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_cache/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_adminmodule/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/system/sb_adminsession/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/ws_languagetext/LibrarySite.php");
require_once($_SERVER["DOCUMENT_ROOT"] .
"/admin/modules/ws_membersession/LibrarySite.php");
printf("%.3f\n", lib_miscMicroTime2Float(microtime()) -
lib_miscMicroTime2Float($glbl["parse_started"])) . " secs";
?>
(you can find the output of this code here:
http://www.gamedrome.com/speedtest.php)
The first part of the freads an image of around 400k, 100 times. The
second part uses require_once on the libraries I use for my website.
These files dont produce output and only contain functions used for
the website.
During normal operations the times for the first part is between
0.120-0130 secs. The second part has times of 0.007, to require_once
the files.
If the performances 'bug' occurs, the times are much higher for the
require_once code than for the fread.
First part (the fread) is between 0.135 0.152 and the require_once
code is much higher: 0.058 0.070.
My conclusion is that there must be some bug in require_once code,
because loading a file doesnt slow down as much (about 10%), while the
require_once increase 800% in time. I've exclude my code or mysql
because in the speed test I only use PHP you see and the files include
do not produce any output.
To exclude the parsing of the included files, I'll create a test with
fread to read the include and use eval to test the speed.
I'm using Windows 2003 web edition, Apache 2.0.48 and PHP as FASTCGI.
Reproduce code:
---
Sorry can't reproduce... Just happens after a while..
Expected result:
none
Actual result:
--
Told you everything in the description.
--
Edit this bug report at http://bugs.php.net/?id=28268&edit=1
