#41911 [NEW]: Passing string encapsulated in SimpleXMLElement to strtotime causes memory leak
From: irb at redwoodtech dot com
Operating system: Windows XP SP2
PHP version: 5.2.3
PHP Bug Type: Date/time related
Bug description: Passing string encapsulated in SimpleXMLElement to strtotime
causes memory leak
Description:
If a time string is to be read from a SimpleXML object and converted into
a unix timestamp then a memory leak occurs if the SimpleXML object is
passed directly to strtotime.
The memory leak can be stopped by type casting before passing the string
to strtotime. For example, change the relevant line in the reproduce code
to:
$lTime = strtotime ((string) $xml['timestamp']);
Reproduce code:
---
while(true)
{
$xml = new SimpleXMLElement('test timestamp=Thu, 5 Jul 2007 16:51:23
GMT/test');
echo 'Current Daemon Memory Usage is ' . memory_get_usage ( ) . bytes :
Before STRTOTIME\n;
$lTime = strtotime ($xml['timestamp']);
echo 'Current Daemon Memory Usage is ' . memory_get_usage ( ) . bytes :
After STRTOTIME\n;
}
Expected result:
The following is expected. The point being that the memory usage of the
application is constant.
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Actual result:
--
Memory usage increases over time.
Current Daemon Memory Usage is ___94240 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94400 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94440 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94600 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94640 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94800 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94840 bytes : After STRTOTIME
--
Edit bug report at http://bugs.php.net/?id=41911edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41911r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41911r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41911r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41911r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41911r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41911r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41911r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41911r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41911r=support
Expected behavior:http://bugs.php.net/fix.php?id=41911r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41911r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41911r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41911r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41911r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41911r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41911r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41911r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41911r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41911r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41911r=mysqlcfg
#41906 [Fbk-Opn]: slow local mysql_connect
ID: 41906 User updated by: kkr at mit dot de Reported By: kkr at mit dot de -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5.2.3 New Comment: Using todays CVS snapshot the problem still exists. Very slow mysql connection still takes 5-6 seconds. Previous Comments: [2007-07-05 21:59:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-05 15:56:22] kkr at mit dot de Description: Between 5.2.1 and 5.2.2 the PHP connects much slower to a local mysql5 installation running under apache/windows 2000. It now takes 5 seconds more to a simple connect which at least does work after that time. In the changelog I've seen a new mysql client lib used starting from 5.2.2 upwards, anyone else has these problems too? The 5.2.3 still has the same behavior. A connect is either via TCP or via named pipe/socket possible but slow. Local graphical frontends to the database are as fast as always. MySQL version is the latest released one 5.0.41. Reproduce code: --- the usual mysql_connect() Expected result: I expect a connect time from 200ms and experience 5500ms now. -- Edit this bug report at http://bugs.php.net/?id=41906edit=1
#41899 [Opn-Csd]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 Updated by: [EMAIL PROTECTED] Reported By: geoffwa at cs dot rmit dot edu dot au -Status: Open +Status: Closed Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 New Comment: Since it's fixed in CVS - closed. Previous Comments: [2007-07-06 01:03:53] geoffwa at cs dot rmit dot edu dot au Is also broken in 5.2.0 and 5.2.2. Appears to be fixed in latest snapshot: ./php-5.2-200707060030 -v PHP 5.2.4-dev (cli) (built: Jul 6 2007 10:59:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies ./php-5.2-200707060030 -f test.php Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file [2007-07-05 21:59:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-05 06:34:06] geoffwa at cs dot rmit dot edu dot au Description: (possibly related to bug #39953 or bug #39351) If a relative path to a file has '..' as a leading path component, and the directory referred to by '..' is not readable by the user, then opening a file using the relative path fails. Using an absolute path or a path with a non-'..' leading component opens said file just fine. Reproduce code: --- See http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php for a large test script. Expected result: (Using PHP 5.1.4) Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Actual result: -- (Using PHP 5.2.3 + suhosin patch) Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Failed to open ./a/b/file from ./a/b/c using ../file Failed to open ./a/b/file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Failed to open ./a/b/c/file from ./a/b/c using ../c/file -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#41912 [NEW]: date() interprets Unix timestamp as GMT and converts it to the default timezone
From: [EMAIL PROTECTED]
Operating system: Debian GNU/Linux
PHP version: 5.2.3
PHP Bug Type: Unknown/Other Function
Bug description: date() interprets Unix timestamp as GMT and converts it to
the default timezone
Description:
date() interprets a Unix timestamp as GMT and converts it to the default
timezone. In my opinion it should not convert timezones.
(bug report requested by Derick Rethans).
Reproduce code:
---
?php
date_default_timezone_set('Europe/Amsterdam');
$date = new DateTime('now', new DateTimeZone('GMT'));
echo 'DateTime::format(): '.$date-format('Ymd, H:i:s').\n;
echo 'date() of unixtime: '.date('Ymd, H:i:s', $date-format('U')).\n;
?
Expected result:
DateTime::format(): 20070706, 07:38:45
date() of unixtime: 20070706, 07:38:45
Actual result:
--
DateTime::format(): 20070706, 07:38:45
date() of unixtime: 20070706, 09:38:45
--
Edit bug report at http://bugs.php.net/?id=41912edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41912r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41912r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41912r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41912r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41912r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41912r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41912r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41912r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41912r=support
Expected behavior:http://bugs.php.net/fix.php?id=41912r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41912r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41912r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41912r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41912r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41912r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41912r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41912r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41912r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41912r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41912r=mysqlcfg
#41913 [NEW]: dbase functions return not all records from a dbf file
From: sdmaster at mail dot ru
Operating system: Windows XP SP2
PHP version: 5.2.3
PHP Bug Type: dBase related
Bug description: dbase functions return not all records from a dbf file
Description:
I'm using Apache 2.2.4, php 5.2.3 loaded with LoadModule. php_dbase
extension v5.2.3.3. Apache is run from a local administrator's account.
after I open a dbf file and use dbase_numrecords() to retrieve number of
records in the file, it returns a number that is randomly less than actual
by 1, 2 or 3. accordingly, dbase_get_record_with_names() doesn't want to
get, i.e., 23-th record from a 24-records dbf file.
a sample dbf file is created by Delphi 7 TDbf component v6.9 and contains
russian characters in string fields.
at the same time such tools as DBV Viewer or like show everything
correctly.
reference to the sample dbf file lies inside comments in the posted php
code.
Reproduce code:
---
?
/*
a simple php code, purely from examples
test file is generated by TDbf Delphi 7 component
a sample dbf file, which is reported by php dbase functions to
have 1 records less than actual, could be taken from here:
http://b64.hopto.org/test.dbf
*/
if ($db = dbase_open('c:\temp\test.dbf', 0)) {
$rn = dbase_numrecords($db);
for ($i = 1; $i=$rn; $i++) {
$row=dbase_get_record_with_names($db, $i);
print_r($row);
}
dbase_close($db);
}
?
Expected result:
all records from dbf file
Actual result:
--
all records except the last one
--
Edit bug report at http://bugs.php.net/?id=41913edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41913r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41913r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41913r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41913r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41913r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41913r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41913r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41913r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41913r=support
Expected behavior:http://bugs.php.net/fix.php?id=41913r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41913r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41913r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41913r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41913r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41913r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41913r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41913r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41913r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41913r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41913r=mysqlcfg
#41779 [Opn]: ftp_nlist() and ftp_rawlist() fail with open_basedir
ID: 41779 User updated by: derernst at gmx dot ch Reported By: derernst at gmx dot ch Status: Open Bug Type: Safe Mode/open_basedir Operating System: Linux PHP Version: 5.2.3 New Comment: The ISP informed me now that he will not install the snapshot as he does not have a test environment, and only wants to run stable releases. So I am sorry I am not able to provide feedback about the snapshot. Previous Comments: [2007-06-27 12:23:39] derernst at gmx dot ch I am working on shared hosting and don't have a server or a local PHP installation nor the knowledge how to maintain it. So I asked the ISP where the issue occurred to kindly try the new snapshot posted. I did not get an answer so far; if he does help with the test, I will post the results here as soon as possible. Anyway if there was someone else who does not mind testing the snapshot with correct open_basedir settings and ftp_nlist() or ftp_rawlist(), I would highly appreciate this. [2007-06-25 17:49:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-06-22 14:18:09] derernst at gmx dot ch Description: After my ISP upgraded to PHP 5.2.3 (sorry I don't know from which previous version), functions ftp_nlist() and ftp_rawlist() stopped working: PHP Warning: ftp_nlist() [function.ftp-nlist]: open_basedir restriction in effect. File(/var/tmp/) is not within the allowed path(s): (/data/htdocs/domain.com/:/usr/local/share/pear/:/tmp/:/var/tmp/) in ... Note that the required path does actually match an allowed paths entry: - File(/var/tmp/) - allowed path(s): (/data/htdocs/domain.com/:/usr/local/share/pear/:/tmp/:/var/tmp/) I found several bugs that might be related to this one, see bugs nr. 40141, 41518, 41684; bug 13720 describes the same phenomenon but assumably for an other reason. The functions work again after my ISP removed the trailing slashes from the open_basedir entries. This can't be a desirable solution, though! -- Edit this bug report at http://bugs.php.net/?id=41779edit=1
#41908 [Opn-Fbk]: CFLAGS=-Os ./configure --enable-debug fails
ID: 41908 Updated by: [EMAIL PROTECTED] Reported By: christian at hoffie dot info -Status: Open +Status: Feedback Bug Type: Compile Failure Operating System: Gentoo Linux PHP Version: 5.2.3 New Comment: does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? Apparently it doesn't. What does you config.log say about the reason of the failure? Previous Comments: [2007-07-05 17:06:17] christian at hoffie dot info Description: PHP's configure script incorrectly manipulates CFLAGS and CXXFLAGS when running with --enable-debug or --enable-gcov. When CFLAGS or CXXFLAGS contains -Os (optimize for size), the configure script builds a bad list of CFLAGS/CXXFLAGS and as such configure fails in a later stage. I created a small patch[1] which should solve that, I'm not completely sure whether it's a good idea to remove that -O stuff at all -- does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? [1] http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.3/5.2.3/php5.2.3-configure-Os-fix.patch?rev=1237 Reproduce code: --- CFLAGS=-Os ./configure --enable-debug (same if you replace CFLAGS by CXXFLAGS or --enable-debug with --enable-gcov) Actual result: -- [EMAIL PROTECTED] /tmp/php-5.2.3 $ env | grep FLAGS CXXFLAGS=-Os CFLAGS=-Os [EMAIL PROTECTED] /tmp/php-5.2.3 $ ./configure --disable-all --enable-debug [...] Configuring libtool checking build system type... i686-pc-linux-gnu checking for ld used by gcc... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for object suffix... configure: error: installation or configuration problem; compiler does not work Depending on ./configure options the output looks different. For example, with --with-xml you will see a libxml2 failure first. -- Edit this bug report at http://bugs.php.net/?id=41908edit=1
#41910 [Opn-Fbk]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
Updated by: [EMAIL PROTECTED]
Reported By: dan at novapulsar dot com
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
Previous Comments:
[2007-07-06 05:03:25] dan at novapulsar dot com
Description:
Since mysql_error() is documented to 'return' a string, I assumed it
would be safe to put it in either a string, or as an argument to an
error handling function.
Reproduce code:
---
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
$strSQL = select all from something will make an error duh;
$objResult = mysql_query ($strSQL) or die (fn_Save_Error('this.php',
mysql_error());
Expected result:
Expected result is that the string value of mysql_error() is passed as
an argument of datatype string whether blank or with contents to the
fn_Save_Error function.
Actual result:
--
Mysql_error() is output directly to the screen/console, instead of
being passed as a value to fn_Save_Error for custom error handling.
Based on the mysql_error() documentation it should not output the error
to screen, it should return it as a string, so that I could do this:
...some wrong query execution...
$error_message = mysql_error(); echo ($error_message);
$error_message should be == to $mysql_error, but instead it just
outputs to screen/console
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41906 [Opn-Bgs]: slow local mysql_connect
ID: 41906 Updated by: [EMAIL PROTECTED] Reported By: kkr at mit dot de -Status: Open +Status: Bogus Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5.2.3 New Comment: The connect is done by MySQL client library, not PHP. PHP just provides an interface to it and cannot make your connection faster if it's slow. Previous Comments: [2007-07-06 06:52:36] kkr at mit dot de Using todays CVS snapshot the problem still exists. Very slow mysql connection still takes 5-6 seconds. [2007-07-05 21:59:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-05 15:56:22] kkr at mit dot de Description: Between 5.2.1 and 5.2.2 the PHP connects much slower to a local mysql5 installation running under apache/windows 2000. It now takes 5 seconds more to a simple connect which at least does work after that time. In the changelog I've seen a new mysql client lib used starting from 5.2.2 upwards, anyone else has these problems too? The 5.2.3 still has the same behavior. A connect is either via TCP or via named pipe/socket possible but slow. Local graphical frontends to the database are as fast as always. MySQL version is the latest released one 5.0.41. Reproduce code: --- the usual mysql_connect() Expected result: I expect a connect time from 200ms and experience 5500ms now. -- Edit this bug report at http://bugs.php.net/?id=41906edit=1
#41912 [Opn-Asn]: date() interprets Unix timestamp as GMT and converts it to the default timezone
ID: 41912
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Date/time related
Operating System: Debian GNU/Linux
PHP Version: 5.2.3
-Assigned To:
+Assigned To: derick
Previous Comments:
[2007-07-06 08:21:10] [EMAIL PROTECTED]
Description:
date() interprets a Unix timestamp as GMT and converts it to the
default timezone. In my opinion it should not convert timezones.
(bug report requested by Derick Rethans).
Reproduce code:
---
?php
date_default_timezone_set('Europe/Amsterdam');
$date = new DateTime('now', new DateTimeZone('GMT'));
echo 'DateTime::format(): '.$date-format('Ymd, H:i:s').\n;
echo 'date() of unixtime: '.date('Ymd, H:i:s',
$date-format('U')).\n;
?
Expected result:
DateTime::format(): 20070706, 07:38:45
date() of unixtime: 20070706, 07:38:45
Actual result:
--
DateTime::format(): 20070706, 07:38:45
date() of unixtime: 20070706, 09:38:45
--
Edit this bug report at http://bugs.php.net/?id=41912edit=1
#41779 [Opn-Fbk]: ftp_nlist() and ftp_rawlist() fail with open_basedir
ID: 41779 Updated by: [EMAIL PROTECTED] Reported By: derernst at gmx dot ch -Status: Open +Status: Feedback Bug Type: Safe Mode/open_basedir Operating System: Linux PHP Version: 5.2.3 New Comment: You can safely install everything you want in your home directory. Previous Comments: [2007-07-06 08:33:48] derernst at gmx dot ch The ISP informed me now that he will not install the snapshot as he does not have a test environment, and only wants to run stable releases. So I am sorry I am not able to provide feedback about the snapshot. [2007-06-27 12:23:39] derernst at gmx dot ch I am working on shared hosting and don't have a server or a local PHP installation nor the knowledge how to maintain it. So I asked the ISP where the issue occurred to kindly try the new snapshot posted. I did not get an answer so far; if he does help with the test, I will post the results here as soon as possible. Anyway if there was someone else who does not mind testing the snapshot with correct open_basedir settings and ftp_nlist() or ftp_rawlist(), I would highly appreciate this. [2007-06-25 17:49:27] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-06-22 14:18:09] derernst at gmx dot ch Description: After my ISP upgraded to PHP 5.2.3 (sorry I don't know from which previous version), functions ftp_nlist() and ftp_rawlist() stopped working: PHP Warning: ftp_nlist() [function.ftp-nlist]: open_basedir restriction in effect. File(/var/tmp/) is not within the allowed path(s): (/data/htdocs/domain.com/:/usr/local/share/pear/:/tmp/:/var/tmp/) in ... Note that the required path does actually match an allowed paths entry: - File(/var/tmp/) - allowed path(s): (/data/htdocs/domain.com/:/usr/local/share/pear/:/tmp/:/var/tmp/) I found several bugs that might be related to this one, see bugs nr. 40141, 41518, 41684; bug 13720 describes the same phenomenon but assumably for an other reason. The functions work again after my ISP removed the trailing slashes from the open_basedir entries. This can't be a desirable solution, though! -- Edit this bug report at http://bugs.php.net/?id=41779edit=1
#41913 [Opn-Fbk]: dbase functions return not all records from a dbf file
ID: 41913
Updated by: [EMAIL PROTECTED]
Reported By: sdmaster at mail dot ru
-Status: Open
+Status: Feedback
Bug Type: dBase related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
Both PHP and dbview output 5 (five) records.
Previous Comments:
[2007-07-06 08:21:20] sdmaster at mail dot ru
Description:
I'm using Apache 2.2.4, php 5.2.3 loaded with LoadModule. php_dbase
extension v5.2.3.3. Apache is run from a local administrator's account.
after I open a dbf file and use dbase_numrecords() to retrieve number
of records in the file, it returns a number that is randomly less than
actual by 1, 2 or 3. accordingly, dbase_get_record_with_names() doesn't
want to get, i.e., 23-th record from a 24-records dbf file.
a sample dbf file is created by Delphi 7 TDbf component v6.9 and
contains russian characters in string fields.
at the same time such tools as DBV Viewer or like show everything
correctly.
reference to the sample dbf file lies inside comments in the posted php
code.
Reproduce code:
---
?
/*
a simple php code, purely from examples
test file is generated by TDbf Delphi 7 component
a sample dbf file, which is reported by php dbase functions to
have 1 records less than actual, could be taken from here:
http://b64.hopto.org/test.dbf
*/
if ($db = dbase_open('c:\temp\test.dbf', 0)) {
$rn = dbase_numrecords($db);
for ($i = 1; $i=$rn; $i++) {
$row=dbase_get_record_with_names($db, $i);
print_r($row);
}
dbase_close($db);
}
?
Expected result:
all records from dbf file
Actual result:
--
all records except the last one
--
Edit this bug report at http://bugs.php.net/?id=41913edit=1
#41911 [Opn-Bgs]: Passing string encapsulated in SimpleXMLElement to strtotime causes memory leak
ID: 41911
Updated by: [EMAIL PROTECTED]
Reported By: irb at redwoodtech dot com
-Status: Open
+Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
All memory leaks are reported by the engine, this is the way the engine
works and it is perfectly acceptable.
Previous Comments:
[2007-07-06 06:06:02] irb at redwoodtech dot com
Description:
If a time string is to be read from a SimpleXML object and converted
into a unix timestamp then a memory leak occurs if the SimpleXML object
is passed directly to strtotime.
The memory leak can be stopped by type casting before passing the
string to strtotime. For example, change the relevant line in the
reproduce code to:
$lTime = strtotime ((string) $xml['timestamp']);
Reproduce code:
---
while(true)
{
$xml = new SimpleXMLElement('test timestamp=Thu, 5 Jul 2007 16:51:23
GMT/test');
echo 'Current Daemon Memory Usage is ' . memory_get_usage ( ) . bytes
: Before STRTOTIME\n;
$lTime = strtotime ($xml['timestamp']);
echo 'Current Daemon Memory Usage is ' . memory_get_usage ( ) . bytes
: After STRTOTIME\n;
}
Expected result:
The following is expected. The point being that the memory usage of the
application is constant.
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Actual result:
--
Memory usage increases over time.
Current Daemon Memory Usage is ___94240 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94400 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94440 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94600 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94640 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94800 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94840 bytes : After STRTOTIME
--
Edit this bug report at http://bugs.php.net/?id=41911edit=1
#41899 [Csd-Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 Updated by: [EMAIL PROTECTED] Reported By: geoffwa at cs dot rmit dot edu dot au -Status: Closed +Status: Assigned Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 -Assigned To: +Assigned To: tony2001 New Comment: I'm still able to reproduce it, though I'm not able to debug it since both GDB and GCC fail to compile on Solaris. I'm working on that atm.. Previous Comments: [2007-07-06 07:54:46] [EMAIL PROTECTED] Since it's fixed in CVS - closed. [2007-07-06 01:03:53] geoffwa at cs dot rmit dot edu dot au Is also broken in 5.2.0 and 5.2.2. Appears to be fixed in latest snapshot: ./php-5.2-200707060030 -v PHP 5.2.4-dev (cli) (built: Jul 6 2007 10:59:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies ./php-5.2-200707060030 -f test.php Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file [2007-07-05 21:59:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-05 06:34:06] geoffwa at cs dot rmit dot edu dot au Description: (possibly related to bug #39953 or bug #39351) If a relative path to a file has '..' as a leading path component, and the directory referred to by '..' is not readable by the user, then opening a file using the relative path fails. Using an absolute path or a path with a non-'..' leading component opens said file just fine. Reproduce code: --- See http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php for a large test script. Expected result: (Using PHP 5.1.4) Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Actual result: -- (Using PHP 5.2.3 + suhosin patch) Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Failed to open ./a/b/file from ./a/b/c using ../file Failed to open ./a/b/file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Failed to open ./a/b/c/file from ./a/b/c using ../c/file -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#41911 [Bgs]: Passing string encapsulated in SimpleXMLElement to strtotime causes memory leak
ID: 41911
User updated by: irb at redwoodtech dot com
Reported By: irb at redwoodtech dot com
Status: Bogus
Bug Type: Date/time related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
Tony, thanks for the quick response.
The messages being logged are generated by my own debug code (See the
echo statements in the reproduce code). Unless I've misunderstood your
comment, you've mistaken my debug messages for the memory leak alerts
raised by the engine.
I didn't mean for the issue raised to be the way in which the memory
leak is reported but rather the memory leak itself.
I asked someone on irc.freenode.net#php to double check my reasoning
and they told me that this looks bogus but for a different reason - that
PHP isn't designed for long-term processes. Is that right?
Any clarification you could provide would be very much appreciated.
Previous Comments:
[2007-07-06 09:20:22] [EMAIL PROTECTED]
All memory leaks are reported by the engine, this is the way the engine
works and it is perfectly acceptable.
[2007-07-06 06:06:02] irb at redwoodtech dot com
Description:
If a time string is to be read from a SimpleXML object and converted
into a unix timestamp then a memory leak occurs if the SimpleXML object
is passed directly to strtotime.
The memory leak can be stopped by type casting before passing the
string to strtotime. For example, change the relevant line in the
reproduce code to:
$lTime = strtotime ((string) $xml['timestamp']);
Reproduce code:
---
while(true)
{
$xml = new SimpleXMLElement('test timestamp=Thu, 5 Jul 2007 16:51:23
GMT/test');
echo 'Current Daemon Memory Usage is ' . memory_get_usage ( ) . bytes
: Before STRTOTIME\n;
$lTime = strtotime ($xml['timestamp']);
echo 'Current Daemon Memory Usage is ' . memory_get_usage ( ) . bytes
: After STRTOTIME\n;
}
Expected result:
The following is expected. The point being that the memory usage of the
application is constant.
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Current Daemon Memory Usage is 53720 bytes : Before STRTOTIME
Current Daemon Memory Usage is 53720 bytes : After STRTOTIME
Actual result:
--
Memory usage increases over time.
Current Daemon Memory Usage is ___94240 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94400 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94440 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94600 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94640 bytes : After STRTOTIME
Current Daemon Memory Usage is ___94800 bytes : Before STRTOTIME
Current Daemon Memory Usage is ___94840 bytes : After STRTOTIME
--
Edit this bug report at http://bugs.php.net/?id=41911edit=1
#41906 [Bgs]: slow local mysql_connect
ID: 41906 User updated by: kkr at mit dot de Reported By: kkr at mit dot de Status: Bogus Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5.2.3 New Comment: It's difficult to clearly seperate the php and mysql client part looking at this behaviour. All normal local applications connect fast enough to the local server, only the php takes loads of time. Can the php extension for mysql make any errors calling the mysql client lib? Is this lib statically compiled into the extension? Until now we stick with 5.2.1 version which is fine for the moment. I will try the same combination on a different windows PC just to be shure. Previous Comments: [2007-07-06 09:09:17] [EMAIL PROTECTED] The connect is done by MySQL client library, not PHP. PHP just provides an interface to it and cannot make your connection faster if it's slow. [2007-07-06 06:52:36] kkr at mit dot de Using todays CVS snapshot the problem still exists. Very slow mysql connection still takes 5-6 seconds. [2007-07-05 21:59:01] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-05 15:56:22] kkr at mit dot de Description: Between 5.2.1 and 5.2.2 the PHP connects much slower to a local mysql5 installation running under apache/windows 2000. It now takes 5 seconds more to a simple connect which at least does work after that time. In the changelog I've seen a new mysql client lib used starting from 5.2.2 upwards, anyone else has these problems too? The 5.2.3 still has the same behavior. A connect is either via TCP or via named pipe/socket possible but slow. Local graphical frontends to the database are as fast as always. MySQL version is the latest released one 5.0.41. Reproduce code: --- the usual mysql_connect() Expected result: I expect a connect time from 200ms and experience 5500ms now. -- Edit this bug report at http://bugs.php.net/?id=41906edit=1
#41908 [Fbk-Opn]: CFLAGS=-Os ./configure --enable-debug fails
ID: 41908 User updated by: christian at hoffie dot info Reported By: christian at hoffie dot info -Status: Feedback +Status: Open Bug Type: Compile Failure Operating System: Gentoo Linux PHP Version: 5.2.3 New Comment: does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? Apparently it doesn't. Don't know if I undestood you correctly -- that CFLAGS manipulation using sed is there because CFLAGS=-O2 -O0 doesn't lead to code being built with -O0, right? What does you config.log say about the reason of the failure? config.log: [...] configure:106983: checking for object suffix configure:106989: gcc -c s -O0 -g -Wall conftest.c 15 gcc: s: No such file or directory (this is the last time this message appears and causes the configure run abort; it happens multiple times as expected, as CFLAGS=s is simply wrong; full config.log at http://home.hoffie.info/php-5.2.3-debug-Os-config.log) Previous Comments: [2007-07-06 09:02:25] [EMAIL PROTECTED] does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? Apparently it doesn't. What does you config.log say about the reason of the failure? [2007-07-05 17:06:17] christian at hoffie dot info Description: PHP's configure script incorrectly manipulates CFLAGS and CXXFLAGS when running with --enable-debug or --enable-gcov. When CFLAGS or CXXFLAGS contains -Os (optimize for size), the configure script builds a bad list of CFLAGS/CXXFLAGS and as such configure fails in a later stage. I created a small patch[1] which should solve that, I'm not completely sure whether it's a good idea to remove that -O stuff at all -- does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? [1] http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.3/5.2.3/php5.2.3-configure-Os-fix.patch?rev=1237 Reproduce code: --- CFLAGS=-Os ./configure --enable-debug (same if you replace CFLAGS by CXXFLAGS or --enable-debug with --enable-gcov) Actual result: -- [EMAIL PROTECTED] /tmp/php-5.2.3 $ env | grep FLAGS CXXFLAGS=-Os CFLAGS=-Os [EMAIL PROTECTED] /tmp/php-5.2.3 $ ./configure --disable-all --enable-debug [...] Configuring libtool checking build system type... i686-pc-linux-gnu checking for ld used by gcc... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for object suffix... configure: error: installation or configuration problem; compiler does not work Depending on ./configure options the output looks different. For example, with --with-xml you will see a libxml2 failure first. -- Edit this bug report at http://bugs.php.net/?id=41908edit=1
#41915 [NEW]: Problem from multiplication
From: pawel1-81 at O2 dot PL Operating system: WINDOWS XP HOME PHP version: 5.2.3 PHP Bug Type: *General Issues Bug description: Problem from multiplication Description: Why for some values $ r ($r * 1000) result on example 1015 be paid back 1.015 E + 10 and for 2886 - 2886000 In previous version php all acts Reproduce code: --- meta HTTP-EQUIV=Refresh CONTENT=10; ?php $function['min'] = 400; $function['max'] = 4000; $r = mt_rand($function['min'], $function['max']); echo 'br$r = '.$r .'br$r * 1000 = '. ($r * 1000) .'br$function[max]* 1000 = '. ($function['max']* 1000) .'br4000 * 1000 = '. (4000 * 1000); ? -- Edit bug report at http://bugs.php.net/?id=41915edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=41915r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=41915r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=41915r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=41915r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=41915r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=41915r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=41915r=needscript Try newer version:http://bugs.php.net/fix.php?id=41915r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=41915r=support Expected behavior:http://bugs.php.net/fix.php?id=41915r=notwrong Not enough info: http://bugs.php.net/fix.php?id=41915r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=41915r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=41915r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41915r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=41915r=dst IIS Stability:http://bugs.php.net/fix.php?id=41915r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=41915r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=41915r=float No Zend Extensions: http://bugs.php.net/fix.php?id=41915r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=41915r=mysqlcfg
#41915 [Opn-Bgs]: Problem from multiplication
ID: 41915 Updated by: [EMAIL PROTECTED] Reported By: pawel1-81 at O2 dot PL -Status: Open +Status: Bogus Bug Type: *General Issues Operating System: WINDOWS XP HOME PHP Version: 5.2.3 New Comment: Expected behaviour, there is nothing wrong here. To output a float, use printf()/number_format() and other functions. Previous Comments: [2007-07-06 10:53:57] pawel1-81 at O2 dot PL Description: Why for some values $ r ($r * 1000) result on example 1015 be paid back 1.015 E + 10 and for 2886 - 2886000 In previous version php all acts Reproduce code: --- meta HTTP-EQUIV=Refresh CONTENT=10; ?php $function['min'] = 400; $function['max'] = 4000; $r = mt_rand($function['min'], $function['max']); echo 'br$r = '.$r .'br$r * 1000 = '. ($r * 1000) .'br$function[max]* 1000 = '. ($function['max']* 1000) .'br4000 * 1000 = '. (4000 * 1000); ? -- Edit this bug report at http://bugs.php.net/?id=41915edit=1
#41908 [Opn-Csd]: CFLAGS=-Os ./configure --enable-debug fails
ID: 41908 Updated by: [EMAIL PROTECTED] Reported By: christian at hoffie dot info -Status: Open +Status: Closed Bug Type: Compile Failure Operating System: Gentoo Linux PHP Version: 5.2.3 New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2007-07-06 10:34:24] christian at hoffie dot info does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? Apparently it doesn't. Don't know if I undestood you correctly -- that CFLAGS manipulation using sed is there because CFLAGS=-O2 -O0 doesn't lead to code being built with -O0, right? What does you config.log say about the reason of the failure? config.log: [...] configure:106983: checking for object suffix configure:106989: gcc -c s -O0 -g -Wall conftest.c 15 gcc: s: No such file or directory (this is the last time this message appears and causes the configure run abort; it happens multiple times as expected, as CFLAGS=s is simply wrong; full config.log at http://home.hoffie.info/php-5.2.3-debug-Os-config.log) [2007-07-06 09:02:25] [EMAIL PROTECTED] does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? Apparently it doesn't. What does you config.log say about the reason of the failure? [2007-07-05 17:06:17] christian at hoffie dot info Description: PHP's configure script incorrectly manipulates CFLAGS and CXXFLAGS when running with --enable-debug or --enable-gcov. When CFLAGS or CXXFLAGS contains -Os (optimize for size), the configure script builds a bad list of CFLAGS/CXXFLAGS and as such configure fails in a later stage. I created a small patch[1] which should solve that, I'm not completely sure whether it's a good idea to remove that -O stuff at all -- does appending -O0 after user-supplied flags not lead to the expected result (building with -O0 and not -O2 for instance)? [1] http://overlays.gentoo.org/proj/php/browser/patches/php-patches/5.2.3/5.2.3/php5.2.3-configure-Os-fix.patch?rev=1237 Reproduce code: --- CFLAGS=-Os ./configure --enable-debug (same if you replace CFLAGS by CXXFLAGS or --enable-debug with --enable-gcov) Actual result: -- [EMAIL PROTECTED] /tmp/php-5.2.3 $ env | grep FLAGS CXXFLAGS=-Os CFLAGS=-Os [EMAIL PROTECTED] /tmp/php-5.2.3 $ ./configure --disable-all --enable-debug [...] Configuring libtool checking build system type... i686-pc-linux-gnu checking for ld used by gcc... /usr/i686-pc-linux-gnu/bin/ld checking if the linker (/usr/i686-pc-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/i686-pc-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/nm -B checking how to recognise dependent libraries... pass_all checking for object suffix... configure: error: installation or configuration problem; compiler does not work Depending on ./configure options the output looks different. For example, with --with-xml you will see a libxml2 failure first. -- Edit this bug report at http://bugs.php.net/?id=41908edit=1
#41913 [Fbk-Opn]: dbase functions return not all records from a dbf file
ID: 41913
User updated by: sdmaster at mail dot ru
Reported By: sdmaster at mail dot ru
-Status: Feedback
+Status: Open
Bug Type: dBase related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
note that the sample dbf has in fact 6 (six) records!
I use dbf viewer 2000
Previous Comments:
[2007-07-06 09:17:40] [EMAIL PROTECTED]
Both PHP and dbview output 5 (five) records.
[2007-07-06 08:21:20] sdmaster at mail dot ru
Description:
I'm using Apache 2.2.4, php 5.2.3 loaded with LoadModule. php_dbase
extension v5.2.3.3. Apache is run from a local administrator's account.
after I open a dbf file and use dbase_numrecords() to retrieve number
of records in the file, it returns a number that is randomly less than
actual by 1, 2 or 3. accordingly, dbase_get_record_with_names() doesn't
want to get, i.e., 23-th record from a 24-records dbf file.
a sample dbf file is created by Delphi 7 TDbf component v6.9 and
contains russian characters in string fields.
at the same time such tools as DBV Viewer or like show everything
correctly.
reference to the sample dbf file lies inside comments in the posted php
code.
Reproduce code:
---
?
/*
a simple php code, purely from examples
test file is generated by TDbf Delphi 7 component
a sample dbf file, which is reported by php dbase functions to
have 1 records less than actual, could be taken from here:
http://b64.hopto.org/test.dbf
*/
if ($db = dbase_open('c:\temp\test.dbf', 0)) {
$rn = dbase_numrecords($db);
for ($i = 1; $i=$rn; $i++) {
$row=dbase_get_record_with_names($db, $i);
print_r($row);
}
dbase_close($db);
}
?
Expected result:
all records from dbf file
Actual result:
--
all records except the last one
--
Edit this bug report at http://bugs.php.net/?id=41913edit=1
#41916 [Opn]: $_SESSION array lost from one page to the next
ID: 41916
User updated by: richard at dominion-web dot com
Reported By: richard at dominion-web dot com
Status: Open
-Bug Type: SPL related
+Bug Type: Session related
Operating System: Windows Server 2003
PHP Version: 6CVS-2007-07-06 (snap)
New Comment:
Sorry wrong category
Previous Comments:
[2007-07-06 13:40:37] richard at dominion-web dot com
Description:
I have a script that runs fine on all versions of PHP until I test with
the latest 6.0.0 snapshot. I am using URL sessions rather than cookie
based sessions
On the first page I start the session with session_start(); and set
some variables with $_SESSION['varname'] = 'value';
I check the session temp directory and the session is there
---
folder|S:5:INBOX;
---
The page directs to the next page and can confirm that the session id
in the URL is the same as that in the session temp directory.
However on both a print_r($_SESSION); and a var_dump($_SESSION); I get
Array ( ) being outputted to the screen.
The data is still in the session temp file i.e. it hasn't been deleted,
just the next script seems unable to read the data out of the file from
one page to the next.
As I say this script works on PHP 4, 5, 5.1 and 5.2 just not on
6.0snapshot.
Reproduce code:
---
1st page
ini_set ( session.use_cookies, 0);
session_start();
$_SESSION['folder'] = 'INBOX';
2nd page
ini_set ( session.use_cookies, 0);
session_start();
var_dump($_SESSION);
Expected result:
To get a variable dump of the $_SESSION array with folder - INBOX in
it
Actual result:
--
Array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=41916edit=1
#41913 [Opn-Bgs]: dbase functions return not all records from a dbf file
ID: 41913
Updated by: [EMAIL PROTECTED]
Reported By: sdmaster at mail dot ru
-Status: Open
+Status: Bogus
Bug Type: dBase related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
Well, then there is apparently some problem with the DBF file since not
only PHP, but the dbview tool does not show this 6th record.
Previous Comments:
[2007-07-06 13:05:11] sdmaster at mail dot ru
note that the sample dbf has in fact 6 (six) records!
I use dbf viewer 2000
[2007-07-06 09:17:40] [EMAIL PROTECTED]
Both PHP and dbview output 5 (five) records.
[2007-07-06 08:21:20] sdmaster at mail dot ru
Description:
I'm using Apache 2.2.4, php 5.2.3 loaded with LoadModule. php_dbase
extension v5.2.3.3. Apache is run from a local administrator's account.
after I open a dbf file and use dbase_numrecords() to retrieve number
of records in the file, it returns a number that is randomly less than
actual by 1, 2 or 3. accordingly, dbase_get_record_with_names() doesn't
want to get, i.e., 23-th record from a 24-records dbf file.
a sample dbf file is created by Delphi 7 TDbf component v6.9 and
contains russian characters in string fields.
at the same time such tools as DBV Viewer or like show everything
correctly.
reference to the sample dbf file lies inside comments in the posted php
code.
Reproduce code:
---
?
/*
a simple php code, purely from examples
test file is generated by TDbf Delphi 7 component
a sample dbf file, which is reported by php dbase functions to
have 1 records less than actual, could be taken from here:
http://b64.hopto.org/test.dbf
*/
if ($db = dbase_open('c:\temp\test.dbf', 0)) {
$rn = dbase_numrecords($db);
for ($i = 1; $i=$rn; $i++) {
$row=dbase_get_record_with_names($db, $i);
print_r($row);
}
dbase_close($db);
}
?
Expected result:
all records from dbf file
Actual result:
--
all records except the last one
--
Edit this bug report at http://bugs.php.net/?id=41913edit=1
#41899 [Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 User updated by: geoffwa at cs dot rmit dot edu dot au Reported By: geoffwa at cs dot rmit dot edu dot au Status: Assigned Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 Assigned To: tony2001 New Comment: I've updated http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php with a shorter test script and two syscall traces of 5.2.3 and 5.2-200707060030. Looking through these the main difference is that 5.2.3 makes a stat() call with an empty path, whereas 5.2-snap makes a stat() call using the relative path supplied to fopen() in the PHP script. We use Sun Studio's C compiler, so I can use dbx for debugging (gdb crashes on most Sun-compiled binaries I give it). Is there anything I can trace for you? Previous Comments: [2007-07-06 09:26:43] [EMAIL PROTECTED] I'm still able to reproduce it, though I'm not able to debug it since both GDB and GCC fail to compile on Solaris. I'm working on that atm.. [2007-07-06 07:54:46] [EMAIL PROTECTED] Since it's fixed in CVS - closed. [2007-07-06 01:03:53] geoffwa at cs dot rmit dot edu dot au Is also broken in 5.2.0 and 5.2.2. Appears to be fixed in latest snapshot: ./php-5.2-200707060030 -v PHP 5.2.4-dev (cli) (built: Jul 6 2007 10:59:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies ./php-5.2-200707060030 -f test.php Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file [2007-07-05 21:59:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi [2007-07-05 06:34:06] geoffwa at cs dot rmit dot edu dot au Description: (possibly related to bug #39953 or bug #39351) If a relative path to a file has '..' as a leading path component, and the directory referred to by '..' is not readable by the user, then opening a file using the relative path fails. Using an absolute path or a path with a non-'..' leading component opens said file just fine. Reproduce code: --- See http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php for a large test script. Expected result: (Using PHP 5.1.4) Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file Actual result: -- (Using PHP 5.2.3 + suhosin patch) Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Failed to open ./a/b/file from ./a/b/c using ../file Failed to open ./a/b/file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Failed to open ./a/b/c/file from ./a/b/c using ../c/file -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#41916 [Opn-Fbk]: $_SESSION array lost from one page to the next
ID: 41916
Updated by: [EMAIL PROTECTED]
Reported By: richard at dominion-web dot com
-Status: Open
+Status: Feedback
Bug Type: Session related
Operating System: Windows Server 2003
PHP Version: 6CVS-2007-07-06 (snap)
New Comment:
Works perfectly fine here as long as session.use_only_cookies = 0 and
session.use_trans_sid = 1.
Previous Comments:
[2007-07-06 13:42:22] richard at dominion-web dot com
Sorry wrong category
[2007-07-06 13:40:37] richard at dominion-web dot com
Description:
I have a script that runs fine on all versions of PHP until I test with
the latest 6.0.0 snapshot. I am using URL sessions rather than cookie
based sessions
On the first page I start the session with session_start(); and set
some variables with $_SESSION['varname'] = 'value';
I check the session temp directory and the session is there
---
folder|S:5:INBOX;
---
The page directs to the next page and can confirm that the session id
in the URL is the same as that in the session temp directory.
However on both a print_r($_SESSION); and a var_dump($_SESSION); I get
Array ( ) being outputted to the screen.
The data is still in the session temp file i.e. it hasn't been deleted,
just the next script seems unable to read the data out of the file from
one page to the next.
As I say this script works on PHP 4, 5, 5.1 and 5.2 just not on
6.0snapshot.
Reproduce code:
---
1st page
ini_set ( session.use_cookies, 0);
session_start();
$_SESSION['folder'] = 'INBOX';
2nd page
ini_set ( session.use_cookies, 0);
session_start();
var_dump($_SESSION);
Expected result:
To get a variable dump of the $_SESSION array with folder - INBOX in
it
Actual result:
--
Array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=41916edit=1
#41884 [Opn-Asn]: ReflectionClass::getDefaultProperties() does not handle static attributes
ID: 41884
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: Feature/Change Request
Operating System: Irrelevant
PHP Version: 5CVS-2007-07-03 (CVS)
-Assigned To:
+Assigned To: helly
Previous Comments:
[2007-07-03 09:10:16] [EMAIL PROTECTED]
Here is a patch for it: http://dev.daylessday.org/diff/bug41884.diff
but I'd like to hear Marcus opinion before committing it.
[2007-07-03 08:35:29] [EMAIL PROTECTED]
Description:
Static properties with default values do not appear in the result of
ReflectionClass::getDefaultProperties().
Reproduce code:
---
?php
class Foo
{
protected static $fooStatic = 'foo';
protected $foo = 'foo';
}
$class = new ReflectionClass('Foo');
print_r($class-getDefaultProperties());
Expected result:
Array
(
[fooStatic] = foo
[foo] = foo
)
Actual result:
--
Array
(
[foo] = foo
)
--
Edit this bug report at http://bugs.php.net/?id=41884edit=1
#41916 [NEW]: $_SESSION array lost from one page to the next
From: richard at dominion-web dot com
Operating system: Windows Server 2003
PHP version: 6CVS-2007-07-06 (snap)
PHP Bug Type: SPL related
Bug description: $_SESSION array lost from one page to the next
Description:
I have a script that runs fine on all versions of PHP until I test with
the latest 6.0.0 snapshot. I am using URL sessions rather than cookie
based sessions
On the first page I start the session with session_start(); and set some
variables with $_SESSION['varname'] = 'value';
I check the session temp directory and the session is there
---
folder|S:5:INBOX;
---
The page directs to the next page and can confirm that the session id in
the URL is the same as that in the session temp directory.
However on both a print_r($_SESSION); and a var_dump($_SESSION); I get
Array ( ) being outputted to the screen.
The data is still in the session temp file i.e. it hasn't been deleted,
just the next script seems unable to read the data out of the file from one
page to the next.
As I say this script works on PHP 4, 5, 5.1 and 5.2 just not on
6.0snapshot.
Reproduce code:
---
1st page
ini_set ( session.use_cookies, 0);
session_start();
$_SESSION['folder'] = 'INBOX';
2nd page
ini_set ( session.use_cookies, 0);
session_start();
var_dump($_SESSION);
Expected result:
To get a variable dump of the $_SESSION array with folder - INBOX in it
Actual result:
--
Array(0) { }
--
Edit bug report at http://bugs.php.net/?id=41916edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41916r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41916r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41916r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41916r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41916r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41916r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41916r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41916r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41916r=support
Expected behavior:http://bugs.php.net/fix.php?id=41916r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41916r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41916r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41916r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41916r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41916r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41916r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41916r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41916r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41916r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41916r=mysqlcfg
#41899 [Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 Updated by: [EMAIL PROTECTED] Reported By: geoffwa at cs dot rmit dot edu dot au Status: Assigned Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 Assigned To: tony2001 New Comment: Which configure options did you use? As I said, I don't see any difference between 5.2.3 and the snapshot and there should not be any difference since I don't remember any changes that could affect it. We use Sun Studio's C compiler, so I can use dbx for debugging I can use that too, but I prefer GDB. Is there anything I can trace for you? No, I'm still hoping to get GCC GDB working there. Previous Comments: [2007-07-06 13:56:10] geoffwa at cs dot rmit dot edu dot au I've updated http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php with a shorter test script and two syscall traces of 5.2.3 and 5.2-200707060030. Looking through these the main difference is that 5.2.3 makes a stat() call with an empty path, whereas 5.2-snap makes a stat() call using the relative path supplied to fopen() in the PHP script. We use Sun Studio's C compiler, so I can use dbx for debugging (gdb crashes on most Sun-compiled binaries I give it). Is there anything I can trace for you? [2007-07-06 09:26:43] [EMAIL PROTECTED] I'm still able to reproduce it, though I'm not able to debug it since both GDB and GCC fail to compile on Solaris. I'm working on that atm.. [2007-07-06 07:54:46] [EMAIL PROTECTED] Since it's fixed in CVS - closed. [2007-07-06 01:03:53] geoffwa at cs dot rmit dot edu dot au Is also broken in 5.2.0 and 5.2.2. Appears to be fixed in latest snapshot: ./php-5.2-200707060030 -v PHP 5.2.4-dev (cli) (built: Jul 6 2007 10:59:53) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies ./php-5.2-200707060030 -f test.php Current working directory is: /home/g/geoffwa/test Opened /home/g/geoffwa/test/a/b/file Opened ./a/b/file from ./a using ./b/file Opened ./a/b/file from ./a using ./b/c/../file Opened ./a/b/file from ./a/b/c using ../file Opened ../file from ./a/b/c using ./../file Opened ./a/b/file from ./a/b using ./file Opened ./a/file from ./a/b using ./c/../../file Opened ./a/b/c/file from ./a/b/c using ../c/file [2007-07-05 21:59:45] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi 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/41899 -- Edit this bug report at http://bugs.php.net/?id=41899edit=1
#41916 [Fbk-Csd]: $_SESSION array lost from one page to the next
ID: 41916
User updated by: richard at dominion-web dot com
Reported By: richard at dominion-web dot com
-Status: Feedback
+Status: Closed
Bug Type: Session related
Operating System: Windows Server 2003
PHP Version: 6CVS-2007-07-06 (snap)
New Comment:
Thanks, I wasn't setting session.use_only_cookies but only
session.use_cookies
Previous Comments:
[2007-07-06 13:58:13] [EMAIL PROTECTED]
Works perfectly fine here as long as session.use_only_cookies = 0 and
session.use_trans_sid = 1.
[2007-07-06 13:42:22] richard at dominion-web dot com
Sorry wrong category
[2007-07-06 13:40:37] richard at dominion-web dot com
Description:
I have a script that runs fine on all versions of PHP until I test with
the latest 6.0.0 snapshot. I am using URL sessions rather than cookie
based sessions
On the first page I start the session with session_start(); and set
some variables with $_SESSION['varname'] = 'value';
I check the session temp directory and the session is there
---
folder|S:5:INBOX;
---
The page directs to the next page and can confirm that the session id
in the URL is the same as that in the session temp directory.
However on both a print_r($_SESSION); and a var_dump($_SESSION); I get
Array ( ) being outputted to the screen.
The data is still in the session temp file i.e. it hasn't been deleted,
just the next script seems unable to read the data out of the file from
one page to the next.
As I say this script works on PHP 4, 5, 5.1 and 5.2 just not on
6.0snapshot.
Reproduce code:
---
1st page
ini_set ( session.use_cookies, 0);
session_start();
$_SESSION['folder'] = 'INBOX';
2nd page
ini_set ( session.use_cookies, 0);
session_start();
var_dump($_SESSION);
Expected result:
To get a variable dump of the $_SESSION array with folder - INBOX in
it
Actual result:
--
Array(0) { }
--
Edit this bug report at http://bugs.php.net/?id=41916edit=1
#41899 [Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 Updated by: [EMAIL PROTECTED] Reported By: geoffwa at cs dot rmit dot edu dot au Status: Assigned Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 Assigned To: tony2001 New Comment: Thanks, but I need to do it myself in order to understand it. I know quite well that realpath() on Solaris is badly broken, that's known issue and Sun is not going to do anything about as far as I understand. The problem is that we need to invent a workaround for it so that we don't break working realpath() implementations. And to do that I need to reproduce it myself and investigate it using GDB. Previous Comments: [2007-07-06 15:00:30] geoffwa at cs dot rmit dot edu dot au Doing a bit of tracing of expand_filepath nets: (from PHP-5.2.3) expand_filepath(filepath = 0xffbff5f4 test2.php, real_path = 0xffbfee20 ) called from function php_execute_script expand_filepath returns 0xffbfee20 /home/g/geoffwa/test/test2.php expand_filepath(filepath = 0xffbfdec0 ./a, real_path = 0xffbfe2c4 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe2c4 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe108 ./a/b/file, real_path = 0xffbfe50c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe50c /home/g/geoffwa/test/a/b/file expand_filepath(filepath = 0xffbfe098 ./a, real_path = 0xffbfe49c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe49c /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe028 ./a, real_path = 0xffbfe42c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe42c /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe120 ./a/b, real_path = 0xffbfe524 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe524 /home/g/geoffwa/test/a/b expand_filepath(filepath = 0xffbfdfd8 ../b/file, real_path = 0xffbfe3dc ) called from function php_checkuid_ex expand_filepath returns (nil) (from PHP 5.2 snap 200707060030) expand_filepath(filepath = 0xffbff5ef test2.php, real_path = 0xffbfee18 ) called from function php_execute_script expand_filepath returns 0xffbfee18 /home/g/geoffwa/test/test2.php expand_filepath(filepath = 0xffbfdeb8 ./a, real_path = 0xffbfe2bc ) called from function php_checkuid_ex expand_filepath returns 0xffbfe2bc /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe100 ./a/b/file, real_path = 0xffbfe504 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe504 /home/g/geoffwa/test/a/b/file expand_filepath(filepath = 0xffbfe090 ./a, real_path = 0xffbfe494 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe494 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe020 ./a, real_path = 0xffbfe424 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe424 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe118 ./a/b, real_path = 0xffbfe51c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe51c /home/g/geoffwa/test/a/b expand_filepath(filepath = 0xffbfdfd0 ../b/file, real_path = 0xffbfe3d4 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe3d4 ../b/file expand_filepath(filepath = 0x53d1c0 ../b/file, real_path = (nil)) called from function _php_stream_fopen expand_filepath returns 0x53d398 ../b/file [2007-07-06 14:02:04] [EMAIL PROTECTED] Which configure options did you use? As I said, I don't see any difference between 5.2.3 and the snapshot and there should not be any difference since I don't remember any changes that could affect it. We use Sun Studio's C compiler, so I can use dbx for debugging I can use that too, but I prefer GDB. Is there anything I can trace for you? No, I'm still hoping to get GCC GDB working there. [2007-07-06 13:56:10] geoffwa at cs dot rmit dot edu dot au I've updated http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php with a shorter test script and two syscall traces of 5.2.3 and 5.2-200707060030. Looking through these the main difference is that 5.2.3 makes a stat() call with an empty path, whereas 5.2-snap makes a stat() call using the relative path supplied to fopen() in the PHP script. We use Sun Studio's C compiler, so I can use dbx for debugging (gdb crashes on most Sun-compiled binaries I
#41899 [Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 User updated by: geoffwa at cs dot rmit dot edu dot au Reported By: geoffwa at cs dot rmit dot edu dot au Status: Assigned Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 Assigned To: tony2001 New Comment: Doing a bit of tracing of expand_filepath nets: (from PHP-5.2.3) expand_filepath(filepath = 0xffbff5f4 test2.php, real_path = 0xffbfee20 ) called from function php_execute_script expand_filepath returns 0xffbfee20 /home/g/geoffwa/test/test2.php expand_filepath(filepath = 0xffbfdec0 ./a, real_path = 0xffbfe2c4 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe2c4 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe108 ./a/b/file, real_path = 0xffbfe50c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe50c /home/g/geoffwa/test/a/b/file expand_filepath(filepath = 0xffbfe098 ./a, real_path = 0xffbfe49c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe49c /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe028 ./a, real_path = 0xffbfe42c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe42c /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe120 ./a/b, real_path = 0xffbfe524 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe524 /home/g/geoffwa/test/a/b expand_filepath(filepath = 0xffbfdfd8 ../b/file, real_path = 0xffbfe3dc ) called from function php_checkuid_ex expand_filepath returns (nil) (from PHP 5.2 snap 200707060030) expand_filepath(filepath = 0xffbff5ef test2.php, real_path = 0xffbfee18 ) called from function php_execute_script expand_filepath returns 0xffbfee18 /home/g/geoffwa/test/test2.php expand_filepath(filepath = 0xffbfdeb8 ./a, real_path = 0xffbfe2bc ) called from function php_checkuid_ex expand_filepath returns 0xffbfe2bc /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe100 ./a/b/file, real_path = 0xffbfe504 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe504 /home/g/geoffwa/test/a/b/file expand_filepath(filepath = 0xffbfe090 ./a, real_path = 0xffbfe494 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe494 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe020 ./a, real_path = 0xffbfe424 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe424 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe118 ./a/b, real_path = 0xffbfe51c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe51c /home/g/geoffwa/test/a/b expand_filepath(filepath = 0xffbfdfd0 ../b/file, real_path = 0xffbfe3d4 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe3d4 ../b/file expand_filepath(filepath = 0x53d1c0 ../b/file, real_path = (nil)) called from function _php_stream_fopen expand_filepath returns 0x53d398 ../b/file Previous Comments: [2007-07-06 14:02:04] [EMAIL PROTECTED] Which configure options did you use? As I said, I don't see any difference between 5.2.3 and the snapshot and there should not be any difference since I don't remember any changes that could affect it. We use Sun Studio's C compiler, so I can use dbx for debugging I can use that too, but I prefer GDB. Is there anything I can trace for you? No, I'm still hoping to get GCC GDB working there. [2007-07-06 13:56:10] geoffwa at cs dot rmit dot edu dot au I've updated http://goanna.cs.rmit.edu.au/~geoffwa/relative_path_bug.php with a shorter test script and two syscall traces of 5.2.3 and 5.2-200707060030. Looking through these the main difference is that 5.2.3 makes a stat() call with an empty path, whereas 5.2-snap makes a stat() call using the relative path supplied to fopen() in the PHP script. We use Sun Studio's C compiler, so I can use dbx for debugging (gdb crashes on most Sun-compiled binaries I give it). Is there anything I can trace for you? [2007-07-06 09:26:43] [EMAIL PROTECTED] I'm still able to reproduce it, though I'm not able to debug it since both GDB and GCC fail to compile on Solaris. I'm working on that atm.. [2007-07-06 07:54:46] [EMAIL PROTECTED] Since it's fixed in CVS - closed.
#41910 [Opn-Fbk]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
Updated by: [EMAIL PROTECTED]
Reported By: dan at novapulsar dot com
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
What is mysql_execute()?
Previous Comments:
[2007-07-06 15:30:24] dan at novapulsar dot com
?php
//connect to valid mysql server
mysql_connect (localhost, user, password) or die
(mysql_error());
mysql_select_db (mysql) or die (mysql_error());
/* db doesn't really matter because we're trying to raise an error
based on an invalid query */
$strSQL = select all from nothing this is broken;
$objResult = mysql_execute ($strSQL) or die (fn_Save_Error ('this.php',
mysql_error()));
/*i expect to see the string generated by the save error function,
mysql_error() as a parameter. instead, the 'return' of mysql_error goes
directly to the screen, instead of being passed as a parameter as it is
documented*/
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
?
[2007-07-06 09:06:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-07-06 05:03:25] dan at novapulsar dot com
Description:
Since mysql_error() is documented to 'return' a string, I assumed it
would be safe to put it in either a string, or as an argument to an
error handling function.
Reproduce code:
---
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
$strSQL = select all from something will make an error duh;
$objResult = mysql_query ($strSQL) or die (fn_Save_Error('this.php',
mysql_error());
Expected result:
Expected result is that the string value of mysql_error() is passed as
an argument of datatype string whether blank or with contents to the
fn_Save_Error function.
Actual result:
--
Mysql_error() is output directly to the screen/console, instead of
being passed as a value to fn_Save_Error for custom error handling.
Based on the mysql_error() documentation it should not output the error
to screen, it should return it as a string, so that I could do this:
...some wrong query execution...
$error_message = mysql_error(); echo ($error_message);
$error_message should be == to $mysql_error, but instead it just
outputs to screen/console
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41913 [Bgs]: dbase functions return not all records from a dbf file
ID: 41913
User updated by: sdmaster at mail dot ru
Reported By: sdmaster at mail dot ru
Status: Bogus
Bug Type: dBase related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
so the question remains.. will this be considered a bug of the
php_dbase extension and eventually fixed, or the result of dbview will
keep being a standard that php_dbase will stick to?
Previous Comments:
[2007-07-06 13:43:47] [EMAIL PROTECTED]
Well, then there is apparently some problem with the DBF file since not
only PHP, but the dbview tool does not show this 6th record.
[2007-07-06 13:05:11] sdmaster at mail dot ru
note that the sample dbf has in fact 6 (six) records!
I use dbf viewer 2000
[2007-07-06 09:17:40] [EMAIL PROTECTED]
Both PHP and dbview output 5 (five) records.
[2007-07-06 08:21:20] sdmaster at mail dot ru
Description:
I'm using Apache 2.2.4, php 5.2.3 loaded with LoadModule. php_dbase
extension v5.2.3.3. Apache is run from a local administrator's account.
after I open a dbf file and use dbase_numrecords() to retrieve number
of records in the file, it returns a number that is randomly less than
actual by 1, 2 or 3. accordingly, dbase_get_record_with_names() doesn't
want to get, i.e., 23-th record from a 24-records dbf file.
a sample dbf file is created by Delphi 7 TDbf component v6.9 and
contains russian characters in string fields.
at the same time such tools as DBV Viewer or like show everything
correctly.
reference to the sample dbf file lies inside comments in the posted php
code.
Reproduce code:
---
?
/*
a simple php code, purely from examples
test file is generated by TDbf Delphi 7 component
a sample dbf file, which is reported by php dbase functions to
have 1 records less than actual, could be taken from here:
http://b64.hopto.org/test.dbf
*/
if ($db = dbase_open('c:\temp\test.dbf', 0)) {
$rn = dbase_numrecords($db);
for ($i = 1; $i=$rn; $i++) {
$row=dbase_get_record_with_names($db, $i);
print_r($row);
}
dbase_close($db);
}
?
Expected result:
all records from dbf file
Actual result:
--
all records except the last one
--
Edit this bug report at http://bugs.php.net/?id=41913edit=1
#41910 [Opn-Fbk]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
Updated by: [EMAIL PROTECTED]
Reported By: dan at novapulsar dot com
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
Just put the default php.ini instead of yours and change settings one
by one to see which one causes it.
Previous Comments:
[2007-07-06 15:50:01] dan at novapulsar dot com
Can log file settings be affecting the way this is working? I've tried
this on multiple servers, and this seems simple enough to work, but yet
it doesn't.
Do you want a link to a phpinfo page on the server this is being run on
and/or a copy of php.ini in a link?
[2007-07-06 15:43:20] [EMAIL PROTECTED]
/local/dev/php/4_4 ./sapi/cli/php /tmp/5.php
Error on page: this.php - You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near 'from nothing this is broken' at line 1
I don't see any problems here.
[2007-07-06 15:37:17] dan at novapulsar dot com
Sorry, early in the morning, I meant mysql_query().
[2007-07-06 15:35:53] [EMAIL PROTECTED]
What is mysql_execute()?
[2007-07-06 15:30:24] dan at novapulsar dot com
?php
//connect to valid mysql server
mysql_connect (localhost, user, password) or die
(mysql_error());
mysql_select_db (mysql) or die (mysql_error());
/* db doesn't really matter because we're trying to raise an error
based on an invalid query */
$strSQL = select all from nothing this is broken;
$objResult = mysql_execute ($strSQL) or die (fn_Save_Error ('this.php',
mysql_error()));
/*i expect to see the string generated by the save error function,
mysql_error() as a parameter. instead, the 'return' of mysql_error goes
directly to the screen, instead of being passed as a parameter as it is
documented*/
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
?
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/41910
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41910 [Fbk-Opn]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
User updated by: dan at novapulsar dot com
Reported By: dan at novapulsar dot com
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
Can log file settings be affecting the way this is working? I've tried
this on multiple servers, and this seems simple enough to work, but yet
it doesn't.
Do you want a link to a phpinfo page on the server this is being run on
and/or a copy of php.ini in a link?
Previous Comments:
[2007-07-06 15:43:20] [EMAIL PROTECTED]
/local/dev/php/4_4 ./sapi/cli/php /tmp/5.php
Error on page: this.php - You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near 'from nothing this is broken' at line 1
I don't see any problems here.
[2007-07-06 15:37:17] dan at novapulsar dot com
Sorry, early in the morning, I meant mysql_query().
[2007-07-06 15:35:53] [EMAIL PROTECTED]
What is mysql_execute()?
[2007-07-06 15:30:24] dan at novapulsar dot com
?php
//connect to valid mysql server
mysql_connect (localhost, user, password) or die
(mysql_error());
mysql_select_db (mysql) or die (mysql_error());
/* db doesn't really matter because we're trying to raise an error
based on an invalid query */
$strSQL = select all from nothing this is broken;
$objResult = mysql_execute ($strSQL) or die (fn_Save_Error ('this.php',
mysql_error()));
/*i expect to see the string generated by the save error function,
mysql_error() as a parameter. instead, the 'return' of mysql_error goes
directly to the screen, instead of being passed as a parameter as it is
documented*/
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
?
[2007-07-06 09:06:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
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/41910
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41910 [Opn-Fbk]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
Updated by: [EMAIL PROTECTED]
Reported By: dan at novapulsar dot com
-Status: Open
+Status: Feedback
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
/local/dev/php/4_4 ./sapi/cli/php /tmp/5.php
Error on page: this.php - You have an error in your SQL syntax; check
the manual that corresponds to your MySQL server version for the right
syntax to use near 'from nothing this is broken' at line 1
I don't see any problems here.
Previous Comments:
[2007-07-06 15:37:17] dan at novapulsar dot com
Sorry, early in the morning, I meant mysql_query().
[2007-07-06 15:35:53] [EMAIL PROTECTED]
What is mysql_execute()?
[2007-07-06 15:30:24] dan at novapulsar dot com
?php
//connect to valid mysql server
mysql_connect (localhost, user, password) or die
(mysql_error());
mysql_select_db (mysql) or die (mysql_error());
/* db doesn't really matter because we're trying to raise an error
based on an invalid query */
$strSQL = select all from nothing this is broken;
$objResult = mysql_execute ($strSQL) or die (fn_Save_Error ('this.php',
mysql_error()));
/*i expect to see the string generated by the save error function,
mysql_error() as a parameter. instead, the 'return' of mysql_error goes
directly to the screen, instead of being passed as a parameter as it is
documented*/
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
?
[2007-07-06 09:06:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-07-06 05:03:25] dan at novapulsar dot com
Description:
Since mysql_error() is documented to 'return' a string, I assumed it
would be safe to put it in either a string, or as an argument to an
error handling function.
Reproduce code:
---
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
$strSQL = select all from something will make an error duh;
$objResult = mysql_query ($strSQL) or die (fn_Save_Error('this.php',
mysql_error());
Expected result:
Expected result is that the string value of mysql_error() is passed as
an argument of datatype string whether blank or with contents to the
fn_Save_Error function.
Actual result:
--
Mysql_error() is output directly to the screen/console, instead of
being passed as a value to fn_Save_Error for custom error handling.
Based on the mysql_error() documentation it should not output the error
to screen, it should return it as a string, so that I could do this:
...some wrong query execution...
$error_message = mysql_error(); echo ($error_message);
$error_message should be == to $mysql_error, but instead it just
outputs to screen/console
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41910 [Fbk-Opn]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
User updated by: dan at novapulsar dot com
Reported By: dan at novapulsar dot com
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
?php
//connect to valid mysql server
mysql_connect (localhost, user, password) or die
(mysql_error());
mysql_select_db (mysql) or die (mysql_error());
/* db doesn't really matter because we're trying to raise an error
based on an invalid query */
$strSQL = select all from nothing this is broken;
$objResult = mysql_execute ($strSQL) or die (fn_Save_Error ('this.php',
mysql_error()));
/*i expect to see the string generated by the save error function,
mysql_error() as a parameter. instead, the 'return' of mysql_error goes
directly to the screen, instead of being passed as a parameter as it is
documented*/
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
?
Previous Comments:
[2007-07-06 09:06:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-07-06 05:03:25] dan at novapulsar dot com
Description:
Since mysql_error() is documented to 'return' a string, I assumed it
would be safe to put it in either a string, or as an argument to an
error handling function.
Reproduce code:
---
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
$strSQL = select all from something will make an error duh;
$objResult = mysql_query ($strSQL) or die (fn_Save_Error('this.php',
mysql_error());
Expected result:
Expected result is that the string value of mysql_error() is passed as
an argument of datatype string whether blank or with contents to the
fn_Save_Error function.
Actual result:
--
Mysql_error() is output directly to the screen/console, instead of
being passed as a value to fn_Save_Error for custom error handling.
Based on the mysql_error() documentation it should not output the error
to screen, it should return it as a string, so that I could do this:
...some wrong query execution...
$error_message = mysql_error(); echo ($error_message);
$error_message should be == to $mysql_error, but instead it just
outputs to screen/console
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41910 [Fbk-Opn]: mysql_error doesn't return a string, just dumps output to screen
ID: 41910
User updated by: dan at novapulsar dot com
Reported By: dan at novapulsar dot com
-Status: Feedback
+Status: Open
Bug Type: MySQL related
Operating System: centos4.3
PHP Version: 4.4.7
New Comment:
Sorry, early in the morning, I meant mysql_query().
Previous Comments:
[2007-07-06 15:35:53] [EMAIL PROTECTED]
What is mysql_execute()?
[2007-07-06 15:30:24] dan at novapulsar dot com
?php
//connect to valid mysql server
mysql_connect (localhost, user, password) or die
(mysql_error());
mysql_select_db (mysql) or die (mysql_error());
/* db doesn't really matter because we're trying to raise an error
based on an invalid query */
$strSQL = select all from nothing this is broken;
$objResult = mysql_execute ($strSQL) or die (fn_Save_Error ('this.php',
mysql_error()));
/*i expect to see the string generated by the save error function,
mysql_error() as a parameter. instead, the 'return' of mysql_error goes
directly to the screen, instead of being passed as a parameter as it is
documented*/
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
?
[2007-07-06 09:06:51] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-07-06 05:03:25] dan at novapulsar dot com
Description:
Since mysql_error() is documented to 'return' a string, I assumed it
would be safe to put it in either a string, or as an argument to an
error handling function.
Reproduce code:
---
function fn_Save_Error ($x_page_url, $x_error) {
if (strlen($x_page_url) strlen($x_error)) {
//output if debugging is on
echo (Error on page: . $x_page_url . - . $x_error);
//save to db
}
}
$strSQL = select all from something will make an error duh;
$objResult = mysql_query ($strSQL) or die (fn_Save_Error('this.php',
mysql_error());
Expected result:
Expected result is that the string value of mysql_error() is passed as
an argument of datatype string whether blank or with contents to the
fn_Save_Error function.
Actual result:
--
Mysql_error() is output directly to the screen/console, instead of
being passed as a value to fn_Save_Error for custom error handling.
Based on the mysql_error() documentation it should not output the error
to screen, it should return it as a string, so that I could do this:
...some wrong query execution...
$error_message = mysql_error(); echo ($error_message);
$error_message should be == to $mysql_error, but instead it just
outputs to screen/console
--
Edit this bug report at http://bugs.php.net/?id=41910edit=1
#41899 [Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899 User updated by: geoffwa at cs dot rmit dot edu dot au Reported By: geoffwa at cs dot rmit dot edu dot au Status: Assigned Bug Type: Streams related Operating System: Solaris 10 PHP Version: 5.2.3 Assigned To: tony2001 New Comment: It's still broken in CVS (my bad - forgot to remove the workaround patch we had). virtual_file_ex() get called several times, with the last invocation being: virtual_file_ex(state = 0xffbfdf9c, path = 0xffbfe018 ../b/file, verify_path = (nil), use_realpath = 1) called from function expand_filepath virtual_file_ex returns 1 Having written a rather grandoise summary of stepping through virtual_file_ex() I think the problem might be in php_checkuid_ex(). Previous Comments: [2007-07-06 15:16:04] [EMAIL PROTECTED] Thanks, but I need to do it myself in order to understand it. I know quite well that realpath() on Solaris is badly broken, that's known issue and Sun is not going to do anything about as far as I understand. The problem is that we need to invent a workaround for it so that we don't break working realpath() implementations. And to do that I need to reproduce it myself and investigate it using GDB. [2007-07-06 15:00:30] geoffwa at cs dot rmit dot edu dot au Doing a bit of tracing of expand_filepath nets: (from PHP-5.2.3) expand_filepath(filepath = 0xffbff5f4 test2.php, real_path = 0xffbfee20 ) called from function php_execute_script expand_filepath returns 0xffbfee20 /home/g/geoffwa/test/test2.php expand_filepath(filepath = 0xffbfdec0 ./a, real_path = 0xffbfe2c4 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe2c4 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe108 ./a/b/file, real_path = 0xffbfe50c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe50c /home/g/geoffwa/test/a/b/file expand_filepath(filepath = 0xffbfe098 ./a, real_path = 0xffbfe49c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe49c /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe028 ./a, real_path = 0xffbfe42c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe42c /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe120 ./a/b, real_path = 0xffbfe524 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe524 /home/g/geoffwa/test/a/b expand_filepath(filepath = 0xffbfdfd8 ../b/file, real_path = 0xffbfe3dc ) called from function php_checkuid_ex expand_filepath returns (nil) (from PHP 5.2 snap 200707060030) expand_filepath(filepath = 0xffbff5ef test2.php, real_path = 0xffbfee18 ) called from function php_execute_script expand_filepath returns 0xffbfee18 /home/g/geoffwa/test/test2.php expand_filepath(filepath = 0xffbfdeb8 ./a, real_path = 0xffbfe2bc ) called from function php_checkuid_ex expand_filepath returns 0xffbfe2bc /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe100 ./a/b/file, real_path = 0xffbfe504 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe504 /home/g/geoffwa/test/a/b/file expand_filepath(filepath = 0xffbfe090 ./a, real_path = 0xffbfe494 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe494 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe020 ./a, real_path = 0xffbfe424 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe424 /home/g/geoffwa/test/a expand_filepath(filepath = 0xffbfe118 ./a/b, real_path = 0xffbfe51c ) called from function php_checkuid_ex expand_filepath returns 0xffbfe51c /home/g/geoffwa/test/a/b expand_filepath(filepath = 0xffbfdfd0 ../b/file, real_path = 0xffbfe3d4 ) called from function php_checkuid_ex expand_filepath returns 0xffbfe3d4 ../b/file expand_filepath(filepath = 0x53d1c0 ../b/file, real_path = (nil)) called from function _php_stream_fopen expand_filepath returns 0x53d398 ../b/file [2007-07-06 14:02:04] [EMAIL PROTECTED] Which configure options did you use? As I said, I don't see any difference between 5.2.3 and the snapshot and there should not be any difference since I don't remember any changes that could affect it. We use Sun Studio's C compiler, so I can use dbx for debugging I can use that too, but I prefer GDB. Is there
#41913 [Bgs]: dbase functions return not all records from a dbf file
ID: 41913
Updated by: [EMAIL PROTECTED]
Reported By: sdmaster at mail dot ru
Status: Bogus
Bug Type: dBase related
Operating System: Windows XP SP2
PHP Version: 5.2.3
New Comment:
I do not consider a bug something that doesn't work witn a third party
utility which is considered de-facto standard for viewing DBF files,
that's why the report is marked as bogus.
But feel free to send us a patch (to support b0rked DBFs), we would
gladly accept it if it doesn't break anything else.
Previous Comments:
[2007-07-06 15:55:54] sdmaster at mail dot ru
so the question remains.. will this be considered a bug of the
php_dbase extension and eventually fixed, or the result of dbview will
keep being a standard that php_dbase will stick to?
[2007-07-06 13:43:47] [EMAIL PROTECTED]
Well, then there is apparently some problem with the DBF file since not
only PHP, but the dbview tool does not show this 6th record.
[2007-07-06 13:05:11] sdmaster at mail dot ru
note that the sample dbf has in fact 6 (six) records!
I use dbf viewer 2000
[2007-07-06 09:17:40] [EMAIL PROTECTED]
Both PHP and dbview output 5 (five) records.
[2007-07-06 08:21:20] sdmaster at mail dot ru
Description:
I'm using Apache 2.2.4, php 5.2.3 loaded with LoadModule. php_dbase
extension v5.2.3.3. Apache is run from a local administrator's account.
after I open a dbf file and use dbase_numrecords() to retrieve number
of records in the file, it returns a number that is randomly less than
actual by 1, 2 or 3. accordingly, dbase_get_record_with_names() doesn't
want to get, i.e., 23-th record from a 24-records dbf file.
a sample dbf file is created by Delphi 7 TDbf component v6.9 and
contains russian characters in string fields.
at the same time such tools as DBV Viewer or like show everything
correctly.
reference to the sample dbf file lies inside comments in the posted php
code.
Reproduce code:
---
?
/*
a simple php code, purely from examples
test file is generated by TDbf Delphi 7 component
a sample dbf file, which is reported by php dbase functions to
have 1 records less than actual, could be taken from here:
http://b64.hopto.org/test.dbf
*/
if ($db = dbase_open('c:\temp\test.dbf', 0)) {
$rn = dbase_numrecords($db);
for ($i = 1; $i=$rn; $i++) {
$row=dbase_get_record_with_names($db, $i);
print_r($row);
}
dbase_close($db);
}
?
Expected result:
all records from dbf file
Actual result:
--
all records except the last one
--
Edit this bug report at http://bugs.php.net/?id=41913edit=1
#41917 [NEW]: oci_field_scale returns expected value multiplied by 256
From: nobleclem+phpbugs at gmail dot com
Operating system: Solaris
PHP version: 5.2.3
PHP Bug Type: OCI8 related
Bug description: oci_field_scale returns expected value multiplied by 256
Description:
When using oci_field_scale to obtain the value stored in
all_tab_columns.data_scale in oracle for a field the value returned is that
in all_tab_columns.data_scale multiplied by 256.
Reproduce code:
---
Assumptions:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2
Code:
$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, SELECT * FROM fees);
oci_execute($stmt);
$field_number = 2;
$scale = oci_field_scale( $stmt, $field_number );
Expected result:
$scale should be assigned the value of 2.
Actual result:
--
$scale is assigned the value of 512.
--
Edit bug report at http://bugs.php.net/?id=41917edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=41917r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=41917r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=41917r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=41917r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=41917r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=41917r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=41917r=needscript
Try newer version:http://bugs.php.net/fix.php?id=41917r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=41917r=support
Expected behavior:http://bugs.php.net/fix.php?id=41917r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=41917r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=41917r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=41917r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=41917r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=41917r=dst
IIS Stability:http://bugs.php.net/fix.php?id=41917r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=41917r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=41917r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=41917r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=41917r=mysqlcfg
#41917 [Opn-Bgs]: oci_field_scale returns expected value multiplied by 256
ID: 41917
Updated by: [EMAIL PROTECTED]
Reported By: nobleclem+phpbugs at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: Solaris
PHP Version: 5.2.3
New Comment:
PHP/OCI8 returns exactly what it got from OCIAttrGet(..,
OCI_DTYPE_PARAM, .., .., OCI_ATTR_SCALE, ).
If Oracle Client returns wrong information, we can't change or fix
that.
Previous Comments:
[2007-07-06 18:40:17] nobleclem+phpbugs at gmail dot com
Description:
When using oci_field_scale to obtain the value stored in
all_tab_columns.data_scale in oracle for a field the value returned is
that in all_tab_columns.data_scale multiplied by 256.
Reproduce code:
---
Assumptions:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2
Code:
$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, SELECT * FROM fees);
oci_execute($stmt);
$field_number = 2;
$scale = oci_field_scale( $stmt, $field_number );
Expected result:
$scale should be assigned the value of 2.
Actual result:
--
$scale is assigned the value of 512.
--
Edit this bug report at http://bugs.php.net/?id=41917edit=1
#41917 [Bgs-Opn]: oci_field_scale returns expected value multiplied by 256
ID: 41917
Updated by: [EMAIL PROTECTED]
Reported By: nobleclem+phpbugs at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: OCI8 related
Operating System: Solaris
PHP Version: 5.2.3
New Comment:
Although I can't reproduce the given testcase on Linux there is a bug
here that stops other testcases working for me, and may cause a port
specific difference in behavior for nobleclem's testcase.
The datatypes of the scale and precision fields in php_oci_out_column
(php_oci8_int.h) should be sb1 and s2 respectively. At the moment they
are both ub2. This, for example, prevents the scale for a FLOAT column
being displayed as -127.
See table 6.8 in Oracle's OCI manual:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci06des.htm#sthref949
@nobleclem, the scale and precision values returned by the OCI8
extension and Oracle's OCI library are the programmatic definitions of
scale and precision, which are different to the user-level values given
in the all_tab_columns table.
@tony2001, I will commit a new testcase to PHP5 and 6, but will let you
evaluate and merge the datatype fix.
Previous Comments:
[2007-07-06 18:53:11] [EMAIL PROTECTED]
PHP/OCI8 returns exactly what it got from OCIAttrGet(..,
OCI_DTYPE_PARAM, .., .., OCI_ATTR_SCALE, ).
If Oracle Client returns wrong information, we can't change or fix
that.
[2007-07-06 18:40:17] nobleclem+phpbugs at gmail dot com
Description:
When using oci_field_scale to obtain the value stored in
all_tab_columns.data_scale in oracle for a field the value returned is
that in all_tab_columns.data_scale multiplied by 256.
Reproduce code:
---
Assumptions:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2
Code:
$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, SELECT * FROM fees);
oci_execute($stmt);
$field_number = 2;
$scale = oci_field_scale( $stmt, $field_number );
Expected result:
$scale should be assigned the value of 2.
Actual result:
--
$scale is assigned the value of 512.
--
Edit this bug report at http://bugs.php.net/?id=41917edit=1
#41917 [Opn]: oci_field_scale returns expected value multiplied by 256
ID: 41917
Updated by: [EMAIL PROTECTED]
Reported By: nobleclem+phpbugs at gmail dot com
Status: Open
Bug Type: OCI8 related
Operating System: Solaris
PHP Version: 5.2.3
New Comment:
A new test has been merged and old tests updated. They will cause
diffs until Tony merges the code change.
The suggested fix is:
--- php_oci8_int.h 29 Mar 2007 02:33:03 -0700 1.11.2.6.2.18
+++ php_oci8_int.h 06 Jul 2007 15:53:44 -0700
@@ -215,8 +215,8 @@
php_oci_define *define; /* define handle */
int piecewise; /* column is fetched
piece-by-piece */
ub4 cb_retlen; /* */
- ub2 scale; /* column scale
*/
- ub2 precision; /* column precision */
+ sb1 scale; /* column scale
*/
+ sb2 precision; /* column precision */
ub1 charset_form; /* charset form,
required for NCLOBs */
ub2 charset_id; /* charset ID */
} php_oci_out_column; /* }}} */
Previous Comments:
[2007-07-06 22:12:51] [EMAIL PROTECTED]
Although I can't reproduce the given testcase on Linux there is a bug
here that stops other testcases working for me, and may cause a port
specific difference in behavior for nobleclem's testcase.
The datatypes of the scale and precision fields in php_oci_out_column
(php_oci8_int.h) should be sb1 and s2 respectively. At the moment they
are both ub2. This, for example, prevents the scale for a FLOAT column
being displayed as -127.
See table 6.8 in Oracle's OCI manual:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14250/oci06des.htm#sthref949
@nobleclem, the scale and precision values returned by the OCI8
extension and Oracle's OCI library are the programmatic definitions of
scale and precision, which are different to the user-level values given
in the all_tab_columns table.
@tony2001, I will commit a new testcase to PHP5 and 6, but will let you
evaluate and merge the datatype fix.
[2007-07-06 18:53:11] [EMAIL PROTECTED]
PHP/OCI8 returns exactly what it got from OCIAttrGet(..,
OCI_DTYPE_PARAM, .., .., OCI_ATTR_SCALE, ).
If Oracle Client returns wrong information, we can't change or fix
that.
[2007-07-06 18:40:17] nobleclem+phpbugs at gmail dot com
Description:
When using oci_field_scale to obtain the value stored in
all_tab_columns.data_scale in oracle for a field the value returned is
that in all_tab_columns.data_scale multiplied by 256.
Reproduce code:
---
Assumptions:
- field #2 is of type NUMBER(12,2)
- all_tab_columns.data_precision is 12
- all_tab_columns.data_scale value is 2
Code:
$conn = oci_connect('username', 'password');
$stmt = oci_parse($conn, SELECT * FROM fees);
oci_execute($stmt);
$field_number = 2;
$scale = oci_field_scale( $stmt, $field_number );
Expected result:
$scale should be assigned the value of 2.
Actual result:
--
$scale is assigned the value of 512.
--
Edit this bug report at http://bugs.php.net/?id=41917edit=1
#37381 [Com]: auto_globals_jit fails to correctly intialize variables
ID: 37381
Comment by: php at modem-help dot com
Reported By: gcp at sjeng dot org
Status: No Feedback
Bug Type: Variables related
Operating System: FreeBSD 6.0
PHP Version: 5.1.4
New Comment:
PHP 5.1.6
(RedHat FC6; std PHP, Apache; fully updated)
`auto_globals_jit = On' works fine with 'normal' PHP scripts. However,
when included via `auto_prepend_file' $_SERVER is completely absent
(together with other Globals).
Test case:
file script:
?php
if( !empty( $GLOBALS[ '_SERVER' ])) {
$_SERVER_ARRAY = '_SERVER';
} elseif( !empty( $GLOBALS[ 'HTTP_SERVER_VARS' ])) {
$_SERVER_ARRAY = 'HTTP_SERVER_VARS';
} else {
$_SERVER_ARRAY = 'GLOBALS';
}
global ${$_SERVER_ARRAY};
$ipRemote = ${$_SERVER_ARRAY}[ 'REMOTE_ADDR' ];
var_dump($GLOBALS);
?
httpd.conf:
IfModule mod_php5.c
AddType application/x-httpd-php .html
php_value auto_prepend_file /path/to/test/file
/IfModule
php.ini:
variables_order = EGPCS
register_globals = Off
register_long_arrays = Off
register_argc_argv = On
auto_globals_jit = On
The above produces nothing ($_SERVER is absent). Change
`auto_globals_jit' to `Off' (plus `apachectl graceful') and it works.
Time to pay attention to this, folks.
- Alex Kemp
Previous Comments:
[2006-06-09 11:01:45] me at thomaskeller dot biz
I forgot to mention: I'm using the apache2handler with httpd-2.2.0
[2006-06-09 10:57:48] me at thomaskeller dot biz
I've encountered the same problem, with a normal rpm installation of
php-5.1.4-1 which ships with FC5.
A simple reproducable script would be
? var_dump($_SERVER); ?
which returns NULL if auto_globals_jit is set to on (default in this
rpm package). This is the same deal with $_REQUEST, which is also NULL.
Now, even if auto_globals_jit is set to false, $_GLOBALS is still not
available.
[2006-06-01 01:00:00] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-05-24 21:59:33] [EMAIL PROTECTED]
Unfortunately, I don't think anybody will be able to find time to debug
phpMyAdmin.
So please provide a short but complete reproduce script to speedup the
resolution of the issue.
[2006-05-10 11:19:09] gcp at sjeng dot org
I don't know of any small testcase. As indicated, this is 100% a
regression in PHP 5.1.3 or 5.1.4 compared to 5.1.2, it's possible to
make it appear/disappear by toggling the indicated PHP setting, and it
happens with a very popular PHP package, in the routine mentioned
earlier.
I can provide help tracing the issue, but I do not have a 10-20 line
reproducible case.
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/37381
--
Edit this bug report at http://bugs.php.net/?id=37381edit=1
#41899 [Asn]: Can't open files with leading relative path of '..' and '..' is not readable
ID: 41899
User updated by: geoffwa at cs dot rmit dot edu dot au
Reported By: geoffwa at cs dot rmit dot edu dot au
Status: Assigned
Bug Type: Streams related
Operating System: Solaris 10
PHP Version: 5.2.3
Assigned To: tony2001
New Comment:
No idea if this is correct but it fixes it:
diff -ur ./php5.2-200707060030/main/safe_mode.c
./php-5.2-snap/main/safe_mode.c
--- ./php5.2-200707060030/main/safe_mode.c 2007-01-13
00:30:58.0 +1100
+++ ./php-5.2-snap/main/safe_mode.c 2007-07-07 11:42:10.804129000
+1000
@@ -86,7 +86,8 @@
* If that fails, passthrough and check directory...
*/
if (mode != CHECKUID_ALLOW_ONLY_DIR) {
- expand_filepath(filename, path TSRMLS_CC);
+ // VCWD_STAT() can handle relative paths right?
+ strlcpy(path, filename, MAXPATHLEN);
ret = VCWD_STAT(path, sb);
if (ret 0) {
if (mode == CHECKUID_DISALLOW_FILE_NOT_EXISTS)
{
diff -ur ./php5.2-200707060030/main/streams/plain_wrapper.c
./php-5.2-snap/main/streams/plain_wrapper.c
--- ./php5.2-200707060030/main/streams/plain_wrapper.c 2007-04-19
00:31:35.0 +1000
+++ ./php-5.2-snap/main/streams/plain_wrapper.c 2007-07-07
11:58:57.673891000 +1000
@@ -888,9 +888,10 @@
return NULL;
}
- if ((realpath = expand_filepath(filename, NULL TSRMLS_CC)) ==
NULL) {
- return NULL;
- }
+ //if ((realpath = expand_filepath(filename, NULL TSRMLS_CC)) ==
NULL) {
+ // return NULL;
+ //}
+ realpath = estrndup(filename, strlen(filename));
if (persistent) {
spprintf(persistent_id, 0, streams_stdio_%d_%s,
open_flags, realpath);
Previous Comments:
[2007-07-06 16:04:30] geoffwa at cs dot rmit dot edu dot au
It's still broken in CVS (my bad - forgot to remove the workaround
patch we had).
virtual_file_ex() get called several times, with the last
invocation being:
virtual_file_ex(state = 0xffbfdf9c,
path = 0xffbfe018 ../b/file,
verify_path = (nil),
use_realpath = 1)
called from function expand_filepath
virtual_file_ex returns 1
Having written a rather grandoise summary of stepping through
virtual_file_ex() I think the problem might be in php_checkuid_ex().
[2007-07-06 15:16:04] [EMAIL PROTECTED]
Thanks, but I need to do it myself in order to understand it.
I know quite well that realpath() on Solaris is badly broken, that's
known issue and Sun is not going to do anything about as far as I
understand.
The problem is that we need to invent a workaround for it so that we
don't break working realpath() implementations.
And to do that I need to reproduce it myself and investigate it using
GDB.
[2007-07-06 15:00:30] geoffwa at cs dot rmit dot edu dot au
Doing a bit of tracing of expand_filepath nets:
(from PHP-5.2.3)
expand_filepath(filepath = 0xffbff5f4 test2.php,
real_path = 0xffbfee20 )
called from function php_execute_script
expand_filepath returns 0xffbfee20 /home/g/geoffwa/test/test2.php
expand_filepath(filepath = 0xffbfdec0 ./a,
real_path = 0xffbfe2c4 )
called from function php_checkuid_ex
expand_filepath returns 0xffbfe2c4 /home/g/geoffwa/test/a
expand_filepath(filepath = 0xffbfe108 ./a/b/file,
real_path = 0xffbfe50c )
called from function php_checkuid_ex
expand_filepath returns 0xffbfe50c /home/g/geoffwa/test/a/b/file
expand_filepath(filepath = 0xffbfe098 ./a,
real_path = 0xffbfe49c )
called from function php_checkuid_ex
expand_filepath returns 0xffbfe49c /home/g/geoffwa/test/a
expand_filepath(filepath = 0xffbfe028 ./a,
real_path = 0xffbfe42c )
called from function php_checkuid_ex
expand_filepath returns 0xffbfe42c /home/g/geoffwa/test/a
expand_filepath(filepath = 0xffbfe120 ./a/b,
real_path = 0xffbfe524 )
called from function php_checkuid_ex
expand_filepath returns 0xffbfe524 /home/g/geoffwa/test/a/b
expand_filepath(filepath = 0xffbfdfd8 ../b/file,
real_path = 0xffbfe3dc )
called from function php_checkuid_ex
expand_filepath returns (nil)
(from PHP 5.2 snap 200707060030)
expand_filepath(filepath = 0xffbff5ef test2.php,
real_path = 0xffbfee18 )
called from function php_execute_script
expand_filepath returns 0xffbfee18 /home/g/geoffwa/test/test2.php
expand_filepath(filepath = 0xffbfdeb8 ./a,
real_path = 0xffbfe2bc )
called from function php_checkuid_ex
expand_filepath returns
