Bug #63073 [Opn]: master make install fails to install PEAR
Edit report at https://bugs.php.net/bug.php?id=63073edit=1 ID: 63073 Updated by: dani...@php.net Reported by:php at bof dot de Summary:master make install fails to install PEAR Status: Open Type: Bug Package:Compile Failure Operating System: openSUSE 11.4 64bit -PHP Version:master-Git-2012-09-12 (Git) +PHP Version:5.5 Block user comment: N Private report: N New Comment: This needs to be fixed so PHP 5.5 can be properly tested. Things work as expected when building PHP = 5.4. Previous Comments: [2012-10-14 11:06:27] bobvin at pillars dot net Branch master does not compile and also is missing file sapi/fpm/php- fpm.service.in Running git-bisect to find the break point, This is the commit that broke compilation: commit 4968fa644b0849321e1761e52b8db15dd46f9b75 Author: theanomaly...@gmail.com googleguy@googleguy-virtualbox.(none) Date: Tue Apr 17 07:31:36 2012 -0400 Fixed bug #61038; Z and better behavior for unpack() Added new Z argument to pack/unpack, now allowing a to return data without stripping, and A strips all trailing white space, while Z will strip everything after the first null. [2012-09-12 15:30:17] php at bof dot de Description: I'm building PHP master from current git (at 5246d6f02e52798e343bd5208692f1a5ed89b9d9) Compile works fine, but on make install, PEAR does not install. See Actual result regarding the error output I get. I can successfully compile AND install, with identical configure, the PHP-5.4.6 release, so I don't think that there is anything wrong with my build environment. I tried to copy over pecl, pear, and the pear environment, from the 5.4 build/install. pecl and pear search works. download or install fetches the file, but then fails with a similar could not extract error. Test script: --- make install Expected result: Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar- already installed: 1.3.7 [PEAR] Console_Getopt - already installed: 1.3.0 [PEAR] Structures_Graph- already installed: 1.0.4 [PEAR] XML_Util - already installed: 1.2.1 [PEAR] PEAR - already installed: 1.9.4 Actual result: -- Installing PEAR environment: /opt/php/php/ [PEAR] Archive_Tar: could not extract the package.xml file from phar://install- pear-nozlib.phar/Archive_Tar-1.3.7.tar [PEAR] Console_Getopt: could not extract the package.xml file from phar://install-pear-nozlib.phar/Console_Getopt-1.3.0.tar [PEAR] Structures_Graph: could not extract the package.xml file from phar://install-pear-nozlib.phar/Structures_Graph-1.0.4.tar [PEAR] XML_Util: could not extract the package.xml file from phar://install- pear-nozlib.phar/XML_Util-1.2.1.tar [PEAR] PEAR: could not extract the package.xml file from phar://install-pear- nozlib.phar/PEAR-1.9.4.tar -- Edit this bug report at https://bugs.php.net/bug.php?id=63073edit=1
Bug #60981 [Opn-Fbk]: Shell environment inaccessible in tests
Edit report at https://bugs.php.net/bug.php?id=60981edit=1 ID: 60981 Updated by: dani...@php.net Reported by:david at davidfavor dot com Summary:Shell environment inaccessible in tests -Status: Open +Status: Feedback Type: Bug Package:Testing related Operating System: Ubuntu 11.10 PHP Version:5.3.10 -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: The environment variables need to be established in a scope available all shell scripts. For example, them in the ~/.bashrc script of the user executing make test. Set the variables in ~/.bashrc source ~/.bashrc make test The source step is only necessary in the first shell since the variables were not available when the shell was opened. All future shells will have them. Previous Comments: [2012-02-05 18:50:42] david at davidfavor dot com Description: Shell environment variables are not accessible via getenv() during tests. Test script: --- export MYSQL_TEST_PASSWD=... make test TESTS=ext/mysql*/tests/001.phpt Runs the mysql + mysqli connect tests and both are skipped. Tests are skipped showing... (using password: NO) Manually setting $passwd in connect.inc for both test sets runs all tests as expected. So MYSQL_TEST_PASSWD is ignored. -- Edit this bug report at https://bugs.php.net/bug.php?id=60981edit=1
Bug #60333 [Opn]: fetch_field() length multiplied by 3 in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60333edit=1
ID: 60333
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:fetch_field() length multiplied by 3 in mysqlnd
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.4SVN-2011-11-19 (SVN)
Block user comment: N
Private report: N
New Comment:
Can this please be fixed before PHP 5.4 goes out the door?
Previous Comments:
[2011-11-21 18:04:38] danielc at analysisandsolutions dot com
That may be the case, but having UTF-8 fields is legit and the answers from
libmysql and mysqlnd should be the same.
[2011-11-21 17:59:23] william dot bailey at cowboysfromhell dot co dot uk
I think this might be down to what encoding the connection is using.
The length in bytes of a mysql utf8 CHAR(2) field is 6.
If you issue a $db-query('SET NAMES latin1'); before the CREATE TABLE then you
should get the results you are expecting.
[2011-11-19 02:38:53] danielc at analysisandsolutions dot com
Description:
Running PHP 5.4 compiled from svn earlier today. The length values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd. The
values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db-query(CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL));
if (!$result) {
echo OOPS: $db-error\n;
exit(1);
}
$result = $db-query(INSERT INTO phptest_fk VALUES ('One', 'c1'));
$result = $db-query(SELECT * FROM phptest_fk);
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60333edit=1
[PHP-BUG] Bug #60734 [NEW]: POST, SKIPIF and CLEAN fail if phpt path has spaces
From: Operating system: PHP version: Irrelevant Package: *General Issues Bug Type: Bug Bug description:POST, SKIPIF and CLEAN fail if phpt path has spaces Description: The POST, SKIPIF and CLEAN sections for phpt fail to execute if the path to the test file has spaces in it. Will attach a patch for run-tests.php. -- Edit bug report at https://bugs.php.net/bug.php?id=60734edit=1 -- Try a snapshot (PHP 5.4): https://bugs.php.net/fix.php?id=60734r=trysnapshot54 Try a snapshot (PHP 5.3): https://bugs.php.net/fix.php?id=60734r=trysnapshot53 Try a snapshot (trunk): https://bugs.php.net/fix.php?id=60734r=trysnapshottrunk Fixed in SVN: https://bugs.php.net/fix.php?id=60734r=fixed Fixed in SVN and need be documented: https://bugs.php.net/fix.php?id=60734r=needdocs Fixed in release: https://bugs.php.net/fix.php?id=60734r=alreadyfixed Need backtrace: https://bugs.php.net/fix.php?id=60734r=needtrace Need Reproduce Script: https://bugs.php.net/fix.php?id=60734r=needscript Try newer version: https://bugs.php.net/fix.php?id=60734r=oldversion Not developer issue: https://bugs.php.net/fix.php?id=60734r=support Expected behavior: https://bugs.php.net/fix.php?id=60734r=notwrong Not enough info: https://bugs.php.net/fix.php?id=60734r=notenoughinfo Submitted twice: https://bugs.php.net/fix.php?id=60734r=submittedtwice register_globals: https://bugs.php.net/fix.php?id=60734r=globals PHP 4 support discontinued: https://bugs.php.net/fix.php?id=60734r=php4 Daylight Savings:https://bugs.php.net/fix.php?id=60734r=dst IIS Stability: https://bugs.php.net/fix.php?id=60734r=isapi Install GNU Sed: https://bugs.php.net/fix.php?id=60734r=gnused Floating point limitations: https://bugs.php.net/fix.php?id=60734r=float No Zend Extensions: https://bugs.php.net/fix.php?id=60734r=nozend MySQL Configuration Error: https://bugs.php.net/fix.php?id=60734r=mysqlcfg
Bug #60467 [Opn]: About 107 auto test [phpt script] failed .
Edit report at https://bugs.php.net/bug.php?id=60467edit=1 ID: 60467 Updated by: dani...@php.net Reported by:Jtang at suse dot com Summary:About 107 auto test [phpt script] failed . Status: Open Type: Bug Package:Testing related Operating System: SLES 11 SP2 PHP Version:5.3.8 Block user comment: N Private report: N New Comment: I'll deal with the ext/date/tests portions in the near future. Previous Comments: [2011-12-08 03:34:59] Jtang at suse dot com Description: I use the phpt file from php 5.3 tarball package for automation test. 11338 test file , 107 failed , in 107 failed : # 33 test are expect as described in output # 9 test have bug NO. # 66 test is failed 66 test cases are: ./ext/calendar/tests/easter_date.phpt ./ext/calendar/tests/unixtojd.phpt ./ext/date/tests/DateTime_days-spring-type2-type2.phpt ./ext/date/tests/DateTime_days-spring-type2-type3.phpt ./ext/date/tests/DateTime_days-spring-type3-type2.phpt ./ext/date/tests/DateTime_days-spring-type3-type3.phpt ./ext/date/tests/DateTime_sub-dates.phpt ./ext/date/tests/DateTime_sub-february.phpt ./ext/date/tests/timezone_location_get.phpt ./ext/dom/tests/DOMDocument_relaxNGValidate_error2.phpt ./ext/dom/tests/DOMDocument_validate_on_parse_variation.phpt ./ext/gmp/tests/gmp_nextprime.phpt ./ext/intl/tests/resourcebundle_arrayaccess.phpt ./ext/intl/tests/resourcebundle_individual.phpt ./ext/intl/tests/resourcebundle_iterator.phpt ./ext/mysql/tests/001.phpt ./ext/mysql/tests/mysql_connect.phpt ./ext/mysql/tests/mysql_max_links.phpt ./ext/mysql/tests/mysql_sql_safe_mode.phpt ./ext/mysqli/tests/mysqli_connect.phpt ./ext/mysqli/tests/mysqli_connect_oo.phpt ./ext/mysqli/tests/mysqli_connect_oo_defaults.phpt ./ext/pcre/tests/006.phpt ./ext/pdo_mysql/tests/pdo_mysql___construct_options.phpt ./ext/pdo_mysql/tests/pdo_mysql_interface.phpt ./ext/posix/tests/posix_ttyname_error.phpt ./ext/posix/tests/posix_ttyname_variation1.phpt ./ext/posix/tests/posix_ttyname_variation2.phpt ./ext/posix/tests/posix_ttyname_variation3.phpt ./ext/posix/tests/posix_ttyname_variation4.phpt ./ext/posix/tests/posix_ttyname_variation5.phpt ./ext/posix/tests/posix_ttyname_variation6.phpt ./ext/posix/tests/posix_ttyname_variation7.phpt ./ext/session/tests/014.phpt ./ext/session/tests/015.phpt ./ext/session/tests/018.phpt ./ext/session/tests/020.phpt ./ext/session/tests/021.phpt ./ext/session/tests/session_id_variation2.phpt ./ext/sockets/tests/socket_strerror.phpt ./ext/spl/examples/tests/dualiterator_001.phpt ./ext/sqlite/tests/sqlite_session_001.phpt ./ext/sqlite/tests/sqlite_session_002.phpt ./ext/sqlite3/tests/sqlite3_prepare_001.phpt ./ext/standard/tests/class_object/is_a_error_001.phpt ./ext/standard/tests/class_object/is_subclass_of_error_001.phpt ./ext/standard/tests/general_functions/getservbyname_variation10.phpt ./ext/standard/tests/general_functions/getservbyname_variation9.phpt ./ext/standard/tests/general_functions/getservbyport_variation1.phpt ./ext/standard/tests/general_functions/phpinfo.phpt ./ext/standard/tests/general_functions/proc_nice_variation5.phpt ./ext/standard/tests/misc/time_sleep_until_basic.phpt ./ext/standard/tests/php_ini_loaded_file.phpt ./ext/standard/tests/strings/htmlentities02.phpt ./ext/standard/tests/strings/htmlentities04.phpt ./ext/standard/tests/strings/htmlentities10.phpt ./ext/standard/tests/strings/htmlentities11.phpt ./ext/standard/tests/strings/htmlentities13.phpt ./ext/standard/tests/strings/htmlentities15.phpt ./ext/standard/tests/strings/setlocale_variation2.phpt ./ext/xsl/tests/xslt010.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcnostring.phpt ./ext/xsl/tests/xsltprocessor_registerPHPFunctions-funcundef.phpt ./sapi/cli/tests/001.phpt ./sapi/cli/tests/015.phpt Test script: --- only one line script env TEST_PHP_EXECUTABLE=/usr/bin/php REPORT_EXIT_STATUS=1 TEST_PHP_SRCDIR=/usr/share/qa/qa_test_php53 TEST_PHP_DETAILED=1 NO_INTERACTION=1 /usr/bin/php -d 'open_basedir=' -d 'output_buffering=0' -d 'memory_limit=-1' /usr/share/qa/qa_test_php53/run-tests.php [phpt.file] Expected result: 65 test cases should pass? Actual result: -- 65 test cases failed -- Edit this bug report at https://bugs.php.net/bug.php?id=60467edit=1
[PHP-BUG] Bug #60362 [NEW]: non-existent sub-sub keys should not have values
From:
Operating system: linux
PHP version: 5.4SVN-2011-11-23 (SVN)
Package: Arrays related
Bug Type: Bug
Bug description:non-existent sub-sub keys should not have values
Description:
In an array, a sub-sub-key of an existing key is now returning a letter of
the value indexed by the main key. This is a regression in 5.4. PHP 5.3
still operates as expected. I suspect this is related to the array
dereferencing changes.
Test script:
---
$arr = array('exists' = 'foo');
if (isset($arr['exists']['non_existent'])) {
echo expected: sub-key 'non_existent' is set: ;
var_dump($arr['exists']['non_existent']);
} else {
echo BEHAVIOR CHANGED: sub-key 'non_existent' is not set.\n;
}
if (isset($arr['exists'][1])) {
echo expected: sub-key 1 is set: ;
var_dump($arr['exists'][1]);
} else {
echo BEHAVIOR CHANGED: sub-key 1 is not set.\n;
}
echo ---\n;
if (isset($arr['exists']['non_existent']['sub_sub'])) {
echo BEHAVIOR CHANGED: sub-key 'sub_sub' is set: ;
var_dump($arr['exists']['non_existent']['sub_sub']);
} else {
echo good: sub-sub-key 'sub_sub' is not set.\n;
}
if (isset($arr['exists'][1][0])) {
echo BEHAVIOR CHANGED: sub-sub-key 0 is set: ;
var_dump($arr['exists'][1][0]);
} else {
echo good: sub-sub-key 0 is not set.\n;
}
echo ---\n;
if (empty($arr['exists']['non_existent'])) {
echo BEHAVIOR CHANGED: sub-key 'non_existent' is empty.\n;
} else {
echo expected: sub-key 'non_existent' is not empty: ;
var_dump($arr['exists']['non_existent']);
}
if (empty($arr['exists'][1])) {
echo BEHAVIOR CHANGED: sub-key 1 is empty.\n;
} else {
echo expected: sub-key 1 is NOT empty: ;
var_dump($arr['exists'][1]);
}
echo ---\n;
if (empty($arr['exists']['non_existent']['sub_sub'])) {
echo good: sub-sub-key 'sub_sub' is empty.\n;
} else {
echo BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: ;
var_dump($arr['exists']['non_existent']['sub_sub']);
}
if (empty($arr['exists'][1][0])) {
echo good: sub-sub-key 0 is empty.\n;
} else {
echo BEHAVIOR CHANGED: sub-sub-key 0 is not empty: ;
var_dump($arr['exists'][1][0]);
}
Expected result:
expected: sub-key 'non_existent' is set: string(1) f
expected: sub-key 1 is set: string(1) o
---
good: sub-sub-key 'sub_sub' is not set.
good: sub-sub-key 0 is not set.
---
expected: sub-key 'non_existent' is not empty: string(1) f
expected: sub-key 1 is NOT empty: string(1) o
---
good: sub-sub-key 'sub_sub' is empty.
good: sub-sub-key 0 is empty.
Actual result:
--
expected: sub-key 'non_existent' is set: string(1) f
expected: sub-key 1 is set: string(1) o
---
BEHAVIOR CHANGED: sub-key 'sub_sub' is set: string(1) f
BEHAVIOR CHANGED: sub-sub-key 0 is set: string(1) o
---
expected: sub-key 'non_existent' is not empty: string(1) f
expected: sub-key 1 is NOT empty: string(1) o
---
BEHAVIOR CHANGED: sub-sub-key 'sub_sub' is not empty: string(1) f
BEHAVIOR CHANGED: sub-sub-key 0 is not empty: string(1) o
--
Edit bug report at https://bugs.php.net/bug.php?id=60362edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60362r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60362r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60362r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60362r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60362r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60362r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60362r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60362r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60362r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60362r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60362r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60362r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60362r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60362r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60362r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60362r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60362r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60362r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60362r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60362r=nozend
MySQL
Bug #55792 [Opn-Bgs]: strtotime(-1 month);
Edit report at https://bugs.php.net/bug.php?id=55792edit=1 ID: 55792 Updated by: dani...@php.net Reported by:fjm20016 at 163 dot com Summary:strtotime(-1 month); -Status: Open +Status: Bogus Type: Bug Package:Date/time related Operating System: windows PHP Version:5.3.8 -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: 1) Use the add(), sub() or modify() DateTime methods for date math. 2) Adding months to dates on or after the 29th of the month is unreliable, as you've found. When performing such operations, an advisable approach is changing the date to the first day of the month, add or subtract the number of months desired, than change the date to the last day of that month. Previous Comments: [2011-09-27 02:13:46] fjm20016 at 163 dot com Description: I often use strtotime, I won't change my program anywhere. +1 month -1 month maybe as expected Test script: --- date(Y-m-d H:i:s, strtotime(-1 month, strtotime(2011-05-31 00:00:00))); //2011-05-01 as expected //2011-04-30 I Like date(Y-m-d H:i:s, strtotime(+1 month, strtotime(2011-05-31 00:00:00))); //2011-07-01 as expected //2011-06-30 I Like date(Y-m-d H:i:s, strtotime(-1 month, strtotime(2011-03-31 00:00:00))); //2011-03-03 as expected //2011-02-28 I Like -- Edit this bug report at https://bugs.php.net/bug.php?id=55792edit=1
Bug #60333 [Opn]: fetch_field() length multiplied by 3 in mysqlnd
Edit report at https://bugs.php.net/bug.php?id=60333edit=1
ID: 60333
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:fetch_field() length multiplied by 3 in mysqlnd
Status: Open
Type: Bug
Package:MySQLi related
Operating System: linux
PHP Version:5.4SVN-2011-11-19 (SVN)
Block user comment: N
Private report: N
New Comment:
That may be the case, but having UTF-8 fields is legit and the answers from
libmysql and mysqlnd should be the same.
Previous Comments:
[2011-11-21 17:59:23] william dot bailey at cowboysfromhell dot co dot uk
I think this might be down to what encoding the connection is using.
The length in bytes of a mysql utf8 CHAR(2) field is 6.
If you issue a $db-query('SET NAMES latin1'); before the CREATE TABLE then you
should get the results you are expecting.
[2011-11-19 02:38:53] danielc at analysisandsolutions dot com
Description:
Running PHP 5.4 compiled from svn earlier today. The length values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd. The
values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db-query(CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL));
if (!$result) {
echo OOPS: $db-error\n;
exit(1);
}
$result = $db-query(INSERT INTO phptest_fk VALUES ('One', 'c1'));
$result = $db-query(SELECT * FROM phptest_fk);
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit this bug report at https://bugs.php.net/bug.php?id=60333edit=1
Bug #60237 [Asn-Dup]: TLA timezone dates produce wrong results with add/diff
Edit report at https://bugs.php.net/bug.php?id=60237edit=1
ID: 60237
Updated by: dani...@php.net
Reported by:s...@php.net
Summary:TLA timezone dates produce wrong results with
add/diff
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: *
PHP Version:5.4.0beta2
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=55253.
Previous Comments:
[2011-11-07 18:15:45] s...@php.net
Description:
If you diff two dates with TLA timezone (like EDT) and then add the interval
back
to the earliest date, you would not get the later date but instead the result
will
be one hour off. See example below.
Test script:
---
$start = new DateTime('2010-06-04 02:18:48 EDT');
var_dump($start-format('U'));
$end = new DateTime('2010-06-06 18:38:28 EDT');
$ts = $end-format('U');
var_dump($start, $end);
$int = $start-diff($end);
var_dump($int, $start);
var_dump($start-format('U'));
$res = $start-add($int);
var_dump($res);
Expected result:
.
object(DateTime)#1 (3) {
[date]=
string(19) 2010-06-06 18:38:28
[timezone_type]=
int(2)
[timezone]=
string(3) EDT
}
Actual result:
--
...
object(DateTime)#1 (3) {
[date]=
string(19) 2010-06-06 17:38:28
[timezone_type]=
int(2)
[timezone]=
string(3) EDT
}
--
Edit this bug report at https://bugs.php.net/bug.php?id=60237edit=1
Bug #54799 [Asn-Dup]: Incorrect results when operating with time on DST changes
Edit report at https://bugs.php.net/bug.php?id=54799edit=1
ID: 54799
Updated by: dani...@php.net
Reported by:robertoherreros at gmail dot com
Summary:Incorrect results when operating with time on DST
changes
-Status: Assigned
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.6
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=51051
Previous Comments:
[2011-05-18 08:34:47] robertoherreros at gmail dot com
One more thing:
// BAD
// 2011-03-27, 02:00:00 - 03:00:00
// Expected: 2011-03-27 03:30:00, Actual: 2011-03-27 02:30:00
// 2011-03-27 02:30:00 don't exists
$tz = new DateTimezone('Europe/Madrid');
$d = new DateTime('2011-03-27 02:30:00',$tz);
echo $d-format('Y-m-d H:i:s').'br/';
[2011-05-17 16:57:51] robertoherreros at gmail dot com
Description:
Incorrect results when operating with time on DST changes.
Operations like: '-1 hour', '-1 min' or setTime()
In order to resolve the problem, all operations with time must be done in
timestamp directly.
Test script:
---
// 2011-03-27, 02:00:00 - 03:00:00
$tz = new DateTimezone('Europe/Madrid');
$d = new DateTime('2011-03-28 02:30:00',$tz);
// OK
// One day early
// Result: 2011-03-27 03:30:00
echo $d-modify('-1 day')-format('Y-m-d H:i:s').'br/';
// BAD
// One hour early (or other TIME operation)
// Expected: 2011-03-27 01:30:00, Actual: 2011-03-27 03:30:00
echo $d-modify('-1 hour')-format('Y-m-d H:i:s').'br/';
// BAD
// SetDate and setTime
// Expected: 2011-03-27 03:30:00, Actual: 2011-03-27 02:30:00
echo $d-setDate(2011,3,27)-setTime(2,30,0)-format('Y-m-d H:i:s').'br/';
// OK
// Set timezone again after setDate and setTime fix the above problem
// Result: 2011-03-27 03:30:00
echo $d-setDate(2011,3,27)-setTime(2,30,0)-setTimezone($tz)-format('Y-m-d
H:i:s').'br/';
// OK
// One hour early but changing timestamp
// Result: 2011-03-27 01:30:00
echo $d-setTimestamp(($d-getTimestamp()-3600))-format('Y-m-d H:i:s').'br/';
// OK
// One hour after
// Result: 2011-03-27 03:30:00
echo $d-modify('2011-03-27 01:30:00')-modify('+1 hours')-format('Y-m-d
H:i:s').'br/';
// BAD
// Two hours after
// Expected: 2011-03-27 04:30:00, Actual: 2011-03-27 03:30:00
echo $d-modify('2011-03-27 01:30:00')-modify('+2 hours')-format('Y-m-d
H:i:s').'br/';
Expected result:
2011-03-27 03:30:00
2011-03-27 01:30:00
2011-03-27 03:30:00
2011-03-27 03:30:00
2011-03-27 01:30:00
2011-03-27 03:30:00
2011-03-27 04:30:00
Actual result:
--
2011-03-27 03:30:00
2011-03-27 03:30:00
2011-03-27 02:30:00
2011-03-27 03:30:00
2011-03-27 01:30:00
2011-03-27 03:30:00
2011-03-27 03:30:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=54799edit=1
Bug #54495 [Opn-Bgs]: Empty DateInterval has wrong days
Edit report at https://bugs.php.net/bug.php?id=54495edit=1
ID: 54495
Updated by: dani...@php.net
Reported by:bandy dot chris at gmail dot com
Summary:Empty DateInterval has wrong days
-Status: Open
+Status: Bogus
Type: Bug
Package:Date/time related
Operating System: Linux, x86_64
PHP Version:5.3.6
-Assigned To:
+Assigned To:danielc
Block user comment: N
Private report: N
New Comment:
days is a calculated field expressing how many days are between two compared
dates. It is never set when instantiating a new date interval. The d
property contains the number of days specified in the interval format.
Everything is operating as expected.
Previous Comments:
[2011-04-08 17:34:08] bandy dot chris at gmail dot com
Description:
A DateInterval created with a period that spans zero days reports $days = FALSE
rather than 0.
A DateInterval created by subtracting two DateTimes reports $days = 0 correctly.
Test script:
---
?php
// Period of zero days, zero seconds
// $days = FALSE
print_r(new DateInterval('P0Y'));
// Difference of identical timestamps
// $days = 0
print_r(date_diff(new DateTime('@1289997296'), new DateTime('@1289997296')));
Expected result:
DateInterval Object
(
[y] = 0
[m] = 0
[d] = 0
[h] = 0
[i] = 0
[s] = 0
[invert] = 0
[days] = 0
)
DateInterval Object
(
[y] = 0
[m] = 0
[d] = 0
[h] = 0
[i] = 0
[s] = 0
[invert] = 0
[days] = 0
)
Actual result:
--
DateInterval Object
(
[y] = 0
[m] = 0
[d] = 0
[h] = 0
[i] = 0
[s] = 0
[invert] = 0
[days] =
)
DateInterval Object
(
[y] = 0
[m] = 0
[d] = 0
[h] = 0
[i] = 0
[s] = 0
[invert] = 0
[days] = 0
)
--
Edit this bug report at https://bugs.php.net/bug.php?id=54495edit=1
Bug #53880 [Opn-Dup]: date_diff returns wrong results
Edit report at https://bugs.php.net/bug.php?id=53880edit=1 ID: 53880 Updated by: dani...@php.net Reported by:an0nym at narod dot ru Summary:date_diff returns wrong results -Status: Open +Status: Duplicate Type: Bug Package:Date/time related Operating System: Windows Server 2008 R2 x64 PHP Version:5.3.5 -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: This is a duplicate of http://bugs.php.net/bug.php?id=51184 Previous Comments: [2011-05-08 11:48:46] eikcam at internode dot on dot net I'm running Windows 7 64-bit and I am having this issue. DateInterval Object ( [y] = 0 [m] = 1 [d] = 30 [h] = 0 [i] = 0 [s] = 0 [invert] = 0 [days] = 6015 ) [2011-01-30 15:12:45] an0nym at narod dot ru Pay attention to the end of description. Windows 7 x64 doesn't have this bug, while Windows Server 2008 R2 do and they have much more simiral codebase than Windows XP and Windows Server 2008 R2. [2011-01-30 15:09:38] an0nym at narod dot ru I didn't compile myself. I downloaded VC6 x86 thread safe from windows binaries php download page. [2011-01-30 10:53:57] s...@php.net Works fine for me on XP 32-bit with VC9. Which compiler/build did you use? [2011-01-29 23:42:08] an0nym at narod dot ru Description: See test script. On FreeBSD 8.1-RELEASE-p1 amd64, Linux 2.6.18-194.32.1.el5 x86_64, Windows 7 x64 everything works fine. Test script: --- date_default_timezone_set(UTC); $d = new DateTime(2011-01-01); echo $d-diff(new DateTime(2010-01-01))-format(%a); Expected result: 365 Actual result: -- 6015 -- Edit this bug report at https://bugs.php.net/bug.php?id=53880edit=1
Bug #53370 [Opn-Dup]: Some relative date/time format returns incorrect result at the end of DST
Edit report at https://bugs.php.net/bug.php?id=53370edit=1
ID: 53370
Updated by: dani...@php.net
Reported by:for-bugs at hnw dot jp
Summary:Some relative date/time format returns incorrect
result at the end of DST
-Status: Open
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Linux and MacOSX
PHP Version:5.3.3
-Assigned To:
+Assigned To:danielc
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=51051
Previous Comments:
[2010-11-21 13:38:57] for-bugs at hnw dot jp
Description:
Relative date/time format '+[number]sec', '+[number]min', '+[number]hour'
returns incorrect time when the current time is in daylight saving time and the
result of calculation is non-daylight saving time.
For example, daylight saving time of this year in the USA was started at
2010-03-14 02:00:00, and finished at 2010-11-07 02:00:00. However, '2010-11-07
01:59:59 +1sec' advance to 3601 sec after.
Test script:
---
?php
date_default_timezone_set('America/Los_Angeles');
echo date(c, strtotime(2010-03-14 01:59:59)) . PHP_EOL;
echo date(c, strtotime(2010-03-14 01:59:59 +1sec)) . PHP_EOL;
echo date(c, strtotime(2010-11-07 01:59:59)) . PHP_EOL;
echo date(c, strtotime(2010-11-07 01:59:59 +1sec)) . PHP_EOL;
Expected result:
2010-03-14T01:59:59-08:00
2010-03-14T03:00:00-07:00
2010-11-07T01:59:59-07:00
2010-11-07T01:00:00-08:00
Actual result:
--
2010-03-14T01:59:59-08:00
2010-03-14T03:00:00-07:00
2010-11-07T01:59:59-07:00
2010-11-07T02:00:00-08:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=53370edit=1
Bug #53225 [Opn-Dup]: add-Method of DateTime-class
Edit report at https://bugs.php.net/bug.php?id=53225edit=1
ID: 53225
Updated by: dani...@php.net
Reported by:i dot sonderegger at meteonews dot ch
Summary:add-Method of DateTime-class
-Status: Open
+Status: Duplicate
Type: Bug
Package:Date/time related
Operating System: Mac OS X 10.5.8
PHP Version:5.3SVN-2010-11-02 (snap)
-Assigned To:
+Assigned To:danielc
Block user comment: N
Private report: N
New Comment:
This is a duplicate of https://bugs.php.net/bug.php?id=55253
Previous Comments:
[2010-11-02 08:41:25] i dot sonderegger at meteonews dot ch
Description:
PHP-Version:
PHP 5.3.99-dev (cli) (built: Nov 1 2010 17:42:09)
Copyright (c) 1997-2010 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2010 Zend Technologies
If a timezone is passed in the time-string to the constructor of the
DateTime-Object, a subsequent add() call could result in incorrect results (if
the add() call oversteps a daylight-saving time).
Test script:
---
// Gives expected result
$date = new DateTime('2010-10-31 01:00 CEST', new
DateTimeZone(Europe/Zurich));
$date-setTimezone(new DateTimeZone('Europe/Zurich'));
$date-add(new DateInterval('PT3H'));
echo $date-format('Y-m-d H:i:sP').\n;
// Doesn't give expected result
$date = new DateTime('2010-10-31 01:00 CEST', new
DateTimeZone(Europe/Zurich));
$date-add(new DateInterval('PT3H'));
$date-setTimezone(new DateTimeZone('Europe/Zurich'));
echo $date-format('Y-m-d H:i:sP').\n;
Expected result:
2010-10-31 04:00:00+01:00
2010-10-31 04:00:00+01:00
Actual result:
--
2010-10-31 04:00:00+01:00
2010-10-31 03:00:00+01:00
--
Edit this bug report at https://bugs.php.net/bug.php?id=53225edit=1
Req #54117 [Opn-Wfx]: Parameter 'z' false
Edit report at https://bugs.php.net/bug.php?id=54117edit=1 ID: 54117 Updated by: dani...@php.net Reported by:a dot borngesser at berlin dot de Summary:Parameter 'z' false -Status: Open +Status: Wont fix Type: Feature/Change Request Package:Date/time related Operating System: Irrelevant PHP Version:Irrelevant -Assigned To: +Assigned To:danielc Block user comment: N Private report: N New Comment: It is impossible to change the behavior of an existing format parameter due to the current behavior being relied on by existing users. If you like, you may open a feature request for a new format parameter, but this does not seem like an important feature since using z + 1 is a simple workaround. Previous Comments: [2011-03-16 09:42:49] a dot borngesser at berlin dot de Is someone working on this issue or shut I open a new thread (and of course in english this time)? [2011-02-28 11:29:03] a dot borngesser at berlin dot de Sorry, my text now in english. The parameter 'z' is false from its basic set-up. The first day of the year is '1' not '0'. I know, that the count starts with 0, but it would be better to change the code of the parameter, than to leave it to the programmers. (I had some cases where it was used simply as is. The results where simply false, and when using it in a very basic way by just displaying it, you don't think of a mistake.) If a parameter is for returning the incremented day of the year, it should do exactly this, and not the incremented day of the year -1. [2011-02-28 11:11:34] paj...@php.net Please report your bug in English. [2011-02-28 11:10:18] a dot borngesser at berlin dot de Description: --- From manual page: http://www.php.net/function.date#Parameter-Liste --- Parameter ist im Grundaufbau falsch. z Der Tag des Jahres (von 0 beginnend)0 bis365 === = Der erste Tag des Jahres ist nicht '0' sondern '1'! Natürlich ist es normal, das von 0 die Zählung beginnt, aber man sollte evtl. bei einem Parameter dies intern gleich um +1 hochzählen und nicht den Programmierern überlassen. Ich habe jetzt schon mehrere Fälle gehabt, wo der Parameter direkt genutzt wurde, was dann zu falschen Ergebnissen geführt hat. Wenn ein Parameter den hochgezählten Tag des Jahres angeben soll, sollte dies auch so sein und nicht 'der hochgezählte Tag des Jahres -1'. Test script: --- echo Der 1.1. 2010 hatte die LOS#: .date (z,mktime(0,0,0,1,1,2010)); Expected result: Der 1.1. 2010 hatte die LOS#: 1 Actual result: -- Der 1.1. 2010 hatte die LOS#: 0 -- Edit this bug report at https://bugs.php.net/bug.php?id=54117edit=1
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at https://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: danielc at analysisandsolutions dot com
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
See also: https://bugs.php.net/bug.php?id=31455
Previous Comments:
[2010-10-15 23:26:30] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it loads.
JavaScript sets cookies that I use in php. When using Internet Explorer,
$_ENV[HTTP_COOKIE] contains multiple entries for each cookie. This does not
happen with Firefox.
As near as I can figure so far, when executing code at a domain named x.y.z,
Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.
Php then puts both sets of cookies into $_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you resolve
your problem.
... Warren Gaebel, B.A., B.C.S.
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request.
But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php
script needs to access the session vars. This forces to close the session file
via session_write_close() in the first script. After this function call, the
second PHP script can do a session_start() and access the current values of the
session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the
session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm afraid
that in combination with HTML frames this behaviour of PHP can force deadlocks
in different browsers like Internet Explorer or Mozilla. Unfortunately I can't
present a 100% working example for reproducable deadlocks.
I would suggest to create a flag containing true or false, if the Cookie for
the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course
another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this bug :)
[2005-01-09 15:49:13] rene dot bangemann at web dot de
Description:
I'm using a combination of session_start() and session_write_close() to access
and update session variables.
In some scripts this function calls will be executed up to 50 times.
For each call of session_start() a HTTP-Header with the PHP session id will be
created in the same HTTP response.
I would expect, that in the HTTP response will be only one HTTP-Header with the
session id.
Reproduce code:
---
?php
session_start();
session_write_close();
session_start();
session_write_close();
session_start();
session_write_close();
?
Expected result:
HTTP-Header Set-Cookie with PHP session id created only once in HTTP response
Actual result:
--
The code above will create a HTTP response with three identical HTTP Set-Cookie
headers
--
Edit this bug report at https
Bug #31455 [Com]: multiple session_start() creates multiple session cookies in HTTP-Response
Edit report at https://bugs.php.net/bug.php?id=31455edit=1
ID: 31455
Comment by: danielc at analysisandsolutions dot com
Reported by:rene dot bangemann at web dot de
Summary:multiple session_start() creates multiple session
cookies in HTTP-Response
Status: Wont fix
Type: Bug
Package:Session related
Operating System: Win32
PHP Version:4CVS, 5CVS
Assigned To:tony2001
Block user comment: N
Private report: N
New Comment:
I mean to say, see also: https://bugs.php.net/bug.php?id=38104
Previous Comments:
[2011-11-20 05:21:02] danielc at analysisandsolutions dot com
See also: https://bugs.php.net/bug.php?id=31455
[2010-10-15 23:26:30] WarrenGaebel at FriendlyNeighbourGuide dot ca
I am experiencing a similar, but not identical problem.
I reload my page multiple times, using session_start() every time it loads.
JavaScript sets cookies that I use in php. When using Internet Explorer,
$_ENV[HTTP_COOKIE] contains multiple entries for each cookie. This does not
happen with Firefox.
As near as I can figure so far, when executing code at a domain named x.y.z,
Internet Explorer sends the cookies for x.y.z followed by the cookies for y.z.
Php then puts both sets of cookies into $_ENV[HTTP_COOKIE].
Perhaps this may be considered a PHP bug, perhaps not. IMHO, this is an
Internet Explorer bug. I post it here in the hope that it may help you resolve
your problem.
... Warren Gaebel, B.A., B.C.S.
[2005-02-14 00:18:30] rene dot bangemann at web dot de
Ok, you are right that someone could start several sessions within one request.
But thats not my use case:
I'm using a PHP script to perform some actions which can take up to some hours.
E.G. for displaying progress information about the running process a second php
script needs to access the session vars. This forces to close the session file
via session_write_close() in the first script. After this function call, the
second PHP script can do a session_start() and access the current values of the
session vars.
After finishing the second request the session file will be closed again.
If the first script has to store new values of session related vars in the
session file, it uses a combination of session_start() and
session_write_close() to update the content within the session file.
Unfortunatly in my case this can happen very often (because of the long
execution time).
Under normal circumstances I could live with this feature :-). But I'm afraid
that in combination with HTML frames this behaviour of PHP can force deadlocks
in different browsers like Internet Explorer or Mozilla. Unfortunately I can't
present a 100% working example for reproducable deadlocks.
I would suggest to create a flag containing true or false, if the Cookie for
the current session id already was sent or not.
If the cookie wasn't already sent, or the used session id changes, of course
another Cookie has to be sent.
[2005-02-13 18:03:51] tony2...@php.net
Okay, no more dirty hacks =)
Marking it as won't fix and considering as a feature.
[2005-02-13 09:44:30] sni...@php.net
Then how would you handle this (very unlikely :) code:
?php
session_name('foo1');
session_id('foobar1');
session_start();
session_write_close();
session_name('foo2');
session_id('foobar2');
session_start();
session_write_close();
session_name('foo3');
session_id('foobar3');
session_start();
session_write_close();
?
Yes, someone MIGHT rely on that kind of code too.
And as it IS possible to start as many _different_ sessions in single
request, why should we not allow it?
(this is actually for Tony, FYI when he figures out how to fix this bug :)
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
https://bugs.php.net/bug.php?id=31455
--
Edit this bug report at https://bugs.php.net/bug.php?id=31455edit=1
Bug #38104 [Com]: session_start()/session_write_close() creates multiple session cookies headers
Edit report at https://bugs.php.net/bug.php?id=38104edit=1
ID: 38104
Comment by: danielc at analysisandsolutions dot com
Reported by:m dot v dot veluw dot smscity at gmail dot com
Summary:session_start()/session_write_close() creates
multiple session cookies headers
Status: Bogus
Type: Bug
Package:Session related
Operating System: any
PHP Version:5.1.4
Block user comment: N
Private report: N
New Comment:
See also https://bugs.php.net/bug.php?id=31455
Previous Comments:
[2011-11-09 18:34:52] rfunk at funknet dot net
I just ran into this bug in PHP 5.3.5 when working with a script that does lots
of
session_start()/session_write_close() in a long-running task, so that separate
requests can still access the
session during that long task. (Specifically those separate requests are
checking the progress of the long
task.)
The resulting absurdly redundant Set-Cookie header caused Firefox 7 to lock up
for a few seconds, and caused IE8
to give its infamously useless Internet Explorer cannot display the webpage
page. So this bug is not Bogus s
it claims.
I do have a workaround, however. I'm already doing an ob_start() at the top of
the script, and now before the
ending ob_end_flush() I replace the Set-Cookie header with a new one:
if (SID) header('Set-Cookie: '.SID.'; path=/', true);
After adding this, I no longer have the above problems in Firefox and IE.
[2011-02-04 17:00:58] vdklah at hotmail dot com
I can not tell how much I disagree on this. Calling session_start() followed by
session_write_close() is a very valid way to avoid blocking multiple processes.
(See also here http://konrness.com/php5/how-to-prevent-blocking-php-requests/.)
This problem is huge since we are facing fatal crashing clients due to zillions
of duplicate PHPSESSID entries in one cookie. Our server is big and complicated
and so we are not willing to change anything in this area while all is already
taken in production. Totally stuck on this and I'm not happy. This is a very
obvious PHP bug that can be proven in 4 lines of code without any client
intervention.
[2006-07-14 20:46:11] il...@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Session is created every time you call session_start(). If you
want to avoid multiple cookie, write better code. Multiple
session_start() especially for the same names in the same
script seems like a really bad idea.
[2006-07-14 10:23:58] m dot v dot veluw dot smscity at gmail dot com
Description:
When using session_start() and session_write_close() with the same session
id/name will add multiple session cookies with the exact same contents
everytime session_start is used.
This is useless overhead if it is the same.
Reproduce code:
---
session_name('uniqueName1');
session_start();
$_SESSION['Foo1'] = 'Bar1';
session_write_close();
session_name('uniqueName2');
session_start();
$_SESSION['Foo2'] = 'Bar2';
session_write_close();
session_name('uniqueName1');
session_start();
$sessionValue = $_SESSION['Foo1'];
print $sessionValue;
session_write_close();
session_name('uniqueName2');
session_start();
$sessionValue = $_SESSION['Foo2'];
print $sessionValue;
session_write_close();
Expected result:
just 1 session cookie header for uniqueName1.
just 1 session cookie header for uniqueName2.
Actual result:
--
2 session cookie headers for uniqueName1, where both are exactly the same
2 session cookie headers for uniqueName2, where both are exactly the same
--
Edit this bug report at https://bugs.php.net/bug.php?id=38104edit=1
[PHP-BUG] Bug #60333 [NEW]: fetch_field() length multiplied by 3 in mysqlnd
From:
Operating system: linux
PHP version: 5.4SVN-2011-11-19 (SVN)
Package: MySQLi related
Bug Type: Bug
Bug description:fetch_field() length multiplied by 3 in mysqlnd
Description:
Running PHP 5.4 compiled from svn earlier today. The length values from
fetch_field() are multiplied by 3 when building mysqli against mysqlnd.
The values are correct when building against libmysql.
Test script:
---
$db = new mysqli(null, $_ENV['MYSQL_TEST_USER'],
$_ENV['MYSQL_TEST_PASSWD'], $_ENV['MYSQL_TEST_DB'],
null, $_ENV['MYSQL_TEST_SOCKET']);
$result = $db-query(CREATE TEMPORARY TABLE phptest_fk (
txt TEXT NULL,
chr2 CHAR(2) default 'df' NOT NULL,
chr10 CHAR(10) default 'df' NOT NULL));
if (!$result) {
echo OOPS: $db-error\n;
exit(1);
}
$result = $db-query(INSERT INTO phptest_fk VALUES ('One', 'c1'));
$result = $db-query(SELECT * FROM phptest_fk);
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
$info = $result-fetch_field();
echo $info-name $info-length\n;
Expected result:
txt 65535
chr2 2
chr10 10
Actual result:
--
txt 196605
chr2 6
chr10 30
--
Edit bug report at https://bugs.php.net/bug.php?id=60333edit=1
--
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=60333r=trysnapshot54
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=60333r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=60333r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=60333r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=60333r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=60333r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=60333r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=60333r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=60333r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=60333r=support
Expected behavior:
https://bugs.php.net/fix.php?id=60333r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=60333r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=60333r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=60333r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=60333r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=60333r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=60333r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=60333r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=60333r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=60333r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=60333r=mysqlcfg
[PHP-BUG] Bug #55253 [NEW]: DateTime::add() and sub() result -1 hour on objects with time zone type 2
From:
Operating system: Ubuntu 10.04
PHP version: 5.4SVN-2011-07-20 (SVN)
Package: Date/time related
Bug Type: Bug
Bug description:DateTime::add() and sub() result -1 hour on objects with time
zone type 2
Description:
Calling add() or sub() on DateTime objects using a type 2 time zone results
in the answer being behind by one hour.
Test script has been added to SVN.
Test script:
---
date_default_timezone_set('America/New_York');
$interval = new DateInterval('PT2H1M');
$date3 = new DateTime('2010-10-04 02:18:48');
$date2 = new DateTime('2010-10-04 02:18:48 EDT');
echo 'Zone Type 3: ' . $date3-format('Y-m-d H:i:s T') . \n;
echo 'Zone Type 2: ' . $date2-format('Y-m-d H:i:s T') . \n;
echo $interval-format('Add %h hours %i minutes') . \n;
$date3-add($interval);
$date2-add($interval);
echo 'Zone Type 3: ' . $date3-format('Y-m-d H:i:s T') . \n;
echo 'Zone Type 2: ' . $date2-format('Y-m-d H:i:s T') . \n;
// Try subtracting from expected result.
$date3 = new DateTime('2010-10-04 04:19:48');
$date2 = new DateTime('2010-10-04 04:19:48 EDT');
echo $interval-format('Subtract %h hours %i minutes from expected') .
\n;
$date3-sub($interval);
$date2-sub($interval);
echo 'Zone Type 3: ' . $date3-format('Y-m-d H:i:s T') . \n;
echo 'Zone Type 2: ' . $date2-format('Y-m-d H:i:s T') . \n;
Expected result:
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 02:18:48 EDT
Add 2 hours 1 minutes
Zone Type 3: 2010-10-04 04:19:48 EDT
Zone Type 2: 2010-10-04 04:19:48 EDT
Subtract 2 hours 1 minutes from expected
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 02:18:48 EDT
Actual result:
--
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 02:18:48 EDT
Add 2 hours 1 minutes
Zone Type 3: 2010-10-04 04:19:48 EDT
Zone Type 2: 2010-10-04 03:19:48 EDT
Subtract 2 hours 1 minutes from expected
Zone Type 3: 2010-10-04 02:18:48 EDT
Zone Type 2: 2010-10-04 01:18:48 EDT
--
Edit bug report at https://bugs.php.net/bug.php?id=55253edit=1
--
Try a snapshot (PHP 5.2):
https://bugs.php.net/fix.php?id=55253r=trysnapshot52
Try a snapshot (PHP 5.3):
https://bugs.php.net/fix.php?id=55253r=trysnapshot53
Try a snapshot (trunk):
https://bugs.php.net/fix.php?id=55253r=trysnapshottrunk
Fixed in SVN:
https://bugs.php.net/fix.php?id=55253r=fixed
Fixed in SVN and need be documented:
https://bugs.php.net/fix.php?id=55253r=needdocs
Fixed in release:
https://bugs.php.net/fix.php?id=55253r=alreadyfixed
Need backtrace:
https://bugs.php.net/fix.php?id=55253r=needtrace
Need Reproduce Script:
https://bugs.php.net/fix.php?id=55253r=needscript
Try newer version:
https://bugs.php.net/fix.php?id=55253r=oldversion
Not developer issue:
https://bugs.php.net/fix.php?id=55253r=support
Expected behavior:
https://bugs.php.net/fix.php?id=55253r=notwrong
Not enough info:
https://bugs.php.net/fix.php?id=55253r=notenoughinfo
Submitted twice:
https://bugs.php.net/fix.php?id=55253r=submittedtwice
register_globals:
https://bugs.php.net/fix.php?id=55253r=globals
PHP 4 support discontinued:
https://bugs.php.net/fix.php?id=55253r=php4
Daylight Savings:https://bugs.php.net/fix.php?id=55253r=dst
IIS Stability:
https://bugs.php.net/fix.php?id=55253r=isapi
Install GNU Sed:
https://bugs.php.net/fix.php?id=55253r=gnused
Floating point limitations:
https://bugs.php.net/fix.php?id=55253r=float
No Zend Extensions:
https://bugs.php.net/fix.php?id=55253r=nozend
MySQL Configuration Error:
https://bugs.php.net/fix.php?id=55253r=mysqlcfg
Try a snapshot (PHP 5.4):
https://bugs.php.net/fix.php?id=55253r=trysnapshot54
Bug #54719 [Opn-Csd]: Serialization tests fail to set serialize_precision
Edit report at http://bugs.php.net/bug.php?id=54719edit=1 ID: 54719 Updated by: dani...@php.net Reported by:mats dot lindh at gmail dot com Summary:Serialization tests fail to set serialize_precision -Status: Open +Status: Closed Type: Bug Package:Unknown/Other Function Operating System: Linux PHP Version:trunk-SVN-2011-05-12 (SVN) -Assigned To: +Assigned To:tyrael Block user comment: N Private report: N New Comment: Patch applied by tyrael on 2011-05-16. Previous Comments: [2011-05-12 13:23:06] mats dot lindh at gmail dot com Description: The tests for the serialization module fails to set the INI value for serialize_precision before running the tests, resulting in failed tests if the default precision is used (if the tests are run before make install and no php.ini file is available). Test script: --- make test TESTS=ext/standard/tests/serialize Expected result: Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:0 ( 0.0%) ( 0.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 50 ( 98.0%) (100.0%) Actual result: -- Number of tests : 5150 Tests skipped :1 ( 2.0%) Tests warned:0 ( 0.0%) ( 0.0%) Tests failed:5 ( 9.8%) ( 10.0%) Expected fail :0 ( 0.0%) ( 0.0%) Tests passed: 45 ( 88.2%) ( 90.0%) -- Edit this bug report at http://bugs.php.net/bug.php?id=54719edit=1
Bug #53634 [Asn]: unknown property when writing to DateInterval::$days
Edit report at http://bugs.php.net/bug.php?id=53634edit=1
ID: 53634
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:unknown property when writing to DateInterval::$days
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: linux
PHP Version:5.3SVN-2010-12-30 (SVN)
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
Why should days be read only? All other properties are writable. Days
needs to be writable too. Writing to various properties is necessary
when overloading the date classes (to compensate for bugs, etc).
Previous Comments:
[2011-01-30 11:57:20] s...@php.net
Hmm... Actually you're not supposed to be writing to days property, it
should be read only. I'll fix it.
[2011-01-24 18:39:45] danielc at analysisandsolutions dot com
While the recent commit removes the fatal error, the property can not be
written to. Here is the output of the initial test script (above) as of
svn revision 307713:
S: 8
DAYS: -9
DAYS: -9
[2011-01-24 03:49:50] s...@php.net
This bug has been fixed in SVN.
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.
[2010-12-30 22:15:05] danielc at analysisandsolutions dot com
Description:
One can not set the DateInterval::$days property. It is readable. All
other properties of DateInterval shown in var_dump() are writeable.
While similar to Bug #52738, this involves an actual property of the
DateInterval class.
Test script:
---
$i = new DateInterval('P1D');
$i-s = 8;
echo S: $i-s\n;
echo DAYS: $i-days\n;
$i-days = 6;
echo DAYS: $i-days\n;
Expected result:
S: 8
DAYS: -9
DAYS: 6
Actual result:
--
S: 8
DAYS: -9
PHP Fatal error: main(): Unknown property (days) in
/home/danielc/test.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=53634edit=1
Bug #53634 [Csd-Asn]: unknown property when writing to DateInterval::$days
Edit report at http://bugs.php.net/bug.php?id=53634edit=1
ID: 53634
User updated by:danielc at analysisandsolutions dot com
Reported by:danielc at analysisandsolutions dot com
Summary:unknown property when writing to DateInterval::$days
-Status: Closed
+Status: Assigned
Type: Bug
Package:Date/time related
Operating System: linux
PHP Version:5.3SVN-2010-12-30 (SVN)
Assigned To:stas
Block user comment: N
Private report: N
New Comment:
While the recent commit removes the fatal error, the property can not be
written to. Here is the output of the initial test script (above) as of
svn revision 307713:
S: 8
DAYS: -9
DAYS: -9
Previous Comments:
[2011-01-24 03:49:50] s...@php.net
This bug has been fixed in SVN.
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.
[2010-12-30 22:15:05] danielc at analysisandsolutions dot com
Description:
One can not set the DateInterval::$days property. It is readable. All
other properties of DateInterval shown in var_dump() are writeable.
While similar to Bug #52738, this involves an actual property of the
DateInterval class.
Test script:
---
$i = new DateInterval('P1D');
$i-s = 8;
echo S: $i-s\n;
echo DAYS: $i-days\n;
$i-days = 6;
echo DAYS: $i-days\n;
Expected result:
S: 8
DAYS: -9
DAYS: 6
Actual result:
--
S: 8
DAYS: -9
PHP Fatal error: main(): Unknown property (days) in
/home/danielc/test.php on line 7
--
Edit this bug report at http://bugs.php.net/bug.php?id=53634edit=1
[PHP-BUG] Bug #53634 [NEW]: unknown property when writing to DateInterval::$days
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-30 (SVN)
Package: Date/time related
Bug Type: Bug
Bug description:unknown property when writing to DateInterval::$days
Description:
One can not set the DateInterval::$days property. It is readable. All
other properties of DateInterval shown in var_dump() are writeable.
While similar to Bug #52738, this involves an actual property of the
DateInterval class.
Test script:
---
$i = new DateInterval('P1D');
$i-s = 8;
echo S: $i-s\n;
echo DAYS: $i-days\n;
$i-days = 6;
echo DAYS: $i-days\n;
Expected result:
S: 8
DAYS: -9
DAYS: 6
Actual result:
--
S: 8
DAYS: -9
PHP Fatal error: main(): Unknown property (days) in /home/danielc/test.php
on line 7
--
Edit bug report at http://bugs.php.net/bug.php?id=53634edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53634r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53634r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53634r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53634r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53634r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53634r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53634r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53634r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53634r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53634r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53634r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53634r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53634r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53634r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53634r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53634r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53634r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53634r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53634r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53634r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53634r=mysqlcfg
Bug #51051 [Com]: DateTime modify wrong result with DST change
Edit report at http://bugs.php.net/bug.php?id=51051edit=1
ID: 51051
Comment by: danielc at analysisandsolutions dot com
Reported by:mehdi dot rande at aliasource dot fr
Summary:DateTime modify wrong result with DST change
Status: Assigned
Type: Bug
Package:Date/time related
Operating System: Linux
PHP Version:5.3.1
Assigned To:derick
Block user comment: N
Private report: N
New Comment:
DateTime::diff() is similarly afflicted with daylight/standard change
over issues. Naturally, diff/add/sub all need to be in sync so
intervals returned by diff can be passed to add/sub and produce the
original datetime.
Previous Comments:
[2010-12-25 02:27:22] dani...@php.net
I just attached a test script that covers issues in the spring and fall.
[2010-12-25 02:26:16] dani...@php.net
The following patch has been added/updated:
Patch Name: bug51051test.php.txt
Revision: 1293240376
URL:
http://bugs.php.net/patch-display.php?bug=51051patch=bug51051test.php.txtrevision=1293240376
[2010-08-24 14:34:22] glennpratt+php at gmail dot com
Correction for the Expected result above.
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-06:00 America/Chicago
[2010-08-24 00:04:28] glennpratt at gmail dot com
Same issue here on PHP 5.3.2
?php
$date = new DateTime('2011-03-13T03:00:00',
timezone_open('America/Chicago'));
print($date-format('c e'));
$date-modify('-2 minutes');
print($date-format('c e'));
?
Actual Result
-
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T03:58:00-05:00 America/Chicago
Expected Result
---
2011-03-13T03:00:00-05:00 America/Chicago
2011-03-13T01:58:00-05:00 America/Chicago
Comparison: Ruby time library
-
irb(main):015:0 date = Time.parse('2011-03-13T03:00:00 in CST')
= Sun Mar 13 03:00:00 -0500 2011
irb(main):016:0 date - 120
= Sun Mar 13 01:58:00 -0600 2011
[2010-02-15 10:56:45] mehdi dot rande at aliasource dot fr
Sorry the expected result is in fact the actual result, and the actual
result is the expected result.
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/bug.php?id=51051
--
Edit this bug report at http://bugs.php.net/bug.php?id=51051edit=1
[PHP-BUG] Bug #53463 [NEW]: sqlite3 columnName() segfaults on bad column_number
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3 columnName() segfaults on bad column_number
Description:
PHP's SQLite3Result::columnName() method produces a segmentation fault when
column_number exceeds the column count.
Inside ext/sqlite3/sqlite3.c, PHP utlizes RETVAL_STRING for the data coming
back from SQLite's sqlite3_column_name() function. But inside
ext/sqlite3/libsqlite/sqlite3.c, their sqlite3_column_name() function calls
columnName(), which returns 0 on error conditions.
PHP's C code needs to be adjusted to account for mixed type results from
sqlite3_column_name(). When making this fix, it seems PHP should return
FALSE if sqlite3_column_name() produces 0.
Test script:
---
$db = new SQLite3(':memory:');
$db-exec('CREATE TABLE test (whatever INTEGER)');
$db-exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db-query('SELECT * FROM test');
while ($row = $result-fetchArray(SQLITE3_NUM)) {
var_dump($result-columnName(0)); // string(8) whatever
// Seems returning false will be most appropriate.
var_dump($result-columnName(3)); // Segmentation fault
}
$result-finalize();
$db-close();
echo Done\n;
Expected result:
string(8) whatever
bool(false)
Done
Actual result:
--
string(8) whatever
Segmentation fault
--
Edit bug report at http://bugs.php.net/bug.php?id=53463edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53463r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53463r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53463r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53463r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53463r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53463r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53463r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53463r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53463r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53463r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53463r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53463r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53463r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53463r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53463r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53463r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53463r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53463r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53463r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53463r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53463r=mysqlcfg
[PHP-BUG] Bug #53464 [NEW]: sqlite3 columnType() returns SQLITE3_NULL on bad column_number
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Bug
Bug description:sqlite3 columnType() returns SQLITE3_NULL on bad column_number
Description:
The SQLite3Result::columnType() method returns SQLITE3_NULL (5) when
column_number exceeds the column count. It seems more appropriate for it
to return FALSE.
Test script:
---
$db = new SQLite3(':memory:');
$db-exec('CREATE TABLE test (whatever INTEGER)');
$db-exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db-query('SELECT * FROM test');
while ($row = $result-fetchArray(SQLITE3_NUM)) {
var_dump($result-columnType(0)); // int(1) [SQLITE3_INTEGER]
// Seems returning false is more appropriate.
var_dump($result-columnType(3)); // int(5) [SQLITE3_NULL]
}
$result-finalize();
$db-close();
echo Done\n;
Expected result:
int(1)
bool(false)
Done
Actual result:
--
int(1)
int(5)
Done
--
Edit bug report at http://bugs.php.net/bug.php?id=53464edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53464r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53464r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53464r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53464r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53464r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53464r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53464r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53464r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53464r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53464r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53464r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53464r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53464r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53464r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53464r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53464r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53464r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53464r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53464r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53464r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53464r=mysqlcfg
[PHP-BUG] Req #53466 [NEW]: sqlite3 columnType() returns SQLITE3_NULL when not in fetch loop
From:
Operating system: linux
PHP version: 5.3SVN-2010-12-03 (SVN)
Package: SQLite related
Bug Type: Feature/Change Request
Bug description:sqlite3 columnType() returns SQLITE3_NULL when not in fetch loop
Description:
The SQLite3Result::columnType() method returns SQLITE3_NULL (5) if not
looping over results. This is done because the data type is unknown. But
this leads to confusion, because SQLITE3_NULL is a legitimate answer in
some cases when inside the loop. It would be clearer if PHP returned NULL
or FALSE instead.
Test script:
---
$db = new SQLite3(':memory:');
$db-exec('CREATE TABLE test (whatever INTEGER)');
$db-exec('INSERT INTO test (whatever) VALUES (1)');
$result = $db-query('SELECT * FROM test');
while ($row = $result-fetchArray(SQLITE3_NUM)) {
var_dump($result-columnType(0)); // int(1) [SQLITE3_INTEGER]
}
// Seems returning null or false is more appropriate.
var_dump($result-columnType(0)); // int(5) [SQLITE3_NULL]
$result-finalize();
$db-close();
echo Done\n;
Expected result:
int(1)
bool(false)
Done
Actual result:
--
int(1)
int(5)
Done
--
Edit bug report at http://bugs.php.net/bug.php?id=53466edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=53466r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=53466r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=53466r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=53466r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=53466r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=53466r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=53466r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=53466r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=53466r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=53466r=support
Expected behavior:
http://bugs.php.net/fix.php?id=53466r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=53466r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=53466r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=53466r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=53466r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=53466r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=53466r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=53466r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=53466r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=53466r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=53466r=mysqlcfg
Bug #43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817edit=1 ID: 43817 Updated by: dani...@php.net Reported by: losd at mail dot dk Summary: opendir() fails on Windows directories with parent directory unaccessible Status: Assigned Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0beta1 Assigned To: pajoye New Comment: That makes sense. I'm on XP. Thanks. If you need quicker feedback, shoot me an email or assign the bug to me. Previous Comments: [2010-04-05 01:59:43] paj...@php.net Nothing has changed in 5.2/3.x about that. The problem may come from the tsrm's real path which tries to access all parent directories to cache them. I have to investigate why it fails on XP (and on on 2003 for your right?) but not on more recent versions. [2010-04-05 01:45:01] dani...@php.net I just installed 5.3.2. The regression has gotten worse. Now the Subdir/.. workaround fails too: Warning: opendir(C:/Dir/Subdir/..,C:/Dir/Subdir/..) [function.opendir]: Access is denied. (code: 5)... [2010-03-29 00:27:55] paj...@php.net Please try with 5.3.2 [2010-03-29 00:12:25] dani...@php.net Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. [2009-06-28 01:00:01] 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. 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/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817edit=1
Bug #43817 [Fbk-Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817edit=1 ID: 43817 Updated by: dani...@php.net Reported by: losd at mail dot dk Summary: opendir() fails on Windows directories with parent directory unaccessible -Status: Feedback +Status: Assigned Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0beta1 Assigned To: pajoye New Comment: I just installed 5.3.2. The regression has gotten worse. Now the Subdir/.. workaround fails too: Warning: opendir(C:/Dir/Subdir/..,C:/Dir/Subdir/..) [function.opendir]: Access is denied. (code: 5)... Previous Comments: [2010-03-29 00:27:55] paj...@php.net Please try with 5.3.2 [2010-03-29 00:12:25] dani...@php.net Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. [2009-06-28 01:00:01] 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. [2009-06-20 11:39:09] paj...@php.net Can't reproduce it with RC4, please try again with 5.3.0RC4. [2009-03-02 20:09:55] paj...@php.net Also see #42832 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/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817edit=1
Bug #43817 [NoF-Asn]: opendir() fails on Windows directories with parent directory unaccessible
Edit report at http://bugs.php.net/bug.php?id=43817edit=1 ID: 43817 Updated by: dani...@php.net Reported by: losd at mail dot dk Summary: opendir() fails on Windows directories with parent directory unaccessible -Status: No Feedback +Status: Assigned Type: Bug Package: Directory function related Operating System: win32 only - Windows Server 2003 PHP Version: 5.3.0beta1 Assigned To: pajoye New Comment: Still exists for me under the official release of PHP 5.3.0 on an XP SP3 machine. Previous Comments: [2009-06-28 01:00:01] 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. [2009-06-20 11:39:09] paj...@php.net Can't reproduce it with RC4, please try again with 5.3.0RC4. [2009-03-02 20:09:55] paj...@php.net Also see #42832 [2009-03-02 20:01:18] paj...@php.net I can now reproduce it on XP, but not on 2008/Vista/win7. I have to investigate deeper :P [2009-02-03 17:36:35] dani...@php.net Changing version from 5.2.5 to 5.3.0beta1 to facilitate this getting fixed before the next release. 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/bug.php?id=43817 -- Edit this bug report at http://bugs.php.net/bug.php?id=43817edit=1
Bug #47627 [Bgs-Dup]: No input file specified causing crash
Edit report at http://bugs.php.net/bug.php?id=47627edit=1 ID: 47627 Updated by: dani...@php.net Reported by: danielc at analysisandsolutions dot com Summary: No input file specified causing crash -Status: Bogus +Status: Duplicate Type: Bug Package: CGI related Operating System: win32 only - WinXP Pro SP3 PHP Version: 5.3CVS-2009-03-11 (snap) -Assigned To: garretts +Assigned To: Previous Comments: [2009-10-19 17:04:45] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=289757 Log: - Merge: improve fix for #49767 and #47627 - make PHP report 'no script' on 404 again [2009-10-16 23:34:32] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revisionrevision=289706 Log: improve fix for #49767 and #47627 - make PHP report no script on 404 again [2009-10-15 21:32:24] s...@php.net Automatic comment from SVN on behalf of pajoye Revision: http://svn.php.net/viewvc/?view=revisionrevision=289687 Log: - Merge: fix crash for bug #47627 [2009-10-13 19:59:00] s...@php.net Automatic comment from SVN on behalf of stas Revision: http://svn.php.net/viewvc/?view=revisionrevision=289621 Log: fix crash for bug #47627 [2009-10-13 19:50:36] paj...@php.net That's correct and has been analyzed in #49767, will be fixed there. Please note that the condition is not only that the file does not exist but also to use when the per directory registry setting is used. Set this one as bogus as the one will be used to track this bug. Thanks for having reproduced it Stas :) 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/bug.php?id=47627 -- Edit this bug report at http://bugs.php.net/bug.php?id=47627edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Here is an updated patch against PHP_5_3. It removes all of the
next_month code in
do_range_limit_days_relative().
http://www.analysisandsolutions.com/php/bug49081v2.53.diff
As with the earlier patch, PHP built fine with it and all of the
ext/date tests that passed under
the unpached PHP_5_3 build continued to pass under the patched
version.
Grepping the entire PHP_5_3 code base indicates the only place
do_range_limit_days_relative() gets
called is in timelib_do_rel_normalize(), and the only place that gets
called is timelib_diff().
It is unclear what purpose the next_month functionality served.
Perhaps it was there in case the
base_y and base_m parameters were later than the y/m/d
parameters? But that doesn't apply
becausetimelib_diff() always passes the earlier date to
timelib_do_rel_normalize() as one and on to
do_range_limit_days_relative() as base_*.
Previous Comments:
[2010-01-06 16:19:14] dani...@php.net
Hmm... Isn't the whole days_next_month functionality in
do_range_limit_days_relative() unnecessary?
[2010-01-06 01:04:18] dani...@php.net
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
?php
date_default_timezone_set('Europe/Berlin');
$d1 = new DateTime('2010-01-01 06:00:00');
$d2 = new DateTime('2010-01-31 10:00:00');
$d = $d1-diff($d2);
print_r($d);
?
Expected:
-
[m] = 0
[d] = 30
Actual:
---
[m] = 1
[d] = 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* 2
months, 30 days. 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns 3
months, 2 days. add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
?
$jan_1 = new DateTime('2009-01-01');
$mar_31 = new DateTime('2009-03-31');
var_dump(date_diff($jan_1, $mar_31));
var_dump($jan_1-add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1-add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' = 0, 'months' = 0, 'days' = 0,
'hours' = 0, 'minutes' = 0, 'seconds' = 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 = ($t3 = strtotime(+1 ${interval}, $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?
Expected result:
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(2)
[d]=
int(30)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16)
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
Hmm... Isn't the whole days_next_month functionality in
do_range_limit_days_relative() unnecessary?
Previous Comments:
[2010-01-06 01:04:18] dani...@php.net
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
?php
date_default_timezone_set('Europe/Berlin');
$d1 = new DateTime('2010-01-01 06:00:00');
$d2 = new DateTime('2010-01-31 10:00:00');
$d = $d1-diff($d2);
print_r($d);
?
Expected:
-
[m] = 0
[d] = 30
Actual:
---
[m] = 1
[d] = 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* 2
months, 30 days. 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns 3
months, 2 days. add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
?
$jan_1 = new DateTime('2009-01-01');
$mar_31 = new DateTime('2009-03-31');
var_dump(date_diff($jan_1, $mar_31));
var_dump($jan_1-add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1-add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' = 0, 'months' = 0, 'days' = 0,
'hours' = 0, 'minutes' = 0, 'seconds' = 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 = ($t3 = strtotime(+1 ${interval}, $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?
Expected result:
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(2)
[d]=
int(30)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-07-03 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
Actual result:
--
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(3)
[d]=
int(2)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-07-03 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
--
Edit this bug report at http://bugs.php.net/?id=49081edit=1
#50680 [NEW]: eight - eighth
From: danielc at analysisandsolutions dot com Operating system: PHP version: 5.3SVN-2010-01-06 (SVN) PHP Bug Type: Date/time related Bug description: eight - eighth Description: In ext/date/lib/parse_date.re, reltextnumber and timelib_reltext_lookup contain ordinal numbers, but when it comes to 8th, it mistakenly uses eight, rather than eighth. Guess it now needs to contain both to provide backwards compatibility. -- Edit bug report at http://bugs.php.net/?id=50680edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=50680r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=50680r=trysnapshot53 Try a snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=50680r=trysnapshot60 Fixed in SVN: http://bugs.php.net/fix.php?id=50680r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=50680r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=50680r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=50680r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=50680r=needscript Try newer version: http://bugs.php.net/fix.php?id=50680r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=50680r=support Expected behavior: http://bugs.php.net/fix.php?id=50680r=notwrong Not enough info: http://bugs.php.net/fix.php?id=50680r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=50680r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=50680r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=50680r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=50680r=dst IIS Stability: http://bugs.php.net/fix.php?id=50680r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=50680r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=50680r=float No Zend Extensions: http://bugs.php.net/fix.php?id=50680r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=50680r=mysqlcfg
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval 28 days
ID: 49081
Updated by: dani...@php.net
-Summary: DateTime::diff calculates diffs incorrectly
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
Previous Comments:
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
?php
date_default_timezone_set('Europe/Berlin');
$d1 = new DateTime('2010-01-01 06:00:00');
$d2 = new DateTime('2010-01-31 10:00:00');
$d = $d1-diff($d2);
print_r($d);
?
Expected:
-
[m] = 0
[d] = 30
Actual:
---
[m] = 1
[d] = 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* 2
months, 30 days. 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns 3
months, 2 days. add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
?
$jan_1 = new DateTime('2009-01-01');
$mar_31 = new DateTime('2009-03-31');
var_dump(date_diff($jan_1, $mar_31));
var_dump($jan_1-add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1-add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' = 0, 'months' = 0, 'days' = 0,
'hours' = 0, 'minutes' = 0, 'seconds' = 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 = ($t3 = strtotime(+1 ${interval}, $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?
Expected result:
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(2)
[d]=
int(30)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-07-03 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
Actual result:
--
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(3)
[d]=
int(2)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-07-03 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
--
Edit this bug report at http://bugs.php.net/?id=49081edit=1
#49081 [Asn]: [PATCH] DateTime::diff() mistake if start in January and interval 28 days
ID: 49081
Updated by: dani...@php.net
Reported By: nate at frickenate dot com
Status: Assigned
Bug Type: Date/time related
Operating System: *
PHP Version: 5.3.0
Assigned To: derick
New Comment:
A better test file:
http://www.analysisandsolutions.com/php/bug49081v2.phpt
The scenarios it covers are more relevant and thorough, plus it
improves the context, making it easier see what the test is doing.
Previous Comments:
[2010-01-05 22:11:57] dani...@php.net
This bug continues to exist in 5.3.2RC2.
DateTime::diff() / date_diff() chokes on dates starting in January if
the interval is greater than 28 days (during non-leap years).
It is happening because of a bug in do_range_limit_days_relative() in
ext/date/lib/tm2unixtime.c. At the end of the function if *d
days_next_month, the code subtracts the days and adds a month. So when
the starting month is January, the days_next_month is 28 or 29,
mistakenly triggering the month/day swapping behavior.
Patch:
http://www.analysisandsolutions.com/php/bug49081.diff
Test:
http://www.analysisandsolutions.com/php/bug49081.phpt
[2009-12-16 05:44:52] peter dot schleif at gmx dot de
More simple code to reproduce error:
?php
date_default_timezone_set('Europe/Berlin');
$d1 = new DateTime('2010-01-01 06:00:00');
$d2 = new DateTime('2010-01-31 10:00:00');
$d = $d1-diff($d2);
print_r($d);
?
Expected:
-
[m] = 0
[d] = 30
Actual:
---
[m] = 1
[d] = 2
[2009-07-27 22:55:24] nate at frickenate dot com
Description:
DateTime::diff calculates diffs incorrectly.
As an example, the diff of 2009-01-01 and 2009-03-31 *should be* 2
months, 30 days. 2009-01-01 + 2 months = 2009-03-01, + 30 days =
2009-03-31. Taking 2009-01-01 and using DateTime::add() to add 'P2M30D'
does indeed result in 2009-03-31. This is correct.
However, running the diff() of 2009-01-01 and 2009-03-31 returns 3
months, 2 days. add()ing 2009-01-01 + 'P3M2D' returns 2009-04-03
instead of 2009-03-31 (as it should, since the diff that told us to add
3M2D was incorrect).
Reproduce code:
---
?
$jan_1 = new DateTime('2009-01-01');
$mar_31 = new DateTime('2009-03-31');
var_dump(date_diff($jan_1, $mar_31));
var_dump($jan_1-add(new DateInterval('P2M30D'))); // correct period
var_dump($jan_1-add(new DateInterval('P3M2D'))); // incorrect period
// END EXAMPLE CODE - following is just extra fluff
// here's the replacement function I am currently
// using to calculate the correct diff until the
// built-in method is patched and functional
function date_diff2 ($t1, $t2) {
if (! preg_match('/^\d+\z/', $t1) ($t1 = strtotime($t1)) ===
false)
return false;
if (! preg_match('/^\d+\z/', $t2) ($t2 = strtotime($t2)) ===
false)
return false;
if ($t1 $t2)
list($t1, $t2) = array($t2, $t1);
$diffs = array(
'years' = 0, 'months' = 0, 'days' = 0,
'hours' = 0, 'minutes' = 0, 'seconds' = 0,
);
foreach (array_keys($diffs) as $interval) {
while ($t2 = ($t3 = strtotime(+1 ${interval}, $t1))) {
$t1 = $t3;
++$diffs[$interval];
}
}
return $diffs;
}
?
Expected result:
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(2)
[d]=
int(30)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-07-03 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
Actual result:
--
object(DateInterval)#3 (8) {
[y]=
int(0)
[m]=
int(3)
[d]=
int(2)
[h]=
int(0)
[i]=
int(0)
[s]=
int(0)
[invert]=
int(0)
[days]=
int(89)
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-03-31 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
object(DateTime)#1 (3) {
[date]=
string(19) 2009-07-03 00:00:00
[timezone_type]=
int(3)
[timezone]=
string(16) America/Montreal
}
--
Edit this bug report at http://bugs.php.net/?id=49081edit=1
#49767 [Asn]: estrdup crash
ID: 49767
Updated by: dani...@php.net
Reported By: mb at smartftp dot com
Status: Assigned
Bug Type: Reproducible crash
Operating System: win32 only -Windows 2008 SP2 x86
PHP Version: 5.3.0
Assigned To: pajoye
New Comment:
Bug #47627 marked duplicate of this.
Previous Comments:
[2009-10-04 19:35:54] mb at smartftp dot com
I have also sent you the crash report by email. Open the .mht file (RS
removed the .mth extension for some reason) with IE.
[2009-10-04 19:25:46] paj...@php.net
I corrected myself about the script by asking for the full bt (the one
on RS was not readable).
The diagnostic sounds good, I have to reproduce it to be sure. Assigned
to me.
[2009-10-04 17:28:20] mb at smartftp dot com
I don't think you need a script. A little bit of time and motivation
would do as well:
Please review your code:
File: main.c
PHPAPI int php_execute_script(zend_file_handle *primary_file
TSRMLS_DC)
{
...
#ifdef PHP_WIN32
UpdateIniFromRegistry(primary_file-filename TSRMLS_CC);
#endif
..
}
Then:
File: registry.c
void UpdateIniFromRegistry(char *path TSRMLS_DC)
{
- BUG: missing check for argument
// here comes the check for Per Directory registry value. If it is not
found the function exists and never comes to the estrdup and hence no
crash.
...
orig_path = path = estrdup(path);
..
}
The problem only happens if the Per Directory Values registry key is
present. In this case estrdup(NULL) is called and you get the crash.
So I think the argument (path) should be checked for NULL. And when I
look at the main.c I also noticed that you sometimes expect the
primary_file-filename to be null, so maybe you add a check before the
UpdateIniFromRegistry() call.
Proposed FIX:
#ifdef PHP_WIN32
if(primary_file-filename)
{
UpdateIniFromRegistry(primary_file-filename TSRMLS_CC);
}
#endif
+ Add argument check for UpdateIniFromRegistry
Workaround:
Remove Per Directories Values registry key.
Regards,
Mat
[2009-10-04 17:23:34] paj...@php.net
Btw, can you also zip the report and send it to me or provide a link to
the zip (pls not one of these radidshare thing) :)
[2009-10-04 17:21:26] paj...@php.net
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/49767
--
Edit this bug report at http://bugs.php.net/?id=49767edit=1
#47629 [Opn]: mysqli connect timeout causes fatal error
ID: 47629 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Open Bug Type: MySQLi related Operating System: Windows XP SP3 PHP Version: 5.3CVS-2009-03-12 (snap) Assigned To: pajoye New Comment: I'll put together tests of the various functions and report back. Previous Comments: [2009-06-21 09:04:11] paj...@php.net 1) That's how PHP 5.2 does it. Not really relevant in this case. 2) That's how the other socket functions do it in 5.2 and 5.3. Then there is a bug here. 3) The timeout is from communication with another entity, not from the script itself. The max_execution_time has the highest priority and should always has it. If it is not the case in one function or another then there is a bug in this function. [2009-06-21 00:48:41] danielc at analysisandsolutions dot com Because: 1) That's how PHP 5.2 does it. 2) That's how the other socket functions do it in 5.2 and 5.3. 3) The timeout is from communication with another entity, not from the script itself. [2009-06-20 20:12:24] paj...@php.net but there is no bug here. Why do you want to let the socket timeout override the main timeout? [2009-06-20 17:34:32] dani...@php.net Yes, the execution timeout makes sense some ways. The problem is the behavior is inconsistent between 5.2 and 5.3 and between other connection functions. [2009-06-20 13:19:04] paj...@php.net With: max_execution_time: 2 default_socket_timeout: 6 It is the expected behavior to have a fatal error about the maximum execution time being exceeded. max_execution_time has the highest importance. 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/47629 -- Edit this bug report at http://bugs.php.net/?id=47629edit=1
#47629 [Bgs-Fbk]: mysqli connect timeout causes fatal error
ID: 47629
Updated by: dani...@php.net
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Feedback
Bug Type: MySQLi related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-03-12 (snap)
-Assigned To:
+Assigned To: pajoye
New Comment:
Yes, the execution timeout makes sense some ways. The problem is the
behavior is inconsistent between 5.2 and 5.3 and between other
connection functions.
Previous Comments:
[2009-06-20 13:19:04] paj...@php.net
With:
max_execution_time: 2
default_socket_timeout: 6
It is the expected behavior to have a fatal error about the maximum
execution time being exceeded. max_execution_time has the highest
importance.
[2009-03-12 04:41:21] danielc at analysisandsolutions dot com
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11
2009 17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . \n\n;
echo ONE ---\n;
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
echo TWO ---\n;
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit this bug report at http://bugs.php.net/?id=47629edit=1
#47629 [Fbk-Opn]: mysqli connect timeout causes fatal error
ID: 47629
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: MySQLi related
Operating System: Windows XP SP3
PHP Version: 5.3CVS-2009-03-12 (snap)
Assigned To: pajoye
New Comment:
Because:
1) That's how PHP 5.2 does it.
2) That's how the other socket functions do it in 5.2 and 5.3.
3) The timeout is from communication with another entity, not from the
script itself.
Previous Comments:
[2009-06-20 20:12:24] paj...@php.net
but there is no bug here. Why do you want to let the socket timeout
override the main timeout?
[2009-06-20 17:34:32] dani...@php.net
Yes, the execution timeout makes sense some ways. The problem is the
behavior is inconsistent between 5.2 and 5.3 and between other
connection functions.
[2009-06-20 13:19:04] paj...@php.net
With:
max_execution_time: 2
default_socket_timeout: 6
It is the expected behavior to have a fatal error about the maximum
execution time being exceeded. max_execution_time has the highest
importance.
[2009-03-12 04:41:21] danielc at analysisandsolutions dot com
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11
2009 17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . \n\n;
echo ONE ---\n;
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
echo TWO ---\n;
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond
after a period of time, or established connection failed because
connected host has failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit this bug report at http://bugs.php.net/?id=47629edit=1
#43866 [Bgs]: Can't define the connect timeout on mysqli extension class
ID: 43866
Updated by: dani...@php.net
Reported By: basilio dot vera at softonic dot com
Status: Bogus
Bug Type: MySQLi related
Operating System: Linux RHEL4
PHP Version: 5.2.5
New Comment:
Examples added to manual.
Previous Comments:
[2008-01-17 18:35:52] u...@php.net
Not a bug, solution is given, documentation flaw discussed.
[2008-01-17 17:54:44] basilio dot vera at softonic dot com
For example with an example inside the mysqli_init() or
mysqli_options() function docs:
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
parent::init();
parent::options( MYSQLI_OPT_CONNECT_TIMEOUT, 5 );
parent::real_connect( $host, $user, $pass, $db );
}
}
Regards.
[2008-01-17 17:29:50] u...@php.net
Give me a hint, what's up with the documentation?
http://us2.php.net/mysqli_connect shows that calling constructor of the
mysqli class is equal to calling mysqli_connect(). As you know, you need
to call mysqli_options() before a connection has been established. In
your reproduceable code you suggest a derived class which explicitly
calls the parent constructor to create a connection. Once the parent
constructor has been called you try to call mysqli_options()
(mysqli::options()). That's too late.
Your second example gets it right. How could we improve the
documentation? Thanks!
Ulf
[2008-01-17 00:19:51] basilio dot vera at softonic dot com
Hi, I've found a solution for this problem. It can be solved with:
class mysqli2 extends mysqli
{
public function __construct( $host, $user, $pass, $db )
{
$this-init();
$this-options(MYSQLI_OPT_CONNECT_TIMEOUT, 5);
$this-real_connect( $host, $user, $pass, $db );
}
}
But you may consider review your docs, because it's and undocumented
feature!
[2008-01-16 14:34:39] basilio dot vera at softonic dot com
Sorry, the error message was:
'Couldn't fetch mysqli2'
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/43866
--
Edit this bug report at http://bugs.php.net/?id=43866edit=1
#45940 [Csd]: MySQLI OO does not populate connect_error property on failed connect
ID: 45940
Updated by: dani...@php.net
Reported By: talmage dot news at gmail dot com
Status: Closed
Bug Type: MySQLi related
Operating System: Centos 5
PHP Version: 5.2.6
Assigned To: mysql
New Comment:
Added information to the documentation.
Previous Comments:
[2009-02-17 10:41:59] johan...@php.net
Fixed in 5.2 CVS, too, now.
[2009-01-12 12:56:23] johan...@php.net
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.
[2009-01-10 10:23:30] nullhility at gmail dot com
Getting the same error with the following version:
PHP 5.2.4-2ubuntu5.4 with Suhosin-Patch 0.9.6.2
I was attempting to suppress errors so I could control
output/formatting etc. Thought i'd just re-iterate this for version
related purposes.
?php
//a forced username/password mismatch
$dbo = @new mysqli('localhost', 'r00t', 'pass', 'my_db');
var_dump($dbo-connect_error);
var_dump(mysqli_connect_error());
?
output:
Warning: main(): Couldn't fetch mysqli in /home/default/php/mysqli.php
on line 4
NULL
string(63) Access denied for user 'r00t'@'localhost' (using password:
YES)
[2008-12-25 21:17:22] ws at develtheory dot com
Was able to reproduce the error in the same method on php 5.2.8, both
with purposeful incorrect passwords and nonexistent host/port combos.
the object is created, connect_error returns NULL on var_dump, error
log dumps:
Dec 25 15:12:18 dev01 httpd: PHP Warning: dbo::__construct() [a
href='dbo.--construct'dbo.--construct/a]: Couldn't fetch mysqli in
/nfs/beta/www/classes/dbo-new.inc.php on line 88
[2008-12-01 13:39:16] dannyrjohnston at msn dot com
Forget my previous comment. I found some code between the new mysqli
statement in the example I was using which was setting the $dbObj to
false if mysql_connect_error was returning a value.
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/45940
--
Edit this bug report at http://bugs.php.net/?id=45940edit=1
#47627 [NEW]: No input file specified causing crash
From: danielc at analysisandsolutions dot com Operating system: Windows XP Pro SP3 PHP version: 5.3CVS-2009-03-11 (snap) PHP Bug Type: CGI related Bug description: No input file specified causing crash Description: In PHP 5.3, pointing my browser to a .php file that does not exist causes php-cgi to crash and Apache to return a 500 error. In PHP 5.2.6, doing so returns output saying No input file specified. During the crash, Windows displays the Please tell Microsoft about this problem dialog box. The title is CGI / FastCGI. The To see what data this error report contains sub dialog box says: Error signature szAppName : php-cgi.exe szAppVer : 5.3.0.0 szModName : php5ts.dll szModVer : 5.3.0.0 offset : 000cea5d The To view technical information about the error report sub sub dialog box contains: C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\php-cgi.exe.mdmp C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\WERc9f6.dir00\appcompat.txt My Apache 1.3 error log message shows: [Wed Mar 11 14:59:02 2009] [error] [client 127.0.0.1] Premature end of script headers: c:/program files/php/php-cgi.exe My PHP version is: PHP 5.3.0beta2-dev (cgi-fcgi) (built: Mar 11 2009 17:04:23) -- Edit bug report at http://bugs.php.net/?id=47627edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=47627r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=47627r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=47627r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=47627r=fixedcvs Fixed in CVS and need be documented: http://bugs.php.net/fix.php?id=47627r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=47627r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=47627r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=47627r=needscript Try newer version: http://bugs.php.net/fix.php?id=47627r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=47627r=support Expected behavior: http://bugs.php.net/fix.php?id=47627r=notwrong Not enough info: http://bugs.php.net/fix.php?id=47627r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=47627r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=47627r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47627r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=47627r=dst IIS Stability: http://bugs.php.net/fix.php?id=47627r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=47627r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=47627r=float No Zend Extensions: http://bugs.php.net/fix.php?id=47627r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=47627r=mysqlcfg
#47629 [NEW]: mysqli connect timeout causes fatal error
From: danielc at analysisandsolutions dot com
Operating system: Windows XP SP3
PHP version: 5.3CVS-2009-03-12 (snap)
PHP Bug Type: MySQLi related
Bug description: mysqli connect timeout causes fatal error
Description:
A fatal error is generated if a MySQLi connection attempt times out AND
the default_socket_timeout ini setting is greater that the
max_execution_time ini setting. This is happening in PHP 5.3, Mar 11 2009
17:04:24, VC6 thread safe snapshot build.
This does not happen on timeouts when using socket_bind().
This does not happen in PHP 5.2.9-1.
Reproduce code:
---
// BOGUS MYSQL PORT NUMBER IS INTENTIONAL.
echo 'PHP ' . phpversion() . \n\n;
echo ONE ---\n;
ini_set('max_execution_time', 6);
ini_set('default_socket_timeout', 2);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
echo TWO ---\n;
ini_set('max_execution_time', 2);
ini_set('default_socket_timeout', 6);
echo 'max_execution_time: ' . ini_get('max_execution_time') . \n;
echo 'default_socket_timeout: ' . ini_get('default_socket_timeout') .
\n;
$mysqli = new mysqli('localhost', 'does', 'not', 'matter', 1);
if ($mysqli-connect_error) {
echo GOOD CATCH\n\n;
}
Expected result:
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
Actual result:
--
PHP 5.3.0beta2-dev
ONE ---
max_execution_time: 6
default_socket_timeout: 2
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
GOOD CATCH
TWO ---
max_execution_time: 2
default_socket_timeout: 6
Warning: mysqli::mysqli() [mysqli.mysqli]: [2002] A connection attempt
failed because the connected party did not (trying to connect via
tcp://localhost:1) in ...
Warning: mysqli::mysqli() [mysqli.mysqli]: (HY000/2002): A connection
attempt failed because the connected party did not properly respond after a
period of time, or established connection failed because connected host has
failed to respond. in ...
Fatal error: Maximum execution time of 2 seconds exceeded in ...
--
Edit bug report at http://bugs.php.net/?id=47629edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47629r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47629r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47629r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47629r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47629r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47629r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47629r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47629r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47629r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47629r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47629r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47629r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47629r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47629r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47629r=php4
Daylight Savings:http
#47543 [Bgs-Opn]: irrelevant warning message
ID: 47543
Updated by: dani...@php.net
Reported By: jeffreybolle at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Mail related
Operating System: Windows Vista SP1
PHP Version: 5.3.0beta1
-Assigned To:
+Assigned To: kalle
New Comment:
The php.ini-recommended and php.ini-dist in CVS need to have the
mail.log entries commented out by default.
Previous Comments:
[2009-03-02 15:45:51] jeffreybolle at gmail dot com
Hi Kalle,
Yes that was it my php.ini file had mail.log = uncommented by
default. Once I removed that line the warning disappeared.
Thank you for your help. Sorry for the bogus report.
Regards
Jeffrey
[2009-03-02 15:30:45] ka...@php.net
Have you enabled the mailing logging feature thats available as of PHP
5.3 and not defined a mail log setting (mail.log)
[2009-03-02 12:50:31] jeffreybolle at gmail dot com
Description:
When using the mail() function PHP displays an irrelevant warning
message.
Reproduce code:
---
mail(jeffreybo...@gmail.com,test subject,test message);
Expected result:
The email is sent and no warnings are displayed.
Actual result:
--
The email is sent but the following warning is displayed:
Warning: mail() [function.mail]: Filename cannot be empty in {script
name} on line {line number}
--
Edit this bug report at http://bugs.php.net/?id=47543edit=1
#47320 [NEW]: $php_errormsg out of scope in functions
From: danielc at analysisandsolutions dot com
Operating system:
PHP version: 5.3.0beta1
PHP Bug Type: Scripting Engine problem
Bug description: $php_errormsg out of scope in functions
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer available
inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . \n;
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . \n;
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . \n;
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1 given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1 given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit bug report at http://bugs.php.net/?id=47320edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=47320r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=47320r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=47320r=trysnapshot60
Fixed in CVS:
http://bugs.php.net/fix.php?id=47320r=fixedcvs
Fixed in CVS and need be documented:
http://bugs.php.net/fix.php?id=47320r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=47320r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=47320r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=47320r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=47320r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=47320r=support
Expected behavior:
http://bugs.php.net/fix.php?id=47320r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=47320r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=47320r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=47320r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=47320r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=47320r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=47320r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=47320r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=47320r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=47320r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=47320r=mysqlcfg
#47320 [Fbk-Opn]: $php_errormsg out of scope in functions
ID: 47320
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.3.0beta1
New Comment:
Compared to 5.2.6.
Previous Comments:
[2009-02-05 23:45:07] j...@php.net
Compared to what version?
[2009-02-05 23:12:59] danielc at analysisandsolutions dot com
Description:
The scope of $php_errormsg has changed in 5.3. It is no longer
available inside functions.
Perhaps this is intentional, perhaps not. If it is intentional, I
encourage the decision be changed to improve compatibility between
versions.
If it won't be changed, we need to update the 5.3 upgrade guide at
http://wiki.php.net/doc/scratchpad/upgrade/53.
Reproduce code:
---
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in global: ' . $php_errormsg . \n;
}
function foo() {
if (!...@substr('no 2nd parameter')) {
echo '$php_errormsg in function: ' . $php_errormsg . \n;
echo '$GLOBALS[php_errormsg] in function: ' .
$GLOBALS['php_errormsg'] . \n;
}
}
foo();
Expected result:
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
$php_errormsg in function: substr() expects at least 2 parameters, 1
given
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
Actual result:
--
$php_errormsg in global: substr() expects at least 2 parameters, 1
given
Notice: Undefined variable: php_errormsg in
D:\webroot\ideasphp\Atest.html on line 10
$php_errormsg in function:
$GLOBALS[php_errormsg] in function: substr() expects at least 2
parameters, 1 given
--
Edit this bug report at http://bugs.php.net/?id=47320edit=1
#43817 [Csd-Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: dani...@php.net
Reported By: losd at mail dot dk
-Status: Closed
+Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
PHP Version: 5.2.5
Assigned To: dmitry
New Comment:
This problem still exists in 5.3.0 beta 1
(http://windows.php.net/downloads/qa/php-5.3.0beta1-Win32-VC6-x86.zip)
Previous Comments:
[2008-08-12 09:42:06] dmi...@php.net
Fixed in CVS HEAD and PHP_5_3.
[2008-03-01 09:09:15] losd at mail dot dk
Doh, sorry, thought I could edit the original text. Just delete that
comment.
But yes, as Daniel correctly points out, it's all Windows permission
handling (As my reproduce code also shows), not just related to network
shares... I experienced it in one at first, I guess that's why it stuck
in my brain.
[2008-03-01 09:02:02] losd at mail dot dk
Description:
If the parent directory of a Windows directory is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
?php
if ($handle = opendir(C:/Test/NoAccess/Access/Subdir)) {
echo Opened dir C:/Test/NoAccess/Access/Subdirbr/;
while (false !== ($file = readdir($handle)))
echoFile: $filebr/;
closedir($handle);
} else {
echo H, can't open directory, is it accessible?br/;
}
echo br/;
if ($handle = opendir(C:/Test/NoAccess/Access)) {
echo Opened directory C:/Test/NoAccess/Accessbr/;
while (false !== ($file = readdir($handle)))
echoFile: $filebr/;
closedir($handle);
} else {
echo H, can't open directory, is it accessible?br/;
}
?
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
[2008-03-01 01:10:46] dani...@php.net
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
[2008-01-11 13:36:50] losd at mail dot dk
Temporary workaround found, but only if there is a known subdirectory
inside the top accessible directory:
opendir(C:/Test/NoAccess/Access/Subdir/..);
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/43817
--
Edit this bug report at http://bugs.php.net/?id=43817edit=1
#43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: dani...@php.net
Reported By: losd at mail dot dk
Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
-PHP Version: 5.2.5
+PHP Version: 5.3.0beta1
Assigned To: dmitry
New Comment:
Changing version from 5.2.5 to 5.3.0beta1 to facilitate this getting
fixed before the next release.
Previous Comments:
[2009-02-03 15:31:49] dani...@php.net
This problem still exists in 5.3.0 beta 1
(http://windows.php.net/downloads/qa/php-5.3.0beta1-Win32-VC6-x86.zip)
[2008-08-12 09:42:06] dmi...@php.net
Fixed in CVS HEAD and PHP_5_3.
[2008-03-01 09:09:15] losd at mail dot dk
Doh, sorry, thought I could edit the original text. Just delete that
comment.
But yes, as Daniel correctly points out, it's all Windows permission
handling (As my reproduce code also shows), not just related to network
shares... I experienced it in one at first, I guess that's why it stuck
in my brain.
[2008-03-01 09:02:02] losd at mail dot dk
Description:
If the parent directory of a Windows directory is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
?php
if ($handle = opendir(C:/Test/NoAccess/Access/Subdir)) {
echo Opened dir C:/Test/NoAccess/Access/Subdirbr/;
while (false !== ($file = readdir($handle)))
echoFile: $filebr/;
closedir($handle);
} else {
echo H, can't open directory, is it accessible?br/;
}
echo br/;
if ($handle = opendir(C:/Test/NoAccess/Access)) {
echo Opened directory C:/Test/NoAccess/Accessbr/;
while (false !== ($file = readdir($handle)))
echoFile: $filebr/;
closedir($handle);
} else {
echo H, can't open directory, is it accessible?br/;
}
?
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
[2008-03-01 01:10:46] dani...@php.net
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
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/43817
--
Edit this bug report at http://bugs.php.net/?id=43817edit=1
#44769 [Com]: declaring private magic methods should throw error
ID: 44769
Comment by: danielc at analysisandsolutions dot com
Reported By: todd at magnifisites dot com
Status: Open
Bug Type: Scripting Engine problem
Operating System: *
PHP Version: 5.2.5
New Comment:
Marcus feels this is a bug and should be addressed
(http://news.php.net/php.internals/37857).
Once this is fixed, the documentation bug should be updated
(http://bugs.php.net/bug.php?id=43924).
Here are earlier bug reports covering this issue...
Documentation bugs that have been closed:
http://bugs.php.net/bug.php?id=31806
http://bugs.php.net/bug.php?id=40103
Illia marked this bogus saying it is the expected behavior.
http://bugs.php.net/bug.php?id=40056
Previous Comments:
[2008-04-17 23:15:57] todd at magnifisites dot com
Description:
When using object overloading I thought I might receive at the very
least a warning error if I attempted to declare any of the magic methods
as private in a class definition as per the documentation:
All overloading methods must be defined as public.
http://php.net/language.oop5.overloading.php
Also tested in PHP 6CVS-2008-04-17 (snap)
Reproduce code:
---
class MemberTest {
/** Location for overloaded data. */
private $data = array();
private function __set($name, $value) {
echo Setting '$name' to '$value'\n;
$this-data[$name] = $value;
}
private function __get($name) {
echo Getting '$name'\n;
if (array_key_exists($name, $this-data)) {
return $this-data[$name];
}
}
}
echo pre\n;
$obj = new MemberTest;
$obj-a = 1;
echo $obj-a . \n;
exit;
Expected result:
A FATAL error or at the very least a WARNING error with
error_reporting = E_ALL | E_STRICT
Actual result:
--
pre
Setting 'a' to '1'
Getting 'a'
1
--
Edit this bug report at http://bugs.php.net/?id=44769edit=1
#45089 [NEW]: __callStatic $name case sensitivity
From: danielc at analysisandsolutions dot com
Operating system:
PHP version: 5.3CVS-2008-05-26 (snap)
PHP Bug Type: Class/Object related
Bug description: __callStatic $name case sensitivity
Description:
The value of $name produced by __callStatic() is lower cased but the $name
produced by the regular __call() is unchanged.
Please adjust __callStatic() so it doesn't change the case of $name.
Reproduce code:
---
class MethodTest {
public static function __callStatic($name, $arguments) {
echo Calling static method '$name'
. implode(', ', $arguments). \n;
}
}
MethodTest::runTest('in static context');
Expected result:
Calling static method 'runTest' in static context
Actual result:
--
Calling static method 'runtest' in static context
--
Edit bug report at http://bugs.php.net/?id=45089edit=1
--
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=45089r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=45089r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=45089r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=45089r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=45089r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=45089r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=45089r=needscript
Try newer version:http://bugs.php.net/fix.php?id=45089r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=45089r=support
Expected behavior:http://bugs.php.net/fix.php?id=45089r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=45089r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=45089r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=45089r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=45089r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=45089r=dst
IIS Stability:http://bugs.php.net/fix.php?id=45089r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=45089r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=45089r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=45089r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=45089r=mysqlcfg
#43817 [Asn]: opendir() fails on Windows directories with parent directory unaccessible
ID: 43817
Updated by: [EMAIL PROTECTED]
Reported By: losd at mail dot dk
Status: Assigned
Bug Type: Directory function related
Operating System: Windows Server 2003
PHP Version: 5.2.5
Assigned To: dmitry
New Comment:
I am experiencing this issue as well, but on local directories, not
network shares. My OS is Windows XP Pro. The opendir() functionality
works correctly in release 5.2.1. The functionality is broken in
releases 5.2.2 through 5.2.5, plus the 526-php5.2-win32-200802292130 and
php5.3-win32-200802201330 snapshots.
Previous Comments:
[2008-01-11 13:36:50] losd at mail dot dk
Temporary workaround found, but only if there is a known subdirectory
inside the top accessible directory:
opendir(C:/Test/NoAccess/Access/Subdir/..);
[2008-01-11 12:23:54] losd at mail dot dk
Description:
If the parent directory of a Windows network share is not accessible,
you are still able to access subdirectories if given explicit
permission.
However, PHP has trouble with the first accessible directory below an
inaccessible directory. This is not a problem for the accessible dir's
subdirs, though.
Scenario:
C:/Test/NoAccess/ -- Not accessible
Access/-- Accesible from here
yyy.txt
Subdir/
xxx.txt
The problem has been found with opendir(), is_dir() and is_readable().
All directory functions are probably affected.
No workarounds has been found so far (suggestions appreciated).
Reproduce code:
---
?php
if ($handle = opendir(C:/Test/NoAccess/Access/Subdir)) {
echo Opened dir C:/Test/NoAccess/Access/Subdirbr/;
while (false !== ($file = readdir($handle)))
echoFile: $filebr/;
closedir($handle);
} else {
echo H, can't open directory, is it accessible?br/;
}
echo br/;
if ($handle = opendir(C:/Test/NoAccess/Access)) {
echo Opened directory C:/Test/NoAccess/Accessbr/;
while (false !== ($file = readdir($handle)))
echoFile: $filebr/;
closedir($handle);
} else {
echo H, can't open directory, is it accessible?br/;
}
?
Expected result:
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Opened dir C:/Test/NoAccess/Access
File: .
File: ..
File: yyy.txt
File: Subdir
Actual result:
--
Opened dir C:/Test/NoAccess/Access/Subdir
File: .
File: ..
File: xxx.txt
Warning: opendir(C:/Test/NoAccess/Access) [function.opendir]: failed to
open dir: No such file or directory in
C:\Inetpub\wwwroot\pm2\opendir.php on line 13
H, can't open directory, is it accessible?
--
Edit this bug report at http://bugs.php.net/?id=43817edit=1
#36688 [NoF-Bgs]: date() doesnt five right date sometimes
ID: 36688
Updated by: [EMAIL PROTECTED]
Reported By: phil at adigital dot com dot mx
-Status: No Feedback
+Status: Bogus
Bug Type: Date/time related
Operating System: Win XP and Linux FC4
PHP Version: 5.1.2
New Comment:
The United States changed Daylight Savings Time start/end:
= 2006: 1st Sunday in April at 2:00 am
= 2007: 2nd Sunday in March at 2:00 am
TEST:
-
?php
//$t1 = strtotime('2006-03-05 02:30:00'); // 1141543800
$t1 = strtotime('2007-03-04 01:30:00'); // 1172989800
//$t2 = strtotime('2006-03-05 01:30:00'); // 1141540200
$t2 = strtotime('2007-03-04 02:30:00'); // 1172993400
$step = 60 * 60 * 24 * 7; // Increment one week
for ($i = 0; $i 6; $i++) {
echo $t1 . ' = ' . date('r', $t1) . \n;
echo $t2 . ' = ' . date('r', $t2) . \n;
echo ---\n;
$t1 = $t1 + $step;
$t2 = $t2 + $step;
}
?
OUTPUT:
---
1172989800 = Sun, 04 Mar 2007 01:30:00 -0500
1172993400 = Sun, 04 Mar 2007 02:30:00 -0500
---
1173594600 = Sun, 11 Mar 2007 01:30:00 -0500
1173598200 = Sun, 11 Mar 2007 03:30:00 -0400
---
1174199400 = Sun, 18 Mar 2007 02:30:00 -0400
1174203000 = Sun, 18 Mar 2007 03:30:00 -0400
---
1174804200 = Sun, 25 Mar 2007 02:30:00 -0400
1174807800 = Sun, 25 Mar 2007 03:30:00 -0400
---
1175409000 = Sun, 01 Apr 2007 02:30:00 -0400
1175412600 = Sun, 01 Apr 2007 03:30:00 -0400
---
1176013800 = Sun, 08 Apr 2007 02:30:00 -0400
1176017400 = Sun, 08 Apr 2007 03:30:00 -0400
---
Previous Comments:
[2006-10-30 16:57:34] gxt3 at dowling dot edu
I can confirm the bug of date() shifting one hour. I use
date in a calendar app :
date(d,(mktime(0,0,0,$month,$day,$year)+$m*24*60*60))
where m goes from 0 to 1 and $month, $day, $year are given
by the user. So it is either mktime or date problem.
for the last week of November the timestamps returned are:
27 Nov: 1161921600
28 Nov: 1162008000
29 Nov: 1162094400
30 Nov: 1162180800 (Bug here it is 23:00PM of 29th yet )
31 Nov: 1162267200 (Bug still here )
01 Oct: 1162353600 (Bug still present)
02 Oct: 116244 (Same here)
The following week (my weeks start on Friday) the times are
back to normal.
The system is slackware 10.2 and I have not seen this bug in
the past year. This is the first week that it occurs.
[2006-03-19 01:00:04] 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-03-11 16:52:51] [EMAIL PROTECTED]
What timezone did you configure your server to use? (date.timezone
php.ini setting).
[2006-03-10 23:48:22] phil at adigital dot com dot mx
Description:
date(Y-m-d H:i:s, 1175403600);
shows: 2007/4/1 00:00:00
Should be: 2007/3/1 23:00:00
the hour is shift 1 hour in PHP from march/11/2007 to april/1/2007 (20
days of 1 hour diff !)
The same problem repeat 2008, 2009, 2010, 2011, etc, but the beginning
of problem is +/- 5 days and ending problem too +/- 5 days
It seems the problem is not occuring before 3/1/2007
I thought first it was maybe a daylight savings problem
BUT:
- it happens on our redhat 8 servers in US (ev1), local servers (FC4)
AND windows XP
- the start and end date of the problem is quite random in a period ,
daylights are quite fixed
- It doesnt happen before 3/1/2007
SO i guess it's a bad bug somewhere
the result *must* be same as unix_timestamp C++ function no ?
It is not
Thx !
Reproduce code:
---
print date(Y-m-d H:i:s, 1175403600); // bad +1 hour
print date(Y-m-d H:i:s, 1238417200); // bad +1 hour
print mktime(0,0,0,4,1,2007);
Expected result:
2007/3/1 23:00:00
2009-03-30 06:46:40
1175407200
Actual result:
--
2007/4/1 00:00:00
2009-03-30 07:46:40
1175403600
--
Edit this bug report at http://bugs.php.net/?id=36688edit=1
#38781 [WFx-Bgs]: strtotime() generates wrong date for 11th month 2007 on.
ID: 38781
Updated by: [EMAIL PROTECTED]
Reported By: rpk at npstrategy dot com
-Status: Wont fix
+Status: Bogus
Bug Type: Date/time related
Operating System: Linux Fedora Core 4
PHP Version: 4.4.4
New Comment:
?php
/*
* The United States changed Daylight Savings Time
* Start:
* = 2006: First Sunday in April at 2:00 am
* = 2007: Second Sunday in March at 2:00 am
* End:
* = 2006: Last Sunday in October at 2:00 am
* = 2007: First Sunday in November at 2:00 am
*
* http://aa.usno.navy.mil/faq/docs/daylight_time.html
*/
// SPRING --
// 2006
//$t1 = strtotime('2006-03-05 02:30:00');
//$t2 = strtotime('2006-03-05 01:30:00');
//
// 2007
//$t1 = strtotime('2007-03-04 01:30:00');
//$t2 = strtotime('2007-03-04 02:30:00');
// --
// FALL
// 2006
//$t1 = strtotime('2006-10-22 01:30:00');
//$t2 = strtotime('2006-10-22 02:30:00');
//
// 2007
$t1 = strtotime('2007-10-21 01:30:00');
$t2 = strtotime('2007-10-21 02:30:00');
// --
$step = 60 * 60 * 24 * 7; // Increment one week
for ($i = 0; $i 6; $i++) {
echo $t1 . ' = ' . date('r', $t1) . \n;
echo $t2 . ' = ' . date('r', $t2) . \n;
echo ---\n;
$t1 = $t1 + $step;
$t2 = $t2 + $step;
}
OUTPUT:
---
1192944600 = Sun, 21 Oct 2007 01:30:00 -0400
1192948200 = Sun, 21 Oct 2007 02:30:00 -0400
---
1193549400 = Sun, 28 Oct 2007 01:30:00 -0400
1193553000 = Sun, 28 Oct 2007 02:30:00 -0400
---
1194154200 = Sun, 04 Nov 2007 01:30:00 -0400
1194157800 = Sun, 04 Nov 2007 01:30:00 -0500
---
1194759000 = Sun, 11 Nov 2007 00:30:00 -0500
1194762600 = Sun, 11 Nov 2007 01:30:00 -0500
---
1195363800 = Sun, 18 Nov 2007 00:30:00 -0500
1195367400 = Sun, 18 Nov 2007 01:30:00 -0500
---
1195968600 = Sun, 25 Nov 2007 00:30:00 -0500
1195972200 = Sun, 25 Nov 2007 01:30:00 -0500
Previous Comments:
[2006-09-12 08:31:43] [EMAIL PROTECTED]
I still can not reproduce it.
month11_2006_date for Friday 2006 = 17(correct)
month11_2007_date = 16 (wrong)
Anyway, we're not going to do any major changes in PHP4.
The datetime related code was rewritten in 5.1, which you should use
instead.
[2006-09-11 21:28:49] rpk at npstrategy dot com
running program
http://southo.org/date_test.php
Code:
$month11_2006_timestamp = mktime(0,0,0,11,1,2006);
$month11_2006_day_timestamp = strtotime(3
Friday,$month11_2006_timestamp);
$month11_2006_date = date('j',$month11_2006_day_timestamp);
echoh1month11_2006_date for Friday 2006 = $month11_2006_date
(correct)/h1;
$month11_2007_timestamp = mktime(0,0,0,11,1,2007);
$month11_2007_day_timestamp = strtotime(3
Friday,$month11_2007_timestamp);
$month11_2007_date = date('j',$month11_2007_day_timestamp);
echoh1month11_2007_date = $month11_2007_date (wrong)/h1;
[2006-09-11 18:29:09] [EMAIL PROTECTED]
Can't reproduce with both 4.4 and 5.2.
I get 17 and 16, both are correct results.
Also, please try to be more clear when you provide reproduce code. Lot
of HTML and text do not add any understanding.
[2006-09-11 18:16:17] rpk at npstrategy dot com
Description:
strtotime starts generating wrong timestamps in November, 2007. Only
wrong in the month of November. Rest of months are ok.
strtotime(3 Friday, $november_2006_timestamp) generates correct
timestamp with date which is the 3rd Friday in November 2006.
strtotime(3 Friday, $november_2007_timestamp) generates wrong
timestamp with date which should be the 3rd Friday in November 2007.
The date generated is -1 day, in this case, Thursday in the month of
November, 2007.
All dates generated are wrong in the months of November. Tested up to
2009. Every other month works ok.
Reproduce code:
---
?php
$month11_2006_timestamp = mktime(0,0,0,11,1,2006);
$month11_2006_day_timestamp = strtotime(3
Friday,$month11_2006_timestamp);
$month11_2006_date = date('j',$month11_2006_day_timestamp);
echoh1month11_2006_date for Friday 2006 = $month11_2006_date
(correct)/h1;
echoh1This correctly shows the 3rd Friday date for November, 2006
/h1;
//test of strtotime() generating date string for day in 3 week in
November 2007
$month11_2007_timestamp = mktime(0,0,0,11,1,2007);
$month11_2007_day_timestamp = strtotime(3
Friday,$month11_2007_timestamp);
$month11_2007_date = date('j',$month11_2007_day_timestamp);
echoh1month11_2007_date = $month11_2007_date (wrong)/h1;
echoh1This incorrectly shows the 3rd Friday date for November, 2007
bras the 15th of November 2007 which is a Thursday.
pEvery day-date generated from November 2007-2009 produces at -1
day from
#38558 [Csd-Opn]: [patch] run-tests.php: spaces in path
ID: 38558 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Closed +Status: Open Bug Type: Unknown/Other Function Operating System: Windows 2000 PHP Version: 5.2.0RC2 New Comment: Thanks for the prompt action, Tony. Here are patches for 5.1 and 5.0: http://www.analysisandsolutions.com/php/run-tests--pathspace-51.diff http://www.analysisandsolutions.com/php/run-tests--pathspace-50.diff Previous Comments: [2006-08-23 07:03:15] [EMAIL PROTECTED] This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Committed, thanks. [2006-08-23 04:25:38] danielc at analysisandsolutions dot com Description: run-tests.php doesn't account for spaces in the path to it. This oversight produces the following errors: Could not open input file: c:\Program (2 times) parse error, unexpected $end in Command line code on line 1 In addition, those errors cause $php_info section from parsing/outputting correctly. The following patch fixes it. http://www.analysisandsolutions.com/php/run-tests--pathspace.diff Thanks. -- Edit this bug report at http://bugs.php.net/?id=38558edit=1
#38558 [NEW]: [patch] run-tests.php: spaces in path
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5.2.0RC2 PHP Bug Type: Unknown/Other Function Bug description: [patch] run-tests.php: spaces in path Description: run-tests.php doesn't account for spaces in the path to it. This oversight produces the following errors: Could not open input file: c:\Program (2 times) parse error, unexpected $end in Command line code on line 1 In addition, those errors cause $php_info section from parsing/outputting correctly. The following patch fixes it. http://www.analysisandsolutions.com/php/run-tests--pathspace.diff Thanks. -- Edit bug report at http://bugs.php.net/?id=38558edit=1 -- Try a CVS snapshot (PHP 4.4): http://bugs.php.net/fix.php?id=38558r=trysnapshot44 Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=38558r=trysnapshot52 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=38558r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=38558r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=38558r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=38558r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=38558r=needscript Try newer version:http://bugs.php.net/fix.php?id=38558r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=38558r=support Expected behavior:http://bugs.php.net/fix.php?id=38558r=notwrong Not enough info: http://bugs.php.net/fix.php?id=38558r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=38558r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=38558r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=38558r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=38558r=dst IIS Stability:http://bugs.php.net/fix.php?id=38558r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=38558r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=38558r=float No Zend Extensions: http://bugs.php.net/fix.php?id=38558r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=38558r=mysqlcfg
#31979 [Bgs-Opn]: msql_fetch_field() not reporting unique keys
ID: 31979
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-15
New Comment:
Jani, you can do better than that. Are you saying you ran my test and
got the expected result? Or are you passing the buck?
Previous Comments:
[2005-06-07 00:24:32] [EMAIL PROTECTED]
Apparently the msql version you've compiled PHP does not set the field
properly.
[2005-02-15 05:26:25] danielc at analysisandsolutions dot com
Description:
One of the properties returned by msql_fetch_field() is unique. It
is supposed to contain 1 if the column in question is part of a unique
key and 0 if it's not. But it always returns 0.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT)', $con);
msql_query('CREATE UNIQUE INDEX bi ON blah (i)', $con);
$result = msql_query('SELECT * FROM blah', $con);
$info = msql_fetch_field($result);
print_r($info);
msql_query('DROP TABLE blah', $con);
Expected result:
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 1
[type] = int
)
Actual result:
--
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 0
[type] = int
)
--
Edit this bug report at http://bugs.php.net/?id=31979edit=1
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I also put together a patch for the PHP_4_3 branch:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.4_3.diff
It hasn't been tested, but looking at the source of the MySQL extension
makes me think it should work.
Though the script I put in the Reproduce code section above doesn't
test what happens with empty strings, I subsequently tested the
behavior and everything works fine.
Previous Comments:
[2005-02-15 02:36:44] danielc at analysisandsolutions dot com
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query(INSERT INTO blah VALUES (1, 'a'), $con);
msql_query(INSERT INTO blah VALUES (2, NULL), $con);
msql_query(INSERT INTO blah VALUES (NULL, 'c'), $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo \n;
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(2) {
[i]=
string(1) 2
[c]=
NULL
}
array(2) {
[a]=
NULL
[c]=
string(1) c
}
Actual result:
--
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(1) {
[i]=
string(1) 2
}
array(1) {
[c]=
string(1) c
}
--
Edit this bug report at http://bugs.php.net/?id=31960edit=1
#31960 [Opn]: PATCH: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
ID: 31960
User updated by: danielc at analysisandsolutions dot com
-Summary: msql_fetch_row() and msql_fetch_array() dropping
columns with NULL values
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: mSQL related
Operating System: NetBSD 2.0
PHP Version: 5CVS-2005-02-13 (dev)
New Comment:
I looked at the MySQL extension to see how they handled NULL values and
copied that into the mSQL extension. Here's the patch against head:
http://www.analysisandsolutions.com/php/php_msql.c.bug31960.diff
Works fine on my installation of 5.0.4-dev.
Previous Comments:
[2005-02-13 21:02:44] danielc at analysisandsolutions dot com
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that
contain NULL values. It's important to retrieve all data from a row,
even if it's NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to
watch out for items that have NULL/0/'' values, it doesn't exactly say
what the problem is and it only talks about results that have only one
column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query(INSERT INTO blah VALUES (1, 'a'), $con);
msql_query(INSERT INTO blah VALUES (2, NULL), $con);
msql_query(INSERT INTO blah VALUES (NULL, 'c'), $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo \n;
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(2) {
[i]=
string(1) 2
[c]=
NULL
}
array(2) {
[a]=
NULL
[c]=
string(1) c
}
Actual result:
--
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(1) {
[i]=
string(1) 2
}
array(1) {
[c]=
string(1) c
}
--
Edit this bug report at http://bugs.php.net/?id=31960edit=1
#31979 [NEW]: msql_fetch_field() not reporting unique keys
From: danielc at analysisandsolutions dot com
Operating system: NetBSD 2.0
PHP version: 5CVS-2005-02-15 (dev)
PHP Bug Type: mSQL related
Bug description: msql_fetch_field() not reporting unique keys
Description:
One of the properties returned by msql_fetch_field() is unique. It is
supposed to contain 1 if the column in question is part of a unique key
and 0 if it's not. But it always returns 0.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT)', $con);
msql_query('CREATE UNIQUE INDEX bi ON blah (i)', $con);
$result = msql_query('SELECT * FROM blah', $con);
$info = msql_fetch_field($result);
print_r($info);
msql_query('DROP TABLE blah', $con);
Expected result:
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 1
[type] = int
)
Actual result:
--
stdClass Object
(
[name] = i
[table] = blah
[not_null] = 0
[unique] = 0
[type] = int
)
--
Edit bug report at http://bugs.php.net/?id=31979edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31979r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31979r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31979r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31979r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31979r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31979r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31979r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31979r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31979r=support
Expected behavior: http://bugs.php.net/fix.php?id=31979r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31979r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31979r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31979r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31979r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31979r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31979r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31979r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31979r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31979r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31979r=mysqlcfg
#31960 [NEW]: msql_fetch_row() and msql_fetch_array() dropping columns with NULL values
From: danielc at analysisandsolutions dot com
Operating system: NetBSD 2.0
PHP version: 5CVS-2005-02-13 (dev)
PHP Bug Type: mSQL related
Bug description: msql_fetch_row() and msql_fetch_array() dropping columns with
NULL values
Description:
msql_fetch_row() and msql_fetch_array() silently drop columns that contain
NULL values. It's important to retrieve all data from a row, even if it's
NULL. oci8 does this just fine.
While there's a comment in the msql_fetch_array() documentation to watch
out for items that have NULL/0/'' values, it doesn't exactly say what the
problem is and it only talks about results that have only one column.
Reproduce code:
---
$con = msql_connect();
$db = msql_select_db('ptdb', $con);
msql_query('CREATE TABLE blah (i INT, c CHAR(5))', $con);
msql_query(INSERT INTO blah VALUES (1, 'a'), $con);
msql_query(INSERT INTO blah VALUES (2, NULL), $con);
msql_query(INSERT INTO blah VALUES (NULL, 'c'), $con);
$result = msql_query('SELECT * FROM blah', $con);
while ($arr = msql_fetch_array($result, MSQL_ASSOC)) {
var_dump($arr);
echo \n;
}
msql_query('DROP TABLE blah', $con);
Expected result:
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(2) {
[i]=
string(1) 2
[c]=
NULL
}
array(2) {
[a]=
NULL
[c]=
string(1) c
}
Actual result:
--
array(2) {
[i]=
string(1) 1
[c]=
string(1) a
}
array(1) {
[i]=
string(1) 2
}
array(1) {
[c]=
string(1) c
}
--
Edit bug report at http://bugs.php.net/?id=31960edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=31960r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=31960r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=31960r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=31960r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=31960r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=31960r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=31960r=needscript
Try newer version: http://bugs.php.net/fix.php?id=31960r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=31960r=support
Expected behavior: http://bugs.php.net/fix.php?id=31960r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=31960r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=31960r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=31960r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=31960r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=31960r=dst
IIS Stability: http://bugs.php.net/fix.php?id=31960r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=31960r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=31960r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=31960r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=31960r=mysqlcfg
#30690 [Bgs-Opn]: Resource handle from ibase_execute becomes invalid after return
ID: 30690
Updated by: [EMAIL PROTECTED]
Reported By: kobaz at kobaz dot net
-Status: Bogus
+Status: Open
Bug Type: InterBase related
Operating System: Linux 2.6.5
PHP Version: 4.3.9
New Comment:
While this behavior may be intentional on your part, I strongly request
it be changed.
1) No other DBMS extension in PHP does this.
2) This makes writing programs using ibase very difficult.
3) This makes it impossible to write abstraction packages, such as PEAR
DB (which I'm the lead of).
Previous Comments:
[2004-11-07 14:21:36] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
When $prepare goes out of scope, it is cleaned up along with all the
resources that depend on it. That includes any results that it
created.
[2004-11-05 02:16:40] kobaz at kobaz dot net
Description:
Resource handle from ibase_execute becomes invalid after return
Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');
function DB_PQuery ($sql, $data) {
global $conn;
$prepare = ibase_prepare($conn, $sql);
$result = ibase_execute($prepare, $data);
//$A = ibase_fetch_assoc($result); // uncommenting this will
show resource is valid here
//print_r($A);
// after this function returns, the return value is no longer a valid
resource
return $result;
}
$result = DB_PQuery(SELECT * FROM testing WHERE a = ?, '1');
$A = ibase_fetch_assoc($result); // fails with: invalid statement
handle
print_r($A);
Expected result:
The ibase_fetch_assoc should be successful after DB_PQuery returns.
Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can
be used with ibase_fetch_assoc successfully.
After DB_PQuery returns, the return value is not a valid resource
handle despite that nothing in the script has modified it.
--
Edit this bug report at http://bugs.php.net/?id=30690edit=1
#29733 [Com]: printf handles repeated placeholders wrong
ID: 29733
Comment by: danielc at analysisandsolutions dot com
Reported By: bugs dot php dot net at bluetwanger dot de
Status: Open
Bug Type:Strings related
PHP Version: 5.0.1
New Comment:
Note, the error only happens when mixing numbered and non-numberd
directives. Tweaking the example from the original bug report to use
only numbered directives eliminates the error:
printf('%1$s - %2$s %3$s %3$s %2$s', 1, 2, 3);
Previous Comments:
[2004-08-27 14:36:16] bugs dot php dot net at bluetwanger dot de
Here's a link:
http://www.bluetwanger.de/~mbertheau/formatted_print.c.patch
You make it really hard to submit a patch. This bug thing has no
provision for attaching a file and you have to strain a lot to get at
an email address of a developer mailing list.
[2004-08-27 14:30:33] bugs dot php dot net at bluetwanger dot de
Here's a patch:
--- ext/standard/formatted_print.c.orig 2004-07-18 19:28:04.0
+0200
+++ ext/standard/formatted_print.c 2004-08-27 14:23:07.580732341
+0200
@@ -537,12 +537,6 @@
php_sprintf_appendchar(result, outpos, size,
'%' TSRMLS_CC);
inpos += 2;
} else {
- if (currarg = argc format[inpos + 1] !=
'%') {
- efree(result);
- efree(args);
- php_error_docref(NULL TSRMLS_CC,
E_WARNING, Too few arguments);
- return NULL;
- }
/* starting a new format specifier, reset
variables */
alignment = ALIGN_RIGHT;
adjusting = 0;
@@ -574,13 +568,6 @@
argnum += format_offset;
- if (argnum = argc) {
- efree(result);
- efree(args);
- php_error_docref(NULL
TSRMLS_CC, E_WARNING, Too few arguments);
- return NULL;
- }
-
/* after argnum comes modifiers */
PRINTF_DEBUG((sprintf: looking for
modifiers\n
sprintf: now
looking at '%c', inpos=%d\n,
@@ -635,6 +622,13 @@
argnum = currarg++ + format_offset;
}
+if (argnum = argc) {
+efree(result);
+efree(args);
+php_error_docref(NULL TSRMLS_CC, E_WARNING, Too few
arguments);
+return NULL;
+}
+
if (format[inpos] == 'l') {
inpos++;
}
Let's see if the line breaks survive.
It basically removes the bogus (format[inpos + 1] != '%' will always be
true there) arg number check and moves the right one outside the special
case for complicated format specifiers.
[2004-08-18 14:46:41] bugs dot php dot net at bluetwanger dot de
Description:
printf('%s - %s %s %3$s %2$s', 1, 2, 3);
complains:
Warning: printf(): Too few arguments in /home/bertheau/printf.php on
line 2
printf('%s - %s %s %3$s %2$s', 1, 2, 3, 4);
does not complain and prints:
1 - 2 3 3 2
I expect the first version to not complain and print what the second
version prints.
--
Edit this bug report at http://bugs.php.net/?id=29733edit=1
#30184 [Bgs]: run-tests error_reporting / ~E_STRICT ignored in phpt files
ID: 30184
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Bogus
Bug Type: Unknown/Other Function
Operating System: Win 2000
PHP Version: 5CVS-2004-09-21 (dev)
New Comment:
Andi:
Thanks for the --INI-- tip.
Regarding your first email which said make sure that E_STRICT is
turned off in the INI, php.ini already had reporting set to E_ALL but
it's being ignored.
The reason I posted it as a bug was this issue seems to have only arose
in the recent past. This issue hadn't come up while I was developing DB
and HTML_Form even though I've been running snapshots of PHP 5 for a
long while.
Thanks again.
Previous Comments:
[2004-09-22 23:43:23] [EMAIL PROTECTED]
And you should use an --INI-- section in your test file for this
anyway.
[2004-09-22 23:04:31] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Certain E_STRICT notices (such as var being deprecated) are emited at
compile-time therefore changing the error_reporting (which only happens
at run-time) will not affect it. You will need to make sure that
E_STRICT is turned off in the INI. One work around for the tests might
be to put the source in an include file and change error_reporting
before we include it. This issue was discussed on internals@ a few
months back and this behavior was agreed on because some of these
E_STRICT issues have to be detected at compile-time.
[2004-09-21 23:34:25] danielc at analysisandsolutions dot com
Something else to take into consideration is run-tests.php is
overriding the error_reporting settings from php.ini. This is causing
tests to fail even though the same tests worked fine under development
versions of PHP 5.
Here's a new set of test scripts...
=== s.phpt
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
echo 'Default error_reporting in s.phpt: ' . error_reporting() . \n;
/*
* RESULT:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* The error_reporting in s.inc: 2047
* Subsequent error_reporting in s.phpt: 2047
*
* RESULT if error_reporting(E_ALL) is commented out:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.inc on line 6
* The error_reporting in s.inc: 4095
* Subsequent error_reporting in s.phpt: 4095
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
echo 'Subsequent error_reporting in s.phpt: ' . error_reporting() .
\n;
?
--EXPECT--
Default error_reporting in s.phpt: 2047
The error_reporting in s.inc: 2047
Subsequent error_reporting in s.phpt: 2047
=== s.inc
?php
echo 'The error_reporting in s.inc: ' . error_reporting() . \n;
class inc {
var $inc_var;
}
[2004-09-21 19:39:19] danielc at analysisandsolutions dot com
Description:
Using:
* PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26)
* run-tests.php version 1.195.2.1 or HEAD
When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings
still come up for code in the .phpt file. The notice isn't generated
for code in included files.
Reproduce code:
---
NOTE: two files...
=== s.phpt =
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
/*
* error_reporting(E_ALL) is ignored for the code
* in this file but not the included file.
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
?
--EXPECT--
=== s.inc =
?php
class inc {
var $inc_var;
}
Expected result:
Test to pass.
Actual result:
--
If error_reporting(E_ALL)
-
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
If error_reporting(E_ALL) commented out
---
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.inc on line 4
#30184 [NEW]: run-tests error_reporting / ~E_STRICT ignored in phpt files
From: danielc at analysisandsolutions dot com
Operating system: Win 2000
PHP version: 5CVS-2004-09-21 (dev)
PHP Bug Type: Unknown/Other Function
Bug description: run-tests error_reporting / ~E_STRICT ignored in phpt files
Description:
Using:
* PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26)
* run-tests.php version 1.195.2.1 or HEAD
When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings
still come up for code in the .phpt file. The notice isn't generated for
code in included files.
Reproduce code:
---
NOTE: two files...
=== s.phpt =
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
/*
* error_reporting(E_ALL) is ignored for the code
* in this file but not the included file.
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
?
--EXPECT--
=== s.inc =
?php
class inc {
var $inc_var;
}
Expected result:
Test to pass.
Actual result:
--
If error_reporting(E_ALL)
-
Strict Standards: var: Deprecated. Please use the public/private/protected
modifiers in s.php on line 12
If error_reporting(E_ALL) commented out
---
Strict Standards: var: Deprecated. Please use the public/private/protected
modifiers in s.php on line 12
Strict Standards: var: Deprecated. Please use the public/private/protected
modifiers in s.inc on line 4
--
Edit bug report at http://bugs.php.net/?id=30184edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=30184r=trysnapshot4
Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=30184r=trysnapshot50
Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=30184r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=30184r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=30184r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=30184r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=30184r=needscript
Try newer version: http://bugs.php.net/fix.php?id=30184r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=30184r=support
Expected behavior: http://bugs.php.net/fix.php?id=30184r=notwrong
Not enough info: http://bugs.php.net/fix.php?id=30184r=notenoughinfo
Submitted twice: http://bugs.php.net/fix.php?id=30184r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=30184r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=30184r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=30184r=dst
IIS Stability: http://bugs.php.net/fix.php?id=30184r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=30184r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=30184r=float
MySQL Configuration Error: http://bugs.php.net/fix.php?id=30184r=mysqlcfg
#30184 [Opn]: run-tests error_reporting / ~E_STRICT ignored in phpt files
ID: 30184
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Win 2000
PHP Version: 5CVS-2004-09-21 (dev)
New Comment:
Something else to take into consideration is run-tests.php is
overriding the error_reporting settings from php.ini. This is causing
tests to fail even though the same tests worked fine under development
versions of PHP 5.
Here's a new set of test scripts...
=== s.phpt
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
echo 'Default error_reporting in s.phpt: ' . error_reporting() . \n;
/*
* RESULT:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* The error_reporting in s.inc: 2047
* Subsequent error_reporting in s.phpt: 2047
*
* RESULT if error_reporting(E_ALL) is commented out:
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.php on line 28
* Default error_reporting in s.phpt: 4095
* Strict Standards: var: Deprecated. Please use the
* public/private/protected modifiers in s.inc on line 6
* The error_reporting in s.inc: 4095
* Subsequent error_reporting in s.phpt: 4095
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
echo 'Subsequent error_reporting in s.phpt: ' . error_reporting() .
\n;
?
--EXPECT--
Default error_reporting in s.phpt: 2047
The error_reporting in s.inc: 2047
Subsequent error_reporting in s.phpt: 2047
=== s.inc
?php
echo 'The error_reporting in s.inc: ' . error_reporting() . \n;
class inc {
var $inc_var;
}
Previous Comments:
[2004-09-21 19:39:19] danielc at analysisandsolutions dot com
Description:
Using:
* PHP 5.0.2RC1 (cli) (built: Sep 21 2004 10:29:26)
* run-tests.php version 1.195.2.1 or HEAD
When error_reporting is set to E_ALL in a .phpt file, E_STRICT warnings
still come up for code in the .phpt file. The notice isn't generated
for code in included files.
Reproduce code:
---
NOTE: two files...
=== s.phpt =
--TEST--
error_reporting ignored for code in phpt
--SKIPIF--
--FILE--
?php
/*
* error_reporting(E_ALL) is ignored for the code
* in this file but not the included file.
*/
error_reporting(E_ALL);
include './s.inc';
class phpt {
var $phpt_var;
}
?
--EXPECT--
=== s.inc =
?php
class inc {
var $inc_var;
}
Expected result:
Test to pass.
Actual result:
--
If error_reporting(E_ALL)
-
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
If error_reporting(E_ALL) commented out
---
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.php on line 12
Strict Standards: var: Deprecated. Please use the
public/private/protected modifiers in s.inc on line 4
--
Edit this bug report at http://bugs.php.net/?id=30184edit=1
#28999 [Opn]: exec()'s output array overwritten
ID: 28999
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: Unknown/Other Function
Operating System: Windows 2000
PHP Version: 5CVS-2004-07-03 (dev)
New Comment:
Curt Zirzow posted a patch for this to internals...
http://news.php.net/php.internals/10968
Previous Comments:
[2004-07-03 06:05:05] danielc at analysisandsolutions dot com
Description:
In PHP 4, when using exec() multiple times with the same array in the
output parameter, the data from subsequent exec() calls appended the
new results to the existing array. This is as the manual says.
When PHP 5 first came out, each call to exec() overwrote the prior
array. At some point a while ago, there was discussion on the list and
things were changed back to the old behavior.
At some point after that, the arrays started getting overwritten again.
Is this intentional?
I saw no notices about it in README.PHP4-TO-PHP5-THIN-CHANGES or in the
man page.
Can the old behavior be reimplemented in order to preserve
compatibility?
I made a post about this to internals:
http://marc.theaimsgroup.com/?l=php-devm=108874256229775w=2
Reproduce code:
---
?php
exec('date', $Return);
exec('date', $Return);
print_r($Return);
?
Expected result:
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
[2] = The current date is: Fri 07/02/2004
[3] = Enter the new date: (mm-dd-yy)
)
Actual result:
--
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
)
--
Edit this bug report at http://bugs.php.net/?id=28999edit=1
#28999 [NEW]: exec()'s output array overwritten
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 5CVS-2004-07-03 (dev)
PHP Bug Type: Unknown/Other Function
Bug description: exec()'s output array overwritten
Description:
In PHP 4, when using exec() multiple times with the same array in the
output parameter, the data from subsequent exec() calls appended the new
results to the existing array. This is as the manual says.
When PHP 5 first came out, each call to exec() overwrote the prior array.
At some point a while ago, there was discussion on the list and things
were changed back to the old behavior.
At some point after that, the arrays started getting overwritten again. Is
this intentional?
I saw no notices about it in README.PHP4-TO-PHP5-THIN-CHANGES or in the
man page.
Can the old behavior be reimplemented in order to preserve compatibility?
I made a post about this to internals:
http://marc.theaimsgroup.com/?l=php-devm=108874256229775w=2
Reproduce code:
---
?php
exec('date', $Return);
exec('date', $Return);
print_r($Return);
?
Expected result:
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
[2] = The current date is: Fri 07/02/2004
[3] = Enter the new date: (mm-dd-yy)
)
Actual result:
--
Array
(
[0] = The current date is: Fri 07/02/2004
[1] = Enter the new date: (mm-dd-yy)
)
--
Edit bug report at http://bugs.php.net/?id=28999edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28999r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28999r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28999r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28999r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28999r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28999r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28999r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28999r=support
Expected behavior: http://bugs.php.net/fix.php?id=28999r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28999r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28999r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28999r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28999r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28999r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28999r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28999r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28999r=float
#28912 [Fbk-Opn]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
ID: 28912 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: Documentation isn't involved. This is purely code. The type property returned from the function != the value of the constant. Perhaps your getting the right result is due to both of us running different versions of the software? Here's what I'm on: MySQL: Ver 14.5 Distrib 4.1.2-alpha, for Win95/Win98 (i32) PHP:PHP 5.0.0-dev (cli) (built: Jun 28 2004 16:29:27) Previous Comments: [2004-06-28 18:51:13] [EMAIL PROTECTED] Looks like a documentation problem. However I couldn't find this in documentation. Also the example output in mysqli_fetch_field returns 254. Could you please give me a link to the wrong documentation? [2004-06-24 18:50:07] danielc at analysisandsolutions dot com Description: The type value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db-connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n; mysqli_query($db-connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit this bug report at http://bugs.php.net/?id=28912edit=1
#28912 [Bgs-Opn]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
ID: 28912 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: MySQL related Operating System: Windows 2000 PHP Version: 5CVS-2004-06-24 (dev) New Comment: Ah. Thanks for the clarification. Then phpdoc/en/reference/mysqli/constants.xml needs updating. You said: varchar column definition returns MYSQLI_TYPE_VAR_STRING, char column definition returns MYSQLI_TYPE_STRING. Though the docs say: MYSQLI_TYPE_STRING (integer) Field is defined as VARCHAR MYSQLI_TYPE_CHAR (integer) Field is defined as CHAR BUT, not so fast... CHAR columns return 253, but MYSQLI_TYPE_STRING's value is 254. And MYSQLI_TYPE_CHAR is defined, but what's it for? ?php mysqli_query($db-connection, 'CREATE TABLE bar (Vf VARCHAR(5),' . ' Cf CHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Vf, Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo $tmp-name type found = $tmp-type\n; echo 'MYSQLI_TYPE_VAR_STRING = ' . MYSQLI_TYPE_VAR_STRING . \n\n; $tmp = mysqli_fetch_field($r); echo $tmp-name type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n\n; echo So, what's this for?...\n; echo 'MYSQLI_TYPE_CHAR = ' . MYSQLI_TYPE_CHAR . \n; mysqli_query($db-connection, 'DROP TABLE bar'); ? vvv OUTPUT Vf type found = 253 MYSQLI_TYPE_VAR_STRING = 253 Cf type found = 253 MYSQLI_TYPE_STRING = 254 So, what's this for?... MYSQLI_TYPE_CHAR = 1 ^^^ Previous Comments: [2004-06-28 23:48:20] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php varchar column definition returns MYSQLI_TYPE_VAR_STRING, char column definition returns MYSQLI_TYPE_STRING. [2004-06-28 19:35:22] danielc at analysisandsolutions dot com Documentation isn't involved. This is purely code. The type property returned from the function != the value of the constant. Perhaps your getting the right result is due to both of us running different versions of the software? Here's what I'm on: MySQL: Ver 14.5 Distrib 4.1.2-alpha, for Win95/Win98 (i32) PHP:PHP 5.0.0-dev (cli) (built: Jun 28 2004 16:29:27) [2004-06-28 18:51:13] [EMAIL PROTECTED] Looks like a documentation problem. However I couldn't find this in documentation. Also the example output in mysqli_fetch_field returns 254. Could you please give me a link to the wrong documentation? [2004-06-24 18:50:07] danielc at analysisandsolutions dot com Description: The type value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db-connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n; mysqli_query($db-connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit this bug report at http://bugs.php.net/?id=28912edit=1
#28912 [NEW]: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-06-24 (dev) PHP Bug Type: MySQL related Bug description: MYSQLI_TYPE_STRING != mysqli_fetch_field() type for VARCHAR column Description: The type value returned from mysqli_fetch_field() for a VARCHAR field is 253. The manual says the constant for VARCHAR fields is MYSQLI_TYPE_STRING which has a value of 254. So, there's no way to determine column types via constants for VARCHAR's. Reproduce code: --- mysqli_query($db-connection, 'CREATE TABLE bar (Cf VARCHAR(5))'); $r = mysqli_query($db-connection, 'SELECT Cf FROM bar'); $tmp = mysqli_fetch_field($r); echo type found = $tmp-type\n; echo 'MYSQLI_TYPE_STRING = ' . MYSQLI_TYPE_STRING . \n; mysqli_query($db-connection, 'DROP TABLE bar'); Expected result: type found = 254 MYSQLI_TYPE_STRING = 254 Actual result: -- type found = 253 MYSQLI_TYPE_STRING = 254 -- Edit bug report at http://bugs.php.net/?id=28912edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28912r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28912r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28912r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28912r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28912r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28912r=needscript Try newer version: http://bugs.php.net/fix.php?id=28912r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28912r=support Expected behavior: http://bugs.php.net/fix.php?id=28912r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28912r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28912r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28912r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28912r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28912r=dst IIS Stability: http://bugs.php.net/fix.php?id=28912r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28912r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28912r=float
#28732 [NEW]: temp and tmp environment vars not registered via web
From: danielc at analysisandsolutions dot com
Operating system: windows 2000
PHP version: 4.3.7
PHP Bug Type: *General Issues
Bug description: temp and tmp environment vars not registered via web
Description:
Neither the TEMP or TMP environment variables show up via $_ENV, $_SERVER,
getenv() or phpinfo() when accessing scripts via a webserver (Apache
1.3.28). They're available when executing scripts via the command line
(both CGI and CLI).
FYI:
C:\PROGRA~1echo %temp%
C:\TEMP
C:\PROGRA~1echo %tmp%
C:\TEMP
Reproduce code:
---
?php
echo 'TEMP: ' . getenv('TEMP') . \n;
echo 'temp: ' . getenv('temp') . \n;
echo 'TMP: ' . getenv('TMP') . \n;
echo 'tmp: ' . getenv('tmp') . \n;
?
Expected result:
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
Actual result:
--
=== Via web server ===
TEMP:
temp:
TMP:
tmp:
=== Via command line ===
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
--
Edit bug report at http://bugs.php.net/?id=28732edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28732r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28732r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=28732r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=28732r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=28732r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=28732r=needscript
Try newer version: http://bugs.php.net/fix.php?id=28732r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=28732r=support
Expected behavior: http://bugs.php.net/fix.php?id=28732r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=28732r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=28732r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=28732r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28732r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=28732r=dst
IIS Stability: http://bugs.php.net/fix.php?id=28732r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=28732r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=28732r=float
#28732 [Opn]: temp and tmp environment vars not registered via web
ID: 28732
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: *General Issues
Operating System: windows 2000
PHP Version: 4.3.7
New Comment:
Just to be 100% clear, PHP executes via CGI on the web server.
Previous Comments:
[2004-06-10 20:16:21] danielc at analysisandsolutions dot com
Description:
Neither the TEMP or TMP environment variables show up via $_ENV,
$_SERVER, getenv() or phpinfo() when accessing scripts via a webserver
(Apache 1.3.28). They're available when executing scripts via the
command line (both CGI and CLI).
FYI:
C:\PROGRA~1echo %temp%
C:\TEMP
C:\PROGRA~1echo %tmp%
C:\TEMP
Reproduce code:
---
?php
echo 'TEMP: ' . getenv('TEMP') . \n;
echo 'temp: ' . getenv('temp') . \n;
echo 'TMP: ' . getenv('TMP') . \n;
echo 'tmp: ' . getenv('tmp') . \n;
?
Expected result:
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
Actual result:
--
=== Via web server ===
TEMP:
temp:
TMP:
tmp:
=== Via command line ===
TEMP: C:\TEMP
temp: C:\TEMP
TMP: C:\TEMP
tmp: C:\TEMP
--
Edit this bug report at http://bugs.php.net/?id=28732edit=1
#28478 [NEW]: won't build: 'convert_scalar_to_number' : too few actual parameters
From: danielc at analysisandsolutions dot com Operating system: win PHP version: 4CVS-2004-05-21 (stable) PHP Bug Type: Sybase-ct (ctlib) related Bug description: won't build: 'convert_scalar_to_number' : too few actual parameters Description: I downloaded the latest PHP 4 windows snapshot and found php_sybase_ct.dll isn't in the extensions directory. The compile log shows... Compiling... php_sybase_ct.c c:\php4build\snap\ext\sybase_ct\php_sybase_ct.c(1136) : error C2198: 'convert_scalar_to_number' : too few actual parameters (from http://snaps.php.net/win32/compile-STABLE.log) -- Edit bug report at http://bugs.php.net/?id=28478edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28478r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28478r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28478r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28478r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28478r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28478r=needscript Try newer version: http://bugs.php.net/fix.php?id=28478r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28478r=support Expected behavior: http://bugs.php.net/fix.php?id=28478r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28478r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28478r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28478r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28478r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28478r=dst IIS Stability: http://bugs.php.net/fix.php?id=28478r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28478r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28478r=float
#28354 [Com]: sybase_free_result crash
ID: 28354
Comment by: danielc at analysisandsolutions dot com
Reported By: alahaye at fmlogistic dot com
Status: Open
Bug Type: Sybase-ct (ctlib) related
Operating System: Linux RadHat 7
PHP Version: 4.3.6
New Comment:
I'm experienceing this on Windows builds as well. The problem arose
some time between these two snapshots:
works php4-win32-STABLE-200401210130
crashes php4-win32-STABLE-200402161330
Previous Comments:
[2004-05-19 13:55:05] alahaye at fmlogistic dot com
Here the backtrace
(gdb) bt
#0 0x40ba7df0 in chunk_free (ar_ptr=0x40c50f00, p=0x8436518) at
malloc.c:3131
#1 0x40ba7d59 in __libc_free (mem=0x84368e8) at malloc.c:3054
#2 0x0816ed49 in shutdown_memory_manager (silent=0, clean_cache=0) at
/users/sources/php/php-4.3.6/Zend/zend_alloc.c:492
#3 0x08154c44 in php_request_shutdown (dummy=0x0) at
/users/sources/php/php-4.3.6/main/main.c:1003
#4 0x0819870d in main (argc=2, argv=0xb70c) at
/users/sources/php/php-4.3.6/sapi/cli/php_cli.c:873
#5 0x40b44177 in __libc_start_main (main=0x8197bd4 main, argc=2,
ubp_av=0xb70c, init=0x8086330 _init, fini=0x82500c0 _fini,
rtld_fini=0x4000e184 _dl_fini, stack_end=0xb6fc) at
../sysdeps/generic/libc-start.c:129
[2004-05-18 01:00:03] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2004-05-11 14:01:18] sergio dot zia at saipm dot com
I am encountering exactly the same problem :-(
Linux RedHat AS 2.1
PHP 4.3.6
[2004-05-10 22:55:49] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2004-05-10 22:28:19] alahaye at fmlogistic dot com
Description:
When using sybase_free_result, apache Segmentation fault.
PB doesn't exist with PHP 4.3.4.
Reproduce code:
---
?
$query = EXEC MyPROC;
$id = sybase_connect(SERVER,LOGIN,PASSWORD);
sybase_select_db(BASE,$id);
$result = sybase_query($query,$id);
While ($row = sybase_fetch_row ($result))
{
print $row[0].BR;
}
sybase_free_result($result);
sybase_close($id);
?
Expected result:
result of stored procedure
--
Edit this bug report at http://bugs.php.net/?id=28354edit=1
#28229 [NEW]: PATCH run-tests tripped up by spaces in names
From: danielc at analysisandsolutions dot com Operating system: Windows PHP version: 5CVS-2004-04-30 (dev) PHP Bug Type: Unknown/Other Function Bug description: PATCH run-tests tripped up by spaces in names Description: While running tests on my Windows machine I ran into a problem with run-tests.php. .phpt files which have spaces in their names/paths cause the tests to fail. The .out file contains text along the lines of Could not open C:\Programs As you can guess, the .phpt files were in a subdirectory of c:\program files\. The following patch places quotes around the file names when creating the $cmd: http://www.analysisandsolutions.com/php/run-tests.spaceinfilename.diff -- Edit bug report at http://bugs.php.net/?id=28229edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=28229r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=28229r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=28229r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=28229r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=28229r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=28229r=needscript Try newer version: http://bugs.php.net/fix.php?id=28229r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=28229r=support Expected behavior: http://bugs.php.net/fix.php?id=28229r=notwrong Not enough info:http://bugs.php.net/fix.php?id=28229r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=28229r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=28229r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=28229r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=28229r=dst IIS Stability: http://bugs.php.net/fix.php?id=28229r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=28229r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=28229r=float
#25987 [Com]: php and xml tag confusion
ID: 25987 Comment by: danielc at analysisandsolutions dot com Reported By: tkwright_233 at hotmail dot com Status: Bogus Bug Type: Scripting Engine problem Operating System: * PHP Version: * New Comment: This needlessly causes problems for users. It would be nice to fix it, please. tkwright_233 seems on target when they say: PHP knows the diffrence of '?=' from '?'. so why can't it detect the diffrence of '?' from '?xml'? Thanks. Previous Comments: [2003-11-04 17:09:53] tkwright_233 at hotmail dot com what just happened? it appears some comments were lost(about 2-4). __ Anyway, it DOES know the diffrence of '?=' from '?'. so why can't it detect the diffrence of '?' from '?xml'? And, according to my brain, and museum.php.net, the deafult opining tag was changed from '?' to ?php' partially for this reason(and the closing tag from '' to '?'), from v.2 to v.4 . [2003-10-26 15:24:32] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php It does recognize the difference, if you disable short_tags, which you should for exactly this reason. [2003-10-25 15:18:05] [EMAIL PROTECTED] Short tags = '?'. That matches '?php' as well as '?=' or '?xml'. [2003-10-25 14:13:23] tkwright_233 at hotmail dot com Description: when an xml 'starting' tag is placed on an document, php confuses it with its opining and closing tag. it confuses its closing tag with xml end of the tag, and php confuses the open tag for php with the start of the tag declaring an xml document. Parse error: parse error, unexpected T_STRING in c:/apache/htdocs/xml.php on line 1 currently, the workaround is: ?php echo''.'?'.'x'.'m'.'l vers'.'ion=1'.'.'.'0'.' en'.'codi'.'ng=UT'.'F-8'.''.'?'.''.\n;? Reproduce code: --- ?xml version=1.0 encoding=UTF-8? Expected result: [no error],rest of page Actual result: -- Parse error: parse error, unexpected T_STRING in c:/apache/htdocs/xml.php on line 1 -- Edit this bug report at http://bugs.php.net/?id=25987edit=1
#27368 [NEW]: php.ini-(dist|recommended) have CR at end
From: danielc at analysisandsolutions dot com Operating system: Windows 2000 PHP version: 5CVS-2004-02-23 (dev) PHP Bug Type: *Configuration Issues Bug description: php.ini-(dist|recommended) have CR at end Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit bug report at http://bugs.php.net/?id=27368edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27368r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27368r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27368r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27368r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27368r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27368r=needscript Try newer version: http://bugs.php.net/fix.php?id=27368r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27368r=support Expected behavior: http://bugs.php.net/fix.php?id=27368r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27368r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27368r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27368r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27368r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27368r=dst IIS Stability: http://bugs.php.net/fix.php?id=27368r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27368r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27368r=float
#27368 [Bgs-Opn]: php.ini-(dist|recommended) have CR at end
ID: 27368 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: *Configuration Issues Operating System: Windows 2000 PHP Version: 5CVS-2004-02-23 (dev) New Comment: Where were you looking? In CVS or in the files distributed in a php5-win32-200402231530 snapshot? They are definitely there in the snapshot. I can email you the files if you don't believe me. This may be due to the new build system, which when it went into effect threw in loads of CR's even though the raw files in CVS were fine. I posted a note to internals and it seems someone fixed something to make all but one of the CR's disappeared. Previous Comments: [2004-02-23 13:17:01] [EMAIL PROTECTED] In CVS: ; tab-width: 4 ; End: (there is no CR there) [2004-02-23 12:23:31] danielc at analysisandsolutions dot com Description: Minor problem... The php.ini-dist and php.ini-recommended files in the latest Windows snapshot (php5-win32-200402231530) are in Unix format, but have a CR thrown in at the end of each file: ... snip ... ; tab-width: 4 ; End ^ here -- Edit this bug report at http://bugs.php.net/?id=27368edit=1
#27123 [NEW]: casting arrays to objects and back
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000 and OS X 10.3
PHP version: 5CVS-2004-02-03 (dev)
PHP Bug Type: Reproducible crash
Bug description: casting arrays to objects and back
Description:
Found PEAR DB's getAssoc() method didn't work correctly when in
DB_FETCHMODE_OBJECT mode. See pear/DB/tests/18get.phpt for that.
I pared it down a bit and then Adam Trachtenberg whittled it down even
farther. Here's what he found:
1) Use an array with a string key: array('a' = 1)
2) Cast it to an object and call get_object_vars()
on the result.
3) Assign this cast object to an array with
multiple elements.
4) Call print_r() on the resulting array.
If I remove any of these, the crash goes away.
Reproduce code:
---
?php
$array = array(1);
$element = (object) array('a' = 1);
get_object_vars($element);
$array[] = $element;
print_r($array);
?
Expected result:
Array
(
[0] = 1
[1] = stdClass Object
(
[a] = 1
)
)
Actual result:
--
~ WINDOWS 2000 ~
Array
(
[0] = 1
[1] = stdClass Object
(
[a] = 1130656883
)
)
~ OS X 10.3, PHP = beta 3 ~
No Output.
~ OS X 10.3, PHP = recent CVS ~
Array
(
[0] = 1
[2] = stdClass Object
(
[a] =
... backtrace ...
#0 0x00271308 in _zend_is_inconsistent (ht=0x5a5a5a5a, file=0x3183f8
/usr/local/cvs/php/php-src/Zend/zend_hash.c, line=504) at
/usr/local/cvs/php/php-src/Zend/zend_hash.c:53
#1 0x00273384 in zend_hash_destroy (ht=0x5a5a5a5a) at
/usr/local/cvs/php/php-src/Zend/zend_hash.c:504
#2 0x002658a8 in _zval_dtor (zvalue=0xbfffe710, __zend_filename=0x3178bc
/usr/local/cvs/php/php-src/Zend/zend_operators.c, __zend_lineno=510) at
/usr/local/cvs/php/php-src/Zend/zend_variables.c:52
#3 0x0025d240 in _convert_to_string (op=0xbfffe710,
__zend_filename=0x317b5c /usr/local/cvs/php/php-src/Zend/zend.c,
__zend_lineno=256) at
/usr/local/cvs/php/php-src/Zend/zend_operators.c:510
#4 0x0026691c in zend_make_printable_zval (expr=0xace8d0,
expr_copy=0xbfffe710, use_copy=0xbfffe720) at
/usr/local/cvs/php/php-src/Zend/zend.c:256
#5 0x002669dc in zend_print_zval_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xace8d0, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:275
#6 0x00266984 in zend_print_zval (expr=0xace8d0, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:266
#7 0x00265d24 in zend_print_variable (var=0xace8d0) at
/usr/local/cvs/php/php-src/Zend/zend_variables.c:171
#8 0x00267094 in zend_print_zval_r_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xace8d0, indent=16) at
/usr/local/cvs/php/php-src/Zend/zend.c:387
#9 0x00266dc8 in zend_print_zval_r (expr=0xace8d0, indent=16) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#10 0x002662c8 in print_hash (ht=0xace860, indent=12, is_object=1 '\001')
at /usr/local/cvs/php/php-src/Zend/zend.c:159
#11 0x00267074 in zend_print_zval_r_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xacea48, indent=8) at
/usr/local/cvs/php/php-src/Zend/zend.c:381
#12 0x00266dc8 in zend_print_zval_r (expr=0xacea48, indent=8) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#13 0x002662c8 in print_hash (ht=0xacde60, indent=4, is_object=0 '\0') at
/usr/local/cvs/php/php-src/Zend/zend.c:159
#14 0x00266ed4 in zend_print_zval_r_ex (write_func=0x208fa0
php_body_write_wrapper, expr=0xacc538, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:356
#15 0x00266dc8 in zend_print_zval_r (expr=0xacc538, indent=0) at
/usr/local/cvs/php/php-src/Zend/zend.c:342
#16 0x00165a10 in zif_print_r (ht=1, return_value=0xacea98, this_ptr=0x0,
return_value_used=0) at
/usr/local/cvs/php/php-src/ext/standard/basic_functions.c:2570
#17 0x0029d5ac in zend_do_fcall_common_helper (execute_data=0xbfffecb0,
op_array=0xacdda8) at /usr/local/cvs/php/php-src/Zend/zend_execute.c:2550
#18 0x0029dff4 in zend_do_fcall_handler (execute_data=0xbfffecb0,
op_array=0xacdda8) at /usr/local/cvs/php/php-src/Zend/zend_execute.c:2697
#19 0x00297a20 in execute (op_array=0xacdda8) at
/usr/local/cvs/php/php-src/Zend/zend_execute.c:1264
#20 0x002689bc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
at /usr/local/cvs/php/php-src/Zend/zend.c:1051
#21 0x00209bf8 in php_execute_script (primary_file=0xb720) at
/usr/local/cvs/php/php-src/main/main.c:1641
#22 0x002aac60 in main (argc=2, argv=0xbc94) at
/usr/local/cvs/php/php-src/sapi/cli/php_cli.c:939
--
Edit bug report at http://bugs.php.net/?id=27123edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27123r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27123r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=27123r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=27123r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=27123r=needtrace
Need
#26206 [Opn-Dup]: argv and argc not defined
ID: 26206
Updated by: [EMAIL PROTECTED]
Reported By: danielc at analysisandsolutions dot com
-Status: Open
+Status: Duplicate
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
In the current thread, Jani pointed out that this is related to bug
25724 -- http://bugs.php.net/bug.php?id=25724 -- which
says that when register_long_arrays is off, the superglobals are
broken.
So, until that bug is fixed, turn register_long_arrays = On in php.ini
to get $_SERVER['argv'] and $_SERVER['argc'] to work.
Previous Comments:
[2004-01-17 19:44:43] danielc at analysisandsolutions dot com
Here's a link to the discussion on the interals list back in October
about these changes:
http://marc.theaimsgroup.com/?t=10650930736r=1w=2
This is a link to the current discussion regarding the situation and
how either I'm misunderstanding things or things may not be working as
expected:
http://marc.theaimsgroup.com/?t=10743658311r=1w=2
[2004-01-17 14:17:35] danielc at analysisandsolutions dot com
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
?php
var_dump($argv);
var_dump($_SERVER['argv']);
?
INVOCATION:
C:\PROGRA~1\phpphp argvtest.php 1 2
OUTPUT:
array(3) {
[0]=
string(12) argvtest.php
[1]=
string(1) 1
[2]=
string(1) 2
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
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/26206
--
Edit this bug report at http://bugs.php.net/?id=26206edit=1
#25724 [Com]: register_long_arrays breaks superglobals
ID: 25724 Comment by: danielc at analysisandsolutions dot com Reported By: kauer at face-online dot de Status: Verified Bug Type: Zend Engine 2 problem Operating System: * PHP Version: 5CVS-2004-01-03 New Comment: Bug 26206 -- http://bugs.php.net/bug.php?id=26206 -- has been marked as a duplicate of this one. Previous Comments: [2004-01-21 02:05:14] [EMAIL PROTECTED] And both register_globals and register_long_arrays have to be off to reproduce this! [2004-01-21 02:03:44] [EMAIL PROTECTED] Only these superglobals are broken: $_SERVER $_ENV $_REQUEST All other work fine.. [2003-11-28 21:20:42] [EMAIL PROTECTED] Reproducable with this quick'n'dirty way too: # sapi/cli/php -d'register_long_arrays=off' -r 'var_dump($_SERVER);' [2003-10-02 04:55:56] kauer at face-online dot de Description: Using the binary from snaps.php.net, turning register_long_arrays off in .htaccess will make $_SERVER unavailable. Reproduce code: --- File: .htaccess php_flag register_long_arrays off PHP: var_dump($_SERVER); Expected result: I expect to see a variable dump of $_SERVER. Actual result: -- var_dump outputs NULL -- Edit this bug report at http://bugs.php.net/?id=25724edit=1
#26206 [Opn]: argv and argc not defined
ID: 26206
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
?php
var_dump($argv);
var_dump($_SERVER['argv']);
?
INVOCATION:
C:\PROGRA~1\phpphp argvtest.php 1 2
OUTPUT:
array(3) {
[0]=
string(12) argvtest.php
[1]=
string(1) 1
[2]=
string(1) 2
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
Previous Comments:
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
[2003-12-01 13:31:20] [EMAIL PROTECTED]
Well, I can't reproduce this with either CLI or CGI, using either
php.ini-dist or php.ini-recommended. So there's something wrong with
your system, not PHP.
[2003-12-01 12:04:35] danielc at analysisandsolutions dot com
100% certain.
New PHP installs on this system are by moving the entirety of the old
install aside, extracting the contents of a new snapshot .zip file then
copying the exact files/structure over to the php directory. The
system finds the DLLS via the %path%, in which
C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries.
The PHP DLL's have never been copied to any other location on this
computer.
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/26206
--
Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Opn]: argv and argc not defined
ID: 26206
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: CGI related
Operating System: Windows 2000
PHP Version: 5CVS-2004-01-08
New Comment:
Here's a link to the discussion on the interals list back in October
about these changes:
http://marc.theaimsgroup.com/?t=10650930736r=1w=2
This is a link to the current discussion regarding the situation and
how either I'm misunderstanding things or things may not be working as
expected:
http://marc.theaimsgroup.com/?t=10743658311r=1w=2
Previous Comments:
[2004-01-17 14:17:35] danielc at analysisandsolutions dot com
Greg just posted on the internals list that he too noticed that
$_SERVER['argv'] and $_SERVER['argc'] aren't set.
He also made a very interesting observation that $argv and $argc ARE
set.
EXAMPLE SCRIPT argvtest.php:
?php
var_dump($argv);
var_dump($_SERVER['argv']);
?
INVOCATION:
C:\PROGRA~1\phpphp argvtest.php 1 2
OUTPUT:
array(3) {
[0]=
string(12) argvtest.php
[1]=
string(1) 1
[2]=
string(1) 2
}
Notice: Undefined index: argv in C:\PROGRA~1\php\argvtest.php on line
3
NULL
[2004-01-08 13:14:25] danielc at analysisandsolutions dot com
No dice using php5-win32-200401081130
[2004-01-07 21:38:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Please try the latest snapshot.
[2003-12-01 13:57:39] danielc at analysisandsolutions dot com
Everything worked fine until I switched from
php5-win32-200310010230.zip to php5-win32-200311040330.zip
I will track down exactly which snapshot in this time period started
causing the problem. Then someone can examine the changes made in
order to isolate the problem.
Please inform me where I can find old snapshots to do this.
http://snaps.php.net/win32/ only has the most recent few.
[2003-12-01 13:31:20] [EMAIL PROTECTED]
Well, I can't reproduce this with either CLI or CGI, using either
php.ini-dist or php.ini-recommended. So there's something wrong with
your system, not PHP.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/26206
--
Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: No dice using php5-win32-200401081130 Previous Comments: [2004-01-07 21:38:51] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip Please try the latest snapshot. [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26791 [Opn]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Know what? The problem was where the ini_set() calls are made. They
must be done BEFORE the connection is established. Once it's made, it
can't be changed.
Oddly, it doesn't matter when one calls ini_set() for
mssql.datetimeconvert.
So, I'm not sure this bug report should be closed, called bogus or not.
It might be nice to have these work regardless of where they are
called. If no change is made, the behavior needs to be documented.
Couple things to keep in mind about my config:
Using CGI
Loading mssql via php.ini extensions
Versions 4.3.4 and php5-win32-200401081130 snapshot
Previous Comments:
[2004-01-08 00:12:28] [EMAIL PROTECTED]
This seams to be related to how the extension is loaded.
ini_set() works fine in php4 whn the extension is loaded from php.ini,
but not when dl() is used.
The dl() will also cause the output from phpinfo() to be incomplete!
[2004-01-06 18:56:04] [EMAIL PROTECTED]
Frank, nothing has changed in that function. Are you sure this really
works with PHP 5..?
[2004-01-05 02:44:12] [EMAIL PROTECTED]
This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did
something happen to the ini_set() funtion ?
[2004-01-05 01:34:58] danielc at analysisandsolutions dot com
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no
feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit this bug report at http://bugs.php.net/?id=26791edit=1
#26791 [Bgs]: mssql.textlimit and mssql.textsize can't be set via ini_set()
ID: 26791 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com Status: Bogus Bug Type: MSSQL related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: Sniper: Don't be so dismissive. Most ini_set()'s work just fine regardless of when they're called. Sessions aren't a good example because all of the session stuff has to be processed before any output. If the team doesn't want to spend time fixing this, please turn this into a documentation bug for ref.mssql.php, where a note should be made about the need to set these before connecting to a db. Previous Comments: [2004-01-08 23:21:09] [EMAIL PROTECTED] Of course the ini_set() has to be called before anything else is what might be using the setting. (this is the case for ANY setting, not just these mssql.* settings, see e.g. session stuff for examples) [2004-01-08 13:51:48] danielc at analysisandsolutions dot com Know what? The problem was where the ini_set() calls are made. They must be done BEFORE the connection is established. Once it's made, it can't be changed. Oddly, it doesn't matter when one calls ini_set() for mssql.datetimeconvert. So, I'm not sure this bug report should be closed, called bogus or not. It might be nice to have these work regardless of where they are called. If no change is made, the behavior needs to be documented. Couple things to keep in mind about my config: Using CGI Loading mssql via php.ini extensions Versions 4.3.4 and php5-win32-200401081130 snapshot [2004-01-08 00:12:28] [EMAIL PROTECTED] This seams to be related to how the extension is loaded. ini_set() works fine in php4 whn the extension is loaded from php.ini, but not when dl() is used. The dl() will also cause the output from phpinfo() to be incomplete! [2004-01-06 18:56:04] [EMAIL PROTECTED] Frank, nothing has changed in that function. Are you sure this really works with PHP 5..? [2004-01-05 02:44:12] [EMAIL PROTECTED] This works in PHP5 but not in PHP4.3.x (tested on the cvs version). Did something happen to the ini_set() funtion ? 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/26791 -- Edit this bug report at http://bugs.php.net/?id=26791edit=1
#26799 [Fbk-Opn]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Interesting. The query produces both a result and an error. I now see
that's how mssql intentionally operates.
By the way... mssql_min_error_severity() didn't change anything. But,
setting mssql_min_message_severity() to 0 caused a PHP warning on the
mssql_query() call.
Sample script:
--
$c = mssql_connect('localhost', 'sa', 'pw');
for ($Counter = 0; $Counter 17; $Counter++) {
//mssql_min_error_severity($Counter);
mssql_min_message_severity($Counter);
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo ' E: ' . mssql_get_last_message();
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
echo ' R: ' . gettype($ar['FOO']);
echo ' C: ' . $Counter;
echo 'br /';
}
Output:
---
Warning: mssql_query(): message: Division by zero occurred. (severity
0) in...
E: Division by zero occurred. R: NULL C: 0
... snipped similar output for brevity ...
E: Division by zero occurred. R: NULL C: 16
Previous Comments:
[2004-01-06 18:38:27] [EMAIL PROTECTED]
Try this script:
?php
error_reporting(E_ALL);
$c = mssql_connect('localhost', 'sa', 'pw');
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo mssql_get_last_message();
?
See also:
http://www.php.net/manual/en/function.mssql-min-error-severity.php
I think this is not really bug as is..the query doesn't actually
'fail'..
[2004-01-05 16:52:37] danielc at analysisandsolutions dot com
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
[2004-01-05 16:45:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799edit=1
#26799 [Opn-Csd]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Open
+Status: Closed
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Close it.
Previous Comments:
[2004-01-06 23:27:16] danielc at analysisandsolutions dot com
Interesting. The query produces both a result and an error. I now see
that's how mssql intentionally operates.
By the way... mssql_min_error_severity() didn't change anything. But,
setting mssql_min_message_severity() to 0 caused a PHP warning on the
mssql_query() call.
Sample script:
--
$c = mssql_connect('localhost', 'sa', 'pw');
for ($Counter = 0; $Counter 17; $Counter++) {
//mssql_min_error_severity($Counter);
mssql_min_message_severity($Counter);
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo ' E: ' . mssql_get_last_message();
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
echo ' R: ' . gettype($ar['FOO']);
echo ' C: ' . $Counter;
echo 'br /';
}
Output:
---
Warning: mssql_query(): message: Division by zero occurred. (severity
0) in...
E: Division by zero occurred. R: NULL C: 0
... snipped similar output for brevity ...
E: Division by zero occurred. R: NULL C: 16
[2004-01-06 18:38:27] [EMAIL PROTECTED]
Try this script:
?php
error_reporting(E_ALL);
$c = mssql_connect('localhost', 'sa', 'pw');
$result = mssql_query('SELECT 0/0 AS FOO', $c);
echo mssql_get_last_message();
?
See also:
http://www.php.net/manual/en/function.mssql-min-error-severity.php
I think this is not really bug as is..the query doesn't actually
'fail'..
[2004-01-05 16:52:37] danielc at analysisandsolutions dot com
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
[2004-01-05 16:45:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799edit=1
#26206 [NoF-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: No Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Sorry I didn't reply sooner. Situation still exists as of 500rc1-dev--php5-win32-200401022330. I still working on getting the build environment to function properly so I can determine when the change happened. Previous Comments: [2004-01-06 20:53:16] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2004-01-01 21:08:24] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2003-12-02 00:31:23] danielc at analysisandsolutions dot com Yes. Works fine with php4-win32-STABLE-200312020130.zip Are the old PHP5 snapshots available anywhere? I'll be glad to track down when this problem started. [2003-12-02 00:12:38] [EMAIL PROTECTED] Does PHP 4 snapshots work? [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26799 [NEW]: divide by zero errors not reported
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: divide by zero errors not reported
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit bug report at http://bugs.php.net/?id=26799edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26799r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26799r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26799r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26799r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26799r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26799r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26799r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26799r=support
Expected behavior: http://bugs.php.net/fix.php?id=26799r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26799r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26799r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26799r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26799r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26799r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26799r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26799r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26799r=float
#26799 [Bgs-Opn]: divide by zero errors not reported
ID: 26799
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Bogus
+Status: Open
Bug Type: MSSQL related
Operating System: Windows 2000
PHP Version: 4.3.4
New Comment:
Exactly. That's why MSSQL considers it an error. But PHP doesn't
report back the error from MSSQL.
Previous Comments:
[2004-01-05 16:45:24] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
Nonumber may be divided by zero.
[2004-01-05 16:31:25] danielc at analysisandsolutions dot com
Description:
MSSQL seems to not like queries that divide by zero -- see the OSQL
commands below. But, PHP doesn't report it as an error.
osql -Usa
1 SELECT 0/0 AS FOO
2 go
Msg 8134, Level 16, State 1, Server BASE2K, Line 1
Divide by zero error encountered.
Reproduce code:
---
$c = mssql_connect('localhost', 'sa', 'pw');
$result = @mssql_query('SELECT 0/0 AS FOO', $c);
if ($result) {
$ar = mssql_fetch_array($result, MSSQL_ASSOC);
var_dump($ar);
} else {
echo mssql_get_last_message();
}
Expected result:
Divide by zero error encountered.
Actual result:
--
array(1) {
[foo]=
NULL
}
--
Edit this bug report at http://bugs.php.net/?id=26799edit=1
#26791 [NEW]: mssql.textlimit and mssql.textsize can't be set via ini_set()
From: danielc at analysisandsolutions dot com
Operating system: Windows 2000
PHP version: 4.3.4
PHP Bug Type: MSSQL related
Bug description: mssql.textlimit and mssql.textsize can't be set via ini_set()
Description:
The mssql.textlimit and mssql.textsize configuration options
can't be set via ini_set(). Changing them in php.ini works.
This is also the case in a recent PHP 5 snapshot
(500rc1-dev--php5-win32-200401022330).
This is the same issue as bug 20797 which was closed due to no feedback.
SCRIPT CAN CHANGE LIMIT
===
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
SET TEXTSIZE 20
SCRIPT CAN'T CHANGE LIMIT
=
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
ini_set('mssql.textlimit', 2147483647);
ini_set('mssql.textsize', 2147483647);
php.ini
mssql.textlimit = 2147483647
mssql.textsize = 2147483647
script
ini_set('mssql.textlimit', 20);
ini_set('mssql.textsize', 20);
php.ini
; mssql.textlimit = 2147483647
; mssql.textsize = 2147483647
script
SET TEXTSIZE 2147483647
php.ini
mssql.textlimit = 20
mssql.textsize = 20
script
SET TEXTSIZE 2147483647
--
Edit bug report at http://bugs.php.net/?id=26791edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26791r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26791r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=26791r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=26791r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=26791r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=26791r=needscript
Try newer version: http://bugs.php.net/fix.php?id=26791r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=26791r=support
Expected behavior: http://bugs.php.net/fix.php?id=26791r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=26791r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=26791r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=26791r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26791r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=26791r=dst
IIS Stability: http://bugs.php.net/fix.php?id=26791r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=26791r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=26791r=float
#20797 [Com]: 4k text limitation can be adjusted by INI_SET
ID: 20797 Comment by: danielc at analysisandsolutions dot com Reported By: carl dot landry at emergis dot com Status: No Feedback Bug Type: MSSQL related Operating System: Windows NT 4.0 build 1381 PHP Version: 4.2.2 New Comment: This is still an issue. Opened new bug: http://bugs.php.net/bug.php?id=26791 Previous Comments: [2003-01-02 18:41:35] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to Open. Thank you. [2002-12-07 01:20:46] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php4-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-latest.zip [2002-12-03 13:05:28] carl dot landry at emergis dot com To adjust the 4k limitation of TEXT fields, I changed the TEXTSIZE and TEXTLIMIT value of MSSQL (SET TEXTSIZE xxx) to a very high value to prevent interference. This works properly. Adjusting the mssql.textlimit and mssql.textsize values in php.ini would allow larger than 4k results to be returned. This seems also fine. However, changing this limit at run time (ini_set(mssql.textlimit, 12000); ini_set(mssql.textsize, 12000);, 12000 (int) or 12000 string, not making a difference) would have no impact on the selected result. PHPINFO() shows the new adjusted value but the result would still be limited to the value set in the PHP.INI file. Also, -1 (as suggested in the INI_SET function description page) seems to limit to 4k too. Server API: ISAPI MSSQL Library version: 7.0 More information can be supplied if requested. -- Edit this bug report at http://bugs.php.net/?id=20797edit=1
#26418 [Fbk-Csd]: loading class files crashes
ID: 26418
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Closed
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5CVS-2003-12-1
New Comment:
Works fine so far. Thanks.
Previous Comments:
[2003-12-15 09:48:01] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
Can not reproduce..
[2003-12-01 13:41:57] danielc at analysisandsolutions dot com
#! c:/progra~1/php/cli/php
?php
/*
* http://bugs.php.net/bug.php?id=26418
*
* Notice the inclusion of PEAR's DB class at the bottom. Make sure
* your include_path or the path in the require statement below is
* correct.
*
* The crashes involve a weird combination of factors. The factors
* can be rearranged to cause the crashes to vanish.
*
* If the parent class' name is 15 characters long, it crashes, but if
* it's 14 or 16 characters long, it does not. But the length of the
* class name isn't _really_ the problem.
*
* For example, the length of the method names and the existence of
* parameters play a role too. See the comment in the class for more
* details.
*/
//class A2345678901234 {
class A23456789012345 {
//class A234567890123456 {
}
//class B extends A2345678901234 {
class B extends A23456789012345 {
//class B extends A234567890123456 {
function foo() {}
function goo($Directory) {}
/*
* Crashes if the next method name is = 21 characters long.
* But doesn't crash if both methods are uncommented.
* Similarly, doesn't crash if the parameter, $Directory, is
removed
* from method goo(), above.
*/
function a2345689012345678901() {}
//function a23456890123456789012() {}
}
require_once('DB.php');
?
[2003-11-26 02:24:47] danielc at analysisandsolutions dot com
Description:
Using the latest snapshot, php5-win32-200311260330.zip, when a script
loads up a bunch of class files, a Dr Watson error dialog appears
saying PHP has crashed. Note, I'm just including the files, not
creating an object via new.
I've tried to pin this down to some particular lines of code, but have
been unable to find something in particular.
While certain combinations of my class files and PEAR::DB create the
crash, others don't.
This code worked fine until now, so I don't think it's the content. In
addition, I've tweaked PEAR.php and DB.php so methods that return by
reference are always returning variables.
Below is an excerpt from a dump file as examined by WinDbg:
(5e4.600): Access violation - code c005 (!!! second chance !!!)
eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0
edi=00d9c658
eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=
efl=0202
*** WARNING: Unable to verify checksum for php4ts.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for php4ts.dll -
php4ts!zend_ts_hash_rehash+481:
100dcf91 89510c mov [ecx+0xc],edx
ds:0023:6e692e73=
--
Edit this bug report at http://bugs.php.net/?id=26418edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. Previous Comments: [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) [2003-12-01 00:35:22] danielc at analysisandsolutions dot com No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -r var_dump($_SERVER['argv']); 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. [2003-11-27 19:24:09] danielc at analysisandsolutions dot com Your test of ignoring the php.ini file via the -n flag gets it to work as expected. FYI... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -n -i | grep argv register_argc_argv = On = On _SERVER[argv] = Array C:\PROGRA~1\php\cliphp -v PHP 5.0.0b3-dev (cli) (built: Nov 26 2003 04:10:19) [2003-11-27 19:03:46] [EMAIL PROTECTED] Try following: php -n -r var_dump($_SERVER['argv']); 1 2 3 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26418 [Fbk-Opn]: loading class files crashes
ID: 26418
User updated by: danielc at analysisandsolutions dot com
Reported By: danielc at analysisandsolutions dot com
-Status: Feedback
+Status: Open
Bug Type: Zend Engine 2 problem
Operating System: Windows 2000
PHP Version: 5CVS-2003-12-1
New Comment:
#! c:/progra~1/php/cli/php
?php
/*
* http://bugs.php.net/bug.php?id=26418
*
* Notice the inclusion of PEAR's DB class at the bottom. Make sure
* your include_path or the path in the require statement below is
* correct.
*
* The crashes involve a weird combination of factors. The factors
* can be rearranged to cause the crashes to vanish.
*
* If the parent class' name is 15 characters long, it crashes, but if
* it's 14 or 16 characters long, it does not. But the length of the
* class name isn't _really_ the problem.
*
* For example, the length of the method names and the existence of
* parameters play a role too. See the comment in the class for more
* details.
*/
//class A2345678901234 {
class A23456789012345 {
//class A234567890123456 {
}
//class B extends A2345678901234 {
class B extends A23456789012345 {
//class B extends A234567890123456 {
function foo() {}
function goo($Directory) {}
/*
* Crashes if the next method name is = 21 characters long.
* But doesn't crash if both methods are uncommented.
* Similarly, doesn't crash if the parameter, $Directory, is
removed
* from method goo(), above.
*/
function a2345689012345678901() {}
//function a23456890123456789012() {}
}
require_once('DB.php');
?
Previous Comments:
[2003-12-01 03:22: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 possible, make the script source available online and provide
an URL to it here. Try avoid embedding huge scripts into the report.
[2003-12-01 00:39:30] danielc at analysisandsolutions dot com
Same problem with new snapshot: php5-win32-200312010330.zip
[2003-11-28 23:48:43] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5-win32-latest.zip
[2003-11-26 02:24:47] danielc at analysisandsolutions dot com
Description:
Using the latest snapshot, php5-win32-200311260330.zip, when a script
loads up a bunch of class files, a Dr Watson error dialog appears
saying PHP has crashed. Note, I'm just including the files, not
creating an object via new.
I've tried to pin this down to some particular lines of code, but have
been unable to find something in particular.
While certain combinations of my class files and PEAR::DB create the
crash, others don't.
This code worked fine until now, so I don't think it's the content. In
addition, I've tweaked PEAR.php and DB.php so methods that return by
reference are always returning variables.
Below is an excerpt from a dump file as examined by WinDbg:
(5e4.600): Access violation - code c005 (!!! second chance !!!)
eax=00866dfc ebx=00d9ad80 ecx=6e692e67 edx=0063 esi=00d9c5e0
edi=00d9c658
eip=100dcf91 esp=0012fae8 ebp=78001db0 iopl=0 nv up ei pl nz na
pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=
efl=0202
*** WARNING: Unable to verify checksum for php4ts.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols
for php4ts.dll -
php4ts!zend_ts_hash_rehash+481:
100dcf91 89510c mov [ecx+0xc],edx
ds:0023:6e692e73=
--
Edit this bug report at http://bugs.php.net/?id=26418edit=1
#26206 [Bgs-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Bogus +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. Previous Comments: [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) [2003-12-01 00:35:22] danielc at analysisandsolutions dot com No luck with the new snapshot. Downloaded php5-win32-200312010330.zip, copied php.ini-recommended to php.ini, turned register_argc_argv = On, ran the following... C:\PROGRA~1\php\cliphp -i | grep argv register_argc_argv = On = On C:\PROGRA~1\php\cliphp -r var_dump($_SERVER['argv']); 1 2 3 PHP Notice: Undefined index: argv in Command line code on line 1 NULL [2003-11-29 00:15:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip I can not reproduce this on windows using latest CVS snapshot. 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
#26206 [Fbk-Opn]: argv and argc not defined
ID: 26206 User updated by: danielc at analysisandsolutions dot com Reported By: danielc at analysisandsolutions dot com -Status: Feedback +Status: Open Bug Type: CGI related Operating System: Windows 2000 PHP Version: 5CVS-2003-11-11 (dev) New Comment: Yes. Works fine with php4-win32-STABLE-200312020130.zip Are the old PHP5 snapshots available anywhere? I'll be glad to track down when this problem started. Previous Comments: [2003-12-02 00:12:38] [EMAIL PROTECTED] Does PHP 4 snapshots work? [2003-12-01 13:57:39] danielc at analysisandsolutions dot com Everything worked fine until I switched from php5-win32-200310010230.zip to php5-win32-200311040330.zip I will track down exactly which snapshot in this time period started causing the problem. Then someone can examine the changes made in order to isolate the problem. Please inform me where I can find old snapshots to do this. http://snaps.php.net/win32/ only has the most recent few. [2003-12-01 13:31:20] [EMAIL PROTECTED] Well, I can't reproduce this with either CLI or CGI, using either php.ini-dist or php.ini-recommended. So there's something wrong with your system, not PHP. [2003-12-01 12:04:35] danielc at analysisandsolutions dot com 100% certain. New PHP installs on this system are by moving the entirety of the old install aside, extracting the contents of a new snapshot .zip file then copying the exact files/structure over to the php directory. The system finds the DLLS via the %path%, in which C:\PROGRA~1\Php;C:\PROGRA~1\Php\dlls; are the first two entries. The PHP DLL's have never been copied to any other location on this computer. [2003-12-01 03:25:23] [EMAIL PROTECTED] And you're absolutely sure you don't have ANY old PHP related dlls in your system before you installed the snapshot? (delete all php4ts.dll files..) 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/26206 -- Edit this bug report at http://bugs.php.net/?id=26206edit=1
